Серверна клоака — це фільтр, який ухвалює рішення на сервері вашого сайту: запит відвідувача надходить на хостинг, 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 у браузері.
- Умови, можливості й склад тарифів — на сторінках можливостей і тарифів.
