Clash速度低下の調査方法：ノード・回線・ローカル設定を段階的に切り分ける

まず段階的に切り分ける：調査手順の全体像

「Clashが遅い」というのは曖昧な表現で、その背後には全く異なる3つの原因が考えられる。ノード自体の品質が悪い、途中の回線が混雑している、あるいはローカルの設定が適切でない、というものだ。多くの人は動作が重いとすぐにサブスクリプションやクライアントを変えてしまうが、一巡しても問題が解決しないのは、順番通りに調査せず中間の段階を飛ばしているからだ。

効率的なのは、外側から内側、遠いところから近いところへと3段階で順に確認していくことだ。

1. ノード層：そのノード自体の帯域幅・負荷・地理的な位置が適切かどうか。
2. 回線層：ユーザーのネットワークからノードサーバーまでの間に、通信事業者間の相互接続の混雑や国際回線の変動がないか。
3. ローカル層：Clashクライアント自身のルールマッチ、DNS解決、TUNモードの設定が全体のパフォーマンスを引き下げていないか。

この3段階を順に切り分けて検証してこそ、ノードを変えるべきか、ピーク時間帯を待つべきか、設定を見直すべきかが判断できる。以下で順に詳しく見ていく。

第1段階：ノード品質の判断方法

ノード品質は最も誤判定されやすい段階だ。多くの人はパネル上の遅延数値だけを見て結論を出してしまうが、実際には遅延が低いことと帯域幅が十分であることは同じではない。ノードが良質かどうかを判断するには、3つの観点をおすすめする。

遅延はあくまで入門的な指標

クライアントのパネルに表示される遅延は、通常は速度測定用アドレスへ1回接続を試みた際にかかった時間であり、ハンドシェイクの速度を反映するものにすぎず、実際の転送帯域幅を意味しない。遅延100ミリ秒以内のノードでも、実際のダウンロード速度が数百KB/sしかないケースは珍しくなく、これは大抵ノードの上り帯域幅を同時接続中の他のユーザーと分け合っていることが原因だ。

ノードを切り替えて比較実験する

あるノードが遅いと感じたら、最も直接的な方法は、同じ時間帯にサブスクリプション内の別の地域・別のラベルのノードを2〜3個切り替え、それぞれ実際のダウンロード速度を測定することだ（コマンドラインツールやブラウザで一定サイズのファイルをダウンロードすればよい）。ノードを変えると速度が明らかに戻るなら、問題はそのノード自体にあり、高負荷か回線品質が悪い可能性が高いので、普段の利用では避ければよい。

サブスクリプションのロードバランスに注目する

多くのサブスクリプションは同一地域に複数ノードを用意しており、名前に番号や「負荷分散」「高速」といったラベルが付いていることが多い。同じノードだけを長期間使い続けると、ピーク時に混雑しやすい。同一地域のノードを適度にローテーションさせたほうが、1つのノードに固執するより体感が安定することが多い。

第2段階：回線と通信事業者の混雑

複数のノードに変えても速度がほとんど変わらない場合、問題はノードではなく、ローカルのネットワークからノードまでの伝送経路にある可能性が高い。この段階でよく見られる現象は、日中は正常でも夜間のピーク時に明らかに遅くなる、あるいは特定の時間帯だけ速度が不安定になる、といったものだ。

まず直結の基準測定を行う

プロキシを一時的にオフにして、地元の速度測定サイトに直接アクセスし、ローカルネットワークの基礎帯域幅を確認する。直結自体が不安定であれば、プロキシの速度が遅いのはローカルの光回線やルーターの問題である可能性が高く、Clashの設定とは無関係なので、まずこの可能性を排除する必要がある。

国際回線のピーク時間帯の傾向

国際出口帯域幅は夜間や週末に混雑しやすく、特に事業者間の相互接続を経由する回線ではその傾向が強い。遅くなる時間帯が概ね決まっていて、夜8〜9時前後や週末の夜に特に目立つなら、これは回線混雑によるものであることが多く、ノードを変えても根本的な解決にはならない。ピーク時間帯をやり過ごすか、より安定した経由ノードを選ぶしかない。

TCPテストでパケットロスと混雑を見分ける

条件が許せば、mtr や traceroute といったツールで経路を追跡し、どこかのホップで明らかな遅延の跳躍やパケットロスが起きていないか確認する。継続的なパケットロスは、特定の区間の回線品質の問題を示している場合が多く、ノードサーバー自体の処理能力の問題ではない。この場合、どのノードに変えても大抵は改善しない。同じ混雑区間を経由している可能性が高いからだ。

第3段階：ローカル設定の確認

ノードと回線を除外してもまだ速度が理想的でない場合は、ローカルのClashクライアントの設定を見直すべきだ。この段階の問題は分かりにくく見落とされやすいが、影響は決して小さくない。

ルールマッチがプロキシを経由しているか

ルールモードでは、通信は設定ファイル内のルールに1つずつマッチさせられ、マッチしたルールに従って処理される。ルールが精密に書かれていないと、本来直結すべき地域内のトラフィックが誤ってプロキシに送られたり、逆のケースが起きたりして、明らかな速度損失につながる。クライアントの接続ログを開き、現在アクセス中のドメインが実際にどのルールにマッチしているかを確認するのが、こうした問題を調査する最も直接的な方法だ。

DNS解決の段階は見落とされやすい

DNS解決が遅いと、接続確立全体のプロセスが遅くなり、ノードや回線に問題がなくても、体感は「遅い」ままになる。設定ファイル内の dns フィールドの設定を確認し、fake-ip モードが有効になっているか、また上流DNSサーバーが利用可能で応答が十分速いかを確かめる。国際アクセスでは、プロキシ対象のドメインを遠隔解決させることをおすすめする。ローカルの通信事業者のDNSが誤ったIPを返し、接続が迂回してしまうのを避けるためだ。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - https://1.1.1.1/dns-query

TUNモードと仮想ネットワークカードのオーバーヘッド

TUNモードを有効にすると、すべての通信は仮想ネットワークカードを経由してClash Meta(mihomo)コアへ転送され処理される。このプロセスは従来のシステムプロキシモードに比べ、パケットのカプセル化・展開という余分な処理が加わる。デバイスの性能が限られている場合や、同時に多くのアプリが帯域幅を消費している場合、TUNモードによる余分なオーバーヘッドはより顕著になる。まずシステムプロキシモードに切り替えて対照テストを行い、速度差がTUNモード自体によるものかどうかを判断できる。

同時接続数とコア負荷

同時に開いている接続数が多すぎる、特にダウンロードツールや動画サイトのマルチスレッド接続が多いと、プロキシコアの処理負荷が急増する。クライアントパネルの接続数とトラフィックグラフを確認し、数値が異常に高いようなら、まず不要なダウンロードタスクを終了し、全体の速度が回復するか確認するとよい。

よくある誤解と実用的なチェックリスト

調査過程で最もよく陥る誤解をまとめておくので、確認の参考にしてほしい。

• 遅延の数値だけを見て、実際のダウンロード速度を測らない——遅延が低いことは帯域幅が十分であることを意味しない。
• 遅いと感じたらすぐにクライアントやサブスクリプションを変える——多くの場合、問題は回線のピーク時間帯やローカルのルールにあり、クライアントを変えても根本的な解決にはならない。
• 直結の基準測定を省略する——ローカルの光回線の問題を排除しないと、プロキシノードに責任を押し付けがちになる。
• ルールを大まかに書きすぎる——本来プロキシを通す必要のないトラフィックまでプロキシに送ってしまい、余分な遅延を加えるだけになる。
• 長期間1つのノードだけを使い続ける——ピーク時に負荷が集中し、体感は必ず低下する。

このチェックリストを日常の調査手順として使ってほしい。まず直結の基準測定を行いローカルネットワークに問題がないことを確認し、次に2〜3個のノードに変えて比較しノードの問題かどうかを判断する。それでも問題がなく依然として遅い場合は、ルールマッチの記録とDNS設定を見直す。この3段階を順に確認していけば、大抵は問題を特定できるので、感覚だけで推測する必要はない。