Playwright SOCKS5 프록시 인증: 실패 원인과 4가지 해결책

Playwright는 socks5:// 서버를 받아들이고 나서 사용자 이름과 비밀번호를 거부합니다. 이 제한은 Playwright가 아닌 Chromium의 문제이며, 2021년부터 열려 있습니다. 이를 해결할 네 가지 방법을 순위별로 소개합니다.

Playwright SOCKS5 프록시 인증은 존재하지 않으며, 이를 미리 알면 저녁 시간을 절약할 수 있습니다. socks5:// 서버와 함께 사용자 이름과 비밀번호를 전달하면 Playwright는 브라우저가 탐색하기 전에 거부합니다. 모든 사람들이 도착하는 기능 요청 microsoft/playwright#10567은 2021년 11월에 열렸고, 여전히 열려 있으며 P3-collecting-feedback 레이블을 유지하고 있습니다. 이 제한은 Playwright가 해결할 수 있는 것이 아닙니다: 이는 Chromium에 존재합니다. 이 게시물은 정확한 오류 문자열을 보여주고, 왜 확장이나 구성 플래그가 당신을 구할 수 없는지 설명하며, 네 가지 해결책을 제공합니다 — 한 줄의 HTTP 전환, IP 화이트리스트, 로컬 릴레이, 그리고 Firefox.

당신이 찾고 있는 오류

이 문제의 모든 버전은 두 가지 문자열 중 하나를 생성합니다. Node에서는 Error: Browser does not support socks5 proxy authentication를 얻고, Python에서는 이전 릴리스는 playwright._impl._api_types.Error:로, 최신 릴리스는 playwright._impl._errors.Error:로 시작합니다. 메시지는 동일하며, 탐색이 아니라 시작 시 발생합니다:

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

더 조용한 변형이 있습니다. 자격 증명 필드를 제거하고 서버 문자열에 대신 넣으면 — socks5://USER:PASS@host:1080 — 아무 것도 발생하지 않습니다. Chromium은 URL의 사용자 정보 부분을 단순히 무시하고, 인증되지 않은 핸드셰이크를 시도하며, 게이트웨이는 이를 거부합니다. 그러면 첫 번째 goto()에서 net::ERR_SOCKS_CONNECTION_FAILED 또는 일반적인 시간 초과가 발생하여 네트워크 버그를 찾게 됩니다.

Playwright SOCKS5 프록시 인증이 실제로 깨지는 곳

Playwright의 자체 문서는 명확합니다: 프록시 옵션의 username과 password 필드는 "HTTP 프록시가 인증을 요구하는 경우" 사용할 자격 증명으로 설명됩니다. SOCKS는 단지 스킴으로만 지원됩니다. 기본적으로 Chromium은 SOCKS5에 대한 RFC 1929의 사용자 이름/비밀번호 하위 협상을 구현하지 않았기 때문에, SOCKS5 인증에 대한 Chromium 문제 추적기 항목(40323993)이 수년간의 댓글을 수집했으며, SwitchyOmega 확장은 사용자가 자격 증명을 사용하여 SOCKS5를 선택하는 순간 경고하고, Brave와 Edge가 동일하게 작동하는 이유입니다. 이는 하나의 엔진, 하나의 간극이며, 그것을 기반으로 구축된 모든 것에 상속됩니다.

이것이 Selenium 사용자를 구하는 트릭이 여기서는 도움이 되지 않는 이유이기도 합니다. Manifest V3 확장은 chrome.webRequest.onAuthRequired를 통해 프록시 챌린지에 응답할 수 있지만, 그 훅은 HTTP 407 Proxy Authentication Required 응답에서 발생합니다. SOCKS5 핸드셰이크는 HTTP가 존재하기 전에 소켓에서 바이트 수준의 협상이며, 따라서 가로챌 이벤트가 없습니다. 그리고 컨텍스트 옵션 httpCredentials를 프록시 인증과 혼동하지 마십시오: 이는 방문 중인 웹사이트의 401 챌린지에 응답하며, 프록시에는 절대 응답하지 않습니다. 스텔스 프레임워크 전반에 걸친 전체 그림을 위해, 우리의 인증된 프록시의 안티-디텍트 프레임워크 맵은 누가 무엇을 지원하는지 다룹니다.

해결책 1: 동일한 게이트웨이의 HTTP 엔드포인트 사용

이것은 대략 열 명 중 아홉 명에게 해당하는 해결책이며, 한 줄입니다. 신뢰할 수 있는 제공업체는 다른 포트에서 두 프로토콜을 통해 동일한 IP 풀을 노출합니다 — 모든 QuantumProxies 플랜은 동일한 자격 증명과 세션 구문을 가진 HTTP 및 SOCKS5 엔드포인트를 제공합니다. 스킴과 포트를 전환하고, 나머지는 그대로 유지하면 Playwright의 네이티브 자격 증명 필드가 제 역할을 합니다:

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()

측정 가능한 손실은 없습니다. 브라우저 트래픽의 경우 HTTP 프록시는 CONNECT 터널을 열고 SOCKS5 터널이 할 것과 동일한 암호화된 바이트를 전송합니다; 두 프로토콜 간의 차이는 UDP 및 비-HTTP 트래픽에 중요하며, 페이지 로드에는 중요하지 않습니다. 우리의 SOCKS5 대 HTTP 프록시 차이 분석에는 자세한 정보가 있습니다. 그리고 프록시 객체는 newContext()에서도 수락되므로, 동일한 자격 증명으로 문맥별 회전을 제공하여 우리의 Playwright 프록시 통합 가이드에서 설명한 대로 정확히 작동합니다.

해결책 2: IP 화이트리스트로 socks5:// 유지

SOCKS5 스킴이 진정으로 필요하다면 — SOCKS만을 사용하는 프록시, 그것을 가정하는 도구 체인 — 요청 대신 머신을 인증하십시오. 스크래퍼의 공용 IP를 제공업체에 등록하고 자격 증명을 제거하면, 협상할 것이 없기 때문에 Chromium은 만족합니다:

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();

화이트리스트는 스크립트가 아닌 머신을 인증하며, 이것이 전체 거래입니다. 안정적인 주소를 가진 VPS나 사무실 출구는 완벽하게 작동합니다; 일시적인 CI 러너, 자동 확장 컨테이너 및 회전하는 NAT 뒤의 모든 것은 주소가 변경되는 순간 실패할 것입니다. 실행을 신뢰하기 전에 출구를 확인하십시오 — 조용히 직접 연결은 타겟이 자신의 IP를 차단하기 시작할 때까지 작동하는 프록시처럼 보입니다. 우리의 무료 IP 품질 검사기는 응답했는지 여부가 아니라 실제로 무엇인지 알려줍니다.

Playwright SOCKS5 프록시 인증을 위한 네 가지 해결책 비교: HTTP 엔드포인트, IP 화이트리스트, 로컬 릴레이 및 Firefox — HTTP 엔드포인트 전환은 한 줄과 아무런 기능 손실이 없습니다. 그 오른쪽의 모든 것은 socks5:// 스킴을 대가로 얻습니다.

해결책 3: 자격 증명을 제거하는 로컬 릴레이

IP를 화이트리스트에 추가할 수 없고 제공업체에 HTTP 포트가 없는 경우, 브라우저 앞에 번역기를 두십시오. 패턴은 항상 동일합니다: 인증 없이 로컬 리스너가 자격 증명이 첨부된 업스트림 SOCKS5 엔드포인트로 전달합니다. gost를 사용하면, 이는 단일 명령입니다:

# 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' }

두 가지 규칙이 있습니다. 리스너를 127.0.0.1에 바인딩하고, 0.0.0.0에 절대 바인딩하지 마십시오 — 인터넷에서 접근 가능한 인증 없는 프록시는 몇 시간 내에 발견되고 악용될 오픈 릴레이입니다. 그리고 릴레이를 감독해야 하는 프로세스로 취급하십시오: 죽으면 Chromium은 직접 요청이 아닌 연결 오류로 돌아가며, 이는 적어도 시끄럽습니다. 이 접근 방식은 충분히 일반화되어 실무자들이 작은 목적에 맞춘 릴레이를 게시하고 있습니다; 우리는 SOCKS5 인증 릴레이 도구에 대한 가이드에서 옵션을 비교합니다.

해결책 4: Chromium 대신 Firefox 실행

Firefox는 SOCKS5 사용자 이름/비밀번호 인증을 네이티브로 구현하며, 이는 Playwright 문제 스레드가 계속 지적하는 차이입니다. 브라우저 유형을 교체하면 오류가 사라집니다:

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()

매번 검증 단계를 수행하십시오. Playwright가 오류를 발생시키지 않는다고 해서 자격 증명이 사용되었다는 증거는 아닙니다 — 오직 IP 에코만이 증거입니다. 그리고 무엇을 구매하고 있는지 명확히 하십시오: 다른 렌더링 엔진, 다른 지문 표면, 그리고 Chromium에 크게 치우친 스텔스 생태계입니다. 타겟이 이미 Firefox를 수용한다면 이는 무료입니다. 반봇 이유로 Chromium을 선택했다면, 프록시 문제를 해결하기 위해 엔진을 교체하는 것은 잘못된 거래입니다 — 해결책 1을 선택하고 브라우저를 유지하십시오.

결정, 각 한 줄로

제공업체에 HTTP 포트가 있는 경우: 사용하십시오. 한 줄, 네이티브 인증, 동일한 출구, 추가 프로세스 없음.
고정 공용 IP: 화이트리스트에 추가하고 socks5://를 자격 증명 없이 유지하십시오.
둘 다 아닌 경우: 로컬 릴레이를 루프백에 바인딩하고 Playwright를 127.0.0.1로 지정하십시오.
이미 Firefox를 사용하는 경우: 자격 증명을 전달하고 출구 IP를 한 번 확인하십시오.
절대 안 되는 경우: server 문자열 내의 자격 증명. Chromium은 아무 말 없이 이를 무시합니다.

Chromium에서 작동하는 Playwright SOCKS5 프록시 구성의 체크리스트 대 오류를 발생시키거나 조용히 실패하는 구성 — Chromium은 SOCKS5 스킴을 수락하며, 자격 증명을 절대 수락하지 않습니다. 이 목록의 오른쪽에 있는 모든 것은 실패합니다 — 그 중 절반은 오류 없이.

자주 묻는 질문

Playwright는 SOCKS5 프록시 인증을 지원합니까?

Chromium에서는 지원하지 않습니다. Playwright의 프록시 옵션은 사용자 이름과 비밀번호를 HTTP(S) 자격 증명으로 문서화하고 있으며, Chromium에는 이를 전달할 SOCKS5 사용자 이름/비밀번호 구현이 없으므로 시작 시 오류가 발생합니다. Playwright의 Firefox는 이를 지원합니다. 추적 문제, microsoft/playwright#10567은 2021년 11월부터 열려 있으며, 수정 일정이 없습니다.

'브라우저가 socks5 프록시 인증을 지원하지 않습니다'는 무슨 뜻입니까?

이는 socks5:// 서버와 함께 자격 증명을 Chromium 시작에 전달했음을 의미합니다. Playwright는 조합을 검증하고, 자격 증명을 조용히 무시할 브라우저를 열기보다는 거부합니다. 게이트웨이의 HTTP 포트로 이동하고 자격 증명 필드를 유지하거나, IP 화이트리스트로 인증하고 이를 완전히 제거하십시오.

Python에서 Playwright로 SOCKS5 프록시를 어떻게 사용합니까?

proxy={"server": "socks5://host:port"}를 사용자 이름이나 비밀번호 없이 전달하고, 제공업체가 머신의 공용 IP를 승인하도록 하십시오. IP가 안정적이지 않다면, 자격 증명을 사용하여 동일한 게이트웨이의 HTTP 엔드포인트를 사용하거나 로컬 릴레이를 통해 전달하십시오. 항상 IP 에코 엔드포인트에 대해 출구를 확인하십시오.

Chrome 확장이 SOCKS5 인증을 추가할 수 있습니까?

아니요. 인증된 HTTP 프록시에 사용되는 확장 트릭은 HTTP 407 응답에서 발생하는 chrome.webRequest.onAuthRequired에 의존합니다. SOCKS5는 HTTP 요청이 존재하기 전에 소켓 핸드셰이크 중에 인증하므로, 확장 API가 이를 볼 수 없습니다. 프록시 스위처 확장은 같은 이유로 이 제한에 대해 경고합니다.

Playwright 스크래핑에 SOCKS5가 HTTP보다 빠릅니까?

의미 있게는 아닙니다. HTTP 프록시를 통한 HTTPS 트래픽은 CONNECT 터널을 사용하므로, 두 프로토콜은 유사한 오버헤드로 동일한 암호화된 스트림을 전송합니다. SOCKS5의 실제 장점은 UDP 지원과 프로토콜 중립성이며, 이는 브라우저 페이지 로드에는 사용되지 않습니다. 인증이 깔끔하게 이루어지는 엔드포인트를 선택하십시오.

짧은 버전: Chromium이 한 번도 하지 않았던 일을 하게 하려는 시도를 멈추십시오. 작업을 HTTP 엔드포인트로 옮기거나, 화이트리스트에 추가하고 자격 증명을 제거하십시오 — 그리고 회전하는 출구와 함께 socks5://를 유지해야 한다면, 코드에 우회로를 두기보다는 중간에 릴레이를 두십시오. 인증이 해결되면, 실행이 성공할지 여부를 결정하는 것은 그 뒤의 풀입니다: 200개 이상의 국가에서의 주거 출구, 요청당 회전 또는 흐름이 하나의 ID를 필요로 할 때의 고정 세션.

한 플랜에서 HTTP 및 SOCKS5 엔드포인트 받기