Серверная клоака — это фильтр, который принимает решение на сервере вашего сайта: запрос посетителя приходит на хостинг, PHP-код спрашивает у сервиса фильтрации, кто перед ним, и только после ответа отдаёт браузеру оффер или нейтральную страницу. Клоака в браузере работает иначе: страница уже загружается, а JS-тег в её <head> прячет содержимое, проверяет визит и показывает нужный вариант.
Обе схемы решают одну задачу — отсеять ботов, сканеры, спай-сервисы и нецелевой трафик, — но видят визит с разных сторон и по-разному ломаются. Пошаговая установка разобрана в статье как подключить клоаку; здесь — архитектура: что происходит внутри, где у каждого способа сильные места и где слабые.
Серверная клоака (server-side cloaking): как идёт запрос
Путь визита при серверной схеме:
- Посетитель кликает по объявлению, браузер запрашивает
ваш-сайт.com. - Запрос попадает на ваш сервер, и первым отвечает PHP-файл, а не лендинг.
- Файл передаёт сервису данные запроса: IP, заголовки, параметры ссылки.
- Сервис проверяет визит и возвращает решение.
- Сервер отдаёт браузеру оффер или White Page. До этого момента браузер не получил ни байта страницы.
Ключевое свойство — страница не уходит к посетителю до решения. Боту нечего сохранить, блокировщику рекламы нечего вырезать, медленному интернету нечего показать раньше времени.
Клоака в браузере: как работает JS-тег
При браузерной схеме порядок обратный:
- Браузер запрашивает страницу, ваш хостинг отдаёт её всем одинаково.
- Первой строкой в
<head>стоит тег — он загружается раньше всего остального и прячет страницу. - Тег собирает сигналы браузера и отправляет их сервису.
- Пришло решение «оффер» — страница показывается. «White Page» или решения нет — посетителя уводит на нейтральную страницу.
Плюс такой схемы — простота: тег вставляется в любую страницу, к которой есть доступ к <head>, даже на конструкторе без своего сервера. Минус — HTML лендинга физически уже у браузера. Тег скрывает его, но не может «не отдать».
Что каждая клоака видит о визите
Главное отличие архитектур — набор сигналов.
| Сигнал | Сервер | Браузер |
|---|---|---|
| IP, провайдер, сеть, страна по адресу | Да | Да, через сервис |
| User-Agent, язык, реферер, заголовки запроса | Да | Да |
| Параметры ссылки: fbclid, gclid, ttclid, UTM | Да | Да |
| Выполняет ли клиент JavaScript | Нет | Да |
| Часовой пояс и язык браузера | Нет | Да |
| Признаки автоматизации (webdriver, headless) | Частично, по заголовкам | Да |
| Экран, платформа, свойства браузера | Нет | Да |
| Движения мыши и касания | Нет | Да |
| Время, проведённое на странице | Нет | Да |
Сервер видит запрос, браузер — среду, в которой этот запрос выполняется. Простого бота из дата-центра поймают оба. Автоматизированный браузер на домашнем прокси с правильным User-Agent сервер по одному запросу от человека не отличит — его выдаёт уже поведение JavaScript: несовпадение часового пояса со страной адреса, следы автоматизации, отсутствие движений. О таких признаках — в статьях headless-браузеры и отпечаток и VPN, прокси и IP дата-центров.
Гибрид: серверное решение плюс страница проверки
Поэтому чисто серверная схема на практике встречается реже, чем кажется. Серверный фильтр решает сразу, если всё ясно по запросу, а в спорных случаях отдаёт короткую страницу проверки: она выполняет JavaScript, собирает сигналы браузера и запрашивает решение повторно. Для человека это доли секунды ожидания, для простого бота — тупик.
В ArtisanClo PHP-файл работает именно так: если правила потока требуют JavaScript или минимального времени на странице, посетитель видит страницу ожидания и проверяется заново. А вот при подключении фильтром для Keitaro или шлюзом для Binom страницы проверки нет — решение принимается только по сети и признакам запроса, поэтому проверка JavaScript и время на странице там не действуют.
Скорость: где теряются миллисекунды
Любой фильтр добавляет к загрузке время на решение. Разница — в том, где именно.
- Серверная схема добавляет запрос от вашего хостинга к сервису до отдачи первого байта. Скорость зависит от сетевой связности хостинга: хороший сервер в дата-центре отвечает быстро, перегруженный виртуальный хостинг тормозит и лендинг, и проверку.
- Браузерная схема добавляет загрузку скрипта и запрос из браузера посетителя. На мобильном интернете это заметнее, но страница при этом уже загружается параллельно — после решения её не нужно скачивать заново.
- Страница проверки намеренно добавляет ожидание. Включайте её там, где строгость оправдана источником, а не везде по умолчанию.
На практике лендинг с десятком скриптов аналитики и тяжёлыми картинками теряет больше времени, чем любой из способов фильтрации. Оптимизация страницы обычно даёт больше, чем выбор архитектуры.
Надёжность: как клоака ведёт себя при сбоях
Отказоустойчивость — место, где архитектуры расходятся сильнее всего.
Если не загрузился JS-тег
Тег — это внешний скрипт. Если его не пропустила сеть, корпоративный фильтр или блокировщик на сервере, страница просто не спрячется, и её увидят все, включая ботов и спай-сервисы. Сбой здесь «открытый». Если же тег загрузился, но решения нет, он уводит посетителя на White Page — это сбой «закрытый».
Если сервис не ответил серверу
Серверный способ ждёт ответа ограниченное время. В ArtisanClo PHP-файл ждёт до 4 секунд, а при потере связи сутки обслуживает визиты по последнему полученному ответу: посетителей с меткой рекламного клика ведёт на оффер, остальных — на White Page. Визит, пришедший раньше самого первого ответа, получит ошибку 503. У фильтра для Keitaro и шлюза для Binom предел 3 секунды, после него визит уходит на White Page.
Если сломался хостинг
Здесь обе схемы равны: лендинг живёт у вас, и фильтр не поднимет упавший сервер. Сервис отвечает за решение, вы — за доступность страницы и сертификат.
| Ситуация | JS-тег | PHP-файл |
|---|---|---|
| Скрипт заблокирован по пути | Страницу видят все | Не применимо |
| Сервис не ответил | White Page | Работа по последнему ответу до суток |
| Нет исходящих соединений с хостинга | Не влияет | Ошибка 503, долгая загрузка |
| Защитный фильтр хостинга (WAF) | Обычно не влияет | Может резать запросы проверки |
Кэш, CDN и прокси: тихие враги серверной клоаки
Серверная схема рассчитывает на то, что каждый запрос дойдёт до PHP-файла. Три вещи этому мешают.
- Кэш страниц. Плагин кэширования, кэш хостинга или CDN отдают сохранённую копию, не спросив решение. В результате все видят одну и ту же страницу — ту, что попала в кэш. Лендинг с фильтром нужно исключать из кэширования. Тегу кэш HTML мешает меньше: скрипт внутри копии всё равно выполнится в браузере, если копия сделана после его установки.
- Прокси перед сайтом. Если хостинг ставит перед сервером свой прокси, PHP-файл видит адрес прокси вместо адреса посетителя, и фильтр оценивает ваш сервер, а не людей. Признак — у всех визитов в журнале один IP. Лечится передачей настоящего адреса (настройка real IP) или проксированием через Cloudflare, чьи заголовки файл понимает.
- Кэш решения в браузере. Чтобы не спрашивать сервис на каждую перезагрузку, решение для одного посетителя может храниться короткое время. В ArtisanClo при PHP-файле — до минуты, поэтому после правки потока проверяйте в новом окне инкогнито.
Разбор этих и других неисправностей — в статье клоака не работает.
Что умеет только серверная схема
Есть возможности, которые физически недоступны коду в браузере.
- Код ответа вместо страницы. Сервер может ответить 403 или 404, как закрытый адрес. Тег код ответа поменять не может — на его месте останется пустая страница.
- Теневой режим. Все посетители идут на оффер, а журнал показывает, кого фильтр отсёк бы. Так проверяют новое правило без потери трафика.
- Режим «Трекер». Фильтр никого не отсекает, только считает клики, конверсии и деньги и помечает ботов в отчётах. Подходит трафику, которому нужен учёт, а не фильтрация, — подробнее в статье трекер для арбитража.
В ArtisanClo теневой режим и режим «Трекер» работают при подключении PHP-файлом, фильтром Keitaro или шлюзом Binom; на JS-теге поток фильтрует как обычная клоака.
Обновления и обслуживание
Ещё одно различие, о котором вспоминают не сразу, — кто отвечает за актуальность кода на сайте.
- JS-тег загружается с сервиса при каждом визите. Когда сервис улучшает проверки браузера, все сайты с тегом получают новую версию автоматически — на вашей стороне ничего менять не нужно.
- PHP-файл лежит на вашем хостинге и сам не обновляется. Логика проверок и базы ботов живут на стороне сервиса, поэтому основная работа фильтра улучшается и без вас, но новые возможности самого файла требуют замены. В ArtisanClo об этом сообщает плашка «Доступна новая версия PHP-файла» со списком того, чего не умеет ваша текущая версия.
При этом настройки потока в обоих случаях хранятся в кабинете, а не в коде на сайте. Сменили страны, строгость или White Page — изменения действуют со следующего визита, перезаливать файл или вставлять тег заново не нужно.
Отдельно стоит помнить о правах доступа. PHP-файл выполняется на вашем сервере, поэтому берите его только из кабинета сервиса и не правьте вручную: «доработанный» файл из чата или с форума может делать на хостинге что угодно.
PHP клоака или JS-тег: что выбрать
| Ваша ситуация | Что подходит |
|---|---|
| Конструктор сайтов без доступа к серверу | JS-тег |
| Свой хостинг с PHP | PHP-файл |
| WordPress | Плагин, который ставит тот же серверный способ |
| Нужен учёт без фильтрации или теневая проверка правил | PHP-файл |
| Трафик уже идёт через Keitaro или Binom | Фильтр или шлюз трекера — см. Keitaro и клоака |
| Хостинг запрещает исходящие соединения | JS-тег |
Коротко: тег быстрее поставить, серверный способ надёжнее и даёт больше режимов. Настройки фильтрации при этом не зависят от архитектуры — они хранятся в потоке, и способ подключения можно сменить без правки правил. О сравнении с самописными скриптами, которые тоже часто называют «PHP-клоакой», — в материале облачная клоака или скрипт.
Совет. Какую бы схему вы ни выбрали, после установки откройте рекламную ссылку в инкогнито и найдите свой визит в журнале кликов. Причина решения сразу покажет, видит ли фильтр настоящий IP, срабатывает ли проверка и не отдаёт ли кэш старую копию.
Серверная фильтрация и правила площадок
Архитектура не меняет правовой стороны. Рекламные площадки запрещают показывать системе проверки объявлений не то, что увидит пользователь, — неважно, решает это сервер или браузер. Честная польза любой схемы — отсев ботов, скликивания, спай-сервисов и нецелевого гео, чистая статистика и учёт денег. Об этом подробнее в статье клоака для арбитража.
Итог
- Серверная клоака решает до отдачи страницы: не зависит от блокировщиков, умеет коды ответа, теневой режим и режим «Трекер», но требует PHP, исходящих соединений и аккуратности с кэшем и прокси.
- Клоака в браузере ставится в любой
<head>и видит сигналы, недоступные серверу, но HTML страницы уже у браузера, а незагрузившийся скрипт ничего не скрывает. - Лучшее из двух миров даёт серверное решение со страницей проверки: сеть и запрос смотрит сервер, поведение и среду — короткий JavaScript в браузере.
- Условия, возможности и состав тарифов — на страницах возможностей и тарифов.
