StableProxy
© StableProxy – 2021 - 2026 – Ukraine

StableProxy
© StableProxy – 2021 - 2026 – Ukraine


Jak skonfigurować proxy w Playwright i Puppeteer. Przykłady kodu, autoryzacja proxy, SOCKS5, rotacja IP oraz ochrona przed wyciekami danych.
Proxychi
Automatyzacja działań w przeglądarkach internetowych za pomocą Playwright lub Puppeteer bez odpowiedniej infrastruktury proxy szybko napotyka rygorystyczne ograniczenia systemów antyfraudowych i antybotowych. Nowoczesne systemy ochrony, takie jak Cloudflare, Akamai i DataDome, analizują nie tylko fingerprint przeglądarki, ale również reputację adresu IP, z którego pochodzą żądania. Bez prawidłowej konfiguracji warstwy sieciowej niemal każdy skrypt headless może zostać wykryty już po kilku iteracjach, co prowadzi do częstego wyświetlania CAPTCHA lub całkowitego zablokowania dostępu.
Prawidłowa integracja proxy z Puppeteer lub Playwright pozwala rozdzielać ruch, utrzymywać sesje oraz symulować użytkowników łączących się z różnych lokalizacji geograficznych. W tym poradniku omówimy praktyczne konfiguracje proxy oraz metody uwierzytelniania dla obu frameworków.
W Puppeteer konfiguracja proxy sieciowego odbywa się podczas uruchamiania instancji Chromium poprzez przekazanie odpowiednich argumentów wiersza poleceń.
Do konfiguracji proxy służy parametr --proxy-server. Podstawowa składnia wygląda następująco:
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({
headless: true,
args: ['--proxy-server=http://185.130.5.15:8080']
});
const page = await browser.newPage();
await page.goto('https://httpbin.org/ip');
await browser.close();
})();
Chromium nie obsługuje przekazywania danych uwierzytelniających w formacie http://user:pass@ip:port bezpośrednio przez argument --proxy-server. W Puppeteer można w tym celu wykorzystać metodę page.authenticate():
const browser = await puppeteer.launch({
headless: true,
args: ['--proxy-server=http://185.130.5.15:8080']
});
const page = await browser.newPage();
// Uwierzytelnianie proxy za pomocą loginu i hasła
await page.authenticate({
username: 'proxy_user',
password: 'proxy_password'
});
await page.goto('https://httpbin.org/ip');
W przypadku proxy SOCKS5 należy użyć odpowiedniego prefiksu protokołu w argumentach uruchomieniowych:
--proxy-server=socks5://185.130.5.15:1080
Jeżeli proxy SOCKS5 wymaga uwierzytelniania, metoda page.authenticate() może działać niestabilnie w niektórych wersjach Chromium. W takich przypadkach można zastosować dodatkowe wtyczki lub przekierować połączenie przez lokalny tunel.
Playwright oferuje bardziej elastyczną architekturę obsługi protokołów sieciowych. W przeciwieństwie do Puppeteer, gdzie proxy jest zazwyczaj konfigurowane na poziomie całego procesu przeglądarki, Playwright pozwala definiować konfigurację proxy zarówno dla całej przeglądarki, jak i dla poszczególnych, odizolowanych kontekstów przeglądarki (BrowserContext).
Obiekt proxy można przekazać bezpośrednio do launch lub newContext, a dane uwierzytelniające określić w ramach tej samej struktury konfiguracyjnej:
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch({
proxy: {
server: 'http://185.130.5.15:8080',
username: 'proxy_user',
password: 'proxy_password'
}
});
// Każdy kontekst może mieć własny, odizolowany stan przeglądarki
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://httpbin.org/ip');
await browser.close();
})();
Playwright natywnie obsługuje uwierzytelniane proxy SOCKS5. Wystarczy określić prefiks protokołu socks5:// w parametrze server:
const context = await browser.newContext({
proxy: {
server: 'socks5://185.130.5.15:1080',
username: 'proxy_user',
password: 'proxy_password'
}
});
Przy automatyzacji ruchu przeglądarkowego wybór odpowiedniej strategii rotacji proxy zależy od konkretnego zastosowania:
Korzystanie z proxy nie gwarantuje automatycznie anonimowości. Sama przeglądarka może nadal ujawniać informacje o rzeczywistym połączeniu za pomocą mechanizmów takich jak WebRTC lub określonych nagłówków przeglądarki.
Domyślnie WebRTC może wykonywać zapytania STUN ścieżkami sieciowymi, które omijają serwer proxy, potencjalnie ujawniając rzeczywisty adres IP urządzenia.
Aby ograniczyć ryzyko wycieku IP w Puppeteer, można wykorzystać rozwiązania do maskowania fingerprintu, takie jak puppeteer-extra-plugin-stealth, a także wyłączyć funkcje związane z WebRTC za pomocą argumentów uruchomieniowych Chromium:
const puppeteer = require('puppeteer-extra');
const StealthPlugin = require('puppeteer-extra-plugin-stealth');
puppeteer.use(StealthPlugin());
const browser = await puppeteer.launch({
args: [
'--proxy-server=http://185.130.5.15:8080',
'--disable-webrtc',
'--enforce-webrtc-ip-permission-check'
]
});
W przypadku automatyzacji w środowiskach wykorzystujących rygorystyczne systemy antybotowe kluczowe znaczenie ma jakość infrastruktury proxy. StableProxy oferuje proxy rezydencjalne i ISP z obsługą HTTP/HTTPS oraz SOCKS5, zaprojektowane w celu ograniczenia wycieków danych i zapewnienia dobrej reputacji adresów IP w chronionych środowiskach.
| Parametr konfiguracji | Puppeteer | Playwright |
|---|---|---|
| Poziom konfiguracji proxy | Globalnie podczas uruchamiania procesu przeglądarki | Na poziomie przeglądarki lub pojedynczego BrowserContext |
| Uwierzytelnianie | Za pomocą osobnej metody page.authenticate() |
Bezpośrednio w obiekcie konfiguracyjnym proxy |
| SOCKS5 z uwierzytelnianiem | Może wymagać dodatkowych rozwiązań lub wtyczek | Obsługiwane natywnie |
| Izolacja IP między kartami/kontekstami | Bardziej złożona; może wymagać oddzielnych procesów | Prosta dzięki oddzielnym instancjom BrowserContext |
Chcesz widzieć nasze nowe artykuły w Google? Dodaj StableProxy do preferowanych źródeł.
Metoda page.authenticate() w Puppeteer obsługuje uwierzytelnianie HTTP na poziomie konkretnej strony. Żądania wykonywane w tle, service workery oraz żądania sieciowe inicjowane przed pełnym załadowaniem dokumentu mogą zostać wysłane zanim mechanizm uwierzytelniania zostanie zastosowany. Jednym z rozwiązań jest wykorzystanie proxy skonfigurowanego z listą dozwolonych adresów IP (IP Whitelisting) lub zastosowanie przechwytywania ruchu sieciowego na poziomie CDP (Chrome DevTools Protocol).
Domyślnie Chromium może próbować rozwiązywać nazwy domen za pomocą serwera DNS systemu hosta zamiast korzystać z węzła proxy. Aby skierować rozwiązywanie DNS przez proxy SOCKS5, dodaj do argumentów uruchomieniowych Chromium następującą opcję: --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 127.0.0.1" Alternatywnie można użyć prefiksu socks5h:// zamiast socks5://. Litera h wskazuje, że rozwiązywanie DNS powinno zostać przekazane do serwera proxy.
Zmiana adresu IP rozwiązuje tylko jeden z problemów związanych z reputacją na poziomie sieci. Cloudflare i inne systemy antybotowe mogą również analizować fingerprint TLS, takie jak JA3/JA4, fingerprinting JavaScript, Canvas, WebGL, AudioContext oraz sygnały takie jak właściwość navigator.webdriver. Jeżeli handshake TLS lub środowisko przeglądarki ujawnia charakterystyczny fingerprint Node.js albo standardowego Headless Chromium, żądanie może zostać odrzucone niezależnie od reputacji adresu IP proxy.
Tak. Ponieważ Playwright obsługuje konfigurację proxy na poziomie BrowserContext, można tworzyć nowe konteksty przeglądarki z różnymi konfiguracjami proxy, zachowując jednocześnie uruchomioną tę samą instancję przeglądarki.
Jednym z najprostszych sposobów automatycznej weryfikacji jest zainicjowanie proxy, a następnie przejście do specjalnego endpointu wykrywającego adres IP, takiego jak https://api.ipify.org?format=json, lub do strony przeznaczonej do testowania wycieków WebRTC. Następnie można odczytać zawartość strony za pomocą page.content(). Alternatywnym rozwiązaniem jest wykonanie kodu JavaScript wewnątrz kontekstu przeglądarki za pomocą page.evaluate(). Skrypt może utworzyć obiekt RTCPeerConnection, zebrać kandydatów ICE i sprawdzić, czy którykolwiek z nich ujawnia rzeczywisty lokalny lub publiczny adres IP urządzenia.
StableProxy
© StableProxy – 2021 - 2026 – Ukraine
