トラブル解決読了時間:約8分

Clash 通信速度が遅い時の階層別診断法:ノード・回線・ローカル設定

通信速度の低下は「ノードが悪い」と決めつけられがちですが、実際の原因は伝送プロトコル・ローカルのDNS・振り分けルールにあることも珍しくありません。本記事では「ノード自体→伝送回線→ローカル設定」の3段階に分けて診断の考え方を整理し、具体的な手順を紹介します。

診断前に問題の範囲を絞り込む

設定を触る前に、まず2分ほど時間をかけて症状を具体的に確認しておくと、その後の無駄な試行を大幅に減らせます。「通信が遅い」という表現は非常に曖昧で、少なくとも3つの異なる現象を指している可能性があり、それぞれ原因がほぼ異なります。

  • ページやアプリの読み込みが遅いが、読み込み後の再生はスムーズ——多くは帯域不足ではなく遅延(RTT)が高いのが原因。ノードの距離や回線品質を優先的に確認しましょう。
  • ダウンロードや再生中に速度が上がらず、途切れが繰り返される——帯域不足や回線の混雑が濃厚。ノードの負荷や伝送プロトコルを確認しましょう。
  • 特定のサイトやアプリだけ遅く、他は正常——プロキシ自体の問題ではなく、振り分けルールがそのトラフィックを適切でないアウトバウンドに送っている、あるいは対象サイトがプロキシのIPを速度制限している可能性が高いです。

現象を分類できたら、どの段階から診断を始めるかを決めます。判断に迷う場合は、以下の3段階を順番に確認するのがおすすめです。この順序は「検証コストが低い順」で設計されており、まず検証しやすいノードの問題を除外し、次に回線設定を確認し、最後にローカルのシステム設定に手をつける流れになっています。

ポイント

診断中は一度に1つの変数だけを変えてテストしましょう。ノード・プロトコル・DNSを同時に切り替えると、どの操作が効いたのか分からなくなります。

第1段階:ノード自体の速度ボトルネックを確認する

ノードは通信経路の出発点であり、検証コストが最も低く、最初に除外すべき段階です。多くのサブスクリプションには複数の地域・回線のノードが含まれており、その速度差は想像以上に大きいことがあります。

遅延テストで一次スクリーニング

クライアントのノード一覧には通常、遅延テストボタンがあります(Clash Meta カーネルの場合は url-test によるヘルスチェック)。クリックすると各ノードにHTTPリクエストを送り、応答時間を記録します。遅延テストが示すのは「接続が確立できるか、接続の立ち上がりが速いか」であり、実際の転送速度と完全に一致するわけではありませんが、遅延が常時500ms超、またはタイムアウトになるノードは基本的に除外できます。

  • 遅延150ms未満:Web閲覧やチャットには十分。
  • 遅延150〜400ms:利用可能だが、動画やゲームでは目に見える引っかかりが出る。
  • 遅延400ms超・タイムアウト頻発:優先的にノードを変更し、このノードでの追加診断はおすすめしません。

ノードの高負荷を除外する

共有ノードはピーク時間帯(多くのサブスクリプションでは19:00〜24:00頃)に帯域が多数の利用者で分け合われ、遅延テストは正常でも実際のダウンロード速度が低くなることがあります。この場合、遅延テストでは問題を検出できないため、手動での実測が必要です。対象ノードに切り替えた状態で、速度が安定している既知の静的ファイル(公開されている速度測定用ファイルなど)にアクセスし、異なるノード・異なる時間帯でのダウンロード速度を比較します。同じノードでも非ピーク時間帯に明らかに速くなる場合は、負荷の問題であって設定の問題ではないと判断できます。

プロキシグループに自動測速とフェイルオーバーを設定する

サブスクリプション内に同一地域の複数ノードがある場合は、proxy-groups に url-test タイプのグループを設定し、適切なテスト間隔を指定することで、クライアントが自動的に遅延の低いノードを選択できるようにし、手動切り替えの頻度を減らせます。

proxy-groups:
  - name: 自動選択-香港
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - HK-01
      - HK-02
      - HK-03

tolerance は許容誤差の範囲を表し、数ミリ秒程度の遅延の揺れで頻繁に切り替わって接続が途切れることを防ぎます。

第2段階:伝送回線とプロトコル設定を確認する

ノード自体に明らかな問題がないことを確認したら、次は「端末からノードまでどのような経路・プロトコルでデータが送られているか」を見ます。この段階の調整は、ノードを変えるよりも速度改善につながることが多く、特にネットワーク環境が特定のプロトコルを制限・妨害している場合に効果的です。

伝送プロトコルを切り替えて試す

同じノードで複数のプロトコル(VMess、Trojan、Hysteria2、ShadowTLS など)が提供されている場合、同じネットワーク環境でもプロトコルによって挙動が大きく異なることがあります。一部のネットワークではTCP系プロトコルへのディープパケットインスペクションが厳しい一方、UDPベースのプロトコル(Hysteria2、TUICなど)は前方誤り訂正や輻輳制御を内蔵しているため、パケットロス率の高い回線ではむしろ安定することがあります。複数プロトコルのノードが利用可能な場合は、次の順で個別に検証しましょう。

  1. まずTCP系プロトコル(VMess/Trojan)の実際のダウンロード速度を測定する。
  2. 次に同じ時間帯でUDP系プロトコル(Hysteria2/TUIC)の挙動を測定する。
  3. 両者の差を記録し、より安定している方のプロトコルを常用する。

速度制限や妨害を受けていないか確認する

一部のネットワーク環境では、検出したプロキシ通信を遮断せず速度制限をかけることがあります。この場合、接続は確立でき遅延テストも正常ですが、転送速度が低い一定値に抑えられます(例えばどのノードに変えても常に200KB/s程度で頭打ちになる、など)。この場合はノードを変えても意味がなく、TLS偽装の有効化や、より耐妨害性の高いプロトコルへの切り替えなど、伝送層の偽装方式の変更を検討する必要があります。

TUNモードとシステムプロキシの違いを確認する

TUNモードはシステムのネットワーク層で全通信を処理する方式で、ブラウザ以外のアプリ(ゲームやバックグラウンドサービス)のプロキシ処理が必要な場面によく使われます。理論上はシステムプロキシより遅くなるはずはありませんが、端末上に他の仮想ネットワークアダプタやセキュリティソフトのネットワークフックが同時に動作していると、干渉によるパケットロス・再送が発生することがあります。TUNモードを無効化し、同じノードでシステムプロキシモードの速度を比較する対照テストを行いましょう。システムプロキシモードの方が明らかに速い場合、問題はノードやプロトコルではなく、端末のネットワークドライバ層にある可能性が高いです。

現象考えられる段階推奨アクション
どのノードに変えても同じくらい遅いローカル設定/ネットワーク環境DNS、TUN、システムのネットワーク設定を確認
特定の時間帯だけ遅いノードの負荷同地域の別ノードに変更、または利用時間をずらす
TCPプロトコルは遅いがUDPプロトコルは速い伝送回線の妨害プロトコルの種類を切り替える
特定のサイトだけ遅い振り分けルール/対象サイトの速度制限ルールの一致状況を確認し、アウトバウンド戦略を変更

第3段階:ローカルクライアントとシステム設定を確認する

前の2段階で問題が見つからない場合、多くはローカル設定が原因になっています。この段階は検証コストがやや高いものの、長期間繰り返し発生する速度問題の根本原因になっていることが少なくありません。

DNS解決の設定を見直す

DNS解決が遅いと「ページの初回読み込みだけ遅く、リソース読み込み後はスムーズ」という現象が起こり、ノードの問題と誤認されやすくなります。設定ファイルでクライアント専用のDNSサーバーを指定し、fake-ip モードを有効にして不要な実DNS解決の遅延を減らすことをおすすめします。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

nameserver は中国本土のドメイン解決を、fallback はプロキシ対象ドメインの解決を担当します。両者を分けて設定することで、中国本土のサイトが不要な迂回解決によって余計な遅延を受けることを防げます。

振り分けルールを整理する

ルールの数が多すぎたり、ルールセットのサイズが大きすぎたりすると、クライアントが各接続を照合するのにかかる時間が増え、低スペック機器(特にルーターや古いスマートフォン)では影響が顕著になります。機能が重複するルールセットを複数読み込んでいないか確認しましょう。例えば広告フィルタリングルールを2種類同時に有効にしている、地域振り分けルールが複数重複しているなどのケースです。重複ルールを統合・削除することで照合コストを減らせます。また、ルールの並び順が適切かどうかも確認しましょう——マッチ頻度の高いルール(中国本土のドメインを直結にするルールなど)をリストの上位に置くことで、平均的な照合回数を減らせます。

バックグラウンドで帯域を使うプログラムを止める

クラウド同期ツール、OSの自動更新、バックグラウンドダウンロードなどはいずれも出口帯域を消費し、プロキシ通信と競合します。その結果「プロキシ自体には問題がないのに、全体の速度が上がらない」という状態になります。速度測定の前にタスクマネージャーやアクティビティモニタでネットワーク使用状況を確認し、明らかに帯域を消費しているバックグラウンドプロセスを一時停止してから再測定しましょう。

クライアントのバージョンとカーネルの状態を確認する

古いバージョンのクライアントやカーネルを使用している場合、後続バージョンで追加された特定プロトコルの性能最適化が反映されていないことがあります。速度問題が長期間続き、上記の診断で原因が特定できない場合は、新しいバージョンがあるか確認し、更新後に改めて上記3段階の診断を行って問題が解消するか確認しましょう。

再利用可能な診断フローを作る

上記の内容をシンプルなチェックリストにまとめておくと、速度問題が発生した際に順番に確認するだけで、診断にかかる時間を大幅に短縮できます。

  1. 遅延テストで明らかに異常なノードを除外する。
  2. 同地域のノードで実測ダウンロード速度を比較し、負荷の問題を除外する。
  3. プロトコルの種類を切り替え、TCP系とUDP系の挙動を比較する。
  4. TUNモードを無効化して対照テストを行い、端末側ネットワーク層の干渉を除外する。
  5. DNS設定を確認・調整し、解決速度を確認する。
  6. 振り分けルールを整理し、照合コストを減らす。
  7. バックグラウンドで帯域を消費しているプログラムを確認する。
  8. クライアントとカーネルのバージョンが最新であることを確認する。

ほとんどの速度問題は最初の3ステップで特定できます。ローカル設定まで踏み込んで診断が必要なケースは比較的少ないものの、一度発生すると長期間繰り返し悩まされる原因になりがちです。ノードを次々変えて場当たり的に対応するより、時間をかけて一度徹底的に診断する方が結果的に効率的です。

Clash をダウンロード