Clashの通信速度が遅いときの原因と対処法｜ノード・経路・端末設定を切り分ける

まず測定条件をそろえる：遅延・通信速度・初回表示時間を区別する

原因調査は、まず通信経路を確認し、次にノードと回線を比較、最後に端末側の通信制御とDNSを調整します。Clashの画面に表示されるミリ秒の数値は、ダウンロード速度を示すものではありません。ノードの遅延は通常、指定された測定先へのリクエストにかかる時間です。接続の再利用状況や接続先、測定方法にも左右されるため、大容量ファイルの転送能力をそのまま表すわけではありません。

まず「遅い」と感じる状況を、再現できる形で記録しましょう。たとえば「同じ動画を1080pで再生すると頻繁に止まる」「ページの初回表示に5秒かかるが、再読み込みは速い」「ダウンロード開始直後は速く、その後ずっと速度が落ちる」などです。症状によって確認箇所は異なります。ルール、DNS、TUNを一度に変更するのは避けてください。

再測定できる記録を残す

• クライアントのバージョンと、実際に使われているコアの名称・バージョンを記録します。クライアントの画面に表示されるバージョンとmihomoコアのバージョンは別です。
• ダウンロード用のファイル、ウェブページ、ノードをそれぞれ1つ決め、クラウド同期、システム更新、ほかの速度測定を一時停止します。
• 1回の測定は30～60秒とし、3回繰り返します。測定時刻、ネットワークの種類、ノード、適用ルール、継続速度を記録してください。
• 単位の違いに注意してください。理論上、100 Mbpsは12.5 MB/sです。実際の通信速度はプロトコルのオーバーヘッド分だけ低くなります。

第1段階：ノードが安定した速度で転送できるか確認する

クライアントの「プロキシ」または「プロキシグループ」画面を開き、具体的なノードを1つ選びます。自動選択グループは測定中に選択先が変わる場合があり、同じグループを使ったつもりでも、実際には異なる出口を経由している可能性があります。「自動選択」だけでなく、最終的に使われたノード名も記録しましょう。

遅延が小さいノードが、必ずしもダウンロードも速いとは限らない

たとえば、ノードAの測定遅延が45 ms、ノードBが120 msだったとしても、Aのほうが動画視聴に向いているとは限りません。Aは帯域制限や出口の混雑があり、Bのほうが安定した速度で転送できる場合もあります。数値は比較方法の説明用であり、本サイトでの実測値ではありません。

1. 同じ手動選択グループでノードAを選び、測定先を固定して、継続速度を3回記録します。
2. モードとDNSは変えず、ノードだけBに切り替えて同じ測定を繰り返します。
3. 続いて、別の提供元からダウンロード先を選んで試します。特定のサイトだけ遅い場合は、接続先のCDN、アカウントの速度制限、ノード出口とサイト間の接続経路を疑いましょう。
4. 契約サービスの残り容量、有効期限、接続台数の制限を確認します。設定をインポートできても、サーバー側で引き続き利用できるとは限りません。

すべてのノードで大容量通信を同時に測定しないでください。同時測定は端末側の帯域を奪い合い、契約通信量を消費することもあります。ノード一覧の接続テストは、接続できないノードを手早く見分ける用途に向いています。転送速度を比較するなら、1つずつ測定したほうが結果を判断しやすくなります。

プロトコルを比較するときは、サーバー条件をそろえる

利用できるプロトコルは、コア、ノード設定、サーバー側の対応状況によって異なります。サービス提供元が該当する接続方式を用意している場合に限り、プロトコルを比較できます。サブスクリプション内の種類を、別のプロトコルにむやみに書き換えることはできません。同じ提供元、近い地域、同じ測定先、同じ時間帯で、その提供元が用意する複数の接続先を比較するのが適切です。

現在のネットワークでUDPを使う接続先の調子が悪く、TCP接続は安定している場合、通信経路に違いがある可能性を示す手がかりになります。オリジナル版Clash、Clash Meta、mihomoでは、対応するプロトコルが完全には一致しません。「未対応のプロキシタイプ」と表示された場合は、パスワードやノード名を何度も変更するのではなく、まずコアの対応状況を確認してください。

第2段階：端末の接続環境、ネットワーク間の経路、出口の混雑を切り分ける

ノードには接続できるものの、夜間に速度が大きく落ちる場合は、経路のどこかが混雑していることがよくあります。通信経路には少なくとも、端末からルーターまで、利用中の回線事業者からノードまで、ノードの出口から接続先までの区間があります。ノードサーバーへの遅延測定だけでは、経路全体を確認できません。

2つの条件を比較して原因を絞る

• 同じ端末でネットワークを変える：パソコンを自宅の固定回線とスマートフォンのテザリングにそれぞれ接続し、ノードと接続先は変えずに測定します。テザリングでは正常で固定回線では遅い場合、固定回線の経路、ルーター、Wi-Fiを重点的に確認します。
• 同じネットワークで時間帯を変える：混雑していない時間帯と夜間に、それぞれ3回測定します。複数のノードが夜間だけ遅くなる場合は、異なる提供元や接続回線も比較しましょう。
• 同じ出口で接続先を変える：特定の接続先だけ遅く、ほかは正常な場合、そのサービスの地域別振り分け、出口IPの制限、CDNまでの経路を確認します。
• 同じネットワークで有線接続に変える：有線では安定し、無線で速度が不安定な場合は、まず電波状況やチャンネル干渉を改善します。ノードを変えても、Wi-Fiのパケットロスは解消できません。

Windowsではping -n 20 192.168.1.1、macOSまたはLinuxではping -c 20 192.168.1.1を実行し、ローカルゲートウェイまでの接続が安定しているか確認できます。ここではゲートウェイを192.168.1.1としていますが、実際のアドレスはシステムのネットワーク設定で確認してください。ゲートウェイがICMPに応答しない場合、タイムアウトだけを根拠にネットワーク障害と判断することはできません。

tracertやtracerouteは経路を調べる手がかりになりますが、通常のコマンドによる通信はアプリのプロキシを経由するとは限らず、動画と同じ通信方式とも限りません。途中のルーターがICMP応答を制限している場合もあります。ある区間から応答がなくても、その後の区間が応答しているなら、そこで実際の通信が破棄されているとは限りません。

第3段階：ルールの適用先とアプリの通信取り込みを確認する

クライアントの「接続」画面を開き、画面によっては「アクティブな接続」と表示される場合もあります。フィルターを解除してから対象ページを開き直し、接続先のドメインまたはIP、適用されたルール、ポリシーの経路、最終的な出力先を確認します。ルールモードでは上から順に照合されます。通常のルール一覧では、先に一致した項目によって、後続のルールが適用されないことがあります。

ルールモードとグローバルモードを短時間比較する

1. 「プロキシ」画面で、現在のポリシーグループが選択しているノードを記録します。
2. ルールモードで対象の接続が実際にどこへ出ているか記録します。意図せずDIRECTに一致していないか、別のグループにある遅いノードを選んでいないか確認してください。
3. 一時的にグローバルモードへ切り替え、グローバルポリシーで同じノードを選択します。
4. 対象アプリの既存接続を閉じてから、リクエストをやり直します。モードを切り替えても、既存の接続がすぐに新しい経路へ切り替わるとは限りません。
5. テスト後はルールモードに戻します。グローバルモードでは正常でルールモードでは遅い場合、ルールとポリシーの選択を優先して見直してください。

グローバルモードにしても、端末内のすべての通信が自動的に取り込まれるわけではありません。グローバルモードが決めるのは、通信がコアに入った後の出力先です。アプリの通信がコアに入るかどうかは、システムプロキシ、アプリ独自のプロキシ設定、TUNによる取り込み方に左右されます。ブラウザーは正常なのにゲームやコマンドラインだけ異常な場合、ノードの故障と決めつけず、まず通信の入口を確認してください。

プロキシを明示して、システムプロキシ設定の違いを避ける

以下の例では、ローカルのHTTPまたはmixedプロキシポート7890を使い、小さなページにリクエストします。実際のポート番号はクライアントで確認してください。SOCKS専用ポートにはこのコマンドをそのまま使えません。Windows PowerShellでは、一部の環境でcurlが別のコマンドとして扱われるのを避けるため、curl.exeを使用します。macOSとLinuxではcurlを使用してください。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Windowsではコマンドの先頭をcurl.exeに変更し、/dev/nullをNULに置き換えてください。例のURLはリクエストの完了を確認するためのもので、通信速度の測定には適しません。明示的なプロキシ経由でのtime_connectは、主にローカルプロキシへの接続時間を示します。最初の1バイトを受信するまでの時間には、プロキシトンネルの確立、接続先への接続、サーバーの応答も含まれるため、単純に「ノードの遅延」とは呼べません。

DNSの確認：初回表示が遅い場合と名前解決経路の違い

ウェブページの初回アクセスが遅く、再読み込みすると明らかに速い場合、DNSは確認項目の一つです。ただし、TLS接続やページキャッシュでも似た症状が起こります。まず「ログ」画面でログレベルを一時的にdebugに設定し、問題を一度再現した後、対象ドメインの名前解決失敗、タイムアウト、重複リクエストを調べます。大量のログが調査に影響しないよう、確認後は元のログレベルに戻してください。

システムの名前解決とコア内部の名前解決を区別する

システム上で実行したnslookup example.comの結果が、mihomo内部で使われている結果と同じとは限りません。ブラウザーでセキュアDNSが有効になっている場合や、コアでfake-ipを有効にしている場合があります。TUNでDNSの横取りを設定していることもあります。まず、どのコンポーネントが名前解決しているかを確認してから、変更する場所を決めてください。

• fake-ipを使用している場合：よく使われる198.18.0.0/16はマッピング用アドレスの範囲です。この範囲のアドレスが表示されても、名前解決が壊れているとは限りません。アドレスのマッピングと接続が正常か、続けて確認してください。
• DoHを有効にしている場合：DNSリゾルバーのアドレスを名前解決し、そこへ接続できる経路が必要です。プロキシ接続が確立する前の段階で、プロキシノードのドメイン解決がその接続に依存する構成は避けてください。
• IPv6を使用している場合：システムのIPv6接続、接続先のAAAAレコード、通信の取り込み設定を確認します。IPv6を一時的に無効にする場合は、比較テストの対象を明確にし、テスト後は設定を元に戻してください。
• サブスクリプションの設定を変更する場合：クライアントが対応するオーバーライドや拡張機能を優先して使ってください。サブスクリプションから生成されたファイルを直接編集すると、次回の更新時に変更が上書きされることがあります。

DNS設定を一式そのままコピーしないでください。nameserverやproxy-server-nameserverなどの項目に対応しているかは、コアとバージョンごとに確認が必要です。DNSリゾルバーを変更した後は、接続先への接続を新しく確立してください。ページを再読み込みするだけでは、システム、ブラウザー、コアのすべてのキャッシュが消えるとは限りません。

TUNと端末の性能：通信の取り込み経路に問題がある場合だけ調整する

TUNは仮想ネットワークインターフェースを通じて通信を取り込み、システムプロキシに従わないアプリにも対応できますが、速度を上げる機能ではありません。明示的なプロキシでは正常なのに、TUNを有効にするとすべてのアプリが遅くなる場合は、ルーティング、DNSの取り込み、ほかのネットワークソフトとの干渉を重点的に確認してください。

次の4項目を順に確認

1. 権限とサービス：クライアントが必要とするサービスモードや管理者権限が有効か確認します。ログにインターフェースの作成やルートの追加失敗が記録されていないかも確認してください。
2. 複数の通信取り込み：ほかのVPNや別のプロキシクライアントを一時的に終了し、通信を取り込むソフトを1つだけにして再測定します。システムのファイアウォールを長期間無効にしないでください。
3. プロセスの負荷：Windowsの「タスク マネージャー」またはmacOSの「アクティビティモニタ」で、クライアントとコアのプロセスを確認します。通信中に特定のプロセスが継続して高負荷になる場合は、ログレベル、ルールの量、コアのバージョンを比較してください。
4. MTUとUDP：小さなページは開けるのに大容量通信が止まる場合や、QUICを使うアプリだけに問題がある場合は、経路MTU、UDPの転送可否、関連ログを確認します。特定のMTU値がすべてのネットワークに適用できると考えないでください。

設定を変更できるブラウザーでは、QUICを一時的に無効にしてから完全に終了し、再起動してTCP経路が改善するか確認できます。改善しても、UDP経路を詳しく調べる必要があるという手がかりにすぎず、特定のプロトコルが必ず速いことを証明するものではありません。テスト後は元の設定に戻し、一時的な診断設定をそのまま使い続けないようにしてください。

最後に：根拠に基づいて対処し、設定を重ねて変更しない

問題を報告する際は、クライアントとコアのバージョン、OS、ネットワークの種類、発生時刻、再現手順、個人情報を削除したログを添えてください。共有前にサブスクリプションURL、アクセストークン、ノードのパスワード、管理インターフェースのキーを削除してください。設定ファイル全体をそのまま公開しないでください。

クライアントの選び方は比較・選び方ガイド、システムプロキシとTUNの基本設定はセットアップガイドをご覧ください。目指すのは、ノード、ネットワーク経路、ルール、通信の取り込み方式のどれが速度低下につながっているか、繰り返し確認できる差を見つけることです。原因がわかったら必要な変更だけを残し、最初に使った測定先で再テストしてください。