まず現象を確認する:システムプロキシは本当にオンになっているか
「システムプロキシが効かない」という表現はあいまいで、実際には「まったくプロキシを通っていない」「一部のアプリだけ通っていない」「プロキシは通っているがルールが判定を誤って直結扱いにしている」という3つの異なる問題が隠れていることがあります。調べ始める前に基本項目を一通り確認しておくと、後の手間が大幅に減ります。
クライアントのメイン画面を開き、サイドバーまたは上部の「システムプロキシ」スイッチがオンになっているか確認します。当たり前に思えるかもしれませんが、実際のサポート事例では、スイッチが誤ってオフになっていた、あるいはシステム再起動やクライアント更新後にシステムプロキシ設定が再書き込みされていなかった、というケースが少なくありません。
続いてポートを確認します。Clash のコアは通常、HTTP(または HTTP+HTTPS 混合)ポートと SOCKS5 ポートをそれぞれリスニングしており、よく使われる既定値は 7890(HTTP)と 7891(SOCKS)です。OSのネットワーク・プロキシ設定パネルを開き、アドレスとポートがクライアントの設定画面に表示されている値と一致しているか、ひとつずつ確認してください。クライアント側でポートを独自の値に変更したのに、システムプロキシの設定が古いポートのままだと、通信はそもそもコアに届きません。
- クライアントの「システムプロキシ」スイッチがオンになっているか;
- クライアントに表示されている混合ポート/HTTPポート/SOCKSポートと、システムプロキシ設定が一致しているか;
- 複数のプロキシツールが同時にシステムプロキシ設定を奪い合い、後から起動したものが前者を上書きしていないか;
- プロキシグループで現在選択されている方式が「直結(DIRECT)」や失効済みのノードになっていないか。
注意:一部のクライアントは設定ファイルを切り替えるとシステムプロキシのスイッチをリセットします。サブスクリプションやローカル設定を変更した後は、記憶に頼らずスイッチの状態を再確認することをおすすめします。
ブラウザ側の確認:プロキシスイッチ、ポート、拡張機能の競合
ブラウザは「プロキシを通っていないように見える」現象が最も起きやすい場面ですが、原因は Clash 本体ではなくブラウザ自体のネットワーク設定側にあることが多いです。ブラウザごとにシステムプロキシの反映方法が完全には統一されていないため、以下の順で範囲を絞り込んでいくことをおすすめします。
ブラウザがシステムプロキシを読み込んでいるか確認する
多くの主要ブラウザは既定でシステムプロキシ設定に追従しますが、独自の「内蔵プロキシ」オプションを備えているブラウザもあり、これが有効になっているとシステム層の設定は無視され、ブラウザ自身が保存しているアドレスが使われます。ブラウザのネットワーク/プロキシ設定画面を開き、モードが「システムプロキシを使用」または「自動検出」になっているか、意図せず「手動設定」に切り替わって古いアドレスが入力されたままになっていないかを確認してください。
拡張機能による競合を調べる
ブラウザ拡張機能も頻出の落とし穴です。一部の回線切替系、広告ブロック系、プライバシー強化系の拡張機能はプロキシ設定を自前で乗っ取ったり PAC スクリプトを注入したりして、システムプロキシと競合します。この場合「クライアントのログに接続記録がまったく残らない」という形で現れます。ネットワーク関連の拡張機能を一時的にすべて無効化してページを再読み込みし、動作を確認してみてください。正常に戻れば、拡張機能を一つずつ有効化しながら競合元を特定します。
プライベートウィンドウで比較テストする
プライベート(シークレット)ウィンドウは既定で通常の拡張機能を読み込まないため、拡張機能による競合を切り分ける手軽な方法になります。プライベートウィンドウでは正常に動くのに通常ウィンドウでは動かない場合、原因は拡張機能かブラウザ内にキャッシュされた古いプロキシ設定であるとほぼ確定できます。ブラウザのネットワーク設定キャッシュをクリアするか、関連拡張機能を再インストールすれば解決します。
ヒント:ブラウザのアドレスバーに about:net-internals のようなネットワーク診断ページ(各ブラウザに対応するもの)を入力すると、現在有効になっているプロキシのアドレスとポートが直接表示される場合があります。推測より確実です。
ターミナル側の確認:環境変数、curl テスト、よくある誤解
ターミナル(コマンドライン)上のプログラムは通常、OSのグラフィカルなプロキシ設定を読み込まず、環境変数に依存します。これが「ブラウザのプロキシは正常なのに git、curl、npm などのコマンドラインツールだけ外部に接続できない」という状況が起きる理由です。
まず Clash クライアントが該当プラットフォーム向けのターミナルプロキシ書き込み機能を有効にしているか確認してください(一部のクライアントはシステムプロキシがオンのときに http_proxy/https_proxy 環境変数を自動で設定しますが、手動設定が必要なクライアントもあります)。ターミナルで現在の環境変数を出力して確認できます:
echo $http_proxy
echo $https_proxy
echo $all_proxy出力が空の場合、現在のターミナルセッションにはプロキシ環境変数が設定されていないため、手動でエクスポートします。ポート番号はクライアントに実際に表示されている値に合わせてください:
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export all_proxy="socks5://127.0.0.1:7891"設定後、詳細情報付きで curl リクエストを実行し、実際にプロキシを経由しているか確認します:
curl -v -x http://127.0.0.1:7890 https://example.orgこのコマンドが正常にコンテンツを返し、-x を付けない通常のリクエストが失敗する、または結果が異なる場合、プロキシの経路自体には問題がなく、対象プログラムが環境変数を読み込んでいないことが原因です。よくある原因は、変数が現在のターミナルセッションにしか有効になっておらず、新しく開いたターミナルウィンドウやGUIから起動したアプリ(デスクトップアイコンから起動したものなど、ターミナル経由でないもの)にはこれらの変数が継承されない、というものです。エクスポート文を shell の起動設定ファイル(.zshrc、.bashrc など)に書き込んで再読み込みするか、システム全体の環境変数として設定すれば、この「時々効く、時々効かない」という見かけ上の不安定さを避けられます。
Windows ターミナルでの追加手順
Windows の PowerShell や CMD もGUI側のシステムプロキシ設定を自動的には継承しないため、セッション変数を個別に設定するか、システム環境変数パネルで永続的に設定する必要があります:
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"設定後は curl.exe -v や Invoke-WebRequest で確認リクエストを実行し、「ブラウザで使えている」だけでターミナルも必ず通ると判断しないようにしてください。
バイパスルールによる見かけ上の未接続
もう一つのパターンとして、プロキシ自体は効いているのに、ルールによって「直結すべき」と判定され、まったくプロキシを通っていないかのように見えるケースがあります。これは設定ファイルの rules セクションやシステムプロキシのバイパスリスト(除外設定)が適切でない場合に最も起きやすい問題です。
システムプロキシ設定には通常「以下のアドレスを除外」といった入力欄があり、既定で localhost やローカルネットワークのアドレス帯が含まれている場合があります。テスト対象のサイトやワイルドカードを誤ってこの除外リストに追加してしまうと、そのアドレスはクライアント自体の状態にかかわらず永久にプロキシを経由しなくなります。まず除外リストを空にして比較テストを行い、問題が解消するか確認することをおすすめします。
設定ファイル側のルールも合わせて確認すべきポイントです。よくあるルールの一例を以下に示します。範囲の広すぎる直結マッチが前方に置かれていないか注目してください:
rules:
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXYテスト対象がたまたま GEOIP,CN,DIRECT のようなルールに先に一致してしまうと、ノードやポートがすべて正常でも、そのリクエストはプロキシノードを経由せず直結扱いになります。クライアントのログパネルを開いて詳細ログレベルに切り替え、対象アドレスへもう一度アクセスして、その接続が実際にどのルールに一致し、最終的にどのプロキシグループが使われたのかを確認してください。これが「ルールの誤判定」なのか「プロキシ自体が効いていない」のかを見分ける最も直接的な証拠になります。
調査の順番:まずログで一致したルールを確認 → 次に除外リストを確認 → 続いてポートとスイッチを確認 → 最後にノード自体の状態を疑う、という順序で進めると効率が最も良く、いきなりクライアントを再インストールしたりサブスクリプションを変更したりする手間を避けられます。
ここまで問題がなければ、TUN モードも検討する
システムプロキシはアプリケーション層プロトコル(HTTP/SOCKS)による転送に依存しているため、システムプロキシ設定に従わないプログラムや、独自のネットワークスタックを使っているアプリはもともとシステムプロキシを経由しません。こうしたケースはシステムプロキシモードだけでは根本的に解決しづらいものです。繰り返し確認してもプロキシ経路自体に問題がなく、一部の頑固なプログラムだけがシステムプロキシ層を回避していることが判明した場合は、TUN モードへの切り替えを検討してください。TUN モードではコアがネットワーク層で全通信を引き受けるため、個々のプログラムがプロキシ設定を読み込むかどうかに依存しなくなります。TUN モードの適用範囲はより徹底していますが、権限やネットワークアダプタの設定要件も高くなるため、システムプロキシの調査で明確に効果がないと確認できた後の次善策として検討し、最初から基本的な確認をスキップして有効化するのは避けることをおすすめします。