まず「遅い」を測定可能な問題に分解する
Clashの画面に表示される遅延、Webページの表示時間、ファイルのダウンロード速度は同じ指標ではありません。遅延テストは通常、小さなHTTPリソースを1つリクエストして接続確立から応答までの時間を確認します。一方、ダウンロード速度は接続先サーバーの帯域、国際回線、TCPの輻輳制御、プロトコルのオーバーヘッド、ローカルの無線ネットワークにも左右されます。あるノードが68 msでも帯域を使い切れるとは限らず、145 msでも動画が必ず止まるとは限りません。
切り分ける前に、条件を固定しましょう。ノードを切り替えながらDNSを変更したり、同時にTUNを有効にしたりして、1回の測定だけで結論を出してはいけません。現在のネットワーク、プロキシモード、ノード名、測定時刻を記録し、「直通の基準値—単一ノードの遅延—単一接続のダウンロード—複数接続のダウンロード」の順に測定するのがおすすめです。各項目は最低3回測定し、最大値ではなく中央値を確認します。
再現可能な基準値を作る
- ClashのシステムプロキシとTUNモードを停止し、同じ端末で直通のネットワークを測定します。500 Mbpsの回線で直通でも35 Mbpsしか出ない場合は、まずWi-Fi、LANケーブル、または回線事業者側のネットワークを確認してください。
- Clashを再び有効にし、「ルール」モードを選択してノードを1つに固定します。メンバーを自動切り替えするプロキシグループは使わないでください。
- クラウドストレージの同期、システム更新、ゲームプラットフォームのダウンロード、ブラウザのバックグラウンド動画を停止し、帯域の消費を避けます。
- 09:00、20:00、23:00にそれぞれ測定します。夜間のピーク時だけ大きく低下するなら、クライアント設定の誤りよりも回線混雑の可能性が高いでしょう。
- 遅延、ダウンロード速度、アップロード速度、パケットロスの状況、接続先を記録します。同じ測定対象で取得したデータだけを比較してください。
| 測定項目 | 測定例 | 主な判断材料 |
|---|---|---|
| 直通ダウンロード | 468 Mbps | ローカル回線への接続が正常か |
| ノードの遅延 | 82 / 86 / 80 ms | 接続の安定性と基本的な往復時間 |
| プロキシ経由・単一接続のダウンロード | 6.8 MB/s | 単一接続での回線品質 |
| プロキシ経由・複数接続のダウンロード | 22.4 MB/s | ノードの総帯域と同時接続性能 |
第1段階：ノード品質とプロトコルのオーバーヘッドを確認する
基準値を取ったら、まず交換しやすいノード層を確認します。サブスクリプションに表示された地域名は単なるラベルであり、「香港01」や「日本02」だけでは入口の場所、出口の通信事業者、ピーク時の容量は分かりません。重要なのは、連続測定の結果、時間帯ごとの挙動、そして対象サイトへアクセスする際に実際に通る経路です。
遅延は最低値ではなく安定性を見る
クライアントのプロキシまたはプロキシグループ画面で遅延を測定する場合は、3〜5回連続で測定します。結果が75、79、81 msのノードは、42、180、タイムアウト、96 msとなるノードより安定していることが多いでしょう。後者は42 msを記録することがあっても、実際の利用中に再送や通信切断が頻発する可能性があります。測定URLも結果に影響するため、比較中はクライアントの既定アドレスを使うか、小さなファイルを安定して返すHTTPSアドレスに固定し、何度も変更しないでください。
- 80 ms未満：通常はWeb閲覧、メッセージング、遅延に敏感な操作に適していますが、帯域は別途確認が必要です。
- 80〜180 ms：国際接続でよくある範囲です。動画やダウンロードが快適かどうかは、主に回線の安定性で決まります。
- 250 ms超：Webページの最初の応答、リモートターミナル、リアルタイム操作で遅さを感じやすくなります。
- タイムアウトが頻発：単に「遅延が高い」のではなく、ノードまたは測定対象に到達できない、あるいは経路が不安定な状態として優先的に確認します。
倍率は通信量の計算に影響するが、速度を直接示すものではない
ノード名にある「0.5×」「1×」「2×」は、通常サブスクリプションの通信量計算倍率を示します。1 GBをダウンロードすると、2×ノードでは2 GBとして計上される場合がありますが、倍率が高いからといって速度が速いとは限りません。高倍率ノードが高価な回線を割り当てられていることもあれば、単なるリソース分けを示しているだけの場合もあります。最終的には、同じ時間帯・同じ対象への実測結果で判断してください。
プロトコルと暗号化はCPUを消費する
現代的なデスクトップCPUでは、一般的なプロキシプロトコルの処理負荷が最初のボトルネックになることは多くありません。ただし、旧型ルーター、低消費電力の小型PC、エントリークラスのAndroid端末では、高速通信時に1コアが飽和することがあります。測定中にシステムのタスクマネージャーやアクティビティモニタを開き、mihomo、Clash、またはクライアントのコアが1コア分の上限近くで張り付き、速度も伸びない場合は、端末性能、プロトコル設定、暗号化の負荷を確認してください。
- 重複して起動しているプロキシコアを停止し、システム上で現在のクライアントだけがプロキシポートを待ち受けていることを確認します。
- デスクトップでは、現在のクライアントが対応する安定版のmihomoコアを優先し、出所の不明な古いコアファイルを混在させないでください。
- ルーター上で動かしている場合は、同じサブスクリプションをデスクトップ版にも読み込んで再測定します。デスクトップは速くルーターだけ遅いなら、ボトルネックは通常、ルーターのCPU、メモリ、またはネットワークインターフェースにあります。
- 速度測定のために、サブスクリプションで配布されたプロトコル項目を不用意に変更しないでください。トランスポート層、サーバー名、Realityパラメータなどはサーバー側と一致している必要があります。
第2段階：入口・出口とピーク時の回線混雑を確認する
ノードが利用できても、現在の通信事業者からノード入口までの経路が常に快適とは限りません。家庭の回線からプロキシ入口まで、入口から出口まで、出口から対象サイトまでの3区間は別々の経路です。どこか1区間が混雑すると、遅延は正常なのにダウンロードだけ遅い、または昼間は正常なのに夜だけ明らかに遅い、といった症状になります。
時間帯と接続回線を組み合わせて混雑箇所を特定する
最も効果的なのは、数十個のノードを次々に切り替えることではなく、小規模な比較テストを行うことです。同じ地域のノードを2つ、異なる地域のノードを2つ選び、固定した測定対象で結果を記録します。その後、PCを家庭のWi-Fiからスマートフォンのテザリングに切り替え、同じノードを再測定します。家庭回線では3 MB/s、テザリングでは14 MB/sなら、問題はローカルの通信事業者から入口までの経路にある可能性が高いでしょう。どちらの接続でも遅い場合は、ノード容量や出口品質を引き続き確認します。
| 症状 | 可能性の高い原因 | 次の対応 |
|---|---|---|
| 昼間は18 MB/s、夜間は2 MB/s | ピーク時の回線またはノード容量の混雑 | 入口の異なる回線に切り替えるか、時間をずらして再測定 |
| 遅延は安定しているが、単一接続は遅く複数接続は速い | 単一接続の帯域制限または国際区間のパケットロス | 経路を変更し、実際のアプリでも確認する |
| すべてのノードが同時に遅くなる | ローカルネットワーク、サブスクリプションの入口、または上流側の障害 | 直通接続とスマートフォンのテザリングを測定する |
| 特定の接続先サイトだけ遅い | 対象サイト側の出口、ルール振り分け、またはCDN経路 | ルールのマッチ結果と出口地域を確認する |
地域間の距離だけで決めない
物理的な距離が近いほど遅延を下げやすいものの、回線品質によって結果は変わります。上海のユーザーが香港ノードに接続しても、東京ノードより常に速いとは限りません。東京への経路が通信事業者間の接続に優れていれば、ピーク時の性能が上回ることもあります。地域を選ぶ際は、対象サービスのCDN振り分けやアクセス制限も考慮しましょう。ソフトウェアリポジトリのダウンロード、動画視聴、リモートワークで最適なノードは異なる場合があるため、すべての通信を1つのノードに集中させず、用途ごとにプロキシグループを分ける方法も有効です。
第3段階：ルール振り分け、プロキシポート、TUNモードを確認する
ノードと回線に明らかな異常がなければ、ローカル設定を確認します。よくある原因はプロキシコアによる「速度制限」ではなく、対象の通信が想定したプロキシグループを通っていない、アプリがシステムプロキシを迂回している、複数のプロキシアプリが設定を上書きしている、またはTUNとセキュリティソフトが同時にパケットを処理していることです。
まず接続履歴でルールのマッチ結果を見る
クライアントの「接続」または「ログ」画面を開き、速度に問題のあるWebサイトへアクセスして、ドメイン、ルール名、最終的なポリシーを確認します。クライアントによってメニュー名は多少異なりますが、一般的には「接続」→リクエストを選択→「ルール」と「プロキシチェーン」を確認、または「ログ」→レベルをInfoに変更→再度リクエストします。対象サイトがDIRECTにマッチしているなら、プロキシを経由していません。自動プロキシグループにマッチしている場合は、そのグループが現在どのノードを選択しているかも確認します。
Clashのルールは上から下へ順番に照合され、最初にマッチしたルールが適用されます。範囲が広すぎるルールを前に置くと、後続の詳細なルールが上書きされることがあります。たとえば、LAN向けルールや中国本土向けルールをプロキシルールより前に置くのは一般的に合理的ですが、カスタムのDOMAIN-SUFFIXの位置を誤ると、対象ドメインが意図しないポリシーに振り分けられます。
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- DOMAIN-KEYWORD,example,Proxy
- GEOIP,CN,DIRECT
- MATCH,Proxyルールを変更したら設定を再読み込みし、接続画面で既存の接続を閉じてから再測定します。既存のTCP接続は、ポリシーを変更しても通常、新しいノードへ自動移行しません。ブラウザの長時間接続、HTTP/2、HTTP/3によって古い経路が残ることもあるため、必要に応じてブラウザを完全に終了して再起動してください。
ポートが二重転送されていないか確認する
一般的なローカルポートには、HTTPプロキシの7890、SOCKS5プロキシの7891、両者を統合するmixed-port: 7890があります。実際のポートは現在の設定に従ってください。ブラウザ拡張機能、ダウンロードツール、ターミナルの環境変数は、現在待ち受けているポートを指定します。「アプリが古いクライアントを経由し、古いクライアントが新しいクライアントへ転送する」ような多重プロキシを避けてください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infoクライアントでは「設定」→「パラメータ設定」から、混合ポート、システムプロキシ、LAN接続の項目を探せます。画面の構成が異なる場合は、現在の設定にあるmixed-portを直接確認してください。他の端末から接続する必要がある場合だけLAN接続を有効にし、OSのファイアウォール設定と待ち受けアドレスが一致していることを確認します。
TUNモードは、より多くの通信を取り込む必要がある場合だけ有効にする
システムプロキシは、OSのプロキシ設定に従うアプリに主に影響します。ゲーム、コマンドラインプログラム、独自のネットワークスタックを持つソフトウェアの一部はこれを迂回します。TUNモードは仮想ネットワークインターフェースを通じて、より多くの通信を取り込めます。「ブラウザは正常だが、他のアプリは直通になる」という問題の解決に役立ちますが、ノードの速度を本質的に高める機能ではありません。ドライバーの競合、誤ったルーティング、不適切なMTU、二重の取り込みによって、逆にスループットが低下することもあります。
- まずTUNを無効にしてシステムプロキシだけを有効にして測定し、その後システムプロキシを無効にしてTUNだけを有効にして再測定します。2つの経路を同時に使って原因を分かりにくくしないでください。
- TUNを有効にしてからWebページは正常でも大容量ファイルの通信が止まる場合は、MTUを確認します。一般的な検証範囲は1280〜1500ですが、接続環境に応じて段階的に調整し、他人の設定をそのまま流用しないでください。
- 他のVPN、ネットワーク高速化ツール、パケットキャプチャツール、仮想NICソフトウェアを一時的に終了し、ルーティング優先度の競合を切り分けます。
- TUN設定を変更したらコアを再起動し、システムのルーティングテーブルとDNSハイジャック機能がクライアントの案内どおり有効になっていることを確認します。
DNS設定：名前解決の遅延、汚染、誤った振り分けを解消する
DNSは通常、大容量ファイル転送の継続速度を決めませんが、最初のページ表示時間、CDNアドレスの選択、ドメインベースのルール振り分けには影響します。典型的な症状は、初回のWebサイト表示だけ数秒待たされて更新後に速くなる、同じノードでドメインへのアクセスだけ遅く既知のIPアドレスへ直接アクセスすると正常、接続履歴にIPアドレスしか表示されずドメインルールがマッチしない、といったものです。
システムDNSとプロキシDNSの競合を避ける
mihomoコアを使う場合、DNS設定にはnameserver、proxy-server-nameserver、fallback、fake-ipなどが含まれることがあります。nameserverは通常の名前解決に使われ、プロキシサーバーのドメイン自体は、利用可能なリゾルバーで先に解決する必要があります。この処理をまだ確立していないプロキシに依存すると、名前解決のループが発生する可能性があります。サブスクリプションに完全なDNS設定が含まれている場合は、公共DNSを大量に追加するのではなく、まず元の設定が機能するか確認してください。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
proxy-server-nameserver:
- 223.5.5.5この設定は構成例であり、すべてのサブスクリプションを直接置き換えるものではありません。IPv6に対応したネットワークでも、プロキシノードやルールがIPv6を正しく処理できないと、アプリが利用できないアドレスを優先してタイムアウトを待つことがあります。切り分けでは一時的にipv6: falseを設定して比較できます。原因を確認したら、実際のネットワーク環境に応じて戻すか判断し、試行錯誤用のスイッチに長期依存しないでください。
Fake-IPモードでは除外項目を確認する
fake-ipはドメインに予約済みアドレスを返し、接続時にコアがドメイン名へ戻すことで、ルールのマッチ精度を高めます。LAN機器の検出、プリンター、一部ゲームのログイン、実際のDNS応答を必要とするアプリでは、除外リストへの追加が必要になる場合があります。特定のアプリだけ起動が遅いなら、まずログでDNS問い合わせの繰り返し、接続リトライ、LANドメインのプロキシ経由を確認し、必要なドメインだけを除外してください。トップレベルドメイン全体を除外するのは避けます。
ローカル端末とネットワーク：Wi-Fi、ブラウザ、バックグラウンド処理を切り分ける
すべてのノードで直通の基準値に届かない場合は、端末側に戻って確認します。混雑した環境の2.4 GHz Wi-Fiは、安定したスループットが数十Mbpsにとどまることがあります。電波強度の表示が最大でも、干渉が少ないとは限りません。可能ならLANケーブル、または5 GHz・6 GHz Wi-Fiで比較し、端末をルーターの近くへ移動します。LANケーブルで460 Mbps、元の場所のWi-Fiで72 Mbpsなら、ノードを交換しても問題は解決しません。
システムモニターでボトルネックの位置を確認する
- CPU：プロキシコアの1コアが継続的に飽和し、CPU使用率に合わせて速度が頭打ちになる場合は、端末性能とプロトコル処理を優先的に確認します。
- メモリ：システムで頻繁にスワップが発生すると、ブラウザ、ダウンロードツール、プロキシコアのすべてで一時停止が起こります。
- ディスク：HDD、暗号化コンテナ、リアルタイム同期フォルダへダウンロードしている場合、書き込み速度がボトルネックになることがあります。
- バックグラウンド通信：OSの更新、写真のバックアップ、ゲームプラットフォームが上り帯域を使い切ると、ダウンロードの確認パケットやWeb応答も遅くなります。
- ブラウザ拡張機能：プロキシ拡張機能が別のルールやポートを設定していると、システムプロキシを上書きすることがあります。新しいブラウザプロファイルで比較テストを行ってください。
速度測定時は、ブラウザの並列ダウンロード実験機能やサードパーティ製ダウンロード拡張機能も無効にし、まず既定設定で基準値を取ります。1つのブラウザだけ遅く、システムのダウンロードツールや他のブラウザが正常なら、原因は通常、拡張機能、キャッシュ、HTTP/3、ブラウザ側のプロキシ上書きにあり、Clashコアではありません。
症状別・10分で行うトラブルシューティング手順
- 1分目：システムプロキシとTUNを無効にして直通速度を測定し、ローカル回線の基準値を確認します。
- 2分目：他のVPN、プロキシクライアント、ネットワーク高速化ツールを終了し、Clashクライアントを1つだけ残します。
- 3分目：ルールモードを有効にしてノードを1つに固定し、遅延を3回連続で測定して変動を記録します。
- 4分目：同じ対象で単一接続と複数接続のダウンロードを測定し、遅延の問題とスループットの問題を切り分けます。
- 5分目：別の地域、別の入口にあるノードで再測定します。同じグループ内の隣り合った番号へ替えるだけでは不十分です。
- 6分目：接続履歴を開き、対象ドメインにマッチしたルール、プロキシグループ、実際のノードを確認します。
- 7分目：アプリのプロキシポートと
mixed-portを確認し、古いクライアントに残ったプロキシ設定を削除します。 - 8分目：システムプロキシとTUNを別々に測定し、TUN経由の場合だけ遅くなるか確認します。
- 9分目：DNSログ、IPv6、Fake-IPの除外項目を確認し、初回接続が長時間待たされていないか調べます。
- 10分目：スマートフォンのテザリングまたは有線ネットワークに切り替えて再測定し、接続回線を変えて通信事業者の経路とWi-Fiの問題を判断します。
最終的な記録には、少なくとも測定日、時刻、接続ネットワーク、クライアントコア、プロキシモード、ノード、遅延、ダウンロード速度、ルールのマッチ結果を含めます。昼間は安定して夜間に低下するなら回線を優先し、すべてのノードが遅いならローカルネットワークと設定を優先します。特定のアプリだけ遅い場合は、そのアプリのプロキシ方式、DNS、接続プロトコルを確認してください。3段階の順序で比較データを残すほうが、サブスクリプションを何度も更新したり、ノードを無作為に切り替えたりするより、本当のボトルネックを見つけやすくなります。