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

まず測定条件をそろえる：遅延・初回応答・ダウンロード速度を分けて記録

Clashの画面に表示される遅延は、帯域幅を示すものではありません。URL遅延テストで測定されるのは、そのノード経由で指定したテスト先にアクセスした際の応答時間です。計測の範囲はクライアントやコアの実装によって異なります。大容量ファイルのダウンロード速度や、すべてのサイトでの使用感を判断する指標にはなりません。「ノードの遅延は80 msなのに動画が止まる」ときは、遅延だけで並べ替えず、接続確立・最初の1バイトの受信・転送中の速度をそれぞれ確認してください。

この記事は、Clashまたはmihomoコアを使うクライアントを対象としています。Clash Metaはmihomoの旧称です。対応プロトコル、DNS関連の項目、TUNの設定はコアのバージョンによって異なります。作業を始める前にクライアントとコアのバージョンを記録し、現在の設定をバックアップしてください。調査中はサブスクリプション、テスト先、クライアントのバージョンを変えず、コアの更新・DNSの変更・ノードの切り替えを同時に行わないでください。

再現可能なテスト記録を作る

• 環境を固定：同じ端末、同じネットワーク、同じダウンロード先を使います。クラウドストレージの同期、システム更新、ほかの大容量通信は一時停止してください。
• 接続先を固定：実際に通信がマッチするプロキシグループからノードを1つ選び、テスト中に切り替わる自動速度測定グループや負荷分散グループは使わないでください。
• 回数を固定：条件ごとに連続で3回測定し、中央値を記録します。継続ダウンロードは少なくとも30秒観察してください。テストで多くの通信量を消費する場合があります。
• 記録項目を固定：測定時刻、対象ドメイン、ルール、プロキシチェーン、遅延、ダウンロード速度、途中で停止したかどうかを記録します。

表の数値は記録方法と読み取り方の例であり、当サイトでの実測値ではありません。単位に注意してください。8 MB/sは約64 Mbpsです（実際にはプロトコルのオーバーヘッドもあります）。回線の公称速度が100 Mbpsでも、ダウンロードアプリに100 MB/sと表示されるわけではありません。

第1段階：ノードの品質を確認し、ノード固有の問題と接続先の速度制限を切り分ける

同じサブスクリプションからノードを2～3個選び、同じ接続先をテストします。ノード名に含まれる地域名が入口の所在地を示すとは限らず、名前と出口経路が一致する保証もありません。代替ノードを選ぶときは、名前だけが違い実際には同じ入口を共有するノードではなく、入口や回線が異なるノードを優先して比較してください。

遅延テストがタイムアウトしても、ノードが完全に使えないとは限らない

テスト先に接続できない、接続先から拒否される、TLSハンドシェイクに失敗するといった理由でもタイムアウトが発生します。まずテストURLを確認し、ブラウザーで実際に利用するサイトにアクセスしてください。一方、速度測定先がすぐ応答しても、成功したのはその特定のリクエストだけです。動画のセグメント、ダウンロード用ドメイン、ログインAPIまで正常とは限りません。

1. クライアントの「プロキシ」画面でノードを手動選択し、その後「接続」画面で新しいリクエストが実際にそのノードを経由しているか確認します。画面名は使用中のクライアントのバージョンによって異なります。
2. 同じHTTPSファイルのURLで3回テストし、次に別の独立したサイトでも試します。特定のサイトだけ遅く、ほかは正常なら、サイト側の速度制限、CDN、または出口側の相互接続を優先して確認してください。
3. 夜間の混雑時間帯と、それ以外の時間帯で結果を記録します。同じノードが夜間だけ継続的に遅くなる場合は、端末の設定よりもノードの容量や共有回線の混雑を疑ってください。
4. ノードを切り替えたら、テスト接続を新しく確立してください。既存のHTTP/2・HTTP/3接続やダウンロード接続には、切り替え前の経路が残ることがあります。必要であれば、テスト対象の接続だけを閉じてください。

明示的なプロキシリクエストでブラウザーの影響を切り分ける

以下のWindows PowerShellコマンドは、ローカルHTTPプロキシ経由でサンプルサイトにアクセスし、最初の1バイトまでの時間と合計所要時間を確認します。7890はポート番号の例です。実行前に、クライアントに表示されているHTTPまたはmixedの待ち受けポートに置き換えてください。すべてのクライアントで使われる既定値ではありません。この小さなページへのリクエストは接続過程の確認用であり、最大帯域幅の測定には使えません。

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

ここでのtime_connectは主にローカルプロキシへの接続を示すもので、リモートノードまでの遅延として扱うことはできません。HTTPプロキシ経由でHTTPSサイトに接続する場合、その後の計測にはプロキシトンネルや接続先とのTLSハンドシェイクなども含まれます。macOSとLinuxではcurlを使い、NULを/dev/nullに置き換えてください。コマンドでは正常なのにブラウザーが遅い場合は、サブスクリプションをすぐに変更せず、ブラウザーの拡張機能、キャッシュ、安全なDNSを確認してください。

第2段階：回線経路を確認する。まずルールの適用先を確かめ、次にネットワークの入口を比較

「ノードを選んだ」だけでは、すべてのアプリがそのノードを経由するとは限りません。ルールモードでは、接続はまずルールに照合され、その後、該当するポリシーまたはプロキシグループに振り分けられます。メインのスイッチでノードを選んでも、対象リクエストが別のグループにマッチしていれば、速度測定を比較できません。ダウンロード用ドメイン、動画のセグメント用ドメイン、ページのメインドメインがそれぞれ別のルールにマッチする場合もあるため注意してください。

接続ログで3つの項目を確認する

• 接続先：ドメイン、接続先IP、アプリのプロセスが、テスト対象と一致しているか確認します。バックグラウンドの更新リクエストを見間違えないようにしてください。
• ルール：DOMAIN-SUFFIX、GEOIP、最終ルールのMATCHなど、マッチしたルールの種類と内容を確認します。
• プロキシチェーン：最終的な接続先が想定したノードであることを確認します。DIRECTや別のポリシーグループ、または自動選択で直前に選ばれた別ノードになっていないかも確認してください。

短時間だけグローバルモードに切り替え、グローバルグループで同じノードを手動選択して比較できます。グローバルモードで明らかに改善し、ルールモードでは遅い場合は、グループの選択とルールの順序を優先して確認してください。グローバルモードが変えるのは、コアに入った通信の振り分けだけです。システムプロキシを使わないプログラムの通信を自動で取り込むことはなく、TUNの代わりにもなりません。テスト後はルールモードに戻し、普段の通信経路を変えないようにしてください。

自宅の固定回線とスマートフォンのテザリングで比較する

ノードとテスト先はそのままに、パソコンの接続を自宅の固定回線からスマートフォンのテザリングに切り替えます。テザリングでは安定し、自宅の回線では遅い場合、Wi-Fi、ルーター、アクセス回線、または通信事業者からノード入口までの経路に原因がある可能性が高まります。次にWi-Fiを有線LANに替えてください。有線で改善し、Wi-Fiだけ遅い場合は、プロキシルールを変更する前に電波干渉や電波強度を確認しましょう。

Windowsではまずipconfigを実行して現在のデフォルトゲートウェイを確認し、続けてping -n 30 192.168.1.1を実行します。このIPアドレスは例です。実際のゲートウェイに置き換えてください。ローカルゲートウェイですでに目立つパケットロスや、数十ミリ秒単位の繰り返しの揺れがある場合は、プロキシの設定変更をいったん止めてください。ただし、ルーターによってはICMPへの応答優先度を下げているため、pingを1回実行しただけで回線障害と判断することはできません。

第3段階：端末の設定を確認する。システムプロキシ、TUN、ポートを見直す

システムプロキシは、アプリがOSのプロキシ設定を使う場合に機能します。一部のコマンドラインツール、ゲーム、独自のネットワークスタックを持つプログラムは、この設定に従いません。TUNは仮想ネットワークアダプターとルーティングを使って対象のIP通信を取り込みますが、ルートの除外設定、権限、ほかのVPNの影響を受けます。対応クライアントでは両方を同時に有効にできます。異常が起きたときは必ず競合すると決めつけず、1つずつ無効にして原因を切り分けてください。

通信の取り込み方式を1つずつ切り替えてテストする

1. まず明示的なプロキシをテスト：前述のcurlコマンドでローカルプロキシポートに直接接続し、システムプロキシの設定が有効かどうかによる影響を除外します。
2. 次にシステムプロキシをテスト：TUNを一時的に無効にしてシステムプロキシを有効にし、システムプロキシに対応したブラウザーで同じ接続先にアクセスします。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で、手動プロキシのアドレスとポートを確認できます。
3. 最後にTUNをテスト：システムプロキシを一時的に無効にし、クライアントの指示に従ってサービスをインストールするか権限を付与してから、TUNを有効にします。テスト接続がコアの接続一覧に表示されることを確認してから、速度を比較してください。
4. ほかの通信取り込みソフトを切り分ける：ほかのVPN、プロキシクライアント、ネットワーク高速化ツールを1つずつ終了します。企業管理端末でセキュリティポリシーが関係する場合は、管理者に相談してください。ドライバーを削除したり、保護機能を停止したりしないでください。

ポートの競合とリソース使用状況

クライアントのログに待ち受け失敗が記録されている場合は、まずポートが使用中か確認します。Windowsでnetstat -ano | findstr :7890を実行し、ローカルアドレスのポート番号が7890と一致するLISTENINGの項目を確認します。その後、PIDをタスクマネージャーで調べてプロセスを特定してください。一致する行が見つかっただけでプロセスを終了しないでください。別の接続や似た番号のポートである可能性もあります。クライアントの待ち受けポートを変更した場合は、システムプロキシと明示的なプロキシコマンドも同じ番号に更新してください。

ダウンロード中は、タスクマネージャーでCPU・メモリ・ネットワークの使用状況も確認します。論理プロセッサの1つが継続して100%近くになる場合、端末の処理能力がスループットを制限している可能性があります。CPU全体の平均使用率が低くても、単一スレッドがボトルネックになっていることはあります。ログレベルをdebugにしたまま使うと記録量が増えます。調査後は通常のレベルに戻してください。コアのバージョンやTUNのネットワークスタックを比較する前に、現在の設定と元に戻す手順を確保しておきましょう。

DNSとプロトコルの確認：初回表示の遅さ、動画の遅さ、断続的な停止を切り分ける

DNSの問題は、初回アクセス時に長く待たされるものの、接続確立後のダウンロードは正常という形で現れることがあります。一方、継続的なスループット低下がDNSに起因するとは限りません。まず接続ログで名前解決のタイムアウトが繰り返されていないか確認し、DNS解決・リモート接続・TLSハンドシェイクの各段階を切り分けてください。別のパブリックDNSに変更しても、リクエストがプロキシ経由になるとは限らず、回線が速くなる保証もありません。

Fake-IPとnameserver-policyで確認する範囲

mihomoのdns.enhanced-mode: fake-ipは、仮想アドレスを使ってコアがドメイン名を復元できるようにする機能です。帯域幅を上げる設定ではありません。nameserver-policyは、条件に一致するドメインに使用するDNSサーバーを指定します。これは名前解決の方針を決めるもので、アプリの通信に適用されるプロキシルールとは別です。DNSの上流サーバーをドメイン名で指定する場合は、その上流サーバー自体の名前解決と到達性も考慮し、依存関係が循環しないようにしてください。

• ブラウザーでセキュアDNSが有効になっていると、システムDNSとは異なる経路で問い合わせる場合があります。ブラウザーのセキュアDNSを一時的に無効にして比較し、結果を記録したら元の設定に戻してください。
• TUNのDNSハイジャック設定で取り込まれるのは、設定ルールの対象になっているDNS通信だけです。一般的な53番ポートのハイジャックで、すべてのアプリ内DoHリクエストを書き換えられるわけではありません。
• DNSを変更したらテスト接続を新しく確立してください。Windowsのipconfig /flushdnsで消去されるのはシステムの名前解決キャッシュだけです。ブラウザー、アプリ、コアのキャッシュすべてが消えるわけではありません。
• IPv6を使う場合は、DNSレコード、システムルート、プロキシの対応状況を合わせて確認してください。設定のスイッチを1つ変更しただけでは、アプリのIPv6通信が取り込まれているとは判断できません。

UDP・QUIC・MTUは後から確認する

ブラウザーはUDPベースのHTTP/3を使う場合があります。使用中のノード、プロトコル、通信の取り込み経路でUDPへの対応が不十分だと、一部のサイトで何度もフォールバックしたり、読み込みに失敗したりすることがあります。まずクライアントのログとブラウザーのネットワーク情報で状況を確認し、その後、対象のブラウザーまたはサイトに限って一時的にTCP接続と比較してください。1つのサイトのためにUDPを全体で遮断しないでください。

小さなページは正常に表示される一方、大容量ファイルや特定のHTTPSリクエスト、TUNモードで頻繁に通信が止まり、ノードとルールの問題も除外できた場合は、経路MTUやトンネルのカプセル化を疑います。その場合に限り、現在の値からTUNのMTUを一時的に1400に変更して比較してください。この値は診断のための候補であり、すべての環境に適した推奨値ではありません。改善しなければ元に戻してください。根拠なくMTUを下げることを、常用の速度改善策にしないでください。項目の対応状況と適用方法は現在のコアのドキュメントを確認し、必要に応じてプロトコルガイドも参照してください。

原因を絞り込む：設定を重ねるのではなく、症状に合わせて次の手順を選ぶ

一度に変更する条件は1つだけにし、テスト後に「何を変えたか」「結果はどうだったか」「元に戻したか」を記録してください。原因を特定したら、一時的なグローバルモード、テスト用DNS、試験的なMTU設定を元に戻し、問題の説明に必要な最小限の変更だけを残します。問い合わせる際は、クライアントとコアのバージョン、OSのバージョン、通信の取り込み方式、テストした時間帯、個人情報を伏せたエラーログを共有してください。サブスクリプションURL、ノードのパスワード、コントロールAPIのキーは公開しないでください。

古いクライアントが現在のOSに合わない場合は、まずクライアント比較で対応OSとコアを確認し、使い方ガイドに沿って最小構成を作り直してください。クライアントの変更で一部の互換性問題を解決できることはありますが、ノード・経路・端末の3段階で原因を切り分ける作業の代わりにはなりません。