Clashが遅いときの原因別チェック手順｜ノード・回線・端末設定

確認を始める前に：表示の遅さ・ダウンロードの遅さ・接続切れを区別する

「Clashの通信速度が遅い」といっても、症状はさまざまです。Webページの表示開始まで時間がかかる、ダウンロード速度がずっと低い、動画が途中で止まる、といったケースがあります。それぞれ、名前解決や接続確立にかかる時間、継続的な転送速度、通信経路の安定性が関係します。まず症状を切り分けてから設定を変更すると、効果のない試行を減らせます。

• 最初の表示は遅いが、その後は正常：まずDNS、接続確立、接続先サイトの応答を確認します。ノードの帯域不足と決めつけないでください。
• 大容量ファイルのダウンロードがずっと遅い：ノードと通信事業者の回線を比較し、サーバー側で単一接続の速度が制限されていないかも確認します。
• 速度が不安定で、頻繁に再接続する：Wi-Fi、パケットロス、ノードの負荷、バックグラウンドでのネットワーク切り替えを確認します。
• 特定のアプリだけ遅い：そのアプリがプロキシを経由しているか、どのルールが適用されているかを先に確認します。

テスト条件をそろえる

クラウドストレージの同期、システム更新、ほかのダウンロードを一時停止します。同じ接続先、同じ端末、同じテスト時間で比較し、変更する条件は毎回1つだけにします。各条件で3回、1回あたり約30秒を目安に測定してください。従量制の通信を使う場合は、テストによるデータ通信量も確認しましょう。

使用中のクライアント名、コアの種類、プロキシモード、システムプロキシとTUNの有効・無効を記録します。Clashはクライアント群で広く使われる名称で、mihomoは旧Clash.Metaから発展したコアです。クライアントやコアによって対応する設定は異なり、メニュー名も変わることがあります。

第1段階：ノード品質を確認する。遅延より転送速度を重視

プロキシ画面の遅延テストは、通常、指定されたURLへの接続でノードの利用可否と応答時間を調べます。結果はテスト先、接続の再利用、クライアントの実装に左右されるため、あらゆるサイトへの速度を順位付けするものではありません。遅延が60 msのノードが、180 msのノードより必ず速くダウンロードできるとは限りません。

2つのノードを比較する

1. クライアントの「プロキシ」画面を開き、接続先サイトに実際に使われているグループを確認します。グループ内にネストされたグループがある場合はさらに開き、最終的に選択されるノードを確認してください。
2. ノードAを選び、接続先への接続を新しく確立します。最初の応答時間、安定したダウンロード速度、通信の途切れの有無を記録します。
3. ノードBに切り替え、新しい接続を確立して同じ条件でテストします。既存の接続は切り替え後も以前の経路を使うことがあるため、元のダウンロードをそのまま見続けるのではなく、新しい接続で確認してください。
4. ノードAに戻してもう一度テストし、接続先サーバーの一時的な変動による誤判定を避けます。

たとえば、Aは遅延70 msでも安定したダウンロード速度が1.2 MB/s、Bは遅延160 msでも7 MB/sだとします。大容量ファイルのダウンロードにはBが適しています。一方、対話的な通信では実際の応答時間や揺らぎも確認が必要です。ノード名に含まれる地域や倍率は選択時の参考情報にすぎず、物理的な経路や利用可能な帯域を示すものではありません。

ノードについて確認できること

• 同じ時間帯、同じネットワークで特定のノードだけ遅い場合は、そのノードの負荷、入口、出口、または該当する通信経路を優先して疑います。
• 複数のノードで同じサイトだけ遅く、ほかのサイトは正常な場合は、クライアントをすぐに再インストールするのではなく、接続先サービス、出口の地域、ルールを確認します。
• サブスクリプション更新後に速度が変わった場合は、ノードが入れ替わっていないか、グループ内の選択先が変わっていないかを確認します。サブスクリプションを更新しても帯域は増えません。

第2段階：通信事業者の回線を確認する。ネットワークと時間帯を比較

端末からノードまでの通信は、ローカル回線、通信事業者のネットワーク、ノードの入口を経由します。同じノード名でも、固定回線とモバイルデータ通信では経路が異なることがあります。夜間の混雑、異なる事業者間の接続、中継ルートの変化などにより、速度が低下する場合があります。

次の順序で原因の範囲を絞る

1. まずWi-Fiなど端末周辺の環境を確認：ルーターの近くで測定するか、有線接続で再テストします。電波状態が良好なら、5 GHz帯のWi-Fiは高速通信に適しています。ただし、壁を挟む環境では2.4 GHz帯より電波が届きにくい場合があります。
2. 次に接続ネットワークを変える：同じPCとノードを使ったまま、スマートフォンのテザリングに切り替えて比較します。モバイルデータ通信の料金に注意し、PCのバックグラウンド更新は一時停止してください。
3. 最後に時間帯を比較：日中と夜間に同じテストを行い、それぞれの結果を記録します。日付やノードが異なるデータをそのまま比較しないでください。

たとえば、同じノードで自宅の固定回線では0.8 MB/s、スマートフォンのテザリングでは6 MB/sだったとします。この場合、接続ネットワークや途中の通信経路を優先して確認する価値があります。ただし、これだけで特定の通信事業者が意図的に速度制限しているとは断定できません。テザリングへの切り替えでは、接続方式、出口、ルーティングも同時に変わるため、さらに比較が必要です。

システムのpingや経路追跡ツールで基本的なネットワーク状態を確認できますが、ICMP通信はHTTPのシステムプロキシを経由しない場合があります。また、ノードの入口がICMPに応答しないこともあります。単発のタイムアウトや途中のホップの高遅延だけでは、プロキシ経路のパケットロスを証明できません。接続先での挙動や実際の通信も合わせて判断してください。

第3段階：ルールの適用先を確認する。遅い接続の出口を特定

Clashのルールモードでは、通常、ルールを上から順に照合し、最初に一致したルールのポリシーが適用されます。サブスクリプションにノードが含まれていても、すべてのアプリがそのノードを使うとは限りません。接続先がDIRECTに一致していたり、手動で選んだものとは異なるグループに振り分けられていたりする場合があります。

接続履歴から実際の経路を調べる

1. クライアントの「接続」画面を開いてから、接続先にもう一度リクエストを送ります。長時間接続の場合は、該当ページを閉じるかタスクを一時停止してから再試行してください。
2. ドメイン、接続先IP、またはプロセスで絞り込み、適用ルール、ポリシーの経路、最終ノードを確認します。クライアントによっては、接続の詳細を展開しないと情報をすべて確認できません。
3. Webページのメインドメインだけでなく、関連するリソースのドメインも確認します。ページは表示されるのに画像や動画が遅い場合、リソースのドメインに別のルールが適用されている可能性があります。
4. 接続画面に記録がない場合は、まずアプリがシステムプロキシを使っているか、TUNで通信が取り込まれているかを確認します。接続がすぐに終了した場合や、画面の絞り込み条件が原因で表示されないこともあります。

接続が実際にクライアントを経由していると確認できたら、一時的にグローバルモードに切り替え、ノードを明示的に選んで新しい接続で比較します。同じリソースの速度が明らかに改善する場合は、元のルール、グループ、出口の違いを重点的に確認してください。グローバルモードでも、もともとクライアントを経由していないアプリが自動的に取り込まれるわけではありません。一度改善しただけでルールファイルの破損と断定することもできません。

明示的なプロキシ指定でシステムプロキシの違いを切り分ける

以下のWindows PowerShellコマンドは、クライアントのHTTPプロキシまたは混合プロキシのポートが7890であることを前提としています。先にクライアントの設定で実際のポートを確認してください。ポートが7897なら、コマンドをその値に変更します。このリクエストは各処理にかかる時間を確認するためのもので、最大ダウンロード速度の測定には使いません。

curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --max-time 30 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

ここでのtime_connectは主にローカルプロキシへの接続時間を示し、接続先Webサイトまでの遅延を表すものではありません。TLS、最初のバイト、合計時間はいずれもリクエスト開始からの累積値なので、単純に足し合わせることはできません。コマンドでは問題なくブラウザーだけ遅い場合は、ブラウザー拡張機能、アプリ独自のプロキシ設定、リクエストのプロトコルの違いを確認してください。

第4段階：DNSの名前解決を確認する。待ち時間と転送速度の問題を切り分ける

DNSは、接続済み通信の継続的なダウンロード速度よりも、初回アクセス、ドメインごとの振り分け、接続先IPの選択に影響することが多い機能です。ファイルの転送が数分間安定しているのに速度が低い場合、DNSを変更するだけで帯域の問題が解決することは通常ありません。

まず、どこで名前解決しているかを確認する

設定中のdns項目、TUNのDNSハイジャック設定、ブラウザーのセキュアDNSの有効・無効を確認します。システムの名前解決、ブラウザーのDoH、コアのDNSは、それぞれ異なる経路を使う場合があります。システムプロキシを有効にしても、すべてのシステムDNSクエリがClashを経由するわけではありません。

• Fake-IPモード：通常、ドメインに対応するマッピング用アドレスを返し、コアが元のドメインと関連付けて接続を処理します。一般的な設定では198.18.0.0/16が使われますが、実際の値はfake-ip-rangeで確認してください。
• Redir-Hostモード：名前解決で実際のIPアドレスを返します。解決結果や、その後のドメインの関連付け・ルール適用は、コアや通信の取り込み方によって異なります。
• カスタム上流DNS：上流DNSに到達できるか、名前解決のリクエストが循環依存していないかを確認します。知名度だけを理由にパブリックDNSを選ばないでください。

WindowsではResolve-DnsName example.comを実行すると、システム経由の名前解決結果を確認できます。ただし、ブラウザー独自のDoHの結果を示すものではありません。Fake-IPが有効なときに設定範囲内のマッピングアドレスが表示されても、名前解決の失敗ではありません。このアドレスを接続先サーバーとみなして、回線の遅延を評価しないでください。

変更の効果を確認する

1. 現在のDNS設定をバックアップし、変更する要素は1つだけにします。たとえば、到達できない上流DNSを1つ変更し、モードやルール一式を同時に切り替えないようにします。
2. クライアントが対応する方法で設定を再読み込みします。必要ならコアを再起動し、ログにDNS上流への接続エラーがないことを確認してください。
3. Windowsではipconfig /flushdnsを実行してシステムのキャッシュを消去し、ブラウザーを開き直してテストします。ブラウザーやコアが独自のキャッシュを保持している場合もあります。
4. 初回と2回目の表示速度を比較します。初回の待ち時間だけ短縮され、継続的なダウンロード速度が変わらない場合は、改善したのは名前解決または接続確立の段階と考えられます。

遅いからといって、fake-ip-filterの対象をまとめて増やさないでください。この設定は、指定したドメインにFake-IPを返さないようにするものです。通常はLAN内のデバイス検出や特定アプリとの互換性などに使われ、汎用的な高速化リストではありません。変更前に、どのドメインでどんな非互換の症状が起きているかを特定してください。

第5段階：端末の設定を確認する。通信の取り込み、リソース、プロトコルを点検

ノード、ネットワーク、ルールに目立った問題がない場合は、端末側を確認します。ここで探すのは「高速化スイッチ」ではなく、プロキシの二重化、リソース不足、アプリ側の再試行などです。

TUNは帯域を増やす機能ではない

TUNは仮想ネットワークインターフェースを使って通信を取り込み、システムプロキシに従わないアプリにも対応します。変わるのは通信がコアに入る方法であり、ノードの契約帯域が増えるわけではありません。プロトコルスタック、ルート、MTUの設定は互換性に影響する場合がありますが、すべての端末に最適な固定の「最速値」はありません。

システムプロキシでは正常で、TUNのときだけ遅い場合は、同じアプリとノードで再現するかを確認してから、ルートの競合、DNSの取り込み、ほかの仮想ネットワークアダプター、コアのログを調べます。MTU、プロトコルスタック、DNSモードを一度に変更しないでください。改善しても、どの設定が効いたのか分からなくなります。

ブラウザーが遅い場合はUDPとQUICも確認する

HTTP/3は通常UDPを使うQUICで通信します。アプリが試すUDP経路で通信できないと、待機後に別の方式へ切り替わることがあります。ノードのプロトコル、サーバー、通信の取り込み方が対象の通信に対応している必要があります。システムHTTPプロキシ経由のブラウザーの動作は、TUNで通信を取り込んだ場合と同じとは限りません。

ブラウザーの開発者ツールにあるネットワークパネルで、プロトコルやリクエスト時間を確認できます。または、ブラウザーのQUIC関連の実験的な設定を一時的に無効にして比較し、テスト後に元へ戻します。UDPの失敗や切り替え時の待ち時間を示す証拠がある場合に限ってこの経路を調べてください。あらゆる速度低下に対してQUICを無効にする必要はありません。

再テストと記録：次に実行する対策を1つに絞る

変更するたびに、元と同じ接続先、同じテスト時間で3回再測定します。効果のあった変更は残し、改善しなかったものは元に戻します。1回のテストから分かることには限りがあります。ノードの切り替えで改善してもDNSの変更が必要とは限らず、テザリングで改善してもクライアントの再インストールが必要とは限りません。

1. ノード間の差が明確：安定して使えるノードを選び、問題のノードと発生時刻を記録して、サブスクリプション提供元に報告します。
2. ネットワークや時間帯による差が明確：端末のDNSを繰り返し変更するのではなく、接続ネットワーク、無線環境、ノードの入口回線を優先して見直します。
3. ルールの出口が想定と異なる：該当ドメインのルールやグループを調整し、メインのリクエストと関連リソースのリクエストの両方が意図した経路を通るか確認します。
4. 初回のリクエストだけ遅い：名前解決、TLS、接続先からの最初の応答を中心に調べます。小さなWebページへのリクエストから帯域を推定しないでください。
5. 特定の通信取り込み方式だけ遅い：正常に使える方式は維持し、コアのバージョン、再現手順、個人情報を削除したログを用意して原因を調べます。

最も役立つのは「すべての設定を試した」という記録ではなく、「同じ接続先でもノードAは遅く、ノードBは正常」「TUNモードでのみ再現する」といった具体的な比較結果です。次に確認すべき段階を絞り込めます。基本的な接続をまだ確認できていない場合は、まず接続確認の手順に沿って、比較の基準となる安定した環境を用意してください。