Hogyan lehet nagy mennyiségű webes adatot gyűjteni anélkül, hogy blokkolnának minket

Bevezető

A webkaparód néhány száz oldalon még jól működik. Ha viszont néhány százezerre irányítod, a lekérdezések fele 403-as hibakóddal, CAPTCHA-val vagy üres oldallal válaszol. Nem a parser hibás. A céloldal észrevette, hogy a forgalmad nem úgy viselkedik, mint egy emberé, és elkezdett ellenállni.

A nagy léptékű webkaparás leginkább arról szól, hogy ne tűnj ki a tömegből. Minden webhely, amit érdemes lekérdezni, valamilyen formában bot-felismerést alkalmaz, és minden további kérés újabb esélyt jelent arra, hogy megjelöljenek. Ezt úgy lehet legyőzni, ha az alapokat jól csinálod: a megfelelő webes adatgyűjtő proxykat használod, a kéréseket megfelelő ütemben küldöd, a kérések úgy néznek ki, mintha valódi böngészőből érkeznének, és van egy terved arra az esetre, ha a webhely visszavág. Ez a cikk bemutatja, hogyan történik valójában a blokkolás, és hogyan lehet olyan folyamatot felépíteni, amely folyamatosan gyűjti az adatokat anélkül, hogy minden riasztót bekapcsolna.

Miért blokkolják a webhelyek az automatizált adatgyűjtést?

A webhelyek nem azért blokkolják a webkaparókat, hogy nehezítsék a dolgot. Azért blokkolják őket, mert a forgalom pénzbe kerül nekik, és olyan adatokat ad ki, amelyeket inkább megőriznének. Egy agresszív webkaparó percenként több ezer kéréssel bombázhatja a szervert, megterhelve azt és eltorzítva az elemzési adatokat. Az árak, a terméklisták és a vélemények pontosan azok az adatok, amelyekre a versenytársaknak szükségük van, ezért az ezeket az adatokat tároló webhelyek a legkeményebben védik őket. Feltételezzük, hogy a célpontod már felkészült az olyanokra, mint te.

Hogyan döntenek a blokkoló rendszerek?

A blokkolás ritkán egyetlen szabályon alapul. A legtöbb védelmi rendszer folyamatosan pontokat számol minden látogató számára, és ha átléped a határt, CAPTCHA-t kapsz, vagy bezárul előtted az ajtó. Ez a pontszám három kérdésre ad választ: ki vagy, milyen gyorsan mozogsz, és közelről hogyan nézel ki.

Hogy ki vagy, az az IP-hírnév: egy ismert adatközponti tartomány vagy egy korábban szabálytalanul viselkedő cím már eleve hátrányt jelent. Hogy milyen gyorsan mozogsz, az a kérések gyakorisága. Hogy hogyan nézel ki, az az ujjlenyomatod, az általad elküldött fejlécek és a TLS-kézfogás, amelyek elárulják, hogy valódi böngésző vagy puszta szkript kezdeményezi-e a kapcsolatot.

A Cloudflare és az Akamai mindhárom tényezőt beépíti egy kérésenkénti valós idejű pontszámba. Ezért csúszik át egy adatgyűjtő simán egy kis webhelyen, míg egy védett oldalon, ugyanazzal a kóddal futva, falba ütközik.

Proxy-pool létrehozása a méretezhetőség érdekében

Kezdd azzal, hogy ki vagy, mert egy IP-cím nem képes nagy feladatot ellátni. Ha százezer kérést küldesz egy címről, gyorsan elindul a hírnév-ellenőrzés. A pool elosztja a terhelést sok IP-cím között, így egyik sem tűnik ki – ez minden nagyméretű adatgyűjtési rendszer alapja. Az itt kiválasztott webes adatgyűjtő proxy-k határozzák meg a további folyamatok felső határát.

A gyenge védelemmel rendelkező vagy védelem nélküli webhelyeken az adatközponti IP-címek végzik a nehéz munkát: olcsók, gyorsak és nagy mennyiségben elérhetők. Nagy volumenű munkához olyan adatközponti IP-címekre van szükséged, amely eket nagy mennyiségű adatgyűjtésre terveztek, nem pedig néhány megosztott cím re, amelyek egy nap alatt kimerülnek. A bökkenő az, hogy könnyen felismerhetők. A TorchProxies (2026) szerint az adatközponti proxy-k védelem nélküli célpontok esetén 60–90 százalékos sikerarányt érnek el, majd a Cloudflare vagy az Akamai botkezelése mögött 20–40 százalékra csökken a sikerarányuk.

A méretezés egyszerű számítás: ha egy webhely percenként körülbelül 10 kérést tolerál IP-címenként, és Önnek 6000-re van szüksége, akkor legalább 600 tiszta IP-címre van szüksége, plusz tartalék a jelzett címekre.

A kérések ütemezése és a rotációs logika

A következő szempont a sebesség. A rotáció határozza meg, hogy melyik IP-cím fogadja az egyes kéréseket; az elosztás pedig a kérések közötti időközöket.

A kérésenkénti rotáció minden híváshoz új IP-címet rendel, ami stateless feladatokhoz, például független termékoldalakhoz ideális. A sticky sessionek egy IP-címet tartanak fenn a kapcsolódó kérések sorozatán keresztül; erre akkor van szükség, ha a webhely nyomon követi a munkamenetet, például a fizetési folyamat során.

Az elosztás határozza meg, hogy a felhasználók elkerülik-e a blokkolásokat a weboldal-lekaparás során, vagy egyenesen belesétálnak azokba. Változtasd véletlenszerűen a kérések közötti késleltetést, mivel egy állandó 200 ms-os szünet önmagában is bot-jelzésnek számít. Korlátozd az IP-nkénti sebességet, és alkalmazz exponenciális visszavonulást, így a hibák esetén lassítasz, ahelyett, hogy erőltetnéd a folyamatot. A fenti ábra megmutatja, miért: a blokkolási arány a nullához közel marad, amíg át nem lépsz a célpont tűréshatárát, majd hirtelen megugrik. A Ranktracker SEO-eszközökhöz készült webes adatgyűjtési útmutatója bemutatja, hogyan biztosítja ugyanaz a sebességszabályozás a rangkövető pontosságát.

Fejlécek és ujjlenyomatok

Végül pedig az, hogy hogyan nézel ki. A tiszta IP-címek is lebukhatnak, ha a kérések maguk is egyértelműen szkriptre utalnak. Minden kérés fejléceket és egy TLS-ujjlenyomatot hordoz, és az észlelés mindkettőt összehasonlítja egy valódi böngészővel.

Kezdd a User-Agent-tel, de ne állj meg ennél. Egy valódi böngésző összeillő Accept, Accept-Language és Accept-Encoding fejlécek sorozatát küldi el következetes sorrendben, és egy olyan kérés, amely ezeket kihagyja vagy felcseréli a sorrendjüket, feltűnővé válik. Mindez alatt a TLS kézfogás húzódik meg, amely egy JA3 ujjlenyomatra vezethető vissza. Egy Python-kliens és a Chrome másképp kezdeményezik a kézfogást, még akkor is, ha a látható fejléceik megegyeznek, ezért a hatékony botellenes rendszerek elemzik a kézfogást, hogy kiszűrjék azokat a webkaparókat, amelyek csak a felszínt hamisítják. Gondoskodj róla, hogy minden kérés végig böngészőhöz hasonló legyen.

A CAPTCHA-k és a lágy blokkolások kezelése

Nem minden blokkolás jelzi magát. A kemény blokkolás nyilvánvaló: egy CAPTCHA-képernyő vagy egy 403-as hiba. A lágy blokkolás rejtőzködik. A webhely 200-as kódot ad vissza, de a testet korlátozzák, elvékonyítják, vagy olyan hibás adatokkal töltik meg, amelyek célja az adatkészlet tönkretétele anélkül, hogy erről értesítenének.

Az észlelés az elsődleges feladat. Jelöld meg azokat a válaszokat, amelyek gyanúsan kicsinek tűnnek, vagy azonosak olyan oldalakon, amelyeknek különbözniük kellene, és kezelje őket hibaként, még akkor is, ha az állapot „siker” jelzést mutat. A hibás bemenetek tönkreteszik mindazt, ami rájuk épül, ezért az adatminőség-ellenőrzés éppoly fontos, mint a hozzáférés. A Ranktracker útmutatója a pontos rangkövetéshez bemutatja, hogyan rontják el a zajos bemenetek a jelentett számokat.

Ha CAPTCHA-k jelennek meg, léteznek megoldó szolgáltatások, de az olcsóbb megoldás a forrásnál keresendő: lassítsd a kérésfrekvenciát, gyakrabban válts, tisztítsd meg az ujjlenyomatot, és így elkerülöd a kihívást.

Mikor kell áttérni a lakossági szolgáltatásra

Előfordul, hogy maga az IP-szint jelenti a felső határt. Ha a botkezelő rendszer folyamatosan blokkolja az adatközponti IP-poolodat, függetlenül attól, hogy mennyire jól szabályozod és álcázod a forgalmat, az a jel, hogy magasabb szintre kell lépned.

A lakossági IP-címek valódi otthoni eszközökről származnak, ezért olyan bizalmat élveznek, amelyet az adatközponti tartományok soha nem érhetnek el. A makacs célpontok esetében a rotáló lakossági IP-címekre való átállás olyan forgalmat biztosít, amely átlagos otthoni felhasználók forgalmaként jelenik meg, így áthidalja azokat a szűrőket, amelyek az adatközponti címeket azonnal elutasítják.

Az ára a sebesség és a pénz. A ProxyWing szerint az adatközponti proxy-k 3–10-szer gyorsabban működnek: nagyjából 200 ms alatt, szemben a lakossági proxy-k 500 ms-tól 2 másodpercig terjedő idejével. Több millió kérés esetén ez jelentős különbséget jelent, ezért érdemes rétegezni: az adatközponti proxy-t tartsd alapértelmezettként, és csak a blokkolt kéréseket irányítsd át a lakossági proxy-ra.

A keresési eredmények klasszikus példák erre. Ha SERP-eket gyűjtünk olyan eszközök táplálására, mint a Ranktracker SERP Checkerje, a legnehezebb oldalak gyakran a lakossági proxyra terelnek.

Teszteljen egy célponton, mielőtt kiterjesztené a műveletet

Mielőtt a webkaparót a teljes céllistára irányítanád, futtasd le egyetlen védett webhelyen, és figyeld a válasz kódokat. Kezdd egy kis adatközponti pool-lal, óvatosan szabályozd a sebességet, majd emeld a sebességet, amíg blokkolások nem jelennek meg, és lépj vissza az utolsó problémamentes szintre. Ez a szám az IP-nkénti felső határ, és ez határozza meg a pool méretét az egész feladathoz. Ha egy webhelyen sikerül beállítanod a webkaparó proxykat és a sebességszabályozást, ugyanaz a beállítás skálázható a többi webhelyre is.

Gyakran feltett kérdések

Hány proxyra van szükségem a nagy léptékű adatgyűjtéshez?

Ez a célpont toleranciájától és az Ön átviteli sebességétől függ. Számolja ki, hány kérésnek bír el egy IP percenként, mielőtt jelzésre kerülne, ossza el a célsebességet ezzel a számmal, majd adjon hozzá egy puffert. 6 000 kérésre van szüksége percenként egy olyan webhely ellen, amely IP-nként 10-et tolerál? Ez több mint 600 tiszta IP-címet jelent, nem pedig egy maroknyit, amit halálra dolgoztat.

Melyik a jobb a webes adatgyűjtéshez: az adatközponti vagy a lakossági proxy?

Egyik sem nyer egyértelműen. Az adatközponti proxy gyorsabb és olcsóbb, és a védelem nélküli webhelyeket is jól kezeli. A lakossági proxy lassabb és drágább, de ellenáll a szigorú bot-kezelésnek. A legtöbb feldolgozási folyamat mindkettőt futtatja, alapértelmezés szerint az adatközponti proxyt használja, és csak akkor vált át a másikra, ha a blokkolások kényszerítik rá.

Miért blokkolnak még proxy-k használata mellett is?

Általában a sebességkorlátozás vagy az ujjlenyomatok miatt, nem az IP-címek miatt. Ha egy nagy poolból váltogatsz, de gépi sebességgel, alapértelmezett fejlécekkel futtatod, a minta akkor is látható marad. Lassíts, véletlenszerűsíts, és először úgy tűnj fel, mint egy böngésző.

Megengedett a nyilvános adatok lekérdezése?

Ez egy jogi szürke zóna, amely a joghatóságtól és a webhely felhasználási feltételeitől függően változik. Ragaszkodj a nyilvánosan látható adatokhoz, tartsd tiszteletben a robots.txt fájlt, ahol csak lehet, hagyd békén a személyes adatokat, és kérj jogi tanácsot, mielőtt bármilyen nagy kereskedelmi adatgyűjtésbe kezdenél.