トラブル対処ガイド · 症状から探す

Clash トラブル対処ガイド

接続状況から設定、プロキシの経路、ネットワークの問題を切り分けます。設定は一度に一つだけ変更し、その都度動作を確認してください。

初めてのインストールや設定のインポートは、まずClashのインストールガイドに沿って進めてください。このページでは、クライアントのインストール後に問題を調べる手順を説明します。まず影響範囲を確認し、ログを調べてから設定を変更します。クライアントによってメニュー名は異なるため、ここでは設定項目の意味とコアのフィールドを基準にしています。

調査を始める前に、クライアント名、OS、現在のモード、使用中の設定ファイル、問題が発生した時刻を記録してください。設定をエクスポートする場合は、サブスクリプションURL、認証情報、ノードの接続情報を削除してください。スクリーンショットでも同様に隠します。元に戻せる設定を一つ保管し、変更を重ねて原因が分からなくなるのを防ぎましょう。

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

「Clashを起動したらネットに接続できなくなった」といっても、原因は一つとは限りません。ブラウザーが終了済みのローカルプロキシを参照している場合や、コアは正常に待ち受けていても通信先がない場合があります。まず、どのアプリで問題が起きるか、すべてのサイトで失敗するか、クライアント終了後に復旧するかを記録してください。特定のサイトだけの問題と、システム全体のネットワーク障害では調べる場所が異なります。いきなり再インストールや設定の全消去、システムDNSの変更を行うと、複数の条件が同時に変わり、原因を判断できなくなります。

まず直結を復旧し、ローカルプロキシの接続先を確認する

クライアントでシステムプロキシとTUNモードを無効にし、通常の手順で終了してください。OSのネットワーク設定を開き、手動プロキシが残っていないことを確認してから、普段プロキシなしでアクセスできるサイトを開きます。それでも失敗する場合は、Wi-Fiのログイン認証が完了しているか、ゲートウェイに到達できるか、ほかの端末でも通信できないかを確認します。この段階ではClashの問題と断定できません。まず基本的なネットワーク接続を復旧してください。会社や組織の管理端末では、自動設定スクリプトやプロキシ設定を保持し、組織から配布されたポリシーを削除しないでください。

直結が復旧したら、クライアントを一つだけ起動し、TUNはまだ有効にしないでください。実行ログで設定の読み込みが完了していることを確認し、設定画面で混合ポートを確認します。ここでは待ち受けポートが7890の場合を例に、ローカルHTTPプロキシをテストします。ポートが異なる場合は数字を置き換えてください。このリクエストはプロキシ経由で応答を受け取れるかを調べるためのもので、すべてのアプリがプロキシを利用していることを示すものではありません。リダイレクトが返ってきた場合も、HTTPレベルの応答が得られたことを確認できます。

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

Windows PowerShellでは、ほかの同名コマンドが実行されないよう、同じ引数をcurl.exeで実行できます。ローカルポートに接続できない場合は、コアが起動しているか、ポートが変更されていないか、セキュリティソフトがローカルでの待ち受けをブロックしていないかを確認してください。ローカルには接続できても、その後のハンドシェイクがタイムアウトする場合は、アプリからプロキシへの接続後に問題が起きています。ノードのタイムアウトを確認してください。ブラウザーのプロキシ拡張を何度も切り替える必要はありません。

モードを切り替えてルールの影響を確認する

システムプロキシを有効にしたら、まずルールモードで同じURLにアクセスし、次に一時的にグローバルモードへ切り替えてください。グローバルのポリシーグループで、実際に利用できるノードが選択されていることも確認します。グローバルでは接続できるのにルールモードで失敗する場合は、ルールの適用結果、ポリシーグループの参照先、ルールデータベースの読み込み状況を確認します。どちらのモードでも失敗する場合は、ノード、DNS、ローカル接続を優先して調べてください。グローバルモードでも、アプリがクライアントに接続されている必要があります。システムプロキシを無視するアプリの通信まで自動的に取り込むわけではないため、モード名だけで通信経路を判断しないでください。

接続一覧で直前にアクセスしたドメインを探し、適用されたルール、出口のポリシー、エラーログを確認してください。出口がDIRECTで、その宛先へ直結できない場合は、すべてのドメインを恒久的にグローバル経由にするのではなく、ルールを修正します。ルールは通常、記載順に評価されます。前方の広いルールが後方の詳細なルールに先に適用されることもあります。変更前に、参照先のポリシー名が現在の設定に存在することを確認してください。ルール内の名前は、ノード名またはポリシーグループ名と一致している必要があります。

問題の範囲に合わせて変更箇所を絞る

特定のブラウザーだけで失敗する場合は、プロキシ拡張のない別のブラウザーでも試し、拡張機能、独立したDNS設定、キャッシュを確認してください。特定のサイトだけで失敗する場合は、サイト側のメンテナンス、証明書エラー、アカウント制限も確認します。証明書の警告が表示されたら、まずシステム時刻を確認してください。アクセスを復旧するために証明書の検証を無効にしてはいけません。詳しくはHTTPS証明書エラーの原因と対処法をご覧ください。サイト側のアクセス拒否画面を、端末全体のネットワーク障害と誤認しないようにしましょう。

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

ノードのテストがタイムアウトした場合、テストリクエストが制限時間内に完了しなかったことを示すだけで、ノードの停止を意味するとは限りません。テスト先、DNS、サーバーのポート、プロトコルのハンドシェイク、接続先サイトのいずれも同じ表示の原因になり得ます。まずノードを一つ選んで実際にアクセスし、問題発生時のログと照らし合わせてください。サブスクリプション全体に何度も同時速度テストを行うのは避けましょう。大量の同時テストで制限がかかることがあり、現在の通信と無関係なエラーがログに混ざって原因を特定しにくくなります。

エラーが発生した段階をログで確認する

ログ設定を一時的にinfoレベルにし、失敗した操作の時刻と接続先を記録してください。ノードのドメインを名前解決できない場合は、まずDNSを確認します。サーバーへの接続がタイムアウトする場合は、現在のネットワークからサーバーに到達できるか確認してください。接続後にTLSや認証のエラーが発生する場合は、プロトコル設定、時刻、サブスクリプションの状態を確認します。必要に応じて一時的にdebugに切り替えますが、詳細ログを長期間有効にしたり、完全なアドレスや認証情報を含むログを公開したりしないでください。

ログの手がかり優先して確認する項目この情報だけでは判断できないこと
dial timeoutサーバーアドレス、ポート、現在のネットワーク経路クライアントのインストール破損とは限らない
connection refusedサーバーが待ち受けているか、ポートが正しいか、接続を拒否されていないかDNSの異常とは限らない
no such hostドメイン名のスペル、リゾルバー、名前解決の経路サーバーが停止したとは限らない
TLS handshake 関連のエラーシステム時刻、サーバー名、プロトコル設定、サーバー側の設定証明書の検証をそのまま無効にしない

エラーメッセージは前後のログと合わせて読んでください。同じtimeoutでも、ノードへの接続で発生する場合と、接続先からの応答待ちで発生する場合があります。ログに記録されたリモートアドレスを調べ、ノードのサーバーと接続先サイトを区別してください。具体的なフィールドはコアやクライアントによって異なるため、英単語一つを検索しただけで結論を出さないでください。Clashの実行ログの見方も参考に、「時刻、接続先、ポリシー、エラー」の4項目を整理しましょう。

一度に一つだけ条件を変えて原因を絞る

クライアントと設定はそのままにして、現在のWi-Fiからスマートフォンのテザリングに切り替え、同じノードで同じURLをテストしてください。テザリングでは成功し、元のネットワークで失敗する場合は、元のネットワークの出口、ファイアウォール、DNSを優先して確認します。どちらのネットワークでも失敗する場合は、別のノードで比較してください。一部のノードだけで失敗するなら、ノードのメンテナンス、アカウントの有効期限、接続制限についてサービス提供元に確認します。ノード一つの不調を理由に、システム全体のネットワーク設定を変更しないでください。

WindowsではTest-NetConnection、macOSやLinuxではncを使い、既知のサーバーのTCPポートを確認できます。自分の設定にあるサーバーアドレスとポートを指定し、ノードの認証情報を公開の端末に貼り付けないでください。TCPで到達できても、アプリケーションのプロトコル、認証、通信の転送が正常とは限りません。また、UDPベースの通信が使えるかどうかは、TCPテストでは判断できません。ICMP pingが無効でも、ノードがプロキシとして正常に動作する場合があります。

プロトコルの互換性と自動選択を確認する

設定をインポートできても、現在のコアがすべてのプロトコル項目に対応しているとは限りません。別のクライアント由来の設定、サブスクリプション変換を経た設定、新しいプロトコルを含む設定では、未対応のタイプ、必須項目の不足、ハンドシェイクの非互換を示すログがないか確認します。利用中のプロジェクトで保守が続いているリリース版に更新するか、現在のコアに適合する設定をサービス提供元から入手してください。クライアントを変更する場合は、まずインストーラーのダウンロードページでClash Plusを確認し、必要なプロトコルに対応しているかを調べてください。出所不明のコアファイルを混在させないでください。

自動選択ポリシーには、前回のテスト結果が残っていたり、実際の用途と異なるURLが測定先に設定されていたりする場合があります。一時的に動作確認済みのノードを手動で選び、今回の調査に不要な自動切り替えを停止して、実際の接続を確認してください。ノード接続後、大容量通信のときだけ切断される場合は、パケットロス、パスMTU、サーバー側の上限も調べます。速度テストの間隔をさらに短くするのは避けましょう。対処後はテスト設定を元に戻し、新しい接続が現在の選択ノードを使っていることを確認してください。

サブスクリプションの更新失敗：ダウンロード・解析・適用を分けて確認する

サブスクリプションの更新には、リモートからデータを取得する、設定として解析する、選択した設定をコアに読み込ませる、という3つの処理があります。ダウンロードは完了したが設定が適用されない場合と、サブスクリプション自体を取得できない場合は別の問題です。まず設定画面に表示された最終更新結果と実行ログを確認し、どの段階で失敗したかを判断してください。サブスクリプションを何度も削除して追加し直すと、ローカルの上書き設定、ルールの選択、履歴設定まで削除され、使用可能なキャッシュ設定を復元できなくなることがあります。

データを取得できない場合はURLと接続経路を確認する

サービス提供元のアカウントページからサブスクリプションURLをもう一度コピーし、先頭や末尾に不足がないか、コピー時に改行が入っていないかを確認してください。QRコードから読み取った場合も、WebページのURLではなくサブスクリプションURLであることを確認します。サブスクリプションには認証情報が含まれることがあるため、オンライン診断サイトや公開の変換ページに貼り付けないでください。サポートに問い合わせる場合は、エラーコード、発生時刻、マスキングしたドメイン情報だけを伝えます。URLのパスやクエリパラメーターにも機密情報が含まれる可能性があります。

HTTPステータスコードが表示された場合は、その意味に応じて対処してください。認証関連のエラーでは、まずアカウントとURLが有効か確認します。アクセス頻度の制限が原因なら、時間を置いてから更新してください。サーバーエラーの場合は、現在の設定を保持します。サービスのWebサイトをブラウザーで開けても、異なるドメインや認証方式を使うサブスクリプションAPIにアクセスできるとは限りません。ブラウザーに何らかの内容が表示されても、設定が正しいとは限りません。ログイン画面や認証画面でも、正常なステータスが返ることがあります。

サブスクリプションのドメインへのアクセスにプロキシが必要な場合は、利用可能な設定で接続してから更新してください。クライアントが更新リクエストを直結に固定している場合は、サブスクリプションのダウンロード設定を確認します。逆に、現在のプロキシが機能していないときにそのプロキシ経由でダウンロードしようとすると、接続が循環して失敗することがあります。クライアントに直結・プロキシの切り替え機能があれば、まずそれを使って比較してください。複数のクライアントを同時に起動して「中継」させると、ローカルポートやシステムプロキシが互いに上書きされるおそれがあります。

データを取得できても形式エラーになる場合

解析に失敗した場合は、完全なYAML設定、ノード一覧、クライアント専用の共有形式を区別してください。これらは常に同じインポート方法を使えるとは限りません。完全な設定は設定管理に読み込み、プロキシプロバイダーはメイン設定から参照する必要があります。ノード一覧をポリシーグループやルールを含むメイン設定として読み込むと、必須項目がない、ポリシーが見つからないといったエラーが発生する場合があります。提供元のインポート手順を確認し、現在のクライアントに対応すると明記されたURLを選んでください。ファイルの拡張子だけで形式を判断しないでください。

YAMLはインデントとデータ型に厳密です。手作業で編集する場合はタブではなく半角スペースを使い、リスト項目と上位フィールドの階層に注意してください。チャットアプリからコピーした全角コロンやスマートクォートが混入しないようにしましょう。エラー行はパーサーが問題を検出した場所にすぎず、実際には一つ前の行で記号が抜けていることもあります。インデントを直すために、すべての引用符をまとめて置き換えないでください。パスワード、正規表現、特殊文字を含む名前などは、引用符が必要な場合があります。

更新後、コアが実際に使用している設定を確認する

設定一覧に戻り、更新した項目が選択されていることを確認してから、ログで再読み込みが完了したか確認してください。クライアントによっては、ファイルを更新しても現在の設定が自動で切り替わりません。画面に表示されたノード一覧が別の設定から読み込まれている場合もあります。ポリシーグループ名と新しい接続の出口を確認してください。以前から開いたままのWebページだけで判断しないようにしましょう。既存の長時間接続は、古いポリシーを使い続けることがあります。テスト用のタブを閉じ、新しくリクエストを実行してください。

更新後にノードは表示されるのにルールが消えた場合、ローカルの上書き設定がrulesやproxy-groupsのリスト全体を置き換えていないか確認してください。配列を置き換えるか追加するかはクライアントのマージ方法によって異なり、どのクライアントも同じとは限りません。まず上書き設定を一つだけ無効にして比較し、サブスクリプション側の問題かマージ後の設定の問題かを切り分けます。修正後は、長期的に保持するローカル設定をクライアントが対応する上書き場所に置いてください。次回の更新で再び上書きされるのを防げます。

インポート方法や設定の選択を確認するには、インストール・設定ガイドをご覧ください。形式の違いや日常的な更新については、ヘルプセンターのインストール・設定に関するFAQも参考になります。サブスクリプションのダウンロードが復旧したら、適切な自動更新間隔を設定してください。更新頻度を上げることは、ノードのタイムアウトやアカウントの問題に対する万能な解決策ではありません。

速度が遅い：応答遅延と継続的な転送を切り分ける

Webページの表示が遅い、動画が途中で止まる、大容量ファイルのダウンロードが遅いといった症状は、原因が異なる場合があります。速度テスト画面のノード遅延はテストリクエストへの応答状況を示すもので、利用可能な帯域や特定サイトのCDNへの経路を保証するものではありません。最初の表示だけが遅いのか、転送中ずっと遅いのか、特定のアプリだけなのかを確認し、同じネットワーク、同じ接続先、同じ時間帯で比較してください。異なるサイトやファイルの結果をそのまま比べてノードの性能を判断しないでください。

まずローカルネットワークとバックグラウンド負荷を除外する

OSの更新、クラウドストレージの同期、ほかのダウンロードを一時停止し、Wi-Fiの電波が安定していることを確認してから、同じ接続先を再テストしてください。ノートPCでは一時的に有線接続へ切り替え、スマートフォンではWi-Fiとモバイルデータ通信を比較します。直結の通信も同時に遅い場合は、ローカルのネットワーク経路や通信事業者の出口を確認してください。プロキシ経由だけが遅い場合は、別のノードと比較します。テストはできるだけ一つずつ行ってください。複数の速度測定サイトを同時に使うと帯域を奪い合い、接続数の影響も受けやすくなります。

クライアントを実行している端末のCPUとメモリ使用率を確認してください。低消費電力のルーター、古いスマートフォン、仮想マシンでは、プロトコルの暗号化・復号や仮想ネットワークの負荷がボトルネックとなり、転送中に一つのCPUコアが高負荷のままになることがあります。端末全体の平均CPU使用率が低いという理由だけで、処理能力不足を除外しないでください。同じノードが一般的なPCでは正常なのにルーターで明らかに遅い場合は、DNSサーバーを何度も変更するのではなく、端末のリソースと設定の複雑さを確認します。

接続記録から実際の出口を確認する

接続一覧を開き、遅いリクエストにどのポリシーが適用されたか確認してください。自動選択、負荷分散、フェイルオーバーのグループでは、リクエストごとに異なる出口が選ばれることがあります。ブラウザーが切り替え前の接続を再利用している場合もあります。テストではノードを一つに固定し、実行中のダウンロードを終了してからリクエストをやり直し、結果を記録してください。グローバルモードはルールとの比較に使うもので、ルールの誤適用を隠すために常用しないでください。特に、本来直結すべき大容量のローカルサービスまでプロキシ経由にしないようにしましょう。

トップページは速いのに画像や動画が遅い場合は、ページ内のリソースに使われているドメインとルールを確認してください。一つのページが複数のドメインからコンテンツを読み込むことはよくあります。メインのドメインがプロキシ経由で正常でも、メディア用のドメインに同じポリシーが適用されるとは限りません。直結とプロキシが混在すると、接続の重複、アクセス地域の不一致、サーバーによるコンテンツの再選択が起きる場合があります。トップレベルドメイン全体の出口を変えるのではなく、実際に失敗したリソースに合わせてルールを調整してください。

症状主な確認項目比較方法
最初の表示は遅いが、その後は正常DNS、ハンドシェイク、キャッシュ同じドメインへの初回と2回目以降のリクエストを比較
開始直後は正常だが、その後速度が低下し続ける混雑、速度制限、端末の負荷テストを一つずつ実行し、リソース使用率を確認
特定のサイトだけ遅い接続先のサービス、CDN、出口までの経路ノードを変えずに接続先を変えて比較
大きなリクエストは止まるが、小さなリクエストは正常パケットロス、パスMTU、通信方式の互換性システムプロキシ経由とTUN経由の経路を比較

通信方式やTUNのパラメーター変更は慎重に行う

動画サービスや一部のブラウザーは、通常UDPを使うQUICを利用します。ノードや現在のネットワークでUDPの対応が不完全だと、応答待ちが繰り返されたり、別の通信方式に切り替わったりすることがあります。原因を示す根拠がある場合は、比較のためにアプリ内のQUICを一時的に無効にできますが、変更前の設定を記録し、テスト後に戻してください。TCPのダウンロードが正常でもUDPが使えるとは限りません。反対に、UDPを使う機能が一つ失敗しても、ノード全体が利用できないとは限りません。速度テストの順位だけで通信方式を選ばず、実際の用途に合わせて判断してください。

TUNを有効にした場合だけ問題が起きるなら、TUNを無効にして明示的なローカルプロキシを使った結果と比較してください。パスMTUが合わないと大きなパケットの再送が発生することがありますが、MTUの変更はあらゆる速度低下に有効なわけではありません。パケットキャプチャ、ネットワーク環境の説明、繰り返し行った比較で原因が示された場合に限り、一項目ずつ変更して元の値を記録してください。プロトコル、DNS、MTU、出口ノードを同時に変更すると、復旧しても原因を特定しにくくなり、次回の更新後に同じ問題が起きる可能性があります。

最後に、サーバーの処理容量、アカウントの通信量制限、接続先サイトのダウンロード制限を確認します。同じノードを複数の端末で同時に利用して遅くなり、ノードを切り替えると復旧する場合は、テスト時刻、接続先の種類、症状をサービス提供元に伝えてください。「接続確立まで時間がかかる」と「接続後の転送速度が遅い」を分けて説明すると、原因の特定に役立ちます。普段から速度テストを実行し続ける必要はありません。一度の測定結果より、実際の用途で安定しているかが重要です。

DNSの問題：名前解決元と実際の通信経路を確認する

DNSの不具合は、特定のドメインだけ開けない、ノードのドメインを名前解決できない、初回の接続に時間がかかる、ネットワークを切り替えても古いアドレスが返る、といった形で現れます。まず、システム、ブラウザー独自、コアの各DNSを区別してください。これらは同時に動作することがあり、使うサーバーも異なる場合があります。システムのコマンドで名前解決に成功しても、そのコマンドが使った経路が正常だと分かるだけで、Clashのコアが正しい結果を取得したとは限りません。ブラウザーで成功した場合も、独自のキャッシュが使われた可能性があります。

システム側の結果とクライアントの接続記録を比較する

プロキシによる通信の取り込みを無効にした状態で対象ドメインを名前解決し、使われたリゾルバーと返されたアドレスを記録してから、クライアントを有効にして該当する接続ログを確認します。以下のコマンドで確認できるのはシステム側の結果であり、コアのDNSサービスを自動的に問い合わせるものではありません。コアが待ち受けるDNSポートへ直接問い合わせる場合は、設定されている待ち受けアドレスとポートを確認し、ポートを指定できるツールを使ってください。コントローラーのポートをDNSポートとして指定しないでください。

nslookup example.com

fake-ipを有効にした設定では、クライアントがドメインとの対応付けに使う予約アドレスを返し、その後コアが接続先をドメインに復元することがあります。この結果だけでDNSの汚染と判断しないでください。重要なのは、その後の接続が同じコアに取り込まれ、ドメインとの対応付けが有効なままかどうかです。アプリが対応付け用のアドレスを取得しても、TUNやローカルプロキシを経由せず直接接続すると、失敗する場合があります。通信の取り込みを無効にした後も古い対応付けのキャッシュを使っていると、一時的にアクセスできなくなることがあります。

ブートストラップDNSと上流へのアクセスを理解する

暗号化DNSのサーバー名も、まず名前解決する必要があります。ノードのドメインを解決するリクエストが、まだ確立していないプロキシに依存すると、循環が起きる可能性があります。調査では、まずDNSの上流サーバーに到達できるか、ノードのドメインをどのリゾルバーが解決しているかを確認し、次にルールに基づくルーティング設定を確認してください。ネット上のDNS設定をそのままサブスクリプションに貼り付けないでください。特にproxy-server-nameserverなどのフィールドに現在のコアが対応しているか、元の設定に同じ機能がすでにあるか確認しましょう。

以下はmihomoを使うクライアント向けの設定項目例です。通常のドメインとプロキシサーバーのドメインで、名前解決元を分ける方法を示すもので、完全な設定ではありません。TUNもDNSの待ち受け先も設定していないため、システムの問い合わせを自動的に取り込むことはありません。既存の設定に統合するときは元のdns項目を編集し、ドキュメント末尾に同じトップレベルキーを追加しないでください。キーが重複した場合の動作は、パーサーによって異なることがあります。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://dns.google/dns-query
  proxy-server-nameserver:
    - 1.1.1.1

例に示した上流サーバーが現在のネットワークから到達できるか確認してください。特定のパブリックDNSを、どのネットワークでも使える正解と考えないでください。会社や学校のネットワーク、家庭内LANでは、内部ドメインの名前解決に専用DNSが必要な場合があります。上流サーバーをすべて置き換えると、一般のWebサイトに接続できても、プリンター、社内システム、ローカルドメインが使えなくなることがあります。その場合はパブリックサーバーを増やし続けるのではなく、ドメインに応じて内部の名前解決経路を残してください。複数の上流サーバーが記載順に単純な予備として使われるとも限りません。

キャッシュ、IPv6、DNS漏れの誤判定を除外する

名前解決の経路を変更したら、まず対象のアプリを再起動してください。必要に応じてシステムDNSキャッシュを消去してから、新しい接続でテストします。Windowsではipconfig /flushdnsを実行できます。systemd-resolvedを使うLinuxではresolvectl flush-cachesを使い、ほかのシステムでは各自のDNSサービスに応じて操作してください。キャッシュの消去は古い結果を削除するだけで、到達できない上流サーバーを修復するものではありません。変更直後に復旧した場合も、実際の経路をもう一度確認し、一時的なキャッシュの変化を最終的な解決とみなさないようにしましょう。

DNS漏れかどうかは、想定しているポリシーと合わせて判断してください。テストページに特定のリゾルバーが表示されても、そのテストリクエストの経路が分かるだけで、すべてのドメインの通信がプロキシを迂回しているとは限りません。ブラウザーのセキュアDNS、OSのプライベートDNS、TUNのDNSハイジャック対象、ルールによる振り分けが一致しているか確認します。IPv6も別に確認してください。IPv4だけを取り込む設定では、アプリがIPv6経由で別の経路を使う場合があります。IPv6を常に無効にするのではなく、クライアントとネットワークの対応状況を確認してください。

システムプロキシが機能しない：アプリがコアに接続しているか確認する

システムプロキシは、OSがアプリに提供するプロキシ設定であり、すべての通信を通すネットワークトンネルではありません。ブラウザー、コマンドラインツール、ゲーム、システムサービスでは、この設定への対応が異なります。そのため、スイッチがオンでも、クライアントが設定を適用しようとしたことが分かるだけで、すべてのプログラムが使っているとは限りません。まずクライアントの接続画面を開き、対象アプリから新しいリクエストを送信してください。対応する記録が表示されるかどうかが、通信経路を確認する重要な手がかりです。

まずシステム設定が正しく適用されているか確認する

OSのネットワークプロキシ設定を開き、アドレスがローカル端末を指しているか、ポートがクライアントの混合ポートと一致しているか確認してください。クライアントが別の端末で動作している場合に限り、その端末のローカルネットワークアドレスを使い、待ち受け設定とファイアウォールも別途調整します。127.0.0.1をリモート端末のアドレスとして使わないでください。常に現在の端末自身を指します。ローカルのブラウザーを接続するためだけにLAN接続を許可しても、待ち受け範囲が広がるだけで、ローカルポートの誤りは解決しません。

Windowsでは、ユーザーのプロキシ設定と、一部のサービスが使うWinHTTPプロキシは別の設定です。macOSのプロキシ設定は通常、ネットワークサービスごとに設定されるため、新しいWi-Fiや有線接続に切り替えた後は再確認してください。Linuxデスクトップ環境のグローバルプロキシも、端末のプログラムが参照するとは限りません。スイッチが勝手に戻る、ポートが元の値に戻る、プロキシアドレスが繰り返し変わる場合は、別のプロキシクライアント、ブラウザー拡張機能、組織のポリシーが設定を管理していないか確認します。

ログにローカルポートの使用中と表示されたら、まず使用しているプログラムを特定し、そのプログラムを終了するかポートを変更するか判断してください。Windowsではnetstat -anoで待ち受けとPIDを確認できます。macOSではlsof -nP -iTCP:7890 -sTCP:LISTENで指定ポートを調べられます。プロセス番号だけを根拠に、見慣れないシステムサービスを強制終了しないでください。混合ポートを変更した後は、システムプロキシ、ブラウザーの手動設定、端末の環境変数も更新します。詳しくはポート使用中のトラブル対処記事をご覧ください。

まず端末で一時的にプロキシを明示してテストする

端末のツールがシステムプロキシを使わない場合は、グローバルな環境変数を変更する前に、一回限りのコマンドでプロキシを明示してください。以下の2つのコマンドは、それぞれHTTPプロキシとSOCKSプロキシを使用します。socks5hの末尾のhは、接続先のドメイン名をプロキシ側で名前解決することを示します。ローカルで名前解決してから接続する場合との比較に使えます。実行前にクライアントが該当するプロトコルで待ち受けていることを確認してください。混合ポートでは通常、どちらの種類のリクエストも受け付けます。

curl -I --proxy http://127.0.0.1:7890 https://example.com
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

プロキシを明示すれば成功し、通常の実行では直結する場合は、ツール側のプロキシ設定を確認してください。HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYを確認し、大文字・小文字の環境変数やツール独自の設定ファイルも調べます。環境変数の優先順位はプログラムによって異なります。また、NO_PROXYに指定されたドメインがプロキシを迂回する場合があります。ブラウザーでは接続できてもGitで失敗する場合、Git独自のプロキシ設定が原因かもしれません。システムのスイッチだけを変更しても解決しないことがあります。

TUNが必要な場合は権限とルーティングを確認する

システムプロキシを参照しないアプリでは、クライアントの説明に従ってTUNを使えますが、先に基本的なプロキシ経路が正常であることを確認してください。有効にした後、権限、仮想ネットワークアダプター、ルートが実際に設定されているかを確認します。画面上のスイッチだけでは判断できません。ほかのVPN、仮想マシン、コンテナのネットワークがルート競合を起こす場合があります。関連する機能を一度に一つだけ停止して比較し、元に戻す手順を記録してください。正体の分からないネットワークアダプターを削除しないでください。企業VPNを併用する必要がある場合は、組織のネットワーク管理ルールに従ってください。

ブラウザーだけで問題が起きる場合は、拡張機能がプロキシを制御していないか、独立したセキュアDNSを使っていないか、古い接続が残っていないかも確認してください。拡張機能を読み込んでいない新しいプロファイルでテストする方が、シークレットウィンドウを使うより確実です。シークレットウィンドウでも実行できる権限を持つ拡張機能があるためです。ブラウザーと端末の詳しい比較手順はシステムプロキシが機能しない場合の対処記事を、基本設定の場所はガイドのシステムプロキシの項目をご覧ください。

調査が終わったらクライアントを通常の手順で終了し、システムプロキシが想定どおりに戻っているか確認してください。プロセスを強制終了したり、端末の電源が突然切れたりすると、停止済みのローカルポートを指す設定がシステムに残ることがあります。その結果、クライアントの終了後にかえってアクセスできなくなる場合があります。クライアントを再起動してシステムプロキシを正常に無効にするか、システム設定で元の値に戻してください。自動起動はプログラムを起動するタイミングを決めるだけです。設定の読み込み、コアの起動、システムプロキシの適用は、それぞれ別に確認してください。

クライアントのクラッシュ：画面・コア・システム環境を切り分ける

ウィンドウだけが消える、タスクトレイには残る、接続がすべて切れる、アプリが起動しないといった症状は、画面のプロセス、コアのプロセス、システムの実行環境のいずれかが原因かもしれません。まずタスクマネージャーまたはアクティビティモニタで関連プロセスが残っているか確認し、クライアントのログフォルダーで最後の記録を調べてください。何度も連続して起動したり、アプリのデータフォルダー全体をすぐに消去したりしないでください。元の設定、エラーログ、起動時の状態は、原因を特定するための重要な情報です。

発生条件を記録し、復旧できる状態を保つ

サブスクリプションの更新、TUNの有効化、テーマの切り替え、OSの更新、スリープからの復帰の直後にクラッシュしなかったか振り返ってください。再現できる操作が分かると、「ときどきクラッシュする」より原因を調べやすくなります。設定と必要なアプリ情報をバックアップしたら、プロキシによる通信の取り込みを無効にして起動してください。ウィンドウが安定して表示される場合は、機能を一つずつ元に戻します。クラッシュ後はシステムプロキシの設定が残っていないかも確認してください。ログを集めている最中にブラウザーへ接続できなくなり、別の障害と誤認するのを防げます。

インストーラーがOSとプロセッサーのアーキテクチャに合っているか確認してください。macOSではApple Silicon用とIntel用を区別する必要があります。Linuxではディストリビューション、パッケージ形式、グラフィカル環境も考慮してください。インストールに失敗したり起動直後に終了したりする場合は、システムに表示されるエラーを確認します。出所不明のサイトからランタイムやドライバーを入手したり、動的ライブラリを置き換えたりしないでください。インストーラーを変更する場合は、ダウンロードページでまずClash Plusを確認し、実際のプラットフォームと用途に合わせて、保守が続いているほかのクライアントと比較してください。

設定の読み込み失敗とアプリのクラッシュを分けて対処する

画面は正常に表示されるのにコアが繰り返し終了する場合は、設定の構文、参照ファイル、ルールプロバイダーのパスを確認してください。サブスクリプションから参照しているファイルをダウンロードできず、設定全体を読み込めないことがあります。設定フォルダーを手動で移動したことで、相対パスが無効になっている場合もあります。まず自動更新を一時停止し、バックアップにある動作確認済みの設定に戻して安定するか確認してください。負荷を減らそうとすべてのルールを削除するのではなく、ログに示されたファイルや項目から一つずつ復旧します。

クライアントに設定の検査機能があれば、まず設定を検査してからコアを再読み込みしてください。コマンドライン版のコアを使う場合は、バックアップ後に以下の構文チェックコマンドを実行できます。このコマンドは指定した設定を検査するだけで、通常の起動の代わりにはなりません。設定に相対パス、プロバイダー、外部データベースが含まれる場合は、使用環境に合わせて正しい作業ディレクトリも指定してください。GUIクライアントは追加のマージ処理で最終設定を生成することがあります。そのため、元のサブスクリプションを検査した結果と、実際に使われる設定を検査した結果が異なる場合があります。

mihomo -t -f config.yaml

コントローラーのアドレス、混合ポート、DNSの待ち受けポートが競合すると、コアが起動直後に終了することがあります。終了時のメッセージだけでなく、エラー全体を確認してください。複数のインスタンス、スタートアップタスク、サービスモードを同時に起動すると、ポートが競合しやすくなります。起動方法を一つだけ残し、古いプロセスがポートを使用していないことを確認してから再起動してください。ローカル接続の問題を解決するために、外部向けのコントローラーポートをインターネットに公開しないでください。起動障害とは関係ありません。

権限、リソース、画面の依存関係を確認する

TUNを有効にしたときだけ終了する場合は、クライアントのサービスが正しくインストールされているか、システムで必要な権限が許可されているか、セキュリティソフトのブロック記録がないか確認してください。必要なプログラムと操作に限って許可を追加し、すべての保護機能を無効にしないでください。Linuxでは一般ユーザーと管理者で起動した場合の設定フォルダーやファイル所有者の違いにも注意が必要です。以前に管理者としてGUIを起動したため、一般ユーザーが同じフォルダーに書き込めず、設定の保存や起動に失敗することがあります。

長時間動作した後にクラッシュする場合は、メモリ使用量が増え続けていないか、ディスク容量が不足していないか、ログが大量に蓄積していないか確認します。接続の詳細など頻繁に更新される画面を一時的に閉じたり、ログレベルを下げたりして、画面の更新とコアの接続負荷のどちらが原因か調べてください。書き込み中のデータベースファイルを直接削除しないでください。まずアプリを終了し、バックアップを取ってから、クライアントの説明に従って再生成できるキャッシュを削除します。削除前にフォルダーの用途を確認し、サブスクリプションやユーザー設定をキャッシュとして扱わないでください。

問題を報告する場合は、OSとアーキテクチャ、クライアント名、発生させた操作、TUNの有効・無効、機密情報を隠したエラー部分、別の設定で試した結果をまとめ、最小限の再現手順を用意してください。Clash for WindowsとClashX Metaは開発が終了しています。OSとの互換性に問題がある場合は、アーカイブ版を何度も再インストールするのではなく、別のクライアントへの移行を検討してください。移行前に元の設定を保存し、新しいクライアントの形式に合わせてインポートします。個人データのフォルダー全体をそのまま上書きしないでください。

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

モバイル端末では、システムVPN、バックグラウンド処理、ネットワークの切り替えが影響するため、デスクトップのシステムプロキシとは確認手順が異なります。まずアプリがVPN接続を実際に確立しているか、対象アプリが通信の取り込み対象かを確認してください。ステータスバーにVPNアイコンが表示されても、ノード認証、DNS、接続先への通信が成功しているとは限りません。使えるノードを一つ選び、ブラウザーと別のアプリでそれぞれテストしてください。一つのアプリの結果だけで端末全体の通信を判断しないようにしましょう。

AndroidでVPNの競合とバックグラウンド制限を確認する

Androidでは接続開始時にシステムVPNの許可が必要です。接続をタップしてすぐ停止する場合は、別のVPN、ファイアウォール、広告ブロッカー、パケットキャプチャアプリがシステムVPNを使用していないか確認します。リモートサーバーがないアプリでも、ローカルVPNを使って通信を処理することがあります。別のアプリを通常の手順で停止してからテストし、複数のアプリを何度も同時に有効にしないでください。仕事用プロファイルや端末管理ポリシーが設定されている場合は、その管理ルールにも従う必要があります。個人用の設定で仕事用プロファイル側の通信を変更できるとは限りません。

接続後、画面をロックすると通信が切れ、アプリに戻ると復旧する場合は、省電力設定、バックグラウンド実行の権限、アプリの強制終了を優先して確認してください。端末の設定でクライアントに必要なバックグラウンド動作を許可し、接続通知の状態も確認します。メーカーによって設定画面の名称が異なります。「通知を許可」だけでバックグラウンドの権限も十分だと判断しないでください。まず画面を短時間オンにしたままテストし、その後ロックして同じ操作を試します。画面ロック後だけ失敗する場合は、バックグラウンド制限が原因である可能性が高まります。

常時接続VPNやVPNを経由しない通信のブロックを有効にすると、クライアントの停止時に通信できなくなることがあります。まずシステムのVPN設定でこれらのオプションが有効か確認し、セキュリティポリシーとプログラムの障害を区別してください。調査のために無効にする場合は、直結通信に戻る可能性を理解し、テスト後に設定を元に戻します。アプリごとのプロキシ設定では、許可リストと除外リストも確認してください。対象アプリが除外されている場合、ほかのアプリがプロキシを使っていても自動的に経由することはありません。

iOSでVPNの接続状態とアプリごとのルールを確認する

iOSではダウンロードページでおすすめのClash Plusを確認できます。公式サイトはclashplus.io、インストール先はApp StoreのClash Plusページです。接続時は、システムが求めるVPN構成の許可を行い、アプリに戻って現在の設定とポリシーを確認してください。接続スイッチが勝手にオフになる場合は、別のVPNや構成プロファイルがネットワークを管理していないか確認します。アプリを繰り返しインストールするのは最初の対処法ではありません。

Safariや特定のアプリだけ挙動が異なる場合は、アプリのネットワーク設定、キャッシュ、通信経路に影響するプライバシー機能を確認してください。iCloudプライベートリレー、独自のDNS設定、ほかのネットワーク拡張機能によって、観測される出口が想定と異なる場合があります。ただし、出口確認ページの地域表示だけを根拠にプロキシの不具合と判断しないでください。まずクライアントの接続記録でドメインとポリシーを確認し、必要な場合だけ機能を一つずつ一時停止して比較します。変更前の設定も記録してください。

Wi-Fi・モバイルデータ通信・スリープの切り替えを確認する

Wi-Fiからモバイルデータ通信に切り替えると、IPアドレスやルートの変更によって既存の接続が切れることがあります。実行中のダウンロードや通話を一度止め、新しく接続してください。それでも失敗する場合は、アプリ内でVPNを切断してから再接続します。ネットワークへの接続にWeb認証が必要な場合は、認証を完了してからプロキシを起動してください。ホテル、空港、学校のネットワークでは、VPNによって認証画面へのリクエストがローカルのログイン画面に届かない場合があります。認証画面が開けないことを、すぐにノードの問題と判断しないでください。

クライアントにモバイルデータ通信の使用が許可されているか、現在のネットワークでデータセーバーやバックグラウンド制限が有効か確認してください。Wi-Fiでは正常でモバイルデータ通信では失敗する場合は、同じ設定と接続先を使って比較し、それぞれのネットワークでノードのドメインを名前解決できるか、到達できるか確認します。ネットワークによってIPv6、UDP、パスMTUの挙動が異なる場合があるため、デスクトップ版の設定をそのまま適用しないでください。同じノードで別の通信方式も比較し、必要であればネットワークの種類とエラーの発生時刻をサービス提供元に伝えます。

モバイル端末でサブスクリプションを再インポートした場合も、新しい設定が選択されていることを確認してください。VPN接続が古い設定を読み込んだままになっている可能性があります。システム上は正常なのに特定のアプリが接続できない場合は、システム権限をさらに広げるのではなく、ルールとアプリごとの設定を確認します。日常的なモード選択はルールモードとグローバルモードのガイドを、よくある利用上の注意点はヘルプセンターの使い方ガイドをご覧ください。最終的に有効だった権限、モード、ネットワーク条件を記録しておくと、OSの更新や端末の買い替え後に確認しやすくなります。