Clashの速度が遅いときの対処法：ノード・回線・端末設定を3段階で確認

まず「遅い」箇所を特定する

Clashでは接続済みと表示されているのに、ウェブページの表示が遅い、動画が頻繁にバッファリングする、ダウンロード速度が低いという場合、必ずしもノードの性能が原因とは限りません。接続経路には、端末上のアプリ、Clashのコア、DNS名前解決、プロキシノード、通信事業者の回線、接続先のウェブサイトが含まれます。どこか一箇所で混雑が起きると、iPhoneでは「Clashを有効にすると遅くなる」ように見えることがあります。

調査前に条件を固定します。同じWi-Fi、同じ速度測定サイト、同じブラウザー、同じプロキシノードを使い、各テストは少なくとも30秒続けて、3回連続で実施してください。ノードとネットワークを同時に切り替えると、改善の原因を判断できません。

4種類の基準値を記録する

テスト条件	記録する項目	判断できること
Clashを無効にして直結	ダウンロード、アップロード、最初の1バイトまでの時間	自宅回線またはモバイル回線の上限
Clashを有効化、ルールモード	同じ測定サイトでの3回分の結果	普段の設定での実際の性能
Clashを有効化、グローバルモード	同じノードでの結果	ルールによる振り分けで出口を誤選択していないか
同じノードでネットワークを切り替え	Wi-Fiとモバイル通信の結果	利用する通信事業者による回線差

たとえば、直結時のダウンロード速度が280 Mbpsで、プロキシ経由では安定して85 Mbpsになるなら、ボトルネックはプロキシ経路またはノードにあります。直結時が18 Mbpsしかない場合、プロキシを使っても現在の接続回線の上限を超えることは通常できません。速度測定は正常なのにウェブページの初回表示に3〜5秒かかるなら、帯域幅のテストを続けるより、まずDNSを確認すべきです。

第1段階：ノードの負荷とプロトコルを確認する

まずClashのプロキシグループ画面で、現在実際に選択されているノードを確認します。「自動選択」や「フェイルオーバー」のプロキシグループを使っている場合、ホーム画面に表示されるグループ名は最終的な出口ノードを意味しません。「プロキシ」または「ポリシー」画面を開き、該当するプロキシグループを展開して、選択中の具体的なノードを確認してください。

固定ファイルで継続スループットを測定する

現在のノードを固定し、実行中のクラウド同期、システムアップデート、動画再生を停止します。
繰り返しアクセスできる100 MB〜500 MBのテストファイルを選び、30秒後の安定した速度を確認します。
2分待ってから同じテストを2回繰り返し、最低値、中央値、最高値を記録します。
DNS、ルールモード、ローカルネットワークは変更せず、ノードだけを切り替えて同じテストを行います。

あるノードの3回の結果が72 Mbps、69 Mbps、74 Mbpsなら、比較的安定しています。一方、8 Mbps、91 Mbps、17 Mbpsのように大きく変動する場合は、ノードの負荷、上流帯域の共有、パケットロスがよくある原因です。この場合、端末側のルールを調整しても大きな効果は通常ありません。

ノードのプロトコルと端末性能

プロトコルごとに暗号化、カプセル化、転送方式が異なり、CPU使用量も変わります。新しいiPhoneなら、一般的なShadowsocks、Trojan、VLESS、WireGuardの通信は通常問題なく処理できますが、古い端末では高帯域、複雑な暗号化、長時間の発熱によって処理性能が低下することがあります。テスト中にiOSの「設定」→「バッテリー」を開き、Clashクライアントの電池使用量が継続的に高くなっていないか、端末が明らかに発熱していないかを確認してください。

単一のノードだけ遅い：まずノードの負荷、出口、またはノード設定の問題を疑います。
同じ地域のノードがすべて遅い：その地域の入口、出口、または通信事業者間接続の混雑が考えられます。
すべてのプロトコルが遅い：中間経路とローカルネットワークを引き続き確認します。
特定のプロトコルだけ遅い：そのプロトコルの転送パラメーター、UDP対応、サーバー設定を確認します。

第2段階：ノードと中間経路の問題を切り分ける

iPhoneからプロキシノードまでの間には、自宅のルーター、ブロードバンド事業者、モバイルネットワーク、異なるネットワーク間の接続が存在します。ノード自体が空いていても、端末からノードまでの経路が快適とは限りません。最も簡単な切り分け方法は、ノードを固定したまま接続ネットワークだけを切り替えることです。

Wi-Fiとモバイル通信を相互にテストする

Wi-Fi接続で固定ノードを1つ選び、遅延とダウンロードのテストを3回行います。
Wi-Fiを無効にして4Gまたは5Gを使用し、同じノードをテストします。
モバイル通信のほうが明らかに速い場合は、ONUとルーターを再起動し、ブロードバンド回線の夜間ピーク時の状況を確認します。
Wi-Fiのほうが速い場合は、モバイル通信の電波強度、通信速度制限、現在接続している基地局の負荷を確認します。

たとえば、同じノードが自宅のWi-Fiでは遅延240 ms、ダウンロード12 Mbps、5Gでは遅延96 ms、ダウンロード83 Mbpsなら、ノード全体の障害ではなく、自宅回線からそのノードまでの経路に問題がある可能性が高いです。逆に、両方のネットワークで約10 Mbpsに安定し、直結時はそれぞれ200 Mbpsと150 Mbpsに達するなら、ノード側の制限がより疑われます。

夜間ピークと継続的なパケットロスを見分ける

回線の混雑は現地時間の20:00〜23:00に集中することがあります。午前、午後、夜間に同じテストを1回ずつ行ってください。昼間は安定しているのに夜間だけ急に低下するなら、設定を頻繁に変更するより、まず入口の地域や異なる通信事業者の経路を切り替えるほうが効果的です。

遅延がときどき80 msから180 msに跳ね上がっても、ダウンロードに影響しない場合があります。しかし数秒おきにタイムアウトが発生するなら、動画、音声通話、ゲームで途切れやすくなります。一部のクライアントは成功したリクエストの遅延しか表示しないため、タイムアウトするノードでも正常な数値に見えることがあります。接続ログにtimeout、connection reset、context deadline exceededが連続して出ていないかも確認してください。

自宅のルーターとWi-Fiを確認する

混雑しやすい2.4 GHz帯を避け、5 GHzまたは6 GHzのWi-Fiを優先します。
ルーターの近くで再測定し、壁による遮蔽や弱い電波による再送の影響を除外します。
重複処理を避けるため、ルーターの二重プロキシ、ペアレンタルコントロール、トラフィックシェーピングを一時的に無効にします。
同一LAN上の端末が写真をアップロードしたり、クラウドストレージを同期したり、大型アップデートをダウンロードしたりしていないか確認します。
ルーターとiPhoneの両方でプロキシを動かしている場合は、通信が二重転送されないよう、テスト中は一方だけを有効にします。

第3段階：Clashのローカル設定を確認する

複数のノードと複数の接続ネットワークで速度が低い場合は、Clashのローカル設定を確認します。重要なのは一度に10個のスイッチを変更することではなく、毎回1項目だけ変更して再測定し、維持するか判断することです。

まずルールモードとグローバルモードを比較する

クライアントの「プロキシ」または「モード」画面で、Ruleを一時的にGlobalへ切り替え、同じノードでテストします。Globalモードで明らかに速くなるなら、ルールモードで速度測定ドメインがDIRECTに振り分けられている、別のプロキシグループが選ばれている、または不適切なルールに一致している可能性があります。テスト後はRuleに戻し、接続ログでルールの一致結果を確認してください。

ルールは上から順に照合され、一致するとそこで処理が終わります。ドメインルール、ルールセット、GEO系ルールの順序が適切でないと、接続先のウェブサイトが誤った出口を通ることがあります。ダウンロードサイトのドメインは直結なのに、リソースドメインだけプロキシ経由になっていると、ページは正常に開くのにファイルのダウンロードだけ遅くなることもあります。

高頻度のヘルスチェックを整理する

ノードのヘルスチェックが帯域幅を直接使い切ることはありませんが、数が多く間隔が短いと、ネットワーク拡張を繰り返し起動して余分な接続を発生させます。80ノードを含むプロキシグループで30秒ごとにチェックすると、1時間に最大9600件のリクエストが発生する可能性があります。普段の利用ではintervalをまず600秒にし、ルールプロバイダーの更新間隔は86400秒に設定できます。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - ノード A
      - ノード B
      - ノード C
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

rule-providers:
  common:
    type: http
    behavior: classical
    path: ./ruleset/common.yaml
    url: https://example.com/rules/common.yaml
    interval: 86400

テスト先は、安定して応答し、返却内容が小さく、現在のネットワークからアクセスできるURLを選びます。複数の大規模なプロキシグループに30秒または60秒間隔のチェックを同時に設定しないでください。クライアントに「設定」→「パラメーター設定」→「ヘルスチェック」という項目がある場合は、使用していないプロキシグループの自動テストを先に無効にします。

TUNモードとMTUを確認する

TUNモードはより多くのシステム通信を引き受けるため、透過プロキシが必要なアプリに適しています。ただし、MTUが不適切だとフラグメント化や再送が発生し、一部のウェブサイトの読み込みが遅くなることがあります。一般的なテスト値は1500、1400、1280です。複数の値を一度に飛ばさず、まず現在の設定を記録して1400に変更し、再測定します。問題がモバイル通信または特定のWireGuard経路だけで発生する場合は、1280も試してください。

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  strict-route: false

この書式はClash.Metaまたはmihomoの設定構文に対応するクライアント向けです。旧バージョンのClashコアでは、すべてのフィールドに対応していない場合があります。iOSクライアントでは、これらの項目がグラフィカルな「設定」→「パラメーター設定」→「TUN」に配置されていることもあります。変更後はシステムVPNを切断して再接続し、ネットワーク拡張に設定を再読み込みさせてください。

二重プロキシになっていないか確認する

iOSでは通常、同時にアクティブにできる主要なVPN構成は1つだけですが、ブラウザーのプロキシ、ルーターのプロキシ、Clashによって多層転送が発生することがあります。iOSの「設定」→「一般」→「VPNとデバイス管理」→「VPN」を開き、想定しているクライアントが接続中か確認します。続いて「設定」→「Wi-Fi」→現在のネットワーク→「プロキシを構成」を開き、普段Clashに通信を任せる場合は通常「オフ」にします。

DNSの遅さと帯域幅の遅さを分けて対処する

DNSは主にドメイン名の解決と初回接続に影響します。URLを入力してから数秒待たされる一方、読み込みが始まると画像や動画は正常な速度になるのが典型例です。大容量ファイルのダウンロード開始後も長時間数百KB/sしか出ないなら、DNSだけを変更しても継続的な帯域幅のボトルネックは通常解消しません。

IPアドレスとドメイン名の挙動で判断する

すべてのウェブサイトで初回表示が遅く、更新すると速くなる：まずDNSのタイムアウトとキャッシュを確認します。
特定のドメインだけ遅い：そのドメインに適用されたルール、IPv6の結果、CDN経路を確認します。
速度測定サイトの遅延は正常なのにダウンロードが遅い：ノードと回線の層に戻って調査します。
ログにDNS timeoutが繰り返し出る：到達可能なnameserverへ切り替え、リッスンアドレスを確認します。

mihomo構文に対応する設定では、まずシンプルなDNS設定を1組だけ使って比較できます。以下の例ではfake-ipを有効にし、明示した2台のDNSサーバーを主解析に使用し、fallbackを過剰に重ねない構成にしています。パブリックDNSへの到達性はネットワークによって異なるため、現在の地域で実測した結果を優先してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 223.5.5.5
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

1053はClashのDNSでよく使われるローカルリッスンポートの例であり、外部DNSサービスのポートではありません。クライアントがDNSを自動管理している場合は、別のローカルサービスに同じポートを使わせないでください。変更前に「設定」→「パラメーター設定」→「DNS」で現在の値を保存し、テスト後の結果に応じて戻すか判断します。

IPv6を個別にテストする

ネットワークによってはAAAAレコードを返しても、実際のIPv6経路の品質が低く、ウェブサイトがまず待機した後にIPv4へフォールバックすることがあります。dns.ipv6を一時的にfalseにして比較してください。無効化後に初回表示が明らかに改善するなら、ローカルIPv6、ノードのIPv6対応、接続先サイトのIPv6経路を引き続き確認すべきであり、すべての問題をノードのせいにすべきではありません。

結果に応じて次の対処を選ぶ

3段階のテストが終わったら、比較データに基づいて対処し、設定を無作為に切り替え続けないでください。以下の対応表で原因の範囲をすばやく絞り込めます。

テスト結果	考えられる原因	次の手順
1つのノードだけ遅い	ノードの負荷または出口の異常	同じ地域の別ノードへ切り替え、サーバー側に報告する
Wi-Fiは遅く、モバイル通信は速い	自宅のブロードバンド回線またはルーター経路	ネットワーク機器を再起動し、周波数帯を変更して別の入口を試す
ルールモードは遅く、グローバルモードは速い	ルールの一致またはプロキシグループの選択ミス	接続ログを確認し、ルールの順序を調整する
初回表示は遅いが、継続ダウンロードは正常	DNSまたはIPv6からのフォールバック	DNS設定を整理し、IPv4とIPv6を個別にテストする
TUNを有効にすると一部のウェブサイトが遅い	MTU、フラグメント化、プロトコルの互換性	1400と1280を試し、VPNを再接続する
すべてのネットワークとノードが遅い	ローカル設定、端末負荷、またはサブスクリプション設定	最小構成の設定を読み込み、切り分けテストを行う

最小構成で最終的な切り分けを行う

問題の原因を特定できない場合は、ノード1つ、プロキシグループ1つ、ルール2つだけを含む一時的な設定を作成します。リッスンポートには一般的な7890を使い、スクリプト、ルールプロバイダー、トラフィックのスニッフィング、追加のヘルスチェックを無効にして、必要な機能だけを残します。最小構成で正常なら、元の設定に競合または余分な負荷があります。最小構成でも遅い場合は、ノード、回線、端末の層に戻って対処してください。

mixed-port: 7890
mode: rule
log-level: info
ipv6: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - テストノード

rules:
  - MATCH,PROXY

テスト後、一時的な設定をそのまま長期運用に使わないでください。これは変数を切り分けるためのもので、日常利用に必要な直結、LAN、プライバシー、アプリごとの振り分けルールは含まれていません。元の設定で問題が起きる範囲を確認したら、DNS、ルールセット、TUN、ヘルスチェックをグループごとに戻し、項目を1つ復元するたびに同じテストを行います。

調査でよくある3つの誤解

ノードの遅延だけを見る

遅延は接続できないノードや応答が明らかに遅いノードを除外するのには役立ちますが、帯域幅、パケットロス、夜間ピーク時の負荷は示しません。少なくとも30秒以上続けるダウンロードテストを1回は追加してください。

DNS、MTU、ルールを同時に変更する

複数項目を一度に変更すると、速度が戻ってもどの変更が効いたのか分かりません。正しい方法は、元の設定を保存し、毎回1つの変数だけを変更して、変更前後の3回分の結果を記録することです。

グローバルモードを常用の高速化スイッチにする

グローバルモードは比較テストに適していますが、より多くの通信を同じプロキシに通すだけで、自然に速くなるわけではありません。ルールの一致が原因だと確認できたら、ルールまたはプロキシグループを修正し、Ruleモードに戻してください。