Clashのよくある質問とトラブル対処

Clashはプロキシコアと設定エコシステムの名称で、オリジナルプロジェクトの開発は終了しています。mihomoは互換性を保ちながら開発が続くコアで、対応プロトコルやルール、ネットワーク機能が拡張されています。GUIクライアントはサブスクリプションの管理、プロキシグループの選択、システムプロキシの設定、サービスのインストールを担い、実際の通信転送はコアが行います。トラブル対処では、Clashの最新版とだけ記すのではなく、クライアント名とコアの情報を記録してください。画面に設定項目があっても、使用中のコアがその項目に対応しているとは限りません。設定エラーが出たら、まずコアのドキュメントを確認し、クライアントが元の設定を上書きしていないかも調べましょう。

クライアントはローカルでの待ち受け、ルール判定、通信転送を行いますが、インストールするだけで利用可能なリモートプロキシが用意されるわけではありません。サブスクリプションには通常、ノード・プロキシグループ・ルールが含まれますが、ノード一覧のみの場合はローカルのテンプレートと組み合わせて使います。まず設定画面で読み込み結果を確認し、プロキシグループに選択可能な項目があるかをチェックしてください。サブスクリプションURLにはアカウントの認証情報が含まれることが多いため、公開の場に貼り付けないでください。漏えいした場合は、提供元でURLを再発行します。当サイトはクライアント情報と設定方法を掲載するサイトであり、サブスクリプションの発行や提供元アカウントの復旧は行っていません。

通常はルールモードを使い、設定内の rules を上から順にリクエストへ適用します。グローバルモードでは、コアに届いたリクエストをグローバル設定で選択するため、ルールによる振り分けが原因かどうかを一時的に切り分ける際に便利です。DIRECTモードでは、コアに届いたリクエストを直接接続します。いずれのモードも、システムプロキシやTUNによる通信の取り込みに代わるものではありません。グローバルモードに切り替えてアクセスできても、元の振り分け経路を確認する必要があるというだけで、すべてのネットワーク障害が解決したわけではありません。テスト後はルールモードに戻し、接続履歴で実際に適用されたルールとポリシーを確認してください。

システムプロキシはOSのプロキシ設定を書き換え、その設定を参照するアプリに適用されます。TUNは仮想ネットワークインターフェースを作成し、ルーティングによってより多くのアプリの通信を取り込みます。通常、サービスの起動や管理者権限が必要です。クライアントによっては併用できますが、正しく動作するかどうかはルートの除外設定、DNS、コアの実装によります。初回設定では、まずシステムプロキシだけを有効にしてブラウザーで確認し、ゲームやコマンドラインなどの用途に応じてTUNを有効にしてください。併用後に通信ループや異常なリソース使用、ネット接続の切断が起きたら、どちらか一方を無効にし、再現に必要な最小限の設定に絞りましょう。

OS、クライアント名、コアの情報、通信の取り込み方法、障害が発生した正確な時刻を記録し、失敗したリクエスト前後のログを保存してください。設定の読み込みエラー、待ち受けアドレス、DNSの名前解決失敗、接続先、適用されたポリシーを重点的に確認します。必要であればログレベルを一時的に上げて再現し、確認後に元へ戻してください。共有前にサブスクリプションURL、認証情報、ノードのサーバー情報、個人のアクセス履歴を削除し、スクリーンショットのアドレスバーも確認しましょう。「ブラウザーでは使えるが、特定のアプリだけ失敗する」のように説明すると、「繋がらない」だけより原因を絞り込めます。変更は一度に一つにすれば、ログがネットワーク版の当てずっぽうになりません。

まず端末の日時と基本のネット接続を確認し、次に提供元のアカウントページでサブスクリプションの期限、利用量、URLの再発行状況を確認します。更新ログのHTTPステータスもチェックしてください。401や403は認証またはアクセス制限、404はURLの変更が原因の可能性があります。タイムアウトの場合は、名前解決と接続経路を続けて確認します。クライアントで更新方法を選べる場合は、直接更新と、利用可能なプロキシ経由での更新をそれぞれ試してください。直近で使えていた設定は残し、何度も削除して作り直すのは避けましょう。ログイン画面や認証画面がダウンロードされる場合、リクエストが成功していても設定として読み込めるとは限りません。

読み込んだものが完全なClash設定、ノード一覧、一般のWebページのどれなのかを確認してください。ノード一覧は対応するプロキシプロバイダーまたはクライアントのテンプレートに追加する必要があり、そのまま完全な実行設定としては使えません。YAMLエラーの場合は、まずログに示された行とその直前の行を確認し、インデントにスペースを使っているか、リストのハイフンが正しいか、コロンの後の文字列を引用符で囲む必要があるかをチェックします。次に、使用中のコアがサブスクリプション内のプロトコルや項目に対応しているか確認してください。読み込み後は設定を選択して再読み込みします。設定一覧に表示されていても、コアで適用中とは限りません。

まずクライアントのログでmixed-portの実際の待ち受けポートを確認し、システムのHTTP・HTTPSプロキシが同じローカルアドレスとポート（例：127.0.0.1:7890）を参照しているか調べます。ポート番号は例なので、現在の設定に合わせてください。ブラウザー独自のプロキシ拡張機能を無効にしてブラウザーを再起動し、個別のプロキシ設定や組織のポリシーが適用されていないか確認します。curl -x http://127.0.0.1:7890 -I https://example.comを実行すれば、明示的なプロキシ接続をテストできます。このコマンドでは接続できるのにブラウザーで失敗する場合は、すぐにノードを変更するのではなく、ブラウザーの設定とシステムプロキシの反映状態を確認してください。

まず他のVPNや仮想ネットワークアダプター関連ツールを終了し、クライアントの手順に従ってサービスモードをインストールまたは修復します。Windowsではサービスの起動状態とセキュリティソフトのブロック履歴を確認します。macOSではシステム設定でネットワーク拡張機能やVPNの使用が許可されているか確認してください。Linuxでは/dev/net/tunの有無と、サービス起動に必要なネットワーク管理権限を確認します。起動させるためにシステム保護を無効にしたままにしたり、出所不明のファイルに安易に権限を与えたりしないでください。許可した後にコアを再起動しても失敗する場合は、画面のスイッチ状態ではなく、最初に記録されたアダプターまたはルートのエラーを確認します。

まず編集しているファイルが現在適用中の設定か確認し、読み込み時にクライアントが上書き設定、スクリプト、マージ設定を追加していないか調べます。リモートから取得したサブスクリプションファイルを直接編集しても、次回の更新で上書きされることがあります。ポート、DNS、カスタムルールなどを継続して使う場合は、クライアントの上書き機能で管理するのがおすすめです。変更前にコピーを保存し、一度に一つの項目だけ調整してから再読み込みし、ログを確認してください。クライアントによって配列のマージ方法は異なるため、rulesが追加されるのか置き換えられるのかにも注意します。編集画面のファイルではなく、最終的に適用された設定を基準にしてください。

ルールモードで、DOMAIN-SUFFIX,example.com,DIRECTを、先に一致する可能性のある広いルールより上に置き、末尾のフォールバックルールは残してください。DOMAIN-SUFFIXは指定したドメインとサブドメインに適用されます。完全一致するホスト名だけを対象にする場合はDOMAINを使います。保存して再読み込みしたら、対象サイトの既存接続を閉じて新しいリクエストを送り、接続画面でルールの種類と最終ポリシーを確認します。Webページは複数のドメインからリソースを読み込むことがあるため、メインのドメインだけをDIRECTにしてもすべてのリクエストが対象になるとは限りません。確立済みの長時間接続にルールの変更は遡って適用されないため、必要に応じて該当する接続を切断してから再試行してください。

まず共有が必要か確認してからallow-lanを有効にし、接続に使うネットワークアダプターを待ち受け対象にします。他の端末には、クライアントを動かしているPCのLAN内アドレスを設定してください。127.0.0.1は常に端末自身を指すため、指定しても接続できません。ホストのファイアウォールでは信頼できるサブネットからのプロキシポートへのアクセスだけを許可し、クライアントが対応していればプロキシ認証も設定します。ルーターでポートがインターネットに転送されていないことも確認してください。管理用インターフェースとプロキシポートは用途が異なるため、まとめて公開しないでください。共有のテストが終わったらLAN接続を無効にし、待ち受けるインターフェースを最小限に抑えましょう。

まずツール独自のプロキシオプションで接続を確認します。例：curl -x http://127.0.0.1:7890 -I https://example.com。その後、ターミナルとツールのドキュメントに従ってHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定してください。変数名のHTTPSは通常、接続先へのリクエスト種別を表すもので、プロキシの接続先にもHTTPSが必須という意味ではありません。プロトコルはローカルの待ち受け設定に合わせます。環境変数は通常、設定したプロセスとその子プロセスにだけ適用されるため、起動済みのターミナルやバックグラウンドサービスには反映されないことがあります。テスト後は一時設定を解除し、クライアント終了後にコマンドが使用できないポートを参照し続けないようにしてください。名前解決が関係する場合は、ローカルとプロキシ側のどちらでDNSを解決するかも確認します。

まず提供元に現在のコアに合った形式のサブスクリプションがあるか確認し、そのまま使えるなら変換を挟む必要はありません。変換が必要な場合は、信頼できるローカルツールを優先し、入力がノードリンク、ノード一覧、完全な設定のどれなのかを明確にしてください。完全なサブスクリプションをオンライン変換サービスに渡すと、認証情報やノード情報もそのサービスに渡すことになります。変換後は読み込みに成功したかだけでなく、プロキシグループの参照、ルールの順序、プロトコルの項目を確認しましょう。変換でできるのは形式の書き換えであり、期限切れのアカウント、接続できないサーバー、コアが未対応のプロトコル機能は解決できません。

まず現在適用中の設定を書き出し、クライアントの設定、待ち受けポート、コアの情報、サービスモードの使用有無を記録して、必要な上書きファイルも保存します。バックアップにはサブスクリプションや認証情報が含まれる可能性があるため、安全な場所に保管し、公開リポジトリにはアップロードしないでください。更新時はクライアント、コア、サブスクリプションのテンプレートを分けて作業し、一つ終えるごとにブラウザー、DNS、普段使うアプリで動作を確認します。不具合が再発したら、まず直前の設定に戻してから、プログラム自体を戻す必要があるか判断してください。サービスやドライバーを変更した場合は、クライアント指定のアンインストール手順に従い、古いサービスと新しいプログラムが混在しないようにします。

タイムアウトは、今回のテストが制限時間内に完了しなかったことを示すだけです。テスト先に到達できない、端末の時刻がずれている、DNSに失敗した、ネットワーク側で通信が制限されている、ノード自体が利用できないなど、さまざまな原因が考えられます。まず通常の直接接続が使えることを確認し、利用可能と分かっているノードで実際にWebページへアクセスして、接続ログのどの段階で失敗したかを確認してください。すべてのノードが同時に失敗する場合は、DNS、ネットワーク環境、コア設定など共通の要因を優先して調べます。一部のノードだけ失敗する場合は、サーバーやプロトコルの違いを確認しましょう。接続テストに成功しても、すべてのサイト、UDP、長時間接続が使えるとは限りません。対象アプリから実際にリクエストして再確認してください。

まずプロキシを無効にして通常のネット接続を確認し、クライアントを再起動して、設定の読み込み、ポートの待ち受け、プロキシグループでの利用可能なノードの選択状態を調べます。次に明示的なプロキシリクエストでローカルの接続口とシステム側の取り込みを切り分け、グローバルモードに一時的に変更して振り分けルールの問題か確認し、最後にDNSの名前解決とTUNのルートログを調べます。各手順の結果を記録し、ポート・DNS・ノードを一度に変更しないでください。画面の「接続済み」は、ローカルの機能が有効であることを示すだけの場合があり、宛先へのリクエスト成功を意味しません。名前解決から接続失敗まで、実際のアクセス一件を追跡してください。

まずブラウザーからローカルプロキシを使えることを確認し、問題のアプリがアプリコンテナーのループバック制限を受けているか調べます。一部のUWPアプリはローカルのループバックプロキシに直接アクセスできません。クライアント付属のループバック除外ツールを使い、必要なアプリだけを許可してください。または管理者権限のターミナルでCheckNetIsolation LoopbackExempt -sを実行すると、現在の除外項目を確認できます。手間を省くためにすべてのアプリを一括許可するのは避けましょう。許可後も失敗する場合は、アプリが使うネットワークインターフェース、プロキシ設定、ファイアウォールを確認し、必要に応じてTUNを個別にテストします。Microsoft StoreからインストールしたアプリがすべてUWPとは限らないため、入手元だけで判断しないでください。

まずシステムDNS、ブラウザーのセキュアDNS、クライアントのDNS、現在の通信取り込み方法を記録します。検査サイトに表示された地域だけでDNSリークと判断しないでください。fake-ipを使う場合はdns.enableとenhanced-modeが有効かを確認し、使用中のコアの設定要件に沿って、TUNでのDNSハイジャック、ルート、DNSの送信先を調べます。ブラウザー独自の暗号化DNSも別途確認が必要です。システムとブラウザーのDNSキャッシュを消去し、接続し直してから再テストしてください。respect-rulesを有効にしている場合は、名前解決ルールとプロキシサーバーのドメインを解決するための処理も確認します。DNSがプロキシに依存し、プロキシがDNSに依存する循環を防ぐためです。

終了後にネットに繋がらなくなった場合は、システムプロキシが停止済みのローカルポートを参照していないか確認し、残っているプロキシ設定を解除します。TUNサービス、仮想ネットワークアダプター、ルートがクライアントの手順どおり終了しているかも確認してください。ポートが使用中の場合は、まずプロセスを特定します。Windowsではnetstat -anoで待ち受けとPIDを確認できます。macOSまたはLinuxではlsof -nP -iTCP:7890 -sTCP:LISTENを使って例のポートを調べられます。正体の分からないシステムプロセスを終了しないでください。mixed-portを変更した場合は、システムプロキシ、ターミナルの環境変数、LAN内端末の設定も合わせて変更します。そうしないと、ポート競合が接続拒否に変わるだけです。