Egy scraper-áradás a Cloudflare Free csomagján: mi állította meg, és mit hagytunk kikapcsolva

Üzemeltetés2026-10-31

Egy reggel az egyik termékleírásos oldalunk nem nyílt meg többé. A Cloudflare 524-es hibát mutatott a látogatóknak, az origin szerver oldalanként két-hat percet vett igénybe, és körülbelül tíz órán át semmi nem jelezte a problémát. Az ok egy scraper volt, amely lakossági proxykon keresztül másodpercenként kb. 225 kérést küldött.

Az áradás leírása

• Több ezer cím, egyenként egy-három kéréssel. Amerikai, spanyol, francia, brazil, brit és egyéb országokbeli otthoni szélessávú kapcsolatok, az a típusú forgalom, amelyet a lakossági proxyhálózatok bérbe adnak.
• Chrome felhasználói ügynökök Mac gépeken, 103-tól 151-ig terjedő verziószámokkal.
• Szinte soha nincs süti vagy Referer. A szerveren mintavételezett 2697 kérés közül 4 tartalmazott sütit és 4 Referert.
• Kétféle kliens. A kérések körülbelül fele nem küldött Sec-Fetch-* fejléceket és kliens hinteket: egy másolt felhasználói ügynök karakterlánccal rendelkező szkript. A másik fele teljes böngészőfejléceket küldött: egy headless böngésző.

Minden kéréshez minden oldalt renderelni kellett, így minden worker több száz renderelést sorolt be, és elérte a CPU-korlátját.

Miért nem segített a címenkénti korlátozás

A sebességkorlátozás címenként számolja a kéréseket. Mivel több ezer címről egyenként csak egy-három kérés érkezett, egyetlen cím sem közelítette meg a korlátot. Az országok blokkolása a látogatóinkat is blokkolta volna. Amit a scraper nem tudott olcsón meghamisítani, az az volt, hogy úgy viselkedjen, mint egy böngésző, amely már járt az oldalon.

A Cloudflare peremén: három ingyenes szabály

A Free csomag zónánként öt egyéni WAF-szabályt engedélyez. Hármat használtunk, mindet kezelt kihívással (managed challenge) blokkolás helyett, így egy tévedésből megakadt felhasználó átkattinthat:

• Hamis böngésző: egy GET kérés, amelynek felhasználói ügynöke tartalmazza a Chrome/ karakterláncot, és amelynek nincs Sec-Fetch-Mode fejléce. Minden 2019 utáni Chrome elküldi ezt.
• Scraper-felhők: oldal-kérés az Alibaba, Tencent és Huawei Cloud hálózatairól, ahonnan a kihívások nagy része származott.
• Vészhelyzeti szabály, alapértelmezetten kikapcsolva: egy GET kérés, amelynek nincs egyáltalán sütije és nincs Referere. Egy személy, aki már járt az oldalon, vagy egy hivatkozáson keresztül érkezik, érintetlenül halad át; egy sütit nem tároló scraper minden kérésnél kihívással találkozik. Csak áradás idején kapcsoljuk be, mert egy friss böngészőbe címet gépelő személyt is kihívás elé állít.

Mind a három engedi a Cloudflare ellenőrzött botjait, azokat a felhasználóügynököket, amelyek robotként azonosítják magukat, a saját címeinket, az API- és webhook-útvonalakat, valamint a nem oldal jellegű fájlokat. Két nappal később az özön még mindig tartott: egy óra alatt a hamis böngésző szabály több mint 10 000 kérést ellenőrzött. A Cloudflare által lekérdezésenként visszaadott 10 000 esemény 9 627 címről származott, amelyek közül egyik sem lépte túl a 4-et.

Az eredeti szerveren: kapu az alkalmazásban

A fej nélküli felén teljes böngészőfejlécek vannak, így a peremszabályok önmagukban nem fogják el, amíg a vészhelyzeti szabály ki van kapcsolva. Magában az alkalmazásban egy kis middleware-t tettünk az oldalrenderelő elé:

• a Sec-Fetch-Mode és a klienshintek nélküli Chrome felhasználóügynök 403-at kap, mielőtt bármilyen munka megtörténne;
• egy idegen, aki egyik sütinkkel sem rendelkezik, és nincs Refererje, csak akkor kap oldalt, ha a munkásnak van szabad kapacitása, másodpercenként néhány oldalon. Ezen felül egy 400 bájtos 503-as oldal beállít egy sütit, és két másodperc múlva újratölt. Egy ember a második próbálkozáskor megkapja az oldalt; egy sütit nem tároló scraper soha.

Az első percben a kapu kb. 6 700 hamis böngészőt utasított el, és kb. 6 700 idegent fordított el, miközben az idegeneknek másodpercenként kb. 9 oldalt szolgált ki. A lassú kérések nullára estek, a munkások CPU-terhelése a limitükről 12–15 százalékra csökkent, a memóriájuk pedig darabonként 4–5 GB-ról 0,65 GB-ra.

Amit kikapcsolva hagytunk

• Bot Fight Mode. Ez ellenőrzi az automatizált forgalmat, és a Free csomagban nem hagyható ki egyéni szabállyal, ráadásul elkapta a fizetési szolgáltatónk webhookjait.
• Under Attack mód a teljes zónára. Minden látogatót, API-ügyfelet és webhookot az interstitialba küld. A vészhelyzeti szabály ugyanezt a munkát végzi el, de csak az idegenek oldal-kéréseire.
• A Free csomag sebességkorlátozó szabálya. Ez címenként számol, amit ez az özön sosem vált ki.
• AI botok blokkolása. Azt szeretnénk, hogy az AI keresőasszisztensek megtaláljanak minket, és ezek a botok nem voltak a probléma.

A tanulság

Az otthoni proxykon keresztül érkező özönt könnyű felismerni arról, ami hiányzik belőle: böngésző fetch fejlécek, sütik és Refererek. Ezt ellenőrizd a peremen, tartsd az idegeneket azon a szinten, amit a munkásaid meg tudnak jeleníteni, és gondoskodj róla, hogy a szerveren kívülről is észrevegyék, ha egy oldal nem nyílik meg többé. A Night Watch mind a hármat csomagolja: az őrszemét, a szabályokat az automatikus kapcsolóval a vészhelyzetihez, és a kaput Python webalkalmazásokhoz.