まず「クライアントが起動中」と「通信がプロキシを経由している」を区別する

まずクライアントの「接続」と「ログ」を開き、表示されないWebページを再読み込みします。ウィンドウに「実行中」と表示される、タスクトレイのアイコンが点灯している、ノードに遅延時間が表示される、といった状態だけでは、一部の機能が動いていることしか分かりません。ブラウザーのリクエストがプロキシを経由したことや、目的のWebサイトにアクセスできることの証明にはなりません。

Clashはプロキシコアやクライアントの一般的な呼び名です。Clash Metaは後にmihomoという名称で開発が続けられています。GUIクライアントによって設定項目の場所は異なります。以下では、Windows 11の設定画面、一般的なクライアントの「システムプロキシ」「プロキシモード」「接続」「ログ」、mihomoの設定項目を例に説明します。ポートの例には 7890 を使いますが、実際の操作では現在の設定を確認してください。

  1. 現在の状態を記録：クライアント名、コアのバージョン、使用中のプロファイル名、現在のノード、混合ポート、TUNの有効・無効を記録します。
  2. ネットワーク自体の障害を切り分ける：システムプロキシとTUNを無効にし、普段プロキシなしでアクセスできるWebサイトを開きます。それでも接続できない場合は、Wi-Fi、ゲートウェイ、ブロードバンドの認証、学校のネットワークへのログインを確認してください。
  3. 検証範囲を絞る：起動するクライアントを1つだけにし、同じURLで繰り返しテストします。変更する項目は毎回1つだけにしてください。
  4. リクエストを確認：再読み込み後に接続ログがない場合は、まず通信の入口を確認します。ログがあるのに接続に失敗する場合は、出力ノード、ルール、DNSを確認してください。

システムプロキシを確認：ブラウザーがローカルポートに接続しているか

アドレス・ポート・プロキシの例外設定を確認

Windows 11で「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」→「編集」を開きます。通常のブラウザー用HTTPプロキシのサーバーアドレスは、クライアントの待ち受けアドレスと一致させます。クライアントがローカルのみで待ち受けている場合は、通常 127.0.0.1 を指定し、ポートには実際のHTTPポートまたは混合ポート（例：7890）を入力します。コントロールパネルのAPIポートをプロキシポートとして指定しないでください。

macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」を開き、「Webプロキシ」と「保護されたWebプロキシ」を確認します。項目名はmacOSのバージョンによって異なる場合があります。自動プロキシ設定を使っている場合は、PACのURLにアクセスできるか、スクリプトのルールで対象ドメインが直接接続されていないかも確認してください。プロキシの例外リストに対象ドメインが誤って含まれていないかも確認します。

  • クライアントを再起動した後、システム設定をもう一度確認してください。古いプロセスの終了時に、別のプロキシ設定へ戻る場合があります。
  • Firefoxでは「設定」→「一般」→「ネットワーク設定」→「接続設定」を開き、「システムのプロキシ設定を利用する」を選ぶか、プロキシを手動で指定します。
  • ブラウザーのプロキシ拡張機能を一時的に無効にし、システムプロキシが上書きされないようにします。組織で管理されているブラウザーでは、ポリシーによって設定が制限されている場合もあります。
  • システムプロキシはすべてのアプリを中継するわけではありません。ターミナルツール、ゲーム、一部のストアアプリでは個別の設定が必要です。通常のプロキシ接続を確認したうえで、必要に応じてTUNを使ってください。

プロキシを明示してリクエストし、ブラウザー設定を切り分ける

Windows PowerShellでは curl.exe を使います。旧バージョンのPowerShellにある curl のエイリアスとの混同を避けるためです。次のコマンドはローカルのHTTPプロキシにリクエストを1回送り、全体のタイムアウトを15秒に設定します。example.com は接続確認用のドメインです。実際にアクセスできないWebサイトに置き換えて、もう一度テストしてください。

curl.exe -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

macOSとLinuxでは、対応するコマンドを実行します。

curl -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

コマンドでHTTPレスポンスを取得できるのにブラウザーでは失敗する場合は、ブラウザー拡張機能、個別のプロキシ設定、接続キャッシュを確認してください。127.0.0.1:7890 への接続が拒否された場合は、まずローカルの待ち受け状態を調べます。すぐにサブスクリプションを変更する必要はありません。レスポンスが 403 の場合も、ネットワークのタイムアウトとは分けて考えてください。HTTPサービスから応答は届いていますが、対象サイトまたは中継機器がアクセスを拒否している可能性があります。

ポート競合を確認：待ち受けているプロセスが現在のコアか調べる

mixed-port はHTTPとSOCKSの両方に使えるプロキシの入口です。一方、external-controller はコントロールAPI用で、用途が異なります。設定例の 9090 をブラウザーのプロキシ欄に入力することはできません。次の設定例は項目の確認用です。サブスクリプション全体を置き換えるために使わないでください。

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090

Windows PowerShellで待ち受けプロセスを確認します。

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

出力に表示された OwningProcess の数値を Get-Process -Id に入力して、プロセス名を確認します。macOSでは1つ目のコマンド、Linuxでは2つ目のコマンドを使えます。プロセス情報の表示に適切な権限が必要な場合があります。

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -ltnp 'sport = :7890'
確認結果考えられる原因次の手順
待ち受けプロセスが見つからないコアが起動していない、設定の読み込みに失敗した、または実際のポートが7890ではない起動ログと使用中のプロファイルを確認し、実際の待ち受けポートを特定する
別のアプリがポートを使用中古いクライアント、別のプロキシツール、またはバックグラウンドサービスが動作している競合するアプリを正常に終了し、現在のコアを再起動する
ログに address already in use と表示される現在のコアがアドレスのバインドに失敗しているポートを解放するか、ポートを変更してシステムプロキシにも反映する
::1 のみで待ち受けている待ち受けアドレスと指定したIPv4ループバックアドレスが一致していない待ち受け設定を確認し、プロキシアドレスを待ち受けアドレスに合わせる

ポート番号だけを見て、見覚えのないプロセスを強制終了しないでください。まずプロセス名と実行元を確認します。混合ポートを 7891 に変更した場合は、システムプロキシ、ブラウザー個別のプロキシ設定、ターミナルの環境変数も合わせて変更してください。変更しないと、リクエストは引き続き古いポートに送られます。

ノードを確認：遅延時間が表示されても対象サイトに接続できるとは限らない

「プロキシ」画面を開き、実際に通信の出力に使われるプロキシグループを探します。グループの転送先が別のグループになっていたり、DIRECT が選ばれていたりする場合があります。画面上でノードが選択状態でも、そのノードが現在の接続に使われているとは限りません。「接続」の詳細に戻り、リクエストのドメイン、ルール適用の経路、最終的な出力ノードを確認してください。

  1. 同じプロキシグループで別のノードを手動選択し、既存の接続を閉じてから対象のWebページを再読み込みします。
  2. 一時的にグローバルモードへ切り替え、グローバル用プロキシグループでノードを明示的に選んで、同じリクエストを試します。
  3. グローバルモードでは接続でき、ルールモードでは失敗する場合は、ルールの適用状況を確認します。どちらも失敗する場合は、ノードとローカルネットワークを優先して確認してください。
  4. サービス提供元のアカウントページで、サブスクリプションの期限、通信量の残量、ノードのメンテナンス情報を確認してください。

グローバルモードで変わるのは、コアに届いた通信のルーティング先です。すべてのアプリの通信が自動的にコアへ入るわけではありません。テスト後はルールモードに戻してください。ノードの遅延時間は通常、クライアントに設定されたテスト用URLへの応答時間です。その時点でテスト用リクエストが完了したことしか示さず、150 ms という数値だけで動画、ログイン、特定のWebサイトが正常に使えるとは判断できません。

ルールの誤判定を確認：最初に一致したルールを調べる

ルールモードでは上から順に照合され、最初に一致したルールで接続先が決まります。よくある原因は、対象ドメインが直接接続ルールに含まれている、範囲の広いルールが先にある、ルールが指定したプロキシグループで利用できないノードが選ばれている、といったケースです。設定末尾の MATCH だけを確認せず、該当する接続の詳細に記録されたルールを確認してください。

以下はルールの順序による違いを示す例です。DIRECT と REJECT は組み込みのポリシーです。この設定例は完全な設定ではなく、使用中のサブスクリプションにそのまま追加するものでもありません。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,REJECT

この設定例では、example.com とそのサブドメインは先に直接接続され、それ以外の一致しないリクエストは拒否されます。2行を入れ替えると、先頭の MATCH がすべてのリクエストを処理するため、後ろのドメインルールは適用されません。これが「ルールを設定したのに機能しない」典型的な原因です。

  • DIRECT に一致して接続できない：対象のサイトが直接接続に対応しているか確認します。プロキシが必要な場合は、より具体的なドメインルールを、該当する範囲の広いルールより前に配置してください。
  • REJECT に一致する：広告フィルターや独自のブロックルールを確認し、ログイン、認証コード、静的ファイルのドメインまで誤ってブロックしていないか調べます。
  • プロキシグループに一致しても失敗する：グループ名だけで判断せず、そのグループで最後に選択されたノードを確認してください。
  • 設定更新後に再発する：クライアントが対応している上書き機能またはマージ機能で独自ルールを保存します。サブスクリプション更新時に消えるファイルを直接編集しないでください。

ルールを変更した後は、該当する既存の接続を閉じてからテストします。ブラウザーが既存のHTTP/2接続を再利用すると、再読み込みしても新しいルーティング判定が行われない場合があります。また、1つのページから複数のドメインにリソースを要求することもあります。ページ本体は表示できても画像やログインに失敗する場合は、失敗したリソースの接続ログを確認してください。

DNSとTUNを確認：名前解決の障害と通信の取り込みを切り分ける

まずDNSエラーかどうかを確認する

Could not resolve host、no such host、ログのDNSタイムアウトが発生した場合は、どの機能がドメイン名を解決しているか確認します。ブラウザーのセキュアDNS、システムDNS、mihomoのDNSモジュールは、それぞれ異なる経路を使うことがあります。Windowsの nslookup example.com は、システムで選択されているDNSサーバーの応答を既定で確認します。mihomo内部の名前解決が正常かどうかを示すものではないため、実際のリクエストログと照らし合わせて判断してください。

fake-ipが有効な場合、198.18.0.0/15 の範囲のアドレスが表示されても、必ずしも異常ではありません。これはコアがドメイン名に割り当てるマッピング用アドレスで、プロキシが通信を取り込んだ後に元のドメイン名へ対応付ける必要があります。TUNを無効にした後もブラウザーにこのアドレスがキャッシュされていると、接続に失敗することがあります。まずDNSと通信経路を整合させてから、ブラウザーを再起動してください。必要に応じてWindowsで ipconfig /flushdns を実行し、システムのDNSキャッシュを消去します。

nameserver や fallback を、出所の不明なパブリックDNSアドレスに一括置換しないでください。まず上流DNSのアドレスと通信方式が現在のネットワークから利用できるか確認します。上流DNSの指定にドメイン名を使っている場合は、起動時の名前解決経路も確認が必要です。ブラウザーのセキュアDNSは比較のため一時的に無効にし、原因を確認した後、必要に応じて元に戻してください。

通常のプロキシが動作することを確認してから、TUNを個別に検証する

TUNは仮想ネットワークインターフェースを使って通信を取り込むため、システムプロキシより確認すべき項目が多くなります。プロキシを明示したコマンドが成功するのに、TUNを有効にすると全体の通信に失敗する場合は、クライアントのサービス権限、仮想インターフェース、ルーティング、DNSの横取りを確認してください。手当たり次第にノードを切り替えるのは避けましょう。

  1. ルーティングの競合を避けるため、ほかのVPN、仮想ネットワークツール、プロキシクライアントを終了し、現在のツールだけを起動します。
  2. クライアントで必要なサービスモードや権限が有効になっているか確認し、TUNの起動ログにエラーがないか調べます。
  3. まずTUNを無効にしてシステムプロキシだけで動作を確認します。その後TUNを有効にし、クライアント推奨のシステムプロキシ設定を使って、経路の重複による切り分けへの影響を避けます。
  4. route print（Windows）または ip route（Linux）で、切り替え前後のルートを確認します。社内ネットワークで必要なルートは個別に設定してください。

mihomoのTUN設定では dns-hijack を使って対象のDNSリクエストを取り込めます。ただし、一般的な53番ポートの横取りで、すべての暗号化DNSを処理できるわけではありません。ブラウザーのDoHはHTTPS通信として扱われるため、実際のルールとDNS構成に合わせた対応が必要です。

エラー内容から原因を絞り込む：再現可能な最小限の情報を記録する

症状・ログ優先して確認する項目
ローカルの7890番ポートへの接続が拒否されるポート、待ち受けアドレス、コアの起動状態
リクエストはコアに届くが、出力接続がタイムアウトする最終ノード、上流への接続状況、出力側でのブロック
グローバルモードでは成功するが、ルールモードでは失敗する適用されたルール、プロキシグループの選択、直接接続の経路
TUNを有効にした場合のみ失敗するサービス権限、仮想インターフェース、ルーティング、DNSの取り込み
certificate verify failedシステム時刻、証明書チェーン、HTTPS検査機器
特定の1サイトだけが403または429を返す対象サイトの制限、出口IPアドレス、アカウント、アクセス頻度

証明書エラーが発生した場合は、まずシステムの日付と時刻を同期し、ネットワークへのログイン認証が必要か、組織のネットワークでHTTPS検査が行われているか確認します。証明書検証をスキップする方法を恒常的な対処にしないでください。403 や 429 が返る場合も、何度も再読み込みしないでください。プロキシ経路は確立しており、サイトのアクセス制限やリクエスト頻度が原因の可能性があります。

問い合わせる際は、クライアントとコアのバージョン、OSのバージョン、再現した日時、対象ドメイン、システムプロキシとTUNの状態、明示的なプロキシを使ったテスト結果、発生時刻前後のエラーログを伝えてください。「ブラウザーが開けない」ではなく、「ローカルポートには接続できるが、ルールで特定のプロキシグループに振り分けられ、最終ノードへの接続がタイムアウトする」と説明すると、調査の方向が明確になります。