Clash クライアントに「接続済み」と表示されていても、コアが起動した、システムプロキシが有効になった、またはVPNインターフェースが作成されたというだけの場合があります。目的のサイトにアクセスできることを意味するわけではありません。ノードの遅延時間が表示されても、確認用のリクエストが一度完了したことしか分かりません。原因を調べるには、通信経路を分けて確認します。アプリがプロキシを経由しているか、ルールで正しい経路が選ばれているか、ノードに接続できるか、ドメイン名が正しく名前解決されているかを確認しましょう。

01｜まずネットワークと障害の範囲を確認

システムプロキシとTUNをオフにして、普段プロキシなしで開けるサイトにアクセスします。それでも失敗する場合は、Wi-Fi、有線LAN、ルーター、回線事業者、学校のネットワーク認証などを先に確認してください。この段階でサブスクリプションを何度更新しても、通常は解決しません。ホテルや空港などのネットワークでは、先にブラウザーでポータル認証が必要な場合があります。プロキシを有効にすると、認証ページにたどり着きにくくなることもあります。

  1. よく使う日本国内のサイトと、もともと開けなかったサイトをそれぞれテストし、すべて失敗するのか一部だけなのかを記録します。
  2. 現在のネットワークをスマートフォンのテザリングに切り替え、同じクライアント、設定、ノードでテストします。テザリングでは正常で元のネットワークでは失敗する場合は、元のネットワーク側の制限を優先して調べます。
  3. システムの日付、時刻、タイムゾーンが正しいことを確認します。時刻が大きくずれていると、TLS証明書の有効期間エラーが発生することがあります。

pingだけでサイトが利用できるかを判断しないでください。接続先がICMPを拒否していても、ブラウザーはTCP 443やQUICで正常に通信できる場合があります。逆に、IPアドレスにpingが通っても、HTTPS、証明書、プロキシ経路が正常とは限りません。

02｜サブスクリプションの有効期限と設定の読み込みを確認

クライアントの「サブスクリプション」または「設定」画面を開き、現在のサブスクリプションを手動で更新して、更新ログを確認します。ダウンロード成功、解析成功、設定の切り替え成功はそれぞれ別です。サブスクリプションURLから内容を取得できても、その内容をコアがYAMLとして読み込めるとは限りません。ログインページ、残量に関する案内、エラーテキストなどが返された場合、設定の解析に失敗する可能性があります。

  • HTTP 401 または 403：認証情報、サブスクリプショントークン、サービス提供元のアカウント状態を確認します。ステータスコードだけで期限切れと判断しないでください。
  • HTTP 200でも解析エラー：返された内容の種類、サブスクリプションの形式、クライアントのコアが使用中のプロトコルや項目に対応しているかを確認します。
  • ノード一覧に古いノードが残っている：古い設定がローカルに残っている場合があります。ノードが表示されていてもプランが有効とは限りません。有効期限と残り通信量も確認してください。
  • 更新後もノードが変わらない：更新した設定が現在有効になっているか確認します。proxy-providersを使っている場合は、該当プロバイダーの更新結果も確認してください。

03｜ノードの接続性を確認し、遅延時間だけで判断しない

ノードを1つ固定し、テスト中に自動選択グループが接続先を切り替えないようにします。同じ接続先に対して3回連続でテストした後、別の地域や回線のノードでも比較します。1つのノードだけ失敗する場合は、まずそのノードを調べます。同じサービス提供元のノードがすべて失敗する場合は、アカウント、ネットワーク、コアとの互換性を確認してください。

遅延テストでは通常、指定されたテスト用URLにリクエストを送ります。成功しても、その時点でそのURLに到達できたことしか分かりません。目的のサイトには別のアクセス制限がある場合や、ノードが混雑時だけパケットロスを起こす場合もあります。ログで失敗箇所が「ノードサーバーへの接続」なのか「ノードから接続先へのアクセス」なのかを確認してください。この2つは異なる段階の障害です。

  • connection refused：接続が明示的に拒否されています。サーバーのポート、サービスの状態、ローカルの待ち受けを確認してください。
  • i/o timeout：接続または読み書きがタイムアウトしています。エラーに表示されたアドレスから、ノード、DNS、接続先のどこで発生したかを判断します。
  • TLSハンドシェイクに失敗する：時刻、SNI、プロトコルのパラメーター、コアの対応状況を確認してください。証明書の検証を安易に無効化しないでください。

04｜システムプロキシとmixed-portを一致させる

「クライアントは正常に見えるのに、ブラウザーのリクエストがログに出ない」場合によくある原因です。現在有効な設定のmixed-portを確認し、デフォルトのポートを推測で決めないでください。ここでは7890を例にします。実際の値が7897なら、システム設定とテストコマンドも同じ値に変更します。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」でアドレスとポートを確認できます。macOSでは「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」を確認します。クライアントがシステムプロキシを管理している場合は、クライアント側のスイッチを使い、双方の設定が上書きし合わないようにしてください。external-controllerは管理インターフェース用であり、Webプロキシのポートとしては使えません。

明示的なプロキシ指定でブラウザー設定を迂回する

Windowsではターミナルでcurl.exeを使います。macOS、Linuxではコマンド名をcurlにしてください。以下のコマンドは最大20秒で待機を打ち切り、レスポンスヘッダーを表示します。Webページ全体はダウンロードしません。

curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

HTTPレスポンスを受信できた場合、リクエストは少なくともHTTPレスポンスを返すサーバーまで届いています。403でもページが正常に使えるとは限りません。200 Connection establishedの後にTLSエラーが出た場合は、プロキシトンネルが確立しただけで、HTTPS通信の成功は確認できていません。明示的なプロキシ指定では成功し、ブラウザーでは失敗する場合は、ブラウザーのプロキシ設定、拡張機能、セキュアDNSを確認します。ローカルポートに接続できない場合は、コアと待ち受け状態を先に確認してください。

# Windows PowerShell：7890番ポートを待ち受けているプロセスを確認
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Linux：待ち受けポートとプロセスを確認
ss -lntp 'sport = :7890'

# macOS：待ち受けポートとプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

ポートを現在のクライアントのコアが使用していることを確認します。別のプログラムが先にポートを使用している場合は、競合しているプログラムを終了するか、プロキシのポートを変更してください。プロセスIDが表示されたからといって、すぐにプロセスを終了しないでください。

05｜アプリがシステムプロキシを迂回していないか確認

システムプロキシは、すべてのプログラムを対象にした一括設定ではありません。一部のゲーム、コマンドラインツール、独自のネットワークスタックを使うソフトはシステムプロキシを参照しません。ブラウザー拡張機能が独自のプロキシ設定を使う場合もあります。リクエストを送信したときに、クライアントの「接続」画面やログに対象の記録があるかを確認してください。

  • ブラウザー：プロキシ切り替え拡張機能を一時的に無効にし、SOCKSアドレスやプロキシ除外リストが個別に設定されていないか確認します。
  • コマンドライン：HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYを確認し、古いポートや除外ルールが想定どおりの設定を上書きしていないか調べます。
  • Firefox：「設定」→「一般」→「ネットワーク設定」→「接続設定」で、システムプロキシを使う設定か手動プロキシかを確認します。

PowerShellではGet-ChildItem Env:*proxy*、macOSとLinuxではenv | grep -i proxyを実行して、関連する環境変数を確認できます。出力に認証情報が含まれる場合があるため、共有前に伏せてください。VPN、プロキシ拡張機能、ネットワーク高速化ツールを同時に有効にすると、通信が乗り換え続ける一方で、調査記録から経路が分からなくなります。

06｜TUNの権限、サービス、ルーティングを確認

明示的なHTTPプロキシでは正常なのにTUNを有効にすると通信できない場合、ノードよりも仮想ネットワークアダプター、ルート、権限を調べます。Windowsのクライアントは通常、サービスモードまたは管理者権限を必要とします。Linuxでは適切なネットワーク管理権限が必要です。macOSではクライアントの指示に従ってネットワークコンポーネントを許可してください。必要な権限は、使用中のクライアントの説明に従って確認します。

  1. TUNをオフにし、システムプロキシまたは明示的なプロキシで正常にアクセスできることを確認して、比較条件を作ります。
  2. コアのログに仮想ネットワークアダプターの作成失敗、権限不足、ルート追加失敗などのエラーがないか確認します。
  3. ほかのVPNや仮想ネットワークソフトを一時的に終了してからTUNを有効にし、デフォルトルートが変わるか確認します。
  4. Androidではシステムの「設定」で「VPN」を検索し、対象のクライアントにVPNの使用が許可されているか確認します。常時接続VPNと「VPNを使わない接続をブロック」の組み合わせが、切り替えに影響することもあります。

mihomoのtun.enable、auto-route、dns-hijackは、それぞれインターフェースの有効化、ルーティング、DNSの横取りに関係します。最初の項目を有効にしただけで、ほかの設定まで正しくなるわけではありません。クライアントがこれらの項目を統合して生成する場合もあるため、サブスクリプションの元データだけでなく、実際に動作している最終設定を確認してください。

07｜ルールモード、ポリシーグループ、REJECTへの一致を確認

「接続」画面で失敗したドメインを探し、一致したルール、ポリシーグループ、最終的に選ばれたノードを確認します。ルールは上から順に評価され、一致すると処理が止まります。特定のドメインが先にDIRECTまたはREJECTに一致していると、後続のフォールバックルールは実行されません。

一時的にグローバルモードに切り替え、確認済みのノードを明示的に選択してテストできます。グローバルモードではアクセスでき、ルールモードでは失敗する場合は、ルールの順序とポリシーグループの選択を確認してください。グローバルモードで変わるのは、コアに入った通信の振り分け方法だけです。もともとプロキシを迂回しているアプリが、自動的にコアの管理対象になるわけではありません。TUN使用時は、プライベートネットワークやルートの除外設定も別途確認が必要です。

# ルール設定の例：PROXYには設定内に実在するノードまたはポリシーグループを指定
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上の例はルールの順序を示すもので、ルール全体を置き換えるためのものではありません。サイトのメインドメインは正常でも、画像やログインが失敗する場合は、関連するCDN、API、認証用ドメインも確認してください。変更後はルールモードに戻し、グローバルモードで問題を覆い隠すのではなく、必要な箇所だけ修正します。

08｜DNSの失敗、汚染、暗号化DNSによる迂回を見分ける

ログにドメイン名の解決失敗やDNSタイムアウトがある場合、または同じドメインを別のネットワークで調べると明らかに異常な結果になる場合は、DNSを調べます。CDNが異なるIPアドレスを返すのは通常あり得るため、2回の結果が違うだけでDNS汚染とは判断できません。返されたアドレスの範囲、接続エラー、信頼できる別の名前解決経路に切り替えた後の結果も合わせて判断してください。

まず、DNSクエリの送信先を確認

# Windows：システムのデフォルトDNSによる応答を確認
nslookup example.com

# mihomoのDNSが実際に127.0.0.1:1053で待ち受けている場合のみ使用
nslookup -port=1053 example.com 127.0.0.1

# macOS、Linux：digがインストールされている場合は同じ待ち受けポートを指定
dig @127.0.0.1 -p 1053 example.com A

1053は例です。最終設定のdns.listenと一致させてください。プロキシの待ち受けポート7890はDNS用ポートではありません。fake-ipが有効な場合、198.18.0.0/16の範囲のアドレスが返されるのは想定どおりのマッピングであり、DNSの異常とは限りません。重要なのは、その後の通信が引き続きコアに処理されているかどうかです。

  • dns.enableが有効であること、上流のDNSサーバーに接続できること、プロキシサーバーのドメイン名解決が依存関係のループを起こしていないことを確認します。
  • TUNのDNS横取りは通常、ポート53の通常のDNSクエリを対象にします。これだけで、ブラウザー内蔵のDoHも同じように処理されるとは限りません。
  • ブラウザーのセキュアDNSやAndroidの「プライベートDNS」をテスト方法に合わせて一時的に設定します。変更は一度に1項目だけにし、テスト後は必要な設定に戻してください。
  • WindowsでDNSを変更した後、ipconfig /flushdnsを実行してからブラウザーを再起動します。システムのキャッシュを消去しても、各アプリのキャッシュがすべて消えるとは限りません。

respect-rulesを使うと、DNS上流への接続にもルーティングルールが適用されます。その場合はproxy-server-nameserverなど、起動時の名前解決設定も合わせて確認してください。1つのドメインを直すために複数のfallbackや上流DNSを重ねると、最終的にどのDNSサーバーが応答したのか分からなくなることがあります。

09｜IPv6、UDP、MTUによる部分的な障害を確認

ホームページは開けるのに、動画、ログイン、大きなファイルの読み込みが止まる場合は、プロトコルの違いを調べます。すぐにクライアントを再インストールするのではなく、同じノードとURLで比較してください。システムにIPv6アドレスがあっても、現在のネットワークやプロキシの出口でIPv6が使えるとは限りません。

症状比較テスト判断上の注意
IPv4の直接接続は正常、IPv6はタイムアウトTUNをオフにし、curlの-4と-6で同じ接続先へ直接接続して比較基本ネットワークの確認に使います。リモートプロキシが選ぶアドレスは判断できません。
ブラウザーは失敗するが、TCP HTTPSのテストは正常ブラウザーのQUICを一時的にオフにして再テスト改善する場合はUDP対応とルーティングを確認します。恒久的に無効化するのは早計です。
TUN使用時だけ大きなデータの読み込みが止まるバックアップ後、TUNのMTUを一時的に1400に設定1400は診断用の候補値であり、すべてのネットワークで最適とは限りません。

基本ネットワークの直接接続テストにはcurl -4 --noproxy "*" -I --max-time 20 https://example.com/を使い、次に-4を-6に置き換えます。Windowsではcurl.exeを使用してください。接続先に対応するアドレスレコードが必要です。HTTPプロキシ経由のテストでは、-4を指定してもリモートプロキシから接続先へのIPv4接続を強制できません。2種類のテストを混同しないでください。

MTUを変更する際は、クライアントに最終設定が実際に反映されていることを確認し、TUNを再接続してからテストしてください。改善しなければ元の値に戻します。UDPが使えなくても、すべてのWebページが失敗するとは限りません。多くのブラウザーはTCPにフォールバックでき、実際の動作はネットワークとアプリの実装によって異なります。

10｜ログで原因を絞り込み、再現手順と復旧方法を残す

最初の9項目で原因を特定できない場合は、デバッグログを短時間だけ有効にし、問題を一度だけ再現してからinfoに戻します。同じ時刻のログをまとめて確認してください。アプリの接続、ルールの一致、選択されたノード、DNSクエリ、最終的なエラーが一連の流れとして追える必要があります。最後の「タイムアウト」という1行だけでは、ローカルの待ち受け、ノードへの接続、接続先からの応答を区別できないことがほとんどです。

問い合わせ前に次の6項目を整理

  1. OSのバージョン、クライアントのバージョン、mihomoコアのバージョンをそれぞれ記録します。
  2. システムプロキシとTUNのどちらを使っているか、実際のmixed-portの値、ほかのVPNを同時に有効にしているか。
  3. 同じURLに対する明示的なプロキシ指定でのテスト結果、ブラウザーでの動作、テスト時刻。
  4. ルールモードとグローバルモードでの比較結果。ポリシーグループ名だけでなく、最終的なノードも記録します。
  5. 現在のネットワークとスマートフォンのテザリングでの比較結果。ノードやネットワークを変更すると障害の状況が変わるか。
  6. 機密情報を隠した関連ログと、再現に必要な最小限の設定。トークン、パスワード、サブスクリプションURL、プライベートアドレス情報は削除します。

YAMLの構文や設定項目を確認するには、実行中と同じコアバイナリを使い、正しい作業ディレクトリからmihomo -t -f config.yamlを実行します。設定チェックに通っても、設定を読み込めることが確認できるだけで、ノード、DNS上流、接続先のネットワークに到達できるとは限りません。外部ルールファイル、データベース、相対パスを使う場合は、テスト環境と実際の実行環境も一致させてください。

この10項目の確認は、すべてのスイッチを順番に切り替えることが目的ではありません。基本ネットワーク → 有効な設定 → ローカルの待ち受け → アプリの通信取り込み → ルール選択 → DNSと出口の順に、各段階で通信できることを確かめます。問題のある段階が分かったら、その部分だけを修正してください。「再インストールしたらたまたま直った」では一度の障害は解消できても、次の原因を特定しにくくなります。