第1段階：まず再現可能な速度基準を作る

Clashに表示されるノードのレイテンシ、ウェブページの表示時間、ダウンロード速度は、それぞれ異なる指標です。レイテンシテストは通常、1回のHTTPリクエストやTCP接続の応答時間だけを測定します。ノードに到達できるかは判断できますが、継続的なスループットを直接示すものではありません。レイテンシが80ミリ秒でも帯域幅が不足しているノードはあります。一方、180ミリ秒のノードが大容量ファイルのダウンロードではより高速な場合もあります。そのため、切り分けの開始時にノード一覧のミリ秒表示だけを見ないようにしましょう。

まず、端末、ネットワーク、テスト対象を固定します。ファイル同期、システム更新、ゲームのダウンロード、写真のアップロードを行っているアプリを終了し、安定したウェブサイトと十分な容量のテストファイルを選びます。各テストは少なくとも数十秒続け、ファーストビューの表示時間、安定したダウンロード速度、途中で停止するかどうかを記録してください。短時間の速度テストは、キャッシュ、接続のウォームアップ、サーバー側の速度制限の影響を受けやすくなります。

  1. ClashのシステムプロキシまたはTUNモードを一時的に無効にし、現在のネットワークの直接接続時の速度を測定します。
  2. Clashを有効にし、1つのノードと1種類のプロキシモードに固定して、同じ対象へ再テストします。
  3. 同じ地域にある別のノードへ切り替え、同じ条件でテストをもう一度行います。
  4. レイテンシ、ダウンロード速度、アップロード速度、パケットロス、ウェブページの名前解決時間をそれぞれ記録します。

直接接続自体が明らかに遅い場合は、すぐにClashの設定を変更せず、まず固定回線、モバイル通信、Wi-Fiを確認します。プロキシ接続だけが遅い場合は、ノード、入口回線、出口回線、クライアント設定を順に調べます。特定のウェブサイトだけ遅く、ほかのプロキシ通信が正常なら、対象サイト、ルーティングルール、またはサイト側から見た出口アドレスへの接続品質に問題がある可能性もあります。

第2段階：ノードのレイテンシ、帯域幅、負荷を切り分ける

ノードは速度低下で最もよくあるボトルネックですが、「ノードが利用可能」という表示は接続を確立できることを示すだけです。実際の速度は、サーバーの帯域幅、同時接続数、プロトコルの実装、通信事業者からの入口回線の品質、出口から対象サイトまでの経路にも左右されます。ピーク時間帯だけ遅く、深夜に回復するなら、負荷や回線混雑の可能性が高くなります。一日中安定して遅い場合は、ノードの速度制限、経路品質、端末の処理能力を確認します。

レイテンシテストを本格的な速度測定と混同しない

Clashクライアントでは、一般的に1つのテストURLを使ってノードのレイテンシを計算します。この結果は、テスト先、接続の再利用、DNSキャッシュ、タイムアウト設定の影響を受けます。レイテンシが低いのにスループットが低い場合は、ノードの帯域幅不足が考えられます。レイテンシが時々急上昇するなら、回線の揺らぎが疑われます。多くのノードが同時にタイムアウトする場合は、ノードを1つずつ繰り返し確認するのではなく、サブスクリプション、ネットワーク権限、DNS、サーバーの状態を調べてください。

ノードを選ぶときは、まず地域ごとにグループ化し、同じ地域で少なくとも3つのノードを比較します。テストにはウェブページ、小容量ファイル、継続的なダウンロードを含めます。動画再生では、瞬間的なピーク速度ではなく、バッファリングが安定しているかも確認してください。クライアントがURL Test、Fallback、負荷分散のプロキシグループに対応している場合は、それぞれの選択基準も理解しておきます。URL Testは応答が速いノードを選びやすく、Fallbackは障害時の切り替えを重視し、負荷分散では接続ごとに異なるノードを通ることがあります。

プロキシグループが実際に目的のノードを選択しているか確認する

設定には複数階層のプロキシグループがよく使われます。たとえば、アプリのルールがまず「海外サイト」に入り、そのグループが「自動選択」を参照し、最終的に具体的なノードへ振り分けられます。画面上でグループを切り替えても、現在のリクエストが必ずそのグループを通るとは限りません。接続履歴やログを開き、対象ドメインがどのルールに一致し、どのプロキシグループに入り、最終的にどのノードを使ったかを確認します。

対象ドメイン → ルール一致 → プロキシグループ → 子プロキシグループ → 具体的なノード

通信がDIRECTに一致した場合、速度テストは実際には直接接続で行われています。REJECTに一致した場合、リクエストは明示的に拒否されます。自動プロキシグループに一致した場合、クライアントがバックグラウンドでノードを再選択することがあります。切り分け中は、プロキシグループ内の具体的なノードを一時的に固定し、自動切り替えが結果に影響しないようにします。テスト後は元のポリシーに戻してください。

第3段階：入口回線と出口回線の混雑を確認する

プロキシ接続には少なくとも、端末から地域の通信事業者、通信事業者からプロキシノード、プロキシノードから対象サイトまでの3区間があります。どの区間でも速度低下は起こり得ます。ノードまでの地理的距離が近くても、通信事業者間の相互接続経路が短いとは限りません。同じノードでも、固定回線やモバイル通信など利用するネットワークによって結果が大きく異なる場合があります。

最も実用的な判断方法は、条件を組み合わせて比較することです。ノードを固定したまま、端末を家庭のWi-Fiからスマートフォンのテザリングへ切り替えます。あるいはネットワークを固定したまま、別地域や別の入口タイプのノードへ切り替えます。同じノードがネットワーク変更後に回復するなら、地域の通信事業者からノードまでの経路に問題がある可能性が高くなります。ノード変更後に回復するなら、元のノードの負荷や経路がより疑わしくなります。

  • 日中は正常なのに夜間は遅い：ピーク時間帯の混雑、共有帯域幅の負荷、通信事業者間の相互接続の混雑を優先して確認します。
  • ウェブページは速いのにダウンロードが遅い：ノードの継続帯域幅、対象サイトの速度制限、単一接続時の性能を確認します。
  • ダウンロードは速いのに動画が頻繁に止まる：ストリーミング先への出口経路、ルールの一致、接続の安定性を確認します。
  • 最初の表示だけ遅く、その後は正常：DNS、TLS接続の確立、初回の経路選択を重点的に確認します。
  • 速度が周期的にゼロになる：パケットロス、無線干渉、ノードの再起動、接続の切り替え、端末のスリープ設定を確認します。

コマンドラインのpingは、限られた参考情報しか提供しません。サーバーによってはICMP応答の優先度を下げたり、完全に応答しなかったりしますが、TCPやUDPの通信は動作している場合があります。tracerouteは経路のどの区間で大きな変化が起きたかを確認するのに役立ちますが、特定の中継点が応答しないだけで障害と判断することはできません。より信頼できる結論は、複数の時間帯、ネットワーク、ノードを比較して得られます。

第4段階：DNS名前解決と接続待ち時間を確認する

DNSの問題は、通信速度の低下と誤解されがちです。URLを入力してから長時間画面が白いままでも、ページの読み込みが始まると速度は正常になることがあります。特定のドメインだけ開けず、別のドメインは開ける、またはネットワークを切り替えるとすぐに回復する場合も同様です。このときボトルネックは、プロキシノードのデータ転送ではなく、ドメイン名の解決段階にある可能性があります。

Clashやmihomoの設定ではDNSを引き継ぎ、動作モードに応じて通常のDNS、暗号化DNS、Fake IP、Redir Hostなどを利用できます。クライアントによってスイッチの名称は異なりますが、最終的な動作はカーネル設定とクライアントが生成する設定によって決まります。変更前に、DNSの有効化状況、リスニングアドレス、デフォルトリゾルバー、上流DNSを確認してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query

上記の断片はフィールド間の関係を説明するためのものです。例示したアドレスを、そのまま利用可能なサービスとみなさないでください。実際の切り分けでは、安定してアクセスできるリゾルバーを使い、システムやルーターがDNSリクエストを別の場所へ強制転送していないことを確認します。上流の暗号化DNSが先にドメイン名の解決を必要とする場合は、bootstrapまたはデフォルトの名前解決経路が正常に動作することも確認してください。

Fake IPモードでよくある誤判定

Fake IPはドメインに予約済みアドレスを返し、カーネルがそのアドレスを元のドメインへ対応付けてルール判定を行います。ドメイン通信を一元的に処理しやすい一方、LAN機器、特殊なアプリ、実際のIPアドレスを必要とするサービスでは、除外リストへの追加が必要になることがあります。プリンター、ルーターの管理画面、LANストレージ、一部のアプリだけに異常がある場合は、ノードが遅くなったと決めつけず、fake-ip-filterとLANバイパスルールを確認してください。

システムには古いDNSキャッシュが残っている場合もあります。設定を切り替えた後は関連アプリを再起動し、必要に応じてシステムのDNSキャッシュを削除してから再テストします。ブラウザーが独自のセキュアDNSを使用していることもあり、その場合はブラウザーとほかのアプリで名前解決経路が異なります。切り分けでは、システム、ブラウザー、Clashのそれぞれがどこで名前解決を担当しているかを確認し、複数のコンポーネントが同時にDNSを書き換えないようにします。

第5段階：システムプロキシ、ルールモード、TUNモードを比較する

システムプロキシは通常、OSのプロキシ設定を通じて、アプリにHTTPまたはHTTPSリクエストをClashへ渡すよう通知します。システムプロキシに従うブラウザーやデスクトップアプリは処理対象になりますが、一部のゲーム、コマンドラインアプリ、ストアアプリ、独自のネットワークスタックを実装したソフトウェアは設定を無視することがあります。TUNモードは仮想ネットワークインターフェースを作成し、より低い層でTCP、UDP、DNSの通信を広く処理します。その分、権限、ルーティングテーブル、OSのネットワークコンポーネントへの依存も大きくなります。

ブラウザーは正常なのに、ゲーム、ターミナルのダウンロードツール、特定のアプリだけが遅い場合は、まずそのアプリがプロキシ対象になっているか確認します。Clashの接続一覧でリクエストが表示されるかを確認し、対象アドレス、プロトコル、ルール、最終ノードを調べてください。接続一覧に記録がない場合、通常は通信がカーネルに入っていません。記録があってDIRECTを使っているなら、ルールが直接接続を選んでいます。記録がありノードを経由している場合に、ノードや経路を詳しく分析します。

ルールモードとグローバルモードの比較方法

ルールモードは、ドメイン、IP、プロセス、ルールセットに基づいてDIRECT、REJECT、またはプロキシグループを選択します。グローバルモードは通常、大部分の通信を指定したプロキシポリシーへ渡します。特定のウェブサイトを切り分けるときは、一時的にグローバルモードへ切り替えて比較します。グローバルモードで回復し、ルールモードだけ遅い場合は、ルールの一致、プロキシグループ、DNSを確認します。どちらのモードでも遅いなら、ノードや経路の問題がより疑われます。

グローバルモードは一時的な切り分けにのみ使い、ルールの修正の代わりにしないでください。テスト後はルールモードに戻し、差が生じた具体的なルールをログから特定します。前段のルールに一致しなかったリクエストは、設定末尾のMATCHルールに到達するため、ここも確認が必要です。

TUNモードで速度が低下したときの確認項目

  • クライアントが仮想ネットワークアダプターの作成とルート変更に必要なシステム権限を持っているか確認します。
  • ほかのVPN、仮想マシンのネットワークアダプター、ゲーム向け回線最適化ツール、セキュリティソフトが同時にルートを変更していないか確認します。
  • MTU設定が現在のネットワークに適しているか確認します。大きすぎるパケットは分割や破棄を引き起こすことがあります。
  • UDPが安定しているか確認します。一部のネットワーク環境ではUDPが制限され、QUIC、ゲーム、リアルタイム通信に影響することがあります。
  • TUNを無効にし、システムプロキシだけを有効にした場合の速度と比較し、問題が仮想インターフェースに関係するか判断します。

一部のブラウザーは、UDPベースのHTTP/3を優先して使用します。回線がUDPを安定して処理できない場合、ウェブページの接続確立が遅い、動画が不安定、速度テストの結果が大きく変動するといった症状が出ることがあります。接続ログでプロトコルを確認してから、短時間の比較テストを行います。複数のネットワーク機能を一度に恒久的に無効化せず、どの変更が結果に影響したのかを先に確認してください。

第6段階：端末性能、無線ネットワーク、バックグラウンド処理を切り分ける

プロキシカーネルは、暗号化、復号、ルール判定、DNS処理、接続転送を実行します。現在のデスクトップ端末なら日常的な通信を処理できることが多い一方、低消費電力のルーター、古いスマートフォン、リソースが限られたサーバー、多数の接続を同時に処理する端末では、CPU使用率が上限に近づくことがあります。この場合、ボトルネックはローカルの処理能力にあるため、ノードを変更しても改善しないことがあります。

速度テスト中はタスクマネージャーやシステムモニターを開き、Clashクライアント、カーネルプロセス、ブラウザー、セキュリティソフトのCPU、メモリ、ディスク、ネットワーク使用率を確認します。速度低下時に特定のコアが継続的に高負荷なら、不要な複雑なルールを減らし、過剰なログを無効にし、同時接続数を減らすか、より高性能な端末で比較してください。

Wi-Fiもよくある変動要因です。2.4GHz帯は近隣の無線LAN、Bluetooth機器、家電の干渉を受けやすく、ルーターから離れるとデータの再送が頻発することがあります。基準測定では、まず有線LANまたは安定した5GHz・6GHz帯を使います。有線では正常で無線だけ遅い場合は、プロキシプロトコルを変更する前に、チャンネル、距離、ルーターの設置場所を調整してください。

バックグラウンドアプリは上り帯域幅を消費し、上り回線の飽和によってダウンロード時のレイテンシも上昇させます。クラウドストレージの同期、写真のバックアップ、ビデオ会議、トレントのアップロードなどが原因になります。ダウンロード帯域に余裕があっても、キューイング遅延によってウェブページや操作への反応が遅く感じられます。バックグラウンド処理を一時停止し、しばらく待ってから同じテストを実行してください。

設定規模とログレベル

大規模なルールセットや頻繁に更新されるサブスクリプションは読み込み時間を増やしますが、通常の設定で各リクエストに明らかな遅延が生じることはありません。クライアント起動後に長時間固まる場合は、ルールセットの重複、同じリソースの多重参照、ログレベルの設定を確認します。デバッグログは短時間の切り分けに適していますが、大量の接続情報を継続的に記録すると、ディスク書き込みや画面描画の負荷が増えます。

サブスクリプション更新後に突然遅くなった場合は、プロキシグループ名とノード名が変わっていないかも確認します。クライアントがグループのデフォルト項目へ戻ったり、自動テストが別のノードを選択したりすることがあります。更新前後の最終設定と現在の選択項目を確認するほうが、サブスクリプションを何度も再インポートするより差異を見つけやすくなります。

順番に進める10分間の切り分け手順

速度の問題は、外側から内側へ順番に範囲を狭めるのが効果的です。以下の手順では、すぐにYAMLを変更する必要はありません。比較によって問題の層を特定してから、該当する設定を調整します。

  1. 直接接続を測定：プロキシを無効にして現在のネットワークをテストし、基礎回線に明らかな異常がないことを確認します。
  2. ノードを固定：自動選択を無効にし、1つのノードを指定してレイテンシと継続的なダウンロード速度を記録します。
  3. ノードを変更：同じ地域と別の地域から1つずつノードを選び、ピーク時と通常時の結果を比較します。
  4. 接続を確認：対象リクエストがClashに入り、どのルール、プロキシグループ、最終ノードを使ったかを記録します。
  5. ネットワークを変更：スマートフォンのテザリングや別の固定回線で同じノードをテストし、入口回線の問題か判断します。
  6. DNSを確認：遅延が名前解決段階にあるのか転送段階にあるのかを確認し、システムとクライアントの名前解決経路を照合します。
  7. モードを比較：ルールモードとグローバルモード、システムプロキシとTUNモードの結果を比較します。
  8. リソースを確認：CPU、メモリ、無線信号、バックグラウンドのアップロードがボトルネックになっていないか確認します。
  9. 設定を再読み込み：設定の解析が成功し、プロキシグループの選択とサブスクリプション更新の結果が想定どおりか確認します。
  10. 設定を復元：テストのためだけに有効にしたグローバルモード、デバッグログ、一時的なDNS変更を元に戻します。

最終的な記録には、テスト日時、ネットワークの種類、クライアントのバージョン、カーネルの種類、プロキシモード、ノード名、対象サイト、速度結果を含めます。ノードサービスの提供者やクライアントプロジェクトへ問題を報告する場合、これらの情報は「なんとなく遅い」よりも診断に役立ちます。設定内容を共有するときは、サブスクリプションURL、認証情報、ノードの資格情報、個人のネットワーク情報を先に削除してください。

切り分けの結論：どの区間で遅いのかを先に特定する

Clashの速度が遅いからといって、必ずしもノードのレイテンシが高いとは限りません。接続全体は、ローカルネットワーク、DNS、ルール判定、プロキシ入口、ノードの処理、出口経路、対象サイトによって構成されています。まず直接接続の基準を測定し、ノードを固定します。その後、ネットワーク、ノード、モードを1つずつ変更して比較すれば、ノード負荷、通信事業者の経路、DNS待ち、端末性能のボトルネックを切り分けやすくなります。

同じネットワークで全ノードが遅く、ネットワークを切り替えると回復するなら、まずローカルネットワークと通信事業者の経路を確認します。一部のノードだけ遅い場合は、ノード負荷と出口回線を重点的に調べます。ウェブページの初回表示だけ遅く、ダウンロードが安定している場合はDNSを確認します。特定のアプリだけ異常があるなら、システムプロキシやTUNが実際に通信を処理しているかを確認してください。層ごとに記録し、変更は1項目ずつ行い、最後に一時設定を戻すことで、単純な問題を複数の設定競合へ広げずに済みます。

お使いのプラットフォームに合うインストーラーを選択

ダウンロードセンターでOSとアーキテクチャを確認し、利用ガイドに従ってインストール、サブスクリプションのインポート、基本的な接続確認を行います。

ダウンロードページへ ガイドを見る