VPNはつながるのに一つのアプリだけネットにつながらない？そのプロキシを確認

トンネルは上がっていて、ステータスページには正常なハンドシェイクが表示されていますが、一つのアプリだけは何も読み込めません。そのアプリはおそらく、より古い仲介役にリクエストを送り続けています。システムプロキシ、拡張機能、デバイス管理から配布される設定ファイル、またはそのプロセスだけが読むプロキシ変数です。VPNサーバーを変えてもその設定には触れず、同じマシンで他のアプリが動くというパターンもこれで説明できます。失敗しているアプリから外側へ調べ、プロキシの問題が片付くまでトンネルはそのままにしてください。

どの層がプロキシ設定を所有しているか

アプリのリクエストに対する権限を主張できる場所は四つあり、ふつうは最も狭い層が勝ちます。OSはグローバルプロキシと任意の自動設定URLを持ち、ブラウザはそれに従うことも上書きすることも拡張機能に制御を渡すこともできます。コマンドラインツールは自身の環境を読み、管理ポリシーは変更後に上記のどれでも再び固定できます。何かを編集する前にどの層が責任を持つかを決めてください。間違った層を消すと、成功した修正のように見えて次のログインで戻ってきます。

二つのアプリを、VPN専用のテストページではなく同じ普通のWebサイトで比較してください。ブラウザが失敗してターミナルのダウンロードが成功するなら、OSは問題ではなく、違いはブラウザのプロファイルか拡張機能にあります。両方失敗しても同じマシンの二つ目のユーザーアカウントで成功するなら、その設定はユーザーごとです。この比較は一分で済み、ほとんどの当て推量を消せます。

各ツールが実際に使っている値を読む

変更する前に設定を出力し、正確なプロキシ文字列を復元できる場所にコピーしてください。シェル変数はコマンドラインツールにとって最速の確認方法です。VPNクライアントは通常それらに触れません。

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

目の前のプラットフォームに合う行だけを実行し、ホスト、ポート、資格情報について出力を読みます。たとえば http://proxy.corp.example:8080 のような値は、ツールがあらゆるリクエストでそのホストに問い合わせることを意味し、空の結果は直接接続していて本当の障害は別の場所にあることを意味します。出力をチケットに貼る前にユーザー名とパスワードの部分を伏せてください。そうした文字列は人が思うよりずっと頻繁に有効な資格情報です。

独自のプロキシエンジンを持つツールには独自の証拠が要ります。Curlは冗長性を上げると下した判断を表示し、これは環境から推測するより確実です。同じフラグで、名前解決がローカルで起きたのかプロキシで起きたのかも分かります。

上書きを消して同じリクエストを再テストする

一つの層を変えてから、失敗したまさにそのリクエストを繰り返してください。別のURLでは何も証明できません。まず現在のシェルで環境変数を消してください。その編集は元に戻せ、トンネルを壊すこともありません：

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

詳細な出力がまだプロキシを主張するなら、環境が権限ではありませんでした。さらに上書きを積むのではなく、一つ上の層へ移ってください。

macOSでは、自動設定ファイルが値を供給していないことを確認し、その後サービスプロキシをオフにして変更を確定してください。Windowsでは、WinHTTPの設定とユーザーごとのブラウザ設定が別のオブジェクトであることを忘れないでください。そのため、きれいなコマンドラインツールが、まだ古いサーバーを指すブラウザと共存できます。拡張機能も同じ疑いを向ける価値があります。プロキシ拡張機能は一つのプロファイルのリクエストだけを書き換えられ、これは一つのブラウザだけに影響して他には何も影響しない障害の形そのものです。

修正が再起動後も残ることを確認する

編集したターミナルでしか動かない設定は修正されていません。デスクトップのランチャーからアプリを開き直し、ログアウトして再ログインし、古いプロキシが戻るかどうかを見てください。

二つの確認が本物の修正と一時的なものを分け、どちらも直接接続または意図した値を報告するはずです。きれいな環境での実行は、削ぎ落としたプロセスがまだシステム設定を拾うかどうかを示します。

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

再起動後に古い値が戻るなら、発生源は管理ポリシーか、それを再適用するプロファイルであり、そのポリシーの所有者が例外を外す必要があります。証明書の検証は最後まで有効にしておいてください。トラフィックを傍受するプロキシは、検証を切った途端に解決したように見えてしまいます。最後に、外した値と日付をメモに書き残してください。次の担当者が意図的なプロキシと忘れられたプロキシを区別できるようにするためです。