Co zapora ukrywa przed logami: martwe pole blokad na brzegu sieci

Osoba odpowiedzialna za witrynę otwiera logi, szuka GPTBot, ClaudeBot albo PerplexityBot, nic nie znajduje i stwierdza, że AI nie interesują się jej treściami. Wniosek jest często fałszywy, i to z przyczyny czysto mechanicznej: kiedy zapora albo CDN odrzuca żądanie, zatrzymuje się ono na brzegu sieci, w warstwie edge, i nigdy nie dociera do serwera źródłowego. Nie istnieje więc w żadnym logu serwera. Cisza w logach nie oznacza nieobecności robotów; może oznaczać dokładnie odwrotną sytuację.

Jak żądanie może zniknąć

W witrynie serwowanej zza sieci CDN takiej jak Cloudflare każde żądanie przechodzi przez kilka warstw, zanim dotrze do serwera. Zapora aplikacyjna, opisana w dokumentacji WAF Cloudflare, ocenia reguły i może zablokować żądanie, przekierować je albo wyświetlić challenge. Moduł zarządzania robotami, szczegółowo opisany w dokumentacji Bots, klasyfikuje ruch automatyczny i stosuje wobec niego przyjętą politykę. Od 2024 roku platformy te proponują blokowanie robotów AI jednym kliknięciem, co Cloudflare zapowiadał we wpisie o blokowaniu robotów AI, i wiele witryn włączyło tę opcję, nie sprawdzając, co ona robi.

Każde żądanie zatrzymane na tym poziomie dostaje odpowiedź wytworzoną przez CDN, zwykle kod 403 albo stronę challenge. Serwer źródłowy nie widzi z tego nic. Logi Apache, nginx czy aplikacji nie zawierają takiego wiersza, a narzędzie do analizy logów, które czyta wyłącznie serwer źródłowy, nie ma go z czego policzyć.

Trzy błędy rozumowania, które z tego wynikają

1. „Żadna AI do nas nie zagląda.” Najczęstszy z nich. Witryna jest w rzeczywistości odwiedzana, tyle że każda wizyta zostaje odrzucona wcześniej. Reguła włączona na wszelki wypadek, czasem przez podwykonawcę, czasem jednym zaznaczonym polem w interfejsie, po cichu odcina wszelką możliwość bycia cytowanym.
2. „Nasz wskaźnik powodzenia crawlowania wynosi 100%.” Panel, który liczy odpowiedzi 200 zwrócone przez serwer źródłowy, pokazuje wynik idealny, bo docierają tam wyłącznie żądania przyjęte. Wskaźnik rzeczywisty, razem z blokadami, bywa bardzo niski.
3. „Robot nie respektuje naszego robots.txt.” Jeśli sam robots.txt serwuje serwer źródłowy, ale pierwsze żądanie robota zostaje zablokowane na brzegu sieci, robot nigdy go nie przeczytał. Obwinia się go o zachowanie, którego przyczyna jest lokalna.

Jak sprawdzić, co dzieje się na brzegu sieci

Kontrole, od najprostszej do najpełniejszej:

• Przeczytać ponownie konfigurację CDN. Reguły WAF, tryb zarządzania robotami, opcje „blokuj roboty AI”, listy odrzucanych user-agent. Trzeba czytać ją taką, jaka jest, a nie taką, jaką się pamięta z ustawiania: w witrynie, którą audytowaliśmy tego lata, odziedziczona po wcześniejszej konfiguracji reguła blokująca odcinała roboty, o których nikt w zespole nie sądził, że są blokowane.
• Przetestować prawdziwymi user-agent. Samodzielnie wysłać żądanie do publicznej strony, deklarując user-agent każdego robota AI, spoza własnej sieci, i sprawdzić kod odpowiedzi oraz to, kto ją wystawił. Kod 403 podpisany przez CDN w sytuacji, gdy serwer źródłowy odpowiada 200, jest bezpośrednim dowodem blokady na brzegu sieci.
• Czytać logi CDN, nie tylko serwera źródłowego. Duże sieci CDN udostępniają statystyki ruchu obejmujące żądania odrzucone, w podziale na reguły i na user-agent, czasem także na ścieżki. To tam widać roboty, które uchodziły za nieobecne. W Cloudflare dane te są dostępne przez interfejs i przez API, tokenem z uprawnieniem odczytu Zone Analytics; w planie bezpłatnym podział na ścieżki wymaga przejścia przez API.

Przypadek zmierzony

W innej witrynie, przemysłowej, audytowanej tego samego lata, logi serwera źródłowego nie pokazywały przez kilka tygodni ani jednego żądania robota AI, a panel crawlowania wyświetlał idealny wskaźnik powodzenia. Logi CDN opowiadały co innego: kilkaset żądań robotów AI odrzuconych kodem 403 przez regułę zapory, o których nikt nie miał śladu. Pierwotny wniosek, „AI do nas nie przychodzą”, był dokładnym odwróceniem rzeczywistości: przychodziły, regularnie, i odchodziły, nie przeczytawszy niczego. Witryna nie pojawiała się w żadnej wygenerowanej odpowiedzi, nie z braku zainteresowania silników, tylko przez jedno ustawienie bezpieczeństwa. Diagnoza zajęła godzinę; mogła nigdy nie zostać postawiona.

Pułapka adresu IP

Drugi skutek obecności CDN utrudnia czytanie logów serwera źródłowego: adres IP, który widzi serwer, należy do CDN, a nie do odwiedzającego, chyba że serwer jest skonfigurowany do odczytu nagłówka przenoszącego adres pierwotny. Kiedy tego ustawienia brakuje, wszyscy odwiedzający, ludzie i roboty, zdają się przychodzić z kilkudziesięciu adresów należących do CDN. Weryfikacje autentyczności opisane w naszym artykule o reverse DNS i zakresach IP stają się niemożliwe, a autentyczny robot może zostać wzięty za podszywającego się, albo odwrotnie. Nagłówek własny, dodawany przez CDN, przeżywa zwykle wszystkie pośrednie przeskoki tam, gdzie nagłówek ogólny bywa nadpisany. W Cloudflare jest to CF-Connecting-IP; nagłówek ogólny, X-Forwarded-For, może zostać nadpisany przez dowolnego pośrednika. Poproś dostawcę hostingu o dokładną nazwę tego, który dodaje, i sprawdź, czy rzeczywiście dociera do logu serwera źródłowego.

Jaką politykę utrzymać

Pytanie zasadnicze jest redakcyjne: serwis medialny, który chce być cytowany przez AI, nie ma żadnego powodu, by blokować ich roboty wyszukiwania i odczytu na brzegu sieci. Zablokowanie trenowania jest decyzją uprawnioną, ale podejmuje się ją w robots.txt, user-agent po user-agent, jak wyjaśniamy w tekście „robots.txt i AI”, a nie jednym przełącznikiem odrzucającym wszystko, co przypomina AI. Blokada na brzegu sieci ma sens wyłącznie wobec dowiedzionego ruchu nadużywającego: nienormalnych wolumenów, podszywania się, scraperów ignorujących robots.txt.

Trzeba zachować jedną ostrożność: nie blokować również podszywających się szeroką regułą opartą na user-agent. Reguła odrzucająca każdy „GPTBot” przychodzący z adresu spoza zakresów opublikowanych przez OpenAI wygląda na rozsądną; w praktyce odrzuci też żądania uprawnione tego dnia, w którym OpenAI doda zakres, którego lokalna lista jeszcze nie zna. Właściwą odpowiedzią na podszywanie się jest pomiar i spowolnienie, a nie ślepe odrzucanie.

Co znaczy mierzyć, kiedy blokada zostanie zdjęta

Kiedy brzeg sieci przepuszcza ruch, logi serwera źródłowego znów są wiarygodnym źródłem, pod warunkiem że przenoszą adres pierwotny i zachowują pełny user-agent. Można wtedy policzyć, robot po robocie i zastosowanie po zastosowaniu (trenowanie, wyszukiwanie, odczyt na żądanie), co AI naprawdę czytają: które strony, jak często i z jakim kodem odpowiedzi. To ten odczyt, a nie panel serwera źródłowego, pozwala twierdzić, że treść dociera do silników generatywnych. Metodę opisujemy szczegółowo w tekście „Czytanie access logu w 30 minut”.

Zasada jest właśnie taka: log serwera źródłowego dowodzi wyłącznie tego, co dotarło do serwera źródłowego. Wszystko, co odrzucono wcześniej, nie zostawia w nim żadnego śladu, i to właśnie trzeba poszukać gdzie indziej, zanim wyciągnie się jakikolwiek wniosek o AI.