Zendriver 프록시 인증: 설정 및 해결 방법

Zendriver는 nodriver의 커뮤니티 유지 포크로, 수정이 더 빠르지만 동일한 인증된 프록시 문제를 가지고 있습니다. 여기 전체 프록시 설정, 실제로 다른 점, 그리고 user:pass 작동을 위한 해결 방법이 있습니다.

zendriver 프록시는 nodriver 프록시와 정확히 동일하게 설정됩니다. 이는 좋은 소식이자 문제점입니다. zendriver(cdpdriver/zendriver 프로젝트)는 nodriver의 커뮤니티 유지 포크로, 비동기 우선, 탐지되지 않는 브라우저 자동화 프레임워크로 DevTools Protocol을 통해 Chrome을 직접 구동하며 WebDriver는 사용하지 않습니다. nodriver의 단일 유지 관리자가 외부 수정을 거의 병합하지 않았기 때문에 커뮤니티가 포크하여 버그 수정을 수용하고 기능을 추가하며 GitHub에서 문제를 처리했습니다. 그러나 인증된 프록시는 수정되지 않았습니다. 이 가이드는 전체 프록시 설정, nodriver와 실제로 다른 점, 그리고 user:pass 작동을 위한 해결 방법을 다룹니다.

설치 및 기본 프록시 설정

설치는 한 줄입니다 — pip install zendriver — 그리고 API는 nodriver와 거의 동일하여 스크립트를 포팅할 때 import zendriver as zd가 유일한 변경 사항인 경우가 많습니다. 인증되지 않은 프록시는 browser_args를 통해 진행되며, 요청은 프록시 IP에서 종료됩니다:

import zendriver as zd

async def main():
    browser = await zd.start(
        browser_args=["--proxy-server=gate.quantumproxies.io:PORT"],
    )
    page = await browser.get("https://httpbin.org/ip")
    print(await page.get_content())   # shows the proxy exit IP
    await browser.stop()

zd.loop().run_until_complete(main())

이는 단지 Chrome 플래그이기 때문에 작동합니다. 자격 증명을 추가하면 — --proxy-server=http://USER:PASS@host:port — Chromium은 USER:PASS@ 부분을 조용히 버리고, 프록시는 407을 응답하며, zendriver가 채울 수 없는 네이티브 로그인 대화 상자가 나타납니다. 이는 Chrome의 제한 사항이지 zendriver의 버그가 아니므로 플래그가 비밀번호를 수용하도록 버전이 올라가지 않습니다.

zendriver 프록시 인증 문제

이 문제는 zendriver의 이슈에서 공개적으로 추적됩니다 — 기능 요청 스레드(#10)와 전용 "Proxy with auth" 이슈(#208) — 이는 주목할 만한 차이점입니다: nodriver에서는 동일한 질문이 유지 관리자가 한 번 답변하고 넘어간 토론에 묻혀 있습니다. 이슈 #10의 한 사용자는 상황을 간단히 요약합니다: 프록시 서버 옵션에는 인증 방법이 없으므로 프록시 확장을 사용하며 잘 작동합니다. 이는 현장에서 테스트된 합의이며, nodriver 사용자가 의존하는 동일한 세 가지 수정 방법을 직접 가리킵니다.

수정 1: IP 화이트리스트(가장 간단함)

작업이 안정적인 공용 IP를 가진 기계에서 실행되는 경우 자격 증명을 완전히 생략하십시오. 제공자 대시보드에 출구 IP를 등록하면 게이트웨이가 소스 주소로 인증합니다 — zendriver 코드는 위의 --proxy-server 스니펫 그대로 유지되며 인증 로직은 전혀 없습니다. 모든 QuantumProxies 플랜은 user:pass와 함께 IP 화이트리스트를 지원하므로 IP가 고정되어 있을 때 기본 권장 사항입니다. 하나의 제한 사항은 기계를 인증한다는 것이지 스크립트를 인증하는 것이 아니므로 NAT 뒤의 임시 실행기와 컨테이너는 다음 두 가지 방법 중 하나를 필요로 합니다.

수정 2: CDP를 통해 도전 과제에 응답

zendriver는 nodriver와 동일한 방식으로 DevTools Protocol을 노출하므로 프로세스 내에서 인증 도전을 가로챌 수 있습니다: RequestPaused 및 AuthRequired 핸들러를 등록한 다음 handle_auth_requests=True로 Fetch 도메인을 활성화하고 continue_with_auth로 응답합니다. 두 가지 명확하지 않은 규칙은 nodriver와 동일합니다 — 도메인을 활성화하기 전에 핸들러를 추가하고, asyncio.create_task로 응답을 발사하여 대기할 때 루프가 교착 상태에 빠지지 않도록 합니다:

import asyncio
import zendriver as zd

async def main():
    browser = await zd.start(browser_args=["--proxy-server=gate.quantumproxies.io:PORT"])
    tab = await browser.get("draft:,")            # blank tab first

    async def on_auth(event):
        asyncio.create_task(tab.send(zd.cdp.fetch.continue_with_auth(
            request_id=event.request_id,
            auth_challenge_response=zd.cdp.fetch.AuthChallengeResponse(
                response="ProvideCredentials", username="USER", password="PASS",
            ),
        )))

    async def on_request(event):
        asyncio.create_task(tab.send(
            zd.cdp.fetch.continue_request(request_id=event.request_id)))

    # handlers FIRST, then enable the domain
    tab.add_handler(zd.cdp.fetch.RequestPaused, on_request)
    tab.add_handler(zd.cdp.fetch.AuthRequired, on_auth)
    await tab.send(zd.cdp.fetch.enable(handle_auth_requests=True))

    page = await browser.get("https://httpbin.org/ip")
    await asyncio.sleep(3)
    print(await page.get_content())
    await browser.stop()

zd.loop().run_until_complete(main())

핸들러 순서가 중요한 이유와 잘못되었을 때 발생하는 상황에 대한 전체 설명은 nodriver 프록시 인증 가이드에 있습니다 — 메커니즘이 공유되므로 두 번 재현할 이유가 없습니다.

수정 3: 프록시 인증 확장 및 SOCKS5

이슈 #10이 권장하는 경로는 생성된 Chrome 확장입니다: 프록시를 설정하고 chrome.webRequest.onAuthRequired에 응답하는 Manifest V3 매니페스트와 워커, --headless=new 아래 --load-extension로 로드됩니다. 이는 SOCKS5를 포함한 모든 프록시 유형을 처리합니다. 이는 인증된 SOCKS5가 플래그를 통해 절대 작동하지 않기 때문입니다 — Chromium은 SOCKS5에 대한 사용자 이름/비밀번호 지원이 없습니다(Chromium 버그 40829748). SOCKS5의 대안은 자격 증명을 보유하고 127.0.0.1에서 인증 없는 엔드포인트를 제공하는 로컬 릴레이로, 프록시 릴레이 가이드에 설명되어 있습니다. 모든 QuantumProxies 플랜은 HTTP 및 SOCKS5 엔드포인트를 제공하므로 HTTP를 사용하여 전체 문제를 우회할 수 있습니다. HTTP는 기본 인증을 깔끔하게 처리합니다.

nodriver와 실제로 다른 점

포크는 단순한 외관상의 변화가 아닙니다. nodriver, zendriver, Selenium 및 Playwright를 최신 안티봇 시스템과 비교한 공개 벤치마크에서 nodriver/zendriver 계열은 가장 강력하게 통과했으며, zendriver는 병합되지 않은 업스트림 수정을 포함하여 약간 앞섰습니다. 실질적으로 프록시 작업에 영향을 미치는 차이점은: 문제를 분류하는 활성 이슈 트래커, 더 안정적인 릴리스 주기, 세션별로 생성할 수 있는 분리된 브라우저 컨텍스트, 그리고 nodriver에서 유지된 편리한 기능들입니다. 이러한 것들은 인증 문제를 해결하지 않지만, 수정이 더 빨리 이루어질 때 도움이 되며, zendriver가 많은 병렬 세션을 실행하기 더 쉬운 포크가 되게 합니다. 이러한 동시 컨텍스트에서 회전 및 풀링 출구를 위해, 프록시 풀 관리에 대한 우리의 노트는 zendriver에 변경 없이 적용됩니다. 회전 프록시를 통해 라우팅하든 로그인된 흐름을 위한 고정 세션을 고정하든 상관없이.

하나의 명확한 구분: docs.rs에 zendriver라는 별도의 Rust 크레이트도 존재합니다. 이는 여기서 논의된 Python 포크와 관련이 없습니다 — Python에서 스크래핑하는 경우, pip install zendriver가 필요한 것입니다.

자주 묻는 질문

zendriver로 프록시를 어떻게 사용하나요?

zendriver.start()를 호출할 때 browser_args를 통해 주소를 전달하십시오: browser_args=["--proxy-server=host:port"]. 이는 인증되지 않은 엔드포인트에 대해 모든 트래픽을 프록시를 통해 라우팅합니다. 인증된 프록시의 경우 플래그에 user:pass를 넣을 수 없습니다 — IP를 화이트리스트에 등록하거나, CDP Fetch.AuthRequired 핸들러를 사용하거나, 프록시 인증 확장을 로드하십시오.

zendriver는 인증된 프록시를 지원하나요?

내장된 매개변수를 통해서는 지원하지 않습니다 — 이 문제는 이슈 #10과 #208에서 추적됩니다. Chromium은 프록시 플래그에서 자격 증명을 무시하므로 다른 방법으로 인증해야 합니다: 제공자에서 IP 화이트리스트, 프로세스 내에서 도전에 응답하는 CDP 핸들러, 생성된 Chrome 확장, 또는 자격 증명을 보유하는 로컬 릴레이를 사용하십시오.

nodriver와 zendriver의 차이점은 무엇인가요?

zendriver는 nodriver의 커뮤니티 유지 포크로, 동일한 CDP 아키텍처, 스텔스 목표 및 API를 가지고 있습니다. 차이점은 유지 관리입니다: zendriver는 GitHub에서 이슈와 풀 요청을 받고, 병합되지 않은 업스트림 버그 수정을 제공하며, 더 정기적으로 릴리스합니다. 프록시 인증은 둘 다 동일하게 작동합니다 — 이 가이드의 수정 사항은 둘 다에 적용됩니다.

zendriver는 인증된 SOCKS5 프록시를 사용할 수 있나요?

플래그를 통해서는 불가능합니다. Chromium은 SOCKS5 사용자 이름/비밀번호 인증을 구현하지 않았기 때문입니다(Chromium 버그 40829748), 그리고 zendriver는 이를 상속받습니다. 프록시 인증 확장을 사용하거나, 자격 증명을 추가하는 로컬 릴레이를 실행하거나, 제공자의 HTTP 엔드포인트로 zendriver를 지정하십시오 — HTTP 기본 프록시 인증은 SOCKS5 인증이 작동하지 않는 곳에서 신뢰할 수 있게 작동합니다.

zendriver는 오늘날 두 포크 중 더 날카로운 선택이지만, nodriver와 동일한 인증된 프록시 문제를 제공합니다. IP가 고정되어 있을 때는 화이트리스트를 사용하고, 그렇지 않을 때는 CDP 도전에 응답하며, 확장과 릴레이를 백업으로 유지하십시오. 어느 것을 선택하든 출구 IP가 주요 역할을 합니다 — 유지된 포크라도 소진된 데이터센터 주소에서는 여전히 차단됩니다.

zendriver에 깨끗한 주거용 출구 제공