アンチディテクトブラウザにおける認証プロキシ: 2026年サポートマップ

ChromiumはSOCKS5での認証情報を受け入れたことがなく、--proxy-serverのみを渡すランチャーは認証プロンプトに応答する者がいません。どのフレームワークがuser:passを受け入れ、どれがヘルパーを必要とし、どれが行き止まりかを示します。

アンチディテクトブラウザでの認証プロキシは3つの方法で失敗し、その症状は変わりません: Chromeの認証情報ポップアップが消えない、すべてのリクエストで407が発生する、または自分のIPから完璧にページが読み込まれる。プロキシが原因であることは稀です。ChromiumはSOCKS5でのユーザー名とパスワードを受け入れたことがなく、--proxy-serverをバイナリに転送するランチャーはブラウザの認証チャレンジに応答する者がいません。これは2026年のマップです: どのフレームワークがuser:passをネイティブに受け入れ、どれがヘルパーを必要とし、どこで道が終わるか。

1つの根本原因、3つの症状

ChromiumのプロキシスタックにはSOCKS5サーバーアドレスのスロットがあり、認証情報のスロットはありません。このリクエストは40323993としてChromiumトラッカーに何年も座っており、SwitchyOmega拡張機能はChromeチームの確認を自身のissue #1455に記録し、ChromeDriverユーザーは同じことを追い求めてcrbug 40829748を指摘されます。Firefoxは例外で、SOCKS5をネイティブに認証します。これがCamoufoxが他のすべてと異なる列に位置する理由です。プロトコルの分割が初めての場合は、SOCKS5 vs HTTP proxiesから始めてください。

HTTPおよびHTTPSプロキシは異なる話です: 認証情報は機能しますが、コマンドラインからは決して機能しません。Chromeは407に応答して認証チャレンジを発生させ、何かが応答しなければなりません。通常のブラウザでは、あなたが見るポップアップです。自動化では、ロードされた拡張機能、Fetch.authRequiredにサブスクライブされたCDPハンドラー、またはフレームワーク自体でなければなりません。起動フラグを渡すだけのものはチャレンジに応答せず、人々がスクリーンショットを撮り続けるハングしたページになります。認証情報形式の半分はfixing 407 proxy authentication requiredでカバーされています。

アンチディテクトブラウザにおける認証プロキシサポート: 2026年マップ

3つのバケット: APIで認証情報を受け入れるもの、構築したヘルパーを介してのみ認証情報を受け入れるもの、設定で動かせないエンジンの限界。

user:passでネイティブに動作

拡張機能、リレー、またはCDPハンドラーが必要

決して動作しない: 認証情報付きSOCKS5

認証プロキシサポートの3列比較: ネイティブのユーザーとパスワードサポートを持つフレームワーク、拡張機能またはCDPハンドラーを必要とするフレームワーク、Chromiumで決して動作しない認証情報付きSOCKS5
同じChromiumコア、3つの結果。最初の列は設定の変更、2番目はビルドステップ、3番目は回避するエンジンの制限です。

回避策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フレームワークで認証情報を保持する必要がある場合、ブラウザ内の何かがチャレンジに応答しなければなりません。オプション1はプロキシを設定しonAuthRequiredに応答する拡張機能です — まさにSeleniumBaseが--proxyフラグの背後で構築するものです。Manifest V3の下でそれを機能させる2つの権限はwebRequestとwebRequestAuthProviderです; 2番目を逃すとリスナーは決して発火しません。

// 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"],
);

2つの注意点。拡張機能はすべてのヘッドレス構成でロードされるわけではないため、これによりサーバー上でヘッドフルと仮想ディスプレイが必要になることがよくあります。そして拡張機能の表面は動きます: SeleniumBaseユーザーはChrome 137の拡張機能の変更でプロキシ認証を失ったため、ブラウザとフレームワークのバージョンを固定してください。

オプション2は拡張機能をスキップし、CDPでチャレンジに応答します。これはnodriverディスカッションで受け入れられた解決策であり、順序がすべての人をつまずかせます: Fetchドメインを有効にする前にハンドラーを登録し、ハンドラー内で決してawaitしないでください、さもないとイベントループをデッドロックします。

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のオープンソースリレーは、環境変数として上流の認証情報を受け取ります。リスナーをループバックにバインドしておいてください — 公開インターフェース上のオープンな認証なしプロキシは他人の無料の帯域幅です。ビルド対インストールはproxy relay tools for SOCKS5 authでカバーされています。

# 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チームは関連する拡張スレッドでサポートされていないことを確認しています。欠けているフラグではありません: コマンドライン引数の組み合わせでSOCKS5認証情報をChromiumに渡すことはできず、すべてのChromiumベースのフレームワークはそれを継承します。

どのアンチディテクトフレームワークが最良のプロキシサポートを持っていますか？

認証されたHTTPプロキシに関しては、Playwrightファミリー — Playwright、Patchright、browser-use、Camoufox — が最も痛みが少ないです。認証情報が一級のパラメータであるためです。CamoufoxはGeoIPオプションを通じてタイムゾーン、ロケール、WebRTCを出口IPと一致させることで最も進んでいます。CDPファーストのツール、nodriverとzendriverはステルスに強いですが、認証を自分で解決することを期待しています。

UCモードで認証プロキシがCloudflareバイパスを壊しますか？

可能性はありますが、通常は2つの別々の問題を1つとして非難します。生成された認証拡張機能はブラウザの表面を変更し、プロキシは出口IPを変更します — 評判の悪いIPはどのフレームワークも通過できない厳しいチャレンジを引き起こします。同じターゲットを2回テストし、1回はプロキシを使用し、1回はホワイトリスト化されたIPを使用してからフレームワークを非難してください。

IPホワイトリスト化はuser:passより安全ですか？

運用上はシンプルで、チャレンジに応答する必要がなく、認証情報が起動フラグやプロセスリストに座ることがないため、失敗のクラス全体を削除します。トレードオフは柔軟性です: プールを固定されたソースアドレスにバインドするため、ネットワークが変わるラップトップやオートスケーリングワーカーにはまだ認証情報が必要です。ほとんどのチームは本番環境をホワイトリスト化し、開発にはuser:passを保持します。

マップは覚えやすいほど短いです。Playwrightとそのフォークは認証情報を受け入れます; nodriverとzendriverは回答を構築させます; SeleniumBaseはそれを構築し、時折壊れます; 認証情報付きSOCKS5はChromiumでは行き止まりです。残りはHTTPエンドポイント、ホワイトリスト化されたIP、拡張機能、リレーの選択です — その順序で、なぜならそれが最小から最大のメンテナンスだからです。

1つのプランでHTTP、SOCKS5、IPホワイトリスト化を取得