1. 読み込みが遅い・ダウンロードが遅い・接続が切れる場合を切り分ける

Clashでノードの遅延が正常と表示されても、動画がバッファリングすることはあります。矛盾ではありません。ノード一覧の遅延は通常、テスト用の宛先へリクエストを1回送った結果で、その時点の応答時間を示すだけです。ダウンロード速度には、ノードの負荷や経由する回線、接続先の速度制限、Wi-Fi環境なども影響します。まずは「遅い」と感じる状況を、繰り返し確認できる形にしましょう。

症状優先して確認する項目比較方法
最初の表示まで時間がかかるが、その後は正常DNS、接続の確立、TLSハンドシェイク初回と再アクセス時の所要時間を比較する
ページは開くが、大きなファイルのダウンロードが遅いノードの転送速度、回線の混雑、サーバー側の速度制限同じファイルを別のノードで試し、次に別のネットワークで試す
特定のアプリだけ遅い、または接続できないアプリのプロキシ対応、適用ルール、UDPの経路該当アプリの実際の接続ログを確認する
プロキシ経由でも直接接続でも遅いWi-Fi、ルーター、固定回線、バックグラウンド通信一時的にプロキシを無効にして、ローカルネットワークをテストする

再現可能な基準を作る

  1. クラウド同期、ゲームのダウンロード、システム更新を一時停止し、端末・場所・対象ファイルをそろえます。
  2. クライアントの「プロキシ」画面で現在のプロキシグループを開き、テスト中に出口が切り替わらないよう、ノードを一時的に手動選択します。
  3. 同じ対象に対して3回連続でテストし、開始時刻、最初の画面が表示されるまでの時間、安定したダウンロード速度を記録します。大きなファイルは約30秒を目安に確認し、データ通信量にも注意してください。
  4. 一度に変更するのは1項目だけにし、「ノード → 接続ネットワーク → ローカル設定」の順に比較します。

2. ノード：遅延が小さくても帯域が十分とは限らない

まずクライアントの「プロキシ」画面を開き、現在のルールで使われているプロキシグループからノードを選びます。Clash Verge RevなどのGUIクライアントでは、サイドバーの「プロキシ」「接続」「ログ」などが一般的な入口です。名称はクライアントによって異なるため、実際の画面を確認してください。ノード一覧だけで判断せず、「接続」画面でテスト通信が選択したノードを通っていることも確認しましょう。

3つの比較でノードの問題を切り分ける

  • 同じ地域の別ノードを試す：接続先は変えず、同じ地域にある2つのノードを比較します。一方だけが長時間遅い場合は、そのノードの負荷や速度制限、出口に原因がある可能性が高くなります。
  • 別の地域の出口を試す：ある地域のノードが全体的に遅く、別の地域では改善する場合、経路や接続先からその出口までの接続を詳しく調べる価値があります。ローカルのクライアント設定が壊れているとは限りません。
  • 別のファイルを試す：同じノードでほかのサイトは正常なのに、特定のダウンロード元だけ遅い場合は、そのサイトのアカウント別速度制限、CDNの割り当て、単一接続の制限を確認します。

全ノードの速度テストを連続実行した直後にダウンロード速度を比較するのは避けましょう。一括テストは短時間にリクエストを増やすうえ、クライアントによっては「遅延テスト」と「ダウンロード速度テスト」が別の機能です。テストを止めてから、ノードを1つずつ比較してください。サブスクリプションに通信量の上限がある場合、大量の速度テスト自体で上限を消費することにも注意が必要です。

サブスクリプション更新後に選択状態が変わっていないか確認する

「サブスクリプション」または「設定」画面を開き、現在有効なProfileと最終更新日時、更新結果を確認します。更新後にノード名やグループの構成が変わり、以前の手動選択が有効でなくなる場合があります。「プロキシ」画面で選択し直し、「接続」画面で実際の経路を確認してください。アカウントトークンを含むサブスクリプションURLを、速度テストのために公開サイトへ貼り付けないでください。

3. 回線：ネットワークや時間帯を変えて混雑を切り分ける

ノード名に含まれる地域は通常、出口の場所を示すもので、入口やネットワーク間の接続、中継経路までは分かりません。同じ出口でも、利用するプロバイダーによって速度が異なることがあります。ノードを変えても結果が安定しない場合は、すぐにDNSを書き換えるのではなく、接続ネットワークを比較しましょう。

  1. まずWi-Fi環境を切り分ける：ノードはそのままにし、PCをルーターの近くへ移動します。可能なら有線LANに切り替えて、同じ接続先への速度が改善するか確認してください。電波が弱い、または無線干渉がある状態を、プロキシ回線の混雑と誤認しないためです。
  2. 次にスマートフォンのテザリングと比較する：同じPCをテザリングに接続し、ノードと接続先は変えずに試します。テザリングで明らかに速くなる場合は、元の固定回線の経路、ルーター、または接続ネットワークに原因がある可能性が高くなります。テストではモバイルデータ通信を消費します。
  3. 時間帯による違いを記録する：たとえば10:00、20:30、23:30に同じ条件でテストします。夜間に全体的な速度が下がる場合は、共有回線の利用増加と一致する傾向があります。ただし、時間帯による変化だけでは混雑箇所を特定できません。

通常のpingはICMPを送信するため、システムのHTTPプロキシを有効にしても自動的にプロキシノードを経由するわけではありません。その結果をプロキシ経由のダウンロード速度として扱うことはできません。経路追跡でも、中継機器が応答しないことがあります。特定の経由地点でタイムアウトしただけでは、その地点でパケットが失われているとは判断できません。同じ端末、同じ接続先で、ネットワークを変えてアプリの通信を比較するほうが有効です。

4. DNS：名前解決の経路を確認してから設定を変更する

DNSの問題では、初回の表示に時間がかかる、一部のドメインに接続できない、適切でないCDNのIPアドレスに解決される、といった症状がよく見られます。一方、接続確立後も速度が安定して低い状態を、DNSだけで説明できることは通常ありません。ダウンロードが続いているのに速度が遅い場合は、まずノードと回線を比較してください。

別々に設定されている可能性がある3つのDNSを確認する

  • システムDNS：クライアントが介在しない名前解決に影響します。Windowsでは、ターミナルでipconfig /allを実行すると、現在のネットワークアダプターに設定されたDNSサーバーを確認できます。
  • コアのDNS：現在の設定にあるDNSの項目を開き、dns.enable、enhanced-mode、上流DNSのアドレスを確認します。mihomoを使うクライアントでは、オーバーライドによって最終的な設定が生成される場合があります。サブスクリプションの元ファイルだけでなく、実行中の設定を確認してください。
  • ブラウザーのセキュアDNS：ブラウザーが独自に暗号化DNSを使う場合があります。Chromeでは通常、「設定」→「プライバシーとセキュリティ」→「セキュリティ」→「セキュアDNSを使用する」から確認できます。比較テストでは現在の設定を記録し、一時的に無効にして結果を確認した後、必要に応じて元に戻してください。

fake-ipが有効な場合、アプリに合成アドレスが表示されるのはこのモードの正常な動作です。アドレスがグローバルIPでないという理由だけで、名前解決の異常と判断しないでください。一方、ブラウザーが独自のDNSを使っている、アプリが古いアドレスをキャッシュしている、ドメインが接続制御の対象外になっているといった理由で、想定どおりにルールが適用されないこともあります。

変更前に設定をバックアップし、一度に変更するのは1項目だけにしてください。サブスクリプション管理クライアントでは、次回の更新で変更が上書きされないよう、対応しているオーバーライド機能を優先して使います。上流DNSへの接続経路が利用可能かどうかも重要です。現在のプロキシを経由しないと到達できないアドレスへ安易に変更すると、問題の切り分けがさらに難しくなる場合があります。設定項目は使用中のコアのドキュメントを確認し、mihomo用の設定を古いClashコアすべてにそのまま適用しないでください。

キャッシュをクリアしてから比較する

WindowsでDNSを変更した後、コマンドプロンプトで次のコマンドを実行し、テストするアプリを完全に終了してから起動し直します。この操作で消去されるのはシステムのDNSキャッシュだけです。ブラウザーのキャッシュ全体が消えるわけではなく、回線の帯域が広がることもありません。

ipconfig /flushdns

5. ルール：実際の出口と接続モードを確認する

クライアントの「接続」画面を開き、対象サイトに再アクセスして、新しい接続をドメインで絞り込みます。適用されたルール、プロキシグループ、最終的なノードを確認してください。Clashのルーティングルールは通常、上から順に照合されます。範囲が広すぎるルールが前にあると、直接接続すべきサービスが遠方のノードを経由したり、プロキシが必要なサービスが直接接続されたりすることがあります。

  1. 現在のモードがRuleであることを確認し、対象接続のルールと出口を記録します。
  2. 一時的にGlobalへ切り替え、グローバル用プロキシグループで同じテスト対象ノードを選び、同じ接続先にアクセスします。
  3. Globalでは正常でRuleモードで問題が出る場合は、ルール分岐とグループの選択を重点的に確認します。どちらのモードでも遅い場合は、ノード、経路、接続先サイトを調べ直してください。
  4. テスト後はRuleに戻し、ローカルサービスや中国本土向けの通信が常に遠回りしないようにします。

以下はルールの順序を示す最小限の例です。「具体的なドメインのルールを先に、最後にフォールバックを置く」という考え方を示しています。PROXYは実際の設定に存在するプロキシグループである必要があります。この内容でサブスクリプション全体を置き換えないでください。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

ノードやルールを切り替えても、既存の長時間接続は以前の出口を使い続けることがあります。ダウンロードを一時停止して再開するか、「接続」画面で対象の接続だけを切断し、新しい接続を確認してください。すべての接続を切ると、会議やファイル転送なども中断するため、毎回行う方法としてはおすすめしません。

6. ローカル側の通信制御：システムプロキシ、TUN、アプリのプロトコル

システムプロキシを使うのは、システムのプロキシ設定に従うアプリが中心で、すべてのプログラムが自動的に対象になるわけではありません。TUNは仮想ネットワークインターフェイスで通信を制御しますが、対象範囲はルーティング、権限、除外設定、コアの実装によって変わります。TUNは帯域を速くするスイッチではありません。ブラウザーがすでにシステムプロキシを正しく経由しているなら、TUNを有効にするだけでノードの混雑が解消することは通常ありません。

明示的なプロキシ接続で通信制御の問題を切り分ける

まずクライアントの「設定」でポート設定を確認するか、実行設定からmixed-portを探します。以下のコマンドは混合ポートが7890であることを前提としています。実際のポートが7897などの場合は置き換えてください。Windowsではcurl.exe、macOSとLinuxではcurlを使います。例では公開テスト用ドメインにのみアクセスし、大容量ファイルの速度は測定しません。

curl --proxy http://127.0.0.1:7890 -o /dev/null -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Windowsでは、上記のコマンドのcurlをcurl.exeに、/dev/nullをNULに置き換えます。各時間はリクエスト開始からの経過時間です。ローカルプロキシを使う場合、time_connectが主に示すのはローカルプロキシへの接続時間であり、ノードへの往復遅延ではありません。first_byteには接続先サーバーの処理時間も含まれます。

  • 明示的なプロキシでは正常だが、アプリでは遅い：アプリがシステムプロキシを使っているか、独自のプロキシ設定があるか、新しいリクエストが「接続」画面に表示されているかを確認します。
  • TUNを使うときだけ問題が起きる：サービスモードや管理者権限、ルートの競合、DNSの制御状態を確認します。まずクライアントの関連設定をデフォルトに戻し、1項目ずつ比較してください。
  • 動画やリアルタイムアプリだけ問題が起きる：アプリによってはQUICなどのUDPプロトコルを使います。HTTPプロキシでのテストが正常でも、UDPの経路が正常とは限りません。ノードとクライアントが該当する通信に対応し、許可していることも確認してください。

最初からMTUを適当に変えたり、IPv6を無効にしたり、DNSを一式置き換えたりしないでください。特定のネットワークで大きなパケットが止まる、特定の種類のアドレスへの接続が繰り返し失敗するといった、再現可能な根拠がある場合に限り、その項目を詳しく調べましょう。端末性能が気になる場合は、タスクマネージャーやアクティビティモニタで、ダウンロード中にコアのプロセスが論理コア1つを使い切っていないか、ルーターが大量の接続を同時に処理していないかを確認します。

7. 調査結果を記録し、根拠に沿って次の手順を決める

調査が終わったら、再現に必要な最小限の条件を記録しましょう。条件や説明のない速度テストのスクリーンショットを何十枚も保存する必要はありません。以下の項目があれば、問題の範囲を判断しやすくなり、サブスクリプションの提供元やクライアントの開発者にも状況を伝えやすくなります。

  • 環境：OS、クライアント名、クライアントとコアのバージョン。「バージョン情報」や起動ログから実際の値を確認します。
  • 経路：固定回線またはテザリング、テスト時刻、ノードの識別名、接続先ドメイン。アカウント情報を公開しないでください。
  • 設定：RuleまたはGlobal、システムプロキシまたはTUN、対象に適用されたルールと最終的な出口。
  • 結果：各条件で3回テストした際の待ち時間と安定速度、ノードやネットワークを変えた後に改善したかどうか。

ログを提出する場合は、ログレベルを一時的に上げて1回だけ問題を再現し、その後は通常のレベルに戻してください。共有前にサブスクリプションのトークン、ノードのパスワード、個人のIPアドレス、アクセス履歴を隠します。基本操作については、Clash 設定ガイドのプロキシモード、ルール分岐、TUNの各項目を参照してください。初回接続がまだの場合は、まず利用ガイドに沿って設定が有効になっていることを確認してから、速度を比較しましょう。