Clashのよくある質問

クライアントは、サブスクリプションの管理やモード選択、システムプロキシなどの画面を提供します。mihomoコアは設定を読み込み、プロキシ接続の確立、ルールの適用、DNSの処理を担います。サブスクリプションは、サービス提供元から設定やプロキシ情報を受け取るためのものです。この3つは別々の役割です。クライアントをインストールしても、使えるプロキシが自動で手に入るわけではありません。クライアントを変えても、提供元が停止したサブスクリプションは復旧しません。トラブル時は、まず設定が読み込まれているか、次にコアが起動しているか、最後にサブスクリプションのサービスが有効かを確認し、アカウントの問題とインストールの問題を切り分けましょう。

ルールモードでは、rulesを上から順に照合し、一致したルールに応じたポリシーを適用します。グローバルモードでは、コアに取り込まれた通信をグローバルポリシーグループに振り分けます。そのグループ内で、利用可能な出口を選ぶ必要があります。ダイレクトモードでは、コアに取り込まれた通信が宛先へ直接接続します。モードが決めるのは、取り込まれた通信の経路です。プロキシを使っていないアプリの通信が自動的にコアへ入るわけではありません。普段はルールモードを使い、振り分けの問題を調べる場合に一時的にグローバルモードへ切り替え、テスト後に戻しましょう。ダイレクトモードでもTUNが無効になるとは限らず、仮想インターフェースがルーティングやDNS処理に使われることがあります。

初回設定では、まずシステムプロキシを有効にし、システムプロキシ設定に従うブラウザーでサブスクリプション、出口、ルールが使えるか確認しましょう。システムプロキシの対象は、その設定を参照するアプリに限られ、すべてのプロセスを取り込むわけではありません。ゲームや一部のコマンドラインツールなど、プロキシ設定に従わないアプリも扱う場合は、TUNを有効にしてサービスの権限、仮想インターフェース、DNSを確認します。原因の切り分け中は、一度に変更する設定を1つにしてください。両方が有効なら片方ずつ無効にして比較し、通信経路が重なって原因を特定しにくくなるのを避けましょう。

遅延テストで確認できるのは、通常、ある出口から設定されたテスト先に接続できることだけです。接続先のWebサイトやすべてのプロトコル、アプリが使えるとは限りません。まず接続ログを見て、ブラウザーのリクエストがコアに届いているか確認し、適用されたルール、ポリシーグループ、実際の出口を確認します。ログに記録がなければ通信の取り込みを優先して確認します。記録があるのに接続できない場合は、宛先ドメインの名前解決、出口の制限、サービスの状態を調べましょう。テスト対象が個別のプロキシか自動選択のポリシーグループかも確認してください。グループ内で選ばれる出口は、手動テストしたプロキシと異なる場合があります。

クライアントの「設定」「サブスクリプション」「Profiles」などの画面で、URLから読み込む項目を探します。サービス提供元から受け取ったサブスクリプションURLをすべて貼り付けて保存し、更新を実行したら、その設定を現在の設定に指定してください。サブスクリプションURLをexternal-controllerに入力したり、WebコンソールのURLをサブスクリプションとして扱ったりしないでください。読み込み後、利用可能なポリシーグループが表示されるか確認し、ログに解析エラーがないか調べます。サブスクリプションURLにはアカウント情報が含まれることが多いため、公開チャットやスクリーンショット、オンライン変換サイトに載せないでください。漏えいした場合は、提供元の管理画面でURLを再発行してください。

まずサービス提供元の管理画面で、アカウントが有効で利用枠が残っていること、サブスクリプションURLが再発行されていないことを確認します。管理画面からURLをコピーし直し、文字の欠落や末尾の空白、期限切れのリンクがないか確認してください。更新ログでは、401または403なら認証とアクセス制限、404ならURL、タイムアウトならネットワーク経路を確認します。現在のネットワークからサブスクリプションのドメインに直接接続できない場合は、クライアントが対応していればプロキシ経由で更新し、利用可能な設定がすでにあることを確認します。HTMLやログイン画面が返ってくる場合は、何度も読み込み直さず、Clashまたはmihomo用の正しい設定URLを提供元に確認してください。

元のファイルを残したまま、ログに表示された行とその1行前を確認し、インデント、コロン、リストの構造を調べます。YAMLのインデントにはスペースを使い、タブと混在させないでください。ポリシーグループが参照するプロキシ名が実在すること、ルールが参照するポリシー名が一致していることも確認します。コアが対応している場合は、設定ファイルのあるディレクトリでmihomo -t -f config.yamlを実行し、設定を検証できます。判断の基準は、現在使っているコアが返すエラーです。構文が正しくても、出口に接続できるとは限りません。未知のフィールドや未対応のプロトコルが表示された場合は、コアの種類とサブスクリプションの形式を確認し、設定全体を安易に削除しないでください。

デスクトップでは、クライアントが必要とするサービスモードがインストールされ、実行中か確認します。必要に応じて、クライアントの案内に従い管理者権限やシステムネットワーク拡張の許可を設定してください。Androidでは、システムのVPN接続リクエストを許可し、VPN接続を使用しているほかのアプリを先に停止します。Linuxでは、起動方法に応じて/dev/net/tun、サービスアカウント、必要なネットワーク権限を確認します。すべてのファイルを一律に書き込み可能にするのは避けてください。ログで最初に出た権限またはインターフェースのエラーを確認します。インターフェースの作成に成功しても通信できない場合は、権限の変更やクライアントの再インストールを繰り返さず、ルーティングとDNSを調べましょう。

まず実際のmixed-portとリッスンアドレスを確認し、プロキシ指定に対応したツールで明示的に指定します。たとえばポートが7890の場合、curl -I --proxy http://127.0.0.1:7890 https://example.comでリクエストを確認し、プロキシ指定なしの結果と比較できます。ターミナルにHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定する場合は、使用中のshellの構文に従い、対象のツールがどの環境変数を参照するか確認してください。環境変数の影響は通常、現在のプロセスとその子プロセスに限られます。テスト後は一時設定を解除し、クライアントを停止したあともターミナルがローカルポートを参照し続けないようにしましょう。

サービス提供元が推奨する更新頻度を優先し、クライアントで現在のサブスクリプションの編集画面を開いて、自動更新または更新間隔を確認します。設定値の単位が分か時間かも確認してください。無効なURLに対して短い間隔で再試行すると、サーバー側でアクセス制限がかかることがあります。設定全体の更新とproxy-providersのintervalは別の設定です。前者はクライアントが管理し、後者はコアがプロバイダーの設定に従って内容を取得します。更新後は、現在有効な設定とポリシーグループが正しいことを確認してください。クライアントを終了した場合や、モバイルOSのバックグラウンド制限がある場合は、予定どおりに更新されないことがあります。

まず現在のモードがルールモードであることを確認し、編集したのが使用中の設定で、未適用のコピーではないことを確かめます。rulesは記載順に照合されるため、通常は具体的なルールを汎用ルールより前に置き、MATCHは末尾に配置します。ルールが指定するポリシーグループが存在することも確認してください。保存後、クライアントで必要な再読み込みを行い、新しい接続を作って適用結果を確認します。既存の長時間接続は、以前の経路を使い続けることがあります。サブスクリプションの更新でローカル変更が上書きされる場合は、クライアントの上書きまたはマージ機能でルールを保存し、生成された設定にルールの重複やインデントエラーがないか確認しましょう。

まずサービス提供元に、現在のコアに対応した設定URLが用意されていないか確認します。直接読み込めるなら、追加の変換は不要です。プロキシ情報の一覧だけを含むサブスクリプションと、ルール、DNS、ポリシーグループを含む完全な設定は同じものではありません。変換後のファイルに必要な構成が含まれているか確認してください。変換サービスには元のサブスクリプションURLと認証情報が渡る可能性があります。信頼できるサービスか自分で運用するツールを優先し、出所不明のサイトにURLを送らないでください。変換しても、古いコアが新しいプロトコルに対応するわけではありません。ログにプロトコル非対応と表示された場合は、対応するコアに切り替えるか、提供元に出力形式の変更を依頼してください。

まずプロキシによる通信の取り込みを無効にし、通常のWebサイトにローカルネットワークから接続できるか確認します。次に、システム時刻、アカウントの状態、サブスクリプションの更新結果を確認してください。特定のプロキシを手動でテストし、ドメインの名前解決、TCP接続、ハンドシェイクのどの段階で失敗するかログを確認します。すべてタイムアウトする場合でも、テスト先に接続できないだけの可能性があり、テスト一覧だけで全出口が停止したとは判断できません。信頼できる別のネットワークでも比較します。現在のネットワークだけで失敗するなら、ネットワーク制限やDNSを重点的に調べてください。複数のネットワークで同じ段階に失敗する場合は、個人情報を伏せたログと発生時刻をサービス提供元に送ります。

システムのネットワーク設定で、プロキシのアドレスとクライアントの実際のリッスン設定が一致しているか確認します。よく使われるローカルアドレスは127.0.0.1ですが、ポートは現在の設定を確認してください。常に7890とは限りません。次にブラウザー拡張機能、アプリ独自のプロキシ設定、除外リストを調べます。これらがシステム設定を上書きしたり、適用対象から外したりする場合があります。接続ログにアプリのリクエストがなければ、プロキシを明示的に指定して比較します。明示的な指定では接続できてシステムプロキシでは失敗する場合は、アプリがプロキシ設定をどう読み込むか確認しましょう。起動時にしか設定を読み込まないアプリは、変更後に再起動が必要です。システムプロキシに従わないアプリにはTUNを検討してください。

まず通常のデスクトップブラウザーが同じプロキシ経由でネットワークに接続できることを確認し、影響を受けているアプリがループバック分離の対象か判断します。クライアントにUWPループバックツールがある場合は、必要なアプリだけに例外を設定できます。管理者ターミナルでCheckNetIsolation LoopbackExempt -sを実行して現在の一覧を確認し、対象アプリのパッケージファミリー名を指定して設定する方法もあります。すべてのアプリを一括で許可しないでください。設定後に対象アプリを再起動し、接続ログを確認します。ループバックの例外で解消できるのはローカルプロキシへのアクセス制限だけです。サブスクリプション、ルール、DNSの設定に代わるものではありません。

まずクライアントでTUNとシステムプロキシを無効にしてから、通常の方法で終了します。システムプロキシが、リッスンを停止したローカルポートを参照したままになっていないか確認してください。直接接続が復旧したら、再起動後は通信を取り込む方式を1つだけ有効にし、最初に発生したルーティングまたはDNSのエラーを確認します。まだ接続できない場合は、使用中のネットワークアダプターのDNSが、到達できないアドレスに手動設定されていないか、ほかのVPNや仮想ネットワークアダプター、セキュリティソフトとルートが競合していないか調べます。ネットワーク設定を戻す前に元の値を記録し、すべてのアダプターを削除するのは避けてください。必要ならシステムを再起動して残存状態を解消します。ネットワークが復旧したら機能を1つずつ有効にし、再現できる最小限の設定を保ちましょう。