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

コアは設定の解析、ルールの照合、接続の確立を担い、GUIクライアントはサブスクリプションの管理や設定の切り替え、ログの表示を行います。mihomoはClash.Metaの開発路線を引き継いでいますが、対応するプロトコルや設定項目はオリジナル版Clashと完全には一致しません。設定画面の場所はクライアントによって異なるため、トラブル対処ではクライアント名、コアの種類、OSをあわせて記録してください。画面のバージョンが同じでも、対応プロトコルが同じとは限りません。

クライアントは接続に使うツールで、インストーラーには通常、接続先の情報は含まれていません。サブスクリプションや設定ファイルには、サーバーアドレス、認証情報、プロキシグループ、ルールが記載されています。読み込む前に、提供元の形式が使用中のコアに対応しているか確認してください。WebページのURLやアカウント管理ページは、サブスクリプションURLとは異なります。URLにはアカウント情報が含まれることがあるため、フォーラムやスクリーンショット、オンライン変換サイトに公開しないでください。サポートを求める場合は、機密情報を除いたエラー内容だけを共有しましょう。

ルールモードは設定内のルールを順に照合し、一致したポリシーに従ってプロキシ接続か直接接続かを決めます。普段使いに適しています。グローバルモードでは、コアに届いた接続をグローバルポリシーに振り分けます。ルールによる振り分けが原因かを短時間で確認するのに便利ですが、すべてのアプリの通信を自動で取り込むわけではありません。ダイレクトモードは、コアに届いた接続を宛先へ直接つなぎますが、クライアントを終了する設定ではありません。確認後はルールモードに戻し、グローバルまたはルール用のプロキシグループがテスト用の項目のままになっていないか確認してください。

システムプロキシはOSにプロキシアドレスを登録し、その設定に従うアプリの通信に適用されます。アプリ独自のプロキシ設定を使うものや、システムプロキシを無視するものもあります。TUNは仮想ネットワークインターフェースとルーティングを使い、対象となる通信を取り込みます。ほかのアプリの通信も対象にしたい場合に適していますが、権限やルート、DNSの設定が必要です。初回はシステムプロキシでサブスクリプションが使えることを確認し、必要に応じてTUNを有効にしましょう。両方を同時に有効にすれば必ず改善するわけではありません。トラブル時は個別にテストし、通信経路を混同しないようにしてください。

クライアントの「サブスクリプション」「設定」または「Profiles」画面でURLからの読み込みを選び、提供元から受け取ったサブスクリプションURLをすべて貼り付けて、ダウンロードまたは更新を実行します。設定名が表示されても、有効になったとは限りません。現在の設定として選択し、プロキシグループに選べる接続先が表示されることを確認して、適切なノードを選びます。その後、ルールモードに切り替えてシステムプロキシを有効にし、ブラウザーで利用したいサービスにアクセスしてください。解析エラーが出た場合は、まずサブスクリプションの形式を確認しましょう。接続パスワードを手当たり次第に変更するのは避けてください。

まずコアのログを確認し、権限不足、仮想ネットワークインターフェースの作成失敗、ルート追加の失敗のどれかを切り分けます。Windowsでは通常、サービスモードをインストールして起動する必要があります。macOSではネットワーク拡張の許可や管理者権限が必要な場合があります。Linuxではクライアントのサービスやネットワーク管理権限によって異なります。まずはクライアントに用意されたサービスのインストール機能を使い、すべてのプログラムを常に高い権限で実行するのは避けてください。ほかのVPNや仮想ネットワークツールを使っている場合は、接続を一時停止してからテストします。権限に問題がないことを確認した後、TUNの設定を見直してください。

エラーログに表示された項目名と行番号を控え、その前後の行を確認します。YAMLのインデントにはスペースを使い、同じ階層ではそろえてください。リスト記号の後にはスペースが必要です。コロン、引用符、プロキシグループ名も確認しましょう。未対応のプロキシタイプや設定項目が表示された場合は、インデントだけでなくコアの対応状況も確認してください。まず設定をバックアップし、一度に一か所だけ修正して再読み込みします。サブスクリプションから生成された設定は、次回更新時に上書きされることがあります。継続的な変更は、クライアントが対応するオーバーライドやマージ機能を使ってください。

スタートアップ設定で保証されるのは、クライアントの起動が試みられることだけです。システムプロキシやTUN、バックグラウンドサービスも同時に有効になるとは限りません。再起動後、クライアントのプロセスとコアが動作していることを確認し、現在の設定が読み込まれているか、システムプロキシが有効か、TUNサービスが正常かを調べます。デスクトップOSによっては、ログイン後に起動する設定であり、ログイン前に動作するわけではありません。ネットワーク接続前にサブスクリプションの更新が失敗した場合は、接続が確立してから手動で更新してください。起動タイミングの問題を、サブスクリプションの無効化と誤認しないようにしましょう。

クライアントのルールオーバーライド、拡張設定、設定マージ機能を使い、サブスクリプションから生成された一時ファイルを直接編集しないでください。ルールは通常、上から順に照合されます。特定のドメインは、広い範囲に一致するルールや最終的なフォールバックルールより前に置き、指定するポリシー名は既存のプロキシグループと完全に一致させます。保存後に設定を再読み込みし、接続一覧で対象のリクエストに適用されたルールを確認してください。既存の接続には古いポリシーが引き続き適用されることがあるため、新しい接続を作成して検証します。誤った振り分けを元に戻せるよう、変更前にバックアップを取ってください。

遅延テストで分かるのは、指定したテスト先へのリクエストにかかる時間です。利用可能な帯域幅を示すものではなく、すべてのサービスでの通信品質を表すわけでもありません。ダウンロード速度はサーバーの負荷や回線の混雑、パケットロス、接続先のサイト、利用中のネットワークにも左右されます。ノードを比較するときは、同じネットワークと接続先を使い、近い時間帯にテストしてください。まずサービスが安定して開けるかを確認し、そのうえで継続的な転送速度を見ます。最小のミリ秒数だけを基準に何度も切り替えるのは避けましょう。特定のサイトだけ遅い場合は、実際に適用されたルールと出口ポリシーも確認してください。

2台のデバイスが互いに通信できるLANに接続されている必要があります。パソコン側でLAN接続を許可し、待ち受けアドレスがループバックアドレスのみに制限されていないことを確認します。ファイアウォールでは、信頼できるネットワークに限ってプロキシのポートを許可してください。もう一方のデバイスには、127.0.0.1ではなく、パソコンのLAN内IPアドレスと実際のmixed-portを入力します。手動のHTTPプロキシ設定は、通常その設定に従うアプリだけに適用され、すべての通信を取り込むものではありません。使い終わったら共有を無効にし、公共のネットワークでアクセス制御のないプロキシを公開しないようにしましょう。

Fake-IPモードは、ドメイン名に内部マッピング用のアドレスを割り当てます。コアはそのアドレスを使って後続の接続を元のドメインに関連付け、ルールによる振り分けを行います。割り当てられるアドレスは接続先サーバーの実アドレスではないため、名前解決の結果だけでDNSの不具合と判断しないでください。プリンターやNAS、内部ドメインにアクセスできない場合は、まずローカルDNSとドメインサフィックスを確認します。そのうえでコアのドキュメントを参照し、fake-ip-filterと必要な名前解決ポリシーを設定してください。変更後は関連するDNSキャッシュを消去して接続し直し、古いキャッシュでテスト結果が変わらない事態を防ぎます。

まずデバイスの日時と基本的なネットワーク接続を確認し、サブスクリプションの提供元でアカウントや有効期限、URLがリセットされていないか確認してください。401は通常、認証の失敗に関連し、403はリクエストが拒否されたことを示しますが、最終的な原因は提供元の案内を確認しましょう。設定内容ではなくログインページが返される場合は、正しいサブスクリプションURLを取得し直してください。タイムアウトする場合は、更新時のダウンロードが直接接続かプロキシ経由かを確認します。URL全体を公開ページに貼り付けたり、出所の不明な変換サイトに入力したりしないでください。

まずプロキシを無効にし、通常のネットワーク接続ができることを確認します。その後、設定の更新が成功しているか、デバイスの日時が正しいかを調べてください。テスト先にアクセスできない場合も、すべてのノードがタイムアウトすることがあります。実際にサービスへアクセスできるかと、コアのログをあわせて判断しましょう。1つのノードだけ失敗する場合は、そのノードの状態を確認します。すべての接続が名前解決またはハンドシェイクで失敗する場合は、DNS、認証情報、コアのプロトコル対応状況を順に確認してください。原因を特定できるよう、一度に変更する条件は1つにし、ほかのVPNは一時停止します。ポート、DNS、モードを同時に変更するのは避けましょう。

まずクライアントの接続一覧を確認します。記録があり、直接接続されている場合は、ルールとポリシーの選択を確認してください。記録がまったくない場合は、アプリがシステムプロキシを使っているか調べます。ブラウザー拡張機能、アプリ内の手動プロキシ設定、プロキシの除外リストが、システム設定より優先されることがあります。OSに登録されたプロキシアドレスとポートが、現在の待ち受け設定と一致しているか確認してください。特にmixed-portを変更した後は、あわせて更新が必要です。コマンドラインツールは、別途設定されたプロキシ環境変数を参照することもあります。通常のブラウザーのリクエストがコアに届くことを確認してから、システム設定に従わないアプリでTUNの利用を検討しましょう。

一部のAppContainerアプリはネットワーク分離の制限を受け、ローカルのループバックプロキシに直接接続できません。まず、通常のデスクトップブラウザーで同じプロキシを使い、接続先にアクセスできることを確認します。次に、クライアントに付属するUWPループバックツールを使い、必要なアプリだけにループバックの例外を追加してください。通常、この操作には管理者権限が必要です。ストアアプリがすべてUWPとは限らず、接続失敗の原因が常にループバック制限とは限りません。例外を追加しても解決しない場合は、接続ログやアプリのプロキシ対応、ファイアウォール設定を確認してください。すべてのアプリに一括で権限を付与するのは避けましょう。