症状から原因を特定するトラブル対処ガイド

Clashのトラブル対処ガイド

接続できない、サブスクリプション更新に失敗する、クライアントに異常がある場合の確認手順。

初めて使う場合は、まずサブスクリプション設定ガイドに沿って、インポート、設定の選択、プロキシの有効化を行ってください。このページでは、インストールは済んでいるものの、どこかの動作が期待どおりでない場合を扱います。該当する症状を選び、順番に確認してください。一度に変更するのは1項目だけにして、結果を記録しましょう。正常に動いている設定まで壊すのを防げます。

新規インストールの場合は、インストーラーのダウンロードページからClash Plusを選ぶのがおすすめです。Clash Verge RevやFlClashなどをすでに使っている場合も、ここでネットワーク経路を切り分けられます。メニュー名はクライアントによって多少異なるため、実際の画面に合わせて確認してください。ログを共有する際は、サブスクリプションURL、アカウント情報、個人を特定できるネットワーク情報を隠してください。

症状を記録変更は1項目ずつ使える設定を保持

インターネットに接続できない：ローカルネットワークとプロキシ経路を切り分ける

プロキシの適用を解除するとネットワークが復旧するか確認

Clashを有効にするとすべてのWebページが開けない、またはクライアントは実行中なのにアプリが読み込み中のままになる症状です。問題が起きるアプリ、アクセス先、発生時刻を記録してから、「システムプロキシ」と「TUNモード」をオフにし、クライアントの画面は開いたままにします。ブラウザーで、普段プロキシなしでアクセスできるサイトを開いてください。それでも接続できない場合は、Wi-Fiのログイン認証、ルーター、システムのネットワーク設定、ほかのVPNを先に確認します。プロキシクライアントだけが原因とは限りません。学校、ホテル、公共のネットワークでは、通信をプロキシに通す前に認証が必要なことがあります。

プロキシの適用を解除してすぐに復旧した場合、問題はローカルの入口、ルールの選択、またはプロキシの接続先に絞られます。「サブスクリプション」または設定一覧を開き、設定をダウンロードしただけでなく、実際に選択していることを確認してください。次に「プロキシ」を開き、現在のプロキシグループで有効な接続先が選ばれているか確認します。グループによっては以前の選択が保持され、サブスクリプション更新で項目名が変わると、動作中に見えても有効な選択肢がないことがあります。すべてのサブスクリプションを削除せず、まず動作確認済みの設定に切り替えて比較してください。

プロキシを明示したリクエストでシステム設定を介さずに確認する

次にクライアントのコアだけを起動し、TUNは一時的にオフにします。「設定」で実際の混合ポートを確認してください。以下では7897を例にしています。ポートが異なる場合は置き換えてください。プロキシを明示したリクエストは、ブラウザーがシステムプロキシ設定に従うかどうかに左右されません。「クライアントが通信を転送できるか」と「アプリの通信がプロキシに入っているか」を分けて確認できます。Windows PowerShellでは、古い環境でcurlが別のコマンドとして扱われることを避けるため、curl.exeを使います。例のドメインはHTTPSリクエストの接続先であり、現在のネットワークから直接アクセスできる必要はありません。

curl --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com

HTTPステータス行が返れば、少なくともそのリクエストにはサーバーから応答があったということです。アクセス拒否のステータスでも、接続自体を確立できない場合とは異なります。127.0.0.1に接続できない場合は、コアが起動しているか、ポート番号が正しいかを確認します。ローカルポートには接続できても、その先でタイムアウトする場合は、送信先のログを確認してください。ブラウザーでは失敗するのに明示的なリクエストは成功する場合は、ノードを何度も切り替えず、システムプロキシの項目でアプリ側の入口を確認します。

ログからルールの問題と送信先への接続失敗を切り分ける

「ログ」を開き、通常の情報レベルに設定して表示を消去したあと、失敗するリクエストを一度だけ再現します。時刻、接続先ドメイン、適用されたルール、最終的なプロキシグループを確認してください。プロキシが必要な接続なのに誤ってDIRECTになっている場合は、ルールの順序やモード選択に問題がある可能性が高いです。比較のため一時的に「グローバル」に切り替えてテストし、終わったら「ルール」に戻します。グローバルでは接続できてルールではできない場合、長期間すべての通信を同じ接続先に送るのではなく、適用されたルールを確認してください。既存の接続には以前のルールが残ることがあるため、切り替え後はページを開き直すか、新しい接続を確立します。

特定のアプリに対応するログがまったくない場合、そのアプリの通信が現在の入口を通っていないか、別のネットワークプロセスを使っている可能性があります。まずブラウザーで確認し、次にアプリ独自のプロキシ設定を確認してください。ログにREJECTがある場合は、広告ブロック、プライバシールール、自作ルールのどれが適用されたかを調べます。関係するルールだけを調整し、ルール一覧を丸ごと消去しないでください。適用優先順位については、ルール構文と適用順序の解説もご覧ください。

変更後に、これまで直接接続できていたサイトまで開けなくなった場合は、直近の正常な状態にすぐ戻してください。TUNをオフにし、DNSを元の設定に戻し、ほかのネットワーク制御ツールを終了してから再テストします。システムのネットワークスタック全体をすぐにリセットする必要はありません。システム全体のリセットでは、一部のアダプターやネットワーク設定が削除され、リモートデスクトップ、仮想マシン、社内ネットワークへの接続まで切れる可能性があります。局所的な修復で解決しないことを確認してから検討してください。

ノードがタイムアウトする：エラーのアドレスから失敗箇所を特定する

接続、ハンドシェイク、接続先へのアクセスを切り分ける

「タイムアウト」の原因はひとつではありません。クライアントの接続テストは特定の確認用アドレスにアクセスする一方、ブラウザーは別のWebサイトに接続するため、結果が一致するとは限りません。まず対象ページを直接開き、同じ時刻のログを確認してください。テストボタンだけがタイムアウトし、実際のアクセスは正常なら、接続テストのアドレスと適用ルールを調べます。ひとつのテスト結果だけで送信先が使えないと判断しないでください。逆にテストに成功しても、そのリクエストが完了したことを示すだけで、すべてのWebサイト、UDP、大容量ファイルの転送が正常とは限りません。

dial tcpに続くアドレスが重要です。プロキシサーバーのアドレスの場合も、直接接続する宛先の場合もあります。前者への接続に失敗するなら、サーバードメインの名前解決、ポート、ネットワークからの到達性を確認します。後者の場合は、なぜリクエストが直接接続を選んだのかを先に確認してください。connection refusedは通常、接続が明示的に拒否されたことを示します。該当ポートでサービスが待ち受けていない場合や、途中の機器が拒否した場合があります。i/o timeoutは制限時間内に読み書きが完了しなかったという意味であり、これだけでサービス提供元の停止とは判断できません。

ログの例	優先して確認すること	次に行うこと
`connection refused`	エラーに表示されたアドレスのサービスとポート	ローカルの入口とリモートの接続先のどちらが拒否したか確認
`i/o timeout`	発生した段階、ネットワーク経路、接続先	ネットワークまたは接続先を変えて、1項目ずつ比較
`no such host`	ドメインの入力と名前解決の経路	サーバードメインの基本的な名前解決を確認
`certificate`関連のエラー	システム時刻、証明書の名前、TLSパラメーター	設定を確認し、証明書検証は無効にしない

ネットワークと接続先を組み合わせてテストし、原因を絞り込む

同じ接続先と同じ宛先のまま、端末を現在のWi-Fiからスマートフォンのテザリングに切り替えてください。テザリングで使える場合、元のネットワークが該当ポートや通信方式を制限しているか、経路の品質に問題がある可能性があります。次に元のネットワークに戻し、別の接続先を試します。特定の接続先だけ失敗する場合は、設定の有効期限やサーバー側の変更を確認し、発生時刻とエラーを添えてサブスクリプションの提供元に問い合わせてください。すべての接続先がどのネットワークでも失敗する場合は、端末の時刻、サブスクリプションの有効性、コアとの互換性を優先して確認します。

UDPを使う通信では、一般的なTCPポートの確認だけではプロトコルが使える証拠になりません。Webサイトにはアクセスできても、UDPが制限されるネットワークがあります。その場合は、異なる通信方式に対応した接続先を比較用に使えます。プロトコル名、ポート、通信方式の項目を安易に別のプロトコルへ書き換えないでください。クライアント側とサーバー側の設定を一致させる必要があります。接続に失敗しても、すぐにファイアウォールを無効にする必要はありません。まずブロック記録を確認し、必要なアプリや明確なポートに限ってルールを追加します。テスト後は一時的に許可した設定を削除してください。

TLS、認証情報、コアとの互換性を確認する

ハンドシェイクに失敗する場合は、まずシステム時刻の自動同期を有効にし、サーバー名、SNI、認証情報、通信経路を確認します。サーバードメインをIPアドレスに置き換えると、証明書の名前検証結果が変わることがあります。そのため、一般的な解決策として使わないでください。サブスクリプションで指定されているパラメーターはまとめて保持し、手動設定の場合はサーバー側の説明と1項目ずつ照合します。認識されないプロトコルや設定項目がある場合は、クライアントが使用するコアを確認してください。旧版のオリジナルClashは、mihomoのすべての拡張機能に対応しているわけではありません。

最近設定を移行した場合は、mihomoとオリジナルコアの違いを確認し、プロトコル、ルールプロバイダー、スニッフィング関連の項目を重点的に見直してください。クライアントを更新する場合は、インストーラーのダウンロードページから端末に合ったビルドを選び、現在の設定を保存してからインストールします。出所のわからない実行ファイルでコアを上書きしないでください。クライアント、サブスクリプション、DNS、すべてのルールを同時に更新すると、どの変更が原因か判断しにくくなります。

サポートに問い合わせる際は、「タイムアウト」の文字だけを切り取るのではなく、失敗したリクエストの直前と直後のログを保存してください。クライアント名、OS、使用ネットワーク、特定の接続先だけに影響するか、ネットワークを変えたテスト結果も伝えると役立ちます。パスワード、サブスクリプション情報、サーバーを特定できる完全な情報は伏せてください。ログ項目の見方はClashの実行ログの読み方をご覧ください。

サブスクリプション更新に失敗する：取得と解析の段階を確認

URLから取得できないのか、内容を読み込めないのかを見分ける

サブスクリプションの更新に失敗しても、現在使える設定は残し、削除して再追加するのは避けてください。サブスクリプションの詳細を開いて、失敗したのが内容の取得段階か解析段階かを確認します。接続タイムアウトや名前解決の失敗は、通常ダウンロード段階で起こります。YAMLの書式エラー、未対応のプロキシ種別、ルールグループの参照エラーは、通常解析段階の問題です。必要な対処はそれぞれ異なります。更新ボタンを繰り返し押しても書式の問題は直らず、サーバー側のリクエスト制限が働いて、原因を特定しにくくなることもあります。

サービス提供元の管理画面からサブスクリプションURLをもう一度コピーし、前後の空白や改行、チャットアプリが付けた句読点、Webページ上の説明文まで含めてコピーしていないか確認してください。URLのクエリパラメーターは認証に使われることが多いため、安易に削除・変更してはいけません。スクリーンショットや掲示板に公開するのも避けてください。まずクライアント内からインポートし、見知らぬオンライン変換サービスにURLを入力しないでください。ブラウザーで確認する必要がある場合は、閲覧履歴、ダウンロード履歴、同期機能にURLが保存される可能性を確認してください。

HTTPレスポンスから対処方法を判断する

401または403が返る場合は、通常、認証、アカウントの状態、サーバー側のアクセス制限を確認します。ローカルの混合ポートを変更する問題ではありません。404はURLのパスが無効になっている可能性がありますが、サーバーが意図的にリソースを非公開にしている場合もあります。提供元から正しいURLを再取得してください。429はリクエスト過多を示すため、連続した再試行をやめ、サーバーの案内に従って待ちます。5xxはサーバーまたは上流側の問題と考えられます。時刻を記録してしばらく待ち、すべてのクライアントをすぐに再インストールするのは避けてください。

成功ステータスが返っても、設定本文ではなくログインページ、認証ページ、エラーメッセージが取得されていることがあります。エラー内容に<html>、文書型宣言、Webログイン画面の内容が含まれていないか確認してください。Clashの設定は通常、プロキシ、プロキシグループ、ルールなどの項目を含むYAML形式です。ノード一覧と完全な設定ファイルも別物です。提供元が複数のサブスクリプション形式を用意している場合は、使用中のクライアントに対応する形式を選んでください。クライアント名やリクエスト識別子の変更は、提供元から明確な指示がある場合にのみ行います。

更新経路の依存関係と設定の競合を解消する

現在のネットワークから直接接続できないサブスクリプションURLを、クライアントが更新時に直接取得しようとする場合があります。反対に、すでに使えなくなったプロキシ経由で更新リクエストが送られていることもあります。更新設定で現在のプロキシ経由の取得が可能か確認し、直接接続と利用可能なプロキシ経路をそれぞれ試してください。現在使える接続先がない場合は、サブスクリプションサービスにアクセスできるネットワークに一時的に切り替えて更新します。「接続するには先に更新が必要だが、更新には先に接続が必要」という状態を避けられます。プロキシサーバーのドメインを名前解決できることも確認してください。

解析エラーに行番号が表示されたら、該当行とその前後のインデントを確認します。YAMLでは階層をスペースで表し、タブを混在させないでください。同じ階層でキー名が重複していると、値の上書きや解析エラーが起きることもあります。以下はコアが設定を読み込めるか確認するための、単独で使える最小限の直接接続設定です。プロキシの接続先は含まず、サブスクリプションの代わりにもなりません。テスト用にローカル設定を新規作成し、リモートのサブスクリプション本文を直接上書きしないでください。

mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

最小設定は読み込めるのにサブスクリプション設定を読み込めない場合は、サブスクリプションの内容、コアの対応状況、ローカルの上書き設定を確認します。クライアントによっては、更新後の設定に「マージ」「スクリプト」「オーバーライド」を適用します。古いオーバーライドが存在しないプロキシグループを参照していると、取得した本文が正しくても最終設定でエラーになることがあります。これらの追加処理を1つずつ無効にして更新し、読み込みを確認してください。原因がわかったら該当する参照だけを修正し、カスタム設定をすべて破棄しないでください。

更新に成功した後も、現在の設定が選択されているか、プロキシグループの項目や接続先が使えるかを確認してください。ダウンロードが完了しても、新しい設定に切り替わったとは限りません。サブスクリプションURLが漏えいした可能性がある場合は、提供元の管理画面でURLを再発行し、すべての端末で更新してください。チャット履歴からメッセージを削除しても、すでにコピーされた認証情報は無効になりません。

速度低下や断続的な切断：帯域、遅延、アプリの動作を切り分ける

「遅い」を再現できる症状として具体化する

まず、どの場面で遅いのかを整理します。ページの最初の表示に時間がかかる、動画の再生中に何度もバッファリングする、ダウンロード速度が低い、一定時間後に接続が切れる、といった違いがあります。ページ表示の遅さはDNS、接続確立、TLSハンドシェイクが原因の場合があります。ダウンロードが継続的に遅い場合は、スループット、回線の混雑、サーバー側の制限が考えられます。一定時間後に切断されるなら、スリープ、バックグラウンド制限、接続維持の設定を確認します。クライアントの遅延値だけではダウンロード帯域はわかりません。往復遅延が小さくても、接続先の回線が混雑していることがあります。

テストでは端末、接続先、アプリを固定し、クラウド同期、システム更新、ほかの大容量通信を一時停止します。まずプロキシを使わないローカルネットワークの状態を確認し、次に同じ接続先で2つの接続先を比較してください。Wi-Fi、ブラウザー、プロトコル、接続先のWebサイトを同時に切り替えると、毎回条件が異なります。速度測定サイトの通信がルールによって直接接続されることもあります。その結果をプロキシ経由の速度と誤認すると、結論が逆になります。テスト時は接続一覧で実際の接続先を確認してください。

ネットワーク経路と端末の負荷を段階的に確認する

Wi-Fiの電波表示が強くても、電波干渉が少ないとは限りません。ルーターに近づく、安定した周波数帯に切り替える、一時的に有線接続にすることで、ローカルの無線環境を確認できます。同じ接続先がスマートフォンのテザリングでは安定し、自宅のWi-Fiでは途切れる場合、まずローカルのネットワーク経路を調べます。社内ネットワーク、共有回線、夜間の混雑も、利用可能な通信速度に影響します。混雑時に一度測定結果が悪かっただけで、インターネット上の「高速設定」をすべて適用しないでください。

次に、システムのタスクマネージャーまたはアクティビティモニタで、CPU、メモリ、ディスクに継続的な負荷がかかっていないか確認します。多数のプロキシ接続があると、クライアントの画面、コア、ほかのセキュリティソフトが同時にリソースを消費することがあります。ログの詳細度を一時的に下げ、スクロールし続けるデバッグ画面を閉じてから、実際の通信を確認してください。速度測定のために必要なセキュリティ保護を無効にしないでください。画面の表示だけが重く、ネットワークリクエストは正常なら、UIの性能とコアの転送処理を分けて対処します。

ルール、プロトコル、大容量データ転送を確認する

特定のWebサイトだけ遅く、ほかは正常な場合は、異なるコンテンツ配信ドメインを使っているか、一部のリソースが別の接続先に振り分けられていないかを確認します。ブラウザーのページは複数のドメインへ同時に接続することがあります。トップページのドメインはプロキシ経由でも、画像や動画は直接接続され、テキストだけ先に表示される場合があります。接続一覧とログで該当するリクエストを確認し、実際に適用されたドメインのルールを調整してください。カスタムルールは先に適用される位置に置き、最後のフォールバックを残します。MATCHより後ろにルールを追加するだけでは解決しません。

システムプロキシでは正常なのに、TUNを有効にすると大容量ファイルの転送が止まりやすい場合は、まずTUNをオフにして比較し、ルーティングとMTUを確認します。MTUが合わないと小さなリクエストは通っても、大きなデータの転送が停滞することがあります。ただし、すべての速度低下に共通する原因ではありません。変更前に元の値を記録し、クライアントとネットワーク環境の案内に従って少しずつ試してください。他人の仮想ネットワークアダプターの設定をそのまま流用しないでください。UDPに依存する通信では、現在のネットワークの品質や速度制限も考慮します。

ブラウザーがQUICを使おうとしたり、アプリが独自にUDPセッションを確立したりする場合があります。こうした通信だけに問題があるなら、明示的な設定を持つテスト用アプリで該当機能を一時的に無効にして比較し、その後設定を戻してください。一度のテストを通すために、すべてのUDP通信をグローバルに拒否しないでください。通話、ゲーム、ほかのサービスに影響します。プロキシグループを切り替えたら接続を再確立します。実行中のダウンロードや動画の接続が、新しい接続先にすぐ切り替わるとは限りません。

特定のアプリだけが継続して遅い場合、そのアプリ独自のプロキシ設定やキャッシュを消す前に、ほかのアプリの同種のリクエストが正常か確認します。プラットフォームによっては、出口IP、アカウント、コンテンツサーバーに応じて異なる経路が割り当てられます。接続先を変えて一時的に改善しても、クライアントの不具合とは限りません。安定した設定を優先し、アカウントの再認証や進行中の処理の中断につながる頻繁な再接続は避けてください。

DNSの問題：システムの名前解決とコアの名前解決を切り分ける

ドメインの名前解決に失敗しても、すべての接続が失敗するとは限らない

よくある症状は、サーバーが見つからないという表示、ログのno such host、同じWebサイトが開けたり開けなかったりする、または到達できないアドレスに名前解決されることです。まずドメインの入力ミスを確認し、エラーがプロキシサーバーの名前解決と最終的なWebサイトの名前解決のどちらで起きたかを切り分けます。プロキシサーバーのドメインを解決できない場合、すべての接続先に影響する可能性があります。特定のWebサイトだけの名前解決に失敗する場合は、その接続先だけの問題かもしれません。IPアドレスを直接開いても、HTTPS証明書、バーチャルホスト、コンテンツ配信がドメイン名に依存するため、ドメインのテストを完全には代替できません。

システムDNS、ブラウザーのセキュアDNS、mihomo内蔵DNSはそれぞれ異なる段階です。ブラウザーが暗号化された名前解決を独自に使うことがあり、アプリによってはシステム設定を経由しない場合もあります。そのため、システムの名前解決に成功してもブラウザーが同じ経路を使うとは限りません。システムの名前解決が失敗しても、プロキシコアが解決できないとは限りません。Windowsではnslookup example.comでシステムの名前解決結果を確認できます。対応するツールがある環境ではdig example.comも使えます。コマンドの結果はクライアントのログと合わせて確認し、単独で結論を出さないでください。

ループ状の依存関係を解消してからキャッシュを確認する

暗号化DNSサービスは、それ自体が接続を確立する必要があり、サーバー名の名前解決が先に必要な場合もあります。プロキシ接続の確立にプロキシサーバーの名前解決が必要なのに、その名前解決にもまだ確立されていないプロキシが必要だと、依存関係が循環します。設定では、基本の名前解決、プロキシサーバーの名前解決、通常の接続先の名前解決に、それぞれ明確な経路を用意してください。すべてのDNSリクエストを強制的にプロキシ経由にし、プロキシサーバーのドメインまで同じ経路で解決するのは避けましょう。サブスクリプションを使っている場合は、まず元のDNS設定に戻し、必要な項目を1つずつ追加します。

DNSを変更した後も、古いキャッシュのため結果がしばらく変わらないことがあります。まずテストするアプリを再起動し、必要であればクライアントの説明に従ってコアのキャッシュを消去するか、コアを再起動します。Windowsでは必要と確認できた場合にipconfig /flushdnsを実行し、システムの名前解決キャッシュを消去できます。ただし、すべてのブラウザーやアプリのキャッシュが同時に消えるわけではありません。キャッシュの層を確認せず、ネットワークアダプターを何度もリセットしないでください。処理のたびに同じドメインで再テストし、ログでリクエスト経路が変わったか記録します。

fake-ipとLAN内ドメインの例外を理解する

fake-ipモードでは、コアが予約済みアドレス範囲から割り当てたアドレスをアプリに返し、内部の対応表を使って元のドメインに戻すことがあります。これは通常の動作であり、そのアドレスが見えただけでDNS汚染とは判断できません。アプリがコアのルーティングを迂回し、割り当てアドレスに直接接続しようとすると失敗する可能性があります。通信の適用を解除した後も古い割り当てを保持しているアプリは、一時的に正常に動作しないことがあります。その場合は適切な通信の適用を戻すか、アプリの接続を再確立してください。割り当てアドレスをシステムのhostsファイルに追加する方法は避けましょう。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query

この設定例にはmihomoの関連項目を記載していますが、選択したDNSサービスに現在のネットワークから接続できることが前提です。すべてのネットワークに適した完全なDNS設定ではありません。必要な項目は既存のdnsマッピングに追加し、同じトップレベルキーを重複して作らないでください。LAN内の端末、社内ドメイン、分割DNSが必要な環境では、ルーターや社内DNSに問い合わせる必要がある場合があります。fake-ipの対象から除外しただけでは適切な内部DNSが自動で選ばれるわけではありません。実際の環境に合わせて名前解決のルールも設定してください。

TUNを有効にすると社内プリンター、NAS、社内ドメインに接続できなくなる場合は、まずTUNをオフにして確認し、DNSのリダイレクト範囲、内部ドメインの名前解決、プライベートネットワークへのルートを調べます。LAN内の通信まですべてリモートの接続先に送らないでください。社内ネットワークでは検索サフィックス、分割DNS、専用VPNが使われていることがあります。公共DNSに変更するだけでは、内部ドメインの名前解決がさらに難しくなる場合があります。組織管理の端末では、管理者の指示に従い、管理対象の設定を上書きしないでください。

ページに証明書エラーが表示されても、証明書検証を無効にして隠さないでください。システム時刻、実際のアクセス先ドメイン、証明書の発行先を確認します。DNSが誤ったアドレスを返している場合や、以前の中間プロキシ設定が残っている場合も、同様の症状が起こります。原因の切り分けにはHTTPS証明書エラーの解説をご覧ください。最終確認では、通常のWebサイト、プロキシが必要なサイト、LAN内のリソースをすべてテストします。一種類の名前解決だけを直して、ほかの通信を壊さないようにしてください。

システムプロキシが効かない：入口、ポート、通信の競合を確認

システムプロキシのスイッチは、端末全体の通信を切り替える機能ではない

クライアントの「システムプロキシ」は有効なのに、一部のプログラムは直接接続する、またはブラウザーは使えるのにターミナルやゲームは使えない症状です。システムプロキシは通常、OSの関連設定にローカルプロキシのアドレスを書き込みます。アプリがその設定を使うかどうかは、ネットワークの実装によって異なります。ブラウザー、システムサービス、コマンドラインツールでプロキシの仕組みが異なることもあります。まずブラウザーとプロキシを明示したリクエストで基準を確認してください。特定のプログラムのログがないからといって、すぐにコアの転送失敗と判断しないでください。

Windowsでは「設定 → ネットワークとインターネット → プロキシ」を開き、アドレスとポートが現在のクライアントと一致しているか確認します。macOSでは「システム設定 → ネットワーク」から使用中のネットワークサービスの詳細を開き、「プロキシ」を確認してください。OSのバージョンによって画面の場所が多少異なります。Wi-Fi、有線接続、ネットワーク環境を切り替えた場合は、どのサービスの設定が現在有効かも確認します。自動プロキシ構成スクリプトや手動プロキシの設定が、ほかのソフトや組織のポリシーから適用されている場合があります。変更前に元の設定を記録し、管理対象の端末ではポリシーを勝手に上書きしないでください。

実際に混合ポートを待ち受けているプロセスを確認する

クライアント画面にポート番号が表示されても、コアがそのポートの使用に成功したとは限りません。アドレスの競合、権限不足、コアの起動失敗がログに出ていないか確認します。以下のコマンドは混合ポート7897を例に、待ち受けプロセスを表示するだけのものです。プロセスを終了することはありません。Windows PowerShellでは最初のコマンドを実行します。lsofをインストールしたmacOSまたはLinuxでは2つ目のコマンドを実行してください。権限の制限で情報が不足する場合は、OSの手順に従って確認権限を上げてください。

Get-NetTCPConnection -LocalPort 7897 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

lsof -nP -iTCP:7897 -sTCP:LISTEN

ポートを以前のクライアントが使用している場合は、タスクマネージャーやアクティビティモニタでプロセス名を確認してから、旧クライアントを通常の方法で終了します。プロセス番号だけを見てシステムサービスを強制終了しないでください。空いている別のポートを使う場合は、アプリ側のプロキシ設定とターミナルのコマンドもすべて更新する必要があります。クライアントのポートだけを変更し、システムプロキシが旧ポートを参照したままだと、「コアは動作しているのにアプリが接続できない」状態になります。旧コアがポートを使用したままの場合は、別の設定にリクエストが送られる可能性もあります。

環境変数とTUNモードを段階的に確認する

ターミナルのプログラムはHTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYの一部またはすべてを参照する場合があります。現在のセッションに古いアドレスが残っていないか、特にコンテナー、リモート開発ツール、統合ターミナルで確認してください。環境変数はプロセス起動時に引き継がれるため、システム変数を変更しても、すでに開いているターミナルには自動反映されないことがあります。まずテストコマンド1つだけにプロキシを明示し、動作を確認してから、環境変数を恒久設定するか判断してください。

システムプロキシに従わないアプリの通信を取り込みたい場合は、TUNの使用を検討します。まずほかのVPN、ネットワーク高速化ツール、重複したTUNインスタンスを終了し、クライアントに必要な権限やサービスモードが正常か確認してください。TUNを有効にしたら、スイッチの状態だけでなく、仮想アダプターとルートが作成されているかも確認します。クライアントによってはシステムプロキシとTUNを併用できますが、原因を調べる際は先に別々にテストしてください。複数の入口を通ることで、遠回りしたり、別のツールに通信を書き換えられたりするのを防げます。

Linuxのデスクトップ環境に設定したプロキシも、すべてのプログラムが参照するとは限りません。コマンドラインアプリ、サンドボックスアプリ、システムサービスには個別の設定がある場合があります。コンテナー内の127.0.0.1はコンテナー自身を指し、ホストのClashを指すわけではありません。ほかの端末やコンテナーからプロキシに接続するには、待ち受けアドレス、ファイアウォール、アクセス制御も設定する必要があります。利便性のためにプロキシの入口をインターネットへ公開しないでください。LANからの接続も、信頼できる送信元に限定します。

最後に、ブラウザー、プロキシを明示したコマンド、以前使えなかったアプリをそれぞれ確認します。前の2つが正常で、対象アプリのログだけがない場合は、アプリ側の入口を重点的に調べます。TUNを有効にしたときだけ失敗するなら、サブスクリプションを何度も変更せず、ルート、権限、DNSを確認してください。この段階的な検証は、起動時にまれに発生する不具合にも有効です。ネットワークの準備ができていること、コアがポートを待ち受けていることを確認し、続けてシステムプロキシが正しく設定されているか調べます。

クライアントがクラッシュする・起動しない：設定を保護して原因を切り分ける

ウィンドウが閉じたのか、バックグラウンドで動いているのか、コアが終了したのかを確認する

ダブルクリックしてもウィンドウが表示されない場合は、タスクトレイやメニューバー、システムのプロセス一覧を確認します。ウィンドウを閉じてもバックグラウンドに常駐するクライアントでは、再度起動しても既存のインスタンスが表示されるだけです。画面が見えないからといって、クラッシュしたとは限りません。ウィンドウは表示されるのにコアが動作していない場合は、画面の再インストールではなくコアのログを確認してください。起動後すぐにプロセスが終了する場合は、起動時のクラッシュを調べます。最後に正常動作した後の変更、たとえばOSの更新、設定の移行、セキュリティソフトのインストール、異常終了を記録してください。

まずクライアントが案内するフォルダーの場所から設定とログを探します。フォルダーを開けない場合は、そのクライアントの説明を確認してください。別のソフトの保存先を参考にして、ファイルを直接削除しないでください。クライアントと関連するバックグラウンドプロセスを正常に終了し、設定フォルダー全体をローカルのバックアップ先にコピーします。中にはサブスクリプションの認証情報が含まれることがあるため、安全に保管してください。バックアップは復元用であり、公開の問い合わせ窓口にアップロードしないでください。ログだけ取得できる場合も、少なくとも最後に起動に失敗した前後の記録と、システムイベント情報を残します。

実行環境、アーキテクチャ、ブロック記録を確認する

Windowsでは、一部クライアントの画面表示にWebView2ランタイムが必要です。関連する読み込みエラーが出る場合は、OSまたはクライアントの案内にある正規の方法でランタイムを修復してください。別のクライアントが起動するからといって、現在のクライアントに必要な実行環境がそろっているとは限りません。次に、インストーラーのアーキテクチャがOSに適合しているか、アーカイブが書き込み可能なフォルダーに正しく展開されているか確認します。圧縮ソフトの一時プレビュー内から実行すると、リソースファイルやデータフォルダーを使用できないことがあります。

macOSでは、アプリが適切な場所に配置されているか、システムのセキュリティ設定にブロック理由が記録されていないか確認します。セキュリティの警告が出た場合は、インストール元を確認してください。システム保護をまとめて無効にしないでください。Linuxでは、パッケージの依存関係、デスクトップ環境、ファイル権限の問題を切り分けます。ターミナルから起動すると、画面には表示されない依存関係のエラーを確認できることがあります。ディストリビューションやデスクトップ環境ごとの差が大きいため、実際のエラーに応じて不足している依存関係だけを追加し、デスクトップ環境全体を再インストールするのは避けてください。

セキュリティソフトがコアを隔離すると、ウィンドウは正常でも接続に失敗する場合があります。隔離の記録とファイルの入手元を確認してから対処してください。ディスク全体を除外フォルダーに追加しないでください。ポートの競合でコアが起動できない場合は、ポートの待ち受け確認を行い、古いインスタンスが使用していないか調べます。サービスモードでは、画面とバックグラウンドサービスが別々に動作することがあります。更新後にパスが一致しなくなった場合は、クライアントのサービス管理機能を使って修復してください。

新しいユーザー設定で比較する

実行環境に明らかな問題がない場合は、バックアップを保管したまま元の設定フォルダー名を変更し、クライアントが対応する方法で新しいユーザー設定を作成します。必ず完全に終了してから行ってください。データベースが書き込み中の状態で、フォルダーを移動しないでください。新しい設定で起動できるなら、旧設定の状態、オーバーライドスクリプト、破損した設定、画面の保存データに原因がある可能性が高まります。その後、信頼できるサブスクリプションを1つだけインポートし、正常動作を確認してからカスタムルールや設定を1つずつ戻してください。旧フォルダーを丸ごと上書きしないでください。

新しい設定でも起動しない場合は、システムのアプリケーションログ、空きディスク容量、フォルダー権限を確認します。システムドライブの空き容量がないと、設定を書き戻せないことがあります。保護されたフォルダーが必要なデータの更新を妨げる場合もあります。以前に管理者権限で実行し、その後通常ユーザーで起動するようになった場合、データファイルの所有者や権限が一致しないことがあります。修復はクライアントのデータフォルダーだけに限定してください。ユーザーフォルダー全体に広い書き込み権限を付与したり、システムフォルダーに再帰的な権限変更を行ったりしないでください。

再インストールが必要な場合は、まず旧プログラムを通常の方法でアンインストールするか終了し、クライアントの説明に従ってサービスを処理してから、インストーラーのダウンロードページで適切なビルドを選びます。新規インストールにはClash Plusがおすすめです。Clash Verge RevやFlClashをすでに使っている場合は、まず現在の環境を修復する方法もあります。アーカイブされたクライアントで新しいOSとの互換性に問題が起きた場合、同じソフトを再インストールしても解決しないことがあります。セキュリティ機能を無効にしたまま使うのではなく、設定の移行を検討してください。

モバイル端末のトラブル：VPN権限、バックグラウンド制限、ネットワーク切り替え

Androidで接続済みなのにアプリからアクセスできない

AndroidのVPNアイコンは、システム側で通信の取り込みが開始されたことを示すだけです。サブスクリプション、接続先、DNSが正常とは限りません。まずクライアントを前面で起動したまま、インポート済みの設定を選び、ブラウザーでテストしてログを確認します。ブラウザーでは正常なのに特定アプリだけ失敗する場合は、「アプリごとのプロキシ」や除外アプリ一覧を確認し、対象アプリが除外されていないか調べてください。クライアントによって「選択したアプリのみをプロキシ経由にする」方式と「選択したアプリを除外する」方式があります。現在のモードを先に確認してください。

初回接続時にシステムからVPN接続の許可を求められます。拒否した場合は、システムプロキシのような設定だけを有効にするのではなく、クライアントから接続をやり直してください。Androidでは通常、複数の一般的なVPNアプリが同時に通信を取り込めません。同種のプロキシ、VPN方式のフィルター、社内ネットワークへの接続は、互いの設定を置き換えることがあります。テスト中は通信を取り込むツールを1つだけにしてください。仕事用プロファイル、管理対象の設定、常時接続VPNには別の制限がある場合があります。管理対象の端末では組織のポリシーを確認し、管理コンポーネントを無理に削除しないでください。

画面ロック後に通信が切れる・ネットワーク切り替え後に復旧しない

画面を表示している間は正常で、ロック後に切断される場合は、バッテリー最適化、バックグラウンド実行権限、メーカー独自の自動起動管理を優先して確認します。クライアントがシステムの要求するフォアグラウンドサービス通知を表示し続けているかを確認し、OSの説明に従って必要なバックグラウンド動作を許可してください。切断の原因はバッテリー最適化だけとは限りません。ネットワークのスリープ、Wi-Fiとモバイル通信の切り替え、上流側セッションの期限切れでも似た症状が起きます。ロックした時刻、ネットワークの種類、アプリに戻るとすぐ復旧するかを記録してテストします。

Wi-Fiからモバイル通信に切り替えると、既存のTCPまたはUDPセッションをそのまま再利用できない場合があります。新しいネットワークではアドレス、ルート、DNSがすべて変わっています。まず対象アプリに接続を再確立させ、必要であればクライアントを切断してから再接続してください。接続が再確立されていない間に複数のノードを次々と切り替えると、ネットワーク切り替え自体の問題が見えにくくなります。特定のWi-Fiだけで失敗する場合は、同じ接続先をモバイル通信で比較し、Wi-Fi側にWeb認証が必要か、特定の通信方式が制限されていないか確認します。

システムの「プライベートDNS」とクライアント内蔵DNSが同時に名前解決へ影響することがあります。ドメインの問題が起きたら、まず現在の設定を記録し、自動モードとクライアント推奨設定をそれぞれ試してください。すべてのDNSを異なるサービスに同時変更したままにしないでください。モバイルネットワークではIPv6が使われることがあります。一部のドメインやプロトコルだけが失敗する場合は、接続先と通信の取り込み方式がIPv6に対応しているか確認します。ある箇所でIPv6を無効にしても、ほかのコンポーネントが引き続きIPv6アドレスを優先しないか注意してください。

iOSの通信取り込み状態と設定を確認する

iOSではiOSのインストールページからClash Plusを選べます。製品情報はclashplus.ioをご覧ください。インストール後、サブスクリプションをインポートして設定を選び、システムの案内に従ってVPN構成の追加を許可します。システム上は接続中でもページを開けない場合は、「対象リクエスト、ログ、ルール、接続先」の順に確認してください。システムの接続状態だけでは、リモートサービスへの接続が成功したとは判断できません。

端末に複数のVPN構成がある場合は、実際に有効な構成を確認します。必要に応じて自動接続のルールが別の通信制御を開始していないかも調べてください。業務端末では管理対象のVPNが使われていることがあります。一般ユーザーが勝手に削除してはいけません。プライバシー保護機能、構成プロファイル、コンテンツフィルターもリクエストの経路を変える場合があります。テストへの影響が明確な場合にだけ一時的に調整し、テスト後は元に戻してください。システムが通信の取り込みを拒否する場合は、ほかのVPNを通常の方法で切断してから、あらためて許可して接続します。

モバイル端末では、クライアントのモバイルデータ使用が禁止されていないか、サブスクリプションの更新がWi-Fi接続時のみに制限されていないか、省データモードがバックグラウンド処理に影響していないかも確認します。モバイル通信でだけ更新に失敗する場合は、まずサービスのURLに接続できるかテストしてください。すぐにアプリを削除しないでください。アンインストールすると、ローカル設定やルールも消えることがあります。再インストールする前に、クライアントが対応するエクスポートまたはバックアップ機能で必要な設定を保存し、認証情報を安全に保管してください。

問い合わせる場合は、端末のOS、クライアント名、ほかのVPNの有無、失敗するアプリ、ネットワークの種類、同じ時間帯の個人情報を隠したログをまとめてください。初期設定の確認が必要な場合は、はじめての設定ガイドをご覧ください。サブスクリプションまたは接続先の問題と確認できている場合は、ネットワークを変えて比較した結果を添えて、該当するサービス提供元に問い合わせます。複数の端末を同時にリセットするより、直近で使えた設定を保管しておくほうが復旧に役立ちます。