VPNとプロキシ：それぞれが何をカバーし、何をカバーしないか

VPNもフォワードプロキシも、ウェブサイトが見るアドレスを変え、多くの比較はそこで止まります。設定を決める違いはカバレッジです。フォワードプロキシはアプリが自ら使うことを選ぶ仲介者であり、ウェブサイトの前に立つリバースプロキシとは異なります。一方VPNは、オペレーティングシステムがトンネルへルーティングするものすべてを移動させます。暗号化、DNSの扱い、障害時の挙動はすべてこの区分から決まります。次の五つの確認を順に行い、最初に失敗したものが、実際に必要な道具を教えてくれます。

その仲介者はどのアプリをカバーするのか？

ブラウザのプロキシ拡張はそのブラウザプロファイルにだけ適用されます。メールクライアント、パッケージマネージャー、二つ目のブラウザはそれぞれ独自の設定を使い続け、一部のアプリはシステムのプロキシ変数をまったく無視します。VPNはルーティングテーブルがトンネルへ送るものをカバーし、それはルートとクライアントポリシーに応じて、すべてのアプリにも、スプリットトンネルでの一部にもなります。

一回のページ読み込みから一般化するのではなく、重要なアプリを試してください。curl https://ifconfig.meは環境のプロキシ変数に従いますが、デスクトップアプリは従わないかもしれません。Windowsではnetsh winhttp show proxyがサービスが使うWinHTTPプロキシを表示し、これはブラウザの設定とは別の設定です。

そのホップは暗号化されているか、TLSはどこで終わるのか？

プロキシプロトコルは待ち合わせ場所であり、保証ではありません。SOCKS5はTCPを暗号化せずに転送し、平文のHTTPプロキシはリクエスト行とヘッダーをそのまま運びます。プロキシ経由のHTTPSはCONNECTを使うため、TLSセッションはプロキシではなく宛先で終わります。プロキシサーバーとトンネリングに関するMDNのガイドが、プロトコルの側からその違いを説明しています。

VPNはデバイスとそのエンドポイントの間の区間を暗号化します。エンドポイントより先では他のネットワークと同じ規則が適用されるため、トンネルだけでは平文HTTPで認証情報を送るアプリを守れません。どちらの設計も、ログイン済みのアカウント、Cookie、ブラウザのフィンガープリントを隠しません。

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

詳細出力を見ると、curlがポート443へCONNECTを送ったのか、完全なURLで通常のGETを送ったのかが分かります。socks5h://ではホスト名がSOCKS5リクエストの中でプロキシに渡され、プロキシは読めないTLSを中継するため、名前とバイト数だけが見えます。http://プロキシ経由ではhttps://のURLはCONNECTになるので、そのプロキシも宛先の名前と量は見えますが、リクエストやレスポンス本文は見えません。

どのリゾルバーが名前を見るのか？

名前解決はリクエストが出る前にローカルで起きることも、プロキシ側で遠隔に起きることもあります。curlではsocks5h://がホスト名をプロキシへ送り、socks5://はまずローカルで解決します。ブラウザのプロキシ設定にも同等のDNSオプションがあり、PACファイルはホストごとに異なる経路を選べます。

二つのプロトコルは、設定の誤りがなくてもプロキシを迂回できます。WebRTCはSTUNで候補を集め、QUICはHTTP/3をUDP上で動かしますが、TCPプロキシはこれを運べません。UDP 443がブロックされていればブラウザはTCPに戻るため、HTTP/3をプロキシ経路に留める確実な方法は、ブラウザのフラグではなく、ホストのファイアウォール（ネットワーク全体ならルーター）でUDP 443をブロックすることです。

リゾルバーはノートPCの視点ではなく、宛先の視点で確認してください。プロキシの出口アドレスで届いても名前がローカルで解決されていれば、ローカルのリゾルバーにはどのサイトを見ているかが伝わったままです。

仲介者が止まったら何が起きるのか？

明示的なプロキシは閉じた形で失敗し、プロキシのプロセスを止めると、ブラウザやアプリは直接通信せず接続エラーを返します。開いた形で失敗するのはPACとWPADの設定です。スクリプトを取得できなければクライアントはDIRECTに戻り、サイトには再び本当のアドレスが見えます。VPNはクライアントと、キルスイッチやファイアウォール規則が有効かどうかによって、開いた形でも閉じた形でも失敗し得ます。

障害のケースを意図的に試してください。プロキシサービスを止めて再読み込みし、直接読み込む代わりにエラーページが出たら、PACのURLを到達できないホストに向けてフォールバックを確認します。それでも通常の経路でページが読み込まれるなら、そのプロキシは自身の障害に対する保護を何も提供しておらず、頼る前に知っておくべき性質です。

順序がサイトに見えるものを決めます。外向きの通信がVPNを通るプロキシでは、サイトにはVPNエンドポイントのアドレスが見えます。プロキシをトンネルの外に置くと（リモートホスト上のプロキシへVPN）、サイトには代わりにそのプロキシの出口アドレスが見えます。どちらでも二つのホップは別々のことを記録できます。

五つの確認、順番に

以下のチェックリストが判断のすべてを一か所にまとめたものです。カバレッジを最初に置くのは、ほとんどの不一致を排除できるからです。カバーすべきアプリが設定を尊重しなければ、リストの後ろのどれもそれを救いません。

次に、変更のきっかけになったアプリで結果を確認します。設定したブラウザでページを読み込み、同じページをcurlで取得し、それぞれが報告するアドレスを比べます。食い違うなら、拡張機能、PAC規則、アプリ単位の上書きのいずれかがまだ働いており、トンネルの調整では直りません。

設定した内容、つまりどのアプリがプロキシを使うか、DNSはローカルか遠隔か、UDPはブロックされているか、障害時の挙動は何かを記録します。この小さな一覧があるから次の比較ができるのです。「IPが変わった」だけでは、五つの確認のどれが通ったのかは分かりませんでした。