Clash Meta
トラブル対処ガイド

ノードがタイムアウトする：名前解決・接続・ハンドシェイクを切り分ける

速度テストの失敗は、すべての通信の失敗を意味しない

クライアントの遅延テストは、通常、指定したプロキシ経由でテスト先にリクエストを送って結果を確認します。サーバーのポートに単純に接続できるかを測るものではありません。テスト先に到達できない、想定外のステータスが返る、サーバー側で頻繁なテストが制限されているといった理由でもタイムアウトになります。同じ出口から実際に必要なサイトへアクセスし、接続ログを確認してください。実際のアクセスが正常なら、サブスクリプションをすぐ削除するのではなく、テスト先や検査間隔を見直します。

失敗の範囲を、単一の出口、同じプロバイダーの全出口、すべてのプロバイダーの出口に分けて確認します。一つだけ失敗するなら、そのサーバーと設定値を優先して確認します。同じグループがまとめて失敗するなら、アカウントの状態、サブスクリプションの更新、サーバー側のメンテナンスを確認してください。すべての出口で失敗するなら、ローカルネットワーク、DNS、時刻、ファイアウォールに戻って調べます。スマートフォンのテザリングは別の接続回線との比較に使えますが、回線を切り替えたら接続を張り直してください。以前の接続結果は新しい回線の状態を示しません。

エラーが発生した段階に注目してログを読む

lookupやno such hostは、通常、サーバーのドメイン名解決に関係しています。connection refusedは接続先から拒否されたことを示し、ポートが待ち受けていない、またはサーバー設定が一致していない場合によく見られます。接続タイムアウトから分かるのは、制限時間内にその段階が完了しなかったことだけで、アカウントが無効とは断定できません。ログがTLSやプロトコルのハンドシェイクまで進んでいる場合は、DNSを何度も変えるのではなく、認証、SNI、通信方式、システム時刻を確認します。

プロキシを手動で設定する場合は、type、サーバーアドレス、ポート、認証情報、トランスポート設定を一つずつ確認します。TLSのサーバー名は接続先アドレスと異なる場合があります。WebSocketのパスとHostも、任意に入れ替えてはいけません。プロバイダーが提示するmihomo設定を基準にし、大文字・小文字や項目の階層を保ってください。サブスクリプション変換後に不明な項目が出る、またはプロトコルが非対応と表示される場合は、クライアント名だけで判断せず、実際に使われているコアを確認します。

プロトコルの対応状況とネットワーク制限を切り分ける

UDPを使う出口では、通常のTCPサイトにアクセスできても、その出口の通信経路が正常とは限りません。反対に、TCPプロキシが正常でゲームだけ失敗する場合は、アプリがUDPを使っている、プロキシがその通信に対応していない、ポリシーグループが想定した出口を使っていない可能性があります。まず通常のHTTPSリクエストで基準を確認し、その後UDPが必要なアプリを個別にテストしてください。異なる用途を同じ遅延の数値だけで判断しないようにしましょう。

システムの日付、タイムゾーン、自動時刻設定を確認してください。時刻がずれていると、証明書がまだ有効でない、または期限切れと判定されることがあります。特定のWi-Fiだけで証明書エラーが起きるなら、認証ポータルやネットワーク検査装置の影響も考えられます。skip-cert-verifyを汎用的な解決策として使わないでください。接続の信頼性を損なう一方、サーバー名、証明書チェーン、認証情報の問題は解決しません。

プロバイダーに問い合わせる際は、エラーの発生時刻とタイムゾーン、接続ネットワークの種類、プロトコル名、個人情報を伏せたエラー行を伝えてください。サブスクリプション全体、QRコード、パスワードを含む設定は送らないでください。回線を変えると復旧するなら、接続経路に関係する問題です。同じ出口が複数の端末・回線で失敗するなら、サーバー側の調査を依頼する根拠になります。タイムアウトを延ばせば応答の遅さを確認できますが、待ち受けていないポートや誤った認証情報は有効になりません。

速度が遅い：帯域幅・遅延・負荷を切り分ける

再現可能な比較条件を整える

「速度が遅い」といっても、ページの表示開始が遅い、動画がバッファリングする、ダウンロード速度が出ない、操作がもたつくなど症状はさまざまです。ひとつの基準でまとめて判断できません。端末、ネットワーク、接続先、出口を固定して比較しましょう。初回表示だけ遅く、その後の転送は正常なら、DNS、接続確立、ハンドシェイクを優先して確認します。ダウンロードが継続的に遅い場合は、利用可能な帯域幅、サーバー負荷、接続先の制限を調べます。すべてのノードを何度も速度テストするより、症状を記録するほうが役立ちます。

まず直接アクセスできるリソースでローカルネットワークの基準を確認し、次に同じリソースへプロキシ経由でアクセスします。プロキシ必須の接続先なら、利用できる二つの出口で比較してください。テスト中はOSの更新、クラウドストレージの同期など、大量の通信を行う処理を一時停止します。複数端末で帯域幅を共有していると誤判定につながります。Wi-Fiの電波、ルーターの負荷、モバイルネットワークの混雑はいずれもプロキシより手前の問題であり、クライアントを変えても解消しません。

遅延テストは通信速度のランキングではない

遅延が小さい出口でも、通信量が多いとは限らず、すべてのサイトに適しているわけでもありません。自動選択は通常、テスト用リクエストを基準に判断し、ダウンロード帯域幅を継続測定するものではありません。特定のサイトだけ遅い場合は、そのサイトのCDN、アカウント制限、出口から接続先までの経路を確認します。すべての接続先が遅い場合は、アクセス回線とサーバー全体の状態を調べてください。大容量ファイルを一度ダウンロードした結果だけで、すべてのアプリの使用感を判断しないようにしましょう。

接続履歴で、実際の通信がどのポリシーグループを通ったか確認します。ルールで自動グループを選んでいても、その内部で別の選択グループを参照している場合があります。画面に表示される外側のグループ名が、最終的な出口とは限りません。ポリシーを変更しても、確立済みの長時間接続は以前の経路を使い続けることがあります。対象アプリの接続を閉じるか、該当する接続だけ切断して再試行してください。重要なダウンロードやリモート接続中にすべての接続を切断し、余計な中断を招かないようにしましょう。

DNS、プロトコル、TUNの負荷を確認する

新しいドメインを開くたびに一時停止する場合は、DNSリクエストが何度もタイムアウトしてから別の経路に切り替わっていないか確認します。上流DNSを複数設定しても、自動的に速くなるわけではありません。到達できない上流、誤ったブートストラップ名前解決、不安定な出口経由のクエリなどが、新しい接続を遅らせることがあります。まず現在のネットワークで使える名前解決経路を一つ残して基準を確認し、必要に応じて振り分けを追加してください。キャッシュが有効なのは再度行う問い合わせだけで、初回の名前解決経路を正すことはできません。

ブラウザーがHTTP/3を優先して試し、出口や現在のネットワークでUDPが不安定だと、TCPへフォールバックするまでに一時停止して見えることがあります。比較のため、そのアプリのQUICを一時的に無効にしてもかまいません。ただし、すべてのUDPを恒久的に遮断するのは最適化になりません。音声通話、ゲーム、一部のプロトコルはUDPを必要とします。診断では接続方式と宛先ポートも確認し、遅いリクエストが実際にUDPを通っているかを調べてください。

TUNはより広い範囲の通信を取り込みます。有効にすると、システムプロキシでは対象外だったバックグラウンド通信も扱われる一方、セキュリティソフト、別のVPN、仮想ネットワークインターフェースとルートが競合する場合があります。同じ接続先で「HTTPプロキシを明示」と「TUNで取り込み」を比較してください。前者が正常で後者が遅いなら、サブスクリプションを変えるのではなく、ルートとネットワークスタックを優先して確認します。stackを変更する前に、使用中のコアとプラットフォームが対応していることを確認し、元の値を記録してください。

小さなリクエストは正常なのに、大きなレスポンスが止まる場合は、経路MTUや中間機器の挙動が関係している可能性があります。ただし、まず接続先の速度制限やパケットロスを除外してください。MTUの調整は実際に使うトンネルインターフェースに対して行い、変更前後を比較します。根拠のない数値をすべてのネットワークアダプターに設定しないでください。速度改善のためにファイアウォールを頻繁に無効化するのも避けましょう。具体的なブロック記録を確認し、クライアントに関係するプログラムやインターフェースのルールだけを調整します。

調査の最後に、再現条件を記録してください。同じ接続先・時間帯で二つの出口、二種類の接続回線を試した結果と、TUNの状態を残します。特定のサーバー経路で継続的に問題が起きるなら、これらの情報をプロバイダーに伝えると効果的です。根拠がないままキャッシュを消す、再インストールする、同時接続数を増やすといった操作を、標準の速度改善手順にしないでください。

システムプロキシが機能しない：アプリの接続方法を確認

システムプロキシはすべての通信を取り込む機能ではない

システムプロキシはアプリに提供されるプロキシ設定であり、実際に使うかどうかはアプリやネットワークライブラリによって異なります。ブラウザーは正常でも、コマンドラインツール、ゲーム、ストアアプリで失敗する場合がありますが、必ずしもルールの問題ではありません。まずプロキシを明示したコマンドでコアの接続口を確認し、次に対象アプリがシステム設定を参照するか調べます。HTTPやSOCKSのアドレスを個別に入力するアプリ、環境変数を使うアプリもあれば、TUNで通信を取り込むほうが適したアプリもあります。一つのスイッチですべてのプロセスが対象になるとは限りません。

Windowsでは、ユーザー向けプロキシ、自動構成スクリプト、WinHTTPの設定はそれぞれ別の接続口です。netsh winhttp show proxyでWinHTTPの状態を確認できますが、使用中のブラウザーの設定を示すものではありません。一つのアプリを直すために、すべてのシステムサービスへプロキシを設定しないでください。サービスアカウント、更新コンポーネント、ユーザーセッションでは必要なネットワークが異なる場合があります。まず失敗するプログラムが使うネットワークライブラリを確認し、適切な設定方法を選びましょう。

ローカルアドレス、ポート、環境変数を確認

ローカルのアプリでは通常、127.0.0.1と実際の待ち受けポートを使います。システムプロキシに古いポートが設定されている場合や、SOCKS専用の欄にHTTPアドレスを入力している場合は接続できません。allow-lan: falseでも、ローカルループバックへのアクセスには影響しません。一方、別の端末から自分自身の127.0.0.1をPCのアドレスとして指定することはできません。LAN内で共有する場合に限り、待ち受けアドレス、ファイアウォール、信頼できる接続範囲を確認してください。

シェルの環境変数は、新しく起動した子プロセスに引き継がれます。クライアントのポートを変更しても、すでに起動しているターミナルには古い値が残ることがあります。システムプロキシを無効にしても、手動設定した環境変数は自動では削除されません。以下はUnix系シェルの現在のセッションで比較する例で、永続設定は変更しません。既存の変数と設定元を確認・記録してからテスト値を設定してください。元に戻す際は、シェルの起動ファイル、開発ツールの設定、プロジェクトのスクリプトから再設定されていないかも確認します。

env | grep -i proxy
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -I --max-time 20 https://example.com
unset http_proxy https_proxy

ここでhttps_proxyの値にhttp://を使っているのは、クライアントがローカルのHTTPプロキシに接続し、その上にHTTPSトンネルを確立するためです。対象へのアクセスを平文にするわけではありません。環境変数の大文字・小文字や優先順位の扱いはツールによって異なります。ALL_PROXYやNO_PROXYも動作に影響することがあります。確認時はこれらの変数も調べ、特に迂回対象のドメインやネットワーク範囲が広すぎないか注意してください。

UWP、コンテナー、TUNのケースを確認

Windowsの一部ストアアプリでは、ループバックアクセスが制限されているため、システムプロキシが正しくてもローカルプロキシに接続できないことがあります。まず通常のデスクトップアプリが同じポートで正常に接続できるか確認し、その後、対象アプリのループバック通信を許可するか、TUNを使うか検討してください。すべてのアプリを一括で許可することを標準手順にしないでください。具体的なコマンドと影響範囲はUWPのループバック制限のトラブル対処をご覧ください。遠隔プロキシの認証設定を変更する必要はありません。

コンテナー、仮想マシン、WSLにはそれぞれ独立したネットワーク環境があり、その内部のループバックアドレスがホストを指すとは限りません。使用中のネットワークモードに応じてホストへ到達できるアドレスを調べ、ファイアウォールと待ち受け範囲を確認してください。最初からローカルプロキシをすべてのインターフェースに公開しないでください。同じネットワーク上の別端末から利用されるおそれがあります。公開が必要な場合は、信頼できる接続元に限定し、クライアントの機能に応じてアクセス制御を設定します。

TUNは仮想インターフェースとルーティング制御によって通信を取り込むため、追加の権限やサービスが必要になることがあります。有効化したら、ログでデバイスの作成、ルートの設定、DNSの取り込み状態を確認します。二つのVPNが同時にデフォルトルートを書き換える場合や、仮想マシンとトンネルのネットワーク範囲が重複する場合、特定の接続先に到達できなくなることがあります。まず他の通信制御プログラムを停止して比較してください。復旧後にルートを明示して共存できるか検討し、ネットワークアダプターの再インストールを繰り返さないようにしましょう。

最後に、対象アプリから新しいリクエストを送り、接続画面でプロセスまたは接続先、適用ルール、出口を確認します。Webページで出口が変わったことだけでは、そのページの経路が正常と分かるだけです。修復後はブラウザー、コマンドライン、以前失敗していたアプリをそれぞれテストします。クライアントを終了した後、システムプロキシ設定が元に戻ることも確認し、停止済みポートへの設定が残らないようにしてください。

モバイル端末の問題：VPN、バックグラウンド動作、ネットワーク切り替え

Android：まずVPNサービスの状態を確認

Androidクライアントは通常、システムのVPNサービスを通じて通信を取り込みます。同じユーザーまたはプロファイルで、別のVPN、一部のローカルフィルター、企業向けセキュリティアプリがこの機能を使用中の場合があります。他の通信制御アプリを停止してから、Clash Plus、Clash Meta for Android、FlClashで再接続し、システムのVPNアイコンと許可状態を確認してください。アプリのホーム画面にあるボタンの色だけで、バックグラウンドサービスが動作中だと判断しないでください。

一部のアプリだけ失敗する場合は、まずアプリの振り分けリストを確認します。除外リストに入っているアプリは、想定どおりプロキシを通りません。選択したアプリだけをプロキシに通す設定では、選択されていないアプリも取り込まれません。Androidの仕事用プロファイルと個人用プロファイルでは、アプリやVPN環境が異なることがあります。個人用プロファイルで正常に接続できても、仕事用プロファイルが同じ経路を使っているとは限りません。問題が起きているアプリのプロファイルを特定し、企業ポリシーの対応が必要か判断してください。

画面ロック後に通信が切れる：省電力とルートの残留を切り分ける

画面表示中は正常で、ロック後に切断される場合は、まずVPNサービスが動作し続けているか確認します。次に、システムがバックグラウンド動作、バックグラウンド通信、自動起動を制限していないか調べてください。Androidはメーカーによって設定の場所が異なります。「設定 → アプリ → 対象のクライアント → バッテリー」からバックグラウンド動作の権限を探し、モバイルデータの制限も確認します。一つずつ変更してロック後に再テストしてください。省電力機能を一度にすべて無効にすると、必要な例外が分からなくなります。

常時接続VPNや、VPNを通らない通信をブロックする設定が有効な場合、サービスが停止すると端末全体がオフラインになることがあります。これは通信遮断ポリシーとサービスの状態が組み合わさった結果であり、ノードが突然使えなくなったとは限りません。一時的に通信を戻す場合も、まずその設定の保護目的を理解したうえで、システムのVPN設定を調整してください。クライアント復旧後に接続を再確認します。詳しい切り分け手順はAndroidのバックグラウンド動作とバッテリー最適化のトラブル対処をご覧ください。

バッテリー消費が多い場合も、アプリのランキングだけで判断しないでください。VPNプロセスは他のアプリのトンネル通信も処理するため、システムの統計ではその通信の一部がVPNに計上されることがあります。使用条件が近い時間帯を選び、画面点灯時間、通信量、ネットワークの種類を比較してから、頻繁なヘルスチェック、サブスクリプションの更新、再接続がないか確認します。アイドル中もログが大量に出る場合は、DNS機能をすべて無効にする前に、同じリクエストが繰り返される原因を探してください。

iOS：トンネルとオンデマンド接続を確認

iOSではダウンロードページからClash PlusのApp Storeページへ移動できます。公式サイトはclashplus.ioです。接続に問題がある場合は、システムのVPN設定とアプリで選択中の設定が一致しているか確認し、他のネットワーク拡張機能が通信を取り込んでいないか調べてください。アプリがバックグラウンドに移っただけでは、トンネルが終了したとは限りません。システムのVPN状態と新しいリクエストの結果を合わせて判断します。

オンデマンド接続が有効だと、ネットワークの変更後にシステムがトンネルを自動的に再確立することがあります。手動で切断してすぐ再接続しても、操作が反映されていないとは限りません。現在のオンデマンドルールと対象ネットワークを確認してください。Wi-Fiでは正常でモバイル通信では失敗する場合は、アプリのモバイルデータ通信の許可を確認し、現在の回線からサブスクリプションと出口にアクセスできるか調べます。モバイル回線の切り替えでは接続元アドレスが変わるため、一部の長時間接続は張り直しが必要です。

ネットワーク切り替え、認証ポータル、LANアクセス

Wi-Fiからモバイル通信に切り替えた後は、ネットワークが安定するのを待ってから対象へ再リクエストしてください。それでも失敗する場合は、設定を削除せず、まずVPNに再接続します。公衆Wi-Fiの認証ページはローカルネットワークや特定のドメインを必要とする場合があります。必要なら一時的にプロキシを停止して認証し、完了後に再び有効にしてください。VPN外の通信が常にブロックされる設定の場合は、前述のVPNポリシーも確認します。トンネルを確立する前に認証リクエストが遮断されないよう注意してください。

スマートフォンからの画面共有、印刷、家庭内サーバーへのアクセスが失敗する場合は、LANアドレスが誤ってリモートへ送られていないか、VPN設定で必要なローカルアクセスが許可されているか確認してください。一台のプリンターのためにすべての通信を直接接続に変更しないでください。対象となるLANアドレスとドメインを記録し、範囲を絞ったルールを設定します。アプリがデバイス検出プロトコルを使っている場合、TCPの宛先を一つルールに追加するだけでは不十分なことがあります。ローカルのブロードキャストやマルチキャストも確認してください。

モバイル端末で問題を再現するときは、OS、接続ネットワーク、画面ロックの前後、VPNが維持されているか、失敗するアプリの範囲を記録します。設定全体を公開して相談しないでください。復旧後は、画面表示中のアクセス、短時間の画面ロック、Wi-Fiとモバイル通信の切り替え、LANアクセスを順にテストします。基本的な内容はトラブルシューティングを、設定を再インポートする場合は入門ガイドの設定手順を参照してください。