Clashの通信速度が遅いときの原因切り分け｜ノード品質・回線混雑・ローカル設定

まずは高遅延・ダウンロード速度の低下・ページの初回表示の遅さを切り分ける

Clashクライアントに表示される遅延は、通常、コアが指定されたテスト先へプロキシ経由でアクセスしたときの測定値であり、継続的なダウンロード帯域を示すものではありません。テスト先やタイムアウト時間、クライアントの実装によって数値は変わります。遅延が80ミリ秒のノードでも、出口の速度制限によってダウンロード速度が非常に低いことがあります。一方、遠距離で遅延が220ミリ秒のノードでも、継続的なスループットが高い場合があります。

調査を始める前に、「遅い」と感じる状況を観測可能な形で記録します。OS、クライアント名、コアのバージョン、現在の設定、プロキシモード、実際に選択されているノード、問題が起きたネットワーク環境を記録してください。クライアントとコアのバージョンは別々に確認し、バージョン情報や起動ログから記録します。「最新版」とだけ書くのは避けましょう。

テスト条件を固定し、一度に複数の要因を変えない

まず、バックグラウンドでの大容量ダウンロード、クラウドストレージの同期、ほかの速度測定を停止します。Wi-Fiはできるだけ同じ場所で利用し、可能であれば有線接続でも一度テストしてください。ルーターで別のVPN、透過プロキシ、振り分けサービスを使っている場合も記録し、二重プロキシの結果を単一の接続結果と混同しないようにします。

1. ローカル回線の基準値を測る：クライアントのシステムプロキシとTUNを無効にし、ブラウザーに個別のプロキシ設定がないことを確認してから、ローカルネットワークから直接アクセスできる速度測定サービスでダウンロード、アップロード、遅延を記録します。この測定で分かるのはインターネット接続の帯域であり、プロキシの出口性能ではありません。
2. テスト先を固定する：テストが許可されているHTTPSのダウンロード先を1つ選び、すべてのノードで同じURL、ダウンロード方法、同時接続数を使います。速度測定サーバーの違いを余計な変数にしないでください。
3. 出口を固定する：実際に通信へ適用されるプロキシグループを、手動で選んだ単一ノードに切り替えます。テスト中に自動選択やフェイルオーバーで出口が変わらないようにしてください。
4. 3回繰り返す：各回を約30秒間実施し、回ごとに約15秒空けて、中央値と実施時間帯を記録します。大容量のテストはサブスクリプションの通信量を消費するため、必要に応じて短縮してください。

ノードを切り替えたら、実行中のダウンロードを停止して新しい接続を確立します。既存のTCP接続は、通常、プロキシグループを切り替えても別の出口へ自動的に移りません。接続を閉じる必要がある場合は、ほかの作業を中断しないよう、まずテスト用アプリの接続だけを終了してください。

たとえば記録には「ノードA：2.1、2.4、2.2 MB/s、中央値2.2 MB/s」と書けます。これは記録形式の例であり、本サイトでの実測値ではありません。比較時は失敗回数も記録してください。3回中2回タイムアウトしたなら、単発の最高速度よりも利用可能性をよく示しています。

ノード品質：単一ノードのスループットと接続先サイトの表示を比較

ノード品質には、入口への接続性、サーバー負荷、速度制限、出口から接続先サイトまでの通信状況が関係します。クライアントの「ワンタップ速度測定」が遅延の測定だけなら、その結果からノードの帯域を判断することはできません。同じサブスクリプションから候補を2～3個選び、同じ条件でそれぞれテストしたうえで、実際の利用環境でも確認しましょう。

接続ログで、テストが目的のノードを経由しているか確認する

1. クライアントの「接続」画面を開き、新しいダウンロードを開始します。
2. 接続先ドメインまたはプロセスで絞り込み、適用されたルールとプロキシの経路全体を確認します。
3. 最終的な出口が選択したノードであり、DIRECTや別のプロキシグループではないことを確認します。
4. proxy-providersを使っている場合は、そのプロキシプロバイダーの更新状況とヘルスチェックの状態を確認します。これは設定ファイル全体の更新とは別のものです。

複数の接続先でノードAが遅く、同じ時間帯にノードBが明らかに速い場合は、まずAの負荷、速度制限、経路の問題を疑います。同じノードでも特定のサイトだけ遅く、ほかのダウンロードが正常なら、そのサイトまでの出口経路やCDNの割り当てに差がある可能性が高く、ノード全体の障害と即断するのは適切ではありません。

回線混雑：時間帯と接続ネットワークを変えて検証する

ノード名の地域表示は通常、出口の場所を示すもので、ローカルから入口を経由して出口へ至る経路全体は分かりません。異なる地域のノードでも入口や中継経路を共有している場合があります。そのため、地域を変えても遅いからといって、回線の問題を除外することはできません。

2つの軸で比較する

• 同じネットワーク・異なる時間帯：たとえば同じノードと接続先を、10時と21時に測定します。複数日にわたり夜間の速度が明らかに落ちるなら、一度だけ遅くなる場合より、ピーク時の混雑が疑われます。
• 同じ時間帯・異なるネットワーク：数分以内に自宅の固定回線とスマートフォンのテザリングを比較します。クライアント、ノード、接続先は変えず、テザリング側の電波状況やデータ通信の制限にも注意してください。
• 同じネットワーク・異なる入口回線：サービス提供元が回線について明確に説明している場合は、入口の異なるノードを比較します。名前だけから回線が独立していると判断しないでください。

自宅の固定回線では複数のノードが遅く、テザリングでは改善する場合、原因は自宅の接続、通信事業者間の接続、またはローカルルーターに近いと考えられます。同じノードが2つのネットワークで遅く、ほかのノードが正常なら、そのノードや出口を重点的に確認しましょう。いずれも原因を絞り込むための手がかりであり、一度の測定だけで結論が出るわけではありません。

大容量のアップロード中にルーターの遅延が急増するかも確認できます。アップロード帯域を使い切ると、キューの待ち時間が増え、Web閲覧や対話的な通信にも影響します。アップロードを止めると改善するなら、帯域の使用状況とルーターのキュー管理を先に確認してください。途中のルーターがプローブに応答しないことはよくあります。特定のホップでパケットロスがあっても、実際の通信でパケットロスが起きているとは限りません。

ルールとDNS：遅い通信が実際に通る経路を確認する

診断時はルールモードを使い、実際に適用されたルールを確認します。Clashとmihomoでは通常、ルールは上から順に評価され、後方のドメインルールより先に前方のルールが適用される場合があります。末尾のMATCHはほかに一致しない通信の受け皿です。対象ドメインをその後ろに追加しても、通常は期待した結果になりません。

全体モードは短時間の比較に使い、常用しない

現在の設定を理解したうえで、短時間だけ全体モードに切り替え、全体モードで使うノードを明示的に選択できます。同じノードでも全体モードでは正常、ルールモードでは異常なら、ルールモードで別のプロキシグループ、直結経路、または多段経路が選ばれていないかを確認してください。テスト後は元のモードに戻します。全体モードでは、本来なら直接接続する通信の行き先まで変わる場合があります。

DNSの待ち時間とデータ転送の遅さを切り分ける

• 初回アクセスだけ遅く、次のリクエストは速い場合：名前解決にかかる時間、キャッシュ、接続の再利用を確認します。すぐにDNS関連の設定をすべて変更しないでください。
• 特定のドメインへのリクエストが失敗し、ほかのサイトは正常な場合：ログに名前解決のタイムアウトがないか確認し、上流DNSに到達できるか調べます。
• ブラウザーとほかのアプリで結果が異なる場合：ブラウザーのセキュアDNS設定を確認します。システムと異なる名前解決経路を使っている可能性があります。
• Fake-IPを有効にしたときに198.18.0.0/16の範囲のアドレスが表示されるのは、仮想的なアドレス割り当てとして正常な場合があります。このアドレスだけを根拠にDNS障害と判断しないでください。実際に使われる範囲は設定によって異なります。

mihomoのdns.nameserver、dns.proxy-server-nameserver、dns.nameserver-policyは、それぞれ通常の名前解決、プロキシサーバーのドメイン解決、ドメインごとのDNSサーバー選択に関係します。実際の動作は設定全体によっても変わります。ネット上のDNS設定を既存のサブスクリプションにそのまま追加しないでください。変更前にバックアップを取り、項目を1つずつ変更して再読み込みし、新しい接続でテストします。項目の説明は設定マニュアルのDNSセクションを参照してください。

システムプロキシとTUN：アプリへの適用範囲とローカル負荷を確認する

システムプロキシは、主にシステムのプロキシ設定に従うアプリで使われます。TUNは仮想ネットワークインターフェースとルーティングを使って、より多くのIP通信を取り込みますが、実際の適用範囲はルートの除外設定、アプリが使用するインターフェース、クライアントの実装に左右されます。TUNは速度を上げるスイッチではなく、ノードの速度制限を回避することもできません。

まず明示的なプロキシ設定で切り分ける

以下のコマンドは、ローカルのHTTPプロキシまたは混合プロキシが127.0.0.1:7890で待ち受けていることを前提とします。クライアントのポート設定で実際の値を確認してください。7890はすべてのクライアント共通の固定ポートではありません。Windowsでは、PowerShell環境によって同名の別名が引数に影響することがあるため、curl.exeを使えます。

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}\nTLS=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
  https://www.example.com/

これはmacOSやLinuxなどで使える、短時間のリクエスト診断コマンドであり、帯域測定ではありません。Windowsではcurlをcurl.exeに、出力先をNULに置き換え、コマンドを1行にまとめてください。時間の単位は秒で、各項目はリクエスト開始からの累積時間です。ローカルHTTPプロキシを使う場合、time_connectが示すのは主にローカルのプロキシ待ち受けポートへの接続であり、リモートノードまでの遅延ではありません。

明示的なプロキシ経由のリクエストは正常なのに、通常のアプリが遅い場合は、アプリがシステムプロキシに従っているか、個別のプロキシ拡張機能を使っていないか、システムプロキシの接続先が現在のクライアントのポートになっているかを確認します。接続拒否のエラーが出る場合は、まずコアが起動しているか、待ち受けアドレスが正しいか、ポートが使用中でないかを確認してください。先にDNSを変更する必要はありません。

2種類の通信制御方式を個別にテストする

1. 現在の設定を保存し、TUNを無効にしてシステムプロキシだけを有効にします。同じブラウザーと接続先でテストしてください。
2. 次にシステムプロキシを無効にしてTUNだけを有効にし、テスト通信が接続ログに表示されることを確認してから、同じテストを繰り返します。
3. タスクマネージャーまたはアクティビティモニタでコアのCPU使用率を確認します。別のVPNや仮想ネットワークインターフェースがルートを書き換えていないかも確認してください。
4. TUNだけで遅延や引っかかりが発生する場合は、クライアントのログ、ルートの競合、現在のネットワークとの互換性を確認し、クライアントがサポートする範囲でプロトコルスタックの設定を比較します。

CPUの単一コア使用率が継続的にほぼ100%に達し、スループットも制限されている場合は、ローカル処理がボトルネックになっている可能性があります。TUNのプロトコルスタック、MTU、DNSを一度に変更しないでください。特にMTUは、大きなパケットの転送が止まるなどの根拠がある場合に比較検証し、特定の数値を万能な答えとして設定しないでください。

切り分け結果を再現可能な問題として整理する

一度に変更する項目は1つにし、変更前後の結果を保存します。次の対応関係は次の手順を決める目安になりますが、ログと繰り返しのテストもあわせて確認してください。

クライアントのメンテナーやサブスクリプション提供元に報告する際は、OSのバージョン、クライアントとコアのバージョン、発生した時間帯、接続ネットワーク、再現手順、機密情報を削除したログを添えてください。サブスクリプションURL、トークン、認証情報、不要なアクセス先ドメインは削除します。次の手順としてクライアントやコアを更新するのは、互換性の問題や明確な修正記録が確認できた場合に限り、元に戻せるよう設定を保存しておきましょう。

手順は、まずローカル回線の基準値を測り、次にノードを固定してスループットを比較し、その後、回線を変えて検証してから、ルール、DNS、通信の取り込み方式を確認します。サブスクリプションの更新失敗や遅延の問題を続けて調べる場合は、トラブルシューティングの遅延診断を参照してください。インポートや有効化の手順がまだ不明な場合は、まずサブスクリプションのインポートガイドで基本設定を確認しましょう。