ブラウザのプロキシ拡張機能で最もつまずきやすいのは適用範囲です。拡張機能はブラウザの通信しか引き受けず、ルールに一致しないと直接接続に流れてしまいます。本記事では用途別に拡張機能を分類し、プロトコル、認証、権限、メンテナンス状況といった評価軸を整理したうえで、出口 IP と WebRTC 漏洩を確認する自己検証手順を示します。
ブラウザのプロキシ拡張機能には、見落とされがちな境界があります。引き受けるのはブラウザが送信するリクエストだけです。OS の更新、デスクトップクライアント、その他のアプリの通信はこれまでどおりの経路を通ります。何をプロキシ経由にしたいのかを先に固めてからツールを選ぶと、後の切り分けがずっと楽になります。
まず用途で三つに分ける
最も多いのはサイト単位の切り替えです。一部のドメインだけをプロキシ経由にし、残りは直接接続のままにします。この用途はルール表で制御し、拡張機能の価値は切り替えの速さとドメイン単位の振り分けにあります。
二つ目はグローバルプロキシで、ブラウザの通信をすべて一つの出口から出します。設定は最も簡単ですが、代償もはっきりしています。出口が落ちるとブラウザは事実上オフラインになり、日常利用の安定性は損なわれます。
三つ目は環境に紐づける方式で、ブラウザプロファイルごとに出口を固定し、プロファイル同士が影響し合わないようにします。複数アカウントや複数プロジェクトを並行して動かすときに使う考え方で、ここでは拡張機能はあくまで補助であり、出口そのものは通常もっと下の層で設定します。
拡張機能を評価するときの観点
第一にプロトコルの対応状況です。HTTP と HTTPS のプロキシは TCP しか扱いません。SOCKS5 はより汎用的ですが、UDP への対応は実装次第で、多くの拡張機能は UDP をそのまま通すか、そのまま捨ててしまいます。この点は後で効いてきます。WebRTC が漏れるかどうかに直結するからです。
認証方式もよく確認します。ユーザー名とパスワードによる認証は便利ですが、拡張機能に保存された資格情報はローカルに平文か弱い暗号化で置かれるため、同じパソコンを使う他人に読まれやすくなります。IP 許可リストによる認証は拡張機能に何も保存しませんが、ネットワークを変えるたびにリストを追加し直す必要があります。
適用範囲が最も問題になりやすい箇所です。ルールモードでは、どのルールにも一致しないドメインは既定で直接接続になりますが、ページが実際にどのドメインを要求しているのかを把握しているとは限りません。HTTPS のサイトは接続を確立した後、拡張機能から見えるのはドメインだけでパスは見えないため、パスで振り分けるという発想はほぼ成立しません。
権限の範囲も一通り確認します。プロキシ拡張機能が、すべてのサイトのデータ読み取り、タブ情報、クリップボードといった権限まで要求しているなら、それが掲げる機能と関係があるのかを問うべきです。ブラウザ拡張機能のマニフェストバージョンの引き上げも利用できるインターフェースを絞っており、古い拡張機能がアーキテクチャの変更を迫られた例もあります。
メンテナンスの活発さは、更新履歴の多さではなく、上流の変化を追いかけている人がいるかで見ます。プロキシ系の拡張機能では、Proxy SwitchyOmega のストア版は公開終了となり、コミュニティが保守するフォーク（例えば ZeroOmega の系統）がその後の対応を引き継ぎました。FoxyProxy のような拡張機能は複数のブラウザ向けの版があります。いずれも中立的な例であり、どれが適しているかは上記の各項目次第です。
拡張機能が覆えない通信
拡張機能を入れるとブラウザ自身はプロキシ経由になりますが、同じパソコン上の他のプログラム、バックグラウンドの更新サービス、そしてブラウザ内部でも拡張機能の要求経路に従わない通信は、依然としてローカルから出ている可能性があります。ネットワークの一貫性の確認は拡張機能のパネルだけを見ていては足りません。完全に分離するには、システムプロキシかそれより上の層で対処する必要があります。
自己検証：まず出口、次に漏洩
最初の手順は出口 IP の確認です。訪問者の IP と所在地を返すページをいくつか開き、通常のウィンドウとルールに一致するタブでそれぞれ一度確認し、結果が一致するかを見ます。ルールにプロキシを書いてあるのにローカルのアドレスが出るなら、ルールが効いていないかドメインが一致していません。複数のサイトで確認すると、一部のリクエストだけがプロキシを通っているケースも見つかります。
二つ目の手順は WebRTC の確認です。専用の検証ページは、ブラウザが取得したローカル候補アドレスと公開候補アドレスを一覧表示します。公開候補にプロキシの出口ではなく実際の IP が現れるなら、UDP がプロキシを通っておらず、ページのスクリプトから実際のネットワーク位置を取得できてしまいます。
三つ目の手順は DNS の確認です。名前解決サーバーの所在地と出口の所在地が離れすぎていると、一部のサイトは環境が異常だと判断します。
最後の手順はシークレットウィンドウでの再確認です。多くの拡張機能は既定ではシークレットモードで動作せず、拡張機能の設定で手動で許可する必要があります。この手順を忘れるとまったく逆の結論に至ります。
検証してから使い方を決める
自己検証の結果は拡張機能の説明より信頼できます。実際の出口、DNS の解決位置、WebRTC の露出状況の三つが揃ったうえで、拡張機能を使い続けるか、出口をもっと下の層に降ろすかを決めます。複数環境を並行させる場面では、各環境に独立した出口を用意して固定し、複数のマシンで一つの出口を共有しないようにしましょう。
