Clashが遅いときの層別トラブルシューティング：ノード・回線・ローカル設定を切り分ける

まず「遅い」を定義する：遅延・帯域幅・応答時間は別の指標

Clashやmihomoの画面で遅延が数十ミリ秒でも、ウェブページの表示が遅いことはあります。逆に、遅延180msのノードでも帯域を安定して使い切れる場合があります。遅延、パケットロス、利用可能帯域、ウェブサイトの応答時間は、それぞれ異なる工程を示す指標だからです。ノード一覧の数字だけを見ていると、回線混雑をクライアントの障害と誤認しやすくなります。

症状	優先して確認する項目	判断のポイント
ウェブページをクリックすると2〜5秒待たされ、その後は正常に読み込まれる	DNS、ローカルルール、IPv6	最初のリクエストが名前解決または接続のフォールバックで止まっていないか
速度テストの開始直後は速いが、数秒後に低速になる	ノード負荷、回線混雑、速度制限	持続的なスループットは安定しているか、夜間のピーク時だけ低下するか
動画は再生できるが、画質が頻繁に下がる	持続帯域、パケットロス、ルール判定	動画ドメインが想定したプロキシグループに入っているか
ブラウザーは正常だが、ゲームやストアアプリが遅い	TUNモード、UDP、システムプロキシの適用範囲	対象アプリの通信が本当にmihomoへ取り込まれているか
すべてのノードが同時に遅くなる	ローカルネットワーク、通信事業者の回線、DNS	直結時の基準速度も低下していないか

再現可能なテスト基準を作る

ノードを切り替える前に、テスト条件を固定します。ファイル同期、アップデートのダウンロード、動画再生中のアプリを終了し、同じ端末を同じルーターへ接続してください。テスト対象は、ウェブページの初回表示時間を見るものと、継続ダウンロード用のものを1つずつ用意します。各テストは少なくとも3回行い、単発の最大値ではなく中央値で判断します。

クライアントを「直結」モードに切り替え、家庭回線の遅延とダウンロード速度を記録します。
「ルール」モードに戻し、同じテストノードと同じテスト先を固定します。
午前と夜間20:00〜23:00にそれぞれ測定し、時間帯による差を比較します。
クライアントの現在のモード、ノード名、ダウンロード速度、初回表示までの待ち時間、タイムアウトの有無を記録します。

第1層：ノード側で遅延・負荷・プロトコル状態を確認

ノード側の問題は、同じプロキシグループ内の一部ノードだけが明らかに遅く、別の地域や入口へ切り替えるとすぐ回復する形で現れます。ここでは「遅延テストに合格すること」と「安定したスループットがあること」を分けて考える必要があります。Clashの遅延テストは通常、指定URLへ接続して応答時間を測定するため、応答しないノードの除外には役立ちますが、大容量ファイルのダウンロード速度を直接示すものではありません。

プロキシグループで同じ条件の横比較を行う

クライアントの「プロキシ」ページを開き、現在のルールが実際に参照しているプロキシグループを確認します。一般的なデスクトップクライアントでは、「プロキシ」→「ノード選択」からグループ内のノードを確認できます。Clash Verge Revを使っている場合は、「設定」→「Clash設定」で実行モードを確認してから、「プロキシ」ページでノードを切り替えます。ノードを交換しながらDNS、TUN、ルールも変更すると、どの変更が効果を生んだのか判断できません。

同じ地域のノードを3つ選び、それぞれ3回ずつ遅延テストを実行します。
遅延の変動が100msを超える、またはタイムアウトが連続する場合は、まずノードまたは入口が不安定だと考えます。
遅延が安定しているのにダウンロード速度が低い場合は、少なくとも60秒の継続ダウンロードテストを行います。
同じ地域のノードがすべて遅い場合は、比較用に別地域のノードを1つ追加します。
1つのノードだけが遅いなら、ローカル設定を調整し続けるより、ノードを交換したほうが効果的です。

倍率は速度を意味しない

サブスクリプション画面にある「0.5倍」「1倍」「2倍」は、通常は通信量の課金倍率を示すもので、速度の倍率ではありません。2倍ノードが1倍ノードの2倍速いとは限らず、異なる回線を使っている場合もあれば、単に通信量の差し引き率が違うだけの場合もあります。速度は実測スループット、パケットロス、時間帯ごとの安定性で判断してください。

自動速度テストグループは「低遅延・低帯域」のノードを選ぶことがある

url-testプロキシグループは、テストURLへの応答結果に基づいてノードを自動選択します。テスト対象が小さなデータしか返さない場合、ハンドシェイクが速いノードが選ばれても、継続的な帯域は十分でないことがあります。切り替えが頻発しないようテスト間隔を適度に長くし、安定性が近いノードを同じグループにまとめる方法も有効です。すべての地域を1つのグループに混在させるのは避けてください。

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

interval: 300は300秒ごとにテストする設定で、tolerance: 80は遅延差が小さいときの頻繁な切り替えを抑えます。このURLは可用性と応答の確認だけを担い、完全な帯域テストには使えません。サブスクリプションから生成された設定を変更する前に、サブスクリプション更新時にローカル変更が上書きされないかも確認してください。

第2層：回線側でピーク時の混雑・パケットロス・経路変化を確認

回線の問題は、ローカルの通信事業者、ネットワーク間接続、入口サーバー、出口サーバーの間で発生します。時間帯による特徴がはっきりしていることが多く、昼は正常なのに夜20時以降に遅延が増えたり、モバイル回線は正常でも家庭の固定回線だけ遅くなったりします。この場合、クライアントの再インストールや設定の削除を繰り返しても、結果はほとんど変わりません。

時間帯と接続回線を変えて相互に検証する

比較結果	可能性が高い問題層	次の対応
同じノードが昼は150 Mbps、夜は15 Mbpsに低下する	ピーク時の混雑または夜間のノード負荷	入口・地域を変えるか、低負荷時間帯に再測定する
家庭の固定回線は遅いが、スマホのテザリングは正常	固定回線の出口またはネットワーク間経路	同じノードのまま、2種類の接続回線を比較する
すべてのノードと直結が同時に遅い	ローカル接続、Wi-Fi、通信事業者側の障害	有線でルーターに接続し、直結でテストする
アジアのノードは正常だが、遠距離ノード全体が不安定	長距離経路とパケットロス	距離の近い入口を優先する

テスト中はノードとクライアント設定を変えず、ネットワークだけを切り替えます。まず家庭のWi-Fiで測定し、次にスマホのテザリングで測定してください。テザリングで速度が12 Mbpsから90 Mbpsに戻るなら、クライアントとノードには少なくともより高いスループットを出す能力があり、家庭回線からノード入口までの経路に問題がある可能性が高くなります。

単発の低遅延より、遅延の変動に注目する

連続テストで58ms、61ms、64msとなるほうが、28ms、190ms、タイムアウトとなる場合より通常は安定しています。後者は一度だけ低い数値が出ても、ジッターとパケットロスによってTCP再送が発生し、ダウンロード速度が低下します。動画、リモートデスクトップ、ゲームはジッターの影響をさらに受けやすい傾向があります。

Windowsでは、PowerShellでノード入口のポートにTCP接続できるかを確認できます。サンプルのホストとポートは、サブスクリプションのノードで実際に使われている値に置き換えてください。

Test-NetConnection example.com -Port 443
ping example.com -n 20

macOSまたはLinuxでは、遅延を継続的に確認できます。

ping -c 20 example.com
curl -x http://127.0.0.1:7890 -o /dev/null -s -w "connect=%{time_connect} total=%{time_total}\n" https://www.gstatic.com/generate_204

例の7890は一般的な混合ポートであり、固定値ではありません。実際のポートは、クライアントの「設定」→「ポート設定」または設定ファイルのmixed-portフィールドで確認してください。コマンドが接続拒否を返す場合は、まずmihomoが実行中か、ポートが一致しているかを確認し、すぐにリモートノードの障害とは判断しないでください。

第3層：ローカル設定でDNS・ルール判定・プロキシ競合を確認

複数のノードが似た挙動を示し、ネットワークを変えても問題が続くなら、ローカル設定を確認します。よくある症状は、ウェブページの初回表示だけ遅い、特定アプリがプロキシを経由しない、ルールモードは遅いのにグローバルモードは正常、TUNを有効にすると急に速度が落ちる、といったものです。ローカル層は「接続がカーネルに取り込まれているか」「正しいプロキシグループがルールで選ばれているか」「DNSが正常に応答しているか」の順に確認します。

ノード名だけでなく、接続ログを確認する

クライアントの接続またはログ画面を開き、問題のウェブサイトへ再度アクセスします。一般的なクライアントでは、「ログ」または「接続」ページで対象ドメイン、適用されたルール、最終的なプロキシグループを確認できます。ドメインがmihomoに捕捉されたか、どのルールに一致したか、最終的にどのプロキシグループとノードが使われたかを確認してください。

接続記録に対象アプリの通信がまったくない場合は、システムプロキシまたはTUNの取り込み範囲を確認します。
対象ドメインがDIRECTに一致しているのにプロキシ経由の想定なら、ルールの順序とルールセットの更新状態を確認します。
誤った地域のプロキシグループに一致している場合は、「プロキシ」ページに戻り、グループ内で現在選択されている項目を確認します。
ログにDNSタイムアウトが続く場合は、まず名前解決の経路を確認します。
同じリクエストで接続が何度も作られている場合は、システム内に別のプロキシソフトが残っていないか確認します。

Clashのルールは上から順に照合され、最初に一致したルールが適用されます。広すぎるルールを前に置くと、後続の具体的なドメインルールが無効になります。たとえばGEOIP,CN,DIRECTは通常、ドメインルールの後、最後のMATCHの前に置きます。変更時は一度に1種類のルールだけを移動し、再読み込み後に接続ログで確認してください。

rules:
  - DOMAIN-SUFFIX,example.net,プロキシノード
  - DOMAIN-KEYWORD,stream,メディア用プロキシグループ
  - GEOIP,CN,DIRECT
  - MATCH,プロキシノード

グローバルモードで短時間比較する

ルールモードが非常に遅い場合は、同じノード・同じ対象を使って一時的にグローバルモードへ切り替えます。グローバルモードですぐ回復し、ルールモードだけ遅いなら、ノードの帯域ではなく、ルール判定、DNSの分岐、または一部リソースが別経路を通っていることが原因の可能性があります。テスト後はルールモードに戻し、ログをもとにルールを修正してください。設定の問題を隠すためにグローバルモードを常用することは推奨しません。

DNSが遅いと「最初だけ止まり、その後は速い」状態になる

ドメイン解決のタイムアウトは、最初のリクエストを遅らせます。特に、複数のnameserverで品質差が大きい場合、IPv6では名前解決できても接続できない場合、システムDNSとmihomoのDNS経路を併用している場合は、ブラウザーが失敗した接続のフォールバックを待つことがあります。設定でDNS処理を統一し、クライアントが設定を正常に読み込んでいることを確認してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

ipv6: falseは、IPv6からのフォールバック待ちが原因か検証するために使えますが、すべてのネットワークでIPv6を恒久的に無効にすべきという意味ではありません。ローカル環境とプロキシ経路がIPv6を完全にサポートしているなら、元に戻して再テストしてください。fake-ipはドメイン通信を早い段階でルール判定へ送れますが、LAN機器、一部のゲーム、実アドレスを必要とするサービスではfake-ip-filterへの追加が必要になることがあります。

システムプロキシとブラウザーのプロキシが二重になっていないか確認する

デスクトップ環境でよくある競合は、クライアントがシステムプロキシを設定している一方、ブラウザー拡張機能も別のポートへ通信を転送しているケースです。終了したはずの古いクライアントがシステムプロキシのアドレスを残している場合もあります。リクエストが2回迂回したり、ローカルで再試行を繰り返したりすることがあります。

クライアントの「設定」→「システムプロキシ」を開き、現在のスイッチ状態を確認します。
「設定」→「ポート設定」を開き、HTTP、SOCKS、mixedのポートを記録します。
ブラウザーのプロキシ拡張機能を確認し、一時的にシステムプロキシに従う設定にします。
OSのネットワークプロキシを確認し、アドレスが通常127.0.0.1で、ポートがクライアントと一致していることを確認します。
ほかのプロキシクライアントを完全に終了してから、初回表示と継続ダウンロードを再テストします。

設定がmixed-port: 7890の場合、HTTPとSOCKSのクライアントはどちらもこのポートへ接続できます。同じブラウザーのリクエストをSOCKS拡張機能に渡した後、さらにシステムのHTTPプロキシへ転送しないでください。ブラウザーだけをプロキシ経由にする場合、システムプロキシが有効なら、拡張機能は通常、直結またはシステム設定に従う状態にします。

TUNモードの確認：アプリの取り込み・MTU・UDP

TUNモードは仮想ネットワークアダプターを使い、システムプロキシに従わないアプリの通信を取り込みます。ゲームクライアント、コマンドラインツール、一部のストアアプリに適していますが、追加のルーティング、DNSハイジャック、パケット処理が発生します。「TUNを無効にすると正常で、有効にすると遅い」場合は、すべてのサブスクリプションノードを交換する前にTUN設定を確認してください。

TUN経路だけが影響を受けているかを先に確認する

ノードを1つ固定し、システムプロキシを有効、TUNを無効にした状態でブラウザーをテストします。
ノードを変えずにTUNを有効にし、同じアドレスをテストします。
接続ページを確認し、2回のテストが同じルールと同じノードに一致していることを確認します。
TUNを有効にしたときだけ速度が落ちる場合は、仮想ネットワークアダプターの競合、MTU、ネットワークスタックを確認します。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixedはmihomoでよく使われる互換性重視の選択肢です。VPN、仮想マシン、コンテナネットワーク、ゲーム用の高速化ツールを同時に実行していると、自動ルーティングが誤った出口アダプターを選ぶことがあります。まず仮想ネットワークアダプターを作成する他のソフトを終了し、クライアントを再起動してテストしてください。stack、MTU、DNSハイジャックを同時に変更すると原因を特定しにくくなります。

MTUが適切でない場合の典型的な症状

MTUの問題では、小さなウェブページは開くのに大容量ファイルで止まる、特定サイトへのアップロードだけ失敗するといった症状が出ます。まずは控えめな値から比較し、たとえばTUN設定でmtu: 1400をテストします。効果を確認してから少しずつ調整してください。適切な値はOS、回線方式、上位トンネルによって異なるため、1400はあくまで切り分けの出発点です。

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  auto-detect-interface: true

MTUの変更後に大容量ファイルのダウンロードが明らかに回復し、ノードとルールを変えていないなら、フラグメントまたはパスMTU探索が障害に関係している可能性があります。改善しない場合は元の設定に戻し、数値を下げ続けるのではなくDNSと回線を確認してください。

サブスクリプションとカーネルの状態：古い設定とバージョン不一致を切り分ける

サブスクリプションの更新に失敗しても、すべてのノードが必ずオフラインになるわけではありません。クライアントがキャッシュ済み設定を使い続け、ノードの入口、ルールセット、DNSパラメーターが長期間更新されないことがあります。確認時は「サブスクリプションの更新日時」と「現在実行中の設定」が同じ内容かを確かめてください。更新後は適用または再読み込みも必要です。ダウンロード完了だけを見て、カーネルの切り替えが済んだと判断しないでください。

サブスクリプションの更新日時と設定の読み込み結果を確認する

「サブスクリプション」または「設定」ページで最終更新日時を確認し、数週間前のキャッシュではないことを確かめます。
手動更新後に、HTTPタイムアウト、認証失敗、空の内容などが発生していないか確認します。
更新に成功したら、その設定を選択して再読み込みします。
ログページを開き、設定の解析に成功し、プロキシグループとルールセットが生成されていることを確認します。
サブスクリプションに上書き機能が含まれる場合は、ローカル上書きが現在のフィールドに適合しているか確認します。

旧Clash設定をmihomoへ移行する場合、基本的なプロキシ、プロキシグループ、ルール構造は引き続き使えることが多い一方、拡張フィールド、TUNパラメーター、ルールセットの動作はバージョンによって変わる場合があります。設定の読み込みエラーが出たら、サブスクリプション全体を削除するのではなく、まずログから問題のフィールドを特定してください。カーネルのバージョンは、クライアントの「設定」→「カーネル」または「バージョン情報」ページで確認できます。メニュー名はクライアントによって多少異なります。

10分で行う切り分け手順と結果の判断

障害が発生している最中は、次の順番で原因範囲を素早く絞り込みます。基本原則は、各ラウンドで変更する変数を1つだけにし、変更前後の結果を記録することです。

1分目：バックグラウンドのダウンロードを停止し、直結モードでローカルの基準値を1回測定します。
2〜3分目：ルールモードに戻し、テストノードを固定して、遅延、初回表示時間、60秒間のダウンロード速度を記録します。
4分目：同じ地域の別ノードへ切り替えます。元のノードだけが遅いなら、ノード側の問題と判断します。
5分目：別地域のノードへ切り替えます。プロキシノード全体が遅く、直結が正常なら、回線またはローカル設定を引き続き確認します。
6分目：スマホのテザリングで同じノードを再テストします。テザリングで回復するなら、家庭の固定回線経路を優先して確認します。
7分目：接続ログを確認し、ルール、プロキシグループ、対象ノードを照合します。
8分目：一時的にグローバルモードへ切り替えます。グローバルモードで回復するなら、ルールとDNSを重点的に確認します。
9分目：ブラウザーのプロキシ拡張機能と他のプロキシクライアントを無効にし、ローカルの二重適用をなくします。
10分目：TUNのオン・オフを比較します。TUNだけが遅い場合は、仮想ネットワークアダプター、MTU、DNSハイジャックを確認します。

最終結果	判断	対応方針
別のノードに替えるとすぐ回復する	単一ノードの負荷または入口の異常	ノードを交換し、元のノードのその後の状態を確認する
同じ地域はすべて遅いが、他地域は正常	地域の入口または該当回線の混雑	一時的に別地域を選択する
テザリングは正常だが、固定回線は遅い	接続事業者またはネットワーク間経路の問題	入口を変え、時間帯を分けて再測定する
グローバルモードは正常だが、ルールモードは遅い	ルール判定またはDNS分岐の問題	接続ログに基づいてルールを修正する
ブラウザーは正常だが、単独アプリは遅い	システムプロキシがそのアプリを対象にしていない	TUNまたはアプリ内プロキシを確認する
TUNを無効にすると回復する	TUNのルーティング、MTU、仮想ネットワークアダプターの競合	TUN設定を1項目ずつ調整する
直結もプロキシも遅い	ローカルネットワークまたは通信事業者側の接続異常	有線接続に切り替え、ルーターと回線を再確認する

トラブルシューティングで残すべき記録

サブスクリプション提供元、ネットワーク管理者、クライアントプロジェクトへ報告する場合、「速度が遅い」だけでは再現が困難です。比較できるデータを提示しつつ、サブスクリプションURL、ノードのパスワード、完全な設定ファイルは公開しないでください。テスト日、時間帯、接続ネットワーク、クライアントのバージョン、mihomoカーネルのバージョン、ノード地域、実行モード、測定結果を記録するのがおすすめです。

テスト時刻：2026-06-20 21:30
接続ネットワーク：家庭の固定回線、有線接続
実行モード：ルールモード、TUN有効
ローカル直結：286 Mbps
ノードA：遅延72ms、継続ダウンロード18 Mbps
ノードB：遅延81ms、継続ダウンロード96 Mbps
スマホのテザリング＋ノードA：74 Mbps
ルール判定：MATCH → プロキシノード
症状：夜間に低下し、昼間に回復

この記録から、ノードAは家庭の固定回線を使う夜間経路で性能が低く、ノードBとスマホのテザリングとの比較から、クライアントの基本設定が完全に機能していないわけではないと判断できます。設定を何度も消去するより、このように層別の証拠を集めたほうが、交換・調整すべき箇所を見つけやすくなります。