Clash Android版の通信速度が遅いときの原因切り分け：ノード・回線・端末設定を3段階で確認

再現可能な速度測定の基準を先に作る

Clashに「接続済み」と表示されても、Android VPNインターフェースやローカルプロキシが起動していることを示すだけで、現在のノードが安定したスループットを提供できるとは限りません。切り分けの前に測定条件を固定しましょう。Wi-Fi、モバイル回線、ノード、接続先サイトが同時に変わると、どの層で速度が落ちたのか判断しにくくなります。

4つの測定結果で問題の範囲を切り分ける

Clashを終了し、現在のWi-Fiで1回測定して、ダウンロード、アップロード、アイドル時の遅延を記録します。
同じWi-FiのままClashを起動し、現在のノードを選んでもう一度測定します。
Clashを起動したまま、別の地域、別のプロトコル、または別の回線のノードに切り替えて、もう一度測定します。
Wi-Fiを切り、4Gまたは5Gに切り替えて、現在のノードと予備ノードを測定します。

各条件で最低2回、1回あたり20〜30秒測定します。測定サーバー、時間帯、対象ファイルは統一してください。速度の単位もそろえます。100 Mbpsは約12.5 MB/sです。ブラウザーで8 MB/sと表示された場合、回線速度は約64 Mbpsに相当するため、MB/sと通信事業者のMbps表記をそのまま比較してはいけません。

測定条件	測定例	優先して確認すること
Clashを終了、Wi-Fiで測定	286 Mbps、遅延18 ms	自宅回線の基準値は正常
Clashを起動、ノードA	22 Mbps、遅延96 ms	ノードまたは中継回線に制限の可能性
Clashを起動、ノードB	173 Mbps、遅延72 ms	クライアント設定はおおむね正常、ノードAに異常
モバイル回線、ノードA	118 Mbps、遅延88 ms	自宅回線からノードAまでの経路が混雑している可能性

第1段階：ノード品質とプロキシグループの選択を確認する

同じネットワークで一部のノードだけ遅い場合、問題は通常ノード層にあります。ノードの過負荷、出口帯域の不足、プロトコルのハンドシェイク再送、サブスクリプション内の失効ノード、画面上の選択と実際に使われるノードの不一致などが主な原因です。

プロキシ画面で実際の出口を確認する

一般的なClash Meta Androidクライアントでは、「プロキシ」画面を開き、ルールから参照されているプロキシグループを展開して、選択マークの付いた実際のノードを確認できます。最上位のグループ名だけを見ないでください。たとえばルールが「ノード選択」を参照し、その内部で「自動選択」を参照している場合、最終的な出口はURL Testによって自動的に切り替わるため、手動で選んだ地域とは限りません。

「プロキシ」→現在のプロキシグループを開き、実際に選択されているノード名を記録します。
右上の速度測定ボタンをタップするか、プロキシグループの遅延テストを実行します。
地域または回線識別子が異なるノードを3つ選び、それぞれ実際のダウンロード速度を測定します。
測定中は自動切り替えを無効にし、途中で出口が変わらないようにします。
「ログ」を開き、対象ドメインが想定したルールとプロキシグループに一致していることを確認します。

遅延テストで80 ms、95 ms、110 msのように近い結果が出ても、最低値だけで選ばないでください。3回連続で測定し、あるノードが72 ms、310 ms、タイムアウトとなるなら、ジッターが大きいと判断できます。別のノードが105〜118 msで安定している場合、実際のWeb閲覧や動画視聴では後者のほうが信頼できます。

ノードの負荷と速度制限を見分ける

夜の混雑時にノードが遅くなり、深夜に回復するなら、ノードの同時接続数や上流回線の混雑が関係している可能性があります。08:00、20:00、23:30の3つの時間帯で同じノードの速度を記録してください。160 Mbpsから18 Mbpsに低下し、他のノードが120 Mbps以上を維持しているなら、Android設定を繰り返し変更するより先にノードを切り替えるべきです。

小さなファイルは正常に開くのに、大きなファイルのダウンロードだけが一定速度で止まるのも典型的な特徴です。Webページの初期表示は速いのに、ダウンロードが常に2.0 MB/s前後なら、ノード側の帯域配分、契約プランの速度制限、単一接続の制限が考えられます。異なる配信元の大きなファイルを2つ使い、さらに複数接続に対応したダウンロードも試すと、接続先サイトの制限かノード全体のスループット不足かを切り分けられます。

サブスクリプションを更新し、無効な項目を除外する

「設定」画面で現在のサブスクリプションを更新し、設定を選び直します。配信元がサーバーアドレスを変更したのに、端末がキャッシュ済みの設定を使い続けていると、旧ノードが断続的にしか接続できない、ハンドシェイクが遅い、速度が極端に低いといった状態になることがあります。更新後はプロキシグループも再確認してください。ノード名の変更により、手動選択が先頭の項目へ戻る場合があります。

第2段階：通信事業者の回線とネットワーク間の混雑を判断する

ノード自体は正常なのに、自宅Wi-Fiでは明らかに遅く、モバイル回線では回復する場合、問題は自宅の通信事業者からプロキシ入口までの間にある可能性があります。2つのノードが同じ地域にあっても、入口側の通信事業者、中継方式、復路の経路は大きく異なることがあります。

ネットワーク切り替えで入口までの経路を特定する

有効な比較方法はClashを何度も再起動することではなく、ノードを固定して接続ネットワークだけを切り替えることです。たとえばノードCが自宅回線では14 Mbps、5Gでは126 Mbpsで、Clashを終了すると両方とも約200 Mbps出る場合、端末性能やノード出口が主な制限とは考えにくく、自宅回線からノード入口までの経路を優先して確認すべきです。

Wi-Fiは遅くモバイル回線は速い：自宅回線の経路、ルーター、IPv6を確認する。
Wi-Fiもモバイル回線も遅い：ノード負荷、プロトコル、クライアント設定を確認する。
特定のWebサイトだけ遅い：ルールの一致、接続先サイトの出口制限、DNSの結果を確認する。
夜間にすべてのノードが遅い：自宅回線または上流中継の時間帯による混雑が考えられる。

DIRECTルールとプロキシルールを比較する

「ログ」画面を開き、速度の遅いWebサイトへアクセスして、接続記録のルール名と最終的なプロキシ設定を確認します。本来プロキシを通すべきドメインがDIRECTに一致すると、通信は自宅の通信事業者を直接経由します。逆に、本来直結すべき大容量ダウンロードサイトが遠いノードへ送られると、迂回と帯域消費が増えます。

たとえばルールセットがソフトウェアミラーサイトを誤ってプロキシグループに入れると、本来20 msの国内経路が「スマートフォン → 海外ノード → 中国国内のミラー」という往復経路になることがあります。この場合、ノードの速度測定は正常でも、特定サイトのダウンロードだけ遅くなります。一時的にそのドメインをDIRECTルールへ追加して再測定すれば、振り分けが原因か確認できます。

rules:
  - DOMAIN-SUFFIX,example-download.com,DIRECT
  - DOMAIN-SUFFIX,example-video.com,PROXY
  - MATCH,ノード選択

ルールを変更するときは、クライアントのオーバーライド機能または独立したルールプロバイダーを優先して使い、サブスクリプション更新のたびにローカル変更が消えないようにします。テスト後はログを確認し、ドメインが本当に新しいルールに一致したことを確認してください。前にある優先度の高いルールに先に処理されていないかも確認します。

IPv4とIPv6の経路差を確認する

一部のネットワークではIPv6の直接接続が非常に速い一方、プロキシノードはIPv4しか安定して対応していないことがあります。また、DNSがAAAAレコードを返すとIPv6接続がタイムアウトしてからIPv4へフォールバックする場合もあります。Webページの読み込み開始前に2〜5秒止まり、読み込み開始後のダウンロード速度は正常という症状が典型です。

クライアントの「設定」→「ネットワーク」または「設定」→「DNS」でIPv6のスイッチを確認し、一時的に無効にして再測定します。クライアントのバージョンによってメニュー名は多少異なりますが、DNS解決とmihomoカーネルのIPv6対応状況を一致させることが重要です。無効化後に最初の応答が改善した場合は、ルーターのIPv6プレフィックス、DNSの応答、ノードのプロトコル対応を確認してください。何度も再接続して使い続ける必要はありません。

第3段階：Androidの端末設定を確認する

複数のノードで、Wi-Fiでもモバイル回線でも似た低速結果になる場合は、端末側を確認します。Androidの省電力設定、VPNの競合、TUNパラメータ、DNS、MTU、その他のネットワークツールがmihomoカーネルの通信に影響することがあります。

バックグラウンド制限と省電力制限を解除する

Androidの「設定」→「アプリ」→現在のClashクライアント→「バッテリー」を開き、バックグラウンド実行を許可するか「制限なし」を選びます。続いて「モバイルデータとWi-Fi」でバックグラウンドデータが利用可能か確認します。メーカーによっては「設定」→「バッテリー」→「アプリのバッテリー使用量を管理」などの経路になります。省電力モードはバックグラウンドのCPUとネットワーク活動を制限し、画面ロック後に特に影響が出ます。

テスト中は5分間画面を点灯し、その後5分間ロックして、同じ継続ダウンロードを比較します。点灯中が90 Mbpsで、ロック後に6 Mbpsまで低下し、再び点灯すると回復するなら、バックグラウンド制御が速度制限に関与していると判断できます。

VPNとネットワークツールの競合を除外する

Androidでは通常、同じユーザー環境で有効にできるシステムVPNインターフェースは1つです。広告ブロッカー、企業VPN、プライベートDNSツール、他のプロキシクライアントがClashとインターフェースを奪い合うことがあります。システムの「設定」→「ネットワークとインターネット」→「VPN」を開き、現在の接続が対象クライアントだけになっていること、常時接続の別VPNが有効になっていないことを確認します。

プライベートDNSそのものがスループットを必ず低下させるわけではありませんが、DNSサーバーに到達できないとドメイン解決の待ち時間が発生します。「設定」→「ネットワークとインターネット」→「プライベートDNS」を開き、一時的に「自動」へ切り替えて、Webページを最初に開くまでの時間を測定します。ダウンロード速度が変わらず、ページの待ち時間だけが4秒から1秒未満になったなら、問題はノード帯域ではなくDNSにあります。

システムプロキシとTUNモードを比較する

システムプロキシモードは、Androidのプロキシ設定に従うアプリだけを処理します。一部のゲーム、QUIC通信、独自のネットワークスタックを使うアプリは迂回することがあります。TUNモードはAndroid VPNインターフェースを通じてより広範な通信を処理しますが、仮想ネットワークカードの処理が1層増えます。切り分けではノード、DNS、TUNを同時に変えず、1つの変数だけを切り替えてください。

「設定」→「ネットワーク」または「設定」→「TUN」で現在の状態を記録します。
同じノードを使い、通常のVPN経由で30秒間測定します。
TUNを有効にしてAndroid VPNを再認証し、同じ条件で測定します。
ダウンロード速度、アップロード速度、遅延、対象アプリが正しくプロキシ経由になっているかを比較します。

通常モードが140 MbpsでTUNモードだけ38 Mbpsなら、MTU、プロトコルスタック、DNSハイジャックを確認してください。すぐにノード障害と判断するべきではありません。逆に、ブラウザーは正常なのに特定のアプリだけプロキシを通らない場合、TUNモードが解決するのは経路の対象範囲であり、回線速度ではない可能性があります。

MTUを調整してフラグメント問題に対処する

MTUが合っていないとパケットが分割または破棄され、小さなWebページは正常なのに画像や動画が止まる、アップロード速度だけ極端に低いといった症状が出ます。TUNで一般的なMTUは1500から試し、モバイル回線、追加トンネル、一部のブロードバンド環境では1480、1420、1400の順に測定します。毎回1つの値だけを変更し、カーネルを完全に停止してから再起動してください。

MTUが1500のときアップロードが0.8 Mbpsしかなく、1400に変更すると18 Mbpsで安定し、ダウンロードの変化が小さいなら、安定する値を採用できます。MTUを下げすぎるとヘッダーのオーバーヘッドが増えるため、いきなり極端に小さくせず、20〜40バイト刻みで特定してください。

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  strict-route: false

設定フィールドが利用できるかどうかは、クライアントに組み込まれたmihomoカーネルのバージョンによって決まります。オーバーライドを使う前に、「概要」または「設定」→「カーネル」でバージョンを記録します。たとえばクライアント2.11.15、mihomo 1.19.12です。変更後はログにunknown field、parse error、TUN create failedが出ていないか確認してください。

DNSの遅さと実際の帯域低下を分けて考える

DNSの問題は「通信速度が遅い」と表現されがちですが、主に接続開始前の名前解決に影響します。URLを入力して数秒待たされる一方、ページの読み込みが始まると速い、すでに接続済みの動画ストリーミングや大容量ファイルのダウンロードはおおむね正常というのが典型です。

最初の応答までの待ち時間と継続的なダウンロードを観察する

新しいドメインを初回だけ開くのが遅く、更新すると速い：DNSキャッシュと上流の名前解決を優先して確認する。
ドメイン解決は速いのに大容量ファイルだけ常に遅い：ノードと回線のスループットを優先して確認する。
一部のドメインが誤ったアドレスを返す：fake-ip、ルールセット、DNSの振り分けを確認する。
TUNを有効にしたときだけ名前解決がタイムアウトする：DNSハイジャックとポートの競合を確認する。

mihomo設定でよく使われるローカル混合プロキシポートは7890、SOCKSポートは7891、DNSの待ち受けポートは1053です。これらの番号は固定ではありませんが、同じポートを2つのサービスが同時に使用することはできません。ログにaddress already in useが出る場合は、他のプロキシ、DNSフォワーダー、古いカーネルプロセスを確認してください。

mixed-port: 7890

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

上記のアドレスは設定構造を説明するための例です。実際に上流DNSを選ぶときは、利用中のネットワークから到達できるか、プロキシ経由で問い合わせる必要があるかを考慮します。DNSリクエスト自体が不安定なノードへ送られるルールになっていると、ノードの混雑に応じて解決時間も長くなります。

プロトコル、カーネル、端末性能を確認する

古い端末や省電力性能の端末では、高スループットの暗号化、ルール照合、TUN転送がCPUを大きく消費することがあります。測定中はシステムのバッテリー画面やパフォーマンスモニターを確認してください。1つのコアが長時間ほぼフル稼働し、速度が一定値で頭打ちになり、端末が発熱しているなら、端末の処理能力が制限要因の可能性があります。

地域だけでなくプロトコルを比較する

同じサービスのノードでも、使用する通信プロトコルが異なる場合があります。測定では入口地域と回線レベルが近く、プロトコルだけが異なるノードを選ぶと、変数を減らせます。現在のモバイル回線で一方のプロトコルだけ頻繁にパケットロスが発生し、もう一方が安定するなら、遅延の数値だけで無理に選ばず、現在のネットワークに適したノードを使ってください。

UDPとQUICも個別に確認する必要があります。WebページがTCPで正常でも、ゲームやHTTP/3が正常とは限りません。ブラウザーのQUICを一時的に無効にするか、対象ドメインを別のノードへ振り分けて比較します。QUICを無効にすると動画の再生開始が改善するのに通常のダウンロードは変わらない場合、ノードのUDP対応と通信事業者のUDP品質を確認してください。

カーネルを更新する前に測定記録を残す

クライアントとmihomoカーネルのバージョンは、プロトコル実装、TUNスタック、DNSの動作に影響します。更新前にAndroidのバージョン、クライアントのバージョン、カーネルのバージョン、現在の設定を更新した日時の4項目を記録します。更新後は同じノードと測定条件で再測定し、変化がソフトウェアによるものかネットワークの時間帯によるものか判断できるようにします。

更新直後に全体的な速度低下が起きた場合は、「ログ」で設定の互換性エラーを確認し、一時的にカスタムオーバーライドを無効にします。古い設定の廃止フィールドは無視されることもあれば、特定のモジュールが想定どおり起動しない原因になることもあります。基本のサブスクリプション設定に戻して速度が正常になったら、DNS、TUN、ルールのオーバーライドを1つずつ戻すことで、競合するフィールドをすばやく特定できます。

測定結果に応じた最終的な確認手順

すべての設定を一度に変更する必要はありません。「ノード → 回線 → 端末」の順に、各段階で1つの変数だけを変えれば、通常15〜30分で問題の範囲を絞り込めます。

直接接続の基準を記録：Clashを終了し、Wi-Fiとモバイル回線でそれぞれ2回測定します。
実際のノードを確認：「プロキシ」を開き、ルールが実際に参照しているプロキシグループと選択中のノードを確認します。
ノードを比較：少なくとも3つの入口を測定し、遅延、ダウンロード、アップロード、測定時間帯を記録します。
サブスクリプションを更新：「設定」を開いて現在のサブスクリプションを更新し、プロキシグループの選択を再確認します。
接続ネットワークを切り替え：ノードを固定したまま、Wi-Fiと4G、5Gを比較します。
ルールログを確認：速度の遅い接続先が想定したDIRECTまたはプロキシ設定に一致していることを確認します。
Androidの制限を確認：バックグラウンドのバッテリー制限を解除し、他のVPNやネットワークツールを停止します。
DNSとスループットを区別：最初の応答までの待ち時間と継続的なダウンロードを比較し、名前解決の遅さを帯域不足と取り違えないようにします。
TUNを比較：同じ条件でモードを切り替え、必要に応じてMTU 1500、1480、1420、1400を測定します。
バージョンとオーバーライドを確認：クライアントとmihomoのバージョンを記録し、カスタム設定を無効にして再測定します。

最終的な判断は3種類にまとめられます。特定のノードだけ遅いならノード品質を確認します。同じノードでもネットワークによって差が大きいなら、通信事業者の経路とルーターを重点的に確認します。すべてのノードとネットワークで遅いなら、Androidのバックグラウンド制限、TUN、DNS、MTU、カーネルのバージョン、端末性能を確認します。測定表を残しておくほうが、再接続を繰り返すより効果的で、サブスクリプションやネットワーク環境が変わった後の再確認にも役立ちます。