Clashのよくある質問

Clashクライアントは、設定のインポートやプロキシグループの選択、接続状況の確認などを行うための画面を提供します。mihomoコアは設定を読み込み、ルールを照合してネットワーク接続を処理します。サブスクリプションは通常、サービス提供元が管理し、ノードや設定一式を配布するために使われます。クライアントをインストールしても、プロキシサービスが利用できるようになるわけではありません。問題を切り分ける際は、まず現在有効な設定を確認し、次にコアが動作していること、最後にノードが利用可能なことを確認しましょう。サブスクリプションの問題をインストールの問題と取り違えないことが大切です。

ルールモードは設定内のルールを上から順に照合するため、普段の通信を振り分けるのに適しています。グローバルモードでは、コアに渡された接続をグローバルプロキシグループで処理しますが、グループ内でDIRECTが選ばれる場合もあります。DIRECTモードでは、コアに渡された通信を宛先へ直接接続します。グローバルモードにしても、すべてのアプリの通信が自動的にプロキシ経由になるわけではありません。特定のサイトで問題が起きた場合は、一時的にグローバルモードに切り替えて比較テストを行い、終わったらルールモードに戻して接続ログで実際に適用されたルールを確認してください。

システムプロキシはアプリにローカルプロキシのアドレスを設定し、その設定に従うプログラムだけに適用されます。TUNモードは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、システムプロキシを参照しない一部のアプリにも適用できますが、通常は管理者権限またはサービスモードが必要です。実際に通信を取り込める範囲は、ルート、除外設定、DNS、システム上の制約によって異なります。まずシステムプロキシで設定とノードが正常に動作することを確認し、必要に応じてTUNを有効にしましょう。複数の設定を同時に変えると、原因を特定しにくくなります。

遅延テストで測定するのは、通常、指定されたテスト先への1回のリクエストにかかる時間です。ノードの継続的な通信速度を示すものではありません。動画やダウンロードの速度は、出口の混雑、接続先のサイト、パケットロス、サービス側の速度制限、ローカルのWi-Fi環境にも左右されます。速度テストと実際のアプリで同じノードを使っているか確認し、同じファイルまたは同じ動画画質で比較してください。遅延の低さだけでノードを並べ替えたり、テスト先やネットワークが異なる数値をそのまま比較したりしないようにしましょう。

ファイルの拡張子だけで互換性を判断することはできません。クライアントによって使用するコアが異なるほか、インポート時にDNS、TUN、ルール設定などが追加されることもあります。プロトコルや設定項目によっては、特定のコアでしかサポートされません。移行前に元の設定とローカルの上書き設定を保存し、新しいクライアントのコアの種類を確認してから、解析ログに表示される具体的な項目エラーを調べてください。メンテナンスが終了したクライアントを使っている場合は、認識できない項目を繰り返し削除するのではなく、継続的に更新されているバージョンへの移行を優先しましょう。

アカウント管理ページやWeb共有ページではなく、サブスクリプションURLをコピーしたことを確認し、URLの前後に空白や改行が入っていないか調べてください。次に更新ログを確認します。ログインページが返される、応答が空、または形式に対応していない場合は、一覧が空になることがあります。設定が現在使用中の項目になっているか、プロキシプロバイダーの更新が別途必要かも確認しましょう。サブスクリプションURLにはアクセス用の情報が含まれることがあり、第三者が内容を取得できる可能性があるため、公開の掲示板などにURL全体を投稿しないでください。

401や403は通常、リクエストが認証されなかったことを示します。サービス提供元によるアクセス制限が原因の場合もあります。まず提供元のアカウントページで有効期限、通信量の残り、URLがリセットされていないかを確認し、新しいURLをコピーして更新してください。クライアントからの更新リクエストが誤ったルールで遮断されていないか、システム時刻が正確かも確認しましょう。サービスの制限を回避するために何度もリトライするのは避けてください。新しいURLでも同じステータスが返る場合は、エラー発生時刻とステータスコードを記録して提供元に問い合わせ、URLに含まれるアクセス情報は公開しないでください。

まずログでエラーの行番号と項目名を確認し、その周辺のインデント、コロン、リストのハイフン、引用符の対応を調べます。YAMLのインデントにはスペースを使い、タブを混在させないでください。特殊文字を含む値は、構文に従って引用符で囲みます。プロキシグループやルールの宛先でエラーが起きている場合は、参照先の名前が存在し、大文字・小文字も一致しているか確認しましょう。修正前に元のファイルを保存し、1か所ずつ変更して再読み込みしてください。サブスクリプションの更新で手動変更が上書きされる場合があるため、継続的な変更にはクライアントが対応する上書き機能を使いましょう。

まずTUNを無効にし、システムプロキシモードで正常に接続できることを確認してください。Windowsではクライアントの説明に従ってサービスモードをインストールまたは修復し、認証が成功したことを確認します。macOSではシステムが要求するネットワーク拡張機能やVPNの許可を確認してください。LinuxではTUNデバイスとプロセスに必要な権限を確認します。ほかのVPNをインストールしている場合は一時的に切断し、仮想ネットワークアダプターの競合がないか調べてください。エラーを回避するためにセキュリティ保護を長期間無効にするのは避け、ログに記録された権限、ドライバー、デバイスの問題を個別に解決しましょう。

一部のUWPアプリはネットワーク分離の制限により、ループバックアドレス上のローカルプロキシに直接アクセスできません。まず、通常のブラウザーが同じプロキシ経由でインターネットに接続できることを確認します。次に、クライアントにUWPのループバック解除ツールがあるか調べ、必要なアプリだけ解除してください。解除しても、アプリがシステムプロキシを必ず使うようになるわけではありません。それでもプロキシを使わない場合は、権限とルーティングが正常であることを確認したうえでTUNを試してください。アプリの更新や再インストール後は、該当パッケージの解除状態を再確認する必要がある場合があります。

サブスクリプションのキャッシュファイルを直接編集するのではなく、クライアントが提供するルールの上書き、拡張設定、またはマージ機能を使いましょう。まず、ルールの適用先となるプロキシグループが存在することを確認し、より具体的なドメインルールを、広範なルールや最後のMATCHより前に配置します。ルールは最初に一致したものが適用されるため、MATCHより後に置いた項目は実行されません。保存後に設定を再読み込みし、接続ログで適用されたルールとポリシーを確認してください。サブスクリプション更新後も上書き設定が適用されているか確認しましょう。

現在使用しているグループが自動速度測定タイプか、手動選択が必要なselectグループかを確認してください。url-testは設定されたテスト先、間隔、タイムアウト、許容値に基づいてノードを選びます。実際のすべての通信速度を継続的に測定するわけではありません。グループがプロキシプロバイダーを参照している場合は、プロバイダーが更新済みかも確認しましょう。ポリシーを切り替えても既存の接続は元のノードを使い続けることがあります。新しい接続でテストし、必要な場合に限って関連する既存接続を閉じてください。クライアント全体を何度も再起動する必要はありません。

サービス提供元の形式がクライアントの要件と異なり、クライアントに直接インポートできない場合に限り、サブスクリプション変換を検討してください。まず提供元にmihomoまたはClash対応の設定を用意できるか確認し、変換の手順を減らしましょう。第三者の変換サービスにはサブスクリプションURL全体が渡る可能性があり、ルール、DNS、プロキシグループが変更されることもあります。利用前に処理方法を確認し、変換後はプロトコルのパラメーターとポリシーの参照先をチェックしてください。直接インポートできるサブスクリプションを、画面を変える目的だけで変換する必要はありません。

クライアントの接続画面で対象のドメインまたはプロセスを探し、適用されたルール、ポリシーの経路、出口ノードを確認して、現在のプロキシグループの選択内容と照らし合わせます。ブラウザーに表示される出口IPアドレスだけでは、ほかのアプリの通信経路は分かりません。接続ログにアプリが見つからない場合は、システムプロキシを迂回していないか、TUNの対象外になっていないか確認してください。テスト前にアプリの既存接続を閉じ、新しいリクエストを送ります。ドメインルールの判定にはDNSログも確認し、宛先IPだけで判断しないようにしましょう。

ローカルのルール上書き、プロキシグループの選択、DNSとTUNのカスタム設定、残しておきたい設定ファイルをバックアップしてください。サブスクリプションURLや設定にはアクセス認証情報が含まれる場合があるため、安全な場所に保管し、公開リポジトリや共有ストレージには置かないでください。移行後は、新しいクライアントで設定を読み込めることを確認してから、カスタム設定を1つずつ戻します。クライアントによって内部データの保存先に互換性がない場合があります。エクスポート機能や編集可能な設定ファイルを優先し、プログラムのデータフォルダー全体をそのまま上書きしないでください。

まずプロキシを無効にして基本のネットワークをテストし、システム時刻、ゲートウェイ、通常のWebサイトへのアクセスが正常か確認してください。次に、現在の設定に有効なノードが含まれているか、サブスクリプションが期限切れでないか、テスト先自体にアクセスできるか調べます。別のノードを選び、実際にアクセスしたいWebサイトで比較しましょう。必要に応じてスマートフォンのテザリングに切り替え、ローカルネットワークの制限かサーバー側の障害かを切り分けます。共通の速度テストだけタイムアウトし、実際のアクセスが正常な場合は、テスト先とテスト用ルールを確認してください。すべてのノードが使えないとすぐに判断しないようにしましょう。

まずコアが動作していること、ローカルの待ち受けポートとシステムプロキシに設定したポートが一致していることを確認し、ポートの競合がないか調べます。次に、ブラウザーで独自のプロキシ拡張機能が有効になっていないか、システム設定に従わないプロキシ設定が使われていないか確認してください。ほかのVPNやプロキシソフトを一時的に終了し、クライアントを1つだけ起動してテストします。リクエストが接続ログに表示される場合は、ルール、ノード、DNSを確認してください。ログに何も表示されない場合は、アプリからローカルプロキシまでの経路を重点的に調べましょう。

まず接続ログで対象ドメインを検索し、REJECTで拒否されていないか、誤ってDIRECTが選ばれていないか、利用できないプロキシグループに振り分けられていないか確認します。一時的にグローバルモードに切り替え、利用可能と確認済みのノードでテストしてください。アクセスが回復すれば、通信経路の違いが原因の可能性はありますが、それだけでDNSが正常だとは判断できません。ログに名前解決の失敗や異常なアドレスが記録されている場合は、DNSの上流サーバー、ドメインポリシー、ブラウザーのセキュアDNSを確認します。設定は一度に1つだけ変更し、新しい接続で結果を確かめてください。

まず、どのドメインをどのリゾルバーで名前解決するのか、DNSリクエストをプロキシ経由にする必要があるのかを明確にしてください。コアのDNS設定、TUNのDNS hijack設定、システムリゾルバー、ブラウザーのセキュアDNSを確認し、複数の入口から異なる経路で通信しないようにします。ブラウザー内蔵の暗号化DNSはシステムの名前解決経路を迂回することがあります。また、システムプロキシだけではすべてのDNS通信が取り込まれるとは限りません。コアのログとネットワークキャプチャを併用して判断してください。検出サイトに表示されるリゾルバーの所在地は、あくまで参考情報です。

まず、システムプロキシが終了済みのローカルポートを参照していないか確認し、プロキシを無効にするか、終了前の設定に戻してください。TUNを使っていた場合は、クライアントを再度起動し、TUNを無効にしてから通常の手順で終了します。その後、仮想ネットワークアダプター、ルート、DNS設定が残っていないか確認してください。組織のポリシーで管理されている端末では、既存のプロキシ設定を独断で変更しないでください。復旧作業では、まず元の設定を記録し、ネットワーク設定全体のリセットは避けます。通常の方法で復旧できないと明らかな場合に限り、OSの手順に従って追加の修復を行ってください。