Clashのよくある質問

クライアントは設定の取り込みやノード選択、システムプロキシなどの操作画面を提供します。mihomoなどのカーネルは接続の処理、ルールの適用、DNSの名前解決を担い、サブスクリプションはサービス提供元からノードや設定一式を受け取る仕組みです。クライアントをインストールしただけでは、利用可能なノードが手に入るわけではありません。トラブル時は、まず問題の発生箇所を切り分けましょう。画面が起動しない場合はクライアントとOS、設定を読み込めない場合はサブスクリプションの形式、設定は正常なのに接続できない場合はノード、プロキシグループ、ネットワークを確認します。カーネルによって対応プロトコルや設定項目が異なるため、ファイルの拡張子だけで互換性を判断しないでください。

普段はルールモードを使い、設定のルールに従って接続を指定のプロキシグループへ振り分けるのがおすすめです。グローバルモードでは、通常カーネルに渡された接続にグローバル設定が適用されますが、すべてのアプリがプロキシ経由になるわけではありません。直結モードでは、カーネルに渡された接続が直接外部へ接続します。特定のサイトで問題が起きた場合は、一時的にグローバルモードに切り替え、動作確認済みのノードを選んで、ルールの影響かどうかを確認できます。テスト後はルールモードに戻してください。モードの切り替えはシステムプロキシやTUNの代わりにはならず、期限切れのサブスクリプションや利用できないノード、サーバー側の制限も解決できません。

システムプロキシはOSにプロキシアドレスを登録する機能で、この設定を参照するブラウザーやアプリで利用できます。独自に接続するアプリや、システムプロキシを無視するアプリには適用されないことがあります。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。対象範囲はクライアント、OSの権限、ルーティング設定などによって異なり、DNSの処理も関係します。まずはシステムプロキシで基本的な接続を確認し、それでも対象にならないアプリがある場合にTUNを検討してください。有効にする前に他のVPNを終了し、現在のネットワーク設定を控えておきましょう。ネットワークに接続できなくなった場合は、まずTUNを無効にして通常の接続が戻ることを確認してから、設定を一つずつ見直してください。

サブスクリプションのURLを開けるかどうかだけでなく、内容の形式が使用中のカーネルに対応しているか確認が必要です。ClashのYAML設定一式、ノードだけのリスト、他のクライアント向けのサブスクリプションは、それぞれ別の形式です。サービス提供元のページでClashまたはmihomo向けのサブスクリプションを選び、クライアントのリモート設定機能から取り込んでください。未対応のプロトコルや不明な設定項目が表示された場合は、まずカーネルの要件を確認し、設定項目をむやみに削除しないでください。サブスクリプションURLには認証情報が含まれることが多いため、信頼できない変換サイトに渡したり、公開の問い合わせにそのまま貼り付けたりしないでください。

まずアカウントのサービスが有効か確認し、提供元のページからサブスクリプションURLを最初から最後までコピーし直します。パラメーターの欠落や余分な空白にも注意してください。更新ログも確認しましょう。401や403は認証の失効やアクセス制限、404はURLの変更、タイムアウトはローカルネットワークや更新リクエストの通信経路が原因の可能性があります。詳しくは提供元の案内を確認してください。現在使える設定は残し、全データを消さずに更新だけを個別にテストします。ログイン画面やエラーページが返ってくる場合は、正しいサブスクリプションURLを取得してください。それでも失敗する場合は、URLの認証情報を隠したうえで、ステータスコードと発生時刻を提供元に伝えましょう。

取り込みが成功しても、クライアントに設定が保存されただけで、有効化されているとは限りません。まず設定一覧で対象の設定を選び、カーネルの読み込みエラーがないことを確認してから、プロキシ画面でプロキシグループを確認します。proxy-providersを使用している場合は、プロバイダーがノードを正常に取得できているか、プロキシグループがuseで参照しているかも確認してください。画面によっては、プロキシグループを展開したときだけノードが表示され、サーバーが一覧にまとめて表示されないことがあります。ノードだけのファイルを設定一式として置き換えないでください。更新後も空の場合は、ログで設定項目のエラー、プロバイダーへのリクエスト失敗、サブスクリプションのサービス状態を確認します。

クライアントの案内に従ってサービスモードをインストールまたは修復し、その後TUNを有効にしてください。画面上のスイッチをオンにするだけでは、仮想ネットワークインターフェースの作成やルートの変更ができない場合があります。Windowsでは通常、サービスのインストールに管理者権限が必要です。macOSではヘルパーツールやネットワーク機能拡張の許可、AndroidではシステムのVPN接続リクエストへの同意が必要なことがあります。詳しくはクライアントの仕様を確認してください。許可を求めているのがインストール済みのクライアントであることを確かめ、出所不明の権限昇格コマンドは実行しないでください。サービスのインストールに失敗した場合は、OSのセキュリティ通知とクライアントのログを確認し、他のVPNが関連機能を使用していないか調べます。対処後はクライアントを再起動して動作を確認してください。

変更できますが、まず使用中のプロセスが、別のプロキシクライアントではないか確認してください。重複して起動しているクライアントを終了して再試行するほうが、ポートを変更するより設定をそろえやすい場合があります。変更が必要な場合は、現在有効な設定またはクライアントのポート設定で未使用のポートを選び、保存して再読み込みします。7890はよく使われる値ですが、必須ではありません。その後、システムプロキシ、ブラウザー拡張機能、ターミナルの環境変数、プロキシを手動設定したアプリのポートも新しい値に変更してください。ローカルでの利用を目的にLANからの接続を許可したり、プロキシの待ち受けアドレスを安易にインターネットから接続できる状態にしたりしないでください。

遅延テストでわかるのは、通常、特定のテスト先からの応答時間です。ダウンロード速度や動画の再生速度、すべてのサイトでの使い心地を示すものではありません。同じネットワークで、近い時間帯に同じサイトを使ってノードを比較し、バックグラウンドのダウンロードが測定に影響していないか確認します。接続ログで、選択したプロキシグループを実際に経由しているかも確認してください。特定のサイトだけ遅い場合は、出口回線、接続先の制限、DNSの応答が関係している可能性があります。すべてのノードで遅い場合は、まずローカルネットワークを確認しましょう。短時間に多数のノードを同時測定すると、サーバー側で制限されることがあります。テストは少数にとどめ、実際の通信状況もあわせて判断してください。遅延の数値一つだけでノードの良し悪しを決めることはできません。

まず、その接続が実際に使用しているプロキシグループを変更したか確認してください。動画、ダウンロード、通常のWeb閲覧が別々のグループに振り分けられている設定では、メインの選択グループを変更しても他のグループには反映されません。自動測定グループが独自の条件でノードを選んでいる場合もあります。接続画面で対象ドメインの新しいリクエストを探し、適用されたルール、プロキシの経由先、最終的な出口を確認します。既存の長時間接続は、切り替え後も古い出口を使い続けることがあります。切り替え後にリクエストを再実行し、必要であれば関連する接続だけを切断してください。クライアントがローカル上書きに対応している場合は、上書き機能でルールやグループの参照先を調整し、サブスクリプションの更新で直接編集した内容が上書きされるのを防ぎましょう。

ダウンロードしたサブスクリプションファイルを直接編集するのではなく、クライアントのルール上書き、拡張設定、永続化に対応したマージ機能を使いましょう。たとえばexample.comとそのサブドメインを直結する場合は、DOMAIN-SUFFIX,example.com,DIRECTを追加し、対象の通信に先に一致する広範なルールより前に配置します。Clashのルールは通常、上から順に評価され、最初に一致したルールのポリシーが適用されます。変更前にバックアップを取り、保存後に設定読み込みログと接続画面で動作を確認してください。対象サイトが複数のドメインからコンテンツを配信している場合は、実際の接続を確認してルールを追加します。手間を省くために無関係なドメインまでまとめて直結するのは避けてください。

少なくとも、現在有効な設定、手動で選択したプロキシグループ、ポート、システムプロキシ、TUNの状態を記録し、ローカルのルール上書きとDNSの変更をバックアップしてください。サブスクリプションの更新前には、リモート設定の内容が置き換わるかを確認します。クライアントの更新前には移行情報を読み、特にカーネル、サービスモード、設定フォルダーの変更に注意してください。重要な項目を一度に複数変更せず、1つずつ変更します。完了後によく使うサイトやアプリを確認すれば、問題が起きたときに原因を特定しやすくなります。バックアップにはサブスクリプションの認証情報やノードの接続情報が含まれることがあるため、安全な場所に保管してください。設定フォルダー全体を公開フォーラムにアップロードせず、問い合わせ時は必要な部分だけを伏せ字にして共有しましょう。

まず現在の設定が有効でノードが使えることを確認し、OSに登録されたプロキシアドレスとクライアントの待ち受けアドレス・ポートが一致しているか確認します。次に通常のブラウザーから新しいリクエストを送り、接続画面に記録が表示されるか確認してください。記録はあるのに直結している場合は、モードとルールを確認します。記録がない場合は、アプリがシステムプロキシを無視していないか、独自のプロキシ設定を使用していないか、別のツールに設定を上書きされていないか調べます。ブラウザーのプロキシ拡張機能、組織のポリシー、他のプロキシクライアントが影響することもあります。ターミナルのプログラムもシステムプロキシを参照するとは限らないため、各プログラムの説明に従って環境変数を設定してください。より広い範囲の通信を取り込む必要がある場合は、TUNを検討します。

まずプロキシを無効にして基本的なネットワーク接続を確認します。次にサブスクリプションの有効期限とシステム時刻を確認し、利用実績のある別のノードやテスト先でも比較してください。タイムアウトは、ドメイン名の解決、サーバーへの接続、接続先サイトへのアクセスのいずれでも発生するため、ログに記録されたアドレスと照らし合わせて判断します。接続拒否は、ポートでサービスが待ち受けていない場合によく見られますが、接続先から拒否されている可能性もあり、ノードの障害とは限りません。特定の回線だけ失敗する場合は提供元に連絡し、すべての回線で失敗する場合は、PCのファイアウォール、他のVPN、ネットワークの制限を確認してください。DNS、ルール、TUNを同時に変更すると、どの操作が有効だったか判断しにくくなるため、一度に変更するのは一項目だけにします。

AppContainerで分離された一部のWindowsアプリは、ローカルのループバックアドレスに直接アクセスできません。そのため、ブラウザーは使えるのに対象アプリだけ失敗する場合は、ループバック制限を確認してください。クライアントにUWPループバックツールがある場合は、案内に従って管理者権限で起動し、ローカルプロキシへのアクセスが本当に必要なアプリだけを許可します。設定後はアプリを再起動してください。すべてのストアアプリに同じ仕組みが適用されるわけではなく、接続の問題が必ずループバック制限によるものとも限りません。まずアプリが使うプロキシ経路と具体的な症状を確認しましょう。TUNが別の通信取り込み方法として有効な場合もありますが、ルートの動作確認が必要です。あらゆる問題に使える万能な修復手段ではありません。

まずTUNとシステムプロキシを無効にし、他のVPNを終了して、通常のネットワーク接続が復旧するか確認します。クライアントを終了してもシステムプロキシがローカルポートを指したままの場合は、OSのネットワーク設定でそのプロキシを無効にしてください。クライアントを再度起動したら、通信の取り込み方法は一つだけ有効にし、DNSリクエストのタイムアウト、ルートの競合、仮想インターフェースの作成失敗がログにないか調べます。DNS設定一式をむやみにコピーせず、使用中のカーネルとネットワーク環境に合わせて一項目ずつ戻してください。関連機能を無効にしても問題が続く場合は、ネットワークに再接続するか、PCを再起動して一時的な状態を解消します。組織の端末に設定されたルートやセキュリティ設定は、管理者に確認してください。