トラブル対処 読了目安 12分

Clashの速度低下を3層で切り分け：ノード・回線・ローカル設定を見分ける

Clashが遅い原因を、ノード・国際回線・ローカル設定の3層に分けて特定。層ごとの速度測定と対処法で、無駄なノード変更を防ぎます。

まず基準値を作る：遅延・帯域幅・安定性は別の指標

Clashパネルに表示される遅延は、通常1回のHTTP接続テストにかかる時間です。ノードに到達できるか、接続確立にどの程度かかるかは確認できますが、ダウンロード速度を直接示すものではありません。遅延85msのノードが8Mbpsしか出ない一方、遅延160msのノードが安定して90Mbps出ることもあります。前者は応答が速くても出口が混雑しており、後者は距離があっても帯域に余裕があるためです。

本格的な切り分けの前に、テスト条件を固定します。ノードを切り替えながらDNSを変更したり、同時にTUNを有効にしたりしないでください。複数の変数を同時に変えると、速度が戻ってもどの設定が効いたのか分かりません。現在の設定を残し、テスト時刻、ノード名、プロキシモード、ダウンロード速度、遅延を記録しておくのがおすすめです。

4種類の基準データ

  1. 直接接続の基準：ClashのシステムプロキシとTUNを無効にし、ISPの速度測定ページにアクセスします。直接接続が20Mbpsしか出ないなら、プロキシで100Mbpsを安定して出すことはできません。
  2. 国内ダウンロードの基準：日本国内のミラーから200MB以上のファイルをダウンロードし、30秒後の安定速度を確認します。Wi-Fiや自宅回線の問題を切り分けるためです。
  3. ノード遅延：同じ地域の3～5個のノードをそれぞれ3回測定します。1回目の結果は採用せず、2回目と3回目の範囲を記録します。
  4. プロキシのスループット：1つのノードで同じテストファイルをダウンロードし、毎回60秒以上継続します。開始直後の瞬間的な速度を安定速度と取り違えないためです。

単位の換算にも注意しましょう。速度測定サイトはMbps、ダウンローダーはMB/sを使うことが多く、両者は約8倍違います。80Mbpsの理論上のダウンロード速度は約10MB/sで、プロトコル、TCP、暗号化のオーバーヘッドを考慮すると、実測8～9.5MB/sなら通常の範囲です。

第1層：ノード自体が遅くなっていないか確認

ノード層の問題は、プロキシサーバー自体やノード提供元の出口で発生します。同じサブスクリプション内の一部のノードだけが遅く、同じ地域の別ノードに切り替えるとすぐ戻るのが典型例です。また、そのノードだけ一日中遅く、他のノードには影響がない場合も該当します。

遅延だけで並べ替えない

自動選択のプロキシグループは通常、テストURLの応答時間を基準にノードを選びます。利用可能性の確認には適していますが、継続的な転送性能までは測れません。テストURLのデータは小さいため、帯域がわずかに残っているノードでも、見栄えのよい遅延値が出ることがあります。

3回測定した例を見てみましょう。ノードAは遅延72、81、76msで、ダウンロード速度は2.1MB/sで安定しました。ノードBは145、151、148msでしたが、ダウンロードは11.4MB/sで安定しました。Web閲覧で最初の応答を重視するならAのほうが速く感じるかもしれませんが、大容量ファイルのダウンロードや高ビットレート動画の視聴にはBが適しています。

ノードの過負荷を見分ける

ノード名に含まれる「倍率」は通常、サブスクリプションの通信量消費を計算するためのもので、速度ランクを示すものではありません。0.5倍のノードが必ず遅いとは限らず、2倍のノードでも速度が2倍になるわけではありません。ノード選びでは、遅延、安定したスループット、パケットロス、通信量コストを分けて確認しましょう。

ノード層での対処法

  1. 同じ地域内でノードを切り替え、プロキシモードとテストファイルは変えない。
  2. 自動選択を無効にして一時的に1つのノードへ固定し、テスト中にプロキシグループが自動切り替えされないようにする。
  3. サブスクリプションを1度更新し、ノードアドレス、ポート、プロトコル設定が提供元によって変更されていないか確認する。
  4. 1つのノードだけに異常がある場合は、テスト時刻と安定速度を記録してからノード提供元へ報告する。

第2層：国際回線やISP経路の混雑か確認

回線層は、自宅回線とプロキシノードの間にあります。ノードサーバー自体に十分な帯域があっても、現在利用しているISPから入口までの経路が迂回していたり、パケットロスや夜間の混雑が発生したりすると、実速度は低下します。この場合、同じデータセンター内の複数ノードへ切り替えても、結果はほとんど変わりません。

回線問題に見られる3つの特徴

通常のpingはICMPパケットを使用するため、サーバーによって優先度を下げられたり、応答されなかったりします。そのため「pingのパケットロスが100%」でもプロキシが使えないとは限らず、「pingが40ms」でもTCPやUDPの転送が快適とは限りません。ClashのHTTP遅延テストは実際のプロキシ接続に近いものの、少量の通信を確認しているにすぎません。

比較テストでISP経路を特定する

  1. ノード1つと200MB以上のダウンロード先を固定し、自宅の固定回線で60秒テストする。
  2. ノードを変えずに4Gまたは5Gのスマートフォンのテザリングへ切り替え、さらに60秒テストする。
  3. 午前中と夜間の混雑時間帯にそれぞれ繰り返し、ピーク値ではなく安定速度を記録する。
  4. テザリングで8MB/s出るのに自宅回線では900KB/sしか出ない場合、Clashのローカル設定は主な原因ではない可能性が高い。

同じ地域のノード全体が混雑しているなら、同じグループを1つずつ試し続けるより、まず地域を変更しましょう。物理的な距離が近いほど遅延は低くなりやすいものの、直線距離より回線品質のほうが重要です。実際の選択は、現在利用しているISPでのテスト結果を基準にしてください。

テスト結果 可能性が高い層 次の手順
1つのノードだけ遅く、他は正常 ノード層 同じ地域の別ノードに固定
同じ地域がすべて遅く、地域変更で回復 回線層 入口の地域を変更し、混雑時間帯を避ける
自宅回線は遅いが、スマートフォンのテザリングは正常 ISP経路 回線を再接続するか、別の回線入口へ変更
すべてのノードが遅く、TUNを無効にすると回復 ローカル設定層 TUN、DNS、セキュリティソフトを確認

第3層：Clashクライアントとローカルネットワーク設定を確認

すべてのノードが同時に遅くなり、ネットワークを変えても差が小さい場合は、ローカル層を確認します。よくある原因は、システムプロキシのポート、プロキシモード、TUN、DNS、ブラウザのプロキシ拡張機能、セキュリティソフト、仮想ネットワークアダプターです。ここでも、一度に変更するのは1項目だけにします。

まずプロキシモードとポートを確認

Clash Verge Rev 2.3.xとmihomo 1.19.xの組み合わせを例にすると、「設定」→「Clash設定」で混合ポートを確認できます。一般的な値は7890ですが、設定ファイルによっては7897、7899など別のポートを使うこともあります。システムプロキシの接続先ポートは、現在カーネルが待ち受けているポートと一致していなければなりません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

ポートが一致しない場合は、通常まったくアクセスできなくなります。ただし、ブラウザ拡張機能、システムプロキシ、アプリ内プロキシが同時に有効だと、リクエストの迂回、二重プロキシ、一部アプリだけの速度異常が起こることもあります。テスト中は入口を1つだけ残しましょう。クライアントのシステムプロキシを有効にするか、対象アプリにHTTP/SOCKSポートを明示的に設定します。

速度テストのリクエストが誤ったプロキシグループへ送られていないか確認

Ruleモードではルールを上から順に照合し、最初に一致した時点で停止します。速度テストサイトのトップページ、ダウンロードドメイン、計測ドメインが別々のポリシーに一致することがあります。ダウンロードドメインがDIRECTへ送られ、ページ自体はプロキシ経由になっている場合、その速度結果はノード性能を示しません。

クライアントの接続ログを開き、通信中のドメインを見つけて、適用されたルールとプロキシグループを確認します。ログには、どのルールに一致したか、最終的にどのノードを使ったかが表示されるはずです。ノード単体をテストする場合は、一時的にGlobalモードへ切り替えて1つのノードに固定します。テスト後はRuleモードへ戻し、普段の通信がすべてプロキシを通らないようにしてください。

TUNモードが遅いときの切り分け

TUNはより多くのシステム通信を引き受けるため、システムプロキシを参照しないアプリや一部のゲームに適しています。一方で、仮想ネットワークアダプター、ルーティング、DNS処理の工程が増えます。システムプロキシモードは正常なのに、TUNを有効にすると明らかに遅くなる場合は、次の順番でテストします。

  1. TUNを無効にし、システムプロキシは有効のまま、同じダウンロードテストを繰り返す。
  2. TUNを再び有効にし、別のVPN、アクセラレーター、古い仮想ネットワークアダプターが同時に動作していないことを確認する。
  3. クライアントのTUN設定で、systemやmixedなど利用可能なスタックを切り替えます。切り替えるたびにカーネルを再起動してください。
  4. MTUを確認します。デフォルト値で一部のWebサイトが固まる場合は、1500、1400、1280の順に試し、変化を記録します。
  5. UDPを使うアプリだけに異常がある場合は、ノードのプロトコルが安定したUDP転送に対応しているかを個別に確認します。

MTUを感覚だけで長期間低く設定するべきではありません。値が大きすぎると断片化や特定接続の停止を招き、小さすぎるとヘッダーのオーバーヘッドが増えます。「Webページは開くのに大容量ファイルで止まる」「一部の画像がいつまでも読み込まれない」といった症状がある場合に限り、段階的なテストを行う価値があります。

DNSの遅さとノード帯域の遅さは別問題

DNSの異常は、最初のページ表示やドメイン解決を主に遅くします。ページのダウンロードが始まった後も帯域を使い切れるなら、通常はノードのスループットに問題ありません。新しいWebサイトを開くたびに3～5秒待たされるのに、表示開始後は速い場合は、ノードを変更する前にDNSを確認しましょう。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

この設定は切り分け用の例であり、既存のサブスクリプションを直接上書きしてはいけません。fake-ipを使う場合、LAN機器、社内ネットワーク、一部の実アドレス依存アプリでは除外ルールが必要になることがあります。DNSの上流も現在のネットワークに合わせて選ぶ必要があり、日本国内側の名前解決とプロキシ側の名前解決では役割が異なります。

ブラウザとバックグラウンドアプリの影響を除外

症状に合わせて固定の切り分け手順を実行

実際の対処で、すべての設定を一通り変更する必要はありません。まず症状に応じて最短の手順を選び、比較テストで結果を確認します。

ケース1：遅延は低いのに、ダウンロードが数百KB/sしか出ない

  1. 現在のノードに固定し、遅延の数値ではなく60秒間の継続ダウンロードを測定する。
  2. 同じ地域の別ノードへ切り替える。速度が戻れば、元のノードが過負荷になっている可能性が高い。
  3. 同じ地域でも遅い場合は別の地域へ切り替え、回線混雑かどうかを判断する。
  4. すべての地域で遅い場合は、TUN、ブラウザ拡張機能、バックグラウンドのダウンロードを無効にして、ローカル層を再測定する。

ケース2：日中は速いのに、夜になると決まって遅くなる

まず日中と夜間のデータをそろえて記録します。たとえば日中11:00は78Mbps、夜間21:30は14Mbpsで、同じノードでもスマートフォンのテザリングは55Mbps出るとします。この結果は、Clashクライアントの障害よりも、自宅回線の夜間混雑による経路の問題を示しています。地域の入口や回線種別を変更するか、混雑時間帯を避けるのが対処の方向性です。

ケース3：ブラウザは速いのに、ゲームやダウンローダーが遅い

まず、そのアプリがシステムプロキシを参照するか確認します。多くのゲームや一部のダウンローダーはHTTPのシステムプロキシを使わないため、TUNまたはアプリ内のSOCKS5設定が必要です。手動プロキシに対応している場合は、127.0.0.1と現在のSOCKS/mixedポート（例：7890）を入力できます。設定後、接続ログで通信が実際にmihomoへ入っていることを確認してください。

ケース4：Clashを有効にすると日本国内のWebサイトまで遅くなる

接続ログを確認し、日本国内のドメインがDIRECTに一致しているか確認します。誤ってプロキシグループへ送られている場合は、ルールの順序とルールセットの更新状態を確認してください。問題を隠すためにすべての通信を直接接続へ変更するのではなく、誤って一致したルールを特定し、ルールセットが正常に読み込まれているか確認します。

対処の優先順位：低リスクの操作から始め、最後に低レイヤー設定を変更

推奨順序は、サブスクリプションの更新、ノードの固定、同じ地域の別ノードへの変更、地域変更、別ネットワークとの比較、TUN無効化との比較、ルールとポートの確認、最後にDNSとMTUの調整です。外部要因からローカルの基盤設定へ段階的に進むため、元に戻す負担を抑えられます。

各テストでは少なくとも60秒間の安定データを残し、変更後はカーネルを再起動します。設定ファイル、DNS、TUNスタック、ノードを同時に変更すると、再利用できる結論が得られません。切り分けが終わったら、Ruleモードに戻し、一時的なデバッグログを無効にして、不要になった手動プロキシ設定を削除します。

DIRECT、PROXY、プロキシグループ、ルールマッチ、fake-ipの関係をさらに理解したい場合は、用語集と高度な設定を参照してください。クライアントを初めて設定する場合は、利用ガイドに従ってサブスクリプション、システムプロキシ、モード選択を改めて確認しましょう。

ClashをダウンロードWindows · macOS · Android · iOS · Linux