Jeśli kiedykolwiek uruchomiłeś scrapera i po 50 żądaniach zaczął zwracać błędy 403 albo captche, najprawdopodobniej problem leżał w proxy pool size scraping, czyli w rozmiarze puli proxy, której używałeś. Za mały pool to pewna blokada. Za duży, źle zarządzany, to marnowanie pieniędzy i zasobów. Konkretnie:
- Czym dokładnie jest proxy pool i jak wpływa na skuteczność zbierania danych
- Jak obliczyć minimalny rozmiar puli dla swoich potrzeb
- Dlaczego mobilne proxy 4G działają lepiej niż datacenter w kontekście pool rotation
- Jak skonfigurować rotację, żeby maksymalizować sukces requestów
Bez lania wody: od podstaw, przez liczenie, po konfigurację.
Czym jest proxy pool i jak działa rotacja IP
Proxy pool to zbiór adresów IP, przez które router przekierowuje twoje żądania HTTP lub SOCKS5. Każdy request możesz wysłać przez inny adres, przez co serwer docelowy widzi wielu różnych użytkowników zamiast jednego scrapera. To podstawa każdego projektu scrapingowego na jakąkolwiek skalę.
Rotacja IP działa prosto: scraper wysyła request przez IP numer 1, następny przez IP numer 2, i tak dalej. Po przejściu całej puli zaczyna od początku. Im większa pula, tym rzadziej każde pojedyncze IP pojawia się w logach serwera docelowego.
Typy rotacji w proxy pool
- Round-robin: każdy kolejny request idzie przez kolejne IP z listy, równomiernie obciążając całą pulę
- Random rotation: losowe wybieranie IP z puli, trudniejsze do przewidzenia dla systemów antyblokadowych
- Sticky session: jedno IP przypisane do konkretnej sesji użytkownika, przydatne przy logowaniu na konto
- Rotacja czasowa: zmiana IP co określony czas niezależnie od liczby requestów
W Proxy Poland możesz zmienić IP w ciągu 2 sekund przez wywołanie API lub panel sterowania. To oznacza, że nawet przy pojedynczym porcie masz dostęp do setek różnych adresów z sieci operatora mobilnego, co skutecznie symuluje dużą pulę.
Na skróty: Proxy pool to nie tylko lista adresów IP, to cały mechanizm zarządzania requestami, który decyduje o tym, czy twój scraper przeżyje dłużej niż 5 minut na agresywnie chronionych domenach.
Proxy pool size scraping: jak duża pula jest wystarczająca
To pytanie, które zadaje sobie każdy, kto zaczyna budować infrastrukturę do zbierania danych. Nie ma jednej odpowiedzi, bo rozmiar puli zależy od trzech zmiennych: liczby requestów na godzinę, agresywności systemu antyblokadowego na docelowej stronie i dopuszczalnego wskaźnika błędów.
Przyjmijmy konkretny przykład. Scrapujesz Allegro w poszukiwaniu cen produktów. Chcesz zbierać 10 000 rekordów dziennie. Allegro blokuje IP po około 200 requestach w ciągu godziny z jednego adresu. Matematyka jest prosta:
- 10 000 requestów dziennie = około 417 requestów na godzinę
- Limit per IP: 200 requestów na godzinę
- Minimalny rozmiar puli: 417 / 200 = 3 IP aktywne jednocześnie
- Z buforem bezpieczeństwa 50%: potrzebujesz minimum 5 IP
Ale to jest absolutne minimum. W praktyce dodaj do tego awaryjne adresy, bo część requestów skończy się błędami, i rotację zapobiegawczą, bo chcesz zmieniać IP zanim zostaniesz zablokowany, a nie po.
Skala projektu a rozmiar puli
- Mały projekt (do 5 000 requestów dziennie): 5 do 10 IP w puli wystarczy
- Średni projekt (5 000 do 50 000 requestów dziennie): 20 do 50 IP
- Duży projekt (ponad 100 000 requestów dziennie): 100 lub więcej IP, najlepiej z różnych zakresów
Pamiętaj, że liczby te dotyczą zwykłych serwisów. Google, Amazon czy Nike SNKRS mają systemy, które blokują po kilku requestach z tego samego IP, jeśli zachowanie wygląda nienaturalnie.
Jak systemy antyblokadowe wykrywają zbyt małe pule proxy
Nowoczesne systemy ochrony stron, takie jak Cloudflare, PerimeterX czy DataDome, nie patrzą tylko na liczbę requestów z jednego IP. Analizują wzorce, i to właśnie tutaj małe pule proxy zawodzą.
Gdy twoja pula ma 5 adresów i wysyłasz 1 000 requestów dziennie, każdy z tych adresów pojawia się w logach średnio 200 razy. System widzi, że te same adresy powtarzają się regularnie, w podobnych odstępach czasu, z identycznym user-agentem i bez typowej losowości ludzkiego przeglądania. To wyraźny sygnał bota.
Sygnały, które zdradzają za małą pulę
- Regularne pojawianie się tych samych IP w krótkich cyklach
- Brak przerw i losowości między requestami z danego adresu
- Identyczne fingerprinting przeglądarki przy rotacji IP (zmiana adresu bez zmiany reszty profilu)
- Requestowanie stron w nieludzkim tempie, np. 1 request co dokładnie 500ms
- Brak cookies i historii sesji typowej dla prawdziwego użytkownika
Sama zmiana IP bez zmiany innych parametrów to za mało. Ale duża pula IP, szczególnie z adresów mobilnych, znacząco utrudnia korelację zachowań między sesjami. Jeśli chcesz sprawdzić, jak twoje proxy są widoczne dla serwisów, możesz użyć narzędzia What Is My IP i zobaczyć, co dokładnie widzi serwer po drugiej stronie.
Na skróty: Za mała pula proxy nie tylko prowadzi do blokad, ale zostawia wyraźne ślady w logach, które serwisy mogą wykorzystać do zablokowania twojego projektu na poziomie innych parametrów, takich jak ASN czy zakres IP.
Datacenter vs mobilne proxy 4G w kontekście rozmiaru puli
Tu robi się ciekawie. Większość ludzi zakłada, że im więcej IP tym lepiej, i kupuje tanie pule datacenter z tysiącami adresów. To błąd, który kosztuje czas i pieniądze.
Proxy datacenter pochodzą z serwerowni. Ich zakresy IP są dobrze znane, i serwisy takie jak Google, Instagram czy Semrush mają te zakresy na czarnych listach. Możesz mieć 10 000 IP datacenter i nadal być blokowany systematycznie, bo ASN tych adresów jest od razu podejrzany.
Przewaga mobilnych IP 4G w proxy pool
Mobilne proxy 4G działają przez prawdziwe modemy LTE podłączone do sieci operatorów komórkowych. W naszej infrastrukturze w Polsce każdy modem używa prawdziwej karty SIM i korzysta z sieci CGNAT, tak samo jak zwykły telefon. To oznacza:
- Twoje IP wygląda jak IP normalnego użytkownika smartfona
- Adresy z sieci mobilnych mają bardzo niski wskaźnik blokowania, bo operatorzy przypisują je do milionów prawdziwych ludzi
- CGNAT sprawia, że za jednym IP może stać wielu użytkowników, co jest normą w sieciach mobilnych
- Nawet mała pula mobilnych IP ma wyższą skuteczność niż duża pula datacenter
W praktyce: 10 mobilnych IP 4G z rotacją co 2 sekundy często wystarcza do projektów, gdzie potrzebujesz 100 IP datacenter. To realna różnica w kosztach i zarządzaniu infrastrukturą. Sprawdź też test szybkości proxy, żeby zweryfikować, że twoje połączenia spełniają wymagania projektu.
Jak obliczyć optymalny rozmiar puli dla swojego projektu
Przejdźmy do konkretów. Oto formuła, której używamy przy konsultacjach z klientami:
- Zdefiniuj skalę: ile requestów dziennie planuje twój scraper?
- Sprawdź limity celu: ile requestów toleruje docelowa strona z jednego IP zanim zablokuje? Zacznij od testów z 50 requestami na IP i obserwuj odpowiedzi.
- Oblicz podstawę: requestów dziennie / limit per IP = minimalna liczba IP
- Dodaj bufor bezpieczeństwa: pomnóż przez 1.5 do 2 dla agresywnych serwisów
- Uwzględnij rotację: jeśli używasz rotacji czasowej co 10 minut, jedno IP z rotacją może zastąpić kilka statycznych
Przykładowe obliczenia dla różnych use case'ów
- Monitoring cen na Amazonie (20 000 requestów/dzień, limit 100/h per IP): potrzebujesz minimum 20 dedykowanych IP lub 5 IP z rotacją co 30 minut
- Scrapowanie profili LinkedIn (2 000 requestów/dzień, bardzo agresywna ochrona): minimum 20 IP, najlepiej mobilnych z losową rotacją
- SEO monitoring w Semrush-style (50 000 requestów/dzień): 50 do 100 IP z round-robin
Przy planach Proxy Poland możesz zacząć od jednego portu za 60 zł miesięcznie i testować zanim zainwestujesz w większą infrastrukturę. Jeden port z rotacją co 2 sekundy daje dostęp do setek różnych adresów w trakcie dnia roboczego.
Konfiguracja rotacji IP dla skutecznego scrapingu
Masz pulę proxy. Teraz musisz ją dobrze skonfigurować, bo zła konfiguracja niszczy skuteczność nawet najlepszej infrastruktury.
Rotacja przez API w Proxy Poland
Wywołanie zmiany IP przez nasze API wygląda tak:
GET https://panel.proxypol.com/api/rotate?port=YOUR_PORT&token=YOUR_TOKEN
Odpowiedź zwraca nowy adres IP w ciągu 2 sekund. Możesz wbudować to wywołanie bezpośrednio w logikę swojego scrapera, zmienia IP po X requestach lub po pierwszym błędzie 429.
Praktyczne zasady konfiguracji
- Zmieniaj IP prewencyjnie, zanim dostaniesz błąd, nie po. Ustaw limit na 70-80% tolerowanej liczby requestów per IP.
- Przy scrapingu wymagającym sesji (np. logowanie na konto) używaj sticky sessions i zmieniaj IP tylko między sesjami.
- Zawsze paruj rotację IP z rotacją user-agenta. Sama zmiana adresu bez zmiany nagłówków HTTP to połowiczny środek. Sprawdź jak wyglądają twoje nagłówki przez analizator nagłówków HTTP.
- Implementuj backoff: gdy dostaniesz 429 lub 503, odczekaj 30 do 60 sekund przed kolejnym requestem przez nowy IP.
- Loguj, które IP generują błędy. Jeśli jeden adres jest permanentnie zablokowany, wyklucz go z rotacji.
Na skróty: Rozmiar puli proxy to tylko część układanki. Bez inteligentnej rotacji i zarządzania sesjami nawet 1 000 IP nie uchroni cię przed wykryciem na poważnie chronionych platformach. Możesz też sprawdzić, czy twoja infrastruktura nie ma wycieków przez test DNS leak.
Dlaczego rozmiar proxy pool ma bezpośredni wpływ na sukces scrapingu
Trzy rzeczy, które warto zapamiętać. Po pierwsze, rozmiar puli to nie jest kwestia "im więcej tym lepiej", to matematyka: dopasuj liczbę IP do liczby requestów i limitów serwisu docelowego. Po drugie, jakość IP jest ważniejsza niż ilość. Dziesięć mobilnych adresów 4G z CGNAT pobije sto adresów datacenter na każdej poważnie chronionej platformie. Po trzecie, proxy pool size scraping to tylko jeden element, obok rotacji, zarządzania sesjami i nagłówków HTTP.
Jeśli chcesz zacząć od sprawdzonej infrastruktury bez ryzyka, Proxy Poland oferuje bezpłatny 1-godzinny trial bez karty kredytowej. Przetestuj, jak mobilne proxy 4G na prawdziwych modemach LTE w Polsce sprawdzają się w twoim projekcie, a potem wybierz plan dopasowany do skali. Zobacz plany i ceny Proxy Poland i zacznij zbierać dane bez blokad.
Praktyczna reguła na sierpień 2026 przy listingu PL marketplace: przy 8-12 workerach na jeden mobile IP i rotacji co request, pool 20-30 adresów 4G zwykle utrzymuje dziennie ok. 25-40 tys. requestów bez gwałtownego skoku captcha, o ile trzymasz rozsądne backoffy. Jak tylko share banów na IP przekroczy ~15% w oknie godziny, najpierw zwiększ cooldown albo skróć concurrency, zanim dokupisz kolejne IP.
Większy pool bez korekty tempa i tak spali nowe adresy w tym samym tempie.
Use-case z monitoringu cen na polskim marketplace: trzy sklepy, odświeżanie oferty co 15 minut, ok. 6 tys. kart produktów łącznie. Przy 10 workerach na IP i rotacji co request pool 24 adresów 4G zwykle starcza na cały dzień bez skoku captcha powyżej tła, o ile ban share w oknie godziny trzymasz poniżej 15%.
Jak ban share rośnie, najpierw wydłuż cooldown o 30-60 s albo zejdź do 6-8 workerów - dokupienie IP bez korekty tempa tylko przyspiesza spalanie puli.
Stan na sierpień 2026 dla lekkiego rank trackingu SERP w PL: 4-6 workerów na IP, odświeżanie 50-80 fraz co godzinę i rotacja co request. Pool 8-12 adresów 4G zwykle trzyma dobę bez skoku captcha, o ile ban share na IP w oknie godziny zostaje poniżej ok. 10%. To mniej niż przy scrapingu kart produktów, bo payload jest lżejszy.
Gdy success spada o więcej niż 5 punktów procentowych trzy godziny z rzędu, najpierw wydłuż cooldown o 20-40 s, a dopiero potem dokup IP. Większy pool bez korekty tempa i tak spali nowe adresy.
Dla lekkiego monitoringu SERP z PL 4G w 2026 sensowny punkt startu to ok. 1 IP na 5-8 workerów przy 40-60 słowach na godzinę i cooldownie 25-35 s po 429. Powyżej ok. 12 workerów na jednym sticky adresie success zwykle spada zanim skończy się pula. Zanim dokupisz 10 kolejnych IP, wydłuż cooldown o 15 s na trzy godziny i porównaj success - często wraca bez większego poola.
Dla ściągania PDF-ów urzędowych i stron rejestrów z PL 4G w 2026 sensowny start to ok. 1 IP na 3-4 workery przy 20-30 dokumentach na godzinę i cooldownie 40-60 s po 403. Pool 6-10 adresów 4G zwykle wystarcza na dzień roboczy, o ile ban share na IP w oknie godziny zostaje poniżej ok. 12%. Gdy timeouty PDF rosną trzy godziny z rzędu, najpierw dodaj ok.
15 s do budżetu fetch, a dopiero potem dokup IP. Większy pool przy tym samym agresywnym tempie i tak spali nowe adresy przed południem.
Use-case porównywarka cen, sierpień 2026: jeden crawler na Allegro, Ceneo i OLX. Licz pool od hosta docelowego, nie od liczby workerów. Daj każdemu marketplace jeden sticky IP 4G i dwa rotujące na wyniki wyszukiwania. Gdy 5xx idzie z originu (strona sklepu leży), dokupienie 8 kolejnych IP nic nie naprawi. Najpierw zdejmij ten host z kolejki na 20-30 minut, potem dopiero ruszaj rozmiar puli.
Stan na sierpień 2026. Przy jednym hoście docelowym licz nie same IP, tylko prefiksy i operatorów. Dwanaście adresów 4G z Plus, Orange i Play zwykle trzyma success dłużej niż dwadzieścia adresów z jednego ASN. Jeśli w logu godzinnym ponad 70% requestów wychodzi z jednego prefiksu /24, rozrzuć wyjścia najpierw, zanim dokupisz kolejne IP.
Ban share w oknie godziny przy puli 15 lub więcej adresów i mniej niż trzech operatorach często rośnie wcześniej niż przy tej samej liczbie IP rozłożonych na trzy albo cztery sieci.
Nowy use-case na sierpień 2026: nocny watch dostępności na jednym polskim sklepie, nie pełny katalog. Lista 80-150 SKU, tylko flaga in_stock, odświeżanie co 5-8 minut. Temu originowi daj jeden sticky IP 4G na karty produktu i dwa rotujące na listing. Pool 3-5 adresów zwykle starcza na zmianę nocną, o ile po 429 dajesz 45-90 s cooldown. Nie skaluj tej puli jak crawlera 24 adresów na trzy marketplace.
Gdy success spada, najpierw wydłuż odstęp między SKU, zanim dokupisz IP.
Stan na sierpień 2026: wielkość puli licz od delty w sitemap, nie od liczby URL w katalogu. Z jednego sticky IP 4G ściągnij sitemap.xml albo sitemap_index raz na godzinę. Jeśli lastmod pokazuje 200-400 zmian w 24 h, na samą deltę zwykle starcza 2-4 adresów 4G oraz 1-2 workery na IP. Pełny recrawl wszystkich URL to osobne zadanie; wtedy wracasz do 8-12 IP.
Łączenie delty z pełnym skanem na tych samych wyjściach spala pulę do rana, nawet gdy liczba adresów wygląda na dużą.