Clashは接続済みなのにインターネットに接続できない：システムプロキシ・DNS・ルールモードの確認リスト

STATE DEFINITION

まず「接続済み」が何を意味するのか確認する

Clashクライアントに「実行中」「接続済み」と表示されたり、VPNマークが表示されたりしても、通常はコアが起動し、設定ファイルが読み込まれた、またはシステムがVPNインターフェースの権限を許可したことを示すだけです。ブラウザの通信がClashに入っていることや、現在選択されているプロキシグループのノードが目的のアドレスに接続できることを意味するわけではありません。トラブル対処では、まず「プログラムの状態」「通信の入口」「ルールによる判断」「ノードの出口」を分けて確認します。

ウェブページへのリクエストは、おおむね次の経路を通ります。アプリが接続を開始し、OSがプロキシ設定またはルーティングに従って通信をClashへ渡し、Clashが対象ドメインを解析します。ルールエンジンがプロキシグループ、DIRECT、REJECTのいずれを使うかを決定し、プロキシグループが具体的なノードを選択して、最後にノードがリモート接続を確立します。どこか一つでも異常があると、ページの読み込みが終わらない、名前解決に失敗する、接続がリセットされる、一部のアプリだけ通信できないといった症状が現れます。

TRAFFIC PATH

ローカルネットワークからゲートウェイに接続でき、デバイスが有効なアドレスを取得している。
アプリの通信がシステムプロキシまたはTUNインターフェース経由でClashに入っている。
DNSが利用可能な結果を返し、Fake-IPのマッピングが正常に機能している。
ルールが想定したプロキシグループに適用され、誤ってDIRECTやREJECTになっていない。
プロキシグループで選択したノードがTCP、UDP、またはQUIC接続を確立できる。
ファイアウォール、セキュリティソフト、他のVPNが途中で通信を遮断していない。

スイッチを何度も切り替えるより、クライアントの接続ログを確認するほうが効果的です。ウェブページを開いても接続一覧に新しい項目がまったく追加されない場合、問題は通常、システムプロキシ、TUNルート、またはアプリ独自のプロキシ設定にあります。接続ログはあるもののDNSエラーが表示される場合は、DNS設定を確認します。特定のプロキシグループに適用されてタイムアウトしている場合は、ノードと上流ネットワークを確認してください。

NETWORK BASELINE

プロキシを無効にして基本ネットワークを確認する

トラブル対処を始める際は、設定ファイルを残したままシステムプロキシとTUNモードを一時的に無効にします。サブスクリプションを削除したり、クライアントを再インストールしたりする必要はありません。その後、ローカルゲートウェイ、通常のウェブサイト、DNSをテストします。これにより、「ネットワーク自体が切断されている」のか「通信がClashを通過した後に途切れている」のかを切り分けられます。Clashを無効にしてもどのウェブサイトも開けない場合は、プロキシルールを変更する前に、Wi-Fi、モバイルネットワーク、ルーター認証、ホテルや学校のネットワークのログイン、通信事業者との接続を確認してください。

アドレス、ゲートウェイ、ネットワーク認証を確認する

デバイスが正常なIPv4またはIPv6アドレスを取得していることを確認します。自動割り当てによる異常なローカルアドレスになっていないかも確認してください。
ホテル、空港、学校などのネットワークでは、まずウェブ認証を完了してからシステムプロキシまたはTUNを起動します。
Wi-Fiからモバイルホットスポットに切り替えてテストします。ホットスポットでは使えるのに元のネットワークで失敗する場合は、元のネットワークのDNS、UDP制限、ファイアウォールポリシーを重点的に確認します。
システムの日付とタイムゾーンを確認します。時刻が大きくずれているとTLS証明書の検証に失敗し、複数のHTTPSサイトが同時に開けなくなることがあります。

段階的なテストでDNSと接続の障害を切り分ける

まずIPアドレスへの接続をテストし、次にドメイン名の名前解決を確認します。Windowsではターミナルで ping 1.1.1.1 と nslookup example.com を実行できます。macOSとLinuxでは ping -c 4 1.1.1.1、dig example.com、または nslookup example.com を使えます。一部のネットワークではICMPが制限されるため、pingの失敗だけでネットワーク断と判断せず、ブラウザでのアクセスやDNSクエリの結果も合わせて確認してください。

TRAFFIC INGRESS

システムプロキシ、ポート、TUNの通信経路を確認する

Clashでよく使われる通信の取り込み方には、システムプロキシとTUNがあります。システムプロキシは、OSのHTTP、HTTPS、SOCKSプロキシ設定に従うアプリに主に影響します。TUNは仮想ネットワークインターフェースとルーティングを使い、より広範囲のTCP・UDP通信を取り込みます。両方をクライアントで一元管理することもできますが、トラブル対処では現在どちらに依存しているのかを明確にし、システムプロキシの問題をノードのせいにしないようにします。

システムプロキシは有効なのにブラウザの接続ログがない

まず、システムプロキシのアドレスがローカルループバックアドレスを指し、ポートが現在の設定の待受ポートと一致していることを確認します。一般的な設定では mixed-port を有効にし、HTTPとSOCKSの両方の接続を受け付けます。古い設定では port と socks-port を個別に使うこともあります。クライアントが設定を更新してポートが変わったのにOSが古いポートを使い続けていると、ブラウザにはすぐにプロキシサーバーによる接続拒否が表示されます。

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

ブラウザやアプリに個別のプロキシが設定されていないかも確認します。個別プロキシの優先順位がシステム設定より高く、すでに終了した別のクライアントを指している場合があります。コマンドラインツールも、デスクトップのシステムプロキシを自動的に読み取るとは限りません。ターミナルのプログラムだけが失敗する場合は、Clash全体の障害と決めつけず、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY の環境変数を確認してください。

TUNは有効なのにすべてのリクエストがタイムアウトする

TUNモードは仮想インターフェース、ルーティングテーブル、システム権限に依存します。初回の有効化では、Windowsでネットワークコンポーネントのインストールや起動に管理者権限が必要になる場合があります。macOS、iOS、AndroidではVPN権限が要求されます。権限が取り消されている、仮想インターフェースの初期化に失敗している、デフォルトルートが書き込まれていないといった場合、画面にはコアが実行中と表示されていても、実際の通信は正しく処理経路に入りません。

他のVPN、ネットワーク高速化ツール、同種のプロキシを停止してから再テストします。複数のプログラムが同時にデフォルトルートやDNSを変更すると、ルーティングの優先順位が衝突しやすくなります。TUNを無効にしてシステムプロキシだけを有効にするとブラウザが復旧する場合、ノードと基本的なプロキシポートはおそらく正常で、問題はTUNの権限、インターフェース、ルーティング、DNSハイジャック設定に絞れます。

DNS PIPELINE

DNS名前解決、Fake-IP、キャッシュの問題を確認する

DNS障害では、ドメイン名では開けないのにIPアドレスへは応答がある、接続ログに名前解決のタイムアウトが続く、一部のドメインだけ失敗する、ネットワークを切り替えても古い結果が使われる、といった症状がよく見られます。Clash Meta（mihomoとも呼ばれます）は、内蔵DNSモジュールで通常の名前解決、Fake-IPマッピング、分流用の問い合わせ、フォールバック判定を実行できます。設定項目が有効でも、上流DNSが現在のネットワークから到達可能とは限りません。

問い合わせがClashに届いているかを確認する

DNSログを有効にするかクライアントログを確認し、テスト用ドメインにアクセスした際に問い合わせ記録が残るか確認します。システムが古いDNSサーバーへ問い合わせ続けている場合、TUNのDNSハイジャックが機能していないか、ブラウザが独自のセキュアDNSを有効にしている可能性があります。トラブル対処中は、問い合わせ経路を一つにするためブラウザ独自のDNSを一時的に無効にします。ClashのDNSが正常だと確認できたら、必要に応じて元に戻してください。

上流プロトコルとネットワークの対応状況を確認する

従来型のUDP DNS、TCP DNS、DoH、DoTでは、必要なネットワーク条件が異なります。ある上流アドレスがモバイルネットワークで使えても、会社や学校のネットワークで使えるとは限りません。特にプロキシノードがまだ接続できない状態で、ドメイン名で指定したプロキシサーバーのアドレスがプロキシ経由でしか解決できないDNSに依存していると、起動時の依存関係が循環することがあります。プロキシサーバーのドメイン名を解決する基盤DNSは、現在のローカルネットワークから直接アクセスできる必要があります。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5

上記の断片は項目同士の関係を示すだけで、既存のサブスクリプションをそのまま上書きするためのものではありません。設定がサブスクリプション提供元やクライアントの上書き機能で管理されている場合は、対応する上書きレイヤーで変更してください。そうしないと、次回のサブスクリプション更新でローカル編集が上書きされます。IPv6を有効にしている一方、ローカルネットワークのIPv6ルートが不安定な場合、アプリが到達不能なアドレスを優先して試すことがあります。比較テストとしてClash DNSのIPv6応答を一時的に無効にできますが、最終的には試行錯誤の設定に頼らず、ネットワークの対応状況に合わせて判断してください。

Fake-IPモードで起きる特殊な現象

Fake-IPでは、まずアプリに予約済みアドレスを返し、その後コアがドメインとのマッピングに基づいて接続を処理します。そのため、198.18.0.0/16 の範囲のアドレスが表示されても、通常は仕組みどおりの動作であり、ドメインが公開ネットワーク上の誤ったアドレスに解決されたことを意味しません。本当に確認すべきなのは、アプリの接続がClashに捕捉されているか、マッピング記録が残っているかです。DNS問い合わせはClashを経由していても、その後の接続がClashを迂回すると、Fake-IPを受け取ったアプリは当然ながら直接アクセスできません。

LAN機器の検出、プリンター、ルーター管理用ドメイン、実アドレスを必要とする一部のサービスでは、Fake-IPフィルターへの追加が必要になる場合があります。フィルターは明確なドメインに対して設定し、広範囲のドメインをまとめて除外するのは避けてください。そうしないと、ルールの適用やDNSの分流結果が予測しにくくなります。変更後はシステムのDNSキャッシュを消去し、影響を受けるアプリを完全に終了して再起動してください。古い接続プールが過去の結果を使い続けるのを防ぐためです。

RULE DECISION

ルールモード、プロキシグループ、ノードの出口を確認する

接続ログがすでに表示されている場合は、各リクエストがどのルールに適用され、どのプロキシグループに渡され、最終的にどのノードが選択されたのかを確認します。Clashのルールは記述順に照合され、通常は最初に適用されたルールで検索を終了します。前方にある広範囲のルールが後方の詳細なルールを隠している場合があります。末尾の MATCH は、それまでに一致しなかったリクエストを受け持ちます。

モード切り替えで比較し、グローバルモードを修復手段にしない

ルールモードを一時的にグローバルモードへ切り替え、動作確認済みのノードを選択します。サイトが復旧するなら、システムプロキシ、DNSの基本経路、ノードの出口は正常で、問題はルールセット、プロキシグループの選択、またはDIRECTルートにある可能性が高くなります。グローバルモードでも失敗する場合は、ノード、プロトコルの互換性、ファイアウォールを引き続き確認します。比較が終わったらルールモードに戻し、グローバルモードで誤適用を隠し続けるのではなく、具体的なルールを修正してください。

ダイレクト接続モードは、ローカルサイトが誤ってプロキシへ送られていないかを判断するためにも使えます。DIRECTではアクセスできるのにルールモードで失敗する場合は、そのドメインがプロキシグループに適用されていないか、選択したノードが対象に適しているかを確認します。反対に、プロキシモードではアクセスできるのにDIRECTがタイムアウトする場合は、現在のローカルネットワークから対象への直接経路が利用できないため、ルールを適切なプロキシポリシーへ渡す必要があります。

プロキシグループが存在していても、利用可能なノードが選択されているとは限らない

select タイプのプロキシグループではメンバーを手動で選択する必要があります。url-test はテスト用アドレスと間隔に基づいて自動選択し、fallback は通常、利用可能性の順に切り替えます。自動テストの結果は、ある時点でのテスト用アドレスへの接続状況しか示しません。すべてのウェブサイト、すべてのプロトコル、長時間接続の安定性を完全に表すものではありません。遅延値が正常なのにウェブページが開けない場合は、プロキシグループの測定結果だけでなく、実際のリクエストログを確認してください。

プロキシグループがREJECT、利用できないノード、またはすでに無効になった子プロキシグループを選択していないことを確認します。
地域も回線も異なるノードを2つ手動で切り替え、同じウェブサイトで繰り返しテストします。
TCPのウェブページは正常なのにゲーム、音声通話、QUICだけが異常な場合は、ノードがUDPに対応しているか、TUNがUDPを取り込んでいるかを確認します。
特定のウェブサイトだけ失敗する場合は、ドメインルール、IPルール、ルールセットの更新状態、最終的なMATCHの行き先を確認します。
サブスクリプション更新直後に障害が発生した場合は、プロキシグループ名とルールの参照先が一致しているか確認し、存在しないグループをルールが指していないか確認します。

SYSTEM BOUNDARY

ファイアウォール、ポート競合、他のネットワークソフトを確認する

別のデバイスでは設定が使えるのに、現在のデバイスだけ常に失敗する場合は、OS側の制限を確認します。ファイアウォールがクライアントの画面表示は許可していても、コアプロセスによる外部接続を阻止していることがあります。セキュリティポリシーによって、ローカルプログラムのプロキシポート待受が禁止されている場合もあります。クライアントの更新後にコアファイルのパスが変わると、以前の許可ルールが新しいパスに自動適用されないことがあるため、ネットワーク権限を再確認してください。

待受ポートが現在のClashコアに割り当てられているか確認する

Windowsでは netstat -ano | findstr 7890 を使ってポートとプロセスIDを確認できます。macOSとLinuxでは lsof -i :7890 を使います。ポートが別のプログラムに占有されている場合、Clashのログには通常、待受に失敗したことが記録されます。その場合は競合しているプログラムを終了するか、設定とシステムプロキシの両方でポートを変更してください。片方だけ変更してはいけません。

複数のネットワーク制御プログラムを重ねて使わない

企業VPN、仮想マシンのネットワーク、コンテナネットワーク、ゲーム高速化ツール、通信フィルタリングソフトは、ルートを書き換えたり、仮想NICをインストールしたり、DNSを変更したりすることがあります。トラブル対処では一つずつ終了し、変更のたびにデフォルトルートと接続ログを確認します。システム再起動後はいったん復旧するのに、特定のネットワークソフトを起動すると再び切断される場合は、競合元を特定する手がかりになります。

LAN共有では追加の確認が必要

他のデバイスがLAN経由で本機のClashに接続する場合、本機の設定でLANアクセスを許可し、プロキシポートをシステムのファイアウォールでも許可する必要があります。クライアント側に入力するサーバーアドレスはClashが動作しているデバイスのLANアドレスであり、127.0.0.1 ではありません。ループバックアドレスは常にクライアント自身を指すためです。アクセス制御の観点から、待受は信頼できるネットワークでのみ開放し、クライアントが対応している認証項目も使って利用範囲を制限してください。

RECOVERY CHECKLIST

決めた順序で設定を戻し、再確認する

個別のテストが終わったら、一時的な変更を安定した設定に整理します。複数の一時DNS、重複したルール、長期的なグローバルモードをそのまま残さないでください。次の順序は、デスクトップとモバイルの多くのクライアントに適しており、原因の切り分け結果を設定管理者に伝える際にも役立ちます。

基本ネットワークを確認：システムプロキシとTUNを無効にし、現在のネットワークで認証を完了して通常のサイトへアクセスできることを確認します。
コアを起動：設定を読み込んだ後に起動ログを確認し、YAMLの解析、ポートの待受、ルールセットの読み込みが成功していることを確認します。
システムプロキシだけを有効化：ブラウザでテストサイトを開き、接続一覧に記録が追加されることを確認します。
DNSを確認：ドメインの問い合わせ結果とログを確認し、キャッシュを消去して同じドメインを再テストします。
ノードを確認：グローバルモードで既知の利用可能ノードを一時的に選択し、ルールモードに戻して結果を比較します。
ルールを確認：実際の適用項目、プロキシグループ、最終ノードを確認し、誤ったDIRECT、REJECT、グループ名の参照を修正します。
TUNだけを有効化：VPN権限、仮想インターフェース、ルーティングが正常であることを確認し、システムプロキシに従わないアプリをテストします。
セキュリティ境界を戻す：必要なファイアウォールとネットワークソフトを再び有効にし、競合が発生していないか一つずつ確認します。

よくある症状と優先確認項目

接続一覧が空のまま: システムプロキシのアドレス、ポート、アプリ独自のプロキシ、TUNの権限、ルーティングの取り込みを優先して確認します。
ドメインは失敗するがIPには到達できる: Clash DNS、システムDNS、ブラウザ独自のDNS、上流DNSへの到達性、キャッシュを優先して確認します。
グローバルモードでは使えるがルールモードでは失敗する: ルールの順序、ルールセットの状態、MATCHの行き先、プロキシグループの参照、DIRECT経路を確認します。
ブラウザは使えるが他のアプリは失敗する: アプリがシステムプロキシを迂回していないか確認し、必要に応じてTUNによる取り込みとUDP対応を確認します。
すべてのノードが同時にタイムアウトする: まずローカルネットワーク、DNS、システム時刻、ファイアウォール、出口制限を確認し、その後でサブスクリプションのノード状態を判断します。
サブスクリプション更新後に使えなくなった: 設定の解析ログ、プロキシグループ名、ルールの参照先、上書き内容、クライアントの項目互換性を確認します。

問題が解決しない場合は、最小限の診断記録を作成します。OSとクライアントのバージョン、コアの種類、通信の取り込み方法、障害発生時刻、テストしたネットワーク、ルールモード、適用されたポリシー、個人情報を伏せたエラーログを記録してください。完全な設定ファイルやサブスクリプションURLは公開しないでください。「再インストールした」という情報より、通信経路を明確にした記録のほうが原因を特定しやすく、無関係な設定の変更や同じ作業の繰り返しも防げます。