Clashの通信速度が遅い
原因を順に確認

まず確認：接続・ダウンロード・特定サイトのどれが遅いか

Clashの画面に表示される遅延値は、指定した宛先への探測結果を示すものです。ダウンロード帯域を表すわけではなく、すべてのサイトでの通信品質を保証するものでもありません。遅延が80 msのノードでも、出口が混雑していれば速度が大きく落ちることがあります。一方、180 msのノードのほうがダウンロードを安定して続けられる場合もあります。症状を整理してから、確認する項目を決めましょう。

測定前に、クラウドストレージの同期、ゲームプラットフォームの更新、その他の大容量通信を一時停止します。端末・接続ネットワーク・接続先を固定し、各条件で3回以上測定してください。時間帯、ルールモード、実際に使われたノード、ダウンロード速度、エラー内容を記録します。測定中にノードを次々切り替えると、接続ごとに出口が変わり、結果を比較しにくくなります。

第1段階：ローカルの待ち受けポートと実際の通信経路を確認する

例示されたポート番号を現在のポートと混同しない

クライアントのポート設定を開き、現在のHTTP、SOCKS、または混合ポートを確認します。よくある例は 7890 ですが、クライアントによって異なる番号が使われることもあります。HTTPポートをSOCKSポートとしてそのまま使うことはできません。mixed-port は、同じ待ち受けポートでHTTPとSOCKSの両方のプロキシ要求を受け付けます。

以下は待ち受けポートの関係を説明するためのmihomo設定例です。ノード、プロキシグループ、ルールを含む完全なサブスクリプションではありません。GUIクライアントでは実行用設定が自動生成されることがあります。手動変更がサブスクリプション更新で上書きされないよう、まずクライアントの設定画面から変更してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

• mixed-port: 7890：ローカルのアプリは 127.0.0.1:7890 に接続してプロキシを利用できます。
• allow-lan: false：LANにプロキシの接続口を公開しません。ローカル端末の速度を調べるだけなら、有効にする必要はありません。
• mode: rule：ルールに基づいてプロキシグループを選びます。すべての接続がプロキシ経由になるという意味ではありません。
• log-level: info：通常のトラブルシューティングに必要な情報を記録します。大量のデバッグログを長期間出し続けるのは避けましょう。

明示的なプロキシ設定でリクエストを試す

Windows PowerShellでは curl.exe を使ってください。環境によっては curl が別のコマンドとして解釈されることがあります。以下のリクエストはHTTPプロキシの接続口とHTTPSトンネルが機能するかを確認するもので、大容量ファイルの速度測定には使いません。実際のポート番号が7890以外の場合は、コマンド内のポート番号を置き換えてください。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://example.com/

macOSやLinuxでは、コマンド内の curl.exe を curl に置き換えてください。また、クライアントの「接続」画面で example.com を検索し、適用されたルール、プロキシグループ、最終的な出口を確認します。ローカルプロキシを明示しても、リクエストがカーネルに届いたことしか確認できません。ルールによって接続先が DIRECT に割り当てられる場合もあります。

ローカルポートに接続できない場合は、リモートノードを切り替える前に、カーネルが起動しているか、ポートが他のプロセスに使われていないかを確認します。Windowsでは次のコマンドで待ち受け状態とPIDを確認できます。何も表示されなければ、そのポートではTCP接続を待ち受けていない可能性があります。PIDが表示されたら、タスクマネージャーの「詳細」タブで該当プロセスを確認してください。

netstat -ano | findstr LISTENING | findstr :7890

第2段階：ノード負荷とプロキシグループの選択を確認する

ノード名は通常、プロバイダーが付けたラベルにすぎず、実際の物理的な場所や通信経路を示すとは限りません。調査時はまずプロキシグループ内のノードを固定し、接続の詳細を確認します。テストするグループが url-test、fallback、load-balance の場合、新しい接続でノードが自動的に切り替わったり、出口が振り分けられたりすることがあります。プロキシグループ名だけで接続先が固定されていると判断しないでください。

1. 現在適用されているプロキシグループでノードAを選びます。自動選択グループの場合は、一時的に既存の手動選択グループを使ってください。先に設定をバックアップし、サブスクリプション全体を上書きしないようにします。
2. 実行中のダウンロードを終了し、新しい接続で再度試します。ノードを切り替えても、すでに確立されたTCP接続が新しい出口へ移るとは限りません。
3. 同じダウンロード元で3回測定し、毎回約30秒間の速度を確認します。開始直後のピーク値だけでなく、速度が安定した状態を記録してください。
4. ノードBでも同じ手順を繰り返します。名前が似たノードに替えるだけでなく、Aとは異なる回線またはプロバイダーのノードを優先して選びましょう。
5. 時間帯を変えて再測定します。夜は遅く昼は正常なら、容量不足や経路の混雑を疑う手がかりになります。ただし、それだけでサーバー負荷が高いと断定はできません。

テスト元ではなく「ノードが遅い」と判断するには

ノードAでは独立した2つのダウンロード元がどちらも遅く、同じ端末・ネットワークでノードBは正常なら、Aの入口、出口、またはリソース制限を優先して疑います。すべてのノードで特定のダウンロード元だけが遅い場合は、サイト側の単一接続あたりの速度制限、アカウント制限、CDNの振り分けを確認しましょう。複数接続を使う公開速度テストの結果は、ブラウザーで単一ファイルをダウンロードする速度と同じとは限りません。

第3段階：ローカルネットワークとリモート回線を切り分ける

「直接接続は正常なのにプロキシは遅い」という症状にも、複数の原因が考えられます。ローカルの通信事業者からノードの入口までの経路が混雑している、ノードの出口から接続先までの品質が悪い、プロキシプロトコルの通信が制限されている、といった可能性があります。同じ端末で接続ネットワークを切り替えると、原因の切り分けに役立ちます。

Windowsではまず ipconfig で現在のデフォルトゲートウェイを確認し、その実際のアドレスに対して ping -n 30 を実行します。macOSやLinuxでは ping -c 30 を使います。例として示されたゲートウェイアドレスを、自宅のルーターのアドレスだと思い込まないでください。何も通信していない状態でもLAN内の遅延が大きく変動したり、継続的にパケットロスが発生したりする場合は、まずWi-Fiのチャンネル、距離、LANケーブル、ルーターの負荷を確認します。

ノード入口へのPingや経路トレースは、あくまで補助的な情報です。サーバーによってはICMPに応答せず、中継ルーターが探測パケットを制限していることもあります。途中の1ホップでパケットロスが表示されても、その後のホップや最終接続先が正常なら、実際のデータ転送で損失が起きているとは限りません。経路トレースの画面だけを根拠にノード障害と判断しないでください。

アップロード中またはダウンロード中だけ遅くなる

何もしていないときは正常でも、ファイルをアップロードするとWebページや音声通話まで遅くなる場合は、上り帯域を使い切って通信の待ち行列が発生している可能性があります。まずアップロード速度を利用可能な上り帯域の約80～90%に制限して、もう一度測定してください。この範囲は原因調査の目安であり、常に最適な値とは限りません。キュー管理に対応するルーターでは、さらに調整できる場合があります。クライアント、ルーター、ノードを同時に変更すると、どの変更が改善につながったのかわからなくなります。

curlで待ち時間と転送速度を分けて確認する

Webページを何度も更新するより、ダウンロードが許可され、サイズがわかっていて、十分な時間転送が続くHTTPSファイルを使うほうが比較しやすくなります。数KB程度のページから帯域を推定したり、ブラウザーのログイン、CAPTCHA、一時的な署名URLが必要なアドレスを使ったりするのは避けてください。以下のコマンドはmacOS、Linuxの一般的なシェル向けです。確認済みのダウンロードURLを対話形式で入力し、ファイルはディスクに保存しません。

printf 'テスト用ファイルのHTTPS URLを入力してください：'
IFS= read -r test_url
curl --noproxy "" \
  --proxy http://127.0.0.1:7890 \
  --location \
  --connect-timeout 10 \
  --max-time 30 \
  --output /dev/null \
  --write-out '\nhttp=%{http_code}\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\nbytes=%{size_download}\nspeed=%{speed_download} B/s\n' \
  "$test_url"

• http：403、429、エラーページではなく、正常なコンテンツが返っていることを確認します。206はサーバーがコンテンツの一部を返したことを示す場合があります。
• first_byte：リクエスト開始から最初の1バイトを受信するまでの時間です。接続やハンドシェイクにかかる時間も含まれ、DNSだけの所要時間ではありません。
• total：今回のリクエストにかかった合計時間です。リダイレクト、サーバーの応答待ち、実際のデータ転送が影響します。
• speed：今回の転送で報告された平均ダウンロード速度（バイト/秒）です。転送された実データの量や測定時間と合わせて確認してください。

大きなファイルの転送が30秒以内に終わらない場合、タイムアウトエラーでコマンドが終了することがあります。これは --max-time 30 で設定された想定どおりの制限です。タイムアウトをすべて回線切断と見なさず、ダウンロード済みのバイト数も確認してください。数秒で転送が終わるファイルを使う場合は、より大きなファイルを選ぶか、短時間のサンプル測定であることを記録します。

HTTPプロキシ経由でHTTPSの接続先にアクセスする場合、接続先ドメインの名前解決は通常、プロキシ経由で行われます。curlが計測するローカルDNSの時間を、mihomo内部での接続先の名前解決時間と見なすことはできません。最初の1バイトが届くまでに時間がかかる場合は、カーネルログ、適用されたルール、実際のDNS設定を合わせて確認してください。単一の計測項目だけで判断しないようにしましょう。

ローカル設定：システムプロキシ、TUN、DNSを個別に確認する

まずは通信を取り込む方法を1つにして基準を取る

システムプロキシの影響を受けるのは、主にシステム設定を参照するアプリです。ターミナル、一部のゲーム、独自のネットワーク処理を行うソフトは、システムプロキシに従わないことがあります。TUNは仮想ネットワークアダプターとルーティングを使い、条件に合うIP通信を取り込みますが、ルール、除外設定、権限、プラットフォームの実装に左右されます。すべての接続がリモートプロキシを経由するわけではありません。

1. 他のVPN、通信高速化ツール、プロキシソフトを一時停止します。システムプロキシや仮想ネットワークアダプターを複数のソフトが同時に制御していないか確認してください。
2. まずTUNを無効にし、前述のcurlによる明示的なプロキシ設定で基準を取ります。この方法では、アプリがシステムプロキシ設定を参照するかどうかに左右されません。
3. 次にシステムプロキシを有効にして、ブラウザーで確認します。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」でシステム設定を確認し、ブラウザーのプロキシ拡張機能が設定を上書きしていないかも確認してください。
4. プロキシに対応していないアプリの通信を取り込む必要がある場合は、TUNを有効にします。クライアントのサービスがインストール済みで、必要な権限が許可されていることを確認し、新しい接続で速度を比較してください。

TUNを有効にしたときだけ速度が低下する場合は、ルーティングの競合、DNSのリダイレクト設定、仮想ネットワークアダプターの状態を重点的に確認します。最初からMTUを変更しないでください。「小さなリクエストは正常だが、大きな応答や特定の接続が繰り返し停止する」といった現象が再現し、ほかの要因を除外できてから、経路MTUを調べるのが適切です。変更前の値を記録し、一度に1項目だけ変更してください。

DNSは「多く設定すれば速くなる」とは限らない

mihomoの dns.nameserver、dns.proxy-server-nameserver、dns.nameserver-policy は、それぞれ異なる用途で使われます。ノードサーバーのドメイン名を解決することと、接続先サイトのドメイン名を解決することも別の処理です。設定を変更する際は、使用中のカーネルのドキュメントとサブスクリプションの設計を確認してください。ノードの名前解決に必要なDNSが、まだ確立されていないプロキシ経路に依存しないよう注意します。

fake-ip を使っている場合、クライアントにマッピング用のアドレスが返るのは正常な仕組みである可能性があり、それだけで名前解決エラーとは判断できません。一部のアプリだけが対応していない場合は、DNSモジュール全体を無効にするのではなく、該当ドメインに対する fake-ip-filter の設定を検討してください。IPv6も、IPv6経路の有無を比較して原因を特定します。あらゆる速度低下に対する解決策として、IPv6を無効にすることはおすすめしません。

設定を読み込めない場合は、速度測定より先にカーネルのエラーを確認してください。mihomoをコマンドラインから使う場合は、設定ファイルのあるディレクトリで次のチェックを実行します。GUIクライアントでは、設定チェックやログの画面を利用してください。構文チェックに通っても、ノードが利用可能であることや、ルールが想定どおりであることまでは保証されません。

mihomo -t -f config.yaml

最後に：変更を最小限にして再現可能な結論を出す

有効なトラブルシューティングでは、「どの条件を変えたとき、どの指標が変化したか」を説明できます。たとえば、同じ端末・ノード・ファイルで、自宅の固定回線では遅くスマートフォンのテザリングでは正常なら、接続ネットワークからノード入口までの経路を優先して調べます。同じネットワークでノードAは2つの接続先とも遅く、ノードBは正常なら、Aの回線やリソースについてプロバイダーに確認します。

• ブラウザーだけ遅い：拡張機能のプロキシ設定、サイトのキャッシュ、そのサイトに実際に適用されているルールを確認します。クライアント全体を再インストールする必要はありません。
• すべてのノードが遅い：プロキシを使わない場合の速度、ローカルの待ち受けポート、バックグラウンド通信、他のネットワークソフトを確認してから、共通するプロバイダー側の制限を調べます。
• 自動選択のプロキシグループだけ遅い：ノードを固定して再測定し、探測先、切り替え動作、新しい接続で実際に使われた出口を確認します。
• サブスクリプション更新後に遅くなった：プロキシグループ、ルールの順序、ノードの変更点を比較し、バックアップを残してください。サブスクリプションファイルのサイズだけを比べても原因はわかりません。
• ほかの人に調査を依頼する：OSのバージョン、クライアントのバージョン、カーネルのバージョン、時間帯、接続ネットワーク、再現手順、個人情報を伏せたログを共有してください。