Autoryzacja Playwright SOCKS5 Proxy: Dlaczego Zawodzi, 4 Rozwiązania

Playwright akceptuje serwer socks5://, a następnie odrzuca twoją nazwę użytkownika i hasło. Ograniczenie leży po stronie Chromium, nie Playwright, i jest otwarte od 2021 roku — oto cztery sposoby na obejście tego, uszeregowane.

Autoryzacja Playwright SOCKS5 proxy nie istnieje, a wiedza o tym z góry oszczędza wieczór. Przekaż serwer socks5:// razem z nazwą użytkownika i hasłem, a Playwright odrzuci zanim przeglądarka w ogóle się połączy. Żądanie funkcji, na które wszyscy trafiają, microsoft/playwright#10567, zostało otwarte w listopadzie 2021 roku, nadal jest otwarte i nadal nosi etykietę P3-collecting-feedback. Ograniczenie nie jest do naprawienia przez Playwright: leży w Chromium. Ten post pokazuje dokładne ciągi błędów, wyjaśnia, dlaczego żadne rozszerzenie ani flaga konfiguracyjna cię nie uratuje, i daje cztery rozwiązania — jednowierszową zamianę HTTP, białą listę IP, lokalny przekaźnik i Firefox.

Błąd, którego szukasz

Każda wersja tego problemu generuje jeden z dwóch ciągów. W Node otrzymujesz Error: Browser does not support socks5 proxy authentication; w Pythonie, starsze wydania poprzedzają to playwright._impl._api_types.Error:, a nowsze playwright._impl._errors.Error:. Wiadomość jest taka sama i jest wyrzucana przy uruchomieniu, nie przy nawigacji:

const { chromium } = require('playwright');

// Fails immediately — no page is ever created
const browser = await chromium.launch({
  proxy: {
    server: 'socks5://gate.quantumproxies.io:PORT',
    username: 'USER',
    password: 'PASS',
  },
});
// Error: Browser does not support socks5 proxy authentication

// Python raises the same thing:
// playwright._impl._errors.Error: Browser does not support
// socks5 proxy authentication

Istnieje cichsza wersja. Jeśli pominiesz pola poświadczeń i umieścisz je w ciągu serwera — socks5://USER:PASS@host:1080 — nic się nie dzieje. Chromium po prostu ignoruje część userinfo w URL, próbuje nieautoryzowanego uścisku dłoni, a brama go odrzuca. Następnie widzisz net::ERR_SOCKS_CONNECTION_FAILED lub zwykły timeout przy pierwszym goto(), co prowadzi ludzi do poszukiwania błędów sieciowych, których tam nie ma.

Gdzie autoryzacja Playwright SOCKS5 proxy faktycznie się łamie

Dokumentacja Playwright jest jasna: pola username i password w opcji proxy są opisane jako poświadczenia do użycia "jeśli HTTP proxy wymaga autoryzacji". SOCKS jest obsługiwany tylko jako schemat. Pod spodem, Chromium nigdy nie zaimplementowało sub-negocjacji nazwy użytkownika/hasła z RFC 1929 dla SOCKS5, co jest powodem, dla którego wpis w trackerze Chromium na temat autoryzacji SOCKS5 (40323993) zebrał lata komentarzy, dlaczego rozszerzenie SwitchyOmega ostrzega użytkowników w momencie, gdy wybierają SOCKS5 z poświadczeniami, i dlaczego Brave i Edge zachowują się identycznie. To jeden silnik, jedna luka, odziedziczona przez wszystko, co na nim zbudowane.

To także powód, dla którego trik, który ratuje użytkowników Selenium, tutaj nie pomaga. Rozszerzenie Manifest V3 może odpowiedzieć na wyzwanie proxy przez chrome.webRequest.onAuthRequired, ale ten hook uruchamia się na odpowiedziach HTTP 407 Proxy Authentication Required. Uścisk dłoni SOCKS5 to negocjacja na poziomie bajtów na gnieździe przed jakimkolwiek HTTP, więc nie ma zdarzenia do przechwycenia. I nie myl opcji kontekstu httpCredentials z autoryzacją proxy: odpowiada ona na wyzwania 401 z odwiedzanej strony, nigdy z proxy. Dla pełnego obrazu w ramach stealth, nasza mapa autoryzowanych proxy w ramach anti-detect pokazuje, kto co obsługuje.

Rozwiązanie 1: użyj punktu końcowego HTTP tego samego gatewaya

To rozwiązanie dla około dziewięciu użytkowników na dziesięciu i to jest jedna linia. Poważni dostawcy udostępniają tę samą pulę IP w obu protokołach na różnych portach — każdy plan QuantumProxies dostarcza punkty końcowe HTTP i SOCKS5 z tymi samymi poświadczeniami i tą samą składnią sesji. Zmień schemat i port, zachowaj resztę, a natywne pola poświadczeń Playwright wykonają swoją pracę:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(proxy={
        # was: "socks5://gate.quantumproxies.io:SOCKS_PORT"
        "server": "http://gate.quantumproxies.io:PORT",
        "username": "USER",
        "password": "PASS",
    })
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.text_content("body"))   # must be the proxy exit IP
    browser.close()

Nie tracisz nic mierzalnego. Dla ruchu przeglądarki proxy HTTP otwiera tunel CONNECT i przenosi te same zaszyfrowane bajty, co tunel SOCKS5; różnice między tymi dwoma protokołami mają znaczenie dla ruchu UDP i nie-HTTP, nie dla ładowania strony. Nasze omówienie różnic między SOCKS5 a HTTP proxy zawiera szczegóły. A ponieważ obiekt proxy jest również akceptowany przez newContext(), te same poświadczenia dają ci rotację per-kontekst dokładnie tak, jak opisano w naszym przewodniku integracji proxy Playwright.

Rozwiązanie 2: biała lista IP utrzymuje socks5:// przy życiu

Jeśli naprawdę potrzebujesz schematu SOCKS5 — proxy, które mówi tylko SOCKS, łańcuch narzędzi, który to zakłada — uwierzytelnij maszynę zamiast żądania. Zarejestruj publiczny IP scraper'a u swojego dostawcy, usuń poświadczenia, a Chromium będzie zadowolone, ponieważ nie ma nic do negocjacji:

const { chromium } = require('playwright');

const browser = await chromium.launch({
  proxy: { server: 'socks5://gate.quantumproxies.io:PORT' }, // no creds
});
const page = await browser.newPage();
await page.goto('https://httpbin.org/ip');
console.log(await page.textContent('body'));
await browser.close();

Biała lista uwierzytelnia maszynę, nie skrypt, i to jest cały kompromis. VPS lub wyjście biurowe ze stabilnym adresem działa idealnie; efemeryczne biegacze CI, autoskalowane kontenery i cokolwiek za rotującym NAT zawiedzie w momencie zmiany adresu. Zweryfikuj wyjście zanim zaufasz uruchomieniu — ciche bezpośrednie połączenie wygląda dokładnie jak działające proxy, dopóki twój cel nie zacznie blokować twojego własnego IP. Nasz darmowy sprawdzacz jakości IP mówi ci, co faktycznie jest wyjściem, nie tylko, że odpowiedziało.

Porównanie czterech rozwiązań dla autoryzacji Playwright SOCKS5 proxy: punkt końcowy HTTP, biała lista IP, lokalny przekaźnik i Firefox — Zamiana punktu końcowego HTTP kosztuje jedną linię i żadnej funkcjonalności. Wszystko po prawej stronie kupuje ci schemat socks5:// za cenę.

Rozwiązanie 3: lokalny przekaźnik, który usuwa poświadczenia

Kiedy IP nie może być na białej liście, a dostawca nie ma portu HTTP, umieść tłumacza przed przeglądarką. Wzorzec jest zawsze ten sam: lokalny słuchacz bez autoryzacji przekazuje do górnego punktu końcowego SOCKS5 z dołączonymi poświadczeniami. Z gost, to jedno polecenie:

# Local no-auth HTTP listener -> authenticated upstream SOCKS5
gost -L=http://127.0.0.1:8080 \
     -F=socks5://USER:PASS@gate.quantumproxies.io:PORT

# Playwright then points at the local hop, with no credentials:
#   proxy: { server: 'http://127.0.0.1:8080' }

Dwie zasady. Zwiąż słuchacza z 127.0.0.1, nigdy z 0.0.0.0 — proxy bez autoryzacji dostępne z internetu to otwarty przekaźnik, który zostanie znaleziony i nadużyty w ciągu kilku godzin. I traktuj przekaźnik jako proces, który musisz nadzorować: jeśli umrze, Chromium wraca do błędu połączenia zamiast bezpośredniego żądania, co jest przynajmniej głośne. To podejście stało się na tyle powszechne, że praktycy publikują małe przekaźniki zbudowane do tego celu; porównujemy opcje w naszym przewodniku po narzędziach przekaźnikowych SOCKS5 auth.

Rozwiązanie 4: uruchom Firefox zamiast Chromium

Firefox implementuje autoryzację SOCKS5 z nazwą użytkownika/hasłem natywnie, co jest różnicą, na którą wątek problemu Playwright ciągle wskazuje. Zmień typ przeglądarki, a błąd zniknie:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.firefox.launch(proxy={
        "server": "socks5://gate.quantumproxies.io:PORT",
        "username": "USER",
        "password": "PASS",
    })
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.text_content("body"))   # confirm the exit before trusting it
    browser.close()

Zrób krok weryfikacji, za każdym razem. To, że Playwright nie wyrzuca błędu, nie jest dowodem, że poświadczenia zostały użyte — tylko echo IP jest. I bądź jasny, co kupujesz: inny silnik renderujący, inną powierzchnię odcisków palców i ekosystem stealth, który mocno skłania się ku Chromium. Jeśli twój cel już akceptuje Firefox, to jest za darmo. Jeśli wybrałeś Chromium z powodów anty-botowych, zmiana silników, aby rozwiązać problem proxy, to zła wymiana — weź rozwiązanie 1 i zachowaj swoją przeglądarkę.

Decyzja, w jednej linii każda

Dostawca ma port HTTP: użyj go. Jedna linia, natywna autoryzacja, te same wyjścia, bez dodatkowego procesu.
Stały publiczny IP: umieść na białej liście i zachowaj socks5:// bez poświadczeń.
Żadne: uruchom lokalny przekaźnik związany z pętlą zwrotną i skieruj Playwright na 127.0.0.1.
Już na Firefox: przekaż poświadczenia i zweryfikuj wyjściowy IP raz.
Nigdy: poświadczenia wewnątrz ciągu server. Chromium odrzuca je bez słowa.

Lista kontrolna konfiguracji Playwright SOCKS5 proxy, które działają w Chromium versus konfiguracje, które wyrzucają błędy lub zawodzą cicho — Chromium akceptuje schemat SOCKS5 i nigdy poświadczenia. Wszystko po prawej stronie tej listy zawodzi — połowa bez błędu.

Często zadawane pytania

Czy Playwright obsługuje autoryzację SOCKS5 proxy?

Nie z Chromium. Opcja proxy Playwright dokumentuje nazwę użytkownika i hasło jako poświadczenia HTTP(S), a Chromium nie ma implementacji nazwy użytkownika/hasła SOCKS5, do której można je przekazać, więc uruchomienie wyrzuca błąd. Firefox w Playwright to obsługuje. Problem śledzenia, microsoft/playwright#10567, jest otwarty od listopada 2021 roku bez zaplanowanej poprawki.

Co oznacza 'Browser does not support socks5 proxy authentication'?

Oznacza to, że przekazałeś poświadczenia razem z serwerem socks5:// do uruchomienia Chromium. Playwright weryfikuje kombinację i odrzuca zamiast otwierać przeglądarkę, która by je cicho zignorowała. Przejdź do portu HTTP gatewaya i zachowaj pola poświadczeń lub uwierzytelnij przez białą listę IP i całkowicie je usuń.

Jak używać proxy SOCKS5 z Playwright w Pythonie?

Przekaż proxy={"server": "socks5://host:port"} bez nazwy użytkownika i hasła, a dostawca autoryzuje publiczny IP twojej maszyny. Jeśli IP nie jest stabilne, użyj punktu końcowego HTTP tego samego gatewaya z poświadczeniami lub przekieruj przez lokalny przekaźnik. Zawsze potwierdzaj wyjście na podstawie punktu końcowego echo IP.

Czy rozszerzenie Chrome może dodać autoryzację SOCKS5?

Nie. Trik z rozszerzeniem używany dla autoryzowanych proxy HTTP opiera się na chrome.webRequest.onAuthRequired, który uruchamia się na odpowiedziach HTTP 407. SOCKS5 autoryzuje podczas uścisku dłoni na gnieździe, zanim istnieje jakiekolwiek żądanie HTTP, więc żadne API rozszerzenia nie może tego zobaczyć. Rozszerzenia przełączników proxy ostrzegają o tym ograniczeniu z tego samego powodu.

Czy SOCKS5 jest szybszy niż HTTP dla skrobania Playwright?

Nie w sposób znaczący. Ruch HTTPS przez proxy HTTP używa tunelu CONNECT, więc oba protokoły przenoszą ten sam zaszyfrowany strumień z porównywalnym narzutem. Prawdziwe zalety SOCKS5 to wsparcie UDP i neutralność protokołu, z których żadne nie jest używane przy ładowaniu strony przeglądarki. Wybierz dowolny punkt końcowy, który autoryzuje się czysto.

Krótka wersja: przestań próbować zmusić Chromium do zrobienia czegoś, czego nigdy nie robiło. Przenieś zadanie na punkt końcowy HTTP lub umieść na białej liście i usuń poświadczenia — a jeśli musisz zachować socks5:// z rotującym wyjściem, umieść przekaźnik w środku zamiast obejścia w swoim kodzie. Gdy autoryzacja jest poza drogą, to, co decyduje, czy uruchomienie się powiedzie, to pula za nim: wyjścia rezydencjalne w ponad 200 krajach, z rotacją na żądanie lub lepkimi sesjami, gdy przepływ wymaga jednej tożsamości.

Uzyskaj punkty końcowe HTTP i SOCKS5 w jednym planie