Clashの速度低下を切り分ける:ノード・回線・ローカル設定の3階層チェック法

なぜ段階的に切り分けるのか、すぐノードを変えてはいけない理由

速度低下はプロキシツール全般でよく報告される不満ですが、その「遅さ」の原因は3つの完全に異なる場所に潜んでいます。ノード自体の品質、デバイスからノードまでの伝送回線、そしてローカルクライアントの設定です。多くの人はカクつきを感じるとすぐノードを切り替え、3つも5つも試してまだ遅いと「このサブスクリプションは駄目だ」と結論づけてしまいます。しかし実際にはローカルのDNS設定やルールマッチングで詰まっているだけで、ノードとは無関係なケースも少なくありません。

闇雲なノード変更には2つのコストがあります。1つは高倍率で消費される有料ノードのトラフィックを浪費すること、もう1つは本当の故障箇所を見えなくしてしまい、同じ問題が再発することです。段階的に切り分けるメリットは、各層に明確なチェック手順と判断基準があること。1層終えるごとに原因のカテゴリを1つ除外または特定できるため、10分程度で問題箇所をかなり絞り込めます。

第1層:ノード品質の確認

ノード品質とは、プロキシサーバー自体の応答速度・負荷状況・回線帯域のことで、ローカル設定とは無関係です。この層は最も検証しやすく、最初に除外すべき層でもあります。

1. 遅延の数値を見る、色だけで判断しない

多くのClashクライアント(Clash Meta系のmihomoコアを使うクライアントを含む)には、ノード一覧に遅延テストボタンがあり、クリックすると各ノードにミリ秒単位の数値が表示されます。おおよその判断基準は以下の通りです。

遅延テストが測るのは「接続応答時間」であり、ダウンロード速度そのものではありませんが、両者には強い相関があります。遅延が長期的に高いノードは、ダウンロード速度もまず改善しません。逆に遅延が正常なのに実際のダウンロードが遅い場合は、この層に問題はなく、第2層のチェックに進みましょう。

2. 異なる地域の2〜3ノードを比較検証する

1つのノードだけで結論を出さないことが重要です。同じサブスクリプション内から異なる拠点・地域のノードを2〜3個選んで速度を測定し、いずれも遅い場合は回線かローカル設定の問題である可能性が高く、一部のノードだけ遅い場合はそのノード自体の負荷問題です。後者なら別の正常なノードに切り替えれば済み、これ以上の切り分けは不要です。

3. トラフィック倍率とプラン残量を確認する

一部のサブスクリプション提供元は高倍率ノードに速度制限をかけていたり、契約トラフィックが上限に近づくと一時的に速度を落としたりします。こうした場合、遅延テストは正常でも実際のダウンロード速度は明らかに制限されます。クライアントのサブスクリプション情報から残りトラフィックと有効期限を確認し、プラン側の制限を除外しましょう。

第2層:伝送回線のチェック

回線とは、データがローカルデバイスを出発し、ローカルネットワーク・ISPの基幹網を経由して、最終的にプロキシサーバーへ到達する一連の経路のことです。この層の問題はプロキシソフト側では解決できないことが多いですが、テストで原因を確認すればソフトを誤って疑わずに済みます。

1. 直接接続の速度を基準値として測る

まずプロキシをオフにして、ローカルネットワークだけでのダウンロード速度を測定します(回線業者の速度測定ツール、または大きめのファイルをダウンロードして時間を計る方法でも可)。直接接続の時点で遅い場合、それはローカルの回線やWi-Fi電波の問題であり、Clashとは無関係です。まずネットワーク自体の問題を解決しましょう。

2. mtrやtracertでルートのホップ数を確認する

直接接続は正常だがプロキシ経由だと遅い場合、ルート追跡ツールでパケットが経由するノードを確認できます。Windowsではコマンドラインで:

tracert 目的サーバーのIP

macOSやLinuxでは:

traceroute 目的サーバーのIP

注目すべき点は2つです。どのホップから急激に遅延が増えるか、そして大量のパケットロス(アスタリスク * で表示)が発生していないかです。国際回線の出口付近のホップで遅延が段階的に増えていくのは物理的な距離による正常な減衰です。一方、あるホップで突然数百ミリ秒単位に跳ね上がり、以降も高止まりする場合は、そのホップが属する通信事業者のノードで混雑が発生していると考えられます。

3. 伝送プロトコルを変えて試す

同一のプロキシ提供元でも、複数のプロトコルに対応したノードが用意されていることが多いです(Shadowsocks、VMess、Trojan、Hysteria2など)。プロトコルによって回線への適性は異なり、特にUDPトラフィックに明確な速度制限をかける回線もあります。Hysteria2のようなQUIC/UDPベースのプロトコルを使っている場合、環境によってはTCP系プロトコルより制限を受けやすいこともあります。同地域でプロトコルが異なるノードがあれば、比較してみましょう。

4. 通信事業者の混雑時間帯に注意する

夜20:00〜23:00は国内の出口帯域が最も混雑する時間帯です。同じノードでも日中は速く、夜になると速度が半減するのはよくある現象で、回線側の正常な変動であり設定の不具合ではありません。時間帯を変えて再測定すれば確認できます。

第3層:ローカルクライアント設定のチェック

前の2層を除外した後、残る原因はほぼクライアント自体の設定に集中します。この層の問題は見えにくいものですが、見つかれば「スイッチを1つ切り替えるだけ」の軽い修正で済むことが多いです。

1. DNSが二重解析になっていないか確認する

enhanced-mode の設定が適切でない場合や、システムDNSとClash内のDNS設定が競合している場合、同じドメインが2回解決されたり、ローカルISPのDNSに戻って解決されたりして、不要な遅延が生じることがあります。設定ファイルの dns セクションを確認し、nameserver が応答の速い解決先を指しているか、fallback が頻繁に発動していないか(頻発する場合はメインの解決ノードが不安定な証拠)を確認してください。

2. ルールモードで誤ったポリシーグループに振られていないか確認する

ルールモード(Rule)では、ルールのマッチミスによってリクエストが速度制限されたノードに振られたり、直接接続に流れた後に通信事業者側で速度制限されたりすることがあります。この場合、「Webページの表示が遅い」のに、プロキシソフト側ではノードが正常に見えるという状態になります。クライアントの接続詳細パネル(通常は「ログ」や「接続」タブ)を開き、実際にアクセスしたドメインがどのルールにマッチし、どのポリシーグループを経由しているかを確認し、想定外のルールに当たっていないかチェックしましょう。

3. TUNモードとシステムプロキシを同時に有効化しない

TUNモードはネットワークカード層で全体のトラフィックを引き受ける方式、システムプロキシはアプリケーション層でHTTP/SOCKSプロキシを設定する方式です。両者は仕組みが異なるため、クライアントでTUNモードを有効にしたまま手動でシステムプロキシも設定していると、一部の通信が重複処理されたり迂回したりして、原因不明のカクつきが発生することがあります。どちらか一方のみを有効にしてください。通常はTUNモードを残せば全体のトラフィックをカバーできます。

4. ミキシングポートとローカルファイアウォール

ローカルファイアウォールやセキュリティソフト、あるいは仮想ネットワークアダプタドライバの不具合により、Clashが待ち受けているミキシングポート(デフォルト7890)に対して深いパケット検査が行われ、転送効率が落ちることがあります。サードパーティのセキュリティソフトを一時的に無効化して試してみてください。速度が明らかに改善する場合は、そのソフトの通信検査が転送経路を遅くしている証拠なので、Clash関連プロセスをホワイトリストに追加する必要があります。

5. クライアント自体のバージョンが古い

古いバージョンのクライアントはコアの転送効率に関する最適化が入っていないことがあります。特にコアがClash Meta/mihomoの本流更新に長期間追随していない場合、転送効率が明らかに劣ることがあります。クライアントとコアのバージョンが最近のリリースかどうかを確認し、古い場合は現在メンテナンスされているバージョンへの更新を推奨します。

10分でできるチェックの流れまとめ

1. ノードの遅延テストを開き、異なる地域の2〜3ノードを比較して、ノード自体の問題かどうかを確認する。
2. プロキシをオフにして直接接続の速度を基準値として測定し、ローカル回線の問題を除外する。
3. ルート追跡で異常なホップがあるかを確認し、回線の混雑状況を判断する。
4. DNS設定・ルールマッチング・TUNとシステムプロキシの競合を確認し、ローカル設定を切り分ける。
5. セキュリティソフトを一時的に無効化して転送効率をテストし、検査による遅延が発生していないか確認する。

順番を間違えても前の手順に戻ればいいだけです。3階層チェックは本質的に対象範囲を徐々に絞り込む作業であり、すべての細部を一度に覚える必要はありません。順番通りに各ステップのチェックを進めれば、答えは途中で自然と見えてきます。