まず「接続済み」がどの層を示しているのか確認する
Clashクライアントの「システムプロキシが有効」「VPN接続済み」「コア実行中」という表示は、ローカルのプロキシ入口が起動していることを示すだけです。リモートノードが利用可能であることや、ブラウザーの通信がClashに入っていることまでは意味しません。完全な通信経路には、アプリ、システムプロキシまたはTUN、mihomoコア、ルール判定、DNS、プロキシノード、対象サイトの少なくとも7つの要素があります。どこか1つが途切れていても、画面上のスイッチは有効のまま表示されることがあります。
トラブルシューティングでは、ノード、DNS、ルール、TUNを同時に変更しないでください。一度に1つの層だけを確認し、各手順で再現可能なテスト結果を残します。テスト先は、ローカルルーターのアドレス、直接接続できるサイト、プロキシ経由が必要なサイトの3つを用意するのがおすすめです。これにより、問題がローカルネットワーク、直接接続経路、プロキシ経路のどこにあるかを素早く切り分けられます。
4つの症状から範囲を絞り込む
| 症状 | 優先して確認する項目 | よくある断点 |
|---|---|---|
| すべてのサイトを開けない | ローカルポート、システムプロキシ、TUN | プロキシポートが待ち受けていない、または通信が誤って別の経路に引き込まれている |
| 直接接続できるサイトは開くが、プロキシが必要なサイトは失敗する | ノード、サブスクリプション、プロキシグループ | ノードが無効、またはプロキシグループでDIRECTが選択されている |
| IPアドレスにはアクセスできるが、ドメイン名では開けない | DNS | 名前解決のタイムアウト、DNSハイジャック、Fake-IP経路の不完全さ |
| ブラウザーは使えるが、ほかのアプリは失敗する | TUN、アプリのプロキシ対応 | アプリがシステムプロキシを参照していない、またはUDPが引き込まれていない |
ステップ1：ノード、サブスクリプション、プロキシグループが実際に使えるか確認する
まずクライアントのプロキシまたはプロキシグループ画面を開き、現在実際に通信を担当しているグループを確認します。多くの設定では、最上位のグループ名が「ノード選択」「Proxy」「GLOBAL」などになっており、その下に自動選択、フォールバック、地域別グループが入っています。ホーム画面に表示されたノード名が、最終的な出口ノードとは限りません。グループを階層ごとに開き、DIRECT、REJECT、または無効になった子グループが誤って選択されていないことを確認してください。
遅延の数値だけを見ない
遅延テストは通常、設定されたテストURLへアクセスします。80msや200msと表示されても、その時点でテスト先から応答があったことしか分かりません。対象サイトへの接続は、TLSハンドシェイク、回線混雑、サーバー側のレート制限、UDP対応の違いによって失敗する場合があります。既知の安定したノードを手動で選び、異なる2つのドメインへ続けてアクセスしてから、接続ログを確認してください。
- 遅延が「タイムアウト」になる：まず異なる地域のノードを2つ切り替え、単一ノードの障害かどうかを確認します。
- すべてのノードが同時にタイムアウトする：端末の基本ネットワーク、サブスクリプションの有効期限、ノードサーバーのドメイン名前解決を確認します。
- 遅延は正常なのにウェブページを開けない：ルール判定、DNS、TLSのエラーを確認し、速度テストを何度も繰り返さないでください。
- UDPを使うアプリだけ失敗する：ノードのプロトコルまたはサーバー側で利用可能なUDP転送が提供されていないか、TUN設定でUDPが引き込まれていない可能性があります。
サブスクリプションを再取得し、更新時刻を確認する
サブスクリプションの期限切れは、必ずしも「インポート失敗」と表示されるとは限りません。クライアントが古い設定を保持し、画面にノード一覧を表示し続けることもあります。「設定」→「サブスクリプション」または「Profiles」画面を開き、手動で更新して更新後の時刻とレスポンスを記録します。ステータスコードが401または403なら、サブスクリプションの権限を確認してください。タイムアウトする場合は、まず直接接続でサブスクリプションのドメインを開きます。レスポンスを解析できない場合は、ログインページ、案内ページ、または互換性のない形式のテキストを取得している可能性があります。
更新後は、一覧にある同名の古いコピーではなく、新しい設定が有効になっていることを確認します。デスクトップクライアントによっては、設定一覧でもう一度クリックして有効化する必要があります。設定でproviderを使用している場合は、providerの更新時刻も確認してください。メイン設定の更新に成功しても、リモートのノード一覧まで同期されたとは限りません。
ステップ2：ローカルプロキシポートとシステムプロキシを確認する
デスクトップ版で最もよくある断点は、コアが待ち受けるポートと、OSやブラウザーが指定するポートが異なっていることです。一般的な設定では、HTTPポートに7890、SOCKS5ポートに7891を使うか、7890などのmixed-portだけを有効にします。ポート番号は固定規格ではないため、現在の設定とクライアントの設定画面に表示された値を必ず確認してください。
ブラウザーを介さず、まずローカルポートを直接テストする
Windows PowerShell、macOSのターミナル、Linux shellでは、curlにプロキシを指定してテストできます。ここではmixed-portが7890だと仮定します。
curl -I --max-time 10 -x http://127.0.0.1:7890 https://example.com
curl -I --max-time 10 --proxy socks5h://127.0.0.1:7891 https://example.comHTTPレスポンスヘッダーが返れば、アプリからローカルプロキシ、プロキシから対象サイトまでの基本経路はつながっています。すぐに「Connection refused」と表示される場合は、ポートが待ち受けていないか、ポート番号が間違っています。10秒待ってタイムアウトする場合は、ノードとDNSを確認してください。HTTPプロキシは成功するのにSOCKS5が失敗する場合は、socks-portが本当に有効か設定を確認します。
ネットワークが正常なら、ローカルプロキシへのリクエストは通常0.2～3秒でレスポンスヘッダーを返します。これはノード品質の基準ではありませんが、毎回10秒でタイムアウトするなら、ブラウザーの復旧を待つのではなくコアのログを確認してください。
システムで実際に使われているプロキシアドレスを確認する
- Windows 11 24H2：「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」のアドレスとポートを確認します。一般的なアドレスは127.0.0.1で、ポートはクライアントと一致している必要があります。
- macOS 15：「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」を開き、WebプロキシとセキュアWebプロキシを確認します。クライアントが自動管理している場合は、別のポートを手動で追加しないでください。
- Android 15：Clash系クライアントは通常、システムVPNインターフェースで通信を引き込むため、Wi-Fiの手動プロキシに127.0.0.1を入力する必要はありません。
- ブラウザー：プロキシ拡張機能が同時に有効になっていないことを確認します。拡張機能が古いポートを指定していると、システムプロキシが上書きされたり迂回されたりします。
システムプロキシを無効にすると直接接続できるのに、有効にした途端すべてのリクエストが失敗する場合、断点はローカルプロキシポートの後ろにある可能性が高いです。ログに接続拒否、ハンドシェイクのタイムアウト、プロキシグループが見つからないといった記録がないか確認します。システムプロキシを無効にしてもどのサイトにもアクセスできない場合は、Clashの調整を続ける前に、Wi-Fi、LANケーブル、ゲートウェイ、システムDNSを修復してください。
ステップ3：DNSの問題をプロキシの問題から切り分ける
「IPには接続できるが、ドメインには接続できない」は、典型的なDNSの手がかりです。Clash Meta、つまり現在よく使われているmihomoコアは、ローカルでドメイン解決、ルール判定、Fake-IPマッピングを実行できます。DNSハイジャック、上流DNSへの到達、Fake-IP通信の引き込みのいずれかが欠けるだけで、ブラウザーが読み込み中のままになったり、一部のアプリでネットワーク利用不可と表示されたりします。
まずドメインが応答を返すか確認する
ターミナルでシステムの名前解決をテストします。Windowsではnslookup example.com、macOSとLinuxではdig example.comを使用できます。Fake-IPモードを使用している場合、198.18.0.0/16の範囲のマッピングアドレスが返るのは正常なことがあります。このアドレスは引き続きmihomoに入り、コアがドメインを復元してルールを適用します。198.18.x.xが表示されても、すぐに名前解決エラーと判断しないでください。
本当に注目すべきなのは、クエリが継続的にタイムアウトする、SERVFAILが返る、またはシステムがFake-IPを取得した後に通信がTUNへ入っていないケースです。TUNを無効にした後もシステムにFake-IPが残っていると、ウェブページに一時的にアクセスできなくなることがあります。まずプロキシを停止し、システムのDNSキャッシュを更新してから、コアとTUNを再起動してください。
設定内のDNS構成を確認する
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://1.1.1.1/dns-query
fallback:
- tls://8.8.8.8:853この例はフィールドの関係を示すもので、既存のサブスクリプションを無条件に上書きするためのものではありません。ポート1053は、よく使われるローカル待ち受け値の一例です。トラブルシューティングでは、dns.enableが有効であること、待ち受けポートをほかのプログラムが使用していないこと、上流アドレスに現在のネットワークから到達できることを確認してください。ドメイン形式のDoHサービスを参照する設定では、そのドメインを解決するbootstrap経路も機能している必要があります。「DNSサーバーのドメイン解決に同じDNSサーバーを依存する」という循環を避けてください。
ログにDNS timeoutが継続して記録される場合は、設定提供元が推奨する別の上流DNSへ一時的に切り替えて比較します。nameserverだけを変更し、ノード、ルール、TUNはそのままにしてください。切り替え直後に復旧すれば、問題は元の上流DNSまたはその経路に集中しています。それでも失敗する場合は、53番ポートのハイジャック、ファイアウォール、TUNルートを確認します。
ステップ4：TUN、システムプロキシ、ほかのVPNの競合を切り分ける
システムプロキシの影響を受けるのは、主にプロキシ設定を自動的に参照するアプリです。ゲーム、コマンドラインプログラム、一部のストアアプリ、UDP通信はこれを無視することがあります。TUNモードは仮想ネットワークアダプターとルートを使ってより多くの通信を引き込みますが、企業VPN、仮想マシン、コンテナネットワーク、通信高速化ツール、セキュリティソフトとは競合しやすくなります。
スイッチの組み合わせで通信の引き込み層を特定する
- まずTUNを無効にし、システムプロキシだけを有効にします。ブラウザーと、前述のcurlコマンドでテストしてください。
- ブラウザーが復旧するなら、ノードとHTTPプロキシはおおむね正常で、問題はTUNルート、DNSハイジャック、権限に絞られます。
- 次にシステムプロキシを無効にし、TUNだけを有効にします。ブラウザーと、システムプロキシを参照しないアプリでテストしてください。
- それぞれ単独では正常なのに同時に有効にすると異常になる場合は、クライアントがルートを二重に設定していないか、DNSの引き込みが二重になっていないか確認します。
- 最後にクライアントが推奨する組み合わせへ戻します。設定ミスを解決せず、切り替えを繰り返して使い続けないでください。
mihomoのTUN設定でよく使われるフィールドには、enable、stack、auto-route、auto-detect-interface、dns-hijackがあります。利用できるstackの選択肢は、OSやクライアントによって異なります。現在gVisorで経路に問題がある場合は、クライアントが対応していればsystemへ切り替えて比較できます。変更後はシステムプロキシをオフ・オンするだけでなく、コアを完全に再起動してください。
WindowsでサービスモードまたはTUNを有効にすると、仮想ネットワークアダプターとルートの書き込みに適切な権限が必要です。「設定」→「ネットワークとインターネット」→「ネットワークの詳細設定」で、仮想アダプターの状態を確認できます。macOSでは初回利用時に「システム設定」→「一般」→「ログイン項目と機能拡張」→「ネットワーク機能拡張」で関連する拡張機能を許可します。AndroidではステータスバーにVPNアイコンが表示されていることを確認し、システムのVPN画面で別の常駐VPNが唯一のインターフェースを占有していないか確認してください。
デフォルトのネットワークアダプター認識を確認する
ノートパソコンで有線ネットワークからWi-Fiへ切り替えたり、テザリングに接続したり、スリープから復帰したりすると、デフォルトの出口が変わることがあります。auto-detect-interfaceが現在のネットワークアダプターを正しく認識できないと、TUN通信が仮想インターフェースへ戻され、ルーティングループになる可能性があります。典型的には、TUNを有効にすると遅延テストがすべてタイムアウトし、無効にするとすぐ復旧します。まずコアを再起動してください。それでも復旧しない場合は、不要な仮想アダプターや古いVPNを切断してから、ネットワーク接続を再確立します。
ステップ5：ログでルール、ハンドシェイク、接続エラーを確認する
ここまでの4ステップで特定できない場合は、ログレベルを一時的にinfoまたはdebugへ変更します。一般的なクライアントでは、「設定」→「ログレベル」または「設定」→「パラメータ設定」→「コア」から設定できます。ログを開いたら失敗するリクエストを1回だけ再現し、すぐに該当ドメインの記録を確認してください。速度テストやバックグラウンド更新による無関係なログを大量に発生させないことが重要です。
次のログの手がかりを重点的に確認する
| ログの手がかり | 意味 | 次に行うこと |
|---|---|---|
| match DIRECT | リクエストがルールによって直接接続と判定された | ルールの順序、ルールセットの更新、対象ドメインを確認する |
| match REJECT | リクエストが拒否ルールにブロックされた | 広告ブロックまたはカスタムルールを確認する |
| connection refused | 対象ポートが接続を明示的に拒否した | ノードを切り替え、サーバー側のポートとプロトコルパラメータを確認する |
| i/o timeout | 接続または読み取りが制限時間を超えた | DNS、ノードサーバー、対象サイトのどこでタイムアウトしたかを切り分ける |
| no such host | ドメインの名前解決に失敗した | nameserver、ネットワーク権限、DNSハイジャックを確認する |
| TLS handshake timeout | TLSハンドシェイクが制限時間内に完了しなかった | 別のノードでテストし、時刻、MTU、回線品質を確認する |
ルールは上から順に照合され、通常は最初に一致した時点で停止します。カスタムのDOMAIN-SUFFIX、IP-CIDR、プロセスルールを汎用ルールより前に置くと、対象を誤ってDIRECTやREJECTへ送ることがあります。トラブルシューティングでは、一時的にグローバルモードを選び、利用可能なノードを指定します。グローバルモードで復旧するなら、ノードと基本的なプロキシ経路はおおむね正常で、問題はルールまたはproviderにある可能性が高いです。それでも失敗するなら、ノード、DNS、TUNを引き続き確認します。
グローバルモードは短時間の比較にのみ使い、最終的な修正として常用しないでください。原因を確認したらルールモードへ戻し、ルールセットの配布元、プロキシグループ名、カスタムオーバーライドを修正します。設定内のプロキシグループ名は、ルールからの参照と完全に一致している必要があります。大文字・小文字、空白、記号の違いだけでも、読み込みエラーやフォールバック動作が発生することがあります。
最後は決まった順序で再テストし、「たまたま直った」を避ける
変更を完了したら、まずコアを5秒間停止してから再起動します。その後、「ローカルネットワーク、DNS、ローカルプロキシポート、ノード、ルール、TUN」の順に確認します。1つのウェブページが開くかだけで判断せず、直接接続用とプロキシ用のドメイン、ブラウザーと非ブラウザーアプリ、Wi-Fi切り替え後の動作もテストしてください。
- Clashを終了し、基本ネットワークからローカルゲートウェイと直接接続サイトへアクセスできることを確認します。
- コアを起動し、設定の読み込みが完了していて、YAMLフィールドやproviderのエラーがないことを確認します。
- 127.0.0.1と現在のmixed-portを指定してcurlテストを実行します。
- サブスクリプションの更新時刻、現在のノード、最上位プロキシグループの選択を確認します。
- ドメインの名前解決結果とDNSログを確認し、正常なFake-IPと実際のタイムアウトを区別します。
- まずシステムプロキシで再テストし、次にTUNだけを有効にして、どの組み合わせで競合が起きるか確認します。
- ルールモードへ戻し、ログでリクエストが想定したプロキシへ振り分けられたことを確認します。
障害が会社、学校、ホテルのネットワークでだけ発生する場合は、そのネットワークがUDP、特定ポート、暗号化DNSを制限していないかも確認します。スマートフォンのテザリングで比較するのが最も効果的です。同じ端末、同じ設定がテザリングでは正常で元のネットワークでは失敗するなら、原因をLANの出口、認証ページ、ネットワークポリシーに絞り込めます。認証を完了してからClashを起動すれば、ホテルWi-Fiのログインページがプロキシルールにブロックされるのも防げます。
この手順の基本は、最短の経路を確認してから、通信を引き込む範囲を段階的に広げることです。ノード、DNS、システムプロキシ、TUNはいずれも似た「接続済みなのにインターネットに接続できない」状態を引き起こしますが、テスト結果は同じではありません。各手順のポート、時刻、ログ、スイッチの組み合わせを記録しておくと、クライアントを何度も再インストールするより早く本当の断点を見つけられます。