Clashの速度が遅いときの対処法

まず確認：表示が遅い、ダウンロードが遅い、接続が切れる？

FlClashはClash Meta（mihomo）コアでプロキシ接続を処理します。Webページへのアクセスには、DNS名前解決、ルール判定、ノードへの接続、接続先からの応答、データ転送など複数の段階があります。どこか一つでも遅ければ「Clashの通信速度が遅い」と感じますが、原因によって対処法は異なります。設定を変える前に症状を記録しておけば、回線の問題をDNSの問題と取り違えずに済みます。

まず、クラウドストレージの同期、システム更新、ほかのダウンロードを一時停止します。端末・ネットワーク・対象ファイルを固定し、同じ条件で測定してください。家庭向け回線の速度は通常Mbps、ダウンロードツールの表示はMB/sです。100 Mbpsは理論上約12.5 MB/sに相当しますが、実際の転送速度はプロトコルのオーバーヘッド、Wi-Fiの電波状況、接続先の制限にも左右されるため、表示された数値をそのまま比較することはできません。

ノードの切り分け：選択先を固定して同じ接続先で比較

遅延測定の値が小さくても、ダウンロードが速いとは限りません。クライアントの遅延テストは通常、指定されたアドレスへの1回のリクエスト時間を測定します。テスト先やキャッシュ、接続確立の処理に左右されるため、継続的な通信速度を直接示すものではありません。遅延が60 msのノードが混雑している一方、160 msのノードのほうがダウンロード速度を維持できることもあります。

A → B → Aの順に測定

1. プロキシグループを開き、一時的にノードAを手動で選択します。自動選択やフォールバックのグループを使っている場合は、測定中に接続先が自動で切り替わらないことを確認してください。
2. 同じ接続先にアクセスし、テストが許可されている同じファイルをダウンロードします。各回約30秒観察し、開始までの待ち時間と速度が安定した後の値をそれぞれ記録します。
3. ノードBに切り替え、テストページを閉じるかダウンロードを停止してから接続し直し、同じ測定を行います。最後にAへ戻し、最初の低速が一時的なものではなかったか確認します。
4. FlClashの接続ログで、ドメイン・ルール・出站経路を確認します。既存の長時間接続は元のノードを使い続ける場合があり、プロキシグループを切り替えてもすべての接続がすぐに移行するわけではありません。

たとえば、ログ上でAが2回とも約1.2 MB/s、Bが8 MB/sだった場合、まず言えるのは「この接続先・時間帯ではBの経路のほうが良好」ということだけです。これらは例示であり、当サイトでの実測値ではありません。Aから接続先までの経路が遠回りしている、接続先が出口IPごとに速度を制限している、ノードの帯域を共有しているなど、さまざまな原因で同じ結果になります。別の接続先でも確認してください。

ルールモードでは、同じWebページでもメインのHTML、画像、動画が別々のプロキシグループを通ることがあります。画面右上で選択されているノードだけを見て判断しないでください。一時的にグローバルモードとルールモードを比較する場合は、グローバルモードのプロキシグループで同じノードが実際に選択されていることを確認します。グローバルモードでは正常でルールモードだけ遅い場合は、遅いリクエストがDIRECT、別のノード、または適切でないルール順序で処理されていないか確認してください。ルールの詳しい仕組みは高度な設定のルール解説を参照してください。

回線の切り分け：時間帯・ネットワーク・接続先を比較

複数のノードが同時に遅くても、端末の設定ミスとは限りません。複数のノードが同じ入口・出口・上位回線を共有していることもあります。名前が異なっていても、ネットワーク経路が別とは限りません。原因を絞るには、別のネットワークや時間帯でも確認してください。

• 時間帯を比較：同じノードと接続先を使い、10:00、20:00、23:00にそれぞれ測定します。夜だけ速度が継続的に低下する場合は、2～3日記録を続け、混雑する時間帯があるか確認してください。
• 接続回線を比較：同じPCを家庭のWi-Fiからスマートフォンのテザリングに切り替えて測定します。通信量に注意し、短時間のテストにとどめてください。テザリングでは回復し、固定回線では低速が続く場合、ルーターや回線接続、関連するネットワーク経路を優先して確認します。
• 接続先を比較：異なる2つ以上のWebサイトから、利用が許可されているファイルをダウンロードして測定します。特定のサイトだけ遅い場合、そのサイトのCDNによる配信先の選択、アカウントの速度制限、出口IPなどが関係している可能性があります。
• LAN内を比較：可能であれば有線LANに切り替えるか、ルーターの近くで測定します。直接接続でもプロキシ経由でも遅い場合は、まずWi-Fiの干渉やローカルネットワークの帯域使用状況を確認してください。

Pingのパケットロスはあくまで手がかりです。ルーターがICMPを制限している場合があり、途中のホップが応答しなくても、実際の通信が途切れているとは限りません。プロキシプロトコル、UDP転送、通常のPingでは経路が異なることもあります。特定のホップがタイムアウトしただけで設定全体を変更せず、実際のダウンロードが止まるか、接続ログに再試行があるかを確認してください。

端末の切り分け：システムプロキシと他のネットワークツール

システムプロキシの影響を受けるのは、通常、その設定を参照するアプリだけであり、すべての通信がプロキシ経由になるわけではありません。一方、TUNモードは仮想ネットワークアダプターとルーティングを使い、条件に合うIP通信を処理します。ブラウザーでアクセスできても、ゲームやコマンドラインがプロキシ経由とは限りません。逆に、ターミナルのプロキシ環境変数によって、リクエストが以前使っていたクライアントのポートへ送られることもあります。

まず、経路を確認できる状態にする

1. ほかのプロキシクライアントと、不要なVPNを一時停止し、変更前の状態を記録します。組織管理の端末では、必要なセキュリティ機能を独断で無効にせず、先に管理ポリシーを確認してください。
2. FlClashで現在有効な設定の待ち受けポートを確認してください。サンプルのポート番号が固定の初期値とは限りません。ブラウザー拡張機能で別のプロキシが指定されていないかも確認します。
3. Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」でシステムプロキシを確認できます。macOSでは「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」を確認してください。OSのバージョンによって項目名が多少異なる場合があります。
4. TUNを無効にし、システムプロキシだけを有効にして、システムプロキシに対応したブラウザーで再測定します。次にシステムプロキシを無効にしてTUNだけをテストし、2つの経路を同時に変更しないようにしてください。

本機のHTTPまたはmixed待ち受けポートが実際に7890の場合を例にすると、次のコマンドで今回のリクエストがその経路を使うよう指定できます。Windows PowerShellではcurl.exe、macOSとLinuxでは通常curlを使います。ポートが異なる場合は、先にコマンドを変更してください。接続先アドレスはリクエストの各段階を確認するためのもので、通信速度の測定用ではありません。

curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --write-out "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Windowsで実行する場合は、/dev/nullをNULに変更してください。ローカルHTTPプロキシ経由でHTTPSに接続する場合、time_connectが示すのは主にローカルのプロキシ入口への接続時間であり、リモートノードへの遅延ではありません。最初の1バイトまでの時間には、プロキシトンネルの確立、TLS、接続先の応答など複数の段階が含まれます。このコマンドは変更前後の比較に使うもので、単一の数値だけからDNS障害と断定することはできません。

TUNの切り分け：経路の取り込みとリソースを確認してからスタックを変更

システムプロキシでは正常で、TUNモードだけ明らかに遅い場合は、仮想ネットワークアダプターが正しく作成されていることと、カーネルに必要な権限があることを確認します。権限やサービスの仕組みはWindows、macOS、Linuxで異なります。AndroidではシステムのVPN権限を使うため、通常、同じユーザー領域で別のVPNを同時に使用できません。

次の順に確認してください

• 接続状況を確認：アプリからリクエストを送信した後、FlClashに該当する接続が表示されるか確認します。記録がない場合は、ノードを変更する前に、ルーティングやアプリの除外設定を確認してください。
• CPUを確認：ダウンロード中のカーネルプロセスのCPU使用率を確認します。特定のコアが継続的に高負荷で、通信速度も一定の上限に達している場合に限り、端末の性能やデータ処理の負荷を調べてください。
• TUNスタックを切り替え：mihomoで一般的なスタックの選択肢はsystem、gvisor、mixedです。利用できる項目はプラットフォーム、カーネル、クライアントのバージョンによって異なります。一度に1項目だけ変更し、画面の案内に従ってTUNを再度有効にしてから測定してください。すべての環境で最速となる設定はありません。
• 最後にMTUを確認：小さなリクエストは正常なのに大きなダウンロードが止まる場合や、特定のネットワークでTLS接続が繰り返し停止する場合は、経路MTUを調べます。MTUの変更を一般的な速度改善策として使わないでください。

MTUが原因だと示す根拠がある場合は、設定が対応していることを確認したうえで、診断用の比較値として1400を試せます。変更前の値を記録し、改善しなければ元に戻してください。MTUを小さくすると、同じデータ量を送るためのパケット数が増えるため、帯域が向上するとは限りません。サービスモード、仮想ネットワークアダプター、ルートの変更を行う場合は、ほかのネットワークに影響が残らないよう、先にTUNの設定方法を確認してください。

DNSの切り分け：名前解決の時間と通信速度は別

DNSが影響しやすいのは、Webサイトを最初に開くときや、接続の確立、接続先アドレスの選択です。接続が確立した後も大容量ファイルのダウンロードが遅い場合、DNSの変更だけで解決することは通常ありません。DNSが関係しているかを判断するには、初回と再アクセス時の違いを確認し、ログのタイムアウトや名前解決エラー、実際の接続先アドレスも調べてください。

Fake-IPとreal-ipの見分け方

fake-ipはアプリにドメインと対応付ける仮想アドレスを返し、カーネルがドメインに基づいて接続を処理します。redir-hostは実際に名前解決したアドレスを使います。198.18.0.0/16の範囲のアドレスが表示されても、それだけで異常とは限りません。実際の使用範囲は現在有効な設定で確認してください。見慣れないアドレスだからといってモードを切り替えたり、2つのモードを単純に「速い」「遅い」と決めつけたりしないでください。

1. サブスクリプションの元データだけでなく、現在有効なDNS設定を確認してください。クライアントによる上書き、パッチ、設定のマージによって、最終的なdnsセクションが変わることがあります。
2. ブラウザー独自のセキュアDNSが有効になっていないか確認します。ブラウザーが独自にDoHで名前解決している場合、システムDNSのテスト結果はブラウザーの実際の経路を反映しないことがあります。
3. 暗号化DNSの上流サーバーに接続できるか、またDNSサーバーのドメインを最初に名前解決する際に、利用できない経路に依存していないか確認してください。設定によっては名前解決の依存関係が生じ、応答待ちが続くことがあります。
4. 名前解決の設定を変更した後は、クライアントの機能に応じてDNSキャッシュを消去し、テストするアプリを再起動してください。ページを再読み込みするだけでは、接続やアプリのキャッシュが再利用される場合があります。

見知らぬDNSサーバーの一覧をそのままコピーして、設定全体を置き換えないでください。DNSサーバーの変更によってCDNの接続先やIPv4・IPv6の選択が変わることがあります。一時的に速くなっても、DNSサーバー自体の性能が高いとは限りません。ログでIPv6接続が繰り返し失敗し、IPv4は安定している場合は、IPv6経路を個別にテストしてください。仮の設定変更で仮説を確認することはできますが、長期的にはルーティングを修正するか、実際のネットワークに合ったアドレスファミリーを設定してください。

調査結果を記録し、原因の層を特定する

調査を終えるときは、再現条件を一文で説明できるようにします。たとえば「家庭の固定回線で夜にノードAを使うと、2つの接続先で速度が落ちる。同じ設定でテザリングすると正常」のように記録します。「どのノードも使えない」より、具体的な再現条件のほうが役立ちます。サブスクリプション提供元やクライアント開発プロジェクトへ報告する場合は、個人情報を除いた時刻、OSとFlClash・カーネルのバージョン、比較手順を添えてください。

ログは問題の再現前後、必要な数十秒だけを抜き出してください。サブスクリプションURL、ノードのパスワード、認証トークン、プライベートなアクセス用ドメインは事前に削除します。サブスクリプションのURLにはアクセス情報が含まれていることが多いため、公開の調査資料に載せないでください。テスト後は一時的に変更したモード、プロキシグループ、システムプロキシの状態を元に戻し、効果を確認できた変更だけを残します。

クライアントで問題を安定して再現できる場合は、プロジェクトの正式リリース版への更新を検討し、更新前後のバージョンと測定結果を記録してください。更新は原因を切り分けるための最初の手順ではありません。同じノード・接続先を使い、一度に1つの条件だけ変えて比較することで、何が改善につながったかを判断できます。サブスクリプションの読み込みや出站モードをまだ確認できていない場合は、先に設定ガイドに沿って正常に動作する基準状態を作り、その後に速度を測定してください。