Gdy ochrona hostingu blokuje nasz serwer

Wiele hostingów stawia przed stroną warstwę ochronną. Obserwuje ona przychodzące połączenia i gdy tylko któreś wyda jej się podejrzane, odpowiada captchą, testem JavaScript albo zwykłym 403 zamiast stroną. Odwiedzający raz rozwiąże captchę i więcej o niej nie pomyśli. Nasz serwer tak nie potrafi: nie wykonuje skryptów, nie przechowuje ciasteczek i nie ma komu nacisnąć przycisku – odbiera stronę z testem i bierze ją za odpowiedź twojej strony.

Kłopot w tym, że taka ochrona bywa włączona domyślnie, na pakiecie, którego nikt nie konfigurował – więc strona wyglądająca w przeglądarce całkiem zdrowo może być dla nas zamknięta od pierwszego dnia w sieci.

Co to psuje

Traffman sięga do twojej strony z zewnątrz w trzech sytuacjach, a ochrona tego rodzaju psuje wszystkie trzy:

• Weryfikacja klienta. Po zapisaniu klucza i sekretu API na twojej stronie nasz serwer wykonuje do niej zwrotne żądanie, aby potwierdzić, że klient rzeczywiście należy do tej strony. Jeśli odpowie captcha, weryfikacja nigdy się nie kończy: klient pozostaje w stanie Oczekuje na potwierdzenie, email z potwierdzeniem nie przychodzi, a wymiana nie może ruszyć – zobacz potwierdzanie klienta.
• Walidacja treści. Każdy przesłany materiał jest pobierany tak, jak pobrałby go anonimowy odwiedzający. Strona z testem nie jest artykułem, więc materiał zostaje oznaczony jako Niepoprawna – zwykle wszystkie naraz, w ciągu tej samej godziny – zobacz jak działa walidacja.
• Kliknięcia w twoje treści. Gdy odwiedzający kliknie twój materiał w bloku na stronie innego uczestnika, serwis sprawdza stronę dokładnie w tej chwili. Zablokowane sprawdzenie wysyła odwiedzającego na naszą stronę treść niedostępna, a ruch przepada – zobacz rewalidacja.

Bloki na twojej własnej stronie przez cały ten czas działają, ponieważ te żądania biegną od twojej strony do nas, a nie odwrotnie. To właśnie wprowadza w błąd: strona wygląda na pełnoprawnego uczestnika, podczas gdy jej własne treści po cichu wypadły z wymiany.

Jak to rozpoznać

Objawy mają jeden wspólny kształt – wszystko, co robisz ze swojej strony, się udaje, a wszystko, co dzieje się w stronę twojej witryny, nie:

• Klient nie wychodzi ze stanu Oczekuje na potwierdzenie, choć klucz i sekret są poprawne.
• Każdy przesłany materiał otrzymuje stan Niepoprawna, mimo że te same adresy otwierają się normalnie w twojej przeglądarce.
• Zakładka Healthcheck we wtyczce zgłasza, że połączenia albo adresu treści nie udało się odczytać.

Strona, która otwiera się w prywatnym oknie przeglądarki, a mimo to nie przechodzi naszego sprawdzenia, to typowy obraz: ochrona przepuszcza przeglądarki i zatrzymuje całą resztę.

Gdzie szukać tej opcji

W każdym panelu nazywa się inaczej, więc warto przejrzeć wszystkie nazwy:

• 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

W panelu hostingu leżą zwykle w sekcji Security (Bezpieczeństwo). Jeśli strona stoi za Cloudflare lub innym CDN-em, jest to druga, niezależna warstwa z własnymi ustawieniami – wyłączenie opcji w panelu hostingu niczego tam nie zmienia. Sam WordPress może trzymać trzecią: wtyczki bezpieczeństwa pokroju Wordfence czy All-In-One Security blokują «złe boty» na własną rękę, od środka strony.

Dwa sposoby, by to naprawić

Przepuścić nasz serwer. Lepsze wyjście: ochrona nadal działa wobec wszystkich innych, a do środka wpuszczany jest tylko nasz adres. Poszukaj w tej samej sekcji pola IP allowlist, Whitelist albo Trusted IPs i dodaj adres podany niżej. Niektóre panele przyjmują też wyjątki według ścieżki – wszystko, o co nasz serwer pyta stronę na WordPressie, leży pod /wp-json/traffman/ – ale sam wyjątek dla adresu w zupełności wystarczy.

Wyłączyć opcję. Dotyczy to całej strony, więc nadaje się tam, gdzie nie ma dokąd dopisać adresu – albo do potwierdzenia diagnozy: wyłącz ochronę, uruchom healthcheck, włącz ją z powrotem. Jeśli sprawdzenie przechodzi tylko przy wyłączonej ochronie, przyczyna jest znaleziona.

Jeśli w twoim panelu nie ma ani jednego, ani drugiego, jest to zwykłe zgłoszenie do wsparcia. Zwykle wystarcza mniej więcej takie sformułowanie: «Proszę o dodanie adresu IP N.N.N.N do białej listy ochrony przed botami i firewalla strony – należy do serwisu, z którym współpracuje moja strona, a na jego żądania odpowiada captcha.»

Adres naszego serwera

Żądania od Traffman do twojej strony przychodzą zawsze z jednego adresu:

142.93.104.213

To jego należy wpisać na białą listę. Jeśli kiedykolwiek się zmieni, ta strona zostanie zaktualizowana, zanim zmiana wejdzie w życie – warto więc sprawdzać tutaj, a nie adres zapisany gdzieś osobno.

Jak sprawdzić, czy pomogło

Na WordPressie wtyczka odpowiada od razu: otwórz Traffman → Settings → Healthcheck i naciśnij oba przyciski – Check the connection from the API server to your client oraz Check content URL availability on your site. Dwa komunikaty o powodzeniu oznaczają, że nasz serwer dociera już do twojej strony. Więcej o tej zakładce w instalacji wtyczki.

Klient pozostawiony w stanie Oczekuje na potwierdzenie nie jest weryfikowany ponownie sam z siebie, więc uruchom weryfikację od nowa: w zakładce API naciśnij Save jeszcze raz z tym samym kluczem i sekretem.

Treści oznaczone już jako nieprawidłowe nie wymagają naciskania czegokolwiek. Te materiały zostają w cyklu powtórnych sprawdzeń i po pierwszym udanym stają się znów prawidłowe, choć materiał zepsuty od dawna sprawdzany jest rzadko – zobacz rewalidacja. Ponowne zapisanie wpisu w WordPressie przesyła go na nowo i od razu planuje świeże sprawdzenie.

Jeśli twoja strona działa przez własną integrację, a nie przez wtyczkę, te same dwa sprawdzenia dostępne są jako wywołania API – zobacz dokumentację API.