Clashが遅い原因を切り分ける方法｜ノード品質・回線混雑・端末設定

まず確認：Webページの表示が遅い？それともダウンロードが遅い？

Clashでノードの遅延が正常と表示されても、ダウンロード速度が速いとは限りません。ノード一覧の測定値は通常、ノード経由でテストURLにアクセスした結果です。接続確立までの時間、接続先の応答、コネクションの再利用、クライアントの測定方法などに左右されます。帯域幅を測るものではなく、動画サイトやファイルサーバーでの通信速度をそのまま示すわけでもありません。

調査を始める前に、問題が起きるWebサイト、端末、ノードをそれぞれ1つに固定します。クラウドストレージの同期、OSの更新、ほかのダウンロードを一時停止し、ルールモードを使って接続一覧から対象の通信が想定したプロキシグループに振り分けられていることを確認します。実際には DIRECT にマッチしている場合、プロキシノードを変更してもその通信の検証にはなりません。

速度測定の基準を決める：入口・ノード・接続先を固定

プロキシのポートと実際の出口を確認

以下では、端末上の混合ポート 7890 を例にします。すべてのクライアントで共通の既定値ではないため、クライアントのポート設定、または現在有効な設定で mixed-port を確認してください。HTTPプロキシへのリクエストにはこのポートを使えます。コントロールパネルのAPIポートは通信に使うプロキシポートではないため、代用できません。

Windows PowerShellで次のコマンドを実行できます。端末上のプロキシ経由で小さなページにアクセスし、接続確立と応答を比較するためのものです。ダウンロード帯域を測り切る用途ではありません。macOSまたはLinuxでは、curl.exe を curl に置き換えてください。

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

macOSとLinuxでは、NUL を /dev/null に置き換えてください。各時間は秒単位で、リクエスト開始からの累積値です。HTTPプロキシを使う場合、time_connect は主に端末からローカルプロキシへの接続時間を示します。time_appconnect にはプロキシトンネルの確立やTLSハンドシェイクの待ち時間も含まれるため、ノードまでの往復遅延と解釈することはできません。通常、ドメイン名の解決はプロキシ経由で行われるため、このコマンドだけではローカルDNSの速度も判断できません。

帯域幅は連続転送で測定

1. アクセス権のある、容量が約100 MB以上のファイルを1つ選び、毎回同じファイルを使います。
2. まず単一接続でダウンロードし、30〜60秒間の安定した転送速度を確認してから、ダウンローダーの複数接続モードを試します。
3. 同じノードに固定します。プロキシグループが自動で切り替わる場合は、一時的にノードを手動選択してからテスト接続をやり直してください。
4. 測定日時、接続ネットワーク、適用されたルール、ノード、速度の単位、クライアントのコア情報を記録します。

単位の換算に注意してください。8 Mbps ≈ 1 MB/sです。公称100 Mbpsの回線で理論上得られる最大速度は約12.5 MB/sですが、実際の速度はプロトコルのオーバーヘッドなどで低下します。速度測定サイトのMbpsとダウンローダーのMB/sをそのまま比べないでください。

第1段階：ノードの品質と接続先との相性を確認

まず、そのノードだけが遅いのかを確認します。同じ地域のノードを2つ選び、同じ接続先にそれぞれ3回アクセスします。大陸間の距離、出口の地域、コンテンツ配信先が同時に変わらないよう、地域はできるだけそろえましょう。契約情報に異なる回線と記載されたノードがあれば、さらに比較できます。ただし、ノード名が異なるだけで入口、サーバー、出口も異なるとは限りません。

遅延が小さいノードほど転送速度が速いとは限らない

以下は判定方法を示す例であり、本サイトでの実測値やおすすめノードではありません。同じ時間帯に同じファイルを測定した結果が、ノードAは遅延65 ms・ダウンロード0.8 MB/s、ノードBは遅延140 ms・ダウンロード8 MB/sだったとします。ダウンロードを続ける用途ならBを優先できますが、応答性が重要な用途では最初の応答時間と安定性も比較してください。遅延の数値だけで並べると、ノードの速度制限や混雑を見落とします。

• 複数のサイトへのアクセスが同じノードで遅い：ノードの負荷や速度制限、端末から入口までの経路を優先して確認します。
• 同じノードで特定のサイトだけ遅い：接続先の速度制限、出口の地域、CDNの振り分けを確認します。この結果だけでノード全体の障害とは判断できません。
• すべてのノードが遅い：回線と端末の問題を調べます。特に家庭内ネットワークの混雑と、実際に異なる出口を選べているかを確認してください。

プロキシグループを切り替えても、すでに確立したダウンロード接続は以前のノードを使い続けることがあります。テストをキャンセルしてやり直すか、接続一覧から該当するテスト接続だけを閉じ、新しい接続経路を確認してください。切り替え前後の同じ長時間接続を速度比較に使わないでください。

自動選択のプロキシグループも測定結果に影響します。url-test は設定されたテスト先に基づいてノードを選び、fallback は順番に利用可能なノードを選択します。load-balance は接続を振り分ける機能であり、1つのファイルをダウンロードするときに帯域を合算するものではありません。ノードを評価するときは、まず自動選択の影響を除いてください。

第2段階：回線の混雑と端末側の接続環境を切り分ける

回線を調べるには「2種類のネットワーク、2つの時間帯」で比較します。PC、クライアント設定、ノード、接続先は変えず、まず自宅の固定回線で測定し、次にスマートフォンのテザリングで測定します。その後、混雑していない時間帯にも再測定してください。テザリングでは通信事業者までの経路が変わるほか、IPv4・IPv6やNATの環境も変わる可能性があります。原因を絞り込むための比較であり、特定の通信事業者に何らかの制限があると証明するものではありません。

まずアップロードの帯域占有とWi-Fi接続を除外する

バックアップ、ライブ配信、同期などで上り帯域が埋まると、ダウンロードの確認通信や操作のリクエストも待たされることがあります。Windows 11では「タスク マネージャー」→「パフォーマンス」→現在使用中の「イーサネット」または「Wi-Fi」を開き、送信・受信速度を確認します。次に「プロセス」タブでネットワーク使用量の多い順に並べます。使用量の多いタスクを一時停止し、約30秒待ってから再測定してください。

Wi-Fiを使っている場合は、まずルーターに近づき、次にLANケーブル接続と比較します。壁などの障害物がある環境では、5 GHzが2.4 GHzより常に優れているとは限りません。実際の電波強度と干渉状況が重要です。有線接続で改善するなら、ClashのDNS設定を変更するのは優先度の高い対処ではありません。

経路追跡は補助的な情報として扱ってください。中継ルーターがICMPへの応答優先度を下げている場合があり、途中のホップでタイムアウトやパケットロスが表示されても、転送中の実際の通信で同じ問題が起きているとは限りません。最終接続先の状態、継続的なダウンロード速度の推移、異なるネットワークでの比較を合わせて判断しましょう。

第3段階：システムプロキシ、ルール、TUNの適用状況を確認

遅いアプリがClashを経由しているか確認

システムプロキシが影響するのは、基本的にシステムプロキシ設定に従うアプリです。すべての通信が自動的にプロキシ経由になるわけではありません。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」から確認できます。クライアントでシステムプロキシを有効にしたら、ここに表示されるアドレスとポートがクライアントの設定と一致するか確認してください。ブラウザー拡張機能やアプリ独自のプロキシ設定がシステム設定より優先される場合もあります。

クライアントの接続一覧を開き、リクエストをもう一度実行して、接続先のドメイン名またはIPアドレス、適用されたルール、プロキシ経路、送受信量を確認します。該当する記録がない場合は、まず通信の取り込み状況を調べます。記録が直接接続を示している場合は、ルールの優先順位を確認してください。ルールは通常、上から順に照合されます。上位に広範なルールや MATCH があると、後続のルールの適用結果が変わります。

TUNの比較では、変更する条件を1つに絞る

1. 現在の設定をバックアップし、ほかのVPNや仮想ネットワークアダプターを作成するプロキシツールを終了します。
2. TUNを無効にしてシステムプロキシだけを有効にし、ブラウザーで同じ接続先をテストして結果を記録します。
3. システムプロキシを無効にしてからTUNを有効にします。クライアントに必要な権限があり、通信が実際に接続一覧に表示されることを確認してください。
4. 同じノードで結果を比較し、ログに記録されたルート、DNS、接続エラーも確認します。

ここで紹介した手順は問題を切り分けるための比較方法であり、普段からどちらか一方だけを使うよう求めるものではありません。TUNのルート設定やDNSの制御方法はクライアントによって異なるため、使用中のバージョンで実際の設定を確認してください。TUNを有効にしてもノードの帯域が増えるわけではありません。主な用途は、通信を透過的に取り込むことです。

DNSの調整：名前解決の待ち時間を確認。帯域の問題とは分けて考える

DNSが主に影響するのは、ドメイン名の解決、接続先IPアドレスの選択、一部のルール判定です。接続後は安定して高速にダウンロードできるのに、ドメイン名を初めて開くときだけ毎回待たされるなら、DNSを優先して確認します。一方、転送中の速度がずっと低い場合は、DNSサーバーを変更するだけでは通常解決しません。

サブスクリプションの元データだけでなく、現在有効な設定を確認

• オーバーライドやマージ機能によって dns が変更されていないか確認してください。実行中の設定はサブスクリプションのファイルと異なる場合があります。
• DNSの上流サーバーに接続できることを確認します。暗号化DNSを使っている場合は、その接続がタイムアウトしていないかも確認してください。
• mihomoの respect-rules などのオプションを使う場合は、DNSリクエストがどのように振り分けられるか、プロキシサーバーのドメイン名を別途解決できるかを確認し、依存関係のループを避けてください。
• fake-ip を使っている場合、一部のアプリがマッピングされたアドレスを受け取るのは想定された動作です。モードを切り替えた後は、古いキャッシュの影響を避けるため、テストするアプリを再起動してください。

Windowsではターミナルで ipconfig /flushdns を実行すると、システムのDNSキャッシュを削除できます。ただし、ブラウザーのキャッシュやコア自体のDNSキャッシュは同時に削除されません。キャッシュを消した直後に最初のリクエストが遅くなることもあるため、その1回だけで比較しないでください。

IPv6も無効化して終わりにするのではなく、比較して確認します。ログでIPv6接続が繰り返しタイムアウトする一方、IPv4は正常なら、IPv6の名前解決または接続を一時的に制限して検証できます。OS、クライアント、DNSそれぞれのIPv6設定は別の項目です。確認後は元の設定に戻し、実際の原因に合わせて修正してください。

同時接続設定：接続先への接続競争と複数スレッドのダウンロードを区別

mihomoの tcp-concurrent は、ドメイン名の解決で得られた複数のアドレスに対してTCP接続を競争させる設定です。一部の接続先では接続確立までの待ち時間を短縮できますが、ノードの帯域上限を何倍にも増やすものではなく、ファイルのダウンロードスレッドを増やす設定とも異なります。旧版のClashやほかのコアでは同名のオプションが使えない場合があるため、クライアントに表示されるコアと対応ドキュメントを先に確認してください。

# mihomo のトップレベル設定例。既存の設定にマージしてください
tcp-concurrent: true

これは完全な設定ファイルではありません。コアが対応していることを確認し、複数アドレスへの接続確立に時間がかかっていると考えられる場合に限り、A/Bテストを行ってください。サブスクリプションがリモートで管理されている場合は、クライアントの永続化オーバーライド機能を優先して使います。キャッシュされたサブスクリプションを直接編集すると、次回の更新で元に戻ることがあります。適用後はログで設定が受け付けられたことを確認し、最初の応答時間を比較してください。

ダウンローダーの接続数を少しずつ増やして検証

分割ダウンロードに対応したファイルで、接続数を1、4、8と順に試します。1接続で1 MB/s、4接続の合計が約4 MB/sなら、同時接続によって単一接続の制限が緩和されたと考えられます。ただし、制限の原因が配信元、回線、ノードのどれかは特定できません。8接続で4接続より遅くなる、またはWebページの応答が明らかに悪化する場合は、接続数を戻してください。むやみに増やす必要はありません。

端末のリソースも確認します。Windows 11では「タスク マネージャー」→「詳細」からプロキシコアのプロセスを確認できます。macOSでは「アクティビティモニタ」でCPUとネットワークの使用状況を確認してください。測定中にコアのCPU使用率が高止まりする、端末が熱くなる、ルーターに負荷がかかりすぎる場合は、転送速度のボトルネックになり得ます。CPU使用率が低くても、回線に問題がないとは限りません。

結論を絞り込み、再現性を確認できた設定だけ残す

調査結果は「同じノードでもテザリングでは正常だが、自宅の有線回線では夜間に遅い」のように、具体的な条件でまとめます。「Clashが不安定」だけでは次に何をすればよいか分かりません。

1. 一部のノードだけ遅い：同じ接続先での比較結果を残し、安定しているノードに切り替えます。測定時刻と回線名を添えてサブスクリプションの提供元に報告してください。
2. 同じネットワーク全体が遅い：まずアップロードの帯域占有、Wi-Fi接続、ルーターの負荷を確認し、その後で通信事業者までの経路を調べます。
3. TUN使用時だけ遅い：ルートの競合、DNSの制御、MTUを1項目ずつテストし、複数の設定を同時に変更しないでください。
4. 最初に開くときだけ遅い：まず名前解決と接続確立を確認します。ダウンロードが継続的に遅い場合は、ノード、回線、配信元の比較に戻ってください。
5. 設定を変更しても安定した改善がない：元の値に戻し、一時的なデバッグ設定を削除して、理由を説明できる最小限の変更だけ残します。

問題を報告するときは、クライアントのバージョン、コアの名称とバージョン、OS、ネットワークの種類、発生する時間帯、プロキシモード、3回分の測定結果を添えてください。ログは必要な部分だけ残し、サブスクリプションURL、アクセストークン、ノードのパスワードなどの認証情報を必ず伏せてください。ポートと通信の取り込み方法はポートのトラブル対処を、初期設定はシステムプロキシの設定手順を参照してください。