Clash が遅いときの調べ方:ノード・回線・ローカル設定の三段階チェック

なぜ三段階で調べるべきか、いきなりノードを変えてはいけない理由

速度が遅くなるという相談は、Clash / Clash Meta(mihomo コア)を使っていて最も多く聞かれるものですが、「遅い」という現象の裏には三つの段階のどこかに問題があるケースがほとんどです——ノード自体の品質低下、国際回線の混雑、あるいはローカルのクライアント設定の不備です。多くの人はまずノードを変えようとしますが、いくつか試しても遅いままだと、今度はサブスクリプション自体を疑い始め、あちこち触っても結局原因がわからないまま終わってしまいます。原因は段階を分けて検証していないことにあります。三つの問題はいずれも「重い」「遅い」「読み込めない」という似た症状として現れますが、確認方法はまったく異なるため、混ぜて測っても時間の無駄になります。

本記事では遠い要因から近い要因の順に切り分けます。まずノード自体が健全かどうか(遅延・パケットロス・倍率)を確認し、次に国際回線が混雑していないか(混雑しやすい時間帯・出口帯域)を確認し、最後にローカル設定が足を引いていないか(DNS・ルール一致・TUNモードとシステムプロキシの競合)を確認します。各段階で「とりあえずノードを変えてみる」といった曖昧な対処ではなく、その場で実行できる具体的な確認動作を示します。

第一段階:ノード品質——遅延・パケットロス・倍率

ノード品質は最も検証しやすく、最初に確認すべき段階です。クライアント画面でノード名の右に表示される遅延値は、ポリシーグループの url-test による探測結果で、端末からノードを経由してテスト用アドレスまでの往復時間を反映しています。数値そのものは参考程度で、より重要なのは安定しているかどうかです。

遅延に加えて、パケットロス率とトラフィック倍率にも注目してください。パケットロス率が高いと TCP の再送が繰り返され、ページの読み込みがカクついたり動画のバッファリングが頻発したりしますが、遅延の数値自体はさほど高くないこともあります。これが「遅延を見ただけでは良いノードだと判断してしまうのに実際は重い」という状況の原因です。トラフィック倍率は使える帯域の感覚に直接影響します。同じ共有ノードでも倍率が低いほど混み合う人数が少なくなる傾向があり、混雑しやすい時間帯にその差がより顕著に出ます。

ノードが安定しているかを確認する簡単な方法は、url-test ポリシーグループの探測間隔を短くし、テスト用アドレスを目的のサービスに近いサイトに変え、数分間の遅延曲線を継続して観察することです。瞬間的な数値だけを見るのではありません。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies: [ノードA, ノードB, ノードC]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

tolerance は許容差の範囲を示し、この範囲内の遅延差では切り替えが発生しないため、ノードが臨界値付近で頻繁に切り替わるのを避けられます。interval は探測頻度を制御し、短すぎるとノード側の負荷が増え、長すぎると遅延の変化を素早く反映できません。一般的には180~300秒程度が妥当です。

第二段階:国際回線と混雑しやすい時間帯

特定のノードの遅延が低くパケットロスも少ないと確認できたにもかかわらず、特定の時間帯だけ明らかに遅くなる場合、問題はノードのサーバー自体ではなく国際回線側にあることが多いです。国際回線の出口帯域は限られたリソースであり、20時~23時のような混雑しやすい時間帯には同じ利用者が集中してアクセスするため、国際出口全体の帯域負荷が重なり、ノードサーバーの負荷が正常でも実際に使える速度は落ちてしまいます。

この問題を見極める方法は簡単です。同じノードを異なる時間帯で繰り返し測定して記録してください。遅延と速度に明らかな「昼夜の傾向」が見られる場合——例えば深夜は正常で夜間に集中的に遅くなる場合——回線の混雑によるものだと判断できます。逆に一日中どの時間帯でも遅い場合は、第一段階に戻ってノード自体を再確認したほうがよいでしょう。

また「中継転送型」と「直接接続型」の二種類の回線構造も区別しておく必要があります。前者は中間ノードで一度転送を行い、後者は接続先サーバーから直接目的のサイトへアクセスします。中継構造は経由するホップ数が増える分、追加の混雑ポイントが生じる可能性があります。同地域に複数のノードが選べる場合は、それぞれ測定してホップ数が少なく遅延曲線が安定している方を日常用に選び、遅延は高いが緊急時に使えるノードは控えとして残しておき、ポリシーグループの手動選択モードで区別すると良いでしょう。自動測定に任せて両者の間を頻繁に切り替えさせるのは避けるべきです。

第三段階:ローカル設定——DNS・ルール一致・モードの競合

ノードと回線の二段階を除外した後も速度の問題が続く場合、ほぼローカルのクライアント設定が原因だと確定できます。この段階は最も見落とされやすい一方で、最も多い「見えにくい速度低下」の原因でもあります。

DNS の解決方式

DNS の設定が適切でないと、ドメイン名の解決が誤ったパスを通ってしまい、プロキシルール自体が正しくても、アクセス体感が遅くなったり「一部のサイトは開けるが一部は開けない」といった状況が起きたりします。mihomo コアでは fake-ip モードを独立した DNS サーバーと組み合わせて使うことを推奨し、解決リクエストがローカルの通信事業者の DNS に漏れたり汚染されたりするのを防ぎます。

dns:
  enable: true
  ipv6: false
  default-nameserver: [223.5.5.5, 119.29.29.29]
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - "https://doh.pub/dns-query"
    - "https://dns.alidns.com/dns-query"
  fallback:
    - "https://1.1.1.1/dns-query"

redir-host モードを使っている場合、解決結果はローカルのネットワーク環境に依存するため、通信事業者側のDNS汚染やハイジャックの影響を受けやすくなります。特別な理由がない限り fake-ip への切り替えを推奨します。

ルール一致とポリシーグループの選択

ルールファイルの順序が間違っていたり、ルールセットが更新されていなかったりすると、本来プロキシを経由すべきトラフィックが DIRECT(直接接続)と判定されたり、逆にローカルサービスのトラフィックまでプロキシグループに流れ込んでしまったりします。どちらのケースも「速度が遅い」という現象として現れます。クライアントの接続ログやトラフィックパネルで、実際の接続がどのルールに一致し、どのポリシーグループを通っているかを確認し、想定どおりかどうかを主観ではなく客観的に判断してください。

TUNモードとシステムプロキシの競合

TUNモードとシステムプロキシを同時に有効にしている場合、あるいはTUNモードでMTUの設定が大きすぎてフラグメントの再送が発生している場合、いずれも明らかな速度低下を引き起こします。一般的にはどちらか一方だけを使うことを推奨します。全体のトラフィックを引き受けブラウザ以外のアプリも対象にしたい場合はTUNモードを、ブラウザなど少数のアプリだけをプロキシ経由にしたい場合はシステムプロキシを使い、両方の経路制御を重ねて混乱させないようにしてください。

三段階チェックのまとめとセルフチェックリスト

上記三段階をつなげて、そのまま実行できる確認の順序にまとめると、原因の特定にかかる時間を大幅に短縮でき、原因がわからないままノードを繰り返し変える手間を避けられます。

1. まずノードを測定

   同地域の2~3個のノードを切り替え、遅延曲線とパケットロスの状況を継続して観察し、ノード自体の失効や過負荷の可能性を排除する。

2. 次に回線を測定

   健全だと確認済みの同じノードを使い、混雑しやすい時間帯と混雑していない時間帯でそれぞれ一度測定し、明らかな昼夜の速度低下パターンがあるかを判断する。

3. 最後にローカルを確認

   DNSモードが fake-ip になっているかを確認し、接続ログでルール一致が想定どおりかを確認し、TUNモードとシステムプロキシが同時に有効になっていないかを確認する。

4. 結果を記録してから結論を出す

   三段階それぞれの測定結果を記録してから、ノードを変えるか、時間帯を変えて使うか、ローカル設定を調整するかを決める。複数箇所を同時に変更してどの操作が効いたのか特定できなくなる事態を避ける。

繰り返し発生する「速度が遅い」という問題の大半は、最終的にこの三段階のいずれかに原因を帰着させることができます。しかも単一の原因ではなく、複数の段階が重なり合って体感上の重さを増幅させていることが多いです。順序どおりに一段階ずつ検証するほうが、感覚だけでノードを何度も変えるより時間の節約になり、サブスクリプション提供元やコミュニティに具体的な現象を伝えやすくなります。