Clash Apple版のトラブルシューティング

インターネットに接続できない：直通とプロキシを切り分ける

まずプロキシをいったん無効にして、通常の接続を確認します。すぐに再インストールする必要はありません。クライアントのシステムプロキシとTUNをオフにして、アプリを終了してください。iPhoneでは該当するVPNを切断します。普段から直接アクセスできるWebサイトをブラウザーで開き、同じネットワークにつないだ別の端末でも確認します。両方の端末で接続できない場合は、Wi-Fi、ルーター、回線事業者のネットワークを優先して確認してください。現在の端末だけで接続できない場合は、残っているプロキシ設定、ほかのVPN、端末のDNSを確認します。通常接続が復旧するまでは、ノードのテスト結果を比較しても判断材料になりません。

再現可能なローカルネットワークの基準を作る

macOSの「システム設定 → ネットワーク」を開き、現在の接続がWi-FiかEthernetかを確認します。ホテル、空港、大学のネットワークではWeb認証が必要な場合があります。Wi-Fiにつながっただけでは、インターネットを利用できるとは限りません。VPNを一時的に切断して認証を済ませてから、プロキシを再接続してください。システム時刻も正確に設定します。時刻がずれているとTLS証明書の検証に失敗し、Wi-Fiが切れたのではなく、複数のHTTPSサイトで同時にエラーが起きることがあります。

次にプロキシクライアントを1つだけ起動し、TUNはまだ有効にしません。設定が選択され、コアが動作していることを確認してから、システムプロキシを有効にします。複数のアプリがシステムプロキシを書き換えると、すでに終了した別のプロセスのアドレスが残ることがあります。複数のトンネルを同時に有効にすると、どの経路を使っているか判断しにくくなります。仕事で使うVPNを維持する場合も、テスト中は接続状態を記録し、各回で条件を変えないようにしてください。

明示的なプロキシ接続で入口と出口を切り分ける

以下のコマンドで、プロキシを使わない接続と、ローカルHTTPプロキシを指定した接続をそれぞれテストします。どちらもレスポンスヘッダーだけを取得します。ポート7890は例です。クライアントに表示されている実際の混合ポートに置き換えてください。テスト先は、アクセスできることが分かっているWebサイトに変更できます。コマンドが成功しても、その宛先への経路が使えることを示すだけで、すべてのアプリ、UDP、すべてのルールが正常だとは限りません。

# macOS：プロキシ環境変数を無視して直接接続をテスト
curl -I --noproxy '*' --connect-timeout 10 --max-time 20 https://www.apple.com/

# クライアントが実際に待ち受けている混合ポートを指定
curl -I --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 20 https://www.apple.com/

明示的なプロキシ接続ですぐに接続拒否になる場合、問題は通常ローカルの入口にあります。コアが起動していない、ポート番号が違う、または待ち受けに失敗している可能性があります。接続がタイムアウトする場合は、クライアントの接続ログを確認し、どのルールとノードが使われたかを調べてください。明示的なプロキシ接続は成功するのにブラウザーで失敗する場合は、システムプロキシが機能しないの項目を確認してください。接続先ノードを次々に試す必要はありません。直接接続は成功し、プロキシ経由だけ失敗するなら、問題は設定、ルール、接続先まで絞り込めています。

ルール、DNS、トンネルの経路を確認する

一時的にルールモードからグローバルモードに切り替え、正常に動作すると分かっているプロキシノードを選んで、同じ接続先にアクセスします。グローバルモードでは成功し、ルールモードでは失敗する場合は、対象ドメインのルール、ポリシーグループの選択、直接接続の経路を確認してください。テスト後はルールモードに戻します。グローバルモードで変わるのは通信の振り分け方です。システムプロキシを使わないアプリが自動的にクライアント経由になるわけではなく、TUNの動作確認にもなりません。

ブラウザーにサーバーが見つからないと表示された場合は、まずDNSの項目を確認します。TUNを有効にしたときだけ失敗する場合は、TUNをオフにして再テストし、補助サービス、デフォルトルート、DNSハイジャックがほかのトンネルと競合していないか確認してください。この段階でゲートウェイを同時に手動変更したり、すべてのネットワークサービスを消去したり、システムファイルを削除したりしないでください。まず「システムプロキシが使える」最小構成に戻し、対象範囲を1つずつ広げます。

ノードがタイムアウトする：疎通テストと実際の接続を切り分ける

ノードのレイテンシがタイムアウトになっても、ノードが必ず停止しているとは限りません。レイテンシの測定では通常、ノード経由で特定のテスト先にアクセスするため、テスト先、DNS、ノードの出口、タイムアウト設定の影響も受けます。対象ノードを選び、ブラウザーと明示的なプロキシの両方で異なる2つの宛先にアクセスして、接続ログを確認してください。測定だけ失敗してWebサイトには接続できる場合は、テスト先や測定方法を確認します。実際の接続にも失敗する場合に、サーバーへの接続やプロトコル設定を調べてください。

どの段階で失敗したかを確認する

ログの接続拒否、接続タイムアウト、証明書エラー、認証エラーはそれぞれ意味が異なります。接続拒否は、通常、接続先には到達できるものの、該当ポートで接続を受け付けていないことを示します。接続タイムアウトの原因には、パケットロス、ファイアウォール、アドレスへの到達不能などがあります。認証エラーでは、パスワード、ユーザーID、サーバー設定を確認します。証明書エラーでは、時刻、サーバー名、信頼チェーンを確認してください。画面の「失敗」という表示だけを切り取るのではなく、前後のログと一緒にエラー全文を保存します。

現在選択しているのが個別のノードか、自動選択、フェイルオーバー、負荷分散のポリシーグループかを確認します。ポリシーグループの画面に表示された名前が、実際に接続で使われた出口とは限りません。接続の詳細を開き、宛先、適用ルール、ポリシーの経路、実際のノードを確認してください。ルールによって直接接続に振り分けられた場合、ノードのテスト結果とそのリクエストは別の経路です。同じ条件の結果として比較しないでください。

サーバーのドメイン名とプロトコル設定を確認する

サブスクリプションは正常に取得できるのにすべてのノードがタイムアウトする場合、パスワードを一括で変更する前に、ノードのサーバー名が名前解決できるか確認します。サーバー名の名前解決には、通常のWebサイト向けDNSとは異なるproxy-server-nameserverが使われる場合があります。名前解決の結果にIPv6アドレスが含まれ、現在のネットワークのIPv6経路に問題があると、ネットワークによって接続できたり、長時間待たされたりすることがあります。アドレスの種類とエラーを記録してから設定を変更してください。

ノードが1つだけ失敗する場合は、サブスクリプションの元データと照らし合わせて、アドレス、ポート、転送方式、TLS、SNI、クライアントのコアが対応しているかを確認します。ノードのIPアドレスをSNIに設定しないでください。証明書エラーを解消するために証明書検証を無効にするのも避けてください。ドメイン名で検証するプロトコルでは、接続先アドレスと証明書名がそれぞれ異なる役割を持つ場合があります。どちらかを安易に変更すると、ルーティングの問題がハンドシェイクエラーに変わることがあります。

# サーバー名の名前解決結果を確認
# example.com は例示用のドメインです。実際の確認ではノードのサーバー名に置き換えてください
dscacheutil -q host -a name example.com

# TCPポートへの接続確認のみ。プロキシ認証やUDPの確認はできません
nc -vz -G 5 example.com 443

上記のTCPテストに成功しても、確認できるのはTCP接続の確立だけです。プロキシの認証、UDP転送、Webサイトへのアクセスが正常とは限りません。UDPを使うプロトコルでは、このテストは実際の転送確認にもなりません。サーバーが完全に正常だと判断する根拠にはしないでください。コマンドが失敗した場合も、実際のポートを指定しているか、現在のネットワークが該当する通信方式を許可しているかを確認します。

ネットワークを比較して外部要因を特定する

ノードと設定を変えずに、自宅のWi-Fiとスマートフォンのテザリングでそれぞれテストします。テザリングでは成功し、元のネットワークでは失敗する場合は、元のネットワークのアクセス制限、UDP制限、経路品質を確認します。どちらでも失敗し、ほかのノードは正常な場合は、該当ノードまたはサーバー設定に問題がある可能性が高くなります。多数のノードを短時間に連続して高速テストしないでください。サーバー側の制限がかかったり、新たな接続負荷によって判断が難しくなったりすることがあります。

現在のコアがプロトコルに対応していない場合は、ダウンロードページから、必要なプロトコルに対応し、現在もメンテナンスされているクライアントを選んでください。Appleデバイスでは、まずClash Plusを候補にし、用途に応じてほかの選択肢と比較できます。コア名とクライアントの画面表示は同じものではありません。詳しくはClash、Meta、mihomoのコアの違いをご覧ください。クライアントを切り替える前に、元の設定を保存してください。切り替え後は同じノードだけをテストし、クライアント選びの変更をネットワークの復旧と混同しないようにします。

サブスクリプションを更新できない：取得・解析・有効化を個別に確認

サブスクリプションのトラブルは、少なくとも3段階に分けられます。リモートのデータを取得できない、取得したデータが有効な設定ではない、有効な設定が反映されていない、という状態です。まずエラーがどの段階で発生しているか確認してください。HTTPステータスの異常、接続タイムアウト、証明書エラーは、通常、取得段階の問題です。YAMLの行番号、フィールドの型、未対応プロトコルのエラーは解析段階に該当します。更新が成功してもノードが変わらない場合は、現在の設定、上書きルール、プロキシプロバイダーのキャッシュを確認してください。診断に必要な情報が失われるため、最初にサブスクリプションを削除するのは避けてください。

取得段階：URL、アクセス権、更新時の接続経路

サービス提供元のサイトからサブスクリプションURLをコピーし直し、前後の空白、改行、チャットアプリで置き換わった記号がないか確認します。クエリパラメーター付きのURLにはアクセス情報が含まれる場合があります。公開の掲示板に貼ったり、信頼できないオンライン変換サービスに渡したりしないでください。サービス提供元のトップページが開けても、サブスクリプションAPIへのアクセスが許可されているとは限りません。トップページ、ログイン状態、サブスクリプションの取得先は、それぞれ別の認証経路であることがあります。

ステータスコード401または403の場合は、通常、認証、利用期限、アクセス制限を確認します。404はURLの変更や無効化、429はリクエスト過多を示すため、更新ボタンを押し続けずに時間をおいてください。成功ステータスが返っても、本文がログインページ、認証ページ、エラー説明ならYAMLとして読み込めません。クライアントに表示されるレスポンスの概要を確認し、ログに認証情報を残さないようにしてください。

クライアントによっては、サブスクリプションの更新を直接接続で行うか、プロキシ経由で行うかを指定できます。初回登録時は現在のプロキシがまだ使えず、「接続するにはサブスクリプションが必要だが、更新には接続が必要」という状態になることがあります。利用が許可されたネットワークから直接更新するか、別の利用可能な接続経由で設定を取得してください。故障中のノードを更新リクエストの経路にしないようにします。接続経路を変更したら一度だけ更新し、エラーが変わったか記録してください。

解析段階：ノードリンクと完全なYAMLを区別する

一般的なBase64形式のノード一覧、単一のプロトコルリンク、Clash YAMLは、それぞれ別の入力形式です。完全な設定にはproxies、proxy-groups、rulesなどのフィールドが含まれます。ノード一覧はプロキシプロバイダーとして追加する必要がある場合があります。変換方法を決める前に、読み込み先が対応している形式を確認してください。形式の構造はサブスクリプションの形式と変換方法をご覧ください。ファイルの拡張子だけで内容を判断しないでください。

解析エラーに行番号が表示されたら、該当行だけでなく前の行も確認します。コロンの不足、タブによるインデント、閉じていない引用符、同じ階層のリストでのインデント不一致などにより、次の行でエラーが報告される場合があります。以下は階層構造を理解するためだけのローカル例で、接続可能なプロキシノードは含まれていません。リモートの設定全体をこれで置き換えても、ノードは自動的に追加されません。

mixed-port: 7890
allow-lan: false
mode: rule
proxies: []
proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,手動選択

有効化段階：設定と上書きの適用元を確認する

更新後は、画面で選択されている設定が、更新したものと同じか確認します。クライアントによっては、ダウンロード、保存、有効化が別々の操作になっています。プロキシプロバイダーにも独自の更新間隔がある場合があります。サブスクリプションカードの更新日時だけでなく、現在のポリシーグループのメンバーと読み込みログを確認してください。ノード数が変わってもルールが変わらない場合は、テンプレートや上書き機能がローカルルールを維持している可能性があり、リモートの更新失敗とは限りません。

リモート設定は次回の更新で上書きされるのが一般的です。変更を維持するには、クライアントが対応する上書き、マージ、拡張設定を使ってください。トラブルシューティングでは、不要な上書きをいったん無効にし、元のファイルをコピーしてから、元のサブスクリプションを読み込んで比較します。元の設定は動作し、マージ後にエラーが出る場合は、上書きを1つずつ戻して競合箇所を探してください。リモートファイルとローカルテンプレートを同時に変更すると、最終的に適用された内容を特定しにくくなります。

速度が遅い：レイテンシ、スループット、アプリの動作を分けて測る

レイテンシが低くても大容量ファイルのダウンロードが速いとは限らず、レイテンシが高くてもスループットが低いとは限りません。Webサイトの表示速度には、DNS、ハンドシェイクの回数、リソース数、接続先サービスの制限も影響します。調査前に症状を明確にしてください。最初のページ表示だけ遅いのか、ダウンロードが継続して遅いのか、動画が頻繁に止まるのか、特定のアプリだけ重いのかを確認します。同じ端末、ネットワーク、接続先を使い、できるだけ近い時刻に比較してください。異なる速度測定サイトや配信経路の結果をそのまま順位付けしないでください。

最小限のテスト表を作る

まずプロキシをオフにし、直接アクセスできる接続先を開いて、ローカルWi-Fiやブロードバンドに目立った問題がないか確認します。次にノードを1つ選び、同じ接続先に明示的なプロキシと通常のブラウザー接続でアクセスします。その後、ノードだけを入れ替えて同じ操作を繰り返してください。直接接続は正常なのにすべてのノードで遅い場合は、クライアントの通信取り込み方式とローカル負荷を確認します。特定のノードだけ遅い場合は、システム全体のネットワークを変更するのではなく、ノードの出口から接続先までの経路を確認します。

「アクティビティモニタ」のCPU、メモリ、ネットワークの各項目も確認します。バックグラウンド同期、システムアップデート、クラウドストレージへのアップロードで上り回線が埋まり、Webページの応答確認が遅くなることがあります。ダウンロード帯域がいっぱいになっていなくても発生します。大容量通信を行っていると確認できたタスクを一時停止して再テストしてください。見覚えのないシステムプロセスは終了しないでください。診断ログを最も詳細なレベルで長時間記録するのも避けます。頻繁な書き込みで負荷が増え、機密性の高い接続情報が蓄積されるおそれがあります。

DNS、ハンドシェイク、ダウンロードの各段階を確認する

以下のコマンドで、DNS、TCP、TLS、全体の所要時間を確認できます。HTTPプロキシ経由では、一部の項目がローカルプロキシまでの処理時間を示す場合があります。接続先ドメインの名前解決をプロキシ側で行うこともあるため、time_namelookupをリモートDNSの所要時間と見なすことはできません。数値1つだけで結論を出さず、クライアントのログと照らし合わせて、どの段階で遅れているかを確認してください。

curl --proxy http://127.0.0.1:7890 --noproxy '' \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'dns=%{time_namelookup}\ntcp=%{time_connect}\ntls=%{time_appconnect}\nfirst=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.apple.com/

TLSがすぐに完了するのに最初のデータが届くまで長くかかる場合は、接続先サーバーの応答や出口までの経路を詳しく確認します。接続段階で再試行が繰り返される場合は、パケットロス、アドレスの種類、ノードの接続状況を調べてください。小さなリクエストだけでは継続的なスループットは測れません。速度測定用のファイルも、サーバー側で速度制限されていることがあります。数字を良く見せようとして並列ダウンロードを繰り返さないでください。サブスクリプションの通信量を消費し、接続先サービスの制限にかかる可能性があります。

UDP、MTU、アーキテクチャの違いを確認する

動画、オンライン会議、ゲームではUDPやQUICが使われることがあり、ブラウザーでの一般的なHTTPSテストでは同じ経路を確認できません。アプリの通信がTUNに取り込まれているか、ノードが必要な転送に対応しているか、現在のネットワークでUDPが制限されているかを確認します。アプリに対応済みの通信方式へ切り替える設定があれば、一時的に比較できます。すべてのUDPを無効にする方法を一般的な高速化策として使わないでください。アプリの動作が変わり、通話を開始できなくなる場合もあります。

MTUが合っていないと、小さなリクエストは成功するのに大容量通信が止まることがあります。ただし、速度低下の原因が常にMTUとは限りません。ネットワークを切り替えたときの結果、ログ、通信時の症状がMTUの問題を示す場合に限り、対応しているTUN設定で少しずつ値を調整します。元の値を記録し、変更のたびにテストしてください。Appleシリコン搭載Macでは、変換処理の条件を減らすため、まずarm64ビルドを選びます。ただし、アーキテクチャを変えても接続先までの回線容量は増えません。クライアントの違いはクライアント比較をご覧ください。

最後に、「同じ接続先でも、テザリングでは正常だが自宅のネットワークでは通信が止まる」のように、再現できる結果を記録してください。「どのノードも遅い」というだけでは、ルーター、ネットワーク制限、経路の問題を判断できません。前者なら確認箇所を絞り込めます。設定を変更した後は、ログの詳細度を通常に戻し、普段使うアプリで動作を確認してください。速度測定を一度実行しただけで完了としないでください。

DNSの問題：名前解決の経路、fake-ip、漏えいの範囲を確認する

DNSのトラブルシューティングでは、まず3点を確認します。どのアプリが問い合わせを送ったか、どのDNSサーバーに渡ったか、取得した結果をどの通信に使ったかです。システムDNS、ブラウザーのセキュアDNS、クライアント内蔵DNS、ノードのサーバー名解決が同時に使われることがあります。Webサイトに接続できないからといって、必ずDNSの失敗とは限りません。DNSテストサイトに表示された地域だけでは、想定した経路を通ったかどうかも判断できません。まず対象ドメインが名前解決できるかを確認し、クライアントの接続ログと実際の出口を照合してください。

システムとクライアントの名前解決を区別する

macOSではscutil --dnsで、DNSリゾルバーとその適用範囲を確認できます。出力にはデフォルト、インターフェース限定、VPNが提供するリゾルバーが含まれる場合があります。最初の項目だけを見て、すべてのドメインの解決先を判断しないでください。社内ドメインの名前解決に分割DNSが必要な場合、すべてのDNSをパブリックDNSに変更すると社内リソースにアクセスできなくなることがあります。ブラウザーで独自のセキュアDNSを有効にしている場合も、システムと同じ経路を使わない可能性があります。

# macOSで現在のリゾルバーと適用範囲を確認
scutil --dns

# システムの仕組みで例示用ドメインを検索
dscacheutil -q host -a name www.apple.com

# 設定変更後に古いキャッシュを消去する必要がある場合のみ実行
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

キャッシュを消去しても古い結果が削除されるだけで、上流DNSや経路の誤りは修復されません。digなどのツールでは特定のDNSサーバーを指定して検索できますが、デフォルトの動作がmacOSアプリで使われるシステム全体の名前解決経路と同じとは限りません。コマンドラインとブラウザーで結果が異なる場合は、まず検索経路とキャッシュを確認してください。どちらかのツールが壊れていると決めつけないでください。暗号化DNSを使う場合は、DNSサーバー名を最初に解決する経路も利用できる状態にします。

fake-ipが通信を取り込む条件を理解する

mihomoのfake-ipモードでは、アプリに対応付け用のアドレスを返し、コアが接続を元のドメインに関連付けます。このアドレスは接続先サーバーの実際のアドレスではありません。fake-ipが表示されても、それだけでDNSが改ざんされているとは限りません。重要なのは、その後の接続も同じコアが処理しているかどうかです。アプリに対応付け用アドレスがキャッシュされた状態でクライアントを終了した場合や、システムDNSがクライアントを参照しているのにDNSサービスが停止した場合は、プロキシ切断後も接続できなくなることがあります。

# mihomoのDNS設定例。サブスクリプション全体ではありません
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

この例はローカルのループバックアドレスだけで待ち受けます。指定した上流DNSに現在のネットワークから接続できることも必要です。通常のシステムDNS設定では、1053のような独自ポートを直接指定できない場合があります。このポートで待ち受ける設定を追加しただけでは、すべてのシステム問い合わせが自動的にそこへ送られるわけではありません。クライアントのDNS取り込み、TUNによるハイジャック、または別の明示的な設定と連携させる必要があります。GUIクライアントが関連項目を上書きすることもあるため、実際に読み込まれた設定と起動ログを確認してください。

症状に応じて修復方法を選ぶ

LAN内の端末名、プリンター、社内ドメインだけに接続できない場合は、ローカルネットワーク探索、分割DNS、fake-ipのフィルタリング設定を確認してください。すべてのドメインを直接接続にする必要はありません。非互換だと確認できたドメインだけをクライアントが対応するフィルターリストに追加し、社内DNSへの経路は維持します。ノードのドメイン名も解決できない場合は、まずノードの名前解決を修復してください。接続できていないノードに、自身のサーバー名を解決させることはできません。

プロキシ接続は正常なのに外部テストで想定外のDNSサーバーが表示される場合は、まずブラウザー独自のDNSを無効にして比較し、次にTUNのDNS取り込み範囲、IPv6、バイパスルールを確認します。DNS問い合わせを直接送るかどうかと、実際の通信をプロキシ経由にするかどうかは別の設定です。要件に合っているかを、実際のプライバシー保護の範囲に基づいて判断してください。テストサイトは特定の方式で行う問い合わせしか確認できません。すべてのアプリのDNSが取り込まれている保証にはなりません。

修復後は、通常のドメイン、以前失敗したドメイン、必要な社内ドメインをそれぞれ確認します。クライアントを一度切断して再接続し、システムのリゾルバーが正しく戻ることも確認してください。長期運用では、仕組みを説明できるDNS方式を1つ選びます。システム、ブラウザー、ルーター、クライアントが互いに依存する転送経路を重ねないでください。TUNの取り込み方式を変更する場合は、macOSのTUN許可に関する解説を参考に、実際の動作経路を確認します。

システムプロキシが機能しない：設定、待ち受け、アプリの接続経路を確認

macOSのシステムプロキシは、アプリが参照するネットワーク設定であり、すべての通信を強制的に転送する仕組みではありません。ブラウザーは設定に従っても、コマンドライン、ゲーム、独自のネットワーク処理を使うアプリは従わない場合があります。まず明示的なプロキシ接続でクライアントの入口が使えるか確認し、次に現在のネットワークサービスにシステム設定が反映されているかを調べます。入口が正常なのに特定のアプリが直接接続する場合は、そのアプリ独自のプロキシ機能を確認してください。必要に応じてTUNを検討し、システムプロキシのオン・オフを繰り返すだけで解決しようとしないでください。

現在のネットワークサービスに設定されているか確認する

「システム設定 → ネットワーク → 現在のネットワークサービス → 詳細 → プロキシ」を開き、WebプロキシとセキュアWebプロキシのホスト名とポートを確認します。macOSのバージョンによって画面の項目名は多少異なりますが、必ず現在通信に使っているサービスを確認してください。Wi-Fiのプロキシ設定がEthernetにも適用されるとは限りません。ドック、テザリング、ネットワークロケーションを切り替えると、以前のサービスに設定が残ったまま、実際の通信は別のサービスを通ることがあります。

# 現在のプロキシ設定の概要を確認
scutil --proxy

# システム設定と照合するため、ネットワークサービスを一覧表示
networksetup -listallnetworkservices

# 例示用のローカルポートでTCPの待ち受けを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

出力には、HTTP、HTTPS、SOCKS、自動プロキシの設定が個別に含まれ、別々に有効になっている場合があります。手動プロキシとPACが同時に設定されている場合、手動設定が必ず自動設定より優先されると決めつけず、アプリが実際にどちらを使っているか確認してください。組織が管理する端末では、構成プロファイルによって制限されていることもあります。その場合は組織のネットワーク要件に従い、管理設定を無理に削除しないでください。クライアントがプロキシ設定を書き込めないときは、スイッチの見た目よりログのほうが権限の問題を特定しやすい場合があります。

待ち受けアドレスと混合ポートを確認する

待ち受けホストには通常127.0.0.1を指定し、ポートはクライアントの実際の設定を使います。外部ノードのサーバーポートをシステムプロキシのポートに設定したり、コントロールAPIのポートと混同したりしないでください。ポートを別のプロセスが使用していると、コアの起動に失敗したり、システムプロキシが別のアプリを参照したりすることがあります。待ち受けコマンドに表示されるプロセス名を確認し、該当するアプリを通常の方法で終了してください。正体の分からないプロセスを強制終了しないでください。

以下はローカルプロキシの入口を示す最小限の設定例で、接続先ノードは含まれていません。mixed-portはHTTPとSOCKSの両方を受け付けます。DNS用ポートとは異なり、外部のWebサイトがこのポートに直接接続するという意味でもありません。GUIクライアントに専用のポート設定がある場合は、まずそちらを変更してください。生成される設定と手動編集が互いに上書きするのを防げます。

mixed-port: 7890
allow-lan: false
mode: rule

アプリ独自のプロキシ設定とターミナル環境を確認する

ターミナルのプログラムは、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYなどの環境変数を読み込む場合もあれば、専用の引数だけを受け付ける場合もあります。確認のために、パスワードを含む変数の値を公開ログに貼らないでください。一時的なコマンド引数は適用範囲が明確なので、診断に適しています。動作を確認できたら、各ツールの説明に従って永続的なプロキシを設定します。HTTPS_PROXYのプロキシ先にもhttp://127.0.0.1:7890を指定できる点に注意してください。

ブラウザー拡張機能、アプリ独自のプロキシ、システムプロキシの設定が互いに競合する場合があります。まずプロキシ拡張を無効にし、新しいウィンドウで再テストしてください。古い接続が再利用されないよう、必要に応じてアプリを完全に終了してから起動し直します。接続を確立した後でルールやノードを切り替えても、既存の接続にすぐ反映されるとは限りません。診断では新しいリクエストを発生させ、接続ログで経路を確認してください。長時間接続したままのページを再読み込みするだけでは不十分です。

アプリがシステムプロキシに対応していない場合は、クライアントのTUN機能で通信を取り込めます。その前に補助サービスがインストールされ、必要な許可があり、ほかのトンネルと競合していないか確認してください。クライアントによって補助サービスを使うものと、システム提供のネットワーク機構を使うものがあります。すべてのクライアントに同じ拡張機能のインストールを求めないでください。クライアント終了後は、プロキシ設定が元に戻っているか確認します。ネットワークに接続できない場合は、まず残っているプロキシをオフにし、この項目を見直して入口を確認してください。セキュリティ機能を恒久的に無効にする対処は避けます。

クライアントがクラッシュする：画面の終了、コアの停止、システムによるブロックを切り分ける

ウィンドウが消える、コアが停止する、システムが起動を拒否するのは、それぞれ別の問題です。画面を閉じてもコアが動作し続ける場合があり、コアがクラッシュしても画面には古い状態が表示されたままのことがあります。発生のタイミングを記録してください。起動直後、設定の読み込み後、TUNを有効にしたとき、スリープから復帰したときのどれでしょうか。最初からデータフォルダー全体を削除しないでください。設定、ログ、クラッシュレポートは原因の特定に重要です。アプリを再インストールしても、これらの状態が消えるとは限りません。

アーキテクチャ、入手元、システムの警告を確認する

Appleシリコン搭載Macではarm64またはApple Silicon版、Intel Macではx86_64版を選びます。「このMacについて」でチップを確認してください。Universal版には両方のアーキテクチャが含まれる場合があるため、アプリの説明を確認します。macOSのダウンロードページから適切なインストーラーを選び直し、複数の古いコピーを交互に起動しないようにしてください。クライアントはまずClash Plusを候補にし、ほかのものはシステム要件とメンテナンス状況を比較して選びます。

アプリが破損している、開発元を確認できない、アクセス権がないといったシステム警告が表示された場合は、まず入手元とクライアントのリリース情報を確認します。システムのセキュリティ機能を無効にするコマンドをすぐに実行しないでください。企業端末では、アプリの実行がポリシーで制限されている場合もあります。インストーラーのアーキテクチャが合わない、OSのバージョンが要件を満たしていない、セキュリティ機能にブロックされるといった問題は、いずれも起動できない症状になりますが、対処方法は異なります。「クラッシュ」とまとめず、実際の警告文を記録してください。

最小構成で起動する前に証拠を集める

macOSの「コンソール」でクラッシュレポートを確認するか、クライアントのログ機能から障害が起きた時刻のログを出力します。レポートの対象がGUI、mihomoプロセス、補助サービスのどれかを確認してください。発生手順と直近の変更も記録します。上書きの追加、コアの切り替え、DNSの変更、TUNの有効化などが該当します。ログにはドメイン、サーバー、サブスクリプション情報が含まれる場合があります。共有前に各項目をマスキングし、ユーザーフォルダー全体をまとめて送信しないでください。

設定のコピーを保存してから、自動起動、自動接続、TUNをオフにし、最小構成で起動します。その後、サブスクリプションや上書きを1つずつ戻してください。最小構成では正常で、元の設定で終了する場合は、原因となるフィールドやルールを絞り込みます。設定を読み込む前から終了する場合は、アプリ本体、実行環境、システムレポートを優先して確認します。クライアントにセーフモードや設定の復旧機能がある場合は、対応している方法を使ってください。データフォルダーの名前を推測して操作しないでください。

補助サービスとリソースの異常を確認する

TUNを有効にしたときだけ失敗する場合は、補助サービスが現在インストールしているクライアントのものか、アップデート後に修復が必要か、ほかのVPNがルートを占有していないか確認します。一般ユーザーがシステム拡張機能を手動で置き換えたり、システム起動時のセキュリティレベルを下げたりしないでください。クライアントに用意されたサービスのインストール、修復、アンインストール機能を使います。画面で要求された権限がリリース情報と一致しない場合は、許可を繰り返すのではなく、いったん操作を止めて入手元を確認してください。

長時間の稼働後に終了する場合は、メモリ負荷、ログのサイズ、接続数の推移も確認します。ルールプロバイダーの頻繁な更新、異常な再接続、詳細ログの継続的な書き込みによって負荷が増す可能性があります。まず診断に関係のない条件を減らし、通常のログレベルに戻して不要な更新を停止したうえで、同じ負荷を再現してください。すべてのルールを消去したり、証明書の検証を無効にしたりして問題を隠さないでください。画面が終了しなくなっても、元のセキュリティ境界や通信の振り分けが失われる可能性があります。

Clash for WindowsとClashX Metaはアーカイブ済みの選択肢です。新しいOSとの互換性に問題がある場合は、現在もメンテナンスされている代替クライアントを優先して検討してください。古い設定をそのまま新しいアプリに上書きしないでください。クライアントによって、設定のマージ、補助サービス、データの保存方法が異なることがあります。まず最小構成のサブスクリプションを読み込み、その後ルールや設定を移行します。こうすれば、元の設定の問題と新しいクライアントとの互換性を分けて確認できます。

安定して再現できる場合は、OSとアーキテクチャ、クライアント名、発生手順、最小構成、個人情報を除いたログを整理し、プロジェクトやアプリの公式サポート窓口から報告してください。バージョン情報を推測したり、画面に表示される実際の識別情報の代わりに「最新版」と書いたりしないでください。復旧後は自動接続を有効に戻し、通常終了と再起動を一度ずつ試して、無効なシステムプロキシや利用できないバックグラウンドサービスが残らないことを確認します。

モバイル端末の問題：iPhone・iPad・Androidのネットワーク切り替え

モバイル端末では、まずシステムのVPN状態とアプリ内の接続状態が一致しているか確認し、Wi-Fiとモバイルデータのどちらを使っているか調べます。iOSのプロキシアプリは、システムが許可するネットワーク拡張機能を使います。macOSの補助サービスやターミナルコマンドをそのまま適用することはできません。iPhoneとiPadでは、まずClash Plusを候補にしてください。App Storeと公式サイトへのリンクはiOSクライアントをご覧ください。設定形式、利用できるルール、機能のオン・オフは、アプリの対応状況に従います。

iOSで接続済みなのにアクセスできない

まずアプリ内で接続を切り、「設定 → 一般 → VPNとデバイス管理」に、ほかのVPNが接続中でないか確認します。複数のアプリのVPN設定をインストールしておくことはできますが、同時に動作するトンネルやオンデマンド接続の設定が競合する場合があります。別のアプリの自動接続を一時的に無効にして再テストしてください。組織から配布された設定は削除しないでください。初回接続時にシステムのVPN追加を許可していない場合、アプリ内で準備完了と表示されても、システムのトンネルは確立されていないことがあります。

モバイルデータでのみ失敗する場合は、「設定 → モバイル通信」でアプリのデータ通信が許可されているか、契約プランやシステムのデータモードに問題がないか確認します。特定のWi-Fiだけで失敗する場合は、VPNを切断してWeb認証を完了してください。ネットワーク切り替え後は古い接続が元のインターフェースに残ることがあります。古いページを何度も更新するより、クライアントを再接続して新しいリクエストを作成したほうが復旧を確認しやすくなります。切り替え前後の結果を記録し、同時にノードを変更して比較条件を崩さないようにします。

iOSのバックグラウンド動作はデスクトップと異なります。アプリが前面に表示されていなくてもネットワーク拡張機能が停止しているとは限りません。また、マルチタスク画面からアプリを取り除いても、確実にサービスを再起動できるわけではありません。アプリ内の接続スイッチを操作し、システム設定で実際の状態を確認してください。端末の発熱や電池消費が気になる場合は、継続的な再接続、設定の頻繁な更新、ほかの大容量通信アプリがないか調べます。ステータスバーにVPNと表示されているだけで、プロキシが原因と判断しないでください。

ローカルネットワーク、プライバシー機能、通信の振り分けを確認する

プリンター、テレビ、LAN内のサービスに接続できない場合は、アプリの「ローカルネットワーク」権限と、クライアントのLANバイパスルールを確認します。IPアドレスでのアクセスと端末名による検出では、仕組みが異なる場合があります。IPアドレスで接続できても、マルチキャストによる検出が正常とは限りません。両方を別々にテストし、必要なローカル名前解決とルートは維持してください。1台の機器の問題を直すために、すべてのプライベートネットワークの通信をリモートの出口に送らないでください。

iCloudプライベートリレーや「IPアドレスのトラッキングを制限」などのシステムプライバシー機能によって、一部の通信経路が変わることがあります。ただし、一般的なプロキシトンネルと同じではありません。競合が疑われる場合は、元の状態を記録してから該当機能を一時的にオフにし、比較テスト後に元へ戻します。あらゆる接続トラブルの原因と決めつけないでください。アプリのリクエストが現在のクライアントに取り込まれたか、どのルールが適用されたか、どの出口を使ったかを確認することが重要です。

Androidと複数端末で使う設定の違い

Androidではダウンロードページの掲載順を参考に、Clash Plus、Clash Meta for Android、FlClash、Surfboardから選べます。バックグラウンド接続が切れる場合は、システムのバッテリー管理、バックグラウンド通信の許可、アプリ内のVPN設定を確認してください。設定画面の場所はメーカーによって異なる場合があります。プライベートDNS、ほかのVPN、常時接続VPNの設定も記録してください。画面ロック後だけ失敗する場合は、まずバックグラウンド制限を再現し、すべてのノードのプロトコルを変更するのは避けます。

Mac、iPhone、iPadで同じサブスクリプションを使っても、すべての動作設定を共通にできるとは限りません。デスクトップの待ち受けポート、コントロールAPI、ファイルパス、補助サービスの設定をそのままスマートフォンにコピーしないでください。ノードや必要なルールは共有し、各端末の動作設定はそれぞれのクライアントに保持します。同期の設計はAppleデバイス間の設定同期方法をご覧ください。読み込み後は実際に適用された内容を確認します。サブスクリプション名が同じだけで、動作も同じだと判断しないでください。

解決しない場合は、まず再現に必要な情報をまとめます。端末のOS、使用中のネットワーク、クライアント、選択中のポリシー、接続できない宛先、おおよその時刻を記録し、個人情報を除いたエラー概要を添えてください。ネットワーク設定をすべてリセットすると、ほかの接続設定も消えて復旧の手間が増えるため、急いで実行しないでください。インストールと接続の手順をやり直す場合は、クイックスタートに戻ってください。特定のドメインやノードだけに問題が残る場合は、該当する項目を確認し、すべての端末を最初から再インストールしないでください。