К нам обратился заказчик с типичной, на первый взгляд, проблемой: рекламные кампании запущены, трафик на сайт идёт, но данные в аналитике не сходятся с реальностью. Часть переходов просто не фиксировалась — заявки терялись, атрибуция ломалась, оптимизировать кампании было невозможно.
Начали разбираться. Оказалось, что одна из рекламных площадок использует в UTM-ссылках динамические макросы формата ${DOMAIN} — автоматически подставляемые значения, которые должны помочь сегментировать трафик по источникам. Выглядит это так:
https://example.com/?utm_source=${DOMAIN}&utm_medium=cpc&utm_campaign=brand
При переходе по такой ссылке пользователь попросту не попадал на сайт — запрос блокировался. Никакой ошибки в интерфейсе рекламного кабинета, никакого предупреждения. Часть аудитории «исчезала», и никто не понимал почему.
В чём была причина: WAF и ложное срабатывание
Виновником оказался WAF (Web Application Firewall) — межсетевой экран веб-приложений, установленный на хостинге сайта. WAF стоит перед сайтом и в режиме реального времени проверяет каждый входящий HTTP-запрос по набору правил безопасности. Его задача — не пропускать потенциально опасные запросы: SQL-инъекции, XSS-атаки, попытки взлома через уязвимые параметры.
Почему именно символ «$»?
Конструкция ${...} — именно тот паттерн, который хакеры используют для атак типа Server-Side Template Injection (SSTI). Злоумышленник может передать в параметре что-то вроде ${7*7}, и если сервер уязвим, он выполнит этот код. WAF, обученный на правилах OWASP CRS (самый распространённый набор правил для ModSecurity), видит ${ в URL — и блокирует запрос превентивно.
Для WAF нет разницы: это макрос рекламной площадки или реальная атака. Срабатывает ложное срабатывание (false positive) — легитимный запрос блокируется как опасный. Мы обратились к хостингу за разъяснениями и получили ответ:
«Срабатывает защита от взлома/инъекций через уязвимые запросы (WAF), настроенная на общем сервере. В частном порядке она не может быть отключена для отдельных сайтов. Переопределение подобных настроек возможно только на выделенных (VPS) серверах».
Ответ технически верный — но не полный. WAF не нужно отключать целиком. Достаточно создать точечное исключение — и проблема решается без смены хостинга.
Решения: их несколько, и не все требуют смены хостинга
Не существует одного универсального способа решить эту проблему. В зависимости от ситуации, технических возможностей и готовности сторон к диалогу, варианты выглядят так:
- Попросить хостера добавить точечное исключение (whitelist rule) — разрешить
${...}в UTM-параметрах вашего домена, не снижая общий уровень защиты - Узнать ID правила, которое срабатывает — в логах сервера фиксируется конкретный Rule ID, по которому можно сделать точечное исключение
- Изменить формат макроса на стороне рекламной площадки — некоторые платформы поддерживают альтернативные форматы без символа
$ - Перейти на VPS или облачный хостинг — на выделенном сервере можно управлять правилами WAF самостоятельно
- Использовать серверное отслеживание (Server-Side Tracking) — настроить передачу данных в обход UTM-меток через серверные события или импорт из рекламной платформы
Ключевое правило при обращении в поддержку: не «отключите WAF», а «добавьте исключение для ложного срабатывания в UTM-параметрах». Это принципиально разные запросы, и второй гораздо чаще получает положительный ответ.
Итог: диалог оказался эффективнее переезда
Мы выбрали путь переговоров с хостером. После технического объяснения ситуации хостинг-провайдер пошёл навстречу и добавил whitelist-правило для нашего домена. Переходы по рекламным ссылкам с макросом ${DOMAIN} перестали блокироваться, статистика начала корректно собираться, атрибуция восстановилась — и всё это без смены хостинга и без снижения уровня безопасности сервера.
Когда WAF блокирует легитимный трафик — это не приговор и не повод немедленно менять хостинг. Это повод разобраться в причине и найти точечное решение. Зачастую достаточно одного грамотного письма в техподдержку.