MacでClashが遅いときの原因と対処法｜ノード・回線・設定を切り分ける

まず症状を確認：表示が遅い、ダウンロードが遅い、接続が途切れる

Clashに表示されるノードの遅延時間は、ファイルのダウンロード速度とは別の指標です。Webページの表示には、DNSによる名前解決、接続確立、TLSハンドシェイク、データ転送が必要です。どの段階で待ち時間が発生しても「速度が遅い」と感じることがあります。まず症状を特定し、ノード、回線、Macの設定の順に確認しましょう。DNS、ルール、TUNを一度に変更するより、原因を絞り込みやすくなります。

再現可能なテストを行う

1. クラウドストレージの同期、システムアップデート、ほかのダウンロードを一時停止し、同じMac、同じネットワーク、同じファイルを使います。
2. 対象のリクエストで使われるプロキシグループを手動選択にし、ノードを固定してテスト中の自動切り替えを防ぎます。
3. 各条件で3回続けてテストし、日時、ノード、ネットワークの種類、プロキシ方式、結果を記録します。初回はキャッシュの影響を受ける可能性があるため、別に記録してください。
4. 一度に変更する項目は1つだけにします。テスト後は設定を元に戻し、同じ結果を再現できるか確認します。

第1段階：ノードの品質と実際のプロキシ出口

まずクライアントの接続一覧を開き、アクセス中のドメインについて、適用されたルール、プロキシグループ、最終的に選択されたノードを確認します。画面上で特定のノードを選んでいても、すべてのリクエストがそのノードを経由するとは限りません。ルールが別のプロキシグループを指定していたり、DIRECTに一致していたりする場合があります。画面やメニューの名称はクライアントによって異なるため、現在使っているクライアントの接続詳細を確認してください。

ノードを固定して自動切り替えを防ぐ

url-testは設定されたテスト結果に応じてノードを選択し、fallbackは優先順位に沿って利用可能なノードを選択します。load-balanceはポリシーに基づいて接続を振り分けます。原因を調べるときは、まず手動選択のグループを使い、テストするリクエストの出口を固定してください。ノードを切り替えても、確立済みの長時間接続は新しいノードに引き継がれないことがあります。リクエストを再実行し、必要であれば対象アプリの古い接続だけを終了してください。

• 特定のノードだけ遅い：ノードの負荷、帯域制限、上流の通信経路が原因の可能性があります。別のノードに切り替えて再テストしてください。
• 同じ地域の複数ノードが遅い：地域や接続入口、プロバイダーの異なるノードも比較してください。ノード名だけでは回線が独立しているか判断できません。
• すべてのノードで特定のWebサイトだけ遅い：接続先の速度制限、CDNの割り当て、アカウントの状態、出口IPに対するアクセス制限を確認してください。

遅延時間とスループットを区別する

遅延時間が短いと操作の応答性は高まりますが、ダウンロード速度は回線の混雑、パケットロス、利用可能な帯域幅、接続先サーバーの処理能力にも左右されます。遅延時間が短いノードでも、大きなファイルのダウンロードが遅いことがあります。テストには、合法的にアクセスできる同じファイルを使ってください。異なるWebサイトのダウンロード結果をそのまま比べたり、数KBしかないページで帯域幅の上限を判断したりしないでください。

単位にも注意してください。ダウンロードツールのMB/sと、回線の公称速度に使われるMbpsは異なります。十進法で換算すると、10 MB/sは約80 Mbpsです。実際のアプリではプロトコルのオーバーヘッドも発生します。これは単位換算であり、ノードの速度を保証するものではありません。

第2段階：ローカルネットワークからノード、ノードから接続先までの回線

プロキシ接続には、少なくともMacからプロキシの入口までと、プロキシの出口から接続先サービスまでの2つの経路があります。ノードを切り替えると、その両方の一部が変わるため、ローカルの接続ネットワークも切り替えて比較してください。ノードと接続先を変えずに、短時間だけスマートフォンのテザリングでテストします。テザリングで明らかに改善する場合は、元のWi-Fi、ルーター、または回線事業者までの経路に原因がある可能性が高くなります。

curlでリクエストがプロキシ経由か確認する

ターミナルのツールがmacOSのシステムプロキシを使うとは限りません。以下のコマンドでは、ローカルのHTTPポートまたは混合ポートを明示し、各段階の所要時間を出力します。例では127.0.0.1:7890を使用しています。実行前に、クライアントで現在待ち受けているポートを確認してください。入力するURLには、ダウンロードが許可された適度なサイズのHTTPSファイルを指定します。署名付きURLやサブスクリプションURLは、公開ログに貼り付けないでください。

printf 'テストファイルのHTTPS URLを入力してください：'
read -r TEST_URL
curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --location --output /dev/null --silent --show-error \
  --connect-timeout 10 --max-time 60 \
  --write-out 'status=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\nbytes=%{size_download}\nspeed=%{speed_download} B/s\n' \
  "$TEST_URL"

speed_downloadの単位はバイト毎秒です。time_starttransferはリクエスト開始から最初の1バイトを受信するまでの累積時間で、サーバーの処理時間だけを示すものではありません。ローカルHTTPプロキシ経由でHTTPSにアクセスする場合、time_connectが示すのは主にローカルプロキシへの接続時間です。リモートノードまでの遅延時間として扱うことはできません。以降のプロキシトンネルやTLSの段階には、リモートまでの経路の影響も含まれます。

接続先が直通接続を許可している場合は、プロキシオプションを--proxy "" --noproxy "*"に置き換えて比較できます。ただし、これで無効になるのはcurlの明示的なプロキシだけです。TUNが有効な場合、リクエストは引き続きルーティングの対象になる可能性があります。直通接続を正確に比較するには、先にTUNを無効にし、ほかのVPNが通信を引き継いでいないことも確認してください。

時間帯ごとの混雑を確認する

同じノードでも日中は正常で夜間に継続して遅くなり、有線接続とWi-Fiでほぼ同じ結果になる場合は、共有回線の混雑を確認しましょう。2つの時間帯でそれぞれ3回測定して記録すると、1回だけの測定より参考になります。プロキシサーバーへのpingで得られる情報には限りがあります。サーバーがICMPを制限している可能性があり、ICMPの経路や優先順位が実際のプロキシ接続と異なることもあります。

第3段階：システムプロキシ、ルール、Macの負荷

比較的新しいmacOSでは、「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」から、HTTP、HTTPS、SOCKSの設定を確認できます。項目名はmacOSのバージョンによって多少異なります。プロキシのアドレスがローカルの待ち受けアドレスであること、ポートがクライアントの設定と一致することを確認し、以前使っていたクライアントの設定が残っていないか調べてください。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
scutil --proxy

ネットワークサービス名を変更している場合や、USB Ethernetを使っている場合は、コマンド内のWi-Fiを最初のコマンドに表示された実際のサービス名に置き換えてください。出力にある有効状態、サーバーアドレス、ポートを確認します。クライアントのスイッチの色だけで、システム設定が書き込まれているか判断しないでください。

複数プロキシとルールの誤適用を確認する

• ブラウザーのプロキシ拡張機能がシステムプロキシを上書きしていることがあります。テスト中は拡張機能を無効にするか、拡張機能が使っている出口を明確にしてください。
• TUN、VPN、通信フィルタリング機能を持つツールを同時に使うと、ルーティングが競合することがあります。テストでは通信を引き継ぐ方式を1つだけ有効にしてください。
• 特定のドメインだけ遅い場合は、接続一覧でそのドメインが意図せずリモートプロキシ経由になっていないか、プロキシ経由にするはずの通信が直通ルールに一致していないか確認してください。
• 「アクティビティモニタ」を開き、CPUとネットワークの使用状況を確認します。クライアントやほかのプロセスが継続してリソースを消費している場合は、負荷の高いバックグラウンド処理を停止してから同じリクエストを再テストしてください。

Clashはコアやクライアントのエコシステムで使われる名称であり、すべてのGUIクライアントが同じオーバーライド、ログ、サービスモードを備えているわけではありません。mihomoを使うクライアントでも、権限管理や設定のマージ方法が異なることがあります。変更前に、サブスクリプションの元のYAMLだけでなく、実際に適用されている設定を確認してください。各フィールドの意味はYAMLマニュアルも参照してください。

DNSモード：初回表示の遅さや名前解決の問題を調べる

DNSの問題は、初回の表示が遅い、一部のドメインに接続できない、ブラウザーとコマンドラインで結果が異なるといった症状として現れます。mihomoのfake-ipモードはドメインに対応するマッピングアドレスを割り当て、redir-hostモードは実際の名前解決結果を使用します。単純に「速い」「遅い」で選べるものではなく、アプリ、ルーティングの引き継ぎ方式、DNS設定との相性によって適切なモードが異なります。

まず名前解決の経路を確認する

1. scutil --dnsを実行して、現在のシステムリゾルバーと適用範囲を確認します。VPNやネットワークインターフェースごとに別のリゾルバーが設定されている場合があります。
2. ブラウザーで独自のセキュアDNSが有効になっているか確認してください。ブラウザーで名前解決できても、システムやクライアント内蔵のDNSが正常とは限りません。
3. クライアントのログで、名前解決のタイムアウト、上流DNSへの接続失敗、再試行の繰り返しがないか確認します。上流DNSへの接続に、まだ確立されていないプロキシが必要な場合、起動時の依存関係の問題が発生することがあります。
4. 影響のあるドメインを1つだけ選んで繰り返しテストし、ネットワークを切り替える前後で結果を比較します。上流DNSとモードを一度にすべて変更しないでください。

HTTPプロキシ経由でHTTPSにアクセスする場合、接続先のドメイン名は通常プロキシ側で解決できます。そのため、curlで測定したローカルの名前解決時間だけでは、接続先ドメインのDNS性能を判断できません。同様に、digが標準でテストする名前解決経路も、ブラウザー、システムの名前解決API、mihomo内部の名前解決経路と同じとは限りません。

TUNスタックとWi-Fiの省電力設定：1項目ずつ検証する

TUNスタックの選択とルーティングを確認する

TUNは仮想ネットワークインターフェースを使ってIP通信を引き継ぐ機能であり、ノードの帯域幅を直接増やすものではありません。mihomoのスタックにはsystem、gvisor、mixedがあります。利用可否やデフォルト値は、クライアントに同梱されているコアとそのドキュメントで確認してください。スタックによってプロトコルの処理方法、互換性、リソース消費量が異なり、すべてのMacに共通する最適な設定はありません。

まず現在のスタックを記録し、スタックの選択肢だけを変更します。クライアントの手順に従ってTUNを再度有効にするか、コアを再起動し、同じリクエストを再テストしてください。以下は比較するフィールドの例であり、完全な設定ではありません。既存のTUN、DNS、ルーティング、権限設定を上書きしないでください。

tun:
  enable: true
  stack: system

明示的なHTTPプロキシでは正常で、TUNでは異常が起きる場合は、ルーティングループ、DNSの引き継ぎ、ほかのネットワーク拡張機能を重点的に確認してください。最初からMTUを安易に変更しないでください。特定の接続先で大きなパケットの転送が止まる、ハンドシェイク後に応答がなくなるなどの根拠がある場合に限り、コアのドキュメントに従ってMTUだけを変えて比較します。自動ルーティングを有効にする前に、LAN機器や業務用VPNへのアクセスが必要かどうかも確認してください。

Wi-Fiの電波障害と低電力モードを切り分ける

Macの低電力モードは「プロキシの速度制限スイッチ」ではなく、有効にしただけでClashのダウンロードが遅くなると決まるわけではありません。テスト項目の1つとして確認できます。「システム設定」→「バッテリー」で低電力モードの状態を確認し、電源アダプターを接続したうえで、同じ場所、同じノードで結果を記録します。項目名や利用できる設定は機種やmacOSによって異なります。1回の変更だけで原因を断定しないでください。

• Optionキーを押しながらメニューバーのWi-Fiアイコンをクリックすると、システムが示す信号強度、ノイズ、通信速度を確認できます。これらは無線区間の指標であり、インターネットのダウンロード速度そのものではありません。
• ルーターに近づいて再テストし、可能であれば有線接続とも比較します。有線では正常でWi-Fiだけに問題がある場合は、電波の強さ、干渉、ローミングを優先して確認してください。
• 5 GHzと2.4 GHzのネットワークを個別にテストします。壁が多い環境では5 GHzのほうが安定するとは限りません。実際に使う場所で繰り返し測定し、結果を比べてください。
• スリープから復帰した後にだけ遅くなる場合は、Wi-Fiに再接続してからクライアントのプロキシとTUNの状態を確認してください。問題を覆い隠すために何度も再インストールしないでください。

結果の分類と設定の復元

トラブルシューティングのゴールは、「いろいろ設定を変えた」ではなく、再現できる結論を得ることです。たとえば「同じノードとファイルでは有線は正常だが、Wi-Fiでは継続して遅い」と分かれば、無線ネットワークに重点を絞れます。「TUNを無効にすると明示的なプロキシ接続は正常」という結果なら、Mac側の通信引き継ぎ経路まで原因を絞り込めます。結論が具体的であるほど、その後の対応で推測に頼らずに済みます。

1. ノードの問題：出口を変更し、発生時刻、ノード、接続先の情報を添えてサービス提供元に問い合わせます。アカウント情報、サブスクリプションURL、認証情報は伏せてください。
2. 回線の問題：接続ネットワークや時間帯ごとの比較結果を残し、ローカル回線の混雑と、出口から接続先までの問題を切り分けます。
3. Mac側の問題：効果を確認できた変更だけを残し、一時的に変更したスタック、DNS、プロキシグループ、省電力設定は元に戻します。
4. 原因を特定できない場合：クライアント名、コアの種類、macOS環境、プロキシ方式、個人情報を伏せたログを共有してください。遅延時間のスクリーンショットだけを送るのは避けましょう。

クライアントを変更すると、GUIの設定や権限の違いを確認できる場合がありますが、サブスクリプションに含まれるノードの容量が自動的に変わるわけではありません。まずボトルネックを特定し、ルールの調整、Mac側の設定修正、出口回線の変更のどれが必要か判断してください。