안티 디텍트 브라우저에서 인증된 프록시: 2026 지원 지도

Chromium은 SOCKS5에서 자격 증명을 수락한 적이 없으며, --proxy-server만 전달하는 런처는 인증 프롬프트에 응답할 사람이 없습니다. 여기 어떤 프레임워크가 user:pass를 수락하는지, 어떤 것이 도움이 필요한지, 그리고 어떤 것이 막다른 길인지에 대한 정보입니다.

안티 디텍트 브라우저에서 인증된 프록시는 세 가지 방식 중 하나로 실패하며, 증상은 변하지 않습니다: Chrome 자격 증명 팝업이 아무 것도 해제할 수 없고, 모든 요청에 407이 발생하거나, 자신의 IP에서 완벽하게 로드되는 페이지입니다. 프록시가 문제인 경우는 드뭅니다. Chromium은 SOCKS5에서 사용자 이름과 비밀번호를 수락한 적이 없으며, 바이너리에 --proxy-server만 전달하는 런처는 브라우저의 인증 도전에 응답할 사람이 없습니다. 이것이 2026 지도입니다: 어떤 프레임워크가 user:pass를 네이티브로 수락하는지, 어떤 것이 도움이 필요한지, 그리고 어디에서 길이 끝나는지.

하나의 근본 원인, 세 가지 증상

Chromium의 프록시 스택에는 SOCKS5 서버 주소를 위한 슬롯이 있으며 자격 증명을 위한 슬롯은 없습니다. 이 요청은 수년간 Chromium 트래커에 이슈 40323993으로 남아 있으며, SwitchyOmega 확장은 자체 이슈 #1455에서 Chrome 팀의 확인을 기록했습니다. 동일한 문제를 쫓는 ChromeDriver 사용자는 crbug 40829748로 안내받습니다. Firefox는 예외입니다 — SOCKS5를 네이티브로 인증합니다 — 그래서 Camoufox가 여기의 다른 모든 것과 다른 열에 위치합니다. 프로토콜 분할이 처음이라면 SOCKS5 vs HTTP 프록시로 시작하세요.

HTTP 및 HTTPS 프록시는 다른 이야기입니다: 자격 증명은 작동하지만, 명령줄에서는 절대 작동하지 않습니다. Chrome은 407에 대해 인증 도전을 제기하며, 누군가가 응답해야 합니다 — 일반 브라우저에서는 팝업이 보입니다. 자동화에서는 로드된 확장, Fetch.authRequired에 구독된 CDP 핸들러, 또는 프레임워크 자체가 응답해야 합니다. 런치 플래그만 전달하는 것은 도전에 응답하지 않으며, 이것이 사람들이 계속 스크린샷을 찍는 멈춘 페이지입니다. 자격 증명 형식의 절반은 407 프록시 인증 필요 수정에서 다룹니다.

안티 디텍트 브라우저에서 인증된 프록시 지원: 2026 지도

세 가지 버킷: API에서 수락된 자격 증명, 직접 구축한 도우미를 통해서만 수락된 자격 증명, 그리고 어떤 구성도 이동하지 않는 엔진의 한계.

user:pass와 네이티브로 작동

확장, 릴레이 또는 CDP 핸들러가 필요

절대 작동하지 않음: 자격 증명이 있는 SOCKS5

인증된 프록시 지원의 세 가지 열 비교: 네이티브 사용자 및 비밀번호 지원이 있는 프레임워크, 확장 또는 CDP 핸들러가 필요한 프레임워크, 그리고 Chromium에서 절대 작동하지 않는 자격 증명이 있는 SOCKS5
동일한 Chromium 코어, 세 가지 결과. 첫 번째 열은 구성 변경, 두 번째는 빌드 단계, 세 번째는 우회해야 하는 엔진 제한입니다.

우회 방법 1: 제공자의 HTTP 엔드포인트 사용

위의 대부분의 스레드를 해결하며 비용이 들지 않습니다. 제공자가 HTTP 및 SOCKS5를 통해 동일한 풀을 노출하면, 브라우저를 HTTP 게이트웨이에 지정하고 자격 증명이 지원되는 매개변수가 됩니다. 프록시 측 DNS는 무료로 제공됩니다: Chromium은 항상 HTTP 프록시에 이름 해석을 위임합니다. 모든 QuantumProxies 계획은 동일한 자격 증명으로 동일한 게이트웨이에서 HTTP 및 SOCKS5를 제공합니다, 따라서 전환은 스킴 변경이지 새로운 주문이 아닙니다.

# Playwright, Patchright and Camoufox all take the same proxy object.
# Swap the import line; the proxy config does not change.
from playwright.sync_api import sync_playwright   # or: from patchright.sync_api import ...

PROXY = {
    "server": "http://gate.quantumproxies.io:PORT",  # HTTP endpoint, not socks5://
    "username": "USER",
    "password": "PASS",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY, headless=False)
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.inner_text("pre"))
    browser.close()

# Camoufox: same dict, plus geoip so timezone/locale/WebRTC follow the exit IP.
# pip install -U "camoufox[geoip]"
# with Camoufox(geoip=True, proxy=PROXY) as browser: ...

우회 방법 2: IP 화이트리스트

가장 깔끔한 답은 인증 단계를 삭제하는 것입니다. IP 화이트리스트를 사용하면 브라우저를 실행하는 머신의 공용 IP를 등록하고 게이트웨이가 소스 주소로 승인합니다 — 사용자 이름, 비밀번호, 팝업, 프레임워크가 응답할 것이 없습니다. 이 페이지의 모든 문제가 한 번에 사라지며, SOCKS5도 포함됩니다, 왜냐하면 전달할 자격 증명이 없기 때문입니다. 고정된 스크래핑 서버나 정적 이그레스 IP 뒤의 컨테이너에는 적합하며, 네트워크가 변경되는 노트북에는 적합하지 않습니다. 화이트리스트는 모든 QuantumProxies 계획에서 user:pass와 함께 제공되므로, 프로덕션은 화이트리스트에 추가할 수 있고 개발은 자격 증명을 유지할 수 있습니다.

90M+ 주거 풀에서 IP를 화이트리스트에 추가하세요

우회 방법 3: 생성된 Chrome 인증 확장 또는 CDP 핸들러

Chromium 프레임워크에서 자격 증명을 유지해야 하는 경우, 브라우저 내부의 무언가가 도전에 응답해야 합니다. 옵션 하나는 프록시를 설정하고 onAuthRequired에 응답하는 확장입니다 — SeleniumBase가 --proxy 플래그 뒤에서 구축하는 것과 정확히 동일합니다. Manifest V3에서 작동하게 만드는 두 가지 권한은 webRequest와 webRequestAuthProvider입니다; 두 번째를 놓치면 리스너가 절대 작동하지 않습니다.

// manifest.json (MV3) — webRequestAuthProvider is the one people forget
{
  "name": "proxy-auth",
  "version": "1.0",
  "manifest_version": 3,
  "permissions": ["proxy", "webRequest", "webRequestAuthProvider"],
  "host_permissions": ["<all_urls>"],
  "background": { "service_worker": "background.js" }
}

// background.js
const HOST = "gate.quantumproxies.io";
const PORT = 8080;              // your gateway port
const USER = "USER", PASS = "PASS";

chrome.proxy.settings.set({
  value: {
    mode: "fixed_servers",
    rules: { singleProxy: { scheme: "http", host: HOST, port: PORT } },
  },
  scope: "regular",
});

chrome.webRequest.onAuthRequired.addListener(
  () => ({ authCredentials: { username: USER, password: PASS } }),
  { urls: ["<all_urls>"] },
  ["blocking"],
);

두 가지 주의 사항이 있습니다. 확장은 모든 헤드리스 구성에서 로드되지 않으므로, 종종 서버에서 헤드풀과 가상 디스플레이를 강제합니다. 그리고 확장 표면은 이동합니다: SeleniumBase 사용자는 Chrome 137 확장 변경으로 프록시 인증을 잃었으므로, 브라우저와 프레임워크 버전을 고정하세요.

옵션 두는 확장을 건너뛰고 CDP를 통해 도전에 응답합니다. 이것이 nodriver 토론에서 수락된 솔루션이며, 순서가 모두를 혼란스럽게 합니다: Fetch 도메인을 활성화하기 전에 핸들러를 등록하고, 핸들러 내에서 절대 대기하지 않거나 이벤트 루프를 교착 상태에 빠뜨립니다.

import asyncio, nodriver as uc

PROXY = "http://gate.quantumproxies.io:PORT"   # no credentials in the flag
USER, PASS = "USER", "PASS"

async def main():
    browser = await uc.start(browser_args=[f"--proxy-server={PROXY}"])
    tab = await browser.get("draft:,")

    async def on_auth(event: uc.cdp.fetch.AuthRequired):
        # fire-and-forget: awaiting here blocks every other request
        asyncio.create_task(tab.send(uc.cdp.fetch.continue_with_auth(
            request_id=event.request_id,
            auth_challenge_response=uc.cdp.fetch.AuthChallengeResponse(
                response="ProvideCredentials", username=USER, password=PASS),
        )))

    async def on_paused(event: uc.cdp.fetch.RequestPaused):
        asyncio.create_task(tab.send(uc.cdp.fetch.continue_request(request_id=event.request_id)))

    tab.add_handler(uc.cdp.fetch.RequestPaused, on_paused)
    tab.add_handler(uc.cdp.fetch.AuthRequired, on_auth)
    # enable AFTER the handlers are registered, or no event ever arrives
    await tab.send(uc.cdp.fetch.enable(handle_auth_requests=True))

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

uc.loop().run_until_complete(main())
프록시 인증에 대한 간단한 수정 사항, 예를 들어 HTTP 엔드포인트 사용 및 IP 화이트리스트와 같은 것과 인증 확장 생성 또는 CDP 핸들러 작성과 같은 더 어려운 것들을 대조하는 체크리스트
작업 순서: 엔드포인트를 변경한 다음 IP를 화이트리스트에 추가하세요. 둘 다 불가능할 때만 확장, 릴레이 또는 CDP 훅을 구축하세요.

우회 방법 4: 로컬 릴레이

릴레이는 자격 증명으로 업스트림 게이트웨이와 통신하고 프레임워크에 인증되지 않은 리스너를 제공하는 localhost에서 실행되는 작은 프록시입니다. 브라우저는 127.0.0.1에 연결하고 인증 도전을 보지 않으며, 자격 증명 문제는 그것과 문제가 없는 프로세스로 이동합니다. 이것이 Chromium에서 자격 증명이 있는 SOCKS5를 사용하는 유일한 방법이며, Camoufox 사용자가 보고하는 것입니다. GitHub의 오픈 소스 릴레이는 환경 변수로 업스트림 자격 증명을 받습니다. 리스너를 루프백에 묶어 두세요 — 공용 인터페이스에 인증 없는 프록시를 열면 다른 사람의 무료 대역폭이 됩니다. 빌드 대 설치는 SOCKS5 인증을 위한 프록시 릴레이 도구에서 다룹니다.

# SeleniumBase UC Mode: one flag, extension generated for you
pytest test_proxy.py --uc --proxy=USER:PASS@gate.quantumproxies.io:PORT

# Relay route: credentials upstream, no auth on the local listener
SOCKS5_SERVER=gate.quantumproxies.io:PORT \
SOCKS5_USER=USER SOCKS5_PASSWORD=PASS \
  ./socks-relay.py 127.0.0.1:1080

# now every framework can use it, credentials and limitations gone
# playwright: proxy={"server": "socks5://127.0.0.1:1080"}
# nodriver:   browser_args=["--proxy-server=socks5://127.0.0.1:1080"]

어떤 경로를 선택할지

자주 묻는 질문

Chrome이 왜 사용자 이름과 비밀번호가 있는 SOCKS5를 지원하지 않나요?

Chromium의 네트워크 스택이 SOCKS5 사용자 이름 및 비밀번호 인증 방법을 구현한 적이 없기 때문입니다. 이 요청은 수년간 Chromium 트래커에 이슈 40323993으로 남아 있으며, Chrome 팀은 관련 확장 스레드에서 지원되지 않는다고 확인했습니다. 누락된 플래그가 아닙니다: 명령줄 인수의 조합이 Chromium에 SOCKS5 자격 증명을 전달하지 않으며, 모든 Chromium 기반 프레임워크가 이를 상속받습니다.

어떤 안티 디텍트 프레임워크가 최고의 프록시 지원을 제공하나요?

인증된 HTTP 프록시의 경우, Playwright 계열 — Playwright, Patchright, browser-use 및 Camoufox — 가 가장 덜 고통스럽습니다, 왜냐하면 자격 증명이 일급 매개변수이기 때문입니다. Camoufox는 GeoIP 옵션을 통해 종료 IP와 타임존, 로케일 및 WebRTC를 정렬하여 가장 멀리 나아갑니다. CDP 우선 도구인 nodriver와 zendriver는 스텔스에 강하지만 인증을 직접 해결해야 합니다.

UC 모드에서 인증 프록시가 Cloudflare 우회를 깨뜨리나요?

그럴 수 있으며, 보고서는 보통 두 가지 별개의 문제를 하나로 비난합니다. 생성된 인증 확장은 브라우저의 표면을 변경하고, 프록시는 종료 IP를 변경합니다 — 평판이 나쁜 IP는 어떤 프레임워크도 통과할 수 없는 강력한 도전을 유발합니다. 동일한 대상을 두 번 테스트하세요, 한 번은 프록시로, 한 번은 화이트리스트에 추가된 IP로, 프레임워크를 비난하기 전에.

IP 화이트리스트가 user:pass보다 안전한가요?

운영적으로 더 간단하며, 도전에 응답할 필요가 없고 자격 증명이 런치 플래그나 프로세스 목록에 앉아 있지 않기 때문에 실패의 전체 클래스를 제거합니다. 거래는 유연성입니다: 풀을 고정된 소스 주소에 묶어 두므로, 네트워크가 변경되는 노트북과 자동 확장 작업자는 여전히 자격 증명이 필요합니다. 대부분의 팀은 프로덕션을 화이트리스트에 추가하고 개발을 위해 user:pass를 유지합니다.

지도가 짧아서 암기할 수 있습니다. Playwright와 그 포크는 자격 증명을 받습니다; nodriver와 zendriver는 답을 만들어야 합니다; SeleniumBase는 그것을 만들어주고 가끔 깨집니다; 자격 증명이 있는 SOCKS5는 Chromium에서 막다른 길입니다. 나머지는 HTTP 엔드포인트, 화이트리스트에 추가된 IP, 확장 및 릴레이 중 선택하는 것입니다 — 그 순서대로, 왜냐하면 그것이 유지보수가 가장 적기 때문입니다.

하나의 계획에서 HTTP, SOCKS5 및 IP 화이트리스트를 받으세요