Clashは接続済みなのにインターネットに接続できない？8段階のトラブル対応チェックリスト

この種の障害は、ネットワーク経路を外側から内側へたどって確認するのが適しています。基本ネットワーク、リモートノード、端末の時刻、ルール選択、DNS、プロキシ入口、TUNの通信取り込み、最後に設定ファイルとカーネルログの順で調べます。各手順では変更する変数を1つに絞り、変更後すぐに再テストしてください。ノード変更、DNS変更、TUN有効化を同時に行うと、本当の原因を特定しにくくなります。

ステップ1：Clashを停止し、基本ネットワークを確認する

まずプロキシサービスを停止します。「ルール」から「直結」に切り替えるだけでは不十分です。Androidクライアントではメイン画面から稼働スイッチをオフにし、ステータスバーのVPN表示が消えたことを確認します。WindowsやmacOSでは「システムプロキシ」も無効にし、カーネル停止後もリクエストがローカルポートへ送られ続けないようにします。

Clashまたはmihomoカーネルを停止する。
システムプロキシとTUNモードを無効にする。
現在のWi-Fiをいったん切断して再接続するか、機内モードを一度オン・オフする。
以前開いたことのない通常のウェブページを開き、ブラウザキャッシュによる誤判定を避ける。
Wi-Fiとモバイルデータをそれぞれテストし、どちらで失敗するか記録する。

Clashを停止してもどのウェブページにもアクセスできない場合、問題は上流のネットワークにあります。Wi-Fiのポータル認証が完了していない、ルーターのDNS異常、モバイルデータの通信制限、現在のネットワークがLAN接続しか提供していない、といった原因が考えられます。公共Wi-Fiでは、まず通常のHTTPページを開いて認証ページを表示させてください。直結ネットワークが復旧して初めて、その後のプロキシ確認に意味があります。

ステップ2：ノードを切り替え、サブスクリプションとノードの可用性を切り分ける

サブスクリプションを更新できても、含まれるすべてのノードが接続できるとは限りません。サブスクリプションの取得は通常1回のHTTPSリクエストですが、プロキシ通信にはドメイン解決、TCPまたはUDPハンドシェイク、TLS時刻検証、プロトコルパラメータ、リモートサービスの状態が関係します。

まず遅延を測定し、その後に実際のアクセスを試す

「プロキシ」または「Proxies」ページで現在のプロキシグループを開き、少なくとも3つの異なる回線で遅延テストを実行します。テスト先は通常、設定内の url で指定されます。例：https://www.gstatic.com/generate_204。結果は次のように判断できます。

80–300 ms：少なくとも今回のテストリクエストは完了していますが、すべてのウェブサイトにアクセスできるとは限りません。
800 ms超：回線の混雑、迂回経路、パケットロスが目立ち、実際のアクセスでも頻繁にタイムアウトする可能性があります。
timeout：テスト時間内にリクエストが完了していません。まずノードを切り替えてください。
0 ms、空白、または即時失敗：テスト先、DNS、権限、カーネル状態に異常がある可能性があります。

同じ自動選択グループ内で何度もクリックするだけでは不十分です。異なる地域、異なるサーバー名のノードを2つ手動で選び、それぞれでウェブページにアクセスしてください。1つのノードだけ使えて他が失敗するなら、原因は回線側に絞られており、クライアントを再インストールする必要はありません。すべてのノードが同時にタイムアウトする場合は、端末の時刻とDNSを確認します。

プロキシグループがDIRECTやREJECTになっていないか確認する

設定によっては、メインの選択グループが「ノード選択」「Proxy」など別の名前になっています。そのグループを開き、現在の選択項目が DIRECT、REJECT、または無効になった下位プロキシグループではないことを確認します。自動プロキシグループには前回のテスト結果が残る場合があるため、手動で切り替えた後、約 5–10 秒 待ってから再テストしてください。

ステップ3：システム時刻とタイムゾーンを調整する

TLS証明書の検証には正確なシステム時刻が必要です。端末の日付が数時間または数日ずれていると、ノードのハンドシェイク、サブスクリプション更新、HTTPSページへのアクセスが失敗することがあります。ログには certificate has expired、not yet valid、TLS handshake failed などがよく表示されます。

Androidでは「設定」→「システム」→「日付と時刻」を開き、「日時を自動設定」と「タイムゾーンを自動設定」をオンにします。一部メーカーの端末では「設定」→「その他の設定」→「日付と時刻」にあります。有効化後、通信事業者またはネットワークとの時刻同期を待ち、Clashを完全に停止してから再起動してください。

デスクトップOSでも時刻同期を確認します。Windowsでは「設定」→「時刻と言語」→「日付と時刻」から「今すぐ同期」を実行できます。タイムゾーンは現在地に合わせます。中国標準時なら通常 UTC+08:00 と表示されます。時計を手動でおおよそ合わせるだけでは同期完了とはいえません。数分のずれでも、一部の短期間有効な証明書や認証リクエストに影響することがあります。

ステップ4：プロキシモードを切り替え、ルールの一致問題を特定する

Clashの代表的なモードには rule、global、direct があります。ルールモードでは設定ファイルの rules を上から順に照合し、一致した通信を指定のプロキシグループへ渡します。ルールの順序ミス、プロキシグループ名の変更、末尾ルールの欠落により、特定のウェブサイトだけアクセスできなくなることがあります。

短時間だけグローバルモードで比較する

現在のモードと選択中のノードを記録する。
モードを「ルール」から「グローバル」に切り替える。
グローバルのプロキシグループで、遅延が正常なノードを1つ手動選択する。
対象のウェブページを新しく開く。古いタブを更新するだけにしない。
テスト後は「ルール」に戻し、プロキシの適用範囲を長時間広げないようにする。

グローバルモードではアクセスできるのにルールモードではアクセスできない場合、ノードと基本接続はおそらく正常で、問題はルールまたはプロキシグループにあります。「接続」ログを開き、対象ドメインに対応する Rule、Rule Payload、Chains を確認してください。対象通信が DIRECT に送られているなら、ドメインルールが、より上位の直結ルールに上書きされていないか確認します。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ルールは上から順に実行され、最初に一致した項目が適用されます。末尾には通常、MATCH,PROXY のようなフォールバックルールが必要です。実際のプロキシグループ名は、proxy-groups 内の名称と大文字・小文字や空白を含めて完全に一致していなければなりません。サブスクリプションで生成された設定を広範囲に直接書き換えるのは避け、クライアントの上書き機能を優先し、元のサブスクリプションを戻せるよう保存しておきます。

ステップ5：DNS解決とFake-IPマッピングを確認する

ウェブページにサーバーが見つからないと表示される、ノードの速度テストがすべて失敗する、IPアドレスにはアクセスできるのにドメイン名ではアクセスできない場合は、DNSを重点的に確認します。Clash Meta、つまりmihomoカーネルでは、fake-ip または redir-host がよく使われます。Fake-IPはまずアプリにマッピング用アドレスを返し、カーネルがその対応関係をもとに実際のドメインを処理するため、DNSリクエストが確実にClashへ入る必要があります。

キャッシュを消去してからDNS経路を再起動する

Clashを停止し、約 5 秒 待つ。
Androidで機内モードを一度オン・オフするか、Wi-Fiを切断して再接続する。
ブラウザのDNSキャッシュを消去する。最も簡単なのは、ブラウザを完全に終了してから再起動する方法です。
Clashを再起動し、これまでテストしていないドメインにアクセスする。

Androidの「プライベートDNS」によって解決経路が変わることもあります。「設定」→「ネットワークとインターネット」→「プライベートDNS」を開き、一時的に「自動」に変更して比較します。メーカーによっては「設定」→「接続と共有」→「プライベートDNS」にあります。指定した暗号化DNSホストに現在のネットワークから到達できない場合、アプリは解決結果を長時間待ち続けることがあります。

設定内のDNS関連項目を確認する

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853

listen ポートが他のプログラムに使用されていないことを確認します。上記の 1053 は一般的な例にすぎず、実際の設定は異なる場合があります。ログに address already in use と出るなら、ポートが競合しています。暗号化DNSアドレスは、ネットワークが対応ポートを許可しているかにも左右されます。DoTは通常 853、DoHは通常 443 を使用します。

ステップ6：システムプロキシのアドレス、ポート、待受状態を確認する

デスクトップ版でよくあるのは、Clashカーネルは正常に動作しているのに、システムプロキシが古いポートを指しているケースです。代表的な混合ポートは 7890、SOCKSポートは 7891 ですが、サブスクリプションやクライアントで変更できるため、初期値だけで判断してはいけません。

クライアントの「設定」→「パラメータ設定」または「General」ページを開き、mixed-port、port、socks-port を記録します。次に、OSのプロキシ設定が 127.0.0.1 と同じポートを指しているか確認します。クライアントがSOCKSだけを待ち受けているのに、システムHTTPプロキシへそのポートを入力していると、一部のプログラムは直ちに接続に失敗します。

ターミナルから明示的なプロキシリクエストを送れば、システムプロキシ設定を介さずにローカル入口が動作しているか確認できます。以下は混合ポートが 7890 である場合の例です。

curl -I --connect-timeout 10 \
  -x http://127.0.0.1:7890 \
  https://example.com

明示的なプロキシリクエストは成功するのにブラウザだけ失敗するなら、問題は主にシステムプロキシまたはブラウザ自身の設定にあります。コマンドを実行するとすぐ「connection refused」が返る場合は、該当ポートで待ち受けていません。カーネルの起動状態とポート変更の有無を確認します。リクエストが止まったまま最終的にタイムアウトする場合、ローカルポートは正常でも、ノード、DNS、または外向き接続に問題が残っている可能性があります。

ブラウザは使えるのにターミナルコマンドが使えない場合も、Clashの障害とは限りません。多くのコマンドラインプログラムはOSのプロキシ設定を自動的に読み取らないため、HTTP_PROXY、HTTPS_PROXY を設定するか、コマンド引数でプロキシを明示する必要があります。

ステップ7：TUNモード、VPN権限、アプリの競合を確認する

Android版Clashは通常、システムの VpnService を使ってローカルVPNインターフェースを作成します。接続リクエストが許可されても、インターフェースを作成できることを示すだけです。システムが権限を取り消した、省電力機能がバックグラウンドサービスを終了した、別のVPNアプリがインターフェースを使用している、といった場合、画面上は一時的に稼働中のままでも通信を正常に転送できなくなります。

他のVPN、ネットワークフィルタリング、ファイアウォールアプリを停止する。
AndroidのVPN設定で古い接続を切断する。
Clashに戻り、サービスを再起動してシステムの接続リクエストを確認する。
まずTUNを無効にし、クライアント標準のVPN取り込み方式だけでテストする。
デスクトップでは逆に、システムプロキシが使えることを確認してから、プロキシ設定を読み取らないプログラム向けにTUNを有効にしてテストする。

デスクトップのTUNモードでは仮想ネットワークアダプターを作成し、ルーティングを調整する必要があります。mihomoでよく使われるパラメータには stack: mixed、auto-route: true、auto-detect-interface: true があります。有線ネットワーク、Wi-Fi、仮想マシンのアダプター、企業VPNを同時に接続していると、自動的な出口インターフェースの判定を誤ることがあります。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

トラブル対応では、まずTUNを無効にしてシステムプロキシを使い、HTTPとHTTPSが復旧するか確認します。システムプロキシは正常で、TUNを有効にすると失敗する場合は、ルート作成、仮想ネットワークアダプターの権限、デフォルトゲートウェイ、他のVPNとの競合を重点的に確認します。「TUNを有効にする」ことを、あらゆる接続問題の万能な解決策と考えてはいけません。TUNが解決するのは通信を取り込む範囲であり、無効なノードや誤ったDNSを修復するものではありません。

ステップ8：ログを読み、設定を戻してサブスクリプションを再インポートする

最初の7段階で特定できない場合に、設定の整合性と稼働ログを確認します。まずログレベルを info に設定し、障害を1回再現してすぐ最新の記録を確認してください。情報が足りない場合だけ短時間 debug を使います。詳細ログは増加が速く、重要なエラーを絞り込みにくくなるためです。

ログ抜粋	優先して確認する項目
`i/o timeout`	ノードに到達できない、パケットロス、外向き通信の遮断
`connection refused`	対象ポートが待ち受けていない、またはリモートサービスが接続を拒否している
`no such host`	DNS解決の失敗、上流DNSに到達できない
`address already in use`	ローカルプロキシポートまたはDNSポートの競合
`authentication failed`	ノードの認証情報、UUID、パスワード、サブスクリプション内容の失効
`certificate` 関連のエラー	システム時刻、証明書チェーン、TLSパラメータ

サブスクリプション更新後に問題が発生した場合は、まず更新前に使えていたローカル設定へ切り替えます。複数の設定がある場合、現在有効なProfileが先ほど確認したものと同じか確認してください。その後サブスクリプションを再取得し、更新日時と設定の解析結果を確認します。解析に失敗した場合は読み込み途中の状態を使い続けず、古い設定へ戻すか、サブスクリプション提供元に設定形式を確認してください。

手動の上書き設定も頻出する障害原因です。dns、rules、proxy-groups、tun、ポート関連の項目を重点的に確認します。YAMLはインデントに敏感なため、空白で階層を統一してください。存在しないノード名をプロキシグループが参照している、存在しないプロキシグループをルールが指定している、同じポートを重複定義している、といった状態は起動失敗や一部機能の停止につながります。

最後に行う最小構成での復旧手順

現在の設定名、ポート、重要な上書き項目をエクスポートまたは記録する。
TUN、プライベートDNS、ブラウザ独自のDNSを無効にする。
解析できることを確認したサブスクリプション設定をインポートする。
遅延が正常なノードを1つ選択する。
まずグローバルモードでテストし、その後ルールモードに戻す。
基本プロキシが復旧したら、DNSの上書きとTUNを1項目ずつ再有効化する。

再テストの基準：ウェブページを1回更新するだけにしない

修復後は少なくとも3種類のテストを行います。1つ目は異なるドメインのHTTPSページを2つ開くこと。2つ目はWi-Fiとモバイルデータを一度切り替え、ネットワーク変更後もサービスが再構築できることを確認すること。3つ目は「接続」ログで、対象ドメインが想定したルールとノードに一致しているか確認することです。速度テストが一度成功しただけでは、その時点でテスト先にアクセスできたことしか分かりません。

Androidではさらに、画面をロックして約 3–5 分 待ってからロックを解除し、ウェブページにアクセスします。画面ロック後だけ通信が切れるなら、ノードプロトコルを変更し続けるのではなく、バックグラウンド実行権限、バッテリー最適化、メーカー独自の省電力機能を確認します。デスクトップではブラウザまたはターミナルを再起動し、古いプロキシ接続とDNSキャッシュが解放されたことを確認します。

完全なトラブル対応の目的は、ステータスボタンを再び「接続済み」にすることではありません。端末が基本ネットワークを取得し、DNSが解決し、通信が正しいプロキシ入口へ入り、ルールが想定したプロキシグループを選択し、ノードが外向き接続を確立し、返ってきたデータが同じ経路でアプリに渡るという、再現可能な通信経路を確認することです。この経路を層ごとに検証すれば、通常は8段階以内に問題を明確な範囲まで絞り込めます。