Clash システムプロキシが機能しない場合の対処法:ブラウザと端末を分けて確認

まず3分でできる基本確認

「システムプロキシが効かない」の大半は、実は最も基本的な部分で引っかかっています。設定をいじる前に、まず以下の4項目を順番に確認してください。多くの場合これだけで原因が絞れます。

1. クライアントが本当に動作しているか確認する。タスクトレイにアイコンが表示され、メイン画面が正常に開けるか。最小化した後にひっそり終了していないか。
2. ノードが使えるか確認する。プロキシページで現在のノードの遅延テストを行い、タイムアウトや異常な遅延が出るノードは切り替える。システムプロキシは入口にすぎず、ノードが通っていなければ入口を正しく開けても意味がない。
3. システムプロキシが実際にOSへ書き込まれているか確認する。クライアント側の表示が「オン」になっているだけでは不十分で、OS側の実際の値を確認する必要がある。Windowsは「設定 → ネットワークとインターネット → プロキシ」で「プロキシサーバーを使用する」を確認。macOSは「システム設定 → ネットワーク → 詳細 → プロキシ」でWebプロキシとセキュアWebプロキシを確認。Linux(GNOME)は「設定 → ネットワーク → ネットワークプロキシ」で手動モードになっているか確認する。アドレスは127.0.0.1、ポートはクライアントと一致していること。
4. ポートが一致しているか確認する。クライアントの設定ページに表示されているポートと、OSに書き込まれたポートが同じである必要がある。ポートを変更した後にスイッチを入れ直し忘れるのは非常によくあるミス。

システムプロキシのスイッチは何をしているのか

仕組みを理解しておけば、無駄な試行錯誤が半分は省ける。このスイッチがやっていることは1つだけ:「127.0.0.1 + クライアントのリスニングポート」をOSのプロキシ設定に書き込むこと。それ以降、システムプロキシに従うアプリ(ほとんどのブラウザやデスクトップソフト)は接続時にまずClashのコア経由でトラフィックを流し、コアがルールに従って振り分ける。システムプロキシを読まないアプリは一切影響を受けず、コマンドラインツールはその典型例。

したがって「スイッチをオンにしても効かない」原因は3つのどこかに絞られる。

• 書き込み失敗:OSにそもそも設定が書き込まれていない。権限不足、セキュリティソフトによるブロック、別のプロキシソフトによる横取りなどが典型。
• アプリが読まない:アプリが独自のプロキシ設定を使っている、またはシステムプロキシをそもそも参照しない。
• 入口が通っていない:設定は正しく書き込まれているが、Clashのポートがリスニングしていない、または現在のノードが使えない。

1番目と3番目は前の節の基本確認で除外できる。残りは、ブラウザと端末の2系統に分けて対処する。

ブラウザ側:まず拡張機能と個別設定を確認

まずコマンド1つでClashの入口自体が通っているか確認する。ターミナルを開き、プロキシを明示的に指定してIP照会APIへアクセスする。

curl -x http://127.0.0.1:7890 https://api.ip.sb

返ってくるのはノードの出口IPのはず。ここで失敗する場合はクライアントやノード側の問題で、ブラウザとは関係ないので前節に戻って対処する。ここが正常でブラウザだけ効かない場合は、以下の順で確認する。

1. プロキシ系拡張機能を無効化する。SwitchyOmegaのような拡張機能はブラウザのプロキシを乗っ取り、システム設定より優先度が高い。まず全て無効化してテストし、正常に戻ったら1つずつ有効化して、どれが競合しているか特定する。
2. シークレットウィンドウで比較する。シークレットモードはデフォルトで拡張機能を読み込まないため、シークレットでは正常・通常ウィンドウでは異常なら、拡張機能が競合していると断定できる。
3. Firefoxの独立設定を確認する。Firefoxのプロキシ設定はOSのパネルと独立しているため、以前手動で変更していた場合は「設定 → ネットワーク設定」で「システムプロキシ設定を使用する」に戻す。
4. 残留した自動構成スクリプトを消す。システムプロキシに「自動構成スクリプト(PAC)を使用する」のアドレスが残っていると、ブラウザはClashではなくそのスクリプトに従って動作するので、この項目をオフにする。
5. 出口IPで最終確認する。IP照会サイトを開き、ノードを切り替えてから再読み込みし、出口IPが変わればリンクは通っている。個別のサイトだけ開けない場合はルールやノードの問題であり、もはやシステムプロキシの問題ではない。

端末側:コマンドラインはシステムプロキシを読まない

これは最もよくある誤解:ターミナル、そしてその中のcurl、git、npmはデフォルトでシステムプロキシを一切読まない。スイッチをオンにし続けても直接接続のままである。ターミナルでプロキシを使うには、環境変数を別途設定する必要がある。

macOS / Linux(bash、zsh):

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:7890

Windows PowerShell:

$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"

Windows cmd:

set http_proxy=http://127.0.0.1:7890
set https_proxy=http://127.0.0.1:7890

設定後にcurl https://api.ip.sbを実行して確認し、ノードのIPが返れば有効になっている。以下も覚えておくとよい。

• 環境変数は現在のウィンドウにのみ有効で、ウィンドウを閉じると無効になる。恒久的に効かせたい場合はshellの設定ファイル(~/.zshrcなど)に書き込む。
• 1つのコマンドだけプロキシを通したい場合、macOS / Linuxでは一時的に接頭辞を付ければよい:https_proxy=http://127.0.0.1:7890 curl https://api.ip.sb。
• ローカルおよびLAN内アドレスへのアクセスはプロキシを回避すべき:export no_proxy=localhost,127.0.0.1。
• ターミナルのプロキシを解除する場合、macOS / Linuxではunset http_proxy https_proxy all_proxyを実行、PowerShellでは対応する変数を空に再設定すればよい。
• gitは独自の設定を使い、環境によっては環境変数を参照しない:git config --global http.proxy http://127.0.0.1:7890で設定、git config --global --unset http.proxyで解除。これはHTTP(S)リモートにのみ影響し、SSHリモートには影響しない点に注意。

ポート競合:リスニングに失敗するとスイッチが無意味になる

ポートが他のプログラムに占有されている場合、Clashのポートリスニングは失敗する。スイッチは普通にオンにでき、システム設定も普通に書き込まれるが、入口の先にトラフィックを受け取るサービスが存在せず、結果として「オンにしてもオフの時と同じ」状態になる。 まずポートが何に占有されているか確認する。Windows(PowerShellまたはcmd): ```bash netstat -ano | findstr :7890 ``` 出力があればポートは既に占有されている。最後の列が占有プロセスのPIDで、`tasklist | findstr ` でどのプログラムかを確認する。macOS / Linux: ```bash lsof -i :7890 ``` Linuxでは `ss -lntp | grep 7890` でも確認できる。出力されたプロセスが自分のClashクライアントでなければ、競合が確定する。対処法は2つ: - ポートを変更する:クライアントの設定ページでmixedポートを空いている値(7897など)に変更し、保存後にシステムプロキシのスイッチを一度オフにしてから再度オンにし、新しいポートをOSに再書き込みさせる。 - ポートを空ける:最もよくある占有者は終了しきれていない別のプロキシクライアント、または前回異常終了した際に残留したプロセス。トレイから終了するか、該当プロセスを直接終了させる。

権限、残留設定、複数クライアントの競合

ポートが正常なのに依然として効かない場合は、以下の3つの頻出原因を確認する。

1. macOSの承認をキャンセルしてしまった。初めてシステムプロキシをオンにする際、OSがパスワード入力を求める承認ダイアログを表示するが、「キャンセル」を押すと書き込みが失敗する。スイッチはオンに見えるが、実際にはOSに書き込まれていない。もう一度スイッチを入れ直し、今回は承認を完了させる。
2. セキュリティソフトによるブロック。Windows上では一部のセキュリティソフトがサードパーティ製プログラムによるシステムプロキシの変更をブロックすることがある。クライアントを信頼リストに追加してからスイッチを入れ直す。
3. 複数クライアントの競合。同時に2つのプロキシクライアントを起動していると、後から起動したものが先に起動したものの書き込みを上書きしてしまい、先に起動したクライアントが「効かない」ように見える。同じ時間帯には1つだけ起動しておく。

逆のパターンにも注意したい。クライアントを終了する前にシステムプロキシをオフにしないと、OS側には127.0.0.1:7890の設定がそのまま残り続け、実際にはリスニングしているサービスがすでに存在しないため、「Clashを終了したらむしろネットが切れた」という現象になる。解決法はクライアントを再度起動してスイッチを一度オフにするか、システムのプロキシ設定から手動でオフにすること。

企業や学校などのデバイスでグループポリシーや構成プロファイルによりプロキシ設定がロックされている場合、手動で書き込んでも即座に元に戻される。この環境ではシステムプロキシにこだわらず、端末の環境変数で対処するか、次節のTUNモードを検討するとよい。

端末系ツールを多用するなら、TUN モードへの切り替えが早い

システムプロキシの本質的な弱点は「アプリの対応に依存する」こと。アプリがシステム設定を読まなければ、スイッチはそのアプリに一切効かない。日常的にターミナルでgit、npm、dockerを使うユーザーには、より手間のかからない選択肢としてTUNモードがある。仮想ネットワークアダプタを作成し、システムのネットワーク層でグローバルにトラフィックを引き受けるため、アプリを選ばず、コマンドラインツールも設定なしで自動的にプロキシを通る。

mihomoコアを採用したクライアント(Clash Verge Rev、Clash Nyanpasu、FlClashなど)は設定ページにTUNのスイッチを備えている。Windows・macOSでは初回起動時にサービスモードのインストールや管理者権限の承認が必要になることが多い。TUNとシステムプロキシは同時にオンにしても問題なく、両者は競合しない。TUNはルーティング層で処理し、システムプロキシはアプリケーション層を担当する、それぞれ別の役割である。

1ページで確認できるチェックリスト

行き詰まったら、以下のチェックリストを頭から順に確認する。

1. クライアントが動作しており、現在のノードの遅延テストに合格している。
2. システムプロキシの設定に127.0.0.1が表示され、ポートがクライアント設定ページと一致している。
3. ターミナルで curl -x http://127.0.0.1:7890 https://api.ip.sb を実行し、ノードのIPが返る。
4. ブラウザのプロキシ系拡張機能を全て無効化し、シークレットウィンドウで比較テストする。
5. ターミナルでhttp_proxy / https_proxy環境変数を個別に設定する。
6. netstatまたはlsofでポート競合がないことを確認し、ポート変更後はスイッチを入れ直す。
7. プロキシクライアントは1つだけ起動し、終了前にシステムプロキシをオフにする。
8. 端末での利用が多い場合はTUNモードに切り替えてグローバルに処理させる。

ほとんどの「システムプロキシが効かない」ケースは、3番目の手順で方向性が絞れる。入口が通っていればアプリ側を確認、通っていなければクライアントとポートを確認する。系統立てて確認する方が、クライアントの再インストールよりはるかに速い。