Clashのよくある質問

Clashはルールベースのプロキシツールと、その設定エコシステムを指します。クライアントは通常、サブスクリプションのインポート、ポリシーの選択、システムプロキシ、ログ表示を担当し、コアは接続、DNS、ルール照合を処理します。mihomoはこのエコシステムで継続的に開発されているコアです。クライアントによって使用するコアや対応フィールドは異なる場合があります。トラブルの切り分けでは、まず「バージョン情報」やコア情報でクライアント名とコア名、バージョンを記録し、該当する説明を確認してください。画面に設定項目があっても、読み込まれているコアが関連設定すべてに対応しているとは限りません。

インストールが完了しても、クライアントが起動できるようになっただけです。利用するには有効なプロキシ設定が必要です。設定はサービス提供元のClashサブスクリプションから取得するか、自分で管理するYAMLファイルを用意します。設定には利用可能なノード、ポリシーグループ、ルールが含まれている必要があります。サイトのチュートリアルや設定例はフィールドの関係を説明するもので、実際のサービスの代わりにはなりません。インポート前にサブスクリプション形式とコアの互換性を確認し、インポート後はノードが表示されることを確かめてから、ポリシーを選択してシステムプロキシを有効にしてください。サブスクリプションURLにはアクセス用の認証情報が含まれることが多いため、アカウントのパスワードと同様に慎重に管理しましょう。

ルールモードでは、rulesの上から順に接続を照合し、一致したルールに指定されたポリシーを適用します。サイトごとに通信を振り分ける日常的な利用に向いています。グローバルモードでは、コアに渡された接続にグローバルポリシーを適用します。ルールに原因があるか一時的に切り分ける際に便利ですが、すべてのアプリの通信がプロキシ経由になるわけではありません。DIRECTモードでは、コアに渡された接続を宛先へ直接接続しますが、コアのDNS処理は引き続き適用される場合があります。モードを切り替えたら新しい接続で確認してください。既存の長時間接続は以前の経路を使い続けることがあるため、開いたままのタブだけで切り替え結果を判断しないでください。

以前の設定に含まれる汎用フィールドは移行の出発点として使えることが多いものの、新しいクライアントが使用するコアで動作を確認する必要があります。移行前に設定をエクスポートし、ポリシーグループの選択、システムプロキシのポート、TUN、DNSの設定を記録してください。インポート後は構文が正しいことを確認してから接続をテストします。旧クライアントの画面設定、スクリプト、上書き機能はそのまま移行できるとは限りません。ダウンロードページから継続的にメンテナンスされているクライアントを選び、エラーに応じてフィールドを一つずつ調整してください。新しいクライアントが正常に動作することを確認してから、旧クライアントの自動起動とプロキシ機能を無効にし、同時にネットワークを制御しないようにしましょう。

クライアントの設定またはサブスクリプション画面でURLからのインポートを選び、URL全体を貼り付けます。ダウンロードが完了したら、その設定を現在使用するプロファイルに指定してください。登録しただけで有効化していない場合、ノード画面には以前の内容が表示されることがあります。ノード一覧が空なら、取得した内容がログインページやエラーメッセージ、他のツール向けのエンコード済みリストではなく、Clash YAMLであることを確認します。続いて、設定にproxiesがあるか、proxy-providersからノードを取得できているか確認してください。サブスクリプションURLを公開の変換サイトに貼り付けず、サービス提供元が案内する互換URLを優先して使いましょう。

まず更新ログでHTTPステータスとエラーの種類を確認します。401や403は認証情報、権限、サービス提供元の制限が原因の可能性があります。404はURLの変更、タイムアウトはネットワークやドメイン名の解決に問題がある可能性があります。サービス提供元の管理画面に戻ってURLをコピーし直し、アカウントの状態やサブスクリプションがリセットされていないか確認してください。更新にプロキシが必要なのに、現在のノードが使えない場合は、クライアントが対応していればDIRECTでダウンロードするか、一時的に利用可能な設定に切り替えます。更新前にローカルのコピーを保存してください。設定を削除してもリモートのURLは直らず、使えていたノードまで失うおそれがあります。

まずログに表示された行番号とフィールド名を確認し、その前後数行も調べます。パーサーが示す行は、問題が実際に発生した場所ではなく、検出された場所の場合があります。YAMLのインデントにはスペースを使い、同じ階層では幅を統一してください。Tabは使えません。コロンの後のスペース、リスト項目のハイフン、引用符の閉じ忘れ、ポリシー名とノード名の不一致を重点的に確認します。特殊文字を含む名前は、対応する引用符で囲んでください。一度に一つだけ修正して設定を再検証し、エラーが出たら直近の変更を元に戻します。サブスクリプションから生成されたファイルは、次回の更新で修正内容が上書きされないよう、上書き機能で調整するのがおすすめです。

まず、クライアントが使用するコアがTUNに対応していることを確認し、クライアントの案内に従ってサービスをインストールするか、システムの許可を設定してください。Windowsでは管理者権限またはサービスモードが必要な場合があります。macOSでは補助コンポーネントや関連するネットワーク権限の許可が必要になることがあります。Linuxでは適切なネットワーク管理権限と利用可能なTUNデバイスが必要です。許可を設定したらコアを再起動し、ルートやデバイスの作成エラーが続くか確認します。また、ルートの競合を避けるため、他のVPNによるネットワーク制御を無効にしてください。権限昇格コマンドをむやみに重ねず、ログから権限不足、デバイスの不在、アドレスの競合を見分けて原因に対処しましょう。

selectでは、ユーザーがノードや別のポリシーを手動で選択します。出口を固定したい場合に適しています。url-testは、設定したテストURLと間隔に基づいて候補を比較し、コアが対応する許容差などの設定に従って出口を選びます。テスト結果が示すのは、そのテスト先への接続状態だけです。fallbackは候補を順番に確認して利用可能なものを選び、メインの出口が使えなくなった際の切り替えに使います。いずれも、対象の接続に適用するにはルールから参照する必要があります。ポリシーを変更した後は新しい接続で、一致したグループと最終的なノードを確認してください。1回のテスト結果を、すべてのサイトでの実際の通信速度と同一視しないようにしましょう。

まず、クライアントに用意されているローカル上書き、ルール追加、マージ機能を使い、その機能が適用される順序を確認してください。ルールは通常上から順に照合されるため、ドメインを指定する詳細なルールは、範囲の広いルールや末尾のMATCHより前に配置します。参照するポリシー名が存在し、大文字・小文字も一致している必要があります。特定のドメインを指定したポリシーに振り分ける場合は、ポリシーグループに利用可能な出口があることも確認してください。保存後に設定を再読み込みし、接続ログで実際に一致したルールを確認します。サブスクリプションのキャッシュファイルを直接編集すると更新時に置き換えられやすいため、カスタム部分は別に保存し、更新後にマージ結果を確認しましょう。

設定ごとに、取得元と用途がわかる名前を付け、ローカルファイルかリモートサブスクリプションかを記録しておきます。Profileを切り替えたら、現在の有効状態、ポリシーグループ、DNS設定が切り替わったことを確認してください。システムプロキシやTUNのスイッチはクライアント全体に適用される設定の場合があり、Profileと一緒に切り替わるとは限りません。バックアップではノード一覧だけでなく、元の設定、ローカル上書き、必要なクライアント設定も保存します。リモートサブスクリプションの更新では通常その内容が置き換わりますが、ローカルファイルは自分で管理します。別の端末に移行するときは、まず設定を一つインポートして動作を確認し、その後、追加設定を一つずつ戻すと互換性の問題を見つけやすくなります。

まず、ホスト端末とほかの端末が相互通信できるLANに接続されていること、クライアントでLANからのアクセスが許可されていること、適切なインターフェースアドレスで待ち受けていることを確認します。次に、別の端末のネットワークプロキシ設定で、ホストのLAN内IPアドレスとクライアントが実際に使用しているHTTPまたはmixedポートを指定します。127.0.0.1は端末自身を指すため、入力しないでください。それでも接続できない場合は、ホストのファイアウォール、ゲストネットワークの端末間通信制限、ポートの競合を確認します。信頼できるネットワークでのみ公開し、必要に応じてプロキシ認証とファイアウォールの適用範囲を設定してください。外部コントローラーは管理用のインターフェースであり、ほかの端末がインターネットに接続するためのプロキシポートではありません。インターネットに直接公開しないでください。

まず、通常の直接接続でWebサイトを閲覧できることを確認し、設定が正しく読み込まれているか、サブスクリプションのアカウントが有効かを調べます。複数のノードを比較し、特定のノードだけ失敗する場合は、そのノードのサービス状態を優先して確認してください。すべて失敗する場合は、端末の時刻、DNS、ネットワーク制限、クライアントのログを確認します。テスト先自体に接続できない場合もタイムアウトになるため、テストボタンの結果だけでなく、実際の接続先への新しい接続でも検証してください。一時的にネットワークを切り替えて比較する場合は、一度に変更する条件を一つにします。ログに認証失敗やプロトコル非対応が表示されたら、タイムアウト値を上げ続けるのではなく、認証情報や互換性を確認しましょう。

システムプロキシが影響するのは、システムのプロキシ設定に従うアプリが中心です。すべての通信が自動的にプロキシ経由になるわけではありません。まず、システム側に設定されたプロキシのアドレスとポートが、クライアントの実際の待ち受け設定と一致しているか確認します。次に、ブラウザー独自のプロキシ拡張機能を無効にし、新しい接続を作成してクライアントの接続ログを確認してください。コマンドラインツール、ゲーム、一部のアプリでは、個別のプロキシ設定が必要な場合や、ルーティング要件を確認したうえでTUNを使う方法があります。接続ログにリクエストがあるのにDIRECTに一致する場合は、システムプロキシを変更し続けるのではなく、ルールとポリシーの選択を確認します。ほかのプロキシツールを終了し、システム設定が繰り返し上書きされないようにしてください。

アプリコンテナーの制限により、一部のWindowsアプリはローカルのループバックプロキシに接続できない一方、通常のデスクトップブラウザーは利用できる場合があります。この場合はループバック制限を確認してください。クライアントがローカルアドレスで待ち受けていることを確認し、クライアント付属のUWPループバックツール、またはWindowsのCheckNetIsolationツールを使って、必要なアプリパッケージに限り免除を設定します。操作には管理者権限が必要な場合があります。アプリごとにパッケージ形式やネットワークの動作は異なるため、すべてのストアアプリに当てはまるわけではありません。設定後は対象アプリを再起動し、接続ログを確認してください。TUNを利用している場合は、ルーティングとDNSも確認します。ループバックの免除で、これらの確認を代替することはできません。

Fake-IPでは、ドメイン名に対してまずマッピング用アドレスを返し、その後コアが実際の宛先と関連付けます。DNSと接続経路が一致しないと、アクセスに失敗することがあります。まず、ほかのツールがDNSを制御していないか、ブラウザーの暗号化DNSが想定した経路を迂回していないか、対象ドメインをfake-ip-filterに追加する必要がないか確認します。クライアント終了後にネットにつながらない場合は、残っているシステムプロキシを無効にし、システムDNSが停止済みのローカルサービスを参照していないか確認してください。元の自動設定または指定設定に戻し、DNSキャッシュを消去して再度試します。変更前のネットワーク設定を控え、一項目ずつ戻してください。トラブル調査ログを共有する際は、サブスクリプションURL、認証情報、機密性の高いドメインを伏せましょう。