Clashは接続済みなのにネットに繋がらない？上から順に確認するトラブルシューティング

Clashの「接続済み」は、通常、iOSのネットワーク拡張機能やTUNインターフェース、ローカルプロキシが起動していることを示すだけです。この状態だけでは、サブスクリプションが有効か、現在のプロキシグループが利用可能なノードを選択しているかまでは分かりません。リクエストはDNS解決、ルール判定、プロキシグループ、リモートノードを順に通過するため、どこか1つでも失敗すると、Safariの読み込みが終わらない、アプリにネットワークエラーが表示される、一部のサイトだけ開けないといった症状になります。

トラブルシューティングでは、複数の設定を続けて変更しないでください。まず現在の設定名とモードを記録し、1つの手順を終えるたびに同じWebページで再テストします。最初にSafariで http://captive.apple.com/hotspot-detect.html を開くのがおすすめです。正常なら通常「Success」と表示されます。次に、普段利用するHTTPSサイトへアクセスします。HTTPとHTTPSを分けてテストすると、ネットワーク入口、DNS、TLS、プロキシ経路の問題を初期段階で切り分けられます。

ステップ1：Clashを有効にした後だけ起きる問題か確認する

オフとオンの状態を比較する

現在のWi-Fiまたはモバイル通信を変えずに、Clashのプロキシスイッチをオフにします。
Safariで、先ほど開けなかったサイトを2つ開き、1回更新します。
Clashを再びオンにし、状態が安定するまで5秒待ってから同じアドレスにアクセスします。
「オフでは正常、オンにすると失敗」なのか、どちらの状態でも失敗するのかを記録します。

Clashをオフにしてもアクセスできない場合、原因はローカルネットワーク、通信事業者の接続、またはサイト側にある可能性が高いです。機内モード、Wi-Fiのログインページ、モバイルデータ通信の権限を確認してください。公衆Wi-Fiでは認証が必要なことがよくあります。その場合は一時的にClashをオフにし、任意のHTTPページを開いてログインページを表示し、認証後にプロキシをオンにします。

オフでは正常で、オンにするとすぐ失敗する場合は、この記事の順番に沿って確認を続けます。特定のアプリだけが失敗する場合は、iOSの「設定」→「モバイル通信」を開き、そのアプリとClashクライアントにモバイルデータ通信の権限があることを確認してください。アプリがWi-Fi接続時のみ動作する設定になっていないか、現在のWi-Fiに再認証が必要なポータルがないかも確認します。

比較結果	優先して確認	後回しにする項目
オフでもオンでも失敗	Wi-Fi認証、モバイルデータ通信、システムネットワーク	ルールとプロキシグループ
オフでは正常、オンで失敗	ノード、ルール、DNS、VPN状態	ルーターのリセット
Webページは正常、特定のアプリだけ失敗	アプリの権限、ルール判定、UDP対応	設定全体の削除
ドメインは失敗、一部のIPには到達できる	DNS設定とDNSハイジャック	ノードを頻繁に切り替える

ステップ2：サブスクリプションが有効で、完全に更新されているか確認する

サブスクリプションがクライアントに表示されていても、配布URLから現在も読み込めるとは限りません。サービスの期限切れ、サブスクリプションURLの無効化、サーバーからのログインページの返却、更新中の通信断などにより、クライアントが古い設定を保持し続けることがあります。古いノードがすべて使えなくなると、画面にはプロキシグループや「接続済み」が表示されても、実際の接続はタイムアウトします。

更新日時と更新結果を確認する

クライアントの設定またはサブスクリプション画面を開き、想定している設定が有効になっていることを確認します。以前に取り込んだローカルコピーになっていないかも確認してください。
最終更新日時を確認します。サブスクリプション提供元がノードを変更したのに、ローカルの更新日時が数日前のままなら、手動で1回更新します。
更新後、プロキシグループにノードが残っていることを確認します。グループ名だけが表示され、選択できるノードがない場合は、サブスクリプションの内容が空、または解析に失敗している可能性があります。
HTTP 401 または 403 が表示されたら、サブスクリプションの権限とURLを確認します。404 の場合は、サブスクリプションURLを再取得する必要があります。5xx の場合は、サーバーが復旧してから再試行してください。

サブスクリプションを更新する前に、古い設定を削除しないでください。より安全なのは、古い設定を残したまま新しい設定スロットを作り、更新後のURLを取り込む方法です。正常に読み込めることを確認してから切り替えます。新しいサブスクリプションに互換性のない項目が含まれていても、すぐに元の設定へ戻して差分を確認できます。

ステップ3：プロキシグループが利用可能なノードを選択しているか確認する

Clashの設定でよく使われるプロキシグループには、select、url-test、fallback、load-balance があります。select は手動選択が必要です。自動テストグループは、テストURL、テスト間隔、ノードへの到達性に左右されます。グループ内にノード名が表示されていても、設定が読み込まれただけで、ノードとのハンドシェイクが成功したことを意味しません。

自動テストの影響を避けるため、まず手動選択を使う

プロキシグループ画面を開き、ルールが最終的に参照しているメインのプロキシグループを探します。たとえば「ノード選択」や「PROXY」です。
下位の地域グループだけを切り替えないでください。最上位のメイングループが DIRECT、REJECT、または無効な自動グループになっていないことを確認します。
明確な単一ノードを手動で選択し、異なる地域のノードを2～3個続けてテストします。
切り替えるたびに3～5秒待ってからWebページを開き直します。古い接続が再利用され、誤判定するのを避けるためです。

遅延テストで分かるのは、その時点でテストURLに到達できるかどうかだけです。80msと表示されたノードでも、目的のサイトにはアクセスできないことがあります。UDP非対応、TLSハンドシェイクの異常、出口側の制限なども考えられます。逆に、テストがタイムアウトしても、テスト先がブロックされているだけで、ノード自体は他のサイトへアクセスできる場合があります。遅延の数値だけで判断せず、実際のWebページの結果と接続ログを併せて確認してください。

よくある接続エラーを見分ける

ログまたは症状	主な原因	対処法
`i/o timeout`	ノードアドレスに到達できない、ポートが遮断されている、または経路がタイムアウトしている	ノードを切り替え、Wi-Fiとモバイル通信で結果を比較する
`connection refused`	リモート側のポートが待ち受けていない、またはノードが停止している	サブスクリプションを更新し、そのノードを無効にする
`TLS handshake timeout`	経路のパケットロス、SNI、またはサーバー側TLSの異常	ノードを変更し、システム時刻を確認する
速度テストは正常なのにWebページがタイムアウトする	ルールが誤ったプロキシグループを選んでいる、または接続先が出口IPを制限している	そのリクエストのルール判定ログを確認する

ステップ4：モードとルール判定を確認する

ルールモードでは、リクエストは上から順に照合され、マッチすると後続のルールは確認されません。範囲が広すぎる DOMAIN-SUFFIX、IP-CIDR、GEOIP ルールによって、目的のリクエストが誤ったプロキシグループへ送られることがあります。最後の MATCH または FINAL も、実在し利用可能なグループを指している必要があります。

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

モードを「ルール」から一時的に「グローバル」へ切り替え、グローバル用プロキシとして確認済みのノードを選択します。Webページが復旧した場合、ノードと基本的なプロキシ経路はおおむね正常で、問題はルール判定またはプロキシグループの参照に絞られます。グローバルモードでも失敗する場合は、ノード、DNS、システムVPNの層に戻って確認します。

グローバルモードは切り分け用であり、最終的な修正として使うものではありません。原因を確認したらルールモードに戻し、接続ログで失敗したドメインに対応するプロキシとルールを探します。たとえばログでリクエストが DIRECT にマッチしていても、現在のネットワークからその接続先へ直接アクセスできないなら、ルールの順番を調整するかルールセットを変更します。空のプロキシグループにマッチしている場合は、設定内のグループ名の参照を修正します。

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

上のルールでは、example.com とそのサブドメインをまず PROXY に送り、次にGEOIP CNに該当する接続先を直接接続し、それ以外のリクエストを PROXY に送ります。対象ドメインのルールより前に範囲の広い直接接続ルールを置くと、後続のルールはマッチする機会を失います。

ステップ5：DNS障害とプロキシ障害を切り分ける

DNS障害では、ドメインを開けない、アプリにサーバーが見つからないと表示されるといった症状が典型的です。一方で、既存の接続や固定アドレスを使う一部のサービスは動作することがあります。Clash Meta（mihomo）でよく使われる拡張モードには fake-ip と redir-host があります。iOSのTUNまたはネットワーク拡張機能の環境では、DNSリクエストがシステムの暗号化DNS、他のVPN設定、LAN側のDNSハイジャックの影響を受けることもあります。

まずログに名前解決エラーがないか確認する

no such host は通常、ドメイン名の解決に失敗したことを示します。
context deadline exceeded は、上流DNSのタイムアウト、または上流へのリクエストが利用できないプロキシグループを経由しようとしている可能性があります。
LAN内のドメインだけが失敗する場合は、192.168.1.1 など、ルーターのDNSで名前解決する必要がないか確認します。
ネットワークを切り替えると復旧する場合、元のWi-FiでDNS、認証状態、またはUDP通信が制限されている可能性があります。

クライアントに「設定」→「パラメータ設定」→「DNS」のような項目がある場合は、現在の値を記録してから、DNSが有効か、拡張モードが設定と一致しているか、上流アドレスの形式が完全かを確認します。メニュー名はクライアントによって異なります。設定がサブスクリプションで管理されている場合は、次回の更新で上書きされないよう、まず独立したコピーを編集してください。

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

1053 はリスニングポートの例であり、他のローカルDNSサービスと競合させないでください。従来のDNSではUDPまたはTCPの53番ポート、DNS over TLSでは853番ポートが一般的です。サブスクリプションの構成を理解しないまま、nameserver、fallback、proxy-server-nameserver、fake IPの範囲を同時に変更しないでください。まず到達可能な上流DNSを1つだけ置き換えて再テストし、どの変更が有効だったのか確認します。

iPhoneに独立した暗号化DNSの構成プロファイルをインストールしている場合は、「設定」→「一般」→「VPNとデバイス管理」を確認します。切り分け中は、他のDNSまたはVPN設定を一時的に無効にし、現在のClashネットワーク拡張機能だけを残してください。テスト後に元の設定へ戻します。

ステップ6：iOSのVPNとTUNの状態を確認する

iOSでは通常、同時に1つの主要なVPNトンネルだけが通信を引き継ぎます。企業VPN、他のプロキシクライアント、コンテンツフィルタ、セキュリティアプリがClashのネットワーク拡張機能と競合することがあります。ステータスバーにVPNマークが表示されても、VPN設定のいずれかが有効だと分かるだけで、どの設定が実際に使われているかまでは判断できません。

システム設定で現在の構成を確認する

「設定」→「一般」→「VPNとデバイス管理」→「VPN」を開きます。
現在接続されている項目が、使用中のClashクライアントに属していることを確認します。
他のVPNを切断し、他のプロキシクライアントのオンデマンド接続を無効にします。
Clashに戻り、まずプロキシをオフにして5秒待ち、その後もう一度オンにします。
接続状態のまま進まない場合は、iPhoneを再起動し、他のネットワークツールを同時に起動せずClashだけを開始します。

TUNモードでは、クライアントが仮想ネットワークインターフェースを作成し、対象の通信を引き継ぐ必要があります。設定のルート除外が広すぎるとリクエストがTUNを迂回し、狭すぎるとLAN機器へのアクセスに影響することがあります。プリンター、NAS、ルーターの管理画面だけ開けない場合は、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 などのLANアドレスを直接接続として残しているか確認します。

問題がモバイル通信時だけ起きる場合は、「設定」→「モバイル通信」を開き、Clashクライアントがモバイルデータ通信を利用できることを確認します。デュアルSIM端末では、現在のデータ回線が正常に登録されているかも確認してください。SIMのデータ回線を切り替えた後は、いったんVPNを切断して再接続し、ネットワーク拡張機能に新しいデフォルトルートを取得させます。

ステップ7：ログで障害の発生箇所を特定する

ここまでの比較を終えると、ログによって問題を明確な段階まで絞り込めます。クライアントの接続またはログ画面を開き、古い記録を消去してから、テスト用ドメインを1つだけ開きます。時刻、ドメイン、マッチしたルール、プロキシグループ、ノード名、最終エラーを記録してください。複数のアプリを同時に開くとバックグラウンド通信で目的の記録が埋もれてしまいます。

リクエストの段階ごとにログを読む

リクエストの記録がまったくない：通信がClashに入っていない可能性があります。VPN設定、TUNの状態、アプリのネットワーク権限を確認してください。
ドメインはあるが解決できない：上流DNS、暗号化DNSの設定、DNS関連のログを確認してください。
ルール判定が表示されている：マッチしたプロキシグループが想定どおりか確認してください。
ノードを選択済みなのに接続がタイムアウトする：ノードとネットワークを切り替え、ノードの停止なのか現在の経路による遮断なのかを判断します。
TCP接続後にTLSエラーが発生する：システム時刻、対象ドメイン、ノード経路、証明書の警告を確認し、出所不明の証明書をそのまま受け入れないでください。

クライアントがログレベルに対応している場合、切り分け中だけ info から debug に変更し、1回再現したらすぐ元に戻します。debugを使い続けると記録が大量に増え、重要なエラーを見つけにくくなります。問い合わせ時は、サブスクリプションURL、認証情報、ノードのパスワード、個人用ドメインを隠し、エラーの種類と必要な前後関係だけを残してください。

最終チェック：結果に応じて次の手順を決める

Clashをオフにしてもネットに繋がらない：まずWi-Fiのログイン、モバイルデータ通信の権限、システムネットワークを確認します。
サブスクリプションの更新でエラーが出る：権限、返却内容、設定形式を確認します。
手動ノードは使えるが自動グループは使えない：テストURL、グループタイプ、テスト間隔を確認します。
グローバルモードは使えるがルールモードは使えない：リクエストの判定を確認し、ルールの順番を調整します。
ドメインに接続できず、ログに名前解決のタイムアウトがある：上流DNSとシステムの暗号化DNSを確認します。
ログにリクエストがない：iOSで現在使われているVPN設定と、TUNが実際に通信を引き継いでいるか確認します。
Wi-Fiでは失敗し、モバイル通信では正常：公衆ネットワークの認証、ルーターのDNS、ポート制限を確認します。
すべてのノードが接続タイムアウトになる：サブスクリプションを更新し、ノードサービス提供元に経路の状態を確認します。

最も効率的な順番は、まずオフとオンを比較し、次にサブスクリプションとノードを確認してから、ルール、DNS、最後にシステムVPNを調べることです。各手順では1つの変数だけを変更し、同じサイトで再テストしてください。これにより、ノード障害をDNSの問題と誤認したり、設定を一度にすべてリセットして再現可能な手がかりを失ったりするのを防げます。