Clash が遅いときの対処法:ノード・回線・ローカル設定の3層診断

なぜ「遅い」を層で分けて診断する必要があるのか

「Clash を使うと遅い」というのはあいまいなフィードバックであり、その裏には全く異なる原因が潜んでいることがあります。ノード自体の帯域不足、海外回線がピーク時間帯に混雑している、プロトロコルの暗号化オーバーヘッドが高い、あるいは単純にローカルのネットワークスタック設定が不適切(MTU設定ミスによるフラグメント再送など)といった具合です。分けて検証しないと、「ノードを10個試してもすべて同じくらい遅いから、クライアント自体に問題がある」といった誤判定に陥りやすくなります――実際にはノードを変えても本当のボトルネックを回避できていないだけかもしれません。

本記事ではノード → 回線 → ローカル設定の3層順序で診断を進め、各層ごとに繰り返し実行でき、結果を比較できる検証動作を提示します。感覚的な判断は避けます。3層の関係は段階的なもので、まずノードに問題がないことを確認し、次に回線に問題がないことを確認し、最後にローカル設定を確認します――順序を逆にすると、間違った箇所で堂々巡りになりやすくなります。

第1層:ノード自体――遅延・パケットロス・帯域テスト

ノードはリンクの第一段階であり、最も誤判定されやすい部分でもあります。多くのユーザーはクライアント画面上の「遅延」数値だけを見て速度を判断しますが、この数値は通常TCPハンドシェイクや単純な探査パケットの往復時間しか反映しておらず、実際のスループット能力を表していません。遅延が非常に低いノードでも、帯域が複数ユーザーに共有されているためダウンロード速度が悪いことは十分にあり得ます。

まず遅延とパケットロスの基本チェック

クライアントのノード一覧で同じグループのノードに遅延テストを行い数値を記録し、次に疑わしいノードに切り替え、OS標準のツールで連続pingを実行して明らかなパケットロスや遅延のばらつきがないか確認します:

ping -c 20 8.8.8.8
# packet loss と avg 遅延に注目、パケットロスが5%を超える場合は通常リンクが不安定

パケットロス率が高く、かつ遅延の振れ幅が大きい場合(たとえば80msと400msの間で変動する場合)、問題はほぼノードまたはその上流回線にあり、ローカル設定の問題ではないと判断できます。

次に実際の帯域テストを行う

遅延が正常でも帯域が十分とは限らないため、実際のダウンロード速度を個別に測定する必要があります。よくあるやり方は、コマンドラインツールで固定サイズのテストファイルをダウンロードし、所要時間から速度を算出することです:

curl -o /dev/null -w "%{speed_download} bytes/s\n" http://speedtest.example/testfile

同じ測定動作を2〜3個の異なるノードでそれぞれ実行し、結果に明らかな差がある場合(例えば一方が5MB/s、もう一方は300KB/sしかないなど)、問題は該当ノードの帯域割り当てにあると判断できます。表現の良いノードに切り替えるだけで解決し、これ以上回線やローカル設定を調べる必要はありません。

第2層:回線とプロトコル――ピーク混雑とプロトコルのオーバーヘッド

同じノード群が日中は正常に測定できるのに、夜間のピーク時間帯にまとめて遅くなる場合、大部分は海外回線または着地サーバーが混雑時間帯に帯域を分散させられているためであり、特定のノードが壊れているわけではありません。この場合の検証方法は単純です:非ピーク時間帯に同じ測定動作を繰り返すことです。速度が明らかに回復すれば、時間帯による混雑であるとほぼ確定します。設定の問題ではありません――この場合、ノードや設定を変更しても効果はなく、ピークが過ぎるのを待つか、負荷の軽い回線を選ぶしかありません。

プロトコル種別による追加オーバーヘッド

異なるプロキシプロトコルはハンドシェイク方式や暗号化のオーバーヘッドが異なり、ネットワーク状況が一般的な環境ではプロトコルの選択自体が速度差を生むことがあります。例えば一部のTLSを多重にラップするプロトコルは弱いネットワーク環境で再送コストが高くなりますが、より軽量なプロトコルはオーバーヘッドが小さい一方で速度制限を受けやすい場合もあります。プロトコル層の問題が疑われる場合、同一の着地サーバー・同一時間帯で、そのサーバーが提供する異なるプロトコルのノードを(サービス提供者が同時に提供している場合)それぞれテストし、速度差が顕著かどうかを比較できます。

mihomo カーネルにおける分流のオーバーヘッド

mihomo(Clash Meta)カーネルを使用する場合、ルールセットの数が多すぎたり、GeoIP/GeoSiteのマッチング階層が深すぎたりすると、各接続に余分な判定処理時間が加わります。特にルールセットが適切に並べ替えられておらず、よく使うルールがリストの末尾に配置されている場合はより目立ちます。アクセス頻度の高いルール(例えば直結すべき国内ドメイン)を一時的にルールリストの先頭付近に移動させ、接続ごとのマッチング回数を減らすことができます。これは回線・プロトコル層以外の小さな最適化ポイントですが、高頻度アクセスのシーンでの体感改善は比較的直接的です。

第3層:ローカル設定――MTU・分流ルール・システムプロキシ

前の2層をすべて確認しても問題が見つからず、すべてのノード・すべての時間帯で遅い場合、問題はローカルのネットワークスタックやクライアント設定にある可能性が高いです。この層は最も見落とされやすい部分で、ノードの遅延テストには反映されないためです。

TUNモードにおけるMTU設定の確認

TUNモードを有効にして全体のトラフィックを引き継ぐ場合、MTU(最大転送単位)の設定が実際のネットワークカードと一致しないと、大きなパケットが強制的にフラグメント化され、余分な再構成オーバーヘッドが発生します。遅延の高いリンクでは明らかな速度低下や間欠的なフリーズとして現れます。まずTUNのMTU値を一般的な1500に調整するか、ISPの推奨に従って1400付近に下げてみて、調整後に再測定して比較してみてください:

tun:
  enable: true
  stack: system
  mtu: 1500

MTUを調整した後に速度が明らかに改善した場合、以前のフラグメント問題が確かに存在していたことになります。変化がなければこの要因は排除でき、次の確認に進んでください。

分流ルールがトラフィックを迂回させていないか確認

一部のカスタムルールセット設定が不適切だと、本来直結すべきトラフィックが誤ってプロキシノードに振り分けられたり、逆にプロキシを通すべきトラフィックが直結になったりし、「あるサイトは遅く、あるサイトは正常」という現象として現れます。クライアントの接続パネルを開き、現在アクティブな接続が実際にどのルールとアウトバウンドノードにマッチしているかを確認し、トラフィックの経路が想定通りかどうかを確かめてください。

システムプロキシとブラウザプロキシの重複を確認

システムプロキシとブラウザ拡張のプロキシを同時に有効にしていたり、ブラウザに手動でプロキシアドレスを設定しつつTUNモードでも引き継いでいたりすると、トラフィックが二重にプロキシを経由してしまい、不要な遅延が積み重なることがあります。プロキシの接続方式は一つだけに絞ることを推奨します:TUNモードで全体を引き継ぐか、システムプロキシを使うかのいずれかにして、ブラウザ拡張で手動設定したプロキシアドレスを同時に重ねないようにしてください。

1. TUNモードのMTU値が自分のネットワークカード設定と一致しているか確認する。
2. 接続パネルで、よくアクセスするドメインの実際の分流経路が想定通りかを確認する。
3. ブラウザ拡張で手動設定されたプロキシアドレスを無効化し、システムプロキシやTUNモードとの重複を避ける。
4. クライアントを再起動し、再度帯域測定を行って調整の効果を確認する。

よくある誤判定パターン対照表

診断の過程で最も起こりやすい誤判定は、「ノードを変えても解決しないならソフトウェアの問題だ」というものと、「遅延数値が低ければ速度も速い」というものです。前述の3層の考え方を踏まえ、以下の典型的な現象と照らし合わせることで素早く問題箇所を特定できます:

• すべてのノードで遅く、時間帯を変えても改善しない → まずローカルのMTUとプロキシの重複設定を確認する。
• 日中は正常、夜間にまとめて遅くなる → 回線のピーク混雑、待つか負荷の軽い回線に変更する。
• 特定のノードだけ持続的に遅く、他は正常 → そのノードの帯域または上流回線自体に問題がある。
• 遅延数値は低いがダウンロード速度は悪い → 遅延テストはハンドシェイク速度しか反映しないため、帯域測定を別途行う必要がある。

この4つのパターンを一通り照らし合わせれば、おおよそ10分以内に問題のある階層を特定でき、無駄にノードを切り替えたりクライアントを再インストールしたりする手間を避けられます。