Isang baha ng scraper sa Free plan ng Cloudflare: ano ang huminto dito, at ano ang iniwan naming naka-off

Ops2026-10-31

Isang umaga, tumigil ang pagbubukas ng isa sa aming mga site ng listing. Ipinakita ng Cloudflare sa mga bisita ang 524, kinuha ng origin ang dalawa hanggang anim na minuto bawat pahina, at walang nagbigay-alam sa amin sa loob ng humigit-kumulang sampung oras. Ang dahilan ay isang scraper na gumagamit ng residential proxies sa humigit-kumulang 225 requests bawat segundo.

Ang hugis ng baha

• Libu-libong address, isa hanggang tatlong requests bawat isa. Mga koneksyon ng home broadband sa US, Spain, France, Brazil, UK at iba pang lugar, ang uri ng traffic na iniupahan ng residential proxy network.
• Chrome user agents sa Mac, na may mga version number mula 103 hanggang 151.
• Halos walang cookie o Referer. Sa 2,697 requests na aming sinuri sa server, 4 ang may cookie at 4 ang may Referer.
• Dalawang uri ng client. Halos kalahati ang walang Sec-Fetch-* headers at walang client hints: isang script na may kinopyang user agent string. Ang kalahati naman ay may buong browser headers: isang headless browser.

Ang bawat pahina ay na-render para sa bawat request, kaya ang bawat worker ay nag-queue ng daan-daang renders at umabot sa kanyang CPU limit.

Bakit hindi nakatulong ang per-address limits

Ang rate limit ay bumibilang ng requests bawat address. Sa isa hanggang tatlong requests mula sa libu-libong address, walang isang address na malapit sa limit. Ang pag-block sa mga bansa ay magba-block sa aming mga bisita. Ang hindi kayang gawin nang mura ng scraper ay ang kumilos na parang browser na nakapunta na sa site.

Sa Cloudflare's edge: tatlong libreng rules

Pinapayagan ng Free plan ang limang WAF custom rules bawat zone. Gumamit kami ng tatlo, lahat ay may managed challenge sa halip na block, kaya ang taong nahuli nang hindi sinasadya ay makakapindot para dumaan:

• Pekeng browser: isang GET na ang user agent ay may Chrome/ at walang Sec-Fetch-Mode header. Ipinapadala ito ng lahat ng Chrome mula 2019.
• Scraper clouds: isang page request mula sa mga network ng Alibaba, Tencent at Huawei Cloud, kung saan galing ang karamihan ng aming na-challenge.
• Emergency, off by default: isang GET na walang cookie at walang Referer. Ang taong nakapunta na sa site, o dumating sa pamamagitan ng link, ay dadaan nang walang sagabal; ang scraper na hindi nag-iimbak ng cookies ay makakatanggap ng challenge sa bawat request. Pinapindot namin ito nang on lamang habang may baha, dahil pinapansin din nito ang taong nagta-type ng address sa bagong browser.

Pahintulutan ng lahat ng tatlo ang mga verified bot ng Cloudflare, ang mga user agent na nagpapangalan sa sarili bilang robots, ang aming mga address, ang mga path ng API at webhook, at ang mga file na hindi mga page. Dalawang araw ang nakalipas at patuloy pa rin ang baha: sa loob ng isang oras, hinamon ng fake-browser rule ang mahigit 10,000 request. Ang 10,000 event na ibinabalik ng Cloudflare bawat query ay galing sa 9,627 address, wala sa kanila ang may higit sa 4.

Sa origin: isang gate sa app

Ang headless na kalahati ay may buong browser headers, kaya hindi ito nahuhuli ng mga edge rules habang naka-off ang emergency rule. Sa mismong app, naglagay kami ng maliit na middleware sa harap ng page renderer:

• ang Chrome user agent na walang Sec-Fetch-Mode ni client hints ay nakakatanggap ng 403 bago pa man magsimula ang trabaho;
• ang estranghero, na walang kahit anong cookie namin at walang Referer, ay pinaglingkuran lamang habang may spare capacity ang worker, sa ilang pages kada segundo. Kapag lampas na dito, ang 400-byte na 503 page ay nagse-set ng cookie at nagre-reload pagkatapos ng dalawang segundo. Nakakakuha ang tao ng page sa ikalawang subok; ang scraper na hindi nagpapanatili ng cookies ay hindi kailanman nakakakuha.

Sa unang minuto nito, tinanggihan ng gate ang humigit-kumulang 6,700 fake browser at pinawalang-bahala ang humigit-kumulang 6,700 estranghero, habang pinaglingkuran ang mga estranghero ng humigit-kumulang 9 pages kada segundo. Bumaba sa zero ang mga mabagal na request, bumaba ang CPU ng mga workers mula sa kanilang limit patungong 12 hanggang 15 percent, at ang memorya nila mula 4 hanggang 5 GB bawat isa patungong 0.65 GB.

Ang mga iniwan naming naka-off

• Bot Fight Mode. Hinahamon nito ang automated traffic at hindi ito maiiwasan gamit ang custom rule sa Free plan, at nahuli nito ang mga webhook ng aming payment provider.
• Under Attack mode para sa buong zone. Ipinapasa nito ang bawat bisita, API client at webhook sa interstitial. Ang emergency rule ang gumagawa ng parehong trabaho para lamang sa mga page request ng mga estranghero.
• Ang rate-limiting rule ng Free plan. Binibilang nito kada address, na hindi kailanman na-trigger ng baha na ito.
• Pag-block sa mga AI crawler. Gusto naming mahuli ng mga AI search assistant, at hindi ang mga crawler na iyon ang problema.

Ang takeaway

Madaling makita ang baha sa pamamagitan ng residential proxies base sa mga kulang dito: browser fetch headers, cookies at Referers. Hamunin ito sa edge, panatilihin ang mga estranghero sa loob ng kaya ng mga worker mong i-render, at tiyakin na may nakakaalam sa labas ng server kapag tumigil na ang pagbubukas ng page. Night Watch ang nagpa-package ng lahat ng tatlo: ang watch, ang mga rules na may automatic switch para sa emergency one, at ang gate para sa mga Python web apps.