Clashの通信速度が遅いときの原因と対処法｜ノード・経路・端末設定を3段階で確認

測定条件をそろえ、遅延と通信速度を分けて確認する

Clashのノード横に表示される遅延時間は、1回の疎通確認にかかった時間です。継続的なダウンロード速度を示すものではなく、動画サイト、コードリポジトリ、Webサイトで同じ経路が使われるとも限りません。「遅延は80ミリ秒なのに、ダウンロード速度は200 KB/s」といった場合は、まず実際の接続状況を記録し、どの層を調べるか判断しましょう。

この記事では、mihomoカーネルを使うクライアントのTUN設定を扱います。従来のClashカーネルやクライアントによって、利用できる項目は異なります。作業前にクライアントの「バージョン情報」または「カーネル」画面で、クライアント名、バージョン、カーネルのバージョン、現在の設定名を記録してください。別のカーネルの設定項目をそのままコピーするのを防げます。

再現可能な基準条件を設定する

1. クラウドストレージの同期、OSの更新、ほかの大容量ダウンロードを一時停止します。可能ならPCを有線LANに接続し、Wi-Fiの場合は場所と周波数帯を固定します。
2. 安定した直接接続先を1つ、プロキシが必要な接続先を1つ選びます。同じファイル、同じ測定時間でテストし、測定のたびにサーバーを変えないでください。
3. ルールモードとプロキシグループは変更せず、ノードを手動で選びます。各条件で3回、1回あたり30秒間測定し、中央値を記録します。
4. 読み込み開始までの時間、安定時のダウンロード速度、接続の切断有無に加え、接続パネルに表示されるルール、プロキシグループ、最終ノードを記録します。

以下は記録方法の例であり、特定のサービスを実測した結果ではありません。実際の調査では、同じ端末、同じテスト対象で得た結果を記入してください。

第1段階：ノードと実際の出口を確認する

接続パネルを確認してからノードを切り替える

クライアントの「接続」パネルで、ダウンロード中のリクエストを探します。接続先のドメイン、適用されたルール、プロキシチェーン、出口ノードを確認してください。プロキシグループのノードを変更しても、すでに確立された接続の出口は変わらないことがあります。ブラウザーの長時間接続、動画再生、ダウンロードが古い接続を使い続ける場合もあります。

切り替えるたびにテストを停止し、再度実行してください。必要な場合は、テストに該当する接続だけを閉じます。リモートデスクトップや会議の最中に、すべての接続を切断しないでください。パネルに DIRECT と表示される場合、選択したプロキシノードの速度が原因ではありません。まずルールの適用状況を確認してください。

• 特定のノードだけ遅い：同じプロキシグループ内のノードを2～3個比較します。1つのノードだけ継続して遅い場合は、ノードの負荷、速度制限、出口の品質を優先して確認してください。
• 自動選択グループでノードが頻繁に切り替わる：テスト中は手動選択グループを使います。url-testは主に応答遅延を基準にノードを選ぶ機能で、帯域幅の測定とは異なります。
• 特定のサイトだけ遅い：別の接続先でもテストします。サイト側の速度制限、CDNの振り分け、ノードの出口から接続先までの相互接続状況も速度に影響します。

ルールモードとグローバルモードを短時間だけ比較する

接続先が誤って直接接続されている疑いがある場合は、短時間だけグローバルモードに切り替え、GLOBALの出口を明示的に選んでからテスト接続を確立し直します。グローバルモードで改善し、ルールモードでは遅い場合は、ルールモードに戻し、ドメインルール、ルールセットの更新状況、プロキシグループの参照先を確認してください。グローバルモードにしてもノード自体の帯域幅は上がらず、クライアントを経由しない通信がすべて取り込まれるわけでもありません。

速度測定のために、サブスクリプション内のルールをすぐにすべて書き換えるのは避けてください。まず適用されたルールを記録し、クライアントが対応するローカル設定で対象ドメインを修正します。サブスクリプションから生成されたファイルを直接編集すると、次回の更新で上書きされる可能性があります。

第2段階：接続ネットワークと遠隔経路を比較する

ノード名に含まれる地域名だけでは、通信経路全体はわかりません。接続は入口サーバーや中継サーバーを経由し、別の出口から接続先にアクセスする場合があります。クライアントの接続パネルで選択中の出口は確認できますが、サーバー側の中継経路すべてが表示されるとは限りません。

条件を組み合わせてテストし、問題の範囲を絞り込む

1. 同じネットワークでノードを変更：自宅のネットワークは固定し、ノードだけを切り替えます。特定の入口を使うノードだけ遅く、ほかの入口は正常な場合は、遅いノードに共通する特徴を記録します。
2. 同じノードでネットワークを変更：ノードと接続先を固定し、自宅のブロードバンド回線からスマートフォンのテザリングに切り替えます。モバイルデータの消費を抑えるため、大容量通信は事前に停止してください。
3. 同じ組み合わせで時間帯を変更：混雑しにくい時間帯と夜間にそれぞれ再測定します。夜間だけ速度が低下する場合は、接続ネットワーク、入口、中継経路の混雑が考えられます。

ノードAが自宅のネットワークでは遅く、テザリングでは速い一方、ノードBはどちらでも正常なら、「自宅のネットワークからノードAまでの経路」に問題がある可能性が高く、Aのサーバー帯域が不足しているとは断定できません。どちらのネットワークでも全ノードが遅いものの、直接接続のダウンロードは正常な場合は、クライアント、端末上のプロキシ経路、テスト対象の制限を確認してください。

Ping・経路追跡・ダウンロード速度は分けて確認する

プロキシの入口に対するPingや経路追跡でわかるのは、ネットワーク状況の一部です。中継ルーターがICMP応答を制限する場合があります。あるホップでパケットロスが表示されても、後続の宛先に同程度のロスがなければ、そのホップが転送中の通信を破棄しているとは限りません。通常の経路追跡では、暗号化されたプロキシ接続内のサーバー間中継経路も確認できません。

経路の問題を報告する際は、発生日時とタイムゾーン、接続事業者、ノード名、接続先ドメイン、3回分の測定結果、ネットワーク切り替え後の結果を添えてください。遅延一覧の画像だけでは不十分です。ログを共有する前に、サブスクリプションURL、トークン、ノードのパスワード、個人のアクセス履歴を削除してください。

第3段階：システムプロキシ・TUN・端末上の競合を切り分ける

まずローカルの待ち受けポートを確認する

システムプロキシは、システム設定に従うアプリの通信をローカルのHTTPプロキシに渡します。一方、TUNは仮想ネットワークアダプターとルーティングを使って通信を取り込みます。設定によっては両方を同時に使えますが、調査中は入口とルートを同時に変更しないよう、分けてテストしてください。以下では、実際の設定に mixed-port: 7890 がある場合を例にしています。7890はすべてのクライアントで共通の固定ポートではありません。

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

Windows PowerShellで次のコマンドを実行し、ポートが待ち受け状態か確認してから、プロキシを明示してリクエストを送信します。このリクエストは経路と応答時間の確認用で、大容量ファイルの帯域測定には使いません。

Get-NetTCPConnection -LocalPort 7890 -State Listen

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

コマンドに指定するポートは、クライアントで実際に使用しているポートに合わせてください。ここでの time_connect は主にローカルプロキシへの接続時間を示すもので、ノードへの往復遅延ではありません。time_starttransfer には、その後のプロキシ接続、TLS、サーバー応答などの時間が含まれます。特定の項目をDNSの問題と決めつけず、同じリクエストでの変化を比較してください。

システムプロキシ、TUNの順にA/Bテストする

1. TUNを無効にしてシステムプロキシだけを有効にし、HTTPプロキシに対応したブラウザー、または上記のコマンドでテストします。
2. 結果を記録してからシステムプロキシを無効にし、TUNを有効にします。同じ接続先への接続を確立し直し、接続パネルに該当するリクエストが表示されていることを確認してください。
3. TUNだけが遅い場合は、ほかのVPN、通信高速化ソフト、仮想ネットワークアダプター用ツールが同時に動作していないか確認します。1つずつ一時停止して再測定し、複数のセキュリティ機能をまとめて無効にしないでください。
4. TUNが起動しない場合は、まずサービスの権限、仮想ネットワークアダプター、ルート作成のエラーを解消します。起動できない問題と通信速度が低い問題は別々に扱ってください。

mihomoのTUNスタックには system、gvisor、mixed があり、利用可否や動作はプラットフォームとカーネルのバージョンによって異なります。mixedは通常、TCPにsystem、UDPにgVisorを組み合わせます。すべての端末に共通する「最速のスタック」はありません。設定は1項目ずつ変更し、関連するカーネルを再起動してから、同じタスクで再測定してください。

DNSとUDP：ページ表示の遅さ、ダウンロードの遅さ、動画の途切れを切り分ける

最初の表示が遅い場合は、まず名前解決を確認する

初回アクセス時に数秒止まり、再読み込みするとすぐ表示される一方、ファイルのダウンロード開始後は速度が正常な場合は、名前解決のタイムアウトと接続確立の処理を優先して確認します。ログにDNSタイムアウトが繰り返し記録されていないか、接続先ドメインについて異なるリゾルバーが大きく異なるCDNアドレスを返していないかを調べます。ブラウザーのキャッシュや接続の再利用でも2回目が速くなるため、この現象だけでDNS障害とは判断できません。

enhanced-mode: fake-ipは仮想アドレスとの対応付けでドメイン識別を補助する機能であり、ノードの帯域幅を直接増やすものではありません。nameserver-policyは特定ドメインに使用するリゾルバーを指定する設定で、出口を選ぶプロキシグループではありません。変更時は、リゾルバーに接続できるか、返されるアドレスが現在の出口に適しているか、DNSリクエストが実際にどの経路を通るかも確認してください。

• ブラウザーのセキュアDNSは独自のDoH経路を使用し、システムDNSを経由しないことがあります。診断時は設定状態を記録し、必要なら短時間だけ無効にして比較してください。確認後は元の設定に戻します。
• TUNの dns-hijack は従来の53番ポートへのリクエストを取り込む用途でよく使われますが、すべてのDoH・DoT通信が取り込まれるとは限りません。
• fake-ipモードと実アドレスによる名前解決を切り替えた後は、クライアントが対応する方法で関連するDNSキャッシュを消去し、テスト接続を確立し直してください。古いアドレスが結果に影響するのを防げます。

動画が途切れる場合はUDPとQUICを確認する

Webページやダウンロードは正常なのに、動画、音声通話、ゲームに問題がある場合は、UDPを個別に確認します。ブラウザーはUDPベースのQUICを使うことがあり、ノードとサーバー側が該当する転送経路に対応している必要があります。クライアントの接続パネルでUDPリクエストの有無を確認し、クライアントまたはブラウザーで可能な方法を使って、一時的にQUICを無効にして比較します。TCPに切り替わった後の変化を確認してください。

切り替え後に改善しても、UDP経路をさらに調べる必要があることを示すだけで、すべてのUDP通信を常時遮断すべきという意味ではありません。同様に、IPv6を無効にすることを万能の高速化策と考えないでください。AAAAレコードの応答、IPv6のデフォルトルート、プロキシによる通信の取り込み状況を確認してから、必要に応じてアドレスファミリーを一時的に制限してテストします。

根拠をもとに原因を絞り込み、元に戻せる設定を保つ

3段階の比較が終わったら、問題の範囲をできるだけ絞り込みます。以下の対応は次の調査を決めるための目安であり、サーバー側やネットワーク側の詳しい診断に代わるものではありません。

元の設定を残すかバックアップをエクスポートし、変更した項目、日時、結果を記録してください。更新後に問題が起きた場合は、まず該当項目を元に戻して改善するか確認し、その後でクライアントやカーネルの更新を検討します。作業が終わったら、普段使うルールモード、必要なセキュリティ設定、ログレベルに戻し、一時的なテスト設定を使い続けないようにしてください。