Коли захист хостингу блокує наш сервер

Багато хостингів ставлять перед сайтом захисний шар. Він стежить за вхідними з'єднаннями і, щойно якесь здається йому підозрілим, відповідає капчею, JavaScript-перевіркою або просто 403 замість сторінки. Відвідувач один раз пройде капчу й більше про неї не згадає. Наш сервер так не може: він не виконує скрипти, не зберігає куки й не має кому натиснути кнопку – він отримує сторінку з перевіркою і вважає її відповіддю вашого сайту.

Незручність у тому, що такий захист часто увімкнений за замовчуванням, на тарифі, який ніхто не налаштовував, – тож сайт, який у браузері виглядає цілком справним, може бути закритий для нас від першого дня в мережі.

Що саме ламається

Traffman звертається до вашого сайту ззовні в трьох ситуаціях, і такий захист ламає всі три:

• Верифікація клієнта. Після збереження API ключа й секрета на вашому сайті наш сервер робить зворотний запит до нього, щоб підтвердити, що клієнт справді належить цьому сайту. Якщо замість відповіді приходить капча, верифікація не завершується: клієнт лишається в стані Очікує підтвердження, лист із підтвердженням не надходить, а обмін не може початися – див. підтвердження клієнта.
• Валідація контенту. Кожен переданий матеріал завантажується так, як його завантажив би анонімний відвідувач. Сторінка з перевіркою – це не стаття, тому матеріал позначається як Невалідний, і зазвичай усі матеріали одразу, протягом однієї години – див. як працює валідація.
• Кліки по вашому контенту. Коли відвідувач натискає на ваш матеріал у блоці на сайті іншого учасника, сервіс перевіряє сторінку саме в цю мить. Заблокована перевірка відправляє відвідувача на нашу сторінку контент недоступний, і трафік втрачається – див. ревалідацію.

Блоки на вашому власному сайті при цьому працюють, бо ці запити йдуть від вашого сайту до нас, а не навпаки. Саме це й збиває з пантелику: сайт має вигляд повноцінного учасника, тимчасом як його власний контент тихо випав з обміну.

Як це розпізнати

Ознаки мають одну спільну форму – усе, що робиться з вашого боку, вдається, а все, що робиться в бік вашого сайту, ні:

• Клієнт не виходить зі стану Очікує підтвердження, хоча ключ і секрет правильні.
• Усі передані матеріали отримують стан Невалідний, хоча ті самі адреси нормально відкриваються у вашому браузері.
• Вкладка Healthcheck у плагіні повідомляє, що з'єднання або адресу контенту не вдалося прочитати.

Сторінка, яка відкривається в приватному вікні браузера, але все одно не проходить нашу перевірку, – типова картина: захист пропускає браузери й зупиняє все інше.

Де шукати цю опцію

У кожній панелі вона зветься по-своєму, тож варто переглянути всі назви:

• Bot protection, Anti-bot, Bot Fight Mode
• Web Application Firewall, WAF, ModSecurity
• Proactive defence, Attack protection, Anti-DDoS, Under Attack Mode
• IP reputation, Country blocking, Rate limiting

У панелі керування хостингом вони зазвичай лежать у розділі Security (Безпека). Якщо сайт стоїть за Cloudflare чи іншим CDN – це другий, окремий шар зі своїми налаштуваннями: вимкнення опції в панелі хостингу там нічого не змінює. А сам WordPress може тримати третій: плагіни безпеки на кшталт Wordfence чи All-In-One Security блокують «поганих ботів» самостійно, зсередини сайту.

Два способи це виправити

Пропустити наш сервер. Кращий варіант: захист і далі працює для всіх інших, а всередину пускається лише наша адреса. Пошукайте в тому самому розділі поле IP allowlist, Whitelist або Trusted IPs і додайте адресу, вказану нижче. Деякі панелі приймають також винятки за шляхом – усе, що наш сервер запитує в сайту на WordPress, лежить під /wp-json/traffman/, – але винятку за адресою цілком достатньо.

Вимкнути опцію. Це стосується всього сайту, тож підходить, коли додати адресу нікуди, – або щоб підтвердити діагноз: вимкніть захист, запустіть healthcheck, увімкніть назад. Якщо перевірка проходить лише при вимкненому захисті, причину знайдено.

Якщо нічого з цього у вашій панелі немає, це звичайне звернення до підтримки. Приблизно такого формулювання зазвичай достатньо: «Прошу додати IP-адресу N.N.N.N до білого списку захисту від ботів і фаєрвола сайту – це сервіс, з яким працює мій сайт, а його запитам відповідає капча.»

Адреса нашого сервера

Запити від Traffman до вашого сайту завжди надходять з однієї адреси:

142.93.104.213

Саме її треба додати в білий список. Якщо вона колись зміниться, ця сторінка оновиться ще до того, як зміна набуде чинності, – тож звіряйтеся тут, а не з адресою, записаною десь окремо.

Як перевірити, що допомогло

На WordPress плагін відповідає одразу: відкрийте Traffman → Settings → Healthcheck і натисніть обидві кнопки – Check the connection from the API server to your client і Check content URL availability on your site. Два повідомлення про успіх означають, що наш сервер тепер дістається вашого сайту. Докладніше про вкладку – у встановленні плагіна.

Клієнт, що залишився в стані Очікує підтвердження, сам повторно не перевіряється, тож запустіть верифікацію заново: на вкладці API ще раз натисніть Save з тими самими ключем і секретом.

Контент, уже позначений як невалідний, нічого натискати не потребує. Ці матеріали лишаються в циклі повторних перевірок і стають валідними після першої успішної, хоча давно зламаний матеріал перевіряється рідко – див. ревалідацію. Повторне збереження допису у WordPress передає його наново й одразу планує свіжу перевірку.

Якщо ваш сайт працює через власну інтеграцію, а не через плагін, ті самі дві перевірки доступні як виклики API – див. документацію API.