Powszechny scenariusz awarii w Puppeteer wygląda tak: pierwsze żądania przechodzą bez problemu, a potem kolejne zaczynają zwracać 403 albo 429, kończą się timeoutem albo trafiają na stronę z wyzwaniem bezpieczeństwa. Mimo to wiele poradników nadal pokazuje rotację proxy tak, jakby wystarczyło zmienić dwie linijki w konfiguracji.
A to w praktyce tak nie działa. Różnica między przykładem w stylu „dodaj flagę --proxy-server” a rozwiązaniem, które da się utrzymać w produkcji, jest ogromna. Ten przewodnik obejmuje rotację na poziomie całej przeglądarki, uwierzytelniane gatewaye, shardowanie przeglądarki lub zewnętrzne relaye, spójne profile przeglądarek, obsługę błędów na poziomie produkcyjnym oraz uczciwą odpowiedź na pytanie, kiedy w ogóle nie warto samemu zarządzać proxy.
Czym jest rotujące proxy i dlaczego Puppeteer go potrzebuje?
Proxy działa jako pośrednik między instancją Puppeteer a witryną, do której się łączysz. Strona widzi adres IP wyjściowy proxy, a nie Twój komputer. Rotujące proxy przełącza się między pulą takich adresów — czasem przy każdym żądaniu, czasem dla całej sesji — dzięki czemu ruch nie wygląda jak tysiąc kolejnych zapytań od jednego klienta.
Puppeteer potrzebuje tego szczególnie dlatego, że headless Chrome wysyłający setki kolejnych żądań z jednego IP to dokładnie taki wzorzec, który systemy antybotowe mają wykrywać. Dokumentacja Cloudflare opisuje kilka warstw wykrywania działających równolegle — heurystyki, sprawdzanie fingerprintu JavaScript, modele uczenia maszynowego i wykrywanie anomalii behawioralnych. Zmiana adresu IP rozwiązuje tylko jedną z tych warstw. Tylko jedną.
Warto znać trzy typy proxy, bo nie są zamienne:
- Proxy z centrów danych — tanie, szybkie i pochodzące od dostawców hostingu. Łatwe do oznaczenia, bo ich ASN (blok sieciowy) wyraźnie wskazuje na centrum danych, a nie na domowy internet.
- Proxy residential — ruch przechodzi przez prawdziwych dostawców internetu dla użytkowników końcowych, więc wygląda jak zwykłe domowe łącze. Są wolniejsze i droższe, ale znacznie bardziej wiarygodne.
- Proxy mobilne — adresy IP z sieci operatorów komórkowych; zwykle najdroższa opcja, przydatna wtedy, gdy faktycznie potrzebna jest tożsamość sieci mobilnej.
Wyjścia residential bywają mniej oczywiste niż proxy z centrów danych, jeśli patrzeć wyłącznie na klasyfikację ASN, ale żadna z tych kategorii nie jest odporna na blokady. Nie istnieje uniwersalny współczynnik wykrywania: wynik zależy od witryny docelowej, reputacji adresu wyjściowego, lokalizacji, historii sesji, profilu przeglądarki i zachowania zapytań.
Jeszcze jedno rozróżnienie, które często myli ludzi: statyczna lista, którą sam rotujesz (zarządzasz pulą, wybierasz kolejny IP, obsługujesz błędy) to coś innego niż proxy backconnect/gateway (łączysz się z jednym endpointem, a dostawca rotuje adresy wyjściowe w tle). Oba rozwiązania są poprawne; po prostu inaczej rozkładają złożoność.
Po co w ogóle ustawiać rotujące proxy w Puppeteer? Najczęstsze zastosowania
Uczciwa odpowiedź brzmi: prawdopodobnie nie potrzebujesz rotacji, dopóki jej naprawdę nie potrzebujesz — a wtedy potrzebujesz jej bardzo.
| Zastosowanie | Dlaczego rotacja ma znaczenie |
|---|---|
| Monitorowanie cen w katalogach produktów | Powtarzane żądania do katalogów z jednego IP mogą uruchamiać limity i sygnały reputacyjne |
| Wzbogacanie leadów / pozyskiwanie danych kontaktowych | Wielokrotne odwiedzanie profili z jednego IP wygląda jak scraping, a nie zwykłe przeglądanie, więc łatwo je wyłapać |
| Scrapowanie wyników SERP | Wyszukiwarki należą do najbardziej agresywnych w zakresie throttlingu IP i CAPTCHA |
| Analiza konkurencji | Wielodniowe, powtarzalne scrapowanie tej samej domeny buduje fingerprint powiązany z Twoim IP i historią ciasteczek |
| Agregacja treści | Dużo stron, mała wartość pojedynczej strony — dokładnie taki wzorzec ruchu, na który systemy antybotowe są wyczulone |
Nie ma żadnej stałej, wiarygodnej liczby typu „Amazon blokuje przy 51. żądaniu”. Serwisy nie publikują uniwersalnych progów, a mechanizmy ochrony mogą zmieniać się zależnie od endpointu, stanu konta, reputacji ASN i kształtu ruchu. Zacznij od najniższego dopuszczalnego tempa zapytań, sprawdzaj nie tylko status, ale też treść odpowiedzi, a rotację włączaj dopiero wtedy, gdy zmierzone zachowanie i polityka celu naprawdę tego wymagają.
Trzy strategie rotacji proxy w Puppeteer: którą wybrać?
To jest właśnie ten fragment, który większość poradników pomija — albo pokazuje tylko najprostszą, najmniej praktyczną wersję. Istnieją trzy poziomy szczegółowości i wybór złego poziomu albo marnuje Twój czas, albo niepotrzebnie komplikuje prosty problem.
| Strategia rotacji | Granularność | Restart przeglądarki? | Złożoność | Najlepsze do |
|---|---|---|---|---|
Na poziomie przeglądarki (--proxy-server) | 1 proxy na instancję przeglądarki | Tak | Niska | Proste, mało intensywne scrapowanie |
Gateway zarządzany przez dostawcę (proxy-chain + backconnect endpoint) | Polityka dostawcy/sesji | Nie | Średnia | Uwierzytelniane gatewaye rotujące |
| Shardowanie przeglądarki lub zewnętrzny relay | 1 proxy na shard przeglądarki albo regułę relay | Brak jednej podmiany w procesie | Wysoka | Kontrolowana współbieżność i precyzyjny routing |
Zanim wybierzesz, ważna uwaga: dokumentacja interceptowania sieci w Puppeteer jasno mówi, że setRequestInterception nie jest czystym przełącznikiem „zmień proxy dla tego jednego żądania” — każde przechwycone żądanie zostaje zatrzymane, dopóki jawnie go nie kontynuujesz, nie odpowiesz na nie albo nie anulujesz. Prawdziwy routing proxy per request zwykle oznacza przepuszczanie ruchu przez lokalny, programowalny gateway (np. proxy-chain), a nie ręczne żonglowanie proxy bezpośrednio w handlerze interceptu. Miej to z tyłu głowy, zanim zdecydujesz się na metodę 3 poniżej.
Jak skonfigurować rotujące proxy w Puppeteer: krok po kroku
Poziom trudności: średni
Szacowany czas: około 30–45 minut dla wszystkich trzech metod
Czego potrzebujesz: Node.js 18+, npm, lista proxy lub konto u dostawcy (format: protocol://user:pass@host:port) oraz pakiety puppeteer, proxy-chain i puppeteer-extra
Wymagania wstępne: co przygotować przed startem
Zainstaluj podstawowe pakiety:
npm install puppeteer proxy-chain puppeteer-extra puppeteer-extra-plugin-stealth
Weź listę proxy od dostawcy (dla czegoś więcej niż testy najlepiej residential) albo przynajmniej kilka testowych proxy, żeby sprawdzić kod, zanim zaczniesz zużywać realny wolumen żądań. Dane dostępowe trzymaj w zmiennych środowiskowych — nigdy nie wpisuj ich na sztywno i nigdy nie umieszczaj w URL, który może trafić do logów.
Metoda 1: rotacja proxy na poziomie przeglądarki z --proxy-server
To jest punkt wyjścia dla większości osób i nie bez powodu — jest przewidywalny. Puppeteer LaunchOptions dokumentuje args jako wspierany sposób przekazywania flag startowych Chrome, a --proxy-server to natywna flaga Chromium.
import puppeteer from 'puppeteer';
const proxyPool = [
'http://proxy1.example:8080',
'http://proxy2.example:8080',
'http://proxy3.example:8080',
];
let proxyIndex = 0;
async function scrapeWithRotation(url) {
const proxy = proxyPool[proxyIndex % proxyPool.length];
proxyIndex++;
const browser = await puppeteer.launch({
headless: true,
args: [`--proxy-server=${proxy}`],
});
const page = await browser.newPage();
// Jeśli proxy wymaga autoryzacji, ta metoda musi zostać wywołana przed jakąkolwiek nawigacją
await page.authenticate({
username: process.env.PROXY_USER,
password: process.env.PROXY_PASS,
});
await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 30_000 });
const content = await page.content();
await browser.close(); // zamknij przed przełączeniem proxy
return content;
}
Zwróć uwagę, że page.authenticate() po cichu włącza pod spodem request interception — tak wynika z dokumentacji Puppeteer — co wiąże się z niewielkim kosztem wydajnościowym, o którym warto pamiętać, zanim zaczniesz szukać przyczyny, dlaczego wszystko działa wolniej niż się spodziewałeś.
Oczekiwany rezultat: każde wywołanie uruchamia nową przeglądarkę przypisaną do innego proxy. Aby wykonać rotację, musisz zamknąć proces i uruchomić go ponownie — nie da się obejść kosztu startu. Przy scrapowaniu 50 stron ta metoda będzie wyraźnie wolniejsza od pozostałych dwóch, tylko przez czas uruchamiania przeglądarki.
Kiedy używać: skrypty o niskiej współbieżności, jednorazowe scrapowanie, sytuacje, w których prostota debugowania jest ważniejsza niż szybkość.
Metoda 2: uwierzytelniany gateway rotujący z proxy-chain
Chrome nie akceptuje poświadczeń w stylu user:pass@host bezpośrednio w URL proxy. Pakiet proxy-chain (utrzymywany przez Apify) rozwiązuje problem uwierzytelniania, uruchamiając lokalne anonimowe proxy, które przekazuje ruch do Twojego uwierzytelnionego upstreamu. Jeśli upstream jest rotującym albo backconnect gatewayem dostawcy, to dostawca zmienia IP wyjściowe za tym jednym endpointem zgodnie ze swoją polityką sesji. Sam proxy-chain nie przypisuje innego proxy do każdej istniejącej strony Puppeteer.
import puppeteer from 'puppeteer';
import { anonymizeProxy, closeAnonymizedProxy } from 'proxy-chain';
async function scrapeThroughGateway(upstreamProxyUrl, targetUrl) {
const localProxy = await anonymizeProxy(upstreamProxyUrl);
let browser;
try {
browser = await puppeteer.launch({
headless: true,
args: [`--proxy-server=${localProxy}`],
});
const page = await browser.newPage();
await page.goto(targetUrl, { waitUntil: 'domcontentloaded' });
return await page.content();
} finally {
if (browser) await browser.close();
await closeAnonymizedProxy(localProxy, true); // zawsze sprzątaj po sobie
}
}
Ten blok finally nie jest ozdobnikiem — osierocone lokalne serwery proxy zajmują porty, a zdarzało mi się, że scrapery cicho zużywały dostępne deskryptory plików przez noc, bo nikt nie zamykał zanonimizowanego proxy. proxy-chain zwraca też konkretne kody błędów (593 dla problemów DNS, 594 dla odmowy połączenia, 597 dla błędu autoryzacji), które naprawdę pomagają klasyfikować awarie — za chwilę do tego wrócimy.
Kiedy używać: uwierzytelniane gatewaye residential/datacenter, w których rotacją zarządza endpoint albo parametry sesji po stronie dostawcy. Jeśli potrzebujesz kilku stałych tożsamości proxy jednocześnie, użyj osobnych procesów przeglądarki (browser sharding) albo specjalnie zbudowanego zewnętrznego relay; natywny Puppeteer nie udostępnia wspieranej opcji proxy per page.
Metoda 3: routing per request wymaga zewnętrznego relay
To opcja o najwyższej granularności — teoretycznie każdy obraz, skrypt i wywołanie API na stronie mogłyby iść innym wyjściem. W praktyce to najbardziej kruche i najsłabiej opisane podejście, bo interceptowanie żądań w Puppeteer zostało zaprojektowane do filtrowania i modyfikowania requestów, a nie do podmieniania transportu sieciowego dla każdego z nich.
import puppeteer from 'puppeteer';
async function inspectRequests(url) {
const browser = await puppeteer.launch({ headless: true });
const page = await browser.newPage();
await page.setRequestInterception(true);
page.on('request', async (request) => {
// W praktyce prawdziwa podmiana proxy per request wymaga routingu
// przez lokalny relay (proxy-chain), a nie przełączania transportu przeglądarki w locie — Chrome tego nie wspiera.
// Większość produkcyjnych wdrożeń używa tego handlera do filtrowania/anulowania
// typów zasobów, a nie do zmiany proxy, łącząc to z browser sharding albo gatewayem.
if (['image', 'font', 'stylesheet'].includes(request.resourceType())) {
request.abort();
} else {
request.continue();
}
});
await page.goto(url, { waitUntil: 'networkidle2' });
await browser.close();
}
Uczciwa ocena: prawdziwe przełączanie IP per request wewnątrz Puppeteer nie jest zapewniane przez setRequestInterception(). Jeśli naprawdę potrzebujesz takiej granularności, kieruj Chrome przez programowalny zewnętrzny relay albo użyj frameworka do scrapingu zbudowanego wokół sesji proxy. W większości projektów jedno proxy na jeden shard przeglądarki albo gateway rotujący zarządzany przez dostawcę będzie po prostu łatwiejszy w obsłudze i audycie.
Pełny stos antydetekcji: same proxy nie wystarczą, żeby nie dostać bana
Częsta skarga brzmi: „Używam proxy, a i tak jestem blokowany”. Adres IP to tylko jeden z sygnałów, które nowoczesny system antybotowy może oceniać, a jego rotacja przy niezmiennych pozostałych sygnałach może wręcz stworzyć silniejszą anomalię. Przeglądarka, która twierdzi, że jest Windows Chrome, podczas gdy client hints, strefa czasowa albo locale mówią co innego, to klasyczny przykład.
Warstwa 1: rotujące proxy residential
Omówione wyżej — wyjścia residential są często bardziej wiarygodne niż datacenter, ale nie ma żadnego uniwersalnego minimalnego rozmiaru puli. Dobieraj ją na podstawie zmierzonego wolumenu żądań, długości sesji, cooldownów i sposobu ponownego użycia adresów przez dostawcę, zamiast wymyślać arbitralną liczbę IP.
Warstwa 2: stealth plugin, żeby ukryć sygnały headless Chrome
puppeteer-extra-plugin-stealth łata zestaw znanych cech headless: navigator.webdriver, ciągi vendor dla WebGL, brakujące obiekty Chrome runtime i kilka innych wycieków CDP. To naprawdę przydatna warstwa kompatybilności, ale README projektu uczciwie przyznaje, że to gra w kotka i myszkę i pełna ochrona prawdopodobnie nie jest możliwa. Traktuj to jako bazę, a nie gwarancję.
Warstwa 3: spójne profile przeglądarki i rozsądne tempo
Ciągi user-agent muszą być wewnętrznie spójne ze wszystkim innym, co zgłasza przeglądarka. Chrome User-Agent Client Hints udostępniają ustrukturyzowane dane platformy, więc ręcznie wpisany user-agent może przeczyć rzeczywistej platformie. Lepiej używać user agenta dostarczanego przez dołączoną wersję Chrome, utrzymywać stabilne viewport/locale/timezone w obrębie sesji i ograniczać tempo żądań zamiast wymyślać nowy fingerprint dla każdej strony.
Oto wszystkie trzy warstwy połączone w jednej konfiguracji uruchomienia:
import puppeteer from 'puppeteer-extra';
import StealthPlugin from 'puppeteer-extra-plugin-stealth';
import { anonymizeProxy, closeAnonymizedProxy } from 'proxy-chain';
puppeteer.use(StealthPlugin());
function boundedDelay(minMs = 800, maxMs = 1800) {
return new Promise((r) => setTimeout(r, minMs + Math.random() * (maxMs - minMs)));
}
async function stableProfileScrape(targetUrl, upstreamProxy) {
const localProxy = await anonymizeProxy(upstreamProxy);
let browser;
try {
browser = await puppeteer.launch({
headless: true,
args: [`--proxy-server=${localProxy}`, '--lang=en-US'],
});
const page = await browser.newPage();
await page.setViewport({ width: 1366, height: 768 });
await boundedDelay();
await page.goto(targetUrl, { waitUntil: 'domcontentloaded' });
return await page.content();
} finally {
if (browser) await browser.close();
await closeAnonymizedProxy(localProxy, true);
}
}
To właśnie ten blok większość konkurencyjnych poradników pomija — proxy, stealth i randomizacja fingerprintu w jednym miejscu, gotowe do skopiowania i dostosowania.
Obsługa błędów na poziomie produkcyjnym i sprawdzanie zdrowia proxy
Większość tutoriali kończy się w momencie, gdy działa ścieżka idealna. W prawdziwym scrapingu awarie zdarzają się cały czas — proxy padają, wygasają poświadczenia, cel ogranicza ruch w połowie procesu — i nic z tego nie rozwiąże samo „liczenie na szczęście”.
Retry z wykładniczym backoffem i jitterem
function backoffMs(attempt, base = 1000, cap = 30_000) {
const exponential = Math.min(cap, base * 2 ** attempt);
return Math.floor(exponential * (0.5 + Math.random() * 0.5)); // jitter zapobiega efektowi thundering herd
}
async function withRetry(fn, maxRetries = 4) {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
try {
return await fn();
} catch (err) {
if (attempt === maxRetries) throw err;
const delay = backoffMs(attempt);
console.warn(`Próba ${attempt + 1} nie powiodła się: ${err.message}. Ponawiam za ${delay} ms`);
await new Promise((r) => setTimeout(r, delay));
}
}
}
Automatyczne czarnolistowanie proxy, które zawodzą
const proxyStats = new Map(); // proxyUrl -> { success, failure }
function recordResult(proxyUrl, success) {
const stats = proxyStats.get(proxyUrl) || { success: 0, failure: 0 };
success ? stats.success++ : stats.failure++;
proxyStats.set(proxyUrl, stats);
}
function isHealthy(proxyUrl) {
const stats = proxyStats.get(proxyUrl);
if (!stats) return true;
const total = stats.success + stats.failure;
if (total < 5) return true; // jeszcze za mało danych
return stats.failure / total < 0.5; // czarnolistuj, jeśli odsetek błędów przekroczy 50%
}
function getHealthyProxy(pool) {
const healthy = pool.filter(isHealthy);
if (healthy.length === 0) throw new Error('W puli nie zostały żadne zdrowe proxy');
return healthy[Math.floor(Math.random() * healthy.length)];
}
Śledź typ błędu, a nie tylko sukces/porażkę — 407 (złe poświadczenia) i 429 (limit żądań) wymagają zupełnie innych reakcji. Męczenie proxy, które nie przechodzi autoryzacji, kolejnymi szybkimi retry tylko marnuje czas; rozwiązaniem jest sprawdzenie credentials, a nie szybsza rotacja.
Najczęstsze błędy rotujących proxy w Puppeteer i jak je naprawić
| Błąd | Najbardziej prawdopodobna przyczyna | Naprawa |
|---|---|---|
ERR_PROXY_CONNECTION_FAILED | Proxy nie działa lub jest niedostępne | Usuń z puli, spróbuj następnego proxy |
407 Proxy Authentication Required | Błędne poświadczenia lub nieobsługiwany typ autoryzacji | Sprawdź dane w page.authenticate(); przy poświadczeniach w URL użyj proxy-chain |
TimeoutError | Wolne proxy lub blokada po stronie celu | Zwiększ timeout; przejdź na proxy residential |
403 Forbidden | IP lub fingerprint został oznaczony | Zrotuj proxy + włącz stealth + randomizuj UA |
ERR_TUNNEL_CONNECTION_FAILED | Problem z tunelem HTTPS | Sprawdź obsługę metody CONNECT; przetestuj lokalny tunel proxy-chain |
Kilka rzeczy, które nie mieszczą się w tabeli, a warto je wiedzieć: status 200 nie oznacza sukcesu. Miękkie blokady bardzo często zwracają pełną stronę HTML — np. login wall albo ekran z wyzwaniem — przy normalnym kodzie statusu, więc sprawdzaj rzeczywistą treść, nie tylko status odpowiedzi. A gdy utkniesz, przewodnik debugowania Puppeteer zaleca uruchomienie z headless: false, dodanie slowMo i ustawienie NODE_DEBUG="puppeteer:*", żeby uzyskać szczegółowe logi protokołu — pamiętaj tylko, że takie logi mogą zawierać wrażliwe dane żądań, więc nie zostawiaj ich włączonych przeciwko produkcyjnym danym logowania.
Samodzielna rotacja proxy vs. gateway proxy vs. API do ekstrakcji AI
| Kryterium | Samodzielnie zarządzana rotacja listy | Backconnect Gateway (Bright Data, Oxylabs, Decodo) | API do ekstrakcji AI (Thunderbit) |
|---|---|---|---|
| Koszt (niski wolumen) | niski do średniego | średni–wysoki za GB | niski (free tier, potem opłata za jednostkę) |
| Niezawodność | zależy od Twoich health checków | wysoka (zarządzane przez dostawcę) | wysoka (zarządzana infrastruktura) |
| Ochrona przed detekcją | DIY — budujesz sam | częściowa (tylko rotacja IP) | wbudowana |
| Strukturalny wynik | nie (surowy HTML) | nie (surowy HTML) | tak (JSON według schematu) |
| Czas konfiguracji | godziny | minuty | minuty |
| Kontrola | pełna | ograniczona do API dostawcy | ograniczona do modelu schematu |
Aktualne ceny dostawców (sprawdzone 2026-08-07) dobrze pokazują, jak wygląda krzywa kosztów gatewaya: cennik residential Bright Data oferuje model pay-as-you-go i plany wolumenowe, których promocje mogą się zmieniać; Oxylabs pokazuje $6/GB przy 5 GB i $2.50/GB przy 1 TB; a Decodo (dawniej Smartproxy) pokazuje $3.75/GB przy 3 GB, $2.75/GB przy 100 GB oraz ofertę pay-as-you-go za $4/GB. Decodo deklaruje też pulę ponad 115M IP i skuteczność 99.92% — to deklaracje dostawcy, nie niezależnie potwierdzone benchmarki.
Schemat decyzyjny, którego naprawdę używam: czy musisz wchodzić w interakcję ze stroną — klikać, przewijać, wypełniać formularze, utrzymywać sesję logowania? Buduj to w Puppeteer z proxy. Jeśli potrzebujesz tylko danych już obecnych na stronie, najpierw sprawdź API do ekstrakcji, zanim zbudujesz infrastrukturę proxy, którą będziesz utrzymywać wiecznie.
Kiedy Puppeteer + proxy to przesada: wyciągaj dane strukturalne przez API
Gdzieś przy trzecim przebudowywaniu systemu health-checków proxy dla projektu, który tak naprawdę potrzebował tylko cen produktów do arkusza, dotarło do mnie coś ważnego: większość tej infrastruktury powstaje po to, żeby rozwiązać problem — pobranie surowego HTML ze strony — który wcale nie jest prawdziwym celem dewelopera. Celem są dane strukturalne. HTML to tylko niewygodny format pośredni.
Open API Thunderbit traktuje ekstrakcję jako główną operację, a nie efekt uboczny automatyzacji przeglądarki. POST /extract przyjmuje URL i schemat JSON, a następnie zwraca dopasowane dane strukturalne — obsługując renderowanie JS, mechanizmy antybotowe i CAPTCHA po stronie backendu, zamiast zostawiać Cię sam na sam ze stealth pluginami i pulami proxy:
curl -X POST https://openapi.thunderbit.com/openapi/v1/extract \
-H "Authorization: Bearer $THUNDERBIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product",
"schema": {
"type": "object",
"properties": {
"name": {"type": "string"},
"price": {"type": "number"}
},
"required": ["name", "price"]
}
}'
Jest też endpoint POST /distill dla przypadków, w których potrzebujesz po prostu czystego Markdown zamiast ścisłego schematu, a także obsługa ekstrakcji wsadowej, żeby uruchomić ten sam schemat na wielu URL-ach jednym wywołaniem. Według aktualnego cennika API Thunderbit Distill zużywa 1 jednostkę na stronę, a Extract 20 jednostek na stronę — darmowy plan obejmuje 600 jednostek jednorazowych, co wystarczy do przetestowania przepływu przed podjęciem decyzji.
Dla deweloperów pracujących w Claude, Cursorze albo innym kliencie zgodnym z MCP Thunderbit udostępnia też narzędzia MCP thunderbit_extract i thunderbit_distill, dzięki którym agent może w trakcie zadania sam zdecydować, że musi pobrać dane ze strony, zamiast wymagać osobnego kroku scrapingu. Warto sprawdzić aktualną dokumentację API przed konfiguracją MCP, bo nazwy narzędzi i parametry mogą się zmieniać między wersjami dokumentacji.
| Wymiar | Puppeteer + rotujące proxy | API Thunderbit |
|---|---|---|
| Złożoność konfiguracji | Wysoka — pula proxy, logika rotacji, stealth, retry | Niska — pojedyncze wywołanie API ze schematem JSON |
| Obsługa antybota | Ręczna | Wbudowana |
| Wynik | Surowy HTML (wymaga parsowania) | Ustrukturyzowany JSON zgodny ze schematem |
| Utrzymanie | Wysokie — selektory się psują, proxy się zużywają | Niskie |
| Najlepsze do | Automatyzacji niestandardowej, flow logowania, niszowych interakcji | Ekstrakcji danych na dużą skalę |
Żeby oddać sprawiedliwość podejściu DIY: jeśli Twój przypadek użycia obejmuje logowanie do konta, przechodzenie przez wieloetapowy proces albo cokolwiek, co wymaga utrzymania stanu w sesji, API do ekstrakcji zwykle tego nie zastąpi — FAQ Thunderbit wprost mówi, że interaktywne flow logowania nie są obecnie wspierane przez API. W takich sytuacjach Puppeteer z proxy nadal wygrywa. Ale jeśli zadanie brzmi „pobierz dane z wielu publicznych stron do schematu, który sam zdefiniuję”, budowanie własnego stosu rotacji proxy rozwiązuje trudniejszy problem, niż faktycznie masz. Dla zespołów, które wolą nie pisać kodu, rozszerzenie Thunderbit do Chrome oferuje tę samą ekstrakcję opartą na AI w interfejsie typu point-and-click — warto je rozważyć, jeśli porównujesz no-code web scraping z pełnym setupem deweloperskim.
Podsumowanie i najważniejsze wnioski
Rotujące proxy w Puppeteer to nie jedna technika. Rotacja na poziomie przeglądarki jest prosta i izolowana. Uwierzytelniany gateway backconnect może rotować wyjścia za jednym endpointem na poziomie całej przeglądarki. Bardziej precyzyjny routing per request albo współbieżne tożsamości wymagają shardowania przeglądarki lub zewnętrznego relay; samo request interception nie zmienia trasy sieciowej Chrome.
To wszystko i tak niewiele da bez reszty stosu. Proxy rozwiązują problem reputacji IP; stealth pluginy i spójność fingerprintu rozwiązują problem sygnałów przeglądarki; jitter i kontrola tempa rozwiązują problem zachowania. Pomijając którąkolwiek warstwę, nadal możesz zostać zablokowany — tylko z innego powodu.
Jeśli budujesz to sam, zacznij od repozytorium proxy-chain i fragmentów kodu powyżej — zaprowadzą Cię dalej niż większość płatnych kursów. Jeśli wolisz całkiem pominąć zarządzanie proxy i po prostu dostać dane strukturalne, dokumentacja API Thunderbit jest warta dziesięciu minut przed tym, jak utopisz weekend w budowie infrastruktury health-checków, którą i tak będziesz utrzymywać przez lata. Oba podejścia są sensowne — ważne tylko, żeby rozwiązywały Twój faktyczny problem, a nie ten, który zakłada każdy poradnik. Jeśli chcesz szerzej spojrzeć na to, jak AI zmienia ten obszar, sprawdź też nasz materiał o AI web scraping i porównanie z tradycyjnymi metodami.
FAQ
Jak często powinienem rotować proxy w Puppeteer?
To zależy od tego, jak agresywne są limity po stronie celu. W witrynach z mocnym wykrywaniem botów rotuj przy każdej stronie albo przy każdej sesji. W bardziej liberalnych serwisach może wystarczyć rotacja sesji, a nawet jedno stałe IP na cały przebieg scrapingu. Nie ma uniwersalnej liczby — traktuj 403, 429 i timeouty jako sygnał, że trzeba rotować częściej, a nie jako z góry ustalony próg żądań.
Czy mogę używać darmowych proxy do scrapingu w Puppeteer?
Technicznie tak, ale nie polecałbym tego do niczego poza szybkim testem. Darmowe listy proxy są zwykle wolne, niestabilne i często już zablokowane przez serwisy, które chcesz scrapować. W zastosowaniach produkcyjnych residential proxy od płatnego dostawcy albo zarządzany gateway są warte swojej ceny.
Czy puppeteer-extra-plugin-stealth działa przeciwko wszystkim systemom antybotowym?
Nie — i dokumentacja samej wtyczki mówi to wprost. Zmniejsza część typowych sygnałów headless Chrome, ale cel nadal może analizować reputację sieci, cechy TLS, ciasteczka, client hints i zachowanie. Traktuj plugin jako jedną z warstw kompatybilności, a nie gwarancję.
Jaka jest różnica między proxy-chain a --proxy-server w Puppeteer?
--proxy-server to natywna flaga uruchamiania Chromium, która przypisuje jeden endpoint proxy do całej instancji przeglądarki, a Chrome nie akceptuje tam osadzonych danych uwierzytelniających. proxy-chain tworzy lokalny anonimowy tunel do uwierzytelnionego upstreamu. Rotacja pochodzi wtedy z ponownego uruchamiania z innym upstreamem, z gatewaya backconnect zarządzanego przez dostawcę albo z osobno zaprojektowanego relay — nie z tego, że proxy-chain przypisuje proxy do pojedynczych stron Puppeteer.
Czy rotujące proxy wystarczy, żeby całkowicie uniknąć blokady?
Nie — i to najczęstsze błędne założenie. Nowoczesne systemy antybotowe, takie jak Cloudflare bot management, łączą reputację IP z fingerprintem przeglądarki, wzorcami zachowań i historią sesji. Proxy rozwiązują tylko część związaną z reputacją IP; nadal potrzebujesz konfiguracji stealth, spójnych fingerprintów i realistycznego tempa, żeby nie zostać oznaczonym przez inne sygnały.
Dowiedz się więcej
