Clashの通信速度が遅い原因を段階別に診断：ノード品質・通信経路・端末設定を順に確認

まず遅い箇所を切り分ける：ページ表示・データ転送・接続の不安定さ

Clashの通信速度が遅いといっても、原因は一つとは限りません。ページを開くまで数秒かかる一方、ファイルのダウンロードは速い場合は、まずDNS、接続確立、接続先サービスの応答を確認します。ダウンロード開始後に速度が落ちる場合は、回線の混雑、ノードの速度制限、パケットロスが疑われます。特定のアプリだけ遅い場合は、プロキシを経由しているか、どのルールが適用されているかを確認しましょう。症状を切り分けてから対処するほうが、いきなりTUNを有効にしたりDNSを変更したりするより効果的です。

ここでいうClashは、クライアントとプロキシの利用環境を指します。実際に使える設定は、動作中のコアによって異なります。mihomoを使うクライアントと旧バージョンのClashクライアントでは、DNS、TUN、プロトコルの対応状況が異なる場合があります。切り分けを始める前に、クライアントの「バージョン情報」またはコア情報の画面で、クライアントとコアのバージョンを確認してください。アプリ名だけで対応状況を判断しないようにしましょう。

再現できるテスト記録を作る

• ネットワークを固定：同じPC・同じルーターを使い、まずは有線LANかルーター近くのWi-Fiでテストします。クラウド同期、OSの更新、ほかのダウンロードは一時停止してください。
• 接続先を固定：同じウェブサイト、同じファイルの配信元を使います。速度測定サイトはサーバーや同時接続数が異なるため、結果をそのまま比較できません。
• 接続方法を固定：ルールモード、実際に使うプロキシグループ、ノード名を記録します。テスト中は自動選択グループによるノード切り替えを止めてください。
• 測定時間を固定：約30秒間連続して転送し、速度が安定した区間の値を記録します。3回繰り返し、開始直後のピーク値だけで判断しないでください。
• 時刻と条件を記録：測定時刻、システムプロキシまたはTUNの状態、遅延とスループットの単位を記録します。

ノード：遅延が小さくてもダウンロード帯域が広いとは限らない

クライアントに表示されるノード遅延は通常、コアがノード経由で指定URLにリクエストを送り、応答までにかかった時間です。測定値は接続先、コネクションの再利用、ノードの出口、サービスの応答速度などに左右されます。ノードの帯域幅を測るものではなく、ICMP pingの値と一致するとも限りません。サブスクリプションにある「倍率」「高速」などの名称も、実際の転送速度の代わりにはなりません。

同じ条件で2～3個のノードを比較する

1. 対象の通信に使われるプロキシグループを開き、一時的にノードAを手動で選択します。現在のルールがネストしたプロキシグループを指定している場合は、最終的にどのノードへ接続するかも確認してください。
2. 同じ遅延テストURLに3回続けてアクセスし、最小値だけでなく値のばらつきやタイムアウトも確認します。
3. 同じ配信元のファイルを約30秒間ダウンロードします。前のテストを終了してから、ノードBで同じ手順を試してください。
4. クライアントの接続一覧を確認し、テストのリクエストが選択したノードを実際に経由しているか調べます。ルールによって測定用ドメインが別のポリシーに振り分けられていないことも確認してください。

この例では、Aは小さなリクエストを頻繁に送る用途に向き、Bは継続的なダウンロードで有利な可能性があります。ただし、接続先によって出口の経路が異なるため、別のサービスでは結果が逆になることもあります。同じ時間帯にほかのノードが正常で、特定のノードだけ遅い場合は、そのノードの負荷や速度制限、接続先までの経路を優先して確認しましょう。すぐに端末の設定を変更する必要はありません。

自動測定グループで分かること・分からないこと

url-testは主に指定URLへの遅延を基準にノードを選びます。fallbackは通常、利用可能なノードを順番に使います。どちらも最大スループットのノードを選ぶとは限りません。原因を調べる間はノードを手動で固定し、問題を確認したら自動選択に戻しましょう。測定間隔を数秒にするのは避けてください。頻繁なチェックはリクエスト数を増やし、通常利用時の状況と測定結果を比較しにくくします。

回線：ピーク時の混雑、ローカルネットワーク、接続先までの経路

プロキシ通信は、ローカルネットワーク、通信事業者の回線、ノードの入口、ノードの出口、接続先サービスを経由します。クライアントに表示される遅延の数値だけでは、どの区間が混雑しているか分かりません。毎晩遅くなり日中に回復する、または複数のノードが同時に遅くなる場合は、時間帯と入口回線ごとに比較しましょう。サブスクリプションを何度も更新しても解決につながらないことがあります。

3つの比較で原因を絞り込む

• 直接接続とプロキシ接続：まず、プロキシなしでアクセスできる普段使いのサイトをテストします。どちらも遅ければ、Wi-Fi、ルーターの負荷、固定回線を優先して確認します。直接接続は正常でプロキシ経由だけ全般的に遅い場合は、プロキシの入口や通信事業者までの経路を調べましょう。
• 固定回線とスマートフォンのテザリング：同じ端末とノードを使い、接続先だけをテザリングに切り替えます。テザリングで明らかに改善する場合は、元のネットワークや通信事業者の経路が疑われます。携帯回線の電波状況やテザリング自体の変動にも注意してください。
• 接続先の違い：同じノードから2つのサービスにアクセスします。片方だけ遅い場合は、そのサービスのCDN、出口経路、速度制限、アカウントの状態などが関係している可能性があります。ノード全体が使えないと判断するのは早計です。

たとえば、同じノードで10:00には7.5 MB/sで安定していたのに、21:00には0.8 MB/sまで低下し、ローカルの直接接続では10 MB/sを維持していたとします。この記録からは、ピーク時のプロキシ経路やノードの負荷を詳しく調べる価値がありますが、それだけで通信事業者による速度制限と断定はできません。別の入口を使うノードとスマートフォンのテザリングでも比較すると、判断の確度が上がります。

パケットロスと経路確認ツールの注意点

ゲートウェイに対してpingを続ければ、ローカルの通信が大きく不安定になっていないか確認できます。外部IPへのpingやtracerouteは、経路の一部を調べる補助として使えます。途中のルーターがICMPへの応答を優先しない場合もあり、ある区間から応答がなくても、実際の通信がそこで失われているとは限りません。通常のtracerouteで「端末からプロキシノードを経由して接続先へ」という経路全体が自動的に分かるわけではありません。プロキシトンネル全体の経路報告として扱わないでください。

端末：システムプロキシ、ルール、実際の接続先を確認する

システムプロキシが影響するのは、通常、システムのプロキシ設定を参照するアプリだけです。すべてのTCP・UDP通信が自動的にプロキシ経由になるわけではありません。ターミナル、ゲーム、一部の独自ネットワーク機能はシステムプロキシを使わない場合があります。TUNは仮想ネットワークインターフェースとルーティングを使って対象の通信を取り込み、より広い範囲をカバーします。その一方で、ルーティング、権限、DNSとの連携が影響することがあります。

接続記録から通信の経路を確認する

1. クライアントがルールモードになっていることを確認してから、問題が起きているウェブサイトやアプリを開きます。
2. クライアントの接続一覧を開き、接続先のドメインまたはIPアドレス、適用ルール、ポリシーの経路、転送量を確認します。画面上の項目名は「接続」または「Connections」の場合があります。
3. リクエストにDIRECTが適用されている場合は、前にあるドメインルール、ルールセット、LAN向けルールが意図どおりか確認します。
4. プロキシ経由になっていても別のノードグループが使われている場合は、メイン画面で目立つグループだけを変更せず、ルールが指定しているポリシーグループを確認してください。
5. 該当する接続が一覧にない場合は、アプリ独自のプロキシ設定、プロキシの除外リスト、その通信が現在のコアに届いているかを確認します。

ルールは上から順に評価され、先に一致した時点で通常は後続のルールへ進みません。切り分けのため、一時的にグローバルモードへ切り替え、同じノードで比較する方法があります。グローバルモードで正常になる場合は、ルールとポリシーグループを重点的に確認しましょう。グローバルモードではほかのアプリの通信経路も変わるため、テスト後は元のモードに戻してください。

明示的なプロキシリクエストでアプリ設定の違いを切り分ける

以下のコマンドは、ローカルのHTTP混合プロキシポートが7890の場合に使えます。実行中の設定でmixed-portを確認し、実際のポートが異なる場合はコマンド内のポート番号を変更してください。macOSとLinuxではcurl、Windows PowerShellでは環境によるコマンドエイリアスの違いを避けるため、curl.exeの使用をおすすめします。

curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --connect-timeout 10 --max-time 20 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

curl.exe --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 -o NUL -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

この204リクエストで確認できるのは、接続と応答にかかる時間であり、ダウンロード帯域幅ではありません。ローカルHTTPプロキシを使う場合、time_connectは主にローカルのプロキシポートへの接続時間を示すもので、ノードまでの往復遅延とは異なります。TLSと最初の1バイトまでの時間はリクエスト開始からの累積値で、各段階だけの所要時間ではありません。コマンドでは正常なのにブラウザーが遅い場合は、ブラウザーのプロキシ設定、拡張機能、内蔵のセキュアDNS、キャッシュを確認しましょう。

DNS：名前解決の遅延、Fake-IP、ブラウザーのセキュアDNS

DNSが影響しやすいのは、初回アクセスやドメインに基づく振り分けです。すでに確立した接続で大容量ファイルを転送するときのスループットを、直接改善するものではありません。ページを初めて開くときは3秒かかるのに、再読み込みすると速い場合は、名前解決、接続の再利用、キャッシュなどが関係している可能性があります。この現象だけでDNSの障害とは断定できません。ログで名前解決のタイムアウトがないか、接続先が想定したドメインになっているかも確認してください。

実際に使われている名前解決の経路を確認する

• サブスクリプションの元ファイルを見るだけでなく、実行中の設定でdns.enable、enhanced-mode、上流DNSサーバー、関連するポリシーを確認します。
• ブラウザーでDNS over HTTPSが有効になっていると、ブラウザー独自の経路で名前解決する場合があります。一時的に無効にして比較し、最終的にどの名前解決経路を使うか判断してください。
• 上流DNSサーバーへ実際に接続できることを確認します。到達できないDNSサーバーを設定すると、応答待ちが発生したり、フォールバックが実行されたりします。
• DNSサーバーをホスト名で指定している場合は、そのホスト名を解決するためのブートストラップDNSも確認してください。名前解決が循環しないようにします。

Fake-IPは、マッピング用のアドレスを使ってドメインと接続を関連付け、コアがドメインルールを適用できるようにします。よく使われる設定範囲は198.18.0.1/16で、ウェブサイトの実サーバーのアドレスではありません。アプリにこの範囲のアドレスが割り当てられても、ノードの異常を意味するわけではありません。一部のLANサービスや特殊なアプリではfake-ip-filterなどで個別に対応します。すべてのドメインを除外すると、想定していたドメイン判定が変わる可能性があるため避けてください。

理由なくFake-IPとredir-hostを何度も切り替えないでください。変更は一度に1項目だけにし、関連する接続を再起動します。必要に応じてクライアントの手順に従ってDNSキャッシュを削除し、同じ条件で再テストしてください。システムの名前解決ツールの結果が、ブラウザーやプロキシコアの結果を示すとは限りません。明示的なHTTPプロキシリクエストでは、接続先のホスト名がプロキシ側で処理されることが多く、ローカルで実行したnslookupだけでは名前解決の全経路を検証できません。

TUN：対象範囲、UDP、ルーティングの競合

TUNは通信を取り込む方式であり、帯域幅を増やすスイッチではありません。システムプロキシで通常のウェブ閲覧が問題なくできるなら、TUNを有効にしても必ず速くなるとは限りません。一方、システムプロキシを参照しないアプリは、TUNで通信を取り込んで初めてプロキシ経由になる場合があります。この場合の改善は通信経路が変わったためであり、TUNがノードの容量を増やしたわけではありません。

モードを比較するときは同じノードを使う

1. 設定のコピーを保存し、ノード、ルールモード、DNS設定を記録します。
2. まずTUNを無効にし、システムプロキシに対応するブラウザーか、プロキシを明示したコマンドでテストします。
3. 次に、クライアントの手順に従ってサービスモードを有効にするか必要な権限を付与し、TUNを有効にします。ルーティングと接続記録に実際の変化があるか確認してください。
4. TUNモードだけで問題が起きる場合は、ほかのVPN、仮想ネットワークアダプター、ルールベースのルーティング、DNSの取り込みが競合していないか調べます。
5. テスト後は普段の設定に戻してください。通信経路を確認する前に、TUNスタック、DNS、ノードのプロトコルを同時に変更しないでください。

ブラウザーのHTTP/3は通常、QUICを使うUDP通信です。システムHTTPプロキシとTUNで処理方法が異なることがあり、アプリ、コア、ノードのUDP対応状況にも左右されます。動画の読み込みや一部のサイトで問題が出る場合は、アプリのQUICを一時的に無効にして比較できます。TCPは正常でUDPだけ問題がある場合は、UDPの経路を調べましょう。すべてのダウンロードに同じ結論を当てはめないでください。

MTUの調整は後回しにする

小さなリクエストは成功するのに大きなデータ転送が何度も止まり、特定のトンネル構成でだけ問題が起きる場合は、経路MTUを確認します。一般的な有線LANのMTUは1500ですが、カプセル化によって利用可能なペイロードが小さくなることがあります。関連する兆候がある場合は、TUNのMTUを一時的に1400にして比較できます。元の値は必ず記録して戻せるようにしてください。1400があらゆる環境で最適というわけではありません。改善しなければ元に戻し、パケットロスやルーティングを調べます。

端末のCPU、メモリ、セキュリティソフトの動作も同時に確認します。その端末だけ遅く、転送中に特定のCPUコアが継続してほぼ100%になる場合は、暗号化処理、通信検査、クライアントの負荷が関係している可能性があります。古い端末で複数の速度測定を同時に実行しながらプロトコルを比較するのは避けてください。会社や組織の端末では、セキュリティポリシーの確認を管理者に依頼し、テストのために保護機能を直接無効にしないでください。

原因を絞り込む：一度に変更するのは1項目だけ

有効な切り分けで分かるべきなのは、「どの層で、どの条件のとき、どの比較結果に変化があったか」です。考えられる原因を並べるだけでは解決につながりません。設定を変更するたびに変更前後の結果を記録しましょう。3項目を同時に変えて速度が戻っても、どの変更が効いたのか分からなくなります。

ノードのサービス提供者やクライアントの開発者に問い合わせる場合は、クライアントとコアのバージョン、OS、発生時刻、ネットワークの種類、接続モード、接続先サービス、3回分の測定結果、関連するエラーメッセージを添えてください。公開前にサブスクリプションURL、認証情報、ノードのパスワード、アクセストークンを削除してください。設定ファイルやログには、これらの情報が含まれている場合があります。

おすすめの順序は、リクエストがプロキシを経由しているか確認し、ノードを固定して比較し、時間帯とネットワークを調べてから、DNS、TUN、端末の負荷を確認することです。ルール用語を確認するには用語集を、具体的なエラーが出ている場合はトラブル対処をご覧ください。サブスクリプションの更新は設定の取得に使うもので、現在のノードの回線混雑を直接解消する方法ではありません。