Selenium 프록시 인증: 실제로 작동하는 4가지 설정

Chrome은 Selenium이 건드릴 수 없는 인증 대화 상자를 띄우고, URL에 자격 증명을 포함하는 트릭은 조용히 실패합니다. 여기 Selenium에서 프록시를 실제로 인증하는 네 가지 설정이 있습니다 — 얼마나 적게 고통을 주는지에 따라 순위가 매겨져 있습니다.

Selenium 프록시 인증은 한 줄로 위장된 함정입니다. --proxy-server Chrome 플래그는 프록시 주소를 기쁘게 받아들이고 — 여기에 포함된 사용자 이름과 비밀번호를 조용히 무시합니다. 그러면 Chrome은 WebDriver가 볼 수 없는 네이티브 인증 대화 상자를 띄우고, 스크립트는 멈추며, Stack Overflow에서 찾은 상위 답변(113+ 표)은 현대 Chrome이 더 이상 로드하지 않는 Manifest V2 확장 프로그램으로 해결합니다. 이 가이드는 오늘날 Selenium에서 프록시를 인증하는 네 가지 설정을 다룹니다 — IP 화이트리스트, Manifest V3 확장 프로그램, selenium-wire, 그리고 전체 브라우저 문제를 API에 맡기는 시기를 아는 것입니다.

기본 Selenium 프록시 인증이 실패하는 이유

세 가지 사실이 모든 실패한 시도를 설명합니다. 첫째, Chromium은 --proxy-server=http://user:pass@host:port에서 자격 증명을 제거합니다 — 플래그 형식에는 자격 증명 지원이 없습니다. 둘째, 프록시의 407 Proxy Authentication Required 챌린지는 DOM 외부의 네이티브 대화 상자로 나타나며, send_keys가 도달할 수 없습니다. 셋째, 오래된 DesiredCapabilities 경로(socksUsername / socksPassword)는 SOCKS 프록시에만 적용되었고 HTTP에는 작동하지 않았습니다 — '올바르게 보이는' 구성은 아무것도 하지 않습니다. 따라서 실제 옵션은 모두 대화 상자를 완전히 피합니다.

방법 1: IP 화이트리스트 — 코드 제로, 대화 상자 제로

스크래퍼가 안정적인 공용 IP를 가진 머신에서 실행된다면, 자격 증명을 완전히 생략하십시오: 해당 IP를 프록시 제공자의 대시보드에 등록하면 게이트웨이가 소스 주소로 인증합니다. 모든 QuantumProxies 플랜은 user:pass와 함께 IP 화이트리스트를 지원합니다. Selenium 측은 항상 인증 없이 잘 작동했던 일반 플래그가 됩니다:

from selenium import webdriver

options = webdriver.ChromeOptions()
options.add_argument("--proxy-server=http://gate.quantumproxies.io:PORT")
options.add_argument("--headless=new")

driver = webdriver.Chrome(options=options)
driver.get("https://httpbin.org/ip")
print(driver.find_element("tag name", "body").text)  # proxy exit IP
driver.quit()

실행을 신뢰하기 전에 항상 출구를 확인하십시오: IP-에코 엔드포인트를 로드하고 주소가 프록시에 속하는지 확인하십시오, 잘못 구성된 플래그는 조용히 실패하고 Chrome은 그냥 직접 연결합니다. 화이트리스트의 한계는 지형적입니다: 머신을 인증하지 스크립트를 인증하지 않습니다. 일시적인 클라우드 러너, NAT 뒤의 컨테이너 및 IP가 변경되는 CI 머신은 아래 방법 중 하나가 필요합니다.

방법 2: Manifest V3 Chrome 확장 프로그램

고전적인 해결책은 프록시를 설정하고 chrome.webRequest.onAuthRequired를 통해 인증 챌린지를 해결하는 작은 Chrome 확장 프로그램을 생성합니다. 유명한 2019년 스니펫은 Manifest V2를 사용하지만, Chrome은 이제 이를 폐기했습니다 — 현대 버전은 manifest_version: 3, 서비스 워커, webRequestAuthProvider 권한이 필요합니다. 이는 런타임에 하나를 빌드하고 로드합니다:

import json, os, tempfile
from selenium import webdriver

HOST, PORT = "gate.quantumproxies.io", "PORT"
USER, PASS = "USER", "PASS"

manifest = {
    "name": "Proxy Auth", "version": "1.0", "manifest_version": 3,
    "permissions": ["proxy", "webRequest", "webRequestAuthProvider"],
    "host_permissions": ["<all_urls>"],
    "background": {"service_worker": "worker.js"},
}

worker = """
chrome.proxy.settings.set({
  value: { mode: "fixed_servers", rules: {
    singleProxy: { scheme: "http", host: "%s", port: parseInt("%s") },
    bypassList: ["localhost"] } },
  scope: "regular"
}, function() {});
chrome.webRequest.onAuthRequired.addListener(
  function(details) {
    return { authCredentials: { username: "%s", password: "%s" } };
  },
  { urls: ["<all_urls>"] },
  ["blocking"]
);
""" % (HOST, PORT, USER, PASS)

ext_dir = tempfile.mkdtemp()
with open(os.path.join(ext_dir, "manifest.json"), "w") as f:
    json.dump(manifest, f)
with open(os.path.join(ext_dir, "worker.js"), "w") as f:
    f.write(worker)

options = webdriver.ChromeOptions()
options.add_argument("--load-extension=" + ext_dir)
options.add_argument("--headless=new")
driver = webdriver.Chrome(options=options)
driver.get("https://httpbin.org/ip")

두 가지 함정이 있습니다. 확장 프로그램은 새로운 헤드리스 모드에서만 로드됩니다 — 일반 --headless는 '확장 프로그램 백그라운드 페이지를 기다리는 데 실패했습니다'라는 암호 같은 오류로 실패하므로 --headless=new가 필수입니다. 그리고 --load-extension을 통해 압축되지 않은 디렉토리를 로드하는 것이 Chrome 버전 간에 압축된 zip을 사용하는 것보다 더 신뢰할 수 있습니다. 이를 유지 관리하고 싶지 않다면, PyPI의 selenium-authenticated-proxy 패키지가 단일 프록시 URL에서 확장 프로그램을 생성합니다.

방법 3: selenium-wire, 그리고 그 타협점

selenium-wire은 WebDriver를 로컬 중간자 공격 프록시로 감싸며, 인증된 상위 프록시 — SOCKS5를 포함하여 —를 일반 옵션 딕셔너리로 만듭니다:

# pip install selenium-wire
from seleniumwire import webdriver

options = {
    "proxy": {
        "http": "http://USER:PASS@gate.quantumproxies.io:PORT",
        "https": "http://USER:PASS@gate.quantumproxies.io:PORT",
        "no_proxy": "localhost,127.0.0.1",
    }
}

driver = webdriver.Chrome(seleniumwire_options=options)
driver.get("https://httpbin.org/ip")

무엇을 구매하는지 아십시오. 이 프로젝트는 2024년 초에 유지 관리자가 아카이브했으며 업데이트를 받지 못하며, 로컬에서 트래픽을 해독하기 때문에 대상은 Chrome의 TLS 핸드셰이크 대신 selenium-wire의 핸드셰이크를 보게 됩니다 — IP가 깨끗해도 JA3/JA4 지문 인식 시스템이 이를 플래그합니다. 개발 중 요청 검사를 위해 유용하며, 확장 프로그램 트릭이 없는 Firefox에서는 유용합니다. 보호된 사이트에서의 프로덕션 스크래핑에는 방법 1-2를 선호하거나 한 층 위로 이동하십시오.

Firefox와 인증 격차

Firefox는 프로필 환경 설정을 통해 인증되지 않은 프록시를 깨끗하게 수용하지만, WebDriver에서 자격 증명 대화 상자를 해결할 Chrome의 확장 프로그램 트릭이 없습니다. 실제로 Firefox 사용자는 IP 화이트리스트나 selenium-wire을 선택합니다. Firefox를 선택한 유일한 이유가 프록시 처리였다면, 그 이유는 더 이상 유효하지 않습니다.

Selenium 패치를 중단하고 API로 전환할 시기

인증은 첫 번째 세금일 뿐, 마지막이 아닙니다. Chrome 인스턴스는 수백 MB의 RAM을 소모하므로 몇십 개의 동시 세션이 서버를 포화시킵니다; ChromeDriver 버전은 Chrome 릴리스를 따라가며; 안티봇 벤더는 IP와 상관없이 일반 Selenium을 감지합니다 — navigator.webdriver와 CDP 아티팩트가 이를 드러냅니다. 두 가지 업그레이드가 경제성을 변화시킵니다. 첫째, 브라우저를 주거용 프록시를 통해 실행하여 IP 평판이 차단의 이유가 되지 않게 하십시오 — 90M+ 가정용 IP가 요청당 회전 또는 로그인 흐름을 위한 고정 세션을 제공합니다. 둘째, 브라우저 유지 관리가 가치가 없을 때, Scraper API가 전체 스택을 하나의 HTTP 호출로 축소합니다: JavaScript를 필요에 따라 렌더링하고, IP 및 재시도를 내부적으로 관리하며, HTML, markdown 또는 구조화된 JSON을 반환합니다. 동일한 타협은 Selenium의 사촌들에게도 적용됩니다 — Playwright 프록시 통합 및 Puppeteer 프록시 설정에 대한 가이드를 참조하여 프레임워크 전환이 탐지 문제를 해결할 것이라고 가정하기 전에 확인하십시오.

자주 묻는 질문

Selenium ChromeDriver에서 인증된 프록시를 어떻게 설정합니까?

프록시 제공자와 함께 머신의 IP를 화이트리스트에 추가하고 일반 --proxy-server 플래그를 전달하거나, 프록시를 설정하고 chrome.webRequest.onAuthRequired를 통해 자격 증명을 제공하는 작은 Manifest V3 확장 프로그램을 로드하십시오. 플래그에 user:pass@를 포함하는 것은 작동하지 않습니다 — Chromium은 이를 무시합니다.

Selenium에서 Chrome이 왜 프록시 로그인 팝업을 표시합니까?

프록시가 407로 응답했고 Chrome이 사람에게 자격 증명을 요청하고 있습니다. 대화 상자는 네이티브 UI로, WebDriver에 보이지 않으므로 선택자나 send_keys 호출로 채울 수 없습니다. 해결책은 대화 상자가 나타나기 전에 인증하는 것입니다: IP 화이트리스트, 인증 확장 프로그램, 또는 selenium-wire 같은 MITM 레이어입니다.

selenium-wire는 2026년에도 여전히 작동합니까?

여전히 많은 작업 부하에 대해 설치 및 작동하지만, 프로젝트는 2024년 초에 아카이브되었고 유지 관리가 없습니다. 그 MITM 설계는 또한 Chrome의 TLS 지문을 Python 지문으로 대체하며, 현대 안티봇 시스템이 이를 감지합니다. 이를 디버깅 도구로 취급하고, 프로덕션 스크래퍼의 기초로 사용하지 마십시오.

Selenium에서 Firefox와 인증된 프록시를 어떻게 사용합니까?

Firefox 프로필 환경 설정은 프록시 주소를 구성하지만 자격 증명 프롬프트에 응답할 수 없으며, Chrome에서처럼 확장 프로그램 해결책도 없습니다. 자격 증명이 필요 없도록 IP 화이트리스트를 사용하거나, Firefox를 selenium-wire을 통해 라우팅하여 상위 인증을 로컬에서 처리하십시오.

Java와 C#에서도 동일하게 작동합니까?

네 — 메커니즘은 Chrome에 있으며, 언어 바인딩에 있지 않습니다. IP 화이트리스트와 --proxy-server는 어디서나 동일하며, Manifest V3 확장 프로그램 접근 방식은 Java나 C#에서도 동일한 두 파일을 작성하고 ChromeOptions에 --load-extension을 추가하여 작동합니다. selenium-wire만 Python 전용이며, 다른 언어는 BrowserMob과 같은 로컬 MITM 프록시를 대체합니다.

짧은 버전: 인증 대화 상자와 싸우지 마십시오. IP가 안정적일 때는 화이트리스트를 사용하고, 그렇지 않을 때는 MV3 확장 프로그램을 생성하며, 검사 작업을 위해 selenium-wire을 유지하고 — 브라우저 유지 관리가 생성하는 데이터보다 커질 때는 작업을 API로 승격하여 저녁 시간을 확보하십시오.

주거용 IP에서 Selenium 실행