Clash 速度低下チェックリスト:ノード・回線・ローカル設定を段階的に切り分ける

速度低下はプロキシツール利用時に最もよく報告される問題ですが、「遅い」原因は実はまったく異なる3つの層に分散しています。ノード自体の品質、ノードとローカル間の国際回線の状況、そしてローカルクライアントの設定の細部です。多くの人はまずノードを変えようとしますが、何度変えても同じ問題が続くのは、層ごとに切り分けていないからで、結局時間を無駄にするだけです。この記事では切り分けの流れを3層に分解し、具体的な操作手順とともに、当てずっぽうではなく問題を根本から特定する方法を紹介します。

第1層:ノード品質自体の問題

ノード品質は最も基礎的な層であり、同時に最も誤判定されやすい層でもあります。同じサブスクリプション内のノードでも品質差は大きく異なることがあります――帯域が十分で遅延も安定しているノードもあれば、共有出口でピーク時に激しく混雑するノードもあります。ノードに問題があるかどうかは、クライアントに表示される遅延の数値だけでなく、実際のスループット表現も合わせて判断する必要があります。

遅延テストの正しい読み方

多くの Clash クライアントはプロキシリストに遅延テストボタンを用意しており、クリックすると各ノードの横にミリ秒単位の数値が表示されます。この数値はクライアントからノードサーバーまでの往復リクエストにかかった時間を計測したもので、通常はテスト用アドレス(例:www.gstatic.com/generate_204)へのHTTPリクエストに基づいています。遅延が低いことは接続確立が速いことを示しますが、**帯域が広いことを意味しません**――遅延80msのノードが遅延40msのノードより実際には速いこともあり得ます。帯域と遅延は独立した指標だからです。

• 遅延が常に300msを超え、タイムアウトが頻発する:回線品質が低い、またはサーバー負荷が高すぎる可能性が高く、変更を推奨。
• 遅延は正常だがダウンロード速度が上がらない:ノードの帯域が制限されている、またはピーク時に多数のユーザーが共有出口を占有している可能性。
• 遅延の波が大きい(同じノードで何度測っても結果が数百ミリ秒違う):回線が不安定で、普段使えても動画通話や大容量ダウンロード時に速度低下やカクつきが発生しやすい。

実際のダウンロード速度計測で検証する

遅延テストは初期スクリーニングにしかならず、ノードが本当に高負荷に耐えられるかを判断するには、実際のダウンロード速度計測が必要です。速度測定サイトをブラウザで開くか、コマンドラインツールで容量が明確なファイルをダウンロードし、所要時間からMB/sに換算します。テスト時は変数を統一することが重要で、同時に1つのノードだけをテストし、他のデバイスが帯域を占有して結果を乱さないよう注意します。

# Windows PowerShell でダウンロード速度を簡易測定する方法
Measure-Command { Invoke-WebRequest -Uri "https://your-test-file-url" -OutFile "test.bin" }

測定した速度と遅延の表現が大きく食い違う場合(遅延は低いがダウンロードが遅い)、基本的にはノードの帯域またはサーバー側の負荷の問題と判断できます。この場合、同じサブスクリプション内で遅延の近い別のノードに変える方が、現在のノードにこだわるより効果的なことが多いです。

第2層:国際回線の状況

ノード自体に問題がなくても、データがローカルからノードサーバーまで到達する間に複数のネットワークリンクを経由するため、どこか一段でも混雑すれば全体の速度は落ちます。この層の問題は通常、異なるプロバイダーのノードに何度変えても速度がほぼ同じで、特定の時間帯(例えば夜のピーク時)に特に速度低下が目立つという形で現れます。

ルートトレースで混雑ポイントを判断する

ルートトレースツールは、自分の端末から目的のサーバーまでデータパケットが経由する各ホップと、各ホップの遅延を表示します。特定のホップで遅延が急増し、それ以降のすべてのホップも連動して高くなっている場合、混雑はそのホップ付近で発生していることを示し、通常は国際出口や特定の中継バックボーンの問題であり、ノード自体で解決できるものではありません。

# Windows でルートをトレースする
tracert ノードサーバーのIPまたはドメイン

# GUIが好みなら WinMTR のようなツールで変動を継続観察するのも良い

注意すべき点として、プロキシノードのドメインに直接ルートトレースを行うと、結果はそのサーバーへの公開ネットワークパスしか反映せず、プロキシトンネルを経由した実際のパスとは完全には一致しませんが、参考としては依然価値があります――もしこのパス自体が迂回していたり混雑ポイントを経由していたりする場合、ノードのプロバイダーを変更しても、大抵は似たようなバックボーン区間を経由することになります。

プロトコルを切り替えて回線問題を緩和する

一部の国際回線は特定のプロトコルに対する干渉や制限がより顕著です。特定のプロトコル(例えば一部のTCP直結)が特定の時間帯に速度が急落し、他のプロトコルは比較的安定している場合、同じ入口に対して異なるプロトコルのノードをそれぞれテストし、実測でより安定している方を日常使いとして選ぶことができます。プロトコル切替は回線層の問題への一般的な対処法であり、プロバイダー変更を伴わず、コストも低い方法です。

第3層:ローカルクライアントとシステム設定

ノードと回線の問題を除外した後、残る速度問題の大部分は実はローカル側にあります。この層は最も見落とされやすいものの、切り分け自体は比較的シンプルで、しかも1回の調整で解決することも多いです。

振り分けルールが通信を低速な経路に流していないか確認する

Clash の振り分けルールは、各接続がプロキシを通すか直結するか、プロキシを通す場合はどのノードグループを経由するかを決定します。ルールファイルの設定が不適切だと、直結すべき通信が強制的にプロキシに流されたり、高速ノードグループを使うべきドメインが低速ノードグループにマッチしてしまうことがあります。クライアントのログページを開き、実際の接続がどのルールにマッチし、どのポリシーグループに落ちているかを観察するのが、この種の問題を特定する最も直接的な方法です。

• ルールの順序ミス:Clash のルールは上から下への順序でマッチングされ、一度マッチすると以降は評価されません。過度に広範なルールを前に置くと、本来もっと正確なルールにマッチすべき通信を「横取り」してしまいます。
• ポリシーグループ内に品質のばらつくノードが混在:あるポリシーグループが「自動で最速を選択」戦略を使っていても、グループ内のノード品質が不揃いなら、自動選択されたものが現在のシナリオに最適とは限りません。既に検証済みの安定ノードを手動指定できます。
• 大容量通信のシナリオ用に個別グループを分けていない:例えばダウンロードや動画のようなシナリオがWebブラウジングと同じポリシーグループを共有していると、マッチしたノードの帯域が限られている場合に互いに干渉します。適切にポリシーグループを分けることで、各シナリオがそれぞれ最適なノードを見つけやすくなります。

DNS設定が速度に与える見えにくい影響

DNS解決が遅い、または解決結果が理想的でない場合も、「速度が遅い」という錯覚を生みます――実際はドメイン解決の工程に時間がかかっている、または解決されたIP自体のルーティングが良くないというケースです。Clash Meta(mihomo カーネル)は DNS 振り分け設定に対応しており、中国本土のドメインと海外のドメインに対して別々の解決サーバーを指定でき、fake-ip モードと組み合わせて不要な実解決のオーバーヘッドを削減できます。

dns:
  enable: true
  ipv6: false
  default-nameserver: [223.5.5.5]
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

ページを開く際の「ぐるぐる」時間が実際の読み込み時間より明らかに長い場合は、まず解決工程が全体の体感を遅らせていないか確認し、その後ノードの問題を検討してください。

TUNモードとシステムプロキシの違い

Clash はシステムプロキシとTUNモードという2種類の接続方式を提供します。システムプロキシは HTTP/SOCKS プロキシパラメータの設定によって機能し、システムプロキシ設定を読み取れるアプリケーションにのみ有効です。TUNモードはネットワークカード層で全通信を引き受け、カバー範囲がより広い一方、システムリソースとネットワークスタックへの要求も高くなります。特定のアプリだけ遅く感じ、他のアプリは正常な場合、通常はそのアプリがプロキシ設定を経由していない、または個別に直結として設定されているためであり、ノードや回線の問題ではありません。逆に、TUNモードを有効にすると全アプリが一様に遅くなる場合は、端末のファイアウォールやセキュリティソフトと衝突していないか確認し、TUNモードを一時的に無効にして速度を比較すれば、問題がこの引き受けロジックの層にあるかどうかを素早く判断できます。

ローカルネットワーク環境の干渉要因

最後に、最も基本的な可能性も見落とさないでください。ルーター自体の負荷、Wi-Fi信号の強さ、同一ネットワーク上の他デバイスによる帯域占有は、いずれも「Clashが遅く見える」現象を引き起こします。クライアントを閉じて直結の速度を直接測定し、プロキシを有効にした状態の速度と比較することは、ローカルネットワーク環境の干渉を排除し、問題が本当にプロキシ経路にあることを確認する上で欠かせないステップです。

推奨される切り分けの順序

上記3層をつなげると、一連の切り分けは以下の順序で行うことを推奨します。複数の変数を同時に変更すると特定が混乱するため避けましょう。

1. プロキシを無効にして直接速度を測定し、ローカルネットワーク自体に問題がないことを確認する。
2. プロキシを有効にし、現在のノードの遅延と実際のダウンロード速度が一致しているかを確認し、ノード自体の品質問題かどうかを判断する。
3. 同じサブスクリプション内で遅延の近い別のノードに変更して比較テストを行い、問題がノードの変化に応じて変わるかを確認する。
4. 複数のノードで一様に遅い場合は、ルートトレースで固定の混雑ホップがあるかを観察し、問題が回線層にあるかを判断する。
5. ノードと回線を除外した後、振り分けルールのマッチ状況、DNS解決の所要時間、システムプロキシとTUNモードの接続方式の違いを確認し、ローカル設定の問題を特定する。

この順序で一巡すれば、通常は10数分でどの層に問題があるかを絞り込めます。ノードを何度変えても根本原因が見つからないという事態を避けられます。日常的に遅延と速度測定の記録を残しておくと、問題が起きた際に異常点をより早く比較できます。