Clashが遅いときの原因と対処法｜ノード・回線・端末設定を順に確認

Clashの通信速度が遅くても、ノードの帯域不足とは限りません。Webページの表示に時間がかかる、動画の再生中に何度も止まる、ダウンロード速度が低い状態が続くといった症状は、それぞれDNSの名前解決、回線の混雑、端末での通信処理に原因がある可能性があります。まず症状を切り分けましょう。DNS、ノード、TUNの設定を一度に変更するより、順番に確認するほうが原因を見つけやすくなります。

準備：再現可能な速度測定の基準を作る

まず、クラウドストレージの同期、システム更新、ほかの大容量ダウンロードを一時停止し、端末・ネットワーク・接続先を固定します。ルールモードを使う場合は、接続詳細で実際に適用されたルール、プロキシグループ、ノードを確認してください。想定したノードを経由していない測定結果では、そのノードの性能を判断できません。

1. 環境を記録：クライアントのバージョン、コアのバージョン、OSのバージョン、接続中のネットワーク、ノード名、システムプロキシとTUNの有効・無効を記録します。コアのバージョンは、クライアントの「バージョン情報」画面や起動ログで確認できます。
2. 使用するノードを固定：クライアントのプロキシまたはプロキシグループ画面でノードを手動選択し、テスト中に自動選択が切り替わらないようにします。手動で固定できない設定の場合は、接続ごとに実際に選ばれたノードを記録してください。
3. 項目ごとに測定：Webページの初回応答時間、継続ダウンロード速度、失敗回数を記録します。各項目を3回ずつ測定し、測定間隔は約30秒空けます。一度だけ出た最高値を安定した速度とみなさないでください。
4. 単位をそろえる：理論上、100 Mbpsは約12.5 MB/sです。実際の速度はプロトコルのオーバーヘッドなどによって変わります。クライアントに表示されるMB/sと、回線契約に記載されたMbpsはそのまま比較できません。

第1段階：ノード品質と実際の転送速度

ノードの遅延とダウンロード速度は別の指標

クライアントの遅延測定は通常、指定されたURLにリクエストを送り、その経路の応答状況を確認するものです。継続的なデータ転送能力を示すわけではありません。遅延が60 msのノードでも、出口帯域を共有していればダウンロードが遅いことがあります。一方、160 msのノードでも、安定した転送速度が得られる場合があります。url-testを使うプロキシグループも、自動で帯域を測定する機能ではありません。

まず同じ地域のノードを2～3個選び、同じファイルを各ノードで3回ずつダウンロードします。測定先、同時接続数、測定時間をそろえてください。特定のノードだけ明らかに遅い場合は、そのノードを優先して確認します。すべてのノードが遅い場合は、同じ入口や中継リソースを共有していないか調べてください。

プロキシポートを指定して再測定する

デスクトップでは、curlでHTTPプロキシを明示的に指定すると、コマンドラインのプログラムがシステムプロキシ設定を読み込んでいない可能性を除外できます。以下は待ち受けを確認済みのローカルHTTPポートまたはmixedポート7890を使う例です。7890がすべてのクライアントの既定値とは限らないため、必ず使用中のポートを確認してください。コマンドは公開テスト用エンドポイントから約10 MBをダウンロードするため、その分の通信量が発生します。

# macOS / Linux；curlがインストールされていること
curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --max-time 60 --write-out 'connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n' 'https://speed.cloudflare.com/__down?bytes=10000000'

# Windows PowerShell；curl.exeを明示して実行
curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --max-time 60 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n" "https://speed.cloudflare.com/__down?bytes=10000000"

speed_downloadの単位はバイト毎秒です。たとえば2500000 B/sは約2.5 MB/sです。これは数値の読み方を示す例であり、本サイトで測定した結果ではありません。小さなファイルではハンドシェイクの影響を受けやすいため、結果はあくまで目安として使ってください。影響が出ている実際のWebサイトでも確認し、1つの測定サービスの結果だけであらゆる通信を判断しないようにしましょう。

第2段階：入口・中継・出口の回線

ノード名が異なっていても、ネットワーク経路が完全に独立しているとは限りません。異なる地域と表示された2つのノードが、同じ接続入口や中継リソースを共有している場合もあります。複数のノードが同じ時間帯に一斉に遅くなるなら、地域を変えるだけでは改善しない可能性があります。

時間帯と接続ネットワークを変えて比較する

• 時間帯を比較：たとえば10:00と21:00に、同じノードから同じファイルをダウンロードします。夜間だけ速度が継続して低下する場合は、まず回線の混雑を疑いましょう。すぐにローカルDNSを変更する必要はありません。
• 接続ネットワークを比較：同じ端末を自宅のブロードバンド回線とスマートフォンのテザリングにそれぞれ接続して測定します。テザリングを試す前にデータ通信量の上限を確認し、バックグラウンドのダウンロードを停止してください。自宅の回線だけで問題が起きる場合は、ルーター、ISPまでの経路、Wi-Fiを確認します。
• 入口を比較：サービス提供元が入口や回線の種類を明確に案内している場合は、同じ接続先地域で比較できます。ノード名に「専用線」などと書かれていても、それだけで性能を判断しないでください。
• 接続先を比較：同じノードから2つのWebサイトに接続します。一方のサイトだけ遅い場合は、接続先のCDN、アカウントの速度制限、出口の地域、サイト側の負荷が原因の可能性もあります。

端末からノードサーバーにpingを実行しても、接続状況について得られる情報は限られています。サーバーによってはICMPに応答しないことがあり、中継ルーターがICMP応答の優先度を下げている場合もあります。経路の途中でパケットロスが多く見えても、その後の経路や最終接続先が正常なら、実際の通信でも同じ割合の損失が起きているとは限りません。実際のHTTPSリクエストと継続的なデータ転送の結果もあわせて判断してください。

同じノードが2種類の接続ネットワークでどちらも遅く、別の独立した回線では正常な場合は、一時的に安定した回線へ切り替え、サービス提供元に測定日時、接続中のISP、ノード名、結果を伝えましょう。サブスクリプションURL、ノードのパスワード、認証情報を含む設定は送らないでください。

第3段階：DNSとTUNの設定

名前解決の遅延とデータ転送の遅さを切り分ける

DNSの問題は、初回アクセス時の待ち時間、断続的な名前解決の失敗、接続先ドメインに適さないIPアドレスが返されるといった形で現れます。一方、すでに確立したダウンロード接続の速度が長時間低いままになる原因としては、通常DNSだけでは説明できません。設定を変更する前に、クライアントのログでDNSのタイムアウト、上流DNSへの接続不能、名前解決の失敗が繰り返されていないか確認してください。

mihomoを使っている場合は、実際に適用されている設定のdns.enable、dns.enhanced-mode、dns.nameserverと、TUN有効時のtun.dns-hijackを確認してください。これらは確認項目であり、すべてを特定の値に変更する必要はありません。GUIクライアントでは、設定の上書きやマージを通じて実行用ファイルが生成されることがあります。サブスクリプションのキャッシュファイルを直接編集しても、次回更新時に変更が失われる可能性があります。

• 上流DNSへの接続を確認：暗号化DNSも、利用できるネットワーク経路が必要です。暗号化DNSがプロキシに依存し、そのプロキシサーバーのドメイン名も同じ名前解決経路に依存する場合、起動時に依存関係の問題が起こることがあります。通常のドメインとプロキシサーバーのドメインで名前解決の設定を分ける方法は、コアのドキュメントで確認してください。
• モードの意味を確認：fake-ipは対応関係を管理するための仮想アドレスを返します。これだけで名前解決エラーとは判断できません。198.18.0.0/16の範囲にあるアドレスが返されたからといって、すぐにDNSを変更しないでください。実際に使われるアドレス範囲は、適用中の設定を確認しましょう。
• ブラウザーの動作を確認：ブラウザーのセキュアDNSは独立したHTTPSリクエストで名前解決を行う場合があり、従来のポート53を使ったDNSの横取りが適用されるとは限りません。比較のためにセキュアDNSを一時的に無効にし、テスト後は元の設定に戻してください。
• 複数箇所を同時に変更しない：名前解決に使う設定を一度に1項目だけ変更し、接続を張り直してから初回アクセスの時間を比較してください。OS、ブラウザー、ルーター、クライアントのDNS設定を同時に変更するのは避けましょう。

システムプロキシとTUNを1項目ずつ比較する

システムプロキシは、アプリがプロキシ設定に対応し、その設定を読み込む場合に利用できます。TUNは仮想ネットワークインターフェースとルーティングを通じて通信を取り込むため、対象となる通信の範囲が異なります。HTTPプロキシに対応していることが明確なブラウザーか、前述のcurlコマンドを使ってください。まずTUNを無効にし、明示的なプロキシリクエストが動作することを確認してから、TUNによる通信の取り込みをテストします。どちらのテストも最終的に同じノードを使っているか確認してください。

1. 現在の設定を保存し、ほかのVPN、ゲーム用ネットワークアクセラレーター、通信フィルタリングツールを切断します。複数の仮想ネットワークインターフェースが同時にルートを競合させないようにしてください。
2. TUNを無効にし、確認済みのローカルプロキシポートを使って同じHTTPSリソースを測定し、速度とエラーを記録します。
3. TUNを有効にして通常のネットワークリクエストを再測定し、接続詳細で通信が取り込まれていることを確認します。明示的なプロキシコマンドだけでは、TUNが正常に動作している証明にはなりません。
4. TUNを有効にしたときだけ問題が起きる場合は、権限、ルーティング、DNSの横取り、クライアントログを確認してください。最初にすべてのノードを変更する必要はありません。

第4段階：システム負荷とローカルネットワーク

端末のリソースが上限に達していないか確認する

WindowsではCtrl + Shift + Escを押してタスクマネージャーを開き、「プロセス」と「パフォーマンス」でCPU、ネットワーク、ディスクの使用状況を確認します。macOSでは「アクティビティモニタ」を開き、「CPU」と「ネットワーク」を確認してください。測定中は画面のプロセスだけでなく、クライアントのコアプロセスも確認しましょう。1つのCPUコアが継続してほぼ100%でも、CPU全体の使用率は高く表示されないことがあります。

性能の低いルーター、古いスマートフォン、仮想マシンでは、暗号化通信や接続数の増加によって性能が頭打ちになることがあります。マルチスレッドのダウンロードを停止し、単一接続で再測定してください。速度の変化とともにCPU使用率が明らかに下がる場合は、まず同時接続数を減らすか、より適した性能の端末を使いましょう。ルールや機能を追加し続けても改善しないことがあります。

Wi-Fi、バックグラウンド通信、ポート競合を確認する

• Wi-Fi：ルーターの近くで再測定し、可能であれば有線接続でも試してください。電波が十分に強い場合は、5 GHz帯のほうが大容量通信の測定に適していることが一般的ですが、壁などの障害物がある環境では実際に比較してください。
• バックグラウンド処理：クラウドストレージ、バックアップ、アップデート、ゲームプラットフォームのダウンロードを一時停止し、上り回線が使い切られていないか確認します。アップロードが混雑していると、Webページの応答やダウンロードの確認パケットにも影響します。
• ローカルポートの待ち受け：ログにaddress already in useと表示された場合は、まずポートの競合を解消してください。Windowsではnetstat -ano | findstr :7890を実行して関連する接続と待ち受けを確認し、PIDを照合できます。ポート競合は起動や通信の取り込みに関する問題であり、ノードによる速度制限ではありません。
• セキュリティソフト：HTTPSスキャン、ネットワークフィルタリング、通信監査の機能が関係していないか確認してください。ソフトウェアの説明に従い、該当機能だけを短時間無効にして比較します。ファイアウォールを長時間無効にしたり、すべてのプログラムに適用される許可ルールを追加したりしないでください。

クライアントを終了しても、通常なら直接接続できるサイトが遅い場合は、まずローカルネットワークの問題を解決してください。反対に、通常の直接接続で速度が出ても、プロキシ経路が正常とは限りません。それぞれの通信で、経由するサーバーやISP間の経路が異なる場合があります。

仕上げの確認：変更の効果を確かめ、記録を残す

設定を変更したら、テスト用の接続を張り直してください。モードやプロキシグループを切り替えても、既存のTCP長時間接続がすべてすぐに切り替わるとは限りません。ブラウザーが以前の接続を再利用していると、測定結果が切り替え前のノードから得られることがあります。進行中のダウンロードを停止してリクエストをやり直し、必要であれば対象の接続だけを閉じてください。すべてのアプリのセッションを消去する必要はありません。

1. 同じ条件で再測定：端末、ネットワーク、接続先、測定方法をそろえて3回繰り返し、最高速度だけでなく中央値とばらつきを比較します。
2. 実際の用途で確認：問題が起きていた動画、Webページ、ダウンロードが改善したか確認してください。測定用の接続先だけ速くなり、実際の利用が変わらない場合は、対象通信のルール振り分け、接続先、プロトコルの経路も確認する必要があります。
3. 効果のあった変更だけ残す：改善しなかったDNS、MTU、プロキシグループの設定は元に戻してください。変更を残しすぎると、次に調べるとき原因の分からない差が増えてしまいます。
4. 問い合わせ情報を整理：発生日時、クライアントとコアのバージョン、ネットワークの種類、TUNの有効・無効、2種類の条件で比較した結果、必要最小限のエラーログを記録します。ログを共有する前に、サブスクリプションURL、認証情報、個人のアクセス履歴を削除してください。

Clashの通信速度が遅い場合は、測定条件を固定し、ノードの転送速度、回線の変化、ローカルDNSとTUN、最後にシステム環境の順に確認するのが効果的です。遅延の数値はあくまで手がかりです。再現でき、条件を比較でき、元に戻せるテストが、次の変更を判断する根拠になります。設定項目やルールの意味はプロトコルリファレンスで、基本的な接続の問題はよくある質問で確認できます。