ブラウザへのプロキシ統合には、グローバルプロキシ、環境単位のバインド、拡張機能によるプロキシの3方式があります。それぞれの適用範囲、長所と短所、認証ダイアログやSOCKSプロトコル不一致などの典型的な問題を比較します。
ブラウザにプロキシを設定する方法は、主に3つあります。表面的には設定手順が違うだけに見えますが、本質的な違いは適用範囲です。どの通信がその出口を使うのか、1回の変更で何個のアカウントに影響するのかを先に整理しておけば、後のトラブルシューティングを大きく減らせます。
グローバルプロキシ：1回の設定でブラウザ全体に適用
OSまたはブラウザのネットワーク設定に出口を1つ指定すると、その後に開くページ、拡張機能が送るリクエスト、バックグラウンドのAPI呼び出しはほぼすべてその出口を通ります。環境ごとに個別設定する必要がないため、最も素早く設定でき、単一アカウントの運用やローカルテストに特に向いています。
問題も同じ適用範囲にあります。すべてのアカウントが同じ出口を共有すると、別々のIDが同じネットワーク経路に結び付けられます。プラットフォームがネットワーク情報を基に関連付けを行う場合、それらを同一グループとして扱う可能性があります。また、出口が不安定になったり停止したりすると、1つのアカウントだけでなく、すべてが同時に影響を受けます。そのため、グローバルプロキシは1人で1〜2アカウントを扱う場面に向き、アカウント数が増えると扱いにくくなります。
環境単位のバインド：1環境につき1出口
プロキシのアドレスと認証情報を特定のブラウザ環境の設定に入れ、出口をその環境に固定します。どの環境を開くかによって使う出口が決まり、環境を切り替えればIDも切り替わります。アカウントとIPの対応関係を固定でき、環境同士が干渉しません。
利点は対応関係が明確なことです。アカウント数が増えると、環境一覧そのものが管理台帳になり、どの環境にどの地域が割り当てられているか一目で確認できます。一括調整も、ブラウザを1つずつ開いてネットワーク設定を変更するより確実です。
見落としやすい点が2つあります。1つ目は、出口を変えることは実質的にIDを変えることだという点です。同じ環境内にCookieとログイン状態は残っているのに、IPだけが突然別の地域へ移ります。プラットフォームから見るとIDと時系列が一致しなくなるため、確認処理や制限が発生しても不自然ではありません。すでに運用中のアカウントでは、安易に出口を変更しない方がよいでしょう。2つ目は、環境をコピーまたはクローンするときに出口まで一緒に複製しないことです。そうすると2つの環境が同じIPを共有し、分離の意味がなくなります。
拡張機能によるプロキシ：最も細かい制御、最も狭い範囲
3つ目は、ブラウザ拡張機能にプロキシ制御を任せる方法です。ドメイン、タブ、ルール単位で転送し、サイトごとに別の出口を使わせたり、素早く切り替えたりできます。地域をまたいだ価格比較や複数サイトのテストに便利です。
ただし、境界を理解する必要があります。拡張機能が管理できるのは、ブラウザ内部で自身が対応しているリクエストだけで、ブラウザ外のプログラムには影響しません。同じ環境にネットワーク制御を行う拡張機能を複数入れると、ルールが競合して原因調査が難しくなることもあります。停止時の挙動にも注意が必要です。拡張機能が無効化されたり、更新に失敗したり、クラッシュしたりすると、通信がそのままローカル回線へ流れ、実アドレスが露出することがあります。環境が多い場合は、各環境への個別インストールと保守も必要になります。
プロトコルと認証で問題が起きやすい箇所
プロキシアドレスがSOCKS5なのに、クライアント側がHTTPプロキシとして接続しようとしている場合、またはその逆の場合、設定値が正しそうに見えるのに接続できない、という症状がよく出ます。この場合はIPを疑う前に、まずプロトコル種別がクライアント設定と一致しているか確認します。
HTTPとHTTPSのプロキシは互換性が高い一方、ユーザー名とパスワードが必要な場合は認証ウィンドウが表示されることがあります。無人運用や一括処理では、このダイアログが処理を止める原因になります。認証情報をアドレス内に書けるツールもありますが、書式はツールごとに統一されておらず、形式を間違えやすい点に注意が必要です。
SOCKS5は認証情報を設定に直接含められ、ポップアップなしで利用できるうえ、より多くの種類の通信を転送できるため、混在トラフィックでは扱いやすくなります。出口の種類では、固定IPのデータセンタープロキシは高速で比較的低コストなので、自動化や多数アカウントに向きます。固定IPのISP住宅プロキシは実ユーザーに近く、長期運用に向きます。ローテーション型の住宅プロキシは通信量課金でアドレスを切り替えられるため、登録やデータ収集など短期タスクに適しています。
4項目を確認して初めて設定完了
ブラウザでWebページを開けても、プロキシが正しく機能しているとは限りません。出口アドレスが想定どおりか、DNS解決もプロキシ経由か、IPv6環境で実アドレスが露出していないか、WebRTCがローカルネットワークアドレスを漏らしていないかを確認する必要があります。どれか1つでも見落とすと、表面上は正常に閲覧できてもID情報は露出している可能性があります。
各パラメータの整合性も必要です。出口の地域はアカウント登録地域と合わせ、タイムゾーンは出口に合わせ、言語は対象市場に合わせます。IPだけ変えて他の設定をそのままにするのでは不十分です。
どう選ぶか
単一アカウントや一時的なテストなら、通常はグローバルプロキシで十分です。アカウント数が多く、長期的に固定したIDを維持する必要がある場合は、環境単位のバインドが向いています。この場合はプロキシと環境の対応関係を一元管理する必要があり、PurpleMarkのようなツールはそれらのバインドを1つの環境一覧にまとめるため、設定変更時のアカウント取り違えを減らせます。サイト単位の振り分けや複数地域の比較が必要なら、ブラウザ内の通信だけが対象になることを前提に、拡張機能によるプロキシを検討できます。
