Clash接続失敗トラブルシューティングチェックリスト:ポート占有からシステムプロキシまで順にチェック

Clashのコア(内核)がエラーを出す、ブラウザでページが開かない、サブスクリプションを更新したのに接続できない――こうした問題の原因は、多くの場合5つの箇所に集中しています。ローカルポートが占有されていないか、システムプロキシのスイッチが実際に有効になっているか、現在選択しているノードが利用可能か、DNS解析が改ざん・汚染されていないか、そしてファイアウォールやセキュリティソフトがコアプロセスを遮断していないか、という点です。クライアントを何度も再起動するより、この順番で一つずつ切り分けるほうがはるかに時間を節約できます。本チェックリストは内側から外側への順で構成しています。まずコア自体が正常にポートをリスニングできているかを確認し、次にシステム側が確かにトラフィックをコアへ転送しているかを確認し、最後に転送されたトラフィックが実際に目的のサイトへ届いているかを確認します。

NOTE / 補足

本記事はClash Metaコア(mihomo)および主要なGUIクライアント(Clash Verge、Clash for Windows系フォーク、ClashX Metaなど)を基準としています。コマンド例はWindows・macOS・Linuxの3プラットフォーム別に示していますので、作業前にクライアントを完全に終了して一度再起動し、一時的な不具合を除外しておいてください。

ステップ1:ローカルポートの占有を確認する

Clashのコアは既定でミックスポート(通常7890)、コントロールパネルポート(9090)、一部クライアントが使用するDNSポート(53または1053)をリスニングします。これらのポートが他のプログラムに占有されていると、コアが起動に失敗したり、サイレントに機能停止したりし、クライアント画面上は「実行中」と表示されていても実際にはトラフィックが流れていない状態になります。

Windows

netstat -ano | findstr "7890"
netstat -ano | findstr "9090"

出力の最後の列がプロセスIDです。タスクマネージャーや tasklist /FI "PID eq プロセスID" でそのプロセスの正体を確認できます。Clash以外のプロセスにポートが占有されている場合は、クライアント設定でミックスポートを7891など空いている値に変更するか、占有プロセスを終了させてからコアを再起動してください。

macOS / Linux

lsof -i:7890
lsof -i:9090

このコマンドは該当ポートをリスニングしているプロセス名とPIDを表示します。出力が空の場合、コアがそのポートのリスニングに全く成功していないことを意味するため、クライアントのログパネルに戻ってコアの起動エラーを確認してください。よくある原因は設定ファイル内のポート項目のタイプミスや、範囲外のポート番号を指定していることです。

ステップ2:システムプロキシのスイッチ状態を確認する

クライアント画面の「システムプロキシ」スイッチは、実質的にシステムのプロキシ設定項目を書き込んでいるだけで、コアを直接制御しているわけではありません。スイッチが「オン」と表示されていても、システムが実際にその設定を採用しているとは限りません。よくあるのは、セキュリティソフトによって設定がリセットされる、あるいはシステム上に複数のネットワーク構成が同時に存在する(VPNとWi-Fiが併存しているなど)ことで、プロキシが誤ったネットワークインターフェースに書き込まれてしまうケースです。

Windowsでの確認

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer

ProxyEnableの値が0x1であればシステムプロキシは有効です。ProxyServerには127.0.0.1:7890のようなアドレスが表示されるはずです。このアドレスがクライアントの実際のリスニングポートと一致しない場合は、クライアント側でシステムプロキシのスイッチを一度オフ→オンにして書き込みを更新してください。

macOSでの確認

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi

有線接続を使用している場合はWi-FiをEthernetまたは対応するインターフェース名に置き換えてください(networksetup -listallnetworkservicesでインターフェース一覧を確認できます)。

Linuxでの確認

大半のLinux用GUIクライアントはシステムレベルのプロキシを直接書き換えず、デスクトップ環境やブラウザ拡張が環境変数を読み取る方式に依存しています。次のコマンドで直接確認することを推奨します。

echo $http_proxy
echo $https_proxy

結果が空の場合、システムプロキシはネットワーク設定またはshellの設定ファイルに手動で宣言する必要があります。あるいはTUNモードに切り替えてシステムプロキシの層を経由せずにトラフィックを引き受ける方法もあります。

ステップ3:ノードの利用可否を確認する

システムプロキシが有効になっていても、ノードが実際に通信できるとは限りません。サブスクリプションの有効期限切れ、機場(プロキシサービス)の一時メンテナンス、選択中のノードの遅延テストがタイムアウトを示している、といったケースがよくあります。切り分けの順番としては、まずクライアントのノード一覧で遅延数値を確認し、次にコンソールで対象ノードを個別にテストするのがおすすめです。

遅延列が「タイムアウト」や「N/A」と表示されている:そのノードは現在利用できません。まず遅延が正常な別ノードに切り替えてください。
すべてのノードの遅延が異常:サブスクリプション全体が失効しているか、端末自体のネットワークが切断されている可能性が高いです。まず端末が日本国内のサイトへ直接アクセスできるか確認してください。
遅延は正常だが目的のサイトにアクセスできない:そのノードが目的サイト側から個別にブロックされている可能性があります。出口の地域を切り替えてみてください。

コントロールパネルのAPIでもノードの接続性を検証できます。ただし設定でコントロールポートが開放されていることが前提です。

curl -x http://127.0.0.1:7890 https://www.google.com -I --max-time 5

HTTP/2 200や30x系のステータスコードが返れば、プロキシ経路自体は通っていることを意味します。コマンドがタイムアウトしたり接続拒否が返る場合は、問題がブラウザやアプリ側ではなくプロキシ経路にあることを示しているため、ブラウザ設定を何度も見直すのではなく、ノードやサブスクリプション側の切り分けに戻るべきです。

CAUTION / 注意

サブスクリプションリンクに対応する機場によっては、1アカウントあたりの同時接続デバイス数に制限があります。同一サブスクリプションを複数の端末で同時に使用すると、機場側が新規接続をランダムに拒否することがあり、ノードの遅延は正常なのにリクエストが失敗する現象として現れます。このような場合は、他の端末でクライアントを終了させてから再度テストしてみてください。

ステップ4:DNS解析を確認する

Clashは設定ファイル内で独自のDNSサーバーを定義したり、fake-ipやredir-hostモードを有効にしたりできます。端末のシステムDNSとClash内蔵DNSが競合すると、ページは開くが表示が遅い、あるいは一部のドメインが常に誤ったIPに解決される、といった現象が起きやすくなります。

現在有効なDNSを確認する

# Windows
nslookup www.google.com

# macOS / Linux
nslookup www.google.com
dig www.google.com +short

fake-ipを有効にしている場合、解析結果は通常198.18.0.0/16という予約アドレス帯に収まります。これは正常な挙動で、プロキシがトランスポート層でドメイン名に基づいて接続を再確立するためであり、解析エラーを意味するものではありません。結果が実在のパブリックIP帯にあるにもかかわらずサイトが開かない場合は、誤ったルーティングルールに一致してそのドメインが直結(プロキシを経由しない)扱いになっていないか、さらに切り分ける必要があります。

Clash内蔵DNSが正しく呼び出されているか確認する

nslookup www.google.com 127.0.0.1 -port=1053

ポート番号は設定ファイル内のdns.listenフィールドと一致させる必要があります。このコマンドがタイムアウトする場合、コアのDNSモジュールが正常に起動していないことを示しているため、設定ファイルに戻ってdns.enableがtrueになっているか、上流DNSサーバーのアドレスに到達可能かを確認してください。

ステップ5:ファイアウォールとセキュリティソフトによる遮断を確認する

OS標準のファイアウォール、サードパーティのセキュリティソフト、企業内ネットワークの端末管理ソフトウェアなどが、Clashのコアプロセスを狙って遮断することがあります。この種の遮断は明確なエラーが出ず、接続要求がサイレントに破棄されるだけなので、切り分け時にノード側の問題と誤認しやすい点に注意が必要です。

Windows Defenderファイアウォール

netsh advfirewall firewall show rule name=all | findstr /i "clash"

一致する結果が無い場合、ファイアウォールにClashコアを許可するルールが存在しないことを意味します。「ファイアウォールを介してアプリを許可する」設定で、クライアントの実行ファイルとコアプロセス(よくあるファイル名はclash-meta.exeやmihomo.exe)にプライベートネットワークとパブリックネットワークの両方にチェックを入れてください。

macOSのアプリケーションファイアウォール

「システム設定 → ネットワーク → ファイアウォール → オプション」のパスから、Clashクライアントとそのコアプロセスの状態が「受信接続を許可」になっているか確認してください。一部のセキュリティソフト(企業向けEDRなど)はシステムファイアウォールとは別に独自に遮断を行うため、該当ソフトの信頼リストに追加で許可設定を行う必要があります。

Linux iptables / ufw

sudo iptables -L -n | grep 7890
sudo ufw status verbose

プロキシポートに対するDROPやREJECTルールが存在しないことを確認してください。TUNモードを使用している場合は、仮想ネットワークカードに対応するルーティングテーブルの項目が正しく書き込まれているかも確認が必要です。ip routeでutunやtun0宛てのデフォルトルートが存在するか確認できます。

チェックリスト一覧

上記5つのステップを、そのまま照らし合わせて使えるチェックリストにまとめました。

ミックスポート(7890)とコントロールポート(9090)が他のプロセスに占有されておらず、コアのログにポート競合エラーが出ていない。
システムプロキシの設定項目(ProxyServerやnetworksetupの出力)がクライアントの実際のリスニングポートと一致している。
現在選択中のノードの遅延が正常、あるいは遅延が正常な別ノードに切り替え済みである。
curl -xによるテストでプロキシ経由で目的のサイトに正常にアクセスでき、正当なHTTPステータスコードが返る。
DNS解析結果が期待どおり(fake-ip帯、または正しい実IP)であり、誤ったルーティングルールに一致していない。
システムファイアウォールとセキュリティソフトの両方で、Clashクライアントとコアプロセスにネットワーク権限が許可されている。
TUNモードを使用している場合、仮想ネットワークカードのルーティングテーブル項目が正しく書き込まれており、他のVPNにデフォルトルートを奪われていない。

STOP / 警告

上記7項目すべてに問題がないにもかかわらず特定のサイトにアクセスできない場合、多くはそのサイト側がプロキシの出口IP帯を個別にブロックしていたり、認証(CAPTCHA)で遮断していたりする、サイト側のポリシーの問題です。このケースでは端末側のネットワーク設定を何度も調整し続けるべきではありません。

このチェックリストをローカルのメモとして保存し、接続異常が起きた際は毎回この順番で実行することをおすすめします。再起動やノードの変更、クライアントの再インストールをランダムに試すよりも効率的です。多くの接続失敗は最初の2ステップ(ポートとシステムプロキシ)を終えた段階で特定できます。残りのノード・DNS・ファイアウォールの3ステップは、少数の厄介なケースへの対処として使います。