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

Clashのノード一覧では80msと表示されるのに、動画はバッファリングする。一方、180msのノードに変えたらダウンロードが速くなった。これは矛盾ではありません。遅延測定、連続転送、アプリの読み込み時間は、それぞれ異なるものを測っています。まず遅い箇所を特定し、ノード、経路、端末の順に確認しましょう。DNSやルール、TUNの設定を次々と変えるより、原因を見つけやすくなります。

1. 遅延が大きい、転送速度が低い、ページの表示開始が遅い状態を区別する

Clash系クライアントの「遅延」は通常、ノード経由でテスト先にリクエストを送った結果です。ICMP pingと同じものではなく、利用できる帯域を直接示すものでもありません。テスト先、タイムアウト時間、コネクションの再利用などによって結果は変わります。テスト先を別のサイトに変えれば数値が変わることがありますが、動画配信サービスの使い勝手が改善するとは限りません。

再現可能な速度測定の条件を整える

1. クラウドストレージの同期、ゲームの更新、ほかの端末での大容量ダウンロードを一時停止します。ノートPCは電源に接続し、安定したWi-Fiまたは有線LANを使いましょう。
2. 同じ端末、同じダウンロード元、同じ接続方式に固定し、テストが許可されている十分なサイズのファイルを選んで、30秒以上連続で転送します。
3. 各条件で3回測定し、中央値を記録します。開始直後の数秒に出るキャッシュ由来のピークだけを記録したり、複数のノードを同時に測定したりしないでください。
4. 直接接続とプロキシ経由の結果をそれぞれ記録します。直接接続できない接続先の場合は、直接接続できる比較対象を使いましょう。接続に失敗した結果を帯域ゼロとして扱ってはいけません。

単位に注意してください。100 Mbpsの理論上の転送上限は約12.5 MB/sで、実際の速度はプロトコルのオーバーヘッド分だけ低くなります。ダウンロードツールで10 MB/sと表示されても、100 Mbps回線の速度が10分の1しか出ていないわけではありません。ブラウザーでの複数接続と単一接続では速度が大きく異なることもあるため、分けて記録しましょう。

2. 第1段階：ノードの品質と実際に選択されている経路を確認する

まずクライアントの「接続」画面で、テスト中のドメインを見つけ、適用されたルール、プロキシグループ、最終的に選択されたノードを確認します。ルールモードでは、画面上のプロキシグループを切り替えても、現在のリクエストに反映されるとは限りません。ネストされたプロキシグループが別の自動選択グループを参照している場合もあります。接続中の通信は、選択を切り替えてもすぐには再接続されないことが多いため、ダウンロードを止めてリクエストをやり直してください。必要な場合に限り、該当する既存の接続を閉じます。

遅延の最小値だけで選ばず、3つのノードを比較する

• 同じ地域の異なるノード：特定のノードだけが混雑しているかを確認します。できるだけ入口や経路の識別情報が異なるノードを選びましょう。
• 異なる地域のノード：接続先サービスが、特定の出口地域や通信事業者との相互接続経路に影響されていないかを確認します。
• 同じノードを時間帯別に測定：昼と夜にそれぞれ測定します。夜だけ大きく遅くなる場合は、回線容量や相互接続の混雑が考えられます。まず端末のMTUを変更するのは避けましょう。

たとえば、ノードAは遅延65ms、連続ダウンロード1.2 MB/s、ノードBは遅延145ms、連続ダウンロード8.0 MB/sだったとします。この例から分かるのは、その大容量ファイルの転送ではBのほうが適していたということだけです。ゲームやWebサイトすべてでBが優れているとは限りません。テスト先、時刻、ノードをセットで記録し、条件の異なる数値をそのまま比較しないようにしましょう。

サブスクリプションの更新で解決できるのは、設定やノード情報が古くなっている場合です。回線容量が増えるわけではありません。まずサブスクリプションの有効期限が切れていないか、通信量を使い切っていないか、サーバーから速度制限の通知がないかを確認し、その後で1回だけ手動更新します。更新に失敗した場合も、動作中の設定は残してエラー内容を確認してください。何度も削除して作り直す必要はありません。

3. 第2段階：端末からの入口、出口経路、接続先を分けて確認する

プロキシ接続では、端末からノードの入口までと、ノードから接続先までの少なくとも2つの経路が関係します。ノードを変更すると複数の条件が同時に変わるため、「切り替えたら速くなった」だけでは原因を特定できません。追加で効果的なのは、ノードを変えずにPCの接続を自宅の固定回線からスマートフォンのテザリングに切り替え、同じ作業をもう一度試すことです。

パケットロスの確認では、中継区間だけでなく接続先まで確認する

Windowsでは、次のコマンドでパブリックIPアドレスへの基本的な疎通を確認できます。このアドレスはネットワークの確認先であり、設定に記述するDNSサーバーではなく、ノードへの経路を示すものでもありません。TUNが有効な場合、プローブがコアを経由するかどうかはルーティング設定とICMPの対応状況によって異なります。直接接続の基準を取るには、まずTUNを一時停止し、システムのルートが元に戻ったことを確認してください。

ping -n 30 1.1.1.1
tracert -d 1.1.1.1

中継ルーターがICMPへの応答を制限していることがあります。途中のホップがタイムアウトしても接続先が正常なら、それだけで経路上のパケットロスとは判断できません。接続先から応答がなくても、Webサイトが利用できないとは限りません。アップロード帯域を使い切っていると、ダウンロードの確認用パケットやWebリクエストが待たされることがあります。アップロードを一時停止して再測定しましょう。この場合、通常はプロキシの通信方式を変更する必要はありません。

4. 第3段階：システムプロキシ、TUN、アプリ設定の競合を確認する

システムプロキシとTUNは、通信をプロキシ経由にするための異なる方式です。システムプロキシは主にOSのプロキシ設定に従うアプリで使われます。TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。両方を有効にしても必ず競合するわけではありませんが、トラブルの切り分け中はどちらか一方にすると、通信経路を確認しやすくなります。

まずシステムプロキシだけでテストする

1. ほかのVPNやプロキシツールを終了し、使用中のクライアントではTUNをオフにして、システムプロキシを有効にします。
2. Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシやスクリプトの設定が意図した内容になっているか確認します。macOSでは「システム設定」→「ネットワーク」→使用中のネットワーク→「詳細」→「プロキシ」を開き、ほかのツールの設定が残っていないか確認してください。
3. クライアントが実際に待ち受けているポートを確認します。以下ではローカルのHTTPまたはmixedポートとして7890を例に使います。これはよくある例で、すべてのクライアントに共通する固定の初期値ではありません。
4. 明示的にプロキシを指定したリクエストと、ブラウザーでの結果を比較します。Windows PowerShellでは、古い環境でのcurlエイリアスの挙動の違いを避けるため、curl.exeを使ってください。

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

この簡易テストでは、リクエストが完了するか、最初の応答までに異常な時間がかかっているかを確認できますが、最大ダウンロード速度は測定できません。HTTPプロキシ経由の場合、time_connectが主に示すのはローカルのプロキシとの接続確立であり、リモートノードまでの遅延ではありません。time_starttransferには、その後のネゴシエーションやサーバーの応答待ちも含まれます。macOSやLinuxではcurlを使い、NULを/dev/nullに置き換えてください。

次にTUNだけをテストする

システムプロキシをオフにしてTUNを有効にし、同じノードと接続先のまま接続をやり直します。TUNだけ遅い場合は、クライアントのサービス権限、仮想インターフェース、ルーティング、ほかのVPNの残存設定を確認してください。明示的なプロキシリクエストは速いのにブラウザーだけ遅い場合は、ノードを買い直すのではなく、ブラウザーのプロキシ拡張機能、セキュアDNS、キャッシュを優先して調べます。

ゲーム、音声通話、一部の動画通信ではUDPを使うことがあります。HTTPプロキシのテストに成功しても、確認できるのは対象のTCPリクエストが使えることだけで、UDP経路が正常だとは限りません。アプリの通信がプロキシに取り込まれているか、ノードのプロトコルが必要な転送に対応しているか、サーバーがUDPを許可しているかを確認し、接続ログで実際の通信を確かめましょう。UDPをすべて無効にする方法は、汎用的な速度改善策ではありません。

5. DNSとMTU：症状に応じて確認・調整する

ページの初回表示が遅い場合は、まず名前解決の経路を確認する

ページを初めて開くと遅く、再読み込み後は正常な場合、ログに名前解決のタイムアウトが繰り返し記録されていないか、DNSの上流サーバーに到達できるかを確認します。mihomoのfake-ipモードでは仮想アドレスが返るのは正常な動作の場合があります。198.18.0.0/16の範囲のアドレスが表示されたという理由だけで、名前解決のエラーと判断しないでください。ブラウザーのセキュアDNS、OSの名前解決、コアのDNSはそれぞれ異なる経路を使うことがあるため、実際の通信の取り込み方に応じて確認しましょう。

• 正常に動作しているDNS設定を基準として残し、仕組みをよく知らない上流サーバーを一度に大量追加しないでください。
• ルールによってDNSの上流サーバーとの循環依存が起きていないか確認します。特に、プロキシ接続の確立前にドメイン名の解決が必要な場合は注意してください。
• DNSまたはfake-ipの設定を変更したら、クライアントの手順に従って再読み込みし、既存の接続を閉じてから再測定します。Windowsではipconfig /flushdnsでシステムのDNSキャッシュを削除できますが、すべてのアプリやコアのキャッシュが消えるわけではありません。

大きなパケットで停止する場合や、TUNだけで問題が起きる場合にMTUを確認する

MTUは、リンク上で転送できる最大のパケットサイズです。カプセル化のオーバーヘッドやパスMTU探索の妨げにより、小さなリクエストは通る一方で、大きなファイルや一部のTLS接続が停止することがあります。ただし、1500、1480、1400のどれも、すべてのネットワークに適した固定値ではありません。MTUを下げてもノードの帯域が自動的に増えるわけではありません。

Windowsでは、コマンドプロンプトからIPv4のフラグメント禁止パケットをテストできます。イーサネットのMTUが1500の場合、ICMPデータ1472バイトに通常のIPv4ヘッダーとICMPヘッダーの合計28バイトを加えると1500バイトになります。失敗した場合は、比較のためデータサイズを1400バイトにして試せます。

ping -4 -f -l 1472 -n 4 1.1.1.1
ping -4 -f -l 1400 -n 4 1.1.1.1
netsh interface ipv4 show subinterfaces

接続先がICMPを遮断している可能性があり、この2つのpingでプロキシトンネルの実際の経路を確認できるとも限りません。結果はあくまで手がかりとして扱ってください。TUNで大きなパケットの問題が起きていると確認できた場合は、まず現在のTUN MTUを記録し、使用中のクライアントまたはmihomoのTUN設定だけを一時的に1400へ変更して、関連する接続を再起動してから再測定します。改善しなければ元に戻してください。物理ネットワークアダプターをまとめて変更したり、このIPv4用の計算式をIPv6に当てはめたりしないでください。

6. 結果を整理し、根拠のない設定変更を繰り返さない

3段階の比較を行えば、問題の範囲をかなり絞り込めます。サービス提供元やクライアントの開発者に連絡するときは、「速度が遅い」と伝えるだけでなく、再現できる手順を共有しましょう。次の項目を記録すれば、調査に役立つ情報をまとめられます。

• 実行環境：OSとクライアントのバージョン、コアの名称とバージョン、TUNの有効・無効、実際の待ち受けポート。
• テスト条件：実施した日時、自宅の固定回線かスマートフォンのテザリングか、接続先サービス、単一接続か複数接続か。
• 比較結果：同じノードで3回連続測定した速度の中央値、ノード切り替え前後の結果、最初の応答までの時間。
• 通信経路：適用されたルール、最終的に選択されたノード、失敗したリクエストの前後に必要なログ。認証情報は削除してください。

使用中のクライアントやコアのメンテナンスが長期間止まっている場合は、サブスクリプションとカスタムルールをバックアップしてから、OSに対応したメンテナンス中のクライアントへ移行しましょう。移行後は最小限の設定で接続し、上書き設定、ルール、TUNの設定を一つずつ追加すれば、以前の環境の競合をそのまま引き継がずに済みます。基本操作はClash設定ガイドを、接続失敗や速度測定のタイムアウトは遅延測定に関するよくある質問をご覧ください。