Clashが遅いときの原因と対処法｜ノード・回線・設定を順に確認

高遅延・低スループット・接続の停滞を切り分ける

Clashが遅いといっても、原因はひとつとは限りません。Webページの表示開始が遅い場合は、DNSの名前解決や接続確立に時間がかかっている可能性があります。ダウンロードが数百KB/sのまま続くなら、スループットがボトルネックかもしれません。動画の再生開始はスムーズでも数分後に読み込みが止まる場合は、回線の変動や出口の混雑、アプリが実際に使っている接続を確認しましょう。まず症状を記録してから設定を変えると、問題を複雑にせずに済みます。

Clashはプロキシコアで、mihomoはClash Metaの系譜を継ぐ互換コアです。デスクトップやモバイルのクライアントは、画面表示のほか、システムプロキシや設定の管理も担います。同じ名前の設定でも、クライアントによって場所が異なる場合があります。調査時はクライアント名・バージョン・コアのバージョンを記録し、「最新版を入れた」とだけ書かないようにしましょう。

基準値を取る：対象・時間帯・接続方法を固定

速度測定ボタンで確認できるのは、通常、指定URLへの応答時間です。すべてのサイトに接続できるかを示すものでも、帯域測定でもありません。自動選択のプロキシグループは、測定中にノードが切り替わることがあります。比較する前に手動選択できるグループへ切り替えてノードを固定し、バックグラウンドのダウンロードやクラウド同期を止めましょう。

1. 現在の状態を記録する。設定をバックアップし、ルールモード、システムプロキシ、TUNの状態、現在の出口ノードを記録します。プロキシクライアントが複数起動していないことも確認してください。
2. ローカルネットワークをテストする。直接接続できる信頼性の高いダウンロードサイトで速度を測ります。直接接続でも遅い場合は、有線接続、ルーターの近くで使うWi-Fi、スマートフォンのテザリングを比較してください。
3. プロキシのテスト対象を固定する。速度測定が許可され、ファイルサイズが十分に大きいHTTPSダウンロードを選びます。各回約30秒測定し、最初の5秒の変動は除いて、3回続けて実施します。
4. アプリの実際の通信経路を記録する。クライアントの「接続」画面で対象ドメインを探し、リクエストが想定したプロキシグループを通っているか確認します。メイン画面に表示されたノード名だけで判断しないでください。
5. 1回のテストで変えるのは1項目だけ。ノードを切り替えるときにDNSも変更したり、TUNをテストするときにスマートフォンのテザリングへ切り替えたりしないでください。各回の測定後は古いダウンロードを終了し、新しく接続し直します。

以下は記録形式の例であり、このサイトで実測した結果ではありません。実際に記入する際は自分のデータを使い、テストファイル・端末・時間帯をそろえてください。瞬間的な最高値だけで全体を判断しないようにしましょう。

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

遅延が最も小さいノードが、ダウンロードも最速とは限らない

遅延測定でわかるのは、小さなリクエストの往復時間です。ノードの応答が速くても、出口の帯域が逼迫していたり、同時接続数に厳しい制限があったり、対象サイトまでの経路が不適切だったりする場合があります。反対に、地理的に遠いノードでも、遅延が少し大きいだけで持続的なスループットが安定することがあります。Web操作と大容量ファイルのダウンロードは別々に測定し、遅延の順番だけで結論を出さないでください。

• 同じサブスクリプションから2～3個のノードを選び、名前が似たノード同士ではなく、入口や回線が異なるものを優先して比較します。
• サービスの通信量残高、速度制限、有効期限を確認してください。サブスクリプションを更新するとノード情報は更新されますが、サーバー側の帯域が増えるわけではありません。
• プロキシグループの入れ子構造を確認します。ルールの転送先がProxyでも、Proxyが別の自動選択グループを参照している場合があります。最終的に使われるノードまで展開して確認してください。
• ノードを切り替えたら、実行中のダウンロードを終了してから再試行します。確立済みの接続は切り替え前の出口を使い続けることがあるため、古い接続の結果を新しいノードの結果として扱わないでください。

自動切り替えが比較に影響しないようにする

url-testは主に指定URLへの遅延をもとに経路を選びます。fallbackは優先順に利用可能な項目を選び、load-balanceは接続ごとに異なるノードへ振り分ける場合があります。いずれも、ノードの持続的なダウンロード速度を直接示すものではありません。これらのグループを使っている場合は、手動選択グループで出口を固定してから、同じファイルを測定してください。

特定のノードだけ遅く、同じ条件でほかのノードは正常なら、原因の範囲は絞り込めています。クライアントの再インストールや設定の全消去を繰り返しても、得られるものはほとんどありません。そのノードの入口や出口の回線を確認するか、具体的な測定記録を添えてサービス提供元に問い合わせましょう。

第2段階：接続回線・出口経路・ピーク時の混雑

プロキシ通信は少なくとも、端末からノードの入口まで、ノード内の転送、出口から対象サイトまでの複数の経路を通ります。ノード名に含まれる地域名だけでは、入口の通信事業者や中継方式まではわかりません。名前の異なるノードでも入口を共有していることがあり、名前だけを変えて経路が変わらなければ、混雑を回避できるとは限りません。

3つの比較で原因を絞る

1. 同じノードでネットワークを変える。自宅の固定回線とスマートフォンのテザリングを比較します。テザリングで明らかに改善するなら、接続ネットワークまたはノードまでの経路が疑われます。ただし、それだけで通信事業者による速度制限とは断定できません。
2. 同じネットワークで時間帯を変える。たとえば10:00と21:00に、それぞれ3回ずつ測定します。複数の夜で似た速度低下が繰り返されて初めて、ピーク時の混雑が原因だと考えやすくなります。
3. 同じ出口で対象サイトを変える。異なるサービスから、正規のダウンロードファイルを選んで比較します。特定のサイトだけ遅い場合は、そのサイトのCDN割り当て、単一接続の制限、プロキシ出口への制御などが考えられます。

速度測定サイトは複数接続を使うことが多い一方、ブラウザーでのファイルダウンロードは1本または少数の接続だけを使う場合があります。そのため、表示される数値が一致しなくても珍しくありません。測定サイトでは速く、単一ファイルのダウンロードが遅い場合は、単一接続での速度も比較しましょう。すぐにクライアントが「速度を落としている」と判断する必要はありません。動画サイトはバッファーやビットレートに応じてダウンロード速度を調整するため、帯域の基準として単独で使うのは適切ではありません。

第3段階：システムプロキシ・ルール・ローカルの待ち受けポート

まずアプリの通信がクライアントを経由しているか確認する

システムプロキシは、端末上のすべての通信を取り込む仕組みではありません。システムプロキシを参照しないアプリもあり、コマンドラインツールは独自の引数や環境変数だけを使うこともあります。TUNモードは仮想ネットワークインターフェイスを通じて、ルーティング条件に合う通信を取り込みますが、動作はプラットフォームの実装、ルート、除外設定にも左右されます。ブラウザーは正常でもゲームやコマンドラインツールが遅い場合は、すぐにノードのせいにせず、まず通信の取り込み方式を確認しましょう。

Windows 11では、「設定」→「ネットワークとインターネット」→「プロキシ」で、手動プロキシのアドレスとポートを確認できます。macOS 13以降では、「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」で確認してください。クライアントでシステムプロキシを有効にすると、通常はこれらの項目が自動入力されます。手動で変更する前に、元の値を記録しておきましょう。

以下は待ち受け設定の一部で、完全な設定ではありません。7890は例示用の値です。テスト時はクライアントで実際に有効なポートを確認してください。画面から設定ファイルを生成するクライアントもあり、サブスクリプションのファイルを直接編集すると、次回更新時に変更が上書きされることがあります。

mixed-port: 7890
allow-lan: false
log-level: info

mixed-portは、同じポートでHTTPとSOCKSのプロキシリクエストを受け付けます。アプリが古いポートを参照したままだと、接続に失敗したり、失敗後に直接接続へ戻ったりすることがあります。allow-lan: falseはLANからのアクセスを制限する設定で、変更しても端末の通信速度は上がりません。

ルールモードでは実際に適用されたルールを確認する

クライアントの「接続」画面で、ドメイン、接続先IP、適用ルール、出力経路を確認します。日本国内のダウンロードサイトがプロキシ経由になっていると、かえって遅くなる場合があります。プロキシ経由にすべき接続がDIRECTになっている場合は、長時間待たされることもあります。ルールは通常、上から順に判定されるため、前方の広範なルールが後方の詳細なルールに先に一致する場合があります。サブスクリプションのプロキシグループ名と、ルール内で参照する名前が一致しているかも確認してください。

比較のために一時的にグローバルモードを使うことはできますが、あくまで診断用です。グローバルモードでは正常でルールモードでは遅い場合は、グローバルモードを常用して問題を覆い隠すのではなく、ルールとプロキシグループを確認しましょう。各項目の意味はプロキシモードの説明とポートの説明をご覧ください。

DNS・TUN・端末負荷を個別に確認する

DNSが影響しやすいのは「表示開始の遅さ」で、あらゆる速度低下ではない

DNSの名前解決は接続確立前に行われ、キャッシュや接続の再利用によって2回目のアクセスが速くなることがあります。ページの読み込み開始まで数秒かかる一方、ダウンロード開始後は正常な速度が出る場合は、名前解決から接続確立までの時間を確認しましょう。すでに確立した長時間接続の速度がずっと遅い場合、DNSを変えるだけでは通常解決しません。

• システム、ブラウザーのセキュアDNS、クライアントのDNSに、それぞれ個別の設定がないか確認してください。ブラウザー内蔵の暗号化DNSは、クライアントが想定する名前解決の経路を通らない場合があります。
• fake-ipを使っている場合、システムに表示されたアドレスがマッピング用だからといって、名前解決の失敗とは限りません。たとえば198.18.0.0/16の範囲がfake-ip用アドレスプールとして使われることがあります。実際の設定とあわせて判断してください。
• IPv6経路の問題が疑われる場合は、一時的にIPv4とIPv6を比較し、元に戻す方法も記録してください。特定のサイトが遅いという理由だけで、システム全体のIPv6を恒久的に無効にしないようにしましょう。

TUNのオン・オフは一度に1項目だけ変えて比較する

まずシステムプロキシ方式で、HTTPプロキシに対応したブラウザーを使ってテストします。次にノードと対象を変えずにTUNで試してください。TUNモードのときだけ遅い場合は、ほかのVPN、仮想マシンのネットワーク、ルートの競合、クライアントのログを確認します。通信の取り込み方式を変えた後も同じ出口を通っているか確かめてください。出口が異なると、2回の結果をそのまま比較できません。

MTUの不一致は、小さなリクエストは通るのに大きな応答が止まる症状につながることがありますが、その現象だけで原因を断定することはできません。「最適なMTU」とされる値をそのまま適用しないでください。検証が必要なら元の値を記録し、該当設定に対応するクライアントで一度に1項目だけ変更して、接続をやり直してから測定します。改善しなければ元に戻しましょう。TUNのstackの対応状況や動作はプラットフォームとコアのバージョンによって異なるため、特定のスタックが必ず速いとは限りません。

CPUの高負荷やログ書き込みもスループットに影響する

Windowsの「タスク マネージャー」→「パフォーマンス」→「CPU」では、グラフを論理プロセッサ表示に切り替えられます。macOSの「アクティビティモニタ」→「CPU」では、クライアントとコアのプロセスを確認してください。全体のCPU使用率が低くても、特定のコアだけがほぼ上限に達していることがあります。古い端末、複雑なルール、多数の同時接続は、処理負荷を高める要因になります。

通常の確認ではログレベルにinfoを使い、詳しい情報が必要なときだけ一時的にdebugへ切り替えます。問題を一度再現したら元に戻してください。デバッグログを大量に出し続けると、処理負荷が増えるほか、アクセスに関する機密情報が記録されるおそれがあります。ログを共有する前に、サブスクリプションURL、トークン、ノードのパスワード、個人用ドメインを伏せてください。

結果をまとめる：記録を残し、一時設定を元に戻す

調査を終えるときは、「同じファイル・同じネットワークでノードAは3回とも約1MB/s、ノードBは約7MB/s」のように、再現できる結論を残しましょう。「夜は遅い」だけでは不十分です。数値は例ですが、条件がそろっていて結果を再現できることが重要です。サービス提供元に連絡するときは、タイムゾーン付きの発生日時、接続事業者、ノード識別情報、クライアントとコアのバージョンを添えれば十分です。サブスクリプション全体は送らないでください。

最後に、一時的に使ったグローバルモード、デバッグログ、ネットワーク設定を元に戻し、サブスクリプション更新後も意図した設定が有効か確認してください。速度測定では実際の通信量を消費します。スマートフォンのテザリングや従量制サービスでは、測定時間を抑えましょう。原因を特定できない場合は、接続トラブルの説明を確認するか、セットアップガイドに戻って基本設定を見直してください。