# Playwright SOCKS5プロキシ認証：失敗する理由と4つの修正方法

Playwrightはsocks5://サーバーを受け入れますが、ユーザー名とパスワードを拒否します。この制限はPlaywrightではなくChromiumにあり、2021年から未解決です。ここではその回避方法を4つ、ランキング形式で紹介します。

Playwright SOCKS5プロキシ認証は存在せず、それを事前に知っておくと夜を無駄にせずに済みます。`socks5://`サーバーをユーザー名とパスワードと共に渡すと、ブラウザがナビゲートする前にPlaywrightが拒否します。誰もがたどり着く機能リクエスト[microsoft/playwright#10567](https://github.com/microsoft/playwright/issues/10567)は2021年11月にオープンされ、まだオープンのままで、`P3-collecting-feedback`ラベルが付いています。この制限はPlaywrightではなく、Chromiumにあります。この投稿では正確なエラーストリングを示し、なぜ拡張機能や設定フラグが救済にならないのかを説明し、4つの修正方法を提供します—1行のHTTPスワップ、IPホワイトリスト、ローカルリレー、そしてFirefox。

## あなたが探しているエラー

この問題のすべてのバージョンは2つの文字列のいずれかを生成します。Nodeでは`Error: Browser does not support socks5 proxy authentication`を取得し、Pythonの古いリリースでは`playwright._impl._api_types.Error:`が、最新のものでは`playwright._impl._errors.Error:`がプレフィックスされます。メッセージは同じで、ナビゲーションではなく起動時に投げられます。

```js
const { chromium } = require('playwright');

// Fails immediately — no page is ever created
const browser = await chromium.launch({
  proxy: {
    server: 'socks5://residentialpremium.quantumproxies.io:1080',
    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のuserinfo部分を無視し、認証されていないハンドシェイクを試み、ゲートウェイがそれを拒否します。その後、最初の`goto()`で`net::ERR_SOCKS_CONNECTION_FAILED`または単なるタイムアウトが表示され、存在しないネットワークバグを探すことになります。

## Playwright SOCKS5プロキシ認証が実際に壊れる場所

Playwrightのドキュメントは明確です：プロキシオプションの`username`と`password`フィールドは「HTTPプロキシが認証を要求する場合に使用する資格情報」として説明されています。SOCKSはスキームとしてのみサポートされています。内部では、ChromiumはSOCKS5のためのRFC 1929からのユーザー名/パスワードのサブネゴシエーションを実装していないため、ChromiumのSOCKS5認証に関する問題トラッカーエントリ（40323993）が何年もコメントを集めている理由、SwitchyOmega拡張機能がユーザーに資格情報付きでSOCKS5を選択した瞬間に警告する理由、BraveとEdgeが同じように振る舞う理由です。それは一つのエンジン、一つのギャップであり、それに基づいて構築されたすべてのものに受け継がれています。

これが、Seleniumユーザーを救うトリックがここでは役に立たない理由でもあります。Manifest V3拡張機能は`chrome.webRequest.onAuthRequired`を通じてプロキシチャレンジに応答できますが、そのフックはHTTP `407 Proxy Authentication Required`レスポンスで発火します。SOCKS5ハンドシェイクは、HTTPが存在する前のソケットでのバイトレベルのネゴシエーションであるため、インターセプトするイベントはありません。そして、コンテキストオプション`httpCredentials`をプロキシ認証と混同しないでください：それは訪問しているウェブサイトからの`401`チャレンジに応答し、プロキシには決して応答しません。ステルスフレームワーク全体の全体像については、[認証プロキシのアンチディテクトフレームワークでのサポート状況マップ](https://quantumproxies.io/blog/anti-detect-frameworks-authenticated-proxies-map)をご覧ください。

## 修正1：同じゲートウェイのHTTPエンドポイントを使用する

これは約10人中9人のユーザーにとっての修正であり、1行です。真剣なプロバイダーは、異なるポートで両方のプロトコルを介して同じIPプールを公開しています—すべてのQuantumProxiesプランは、同じ資格情報と同じセッション構文で[HTTPおよびSOCKS5エンドポイント](https://quantumproxies.io/socks5-proxies)を提供します。スキームとポートを切り替え、他はすべてそのままにして、Playwrightのネイティブ資格情報フィールドがその役割を果たします：

```python
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(proxy={
        # was: "socks5://residentialpremium.quantumproxies.io:1080"
        "server": "http://residentialpremium.quantumproxies.io:8080",
        "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トンネルが運ぶのと同じ暗号化されたバイトを運びます。2つのプロトコルの違いはUDPや非HTTPトラフィックに関係しますが、ページロードには関係ありません。[SOCKS5対HTTPプロキシの違い](https://quantumproxies.io/blog/socks5-vs-http-proxy-difference)の詳細は私たちの解説にあります。そして、プロキシオブジェクトは`newContext()`でも受け入れられるため、同じ資格情報でコンテキストごとの回転が可能です。これは[Playwrightプロキシ統合](https://quantumproxies.io/blog/playwright-proxy-integration)ガイドで説明されている通りです。

## 修正2：IPホワイトリストでsocks5://を維持する

SOCKS5スキームが本当に必要な場合—SOCKSのみを話すプロキシ、またはそれを前提とするツールチェーン—リクエストではなくマシンを認証します。スクレイパーのパブリックIPをプロバイダーに登録し、資格情報を削除します。Chromiumは交渉するものがないため満足します：

```js
const { chromium } = require('playwright');

const browser = await chromium.launch({
  proxy: { server: 'socks5://residentialboson.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品質チェッカー](https://quantumproxies.io/ip-checker)は、実際に出口が何であるかを教えてくれます。単に応答しただけではありません。

![PlaywrightのSOCKS5プロキシ認証に対する4つの修正を並べた比較：ゲートウェイのHTTPエンドポイントへの切り替え、IPのホワイトリスト登録、ローカルリレーの実行、Firefoxの起動。カードには各方法のコストを示している：HTTPへの切り替えは1行で済み、ほかは固定IP、監視すべきプロセス、または別のエンジンが必要になる。](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776550/blog/generated/qp-b10-003-diag1.png)
*HTTPエンドポイントのスワップは1行で能力を失うことはありません。それ以降のすべては、socks5://スキームを手に入れるための代償です。*

## 修正3：資格情報を削除するローカルリレー

IPをホワイトリストに登録できず、プロバイダーにHTTPポートがない場合、ブラウザの前にトランスレーターを配置します。パターンは常に同じです：認証なしのローカルリスナーが、資格情報を添付して上流のSOCKS5エンドポイントに転送します。gostを使用すると、それは1つのコマンドです：

```bash
# Local no-auth HTTP listener -> authenticated upstream SOCKS5
gost -L=http://127.0.0.1:8080 \
     -F=socks5://USER:PASS@residentialpremium.quantumproxies.io:1080

# Playwright then points at the local hop, with no credentials:
#   proxy: { server: 'http://127.0.0.1:8080' }
```

2つのルール。リスナーを`127.0.0.1`にバインドし、決して`0.0.0.0`にしないでください—インターネットから到達可能な認証なしのプロキシは、数時間以内に発見され悪用されるオープンリレーです。そして、リレーを監視しなければならないプロセスとして扱います：それが死んだ場合、Chromiumは直接リクエストではなく接続エラーに戻ります。これは少なくとも目立ちます。このアプローチは一般的になりすぎて、実務者が小さな目的別のリレーを公開しています；私たちは[SOCKS5認証リレーツール](https://quantumproxies.io/blog/proxy-relay-socks5-auth-tools)のガイドでオプションを比較しています。

## 修正4：Chromiumの代わりにFirefoxを実行する

FirefoxはSOCKS5のユーザー名/パスワード認証をネイティブに実装しており、Playwrightの問題スレッドが指摘し続けている違いです。ブラウザタイプを切り替えるとエラーが消えます：

```python
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.firefox.launch(proxy={
        "server": "socks5://residentialpremium.quantumproxies.io:1080",
        "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を取り、ブラウザを維持してください。

## 決定を1行で

- **プロバイダーにHTTPポートがある場合：**それを使用します。1行、ネイティブ認証、同じ出口、余分なプロセスなし。
- **固定パブリックIP：**ホワイトリストに登録し、資格情報なしで`socks5://`を維持します。
- **どちらもない場合：**ローカルリレーをループバックにバインドし、Playwrightを`127.0.0.1`に向けます。
- **すでにFirefoxを使用している場合：**資格情報を渡し、出口IPを一度確認します。
- **決して：**資格情報を`server`文字列内に入れないでください。Chromiumはそれを無言で破棄します。

![ChromiumでのPlaywright SOCKS5設定：プロキシのフィールドに認証情報を入れると起動時にエラーになり、socks5://のサーバー文字列に認証情報を入れるとSOCKS接続エラーで静かに失敗する。カードには動作する方法を挙げている：ユーザー名とパスワード付きのHTTPエンドポイント、ホワイトリスト登録したIPでのsocks5://、またはローカルリレー。](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776551/blog/generated/qp-b10-003-diag2.png)
*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プロキシに使用される拡張機能のトリックは`chrome.webRequest.onAuthRequired`に依存しており、これはHTTP 407レスポンスで発火します。SOCKS5はソケットハンドシェイク中に認証され、HTTPリクエストが存在する前に行われるため、拡張機能APIはそれを見ることができません。プロキシスイッチャー拡張機能は同じ理由でこの制限について警告します。

### PlaywrightスクレイピングにおいてSOCKS5はHTTPより速いですか？

意味のあるほどではありません。HTTPプロキシを通じたHTTPSトラフィックは`CONNECT`トンネルを使用するため、両方のプロトコルは同じ暗号化ストリームをほぼ同じオーバーヘッドで運びます。SOCKS5の本当の利点はUDPサポートとプロトコルの中立性であり、どちらもブラウザのページロードでは使用されません。どちらのエンドポイントがクリーンに認証されるかを選んでください。

短いバージョン：Chromiumにこれまでやったことのないことをさせようとするのをやめてください。作業をHTTPエンドポイントに移動するか、ホワイトリストに登録して資格情報を削除してください—そして、回転する出口で`socks5://`を維持する必要がある場合は、コードに回避策を入れるのではなく、中間にリレーを置いてください。認証が解決されたら、実行が成功するかどうかを決定するのは、その背後にあるプールです：[200以上の国にわたる住宅用出口](https://quantumproxies.io/residential-proxies)、フローが1つのアイデンティティを必要とする場合のリクエストごとの回転またはスティッキーセッション。

[1つのプランでHTTPおよびSOCKS5エンドポイントを取得](https://quantumproxies.io/socks5-proxies)