Clashのトラブルシューティングガイド：接続・サブスクリプション・DNS・システムプロキシ

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

プロキシを無効にしてネット接続を確認する

ブラウザーでどのページも開けない場合は、まずクライアントのシステムプロキシとTUNモードを無効にし、普段プロキシなしでアクセスできるサイトを試します。クライアントを終了しても、OSに手動プロキシの設定が残ることがあります。OSのネットワーク設定も確認してください。プロキシを無効にしても接続できない場合は、ノードの設定を変更する前に、Wi-Fiや有線LAN、ルーター、ネットワーク認証の必要性を確認します。

ホテルや学校、公共のWi-Fiでは、最初に認証ページを開く必要がある場合があります。プロキシやカスタムDNSの影響で認証ページに移動できず、Wi-Fiに接続済みでもWebページが開かないことがあります。プロキシを一時停止してネットワーク認証を済ませてから、クライアントを再開してください。同じネットワークにつないだほかの端末も直接接続できない場合は、まずネットワーク自体の問題を解決します。直接接続に問題がないことを確認してから、プロキシ経路を調べましょう。

プロキシを明示したリクエストで問題の箇所を絞り込む

クライアントを再開したら、コアが動作していることを確認し、設定画面で実際に使われている混合ポートを調べます。以下は一般的なローカルポートを使った例です。実際のポートが異なる場合は、コマンドを変更してください。1つ目はプロキシ関連の環境変数を無視し、2つ目はローカルのHTTPプロキシを明示して接続します。Windowsではcurl.exe、macOSとLinuxではcurlを使い、別のコマンドのエイリアスを同じものとして扱わないようにしてください。

curl --noproxy "*" -I --connect-timeout 10 https://example.com
curl -x http://127.0.0.1:7890 -I --connect-timeout 10 https://example.com

テスト先は、現在のネットワークからアクセスできると分かっているサイトに置き換え、2つのリクエストで同じURLを使います。2つ目のリクエストで直ちに接続拒否となる場合、ローカルの待ち受けポートかコアに問題がある可能性があります。プロキシ経由のリクエストがHTTPレスポンスを返すのにブラウザーでは失敗する場合は、ブラウザーの拡張機能、システムプロキシ、アプリ独自のネットワーク設定を確認します。サイトからアクセス拒否のステータスコードが返ることは、プロキシ接続の失敗とは異なります。

モード、ポリシー、ルールの適用状況を確認する

ローカルポートには接続できるのにサイトが開かない場合は、現在のモードがルール、グローバル、ダイレクトのどれかを確認します。ルールモードでは、接続ログに記録されたルールとポリシーグループを確認してください。メイン画面で選択されているノードだけでは判断できません。サブポリシーグループが停止中のノードを選んだままの場合や、直前に適用されたダイレクトルールに通信が振り分けられている場合もあります。接続ログの宛先ドメイン、ルール、最終的な接続先を順に確認します。

比較のため、一時的にグローバルモードに切り替え、利用できると分かっているノードを手動で指定する方法もあります。グローバルモードでは正常でルールモードでは失敗する場合、ルールの順序、ルールセットの読み込み、DNSを重点的に確認します。どちらも失敗する場合は、まずノード経路を調べてください。グローバルモードは原因の切り分けに使うもので、すべての問題に対する恒久的な解決策ではありません。比較後は元のモードに戻し、該当するルールを修正します。ダイレクト接続すべきサービスまでプロキシ経由にしないよう注意してください。

設定を戻す順序と確認の終了条件

一部のサイトだけ開けない場合は、サイト側の障害、接続元の地域制限、アカウントの利用権限を確認します。ブラウザーで証明書エラーが発生する場合は、端末の日付とタイムゾーンも確認してください。証明書の検証を無効にして解決しようとしてはいけません。別のVPNや高速化ツール、セキュリティソフトが動作している場合は、まず1つを終了して再テストします。複数のソフトが同時にデフォルトルートを変更すると、通信経路が競合することがあります。

手順を1つ終えるごとに、同じテスト先を使って再確認し、直接接続、プロキシを明示した接続、ブラウザーでの接続の結果を記録します。3つの方法で接続が復旧したら、ほかのネットワークツールを1つずつ再開してください。さらにサポートが必要な場合は、「接続できない」とだけ伝えるのではなく、エラーの全文と発生した段階を共有します。基本的な接続が復旧したら、システムプロキシ設定ガイドで普段の使い方を確認してください。

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

どのテストでタイムアウトしたかを確認する

クライアントのノード速度テストでは通常、指定されたURLにリクエストを送り、応答時間を計測します。実際のダウンロード速度を測るものではなく、すべてのアプリが同じノード経由でアクセスできることを保証するものでもありません。テスト先へのアクセス制限、想定外のレスポンス、短すぎるタイムアウト時間などが原因で、速度テストに失敗することがあります。まず実際に使うサービスへそのノードから接続し、テスト条件の問題かプロキシ経路の障害かを判断してください。

Webページを開けるのに速度テストだけがタイムアウトする場合は、テスト先のプロトコルと到達性を確認し、クライアントやサブスクリプション提供元が推奨する方法を使ってください。1つのノードを確認するために連続して一括測定するのは避けましょう。大量の同時テストは接続制限の対象になったり、ネットワークに負荷をかけたりすることがあります。まずノードを1つ選んでテストし、結果が出てから、利用可能と分かっている別のノードと比較します。

ログに記録された接続段階からサーバーへの接続を確認する

接続ログに記録されたDNSの名前解決失敗、接続拒否、ハンドシェイク失敗、読み書きのタイムアウトは、それぞれ異なる箇所の問題を示します。名前解決に失敗した場合、サーバーのアドレスを取得できていません。接続拒否は通常、宛先ポートが接続を受け付けていないことを示します。ハンドシェイク失敗は、プロトコルの設定、認証情報、端末の時刻、経路上の干渉などが原因となることがあります。画面上の赤いステータスだけでなく、特に最下層の原因を含むエラー全体を記録してください。

Windowsでは次のコマンドを使い、サブスクリプションに含まれるノードサーバーのTCPポートに接続できるか確認できます。アドレスとポートは実際のノード情報に置き換えてください。このテストで確認できるのはTCP接続の確立までで、プロキシ認証の成功は確認できません。UDPを主な通信方式として使うノードでは、TCPテストの失敗だけでノードが利用できないと判断しないでください。ノード情報を公開の掲示板に貼り付けないよう注意してください。

Test-NetConnection -ComputerName example.com -Port 443

サーバーにドメイン名を使っている場合は、想定される種類のアドレスに名前解決されているか確認します。IPv4だけが利用できるネットワークで、到達できないIPv6経路が優先されると、しばらく待った後に接続が失敗することがあります。設定を記録したうえで、クライアントのIPv6関連設定を一時的に変更して比較してもかまいません。ただし、一部のプロトコルではTLSハンドシェイクにもサーバーのドメイン名を使うため、サブスクリプション内のドメイン名を削除しないでください。

プロトコル設定とサブスクリプションの状態を確認する

ノードが下位レイヤーの接続を確立できても、ハンドシェイクで失敗する場合は、サブスクリプションを更新してアカウントの状態、有効期限、端末数の制限を確認します。ノード情報を手作業でコピーすると、暗号化方式、トランスポート方式、サーバー名、パス、公開鍵などの項目を見落としがちです。ほかのノードの設定を流用せず、現在のクライアントで使える完全な設定を再度インポートしてください。名前が似ている項目でも、プロトコルが異なれば互換性があるとは限りません。

新しいプロトコルの中には、比較的新しいコア機能が必要なものがあります。画面にノード名が表示されても、コアがすべての設定項目を読み込めているとは限りません。起動ログに、未対応のプロキシタイプや設定項目の警告がないか確認してください。開発が終了したClash for WindowsやClashX Metaを使っている場合は、元の設定を保存してからクライアントのダウンロードページでメンテナンス中のクライアントを試してください。一般的な用途にはClash Plusがおすすめです。

ネットワークとノードを交差してテストし、問題の範囲を絞り込む

同じ端末でスマートフォンのテザリングに切り替えて復旧する場合、元のネットワークの出口、認証、ルーティング、ファイアウォールを優先して確認します。ただし、テザリングと元のネットワークでIPの種類や経路が異なる場合があるため、この結果だけで特定の通信事業者によるノード制限と断定できません。クライアントと設定を変えずに、2つのネットワークの名前解決結果とエラーが発生する段階を比較すると、ネットワークの違いと設定の違いを切り分けられます。

1つのノードだけ失敗し、ほかのノードは使える場合は、全体のDNSやシステムプロキシを変更せず、そのノードの状態と設定を確認します。複数のネットワークで全ノードが失敗する場合は、サブスクリプションのアカウント状態とクライアントの互換性を調べてください。自動ポリシーグループが問題のあるノードを繰り返し選ぶこともあります。調査中は出力先を1つに固定し、復旧後にポリシーグループの種類と選び方を参考に、ノードのテスト方法を調整してください。

サブスクリプションの更新に失敗する：ダウンロード、解析、適用を切り分ける

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

サブスクリプションの追加は、リンク先の内容を取得し、設定を解析し、関連リソースをダウンロードして、有効な設定として適用する一連の処理です。更新ボタンにエラーが出ても、現在の設定が使えなくなったとは限りません。クライアントによっては、最後に正常更新した内容を保持します。まず設定の更新日時と有効状態を確認し、エラーの詳細を読みます。唯一使える古い設定を削除して、サブスクリプションを更新するための通信経路まで失わないようにしてください。

サブスクリプションURLをコピーするときは、空白、改行、日本語の句読点、チャットアプリが追加した説明文が含まれていないか確認します。URLのクエリパラメーターが認証情報として使われている場合があるため、勝手に削除したり、公開したりしないでください。提供元のサイトにログインして専用リンクを発行する必要がある場合は、指定された手順を使います。通常のWebページのURLはブラウザーで開けても、クライアントが解析できる設定を返すとは限りません。

ダウンロード失敗と更新経路のループを解消する

リクエストのタイムアウト、接続のリセット、名前解決の失敗が発生した場合は、まずサブスクリプションのドメインにアクセスできるか確認します。次に、クライアントが更新に使う通信経路が、直接接続、現在のプロキシ、カスタムのダウンロード経路のどれかを調べます。ネットワークからサブスクリプションサービスに直接接続できなくても、以前のノードが使えるなら、一時的にその設定経由で更新できます。逆に、以前のプロキシがすでに使えない場合、更新をプロキシ経由に固定するとループします。到達可能なダウンロード経路に切り替えてください。

認証失敗やアクセス拒否が発生した場合は、提供元でリンクの状態、アカウント制限、再発行の必要性を確認します。短時間にリクエストしすぎると、一時的に制限されることがあります。更新ボタンを連打しても復旧は早まりません。ログにサーバー証明書のエラーがある場合は、まずシステム時刻とネットワーク認証の状態を確認してください。証明書検証を常に無効にして更新を続けると、原因を隠し、接続の安全性を損なうおそれがあります。

設定ファイルの形式エラーとコアの互換性問題を切り分ける

ダウンロード後にYAMLの解析エラーが出た場合は、エラー行の前後にあるインデント、コロン、引用符を確認します。YAMLのインデントには通常スペースを使います。コードのコピー時にタブが混入したり、項目名に全角コロンが入ったりすると、ファイルを読み込めないことがあります。ただし、表示された行は解析が停止した場所にすぎず、実際の原因はその前の行にある場合もあります。最後に正常だったファイルを復元し、コピー上で修正してください。サブスクリプション全体を書き直さないようにしましょう。

取得した内容がログインページ、メンテナンスページ、構造化されたエラーメッセージの場合、それが設定ファイルとして保存され、後から解析エラーを起こすことがあります。インデントを何度も変更するのではなく、レスポンスの冒頭が設定ファイルの形式に合っているか確認してください。プロトコルの互換性に問題がある場合は、提供元がClashまたはmihomo向けとして案内する形式を選び、現在のクライアントのコアが該当項目に対応しているか確認します。

ノード一覧が表示されているのに設定を有効にできない場合は、ルールセットやプロキシプロバイダーが正常に読み込まれているかも確認します。設定本体、ノードプロバイダー、ルールプロバイダーが異なる場所から取得される場合があり、どれか1つの失敗が全体に影響することがあります。ログに特定のリソース名が記録されている場合は、そのリソースのパス、アクセス方法、形式を個別に調べます。すべてのエラーをサブスクリプションURLの問題として扱わないでください。

カスタムルールとセキュリティを維持する

サブスクリプションを更新すると、リモート管理されている項目が上書きされることがあります。ポート、LAN接続の許可、カスタムルールは、クライアントが対応するオーバーライド、マージ、拡張機能を使って保存してください。適用順序はクライアントの説明を確認します。ダウンロード済みファイルを直接編集しても、そのセッションでしか有効にならない場合があります。更新後にカスタムルールが残っているか確認し、テキストだけでなく接続ログで実際の適用状況を確かめてください。

設定に外部リソースやスクリプト拡張が含まれる場合は、提供元と用途を確認します。サブスクリプションURLは認証情報と同じように扱ってください。変換サービスにノード情報を渡す場合もあるため、信頼できないサイトに安易に共有しないでください。変換の必要性や対応形式についてはサブスクリプション変換に関するよくある質問をご覧ください。基本的な追加手順はサブスクリプションの追加ガイドで確認できます。

速度が遅い：ノード、回線、端末を順番に比較する

待ち時間、遅延、データ転送速度を分けて記録する

Webページの表示開始が遅い、動画が止まる、ファイルのダウンロードが遅いといった問題は、原因となる段階が異なることがあります。最初の読み込み待ちはDNS、ハンドシェイク、ルールリソースの読み込みなどが関係します。ダウンロード速度は主に回線の帯域、混雑、接続先サーバーの制限に左右されます。ノードの速度テストで表示される応答時間は、利用可能な帯域を示すものではありません。応答時間が短いノードでも、混雑時に転送速度が落ちることがあります。数値だけで速度の異常を判断しないでください。

比較する際は端末、接続先、テスト方法、時間帯をそろえ、変える条件は1つだけにします。同じファイルやサービスで2つのノードを比較し、次にノードを固定してネットワークを切り替えます。速度テストは大量の通信を発生させたり、サーバー側の速度制限を引き起こしたりする場合があります。テスト前にアカウントの利用可能量を確認してください。クラウド同期やシステム更新、帯域テストを同時に実行すると、端末内で帯域が分散され、速度が落ちることがあります。

まずノードと出口回線を確認する

特定のノードだけ遅い場合は、同じ地域や異なる回線のノードでも同様の現象が起きるか確認します。同じ地域にあるからといって経路が同じとは限らず、名前が異なっていても出口が別とは限りません。夜だけ遅く、ほかの時間帯に回復する場合は、回線の混雑やサーバー負荷を確認してください。終日、一定の速度上限で安定している場合は、プラン、接続先サービス、ルーターの速度制限、ローカル接続速度も調べます。クライアントが原因とは限りません。

特定のサイトやダウンロード元だけ遅い場合は、別のノードから同じリソースへアクセスして比較します。コンテンツ配信ネットワークでは、DNSや出口IPに応じて配信サーバーが割り当てられるため、ノードを変えると別のエッジサーバーにつながり、速度が大きく変わることがあります。この場合は、すべての通信をグローバルプロキシにするのではなく、対象サービスのポリシーを調整してください。まず適用ルールを確認し、そのサービス専用のポリシーグループが必要か判断します。

端末の負荷と接続方法を確認する

タスクマネージャーまたはアクティビティモニタで、クライアントのコア、ブラウザー、セキュリティソフトのCPU使用率を確認します。高い転送速度、複雑なルール、大量の同時接続は処理負荷を高めることがあります。詳細ログを長時間有効にすると、ディスクへの書き込みも増加します。原因を特定したら通常のログレベルに戻してください。CPU使用率が上限に近いのにネットワーク使用率が低い場合は、より速いノードを探すより先に端末側のボトルネックを調べます。

Wi-Fiの電波が弱い、同じ周波数帯で干渉がある、Bluetoothと干渉する、ルーターの性能が不足しているといった原因でも速度が不安定になります。可能であれば有線接続と比較し、ほかの端末での大容量通信を一時停止してください。システムプロキシとTUNモードを切り替えるときは、アプリが同じノードを経由していることを確認します。モードによってルールやDNS経路が異なる場合、速度差を接続方式そのものの優劣とは判断できません。

同時接続数、MTU、自動ポリシーの変更は慎重に

同時接続数を増やしても回線自体の帯域は増えず、サーバー側の接続制限にかかりやすくなることがあります。同時接続の設定は、現在のコアのドキュメントと実際のアプリの動作に基づいて変更してください。ほかのプロトコルで使われている値をそのまま流用しないでください。小さなページは開けるのに大きなファイルの転送が止まる場合や、特定のトンネルだけに問題がある場合は、経路MTUも確認します。まずほかのVPNを終了した状態で比較し、現在の値を記録してから範囲を絞って検証してください。

インターネット上で見かける固定のMTU値をそのまま設定することはおすすめしません。接続ネットワークやトンネルのカプセル化方式によって、有効なペイロードサイズは異なります。根拠なくMTUを下げると、一時的に問題を回避できても処理負荷が増えることがあります。TUNが原因だと確認できた場合は、クライアントが対応する診断方法でフラグメントとルーティングを調べ、元に戻せる設定を保ってください。Webページがときどき遅いというだけでは、システムのネットワーク設定を変える根拠になりません。

自動速度テストを行うポリシーグループは、テスト条件が変わるとノードを切り替えることがありますが、既存の接続が新しいノードに切り替わるとは限りません。テスト中はノードを固定し、終了後に自動選択へ戻してください。段階的な原因の切り分けと記録方法はClashの速度低下を段階的に調べる方法をご覧ください。速度テストの手順と基本的な比較方法はノードの速度テストガイドで確認できます。

DNSの問題：名前解決経路と接続先アドレスを確認する

エラーメッセージからDNSを確認すべきか判断する

ログに名前解決の失敗、ホストが見つからない、DNSクエリのタイムアウトが明記されている場合は、名前解決を確認します。接続先のIPアドレスに接続した後で認証に失敗している場合、まずDNSを変更する必要はありません。一部のサイトだけ開けず、ほかのサイトは開ける場合もDNSが原因の可能性がありますが、接続先サービスの障害、ルールの誤適用、到達できないIPv6経路でも似た症状が起きます。接続ログと合わせて判断してください。

システムDNS、ブラウザーのセキュアDNS、クライアント内蔵DNS、プロキシサーバー側の名前解決が同時に使われることがあります。コマンドラインで取得したアドレスが、ブラウザーで実際に使われるアドレスとは限りません。アプリがどこに問い合わせるか、その問い合わせがTUNに入るか、クライアントがマッピングアドレスを返すか、どの出力先が最終的な接続を確立するか、リクエスト経路を整理してください。システムDNSだけを変更しても、ブラウザーやクライアントが処理する問い合わせには影響しないことがあります。

fake-ipと実際のアドレス解決の仕組み

fake-ipを有効にすると、クライアントは予約済みアドレス範囲のマッピングアドレスをアプリに返し、その後の接続時に対応するドメイン名へ戻します。この結果は、ドメインが誤って名前解決されたことを意味するわけではありません。また、そのアドレスに対して直接インターネット接続をテストするべきではありません。マッピングアドレスが返された後、アプリの接続が同じクライアントを通るかが重要です。DNSはプロキシ経由で解決されるのに、接続がクライアントを迂回すると、マッピングアドレスを取得できてもアクセスできない場合があります。

LAN内のデバイス検出、特殊なドメイン名の利用、独自の名前解決テストが必要なアプリでは、すべてをfake-ipにするのが適さない場合があります。DNSの仕組み全体を無効にするのではなく、対象ドメインだけを例外に設定してください。以下の例は項目の関係を示すもので、完全な設定ではありません。待ち受けアドレスにはローカルループバックを使い、ポートはほかのサービスと重複しないようにしてください。適用前に、クライアントのオーバーライド機能がこれらの項目を上書きするか確認します。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

例にあるDNSサービスは構文を説明するためのもので、すべてのネットワークで利用できるとは限りません。実際には、現在のネットワークから安定してアクセスでき、プライバシー要件にも合うサービスを選んでください。ローカルポートで待ち受ける設定をしただけでは、システムのDNS問い合わせは自動的にそのポートへ送られません。クライアントのTUNによるDNSの取り込みなど、明示的な転送方法も必要です。DNSを取り込む目的で、すべてのネットワークインターフェースへの待ち受けを安易に許可しないでください。

暗号化DNSの起動依存ループを避ける

DoHなど、接続先にドメイン名を使う上流DNSでは、クライアントがまず上流DNS自身の名前を解決する必要があります。この処理が、まだ確立していないプロキシや同じ上流DNSに依存すると、起動時にループが発生します。コアのドキュメントに従って到達可能な初期名前解決経路を設定し、ノードサーバーのドメイン名に使うDNSも確認してください。設定項目がサポートされているか、ルーティングルールが適用されるかは、現在のコアの動作を基準に判断します。

ブラウザーでカスタムのセキュアDNSを有効にすると、システムの名前解決ポリシーを迂回し、クライアントのルールと実際の接続先アドレスが異なることがあります。原因を調べる際は現在の設定を記録し、一時的にシステム設定に従うよう変更して比較してください。復旧した場合は、ブラウザー専用のDNS設定が必要か判断します。企業ネットワークの内部ドメインは指定されたDNSでしか解決できない場合があります。公共DNSをすべてのドメインに使える万能な代替手段として扱わないでください。

キャッシュを消す前に設定が修正されているか確認する

DNSの設定を変更した後も、既存の接続やブラウザー、システムのキャッシュに古い結果が残ることがあります。まず該当するページやアプリの接続を終了し、OSが対応する方法でキャッシュを更新してください。Windowsでは以下のコマンドを実行できます。ほかのプラットフォームでは、システム環境によってキャッシュサービスやコマンドが異なるため、そのまま流用しないでください。キャッシュの削除で新しい問い合わせは行われますが、到達できない上流DNSや誤ったルールは修正されません。

ipconfig /flushdns

復旧の目安は、想定した名前解決経路で同じドメインから妥当な結果が得られ、実際のサービスに安定して接続できることです。ルールモードでは、広範囲に一致するIPルールより先に、ドメインルールが適用されるかも確認してください。GEOIP、GEOSITE、ルールセットの関係はルールによる通信の振り分け方で解説しています。DNSを何度も変更して、ルール設計の問題を覆い隠さないようにしましょう。

システムプロキシが効かない：ポート、アプリ、TUNを確認する

2種類の通信経路の違いを確認する

システムプロキシは、システム設定に従うアプリにプロキシのアドレスを通知するだけで、すべての通信を自動的に取り込むものではありません。一部のコマンドラインツール、ゲーム、独自のネットワーク設定を持つアプリは、この設定を読み取りません。TUNは仮想ネットワークインターフェースとルーティングを通じて対象の通信を受け取るため、通常はより広い範囲をカバーしますが、権限、ルーティング、除外設定、システム拡張の状態にも左右されます。両方を有効にしても、単純に適用範囲が合算されるわけではありません。

ブラウザーでは接続できるのにターミナルで失敗する場合は、ターミナルのプログラムがシステムプロキシや環境変数に対応しているか確認してください。すぐにクライアントの故障と判断しないようにしましょう。逆に、ローカルプロキシを明示したコマンドでは接続できるのに、どのブラウザーでも失敗する場合は、システムプロキシが正しいネットワークインターフェースに設定されているか、ブラウザーの拡張機能が別のプロキシを設定していないか、アプリに古い設定が残っていないか確認します。まず最も単純な経路で検証し、ほかのツールを1つずつ戻してください。

ポート設定と待ち受けアドレス

混合ポートはHTTPとSOCKSの両方のプロキシリクエストを受け付け、外部コントロールポートは管理インターフェースに使います。用途は異なります。管理ポートをブラウザーのプロキシ欄に入力しても、通常はWeb通信を転送できません。設定画面に表示されたポートは設定上の値にすぎず、実際に待ち受けているかは起動ログで確認します。ポートが使用中の場合、コアが起動しないことや、クライアントからポートの変更を求められることがあります。

項目・設定	用途	確認するポイント
`mixed-port`	HTTP・SOCKSプロキシの接続口	アプリに設定したポートと実際の待ち受けポートが一致しているか
`allow-lan`	ほかの端末からのプロキシ接続を許可する	バインドアドレス、ファイアウォール、ネットワークの信頼範囲をあわせて確認
`external-controller`	クライアントの管理インターフェース	プロキシ用ポートとして使用できない
TUNモード	仮想ネットワークインターフェース経由で通信を取り込む	権限、デフォルトルート、除外設定を確認

この端末だけで使う場合、プロキシのアドレスには通常127.0.0.1を指定し、LANからのアクセスを許可する必要はありません。以下の例はローカルプロキシの接続口だけを示しており、利用可能なノードは含まれていません。設定を変更したら再読み込みし、システムプロキシに設定されたポートも確認してください。クライアントにポート専用の設定項目がある場合は、画面から変更するのがおすすめです。リモートのサブスクリプション更新後に古い値へ戻るのを防げます。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

ポートの競合とTUNのルート競合を調べる

Windowsでは以下のコマンドで、待ち受け中のポートと対応するプロセスIDを確認できます。その後、タスクマネージャーでプロセスを特定してください。使用中のポートを見つけても、正体の分からないプロセスをすぐ終了しないでください。以前のクライアント、残っているコア、別のプロキシツールを終了してから、対象のクライアントを再起動します。ポートを変更した場合は、ブラウザー、ターミナルの環境変数、LAN内の端末に設定したアドレスも更新してください。古い接続先を使い続ける可能性があります。

netstat -ano | findstr :7890

TUNを有効にした後、すべての通信が切れた場合は、まずTUNを無効にしてシステムプロキシが使えるか確認します。次に、クライアントが仮想ネットワークインターフェースの作成に必要な権限を持っているか調べてください。別のVPN、コンテナネットワーク、企業向けセキュリティソフトが、近いルートを使ったりインターフェースの優先順位を変更したりすることがあります。比較時はデフォルトルートを制御するツールを1つだけ有効にします。システムのネットワークインターフェースを削除したり、ルートを一括消去したりすると問題が広がるおそれがあります。

終了後の設定復旧とLANでの利用

クライアントが異常終了すると、停止したローカルプロキシをシステムが引き続き参照することがあります。まずシステムの手動プロキシを無効にし、ブラウザーが直接接続に戻ったか確認します。自動構成スクリプトでプロキシを設定している場合は、その設定も確認してください。通常終了とプロセスの強制終了では、設定のクリーンアップ方法が異なることがあります。復旧後はクライアントの起動と終了を一度ずつ試し、状態に応じて設定が正しく切り替わるか確認してください。

ほかの端末からPCのプロキシを使う場合は、PCのLAN内アドレスを指定します。スマートフォン自身のループバックアドレスを指定するわけではありません。共有が必要な場合だけLAN接続を許可し、信頼できるネットワーク内の必要な端末に限定してください。管理インターフェースまで外部に公開しないようにしましょう。操作方法とファイアウォールの設定範囲は混合ポートとLAN接続の設定をご覧ください。この端末だけで使う場合はシステムプロキシ設定ガイドを確認してください。

クライアントがクラッシュする：画面、コア、設定の問題を切り分ける

どの部分が終了したのか確認する

ウィンドウが閉じること、タスクトレイのアイコンが消えること、コアが停止することは、それぞれ異なる状態です。ウィンドウを閉じてもバックグラウンドで動作するクライアントもあれば、画面が表示されたままコアだけが終了することもあります。クラッシュと判断する前に、タスクトレイ、システムのプロセス、ローカルの待ち受けポートを確認してください。管理インターフェースのアドレスが変わった、またはバックグラウンドサービスがまだ起動していないために、画面に接続エラーが表示されることもあります。プログラム全体が壊れたとは限りません。

設定のインポート、サブスクリプションの更新、TUNの有効化、ネットワークの切り替え、スリープからの復帰など、クラッシュ直前に行った操作を記録してください。再現できる条件は、エラー画面のスクリーンショット1枚よりも重要な手掛かりになります。クライアントログとOSのアプリケーションエラー記録を保存し、エラーの発生時刻が一致しているか確認します。コアが先に設定エラーを出し、その後画面に切断と表示される場合は、画面のプログラムを再インストールする前に設定を修正してください。

データを保護しながら設定の範囲を絞る

起動直後に終了する場合は、設定フォルダーとカスタムオーバーライドをバックアップし、クライアントに用意されている設定の無効化やリセット機能を試します。データの保存場所はアプリやOSによって異なるため、クライアントの説明やログの保存場所から確認してください。名前が似ているユーザーフォルダーを丸ごと削除しないでください。ファイルを手作業で移動する必要がある場合は、クライアントとバックグラウンドサービスを完全に停止してから行い、元のフォルダーも復元用に残します。

画面を操作できる場合は、最近追加したルールプロバイダー、スクリプト拡張、複雑なオーバーライドを無効にし、その後1つずつ戻します。最小限の設定にする目的は、障害の原因を特定することであり、サブスクリプションの認証情報を手作業で組み直すことではありません。項目を削除して復旧した場合は、現在のコアがその項目に対応しているか、重複してマージされていないか、関連ファイルのパスが有効かも確認します。すぐにクライアントの不具合だと決めつけないでください。

OSの互換性、権限、リソースを確認する

インストールパッケージのアーキテクチャは、端末に合ったものを選んでください。Windows、macOS、Linuxでは、ファイル名が似ているだけで異なるアーキテクチャのパッケージを使い回すことはできません。Linuxではディストリビューションのパッケージ形式と、デスクトップ環境に必要な依存関係も確認します。起動できない場合は、まずOSに表示された具体的な理由を確認してください。ダウンロードページから対応するOSのクライアントを選ぶことをおすすめします。一般的な用途にはClash Plusを推奨します。不明な配布元から実行ファイルを入手して置き換えないでください。

macOSでは、ネットワーク関連のコンポーネントをシステム設定で明示的に許可する必要がある場合があります。WindowsのTUNサービスでは管理者権限が必要な場合があります。許可に失敗したら、システムの案内に従って対処してください。システム保護を長期間無効にしないようにしましょう。セキュリティソフトがファイルを隔離した場合は、警告の対象と理由を確認し、ダウンロード元とアプリの正当性を確認してから対処します。単一のプログラムを起動するために、ディスク全体やユーザーフォルダーを除外リストに追加しないでください。

長時間使った後にクラッシュする場合は、メモリ使用量、接続数、ディスク空き容量も確認します。大量の接続、異常な再試行、詳細すぎるログ、制御されていないリソース更新は、リソース消費を増やすことがあります。不要なログを減らし、重複するタスクを停止して、安定するか確認してください。キャッシュの削除にはクライアントが対応する機能を使います。データベースや設定キャッシュを直接削除する場合は、書き込み中の破損を防ぐため、事前にコアを終了してください。

更新、以前のバージョンへの復帰、再現に役立つ情報

更新後に問題が発生した場合は、設定形式の移行、新機能の有効化、デフォルトDNSの変更が同時に行われていないか確認します。現在のデータをバックアップし、別の設定でメンテナンス中のクライアントを試してください。2つのプログラムでシステムプロキシとTUNを同時に有効にしないでください。以前のバージョンに戻す必要がある場合は、信頼できる配布元から、既存の設定に対応するインストーラーを入手します。新しい形式のデータを古いプログラムで上書きしないように注意してください。

問題を報告する際は、OSの種類、端末のアーキテクチャ、クライアント名、再現手順、個人情報を除いたログを添えてください。画面で実際のバージョンを確認できる場合は、バージョン情報も共有します。ダウンロードしたファイル名から推測しないでください。ログにはエラーの種類と発生段階を残し、ノードの認証情報は削除します。「失敗」とだけ分かるように切り詰めたログでは、原因を特定できません。設定の同期やバックアップ方法は複数デバイス間の設定同期を比較で紹介しています。

復旧の確認は、画面が再び開くだけでは不十分です。コアの起動、ポートの待ち受け、サブスクリプションの更新、実際のアクセスが正常か確認してから、停止していた機能を再度有効にします。特定の拡張機能を戻すたびに問題が再発する場合は、その拡張機能を無効のままにして、互換性の要件を個別に確認してください。切り分け可能な問題のために、クライアントのデータを何度もすべて消去する必要はありません。

スマホでのトラブル：VPN権限、バックグラウンド動作、ネットワーク切り替え

OSによる通信の取り込み状態と、ほかのVPNを確認する

スマートフォンに接続済みのアイコンが表示されても、OSのVPNトンネルが何らかの形で動作中であることを示すだけです。サブスクリプションのノード、DNS、接続先のサービスがすべて使えるとは限りません。まずクライアントで現在の設定、選択中のポリシー、ログを確認し、同じWebページにアクセスしてみます。接続アイコンが別のVPN、広告ブロッカー、企業向けネットワークツールによるものなら、実際にどのアプリがVPN接続を使っているか確認してください。Clashが有効だと誤解しないようにしましょう。

Androidクライアントは通常、OSのVPNインターフェース経由で通信を取り込みます。初回接続時にはユーザーによる許可が必要です。同じインターフェースを使う別のアプリと接続を取り合うことがあります。また、VPNを常時接続にする設定や、VPNを経由しない通信を遮断する設定がある端末もあります。元のクライアントが停止したときに、これらの設定によって端末全体がネットに接続できなくなる場合があります。まずOSのVPN設定を確認し、現在の状態を記録してから、どの制限を一時的に解除するか判断します。

Androidのバックグラウンド切断とアプリごとの通信設定を確認する

画面ロック後に切断する、別のアプリに切り替えた後の復帰が遅い場合は、バッテリー最適化やバックグラウンド制限でクライアントが停止されていないか確認します。OSが用意する方法で必要なバックグラウンド動作と通知を許可し、改善するか確認してください。ネットワークアプリ1つのために、すべてのアプリのバックグラウンド権限を一括で許可する必要はありません。メーカー独自のOSでは設定名が異なります。プロセスが動作し続けているか、VPNが再確立されているか、ログに再起動の記録があるかを確認します。

アプリごとのプロキシ設定や除外機能を使う場合は、許可リストと除外リストのどちらを設定しているか確認してください。アプリがプロキシを通らない場合、ルールの不具合ではなく、アプリが振り分け設定から除外されているだけかもしれません。リストの変更後は、接続を再確立する必要があることがあります。アプリに以前のネットワーク接続が残る場合もあります。対象アプリを完全に終了し、再接続して確認してください。仕事用プロファイル、アプリのクローン、個人用プロファイルは別のユーザー環境として扱われることがあります。1つのリストがすべてに適用されるとは限りません。

Wi-Fiでは接続できるのにモバイル通信では失敗する場合は、クライアントにモバイルデータの使用が許可されているか、データセーバーが有効か、現在のネットワークでIPv4またはIPv6が利用できるか確認します。PCの待ち受けアドレスやシステムプロキシの設定をそのまま流用しないでください。スマートフォン本体のVPN接続と、PCのプロキシを共有して使う方法は別の経路です。比較する際は、通信が別の経路に回り込まないよう、もう一方の接続を先に無効にします。

iOSのネットワーク拡張と接続の復旧を確認する

iOSでClash Plusを使う場合は、VPN構成の追加がOSで許可されているか確認し、現在有効な構成がClash Plusのものかを確かめます。組織が管理するネットワーク構成や、別のオンデマンド接続設定がある場合、ネットワークの切り替え時に別の接続が起動することがあります。管理対象端末のプロファイルをむやみに削除せず、変更できる範囲を管理者に確認してから個別に接続をテストしてください。

Wi-Fiからモバイル通信に切り替えた後は、以前の接続がすでに無効になっていても、アプリに古いセッションが残ることがあります。まずクライアントの接続を停止して再接続し、対象アプリも終了してから再度開き、復旧するか比較してください。スリープ後だけ問題が起きる場合は、切り替え前後のネットワークの種類、クライアントの状態、エラーの発生時刻を記録します。一度の再接続で成功しただけで、ノードに問題がないと判断しないでください。クライアントはiOSのダウンロード案内から確認できます。

LAN経由の共有プロキシとスマホ本体のプロキシを区別する

スマートフォンからPCのプロキシを使うには、相互に通信できるネットワークに接続し、PCの現在のLAN内アドレスとプロキシポートを指定する必要があります。PCのスリープ、アドレスの変更、ゲストネットワークによる端末間通信の遮断、ファイアウォールが原因で、急に接続できなくなることがあります。スマートフォン上の127.0.0.1はスマートフォン自身を指し、PCを示すものではありません。同じ名前のWi-Fiネットワークでも端末間通信が許可されているとは限らないため、ネットワークの隔離設定を確認してください。

スマートフォンでサブスクリプションをスキャンまたはコピーする場合は、Webページの共有URLではなく、完全なサブスクリプションURLを取得できているか確認してください。スマートフォンとPCで利用できるコア機能が異なる場合、同じサブスクリプションでも対応形式を選び分ける必要があります。項目を何度も手作業で削除して、設定を2種類維持しないでください。更新後は、それぞれの端末でカスタムルール、アプリごとの通信設定、DNSの動作を確認します。同期できたことと、各OSの設定が一致していることは別です。

スマートフォンでの復旧確認には、アプリを前面に表示した状態でのアクセス、短時間ロックした後のアクセス、ネットワークを切り替えた後の再接続を含めます。テスト中は必要なプロキシ機能だけを有効にし、安定してから自動選択やアプリごとの振り分けを戻してください。問題が続く場合は、このページのサブスクリプション、DNS、ノードの各項目を確認します。一般的な質問はよくある質問を、初めての設定は設定ガイドを参照してください。