Clashのよくある質問
インストール・設定・接続のトラブル対処

クライアントは設定の読み込み、プロキシ転送、ルールの適用を行いますが、接続先のサーバーを生成するものではありません。サブスクリプションは通常サービス提供元から配布され、サーバーアドレス、認証情報、プロキシグループ、ルーティングルールが含まれています。設定またはProfiles画面からインポートした後、対象の設定を有効にし、プロキシ画面で利用可能な接続先を選択してください。インストールしただけ、サブスクリプションURLを保存しただけ、またはインポート後に設定を有効にしていない状態では、接続は確立されません。サブスクリプションは機密情報です。URL全体を公開コメントやスクリーンショットに載せないでください。

コアは設定の読み込み、ルールの照合、プロキシ接続を担当します。GUIクライアントは設定一覧、システムプロキシの切り替え、ログ、インストール設定などを表示・管理します。mihomoはClashエコシステムで開発が続くコアですが、Clashの名称を含むすべてのクライアントが同じコアを採用し、同じ設定項目に対応しているわけではありません。互換性を確認する際は、「バージョン情報」やコア情報の画面でクライアント名、コアの種類、エラーが出た設定項目を記録してください。ボタンの位置はクライアントによって異なります。説明にある設定名を実際の画面で探し、スクリーンショットの位置だけを頼りに操作しないでください。

ルールモードは設定内のルールを順に照合し、接続先ごとに直接接続、プロキシグループ、拒否のいずれかを選ぶため、日常利用に適しています。グローバルモードでは、コアに入った通信にグローバル用のポリシーグループを適用します。そのグループ内で利用可能な接続先を選ぶ必要があり、すべてのアプリの通信を自動的に取り込む機能ではありません。直接接続モードは、コアに入った通信をそのまま接続先へ送るため、比較や切り分けに便利です。モードを切り替えても、既存の長時間接続は以前の経路を使い続ける場合があります。ページを再読み込みするか、対象アプリを再起動してください。通信を取り込む範囲を変える場合は、モードだけでなくシステムプロキシやTUNの設定を確認します。

旧クライアントでも従来の設定を読み込める場合はありますが、開発終了後はOSへの対応、プロトコルの追加、問題の修正が保証されません。移行前にローカルルール、上書き設定、サブスクリプションの配布元を保存し、必要な設定構文に対応した開発継続中のクライアントを選んでください。旧プログラムのフォルダー全体を新しいクライアントのフォルダーに上書きするのは避けましょう。まず元のサブスクリプションをインポートし、読み込みと接続を確認してから、カスタムDNS、ポート、ルールを一つずつ移行します。未対応の項目やプロトコルが見つかった場合は、新クライアントのログを確認し、設定の配布元に対応形式を問い合わせてください。

まず、取得エラーと解析エラーを切り分けます。401または403が表示される場合は、有効期限切れ、URLの再発行、サービス提供元によるアクセス制限を確認してください。タイムアウトする場合は、現在のネットワークと、クライアントのサブスクリプション更新時に使うプロキシ設定を確認します。YAMLの解析エラーが表示された場合、取得した内容がログイン画面やエラーページだったり、設定形式に互換性がなかったりする可能性があります。URL全体をコピーし直し、余計な空白が入らないようにしてください。更新前に使用中の設定を残し、失敗しても何度も削除・再作成しないでください。認証情報を含むURLを、信頼できないオンライン変換サービスに入力するのも避けましょう。

まずクライアントの設定で、サービスモード、補助プログラム、仮想NICコンポーネントが正しくインストールされているか確認し、クライアントの案内に従って権限を許可してください。Windowsでは必要な権限を持つサービスのインストールが必要になることが多く、macOSではネットワーク関連の権限を許可する場合があります。Linuxの権限設定は、パッケージやサービスの構成によって異なります。サービスのインストールエラーを隠すために、プログラム全体の権限を恒常的に拡大しないでください。初回のテストでは他のVPNや仮想NICツールを終了し、TUNを有効にした後、ログでNICやルートのエラーを確認します。ネットワークに接続できなくなった場合は、まずTUNを無効にして通信を復旧し、エラーの内容を確認してください。

まず、重複して起動しているクライアントを終了し、対象ポートを使用しているプロセスを調べます。用途を確認してから停止するか判断し、正体の分からないシステムサービスを終了しないでください。クライアントのポート設定でmixed-portを変更する方法もあります。適用後、ログで新しいポートの待ち受けを確認してください。続いてシステムプロキシをいったん無効にして再度有効にし、ブラウザーの手動プロキシ、ターミナルの環境変数、アプリ内のプロキシアドレスも更新します。external-controllerは制御用インターフェースで、ブラウザー向けのプロキシポートではありません。混同しないでください。サブスクリプションの上書き設定でポート値が戻る場合があるため、更新後も変更が保持される場所に設定してください。

アプリコンテナーの制限により、一部のWindowsアプリはローカルのループバックプロキシに直接接続できません。まず、通常のブラウザーが同じクライアント経由で接続できることを確認します。そのうえでクライアント付属のUWPループバックツールを使い、ローカルプロキシが必要なアプリだけにループバックの例外を設定してください。操作に管理者権限が必要な場合があります。ツールがない場合は、WindowsのCheckNetIsolationを使ってアプリパッケージIDごとに設定できます。すべてのアプリに無条件で例外を設定しないでください。クライアントがTUNで通信を取り込んでいる場合、原因はルートやDNSの可能性もあります。ログを確認して切り分け、ストアアプリの不具合をすべてループバックの問題と決めつけないようにしましょう。

システムプロキシの設定が適用されるのは、その設定を参照するアプリだけです。ブラウザー拡張機能、ブラウザー独自のプロキシ設定、ターミナルの環境変数によって、実際の通信経路が変わることがあります。まずプロキシ拡張機能を一時的に無効にし、システム設定のプロキシアドレスがクライアントの待ち受けポートを指しているか確認してから、ブラウザーを個別にテストしてください。ターミナルではHTTP_PROXY、HTTPS_PROXY、ALL_PROXYと、それぞれの小文字表記を確認します。変更後はターミナルを開き直してください。制御用インターフェースのポートをプロキシ設定に入力しないでください。システムプロキシを参照しないアプリでは、アプリ内のプロキシ設定を使うか、ルートと権限を確認したうえでTUNを利用します。

速度テストで分かるのは、クライアントから指定されたテスト先へ送った一度のリクエストの結果です。すべてのWebサイト、プロトコル、接続方法が使えることを示すものではありません。まず現在のルールがどのプロキシグループに一致したか、そのグループでどの接続先が選択されているかを確認し、失敗したリクエストのログを調べてください。テスト先には接続できても目的のサイトを開けない場合、接続先の制限、DNS、サーバーの出口、プロトコルの互換性などが原因として考えられます。遅延の順に並べて何度も切り替えるだけでは解決しません。同じ接続先とモードで出口を一つずつ比較し、切り替え後に既存の接続を閉じれば、選んだノードによる変化か判断しやすくなります。

クライアントの上書き設定、設定のマージ、ルール拡張機能を優先して使い、次回更新で置き換わるサブスクリプションのキャッシュファイルは直接編集しないでください。対象のドメインと適用したいポリシーを記録し、先に一致する可能性がある広範なルールより前に追加します。通常、MATCHは末尾のフォールバックルールとして使います。ポリシー名は、設定内のプロキシグループ名と完全に一致させてください。適用後、接続の詳細またはログで実際に一致したルールを確認し、サブスクリプションを更新してもルールが残ることを確かめます。GEOSITEなどのルールは対応するデータファイルとコアのサポートも必要です。実行環境を確認せず、ルール文だけをコピーしないでください。

クライアントの設定で自動起動を有効にした後、OSのスタートアップ項目やログイン項目でも実行が許可されているか確認してください。クライアントの自動起動、システムプロキシの自動有効化、TUNの自動起動は別々の設定であることが多く、一つのスイッチですべて設定できるとは限りません。再起動後、プロセス、使用中の設定、ポートの待ち受けを確認してからWebページを開いてテストします。終了前にクライアントを正常に停止しなかった場合、OSにローカルプロキシの設定が残り、クライアントが起動していないとネットに接続できないことがあります。その場合はシステムプロキシを無効にして接続を復旧し、自動起動の権限とサービスの状態を確認してください。

まずプロキシを無効にし、普段直接接続できるサイトにローカルネットワークからアクセスできることを確認します。次に、システム時刻、サブスクリプションの状態、現在の設定が読み込まれているかを確認してください。プロキシを再び有効にしたら、接続先を一つだけ選んで同じ宛先をテストし、ログでサーバー接続のタイムアウト、認証エラー、接続先への接続失敗のどれかを確認します。別のネットワークで試すと、現在のネットワークによる接続制限を判断しやすくなります。その際、ほかの設定は変えないでください。複数の接続先が異なるネットワークでも失敗する場合は、サービス提供元に稼働状況を問い合わせます。タイムアウト時間を延ばしても待ち時間が長くなるだけで、無効なアドレス、認証ミス、接続先への到達不能は解決しません。

まず、名前解決に失敗しているのか、DNSの経路が想定と異なるのかを切り分けます。有効な設定のdns項目と、クライアントの上書き設定によってnameserver、fallback、拡張モードが変更されていないかを確認してください。各項目の動作はコアの対応状況にも左右されます。ブラウザーのセキュアDNS、OSの暗号化DNS、別のVPNが独自の名前解決経路を使っている場合があるため、一つずつ記録して比較します。TUNを使っている場合は、DNSのリダイレクトとルーティングが実際に機能していることも確認してください。DNSテストサイトに表示されるリゾルバーの場所は参考情報であり、すべてのアプリの名前解決経路を証明するものではありません。変更後はログと実際のリクエストを確認してください。

証明書検証を無効にしたり、入手元の不明なルート証明書をインストールしたりして、エラーを回避しないでください。まずシステムの日付、時刻、タイムゾーンが正しいことを確認し、プロキシを無効にした場合、接続先を切り替えた場合、ネットワークを変更した場合の結果を比較します。特定の接続先だけで証明書エラーが起きる場合は、その接続先の利用を中止し、サービス提供元に報告してください。企業ネットワーク、公共Wi-Fiのログインページ、セキュリティソフトによるHTTPS検査が証明書チェーンに影響することもあります。ネットワーク管理者の指示に従って対応してください。報告にはエラーコードと接続先ドメインを記載し、アカウント情報、サブスクリプションURL、リクエスト全体を含むスクリーンショットやログは送らないでください。

まずOSのネットワーク設定で残っている手動プロキシを無効にし、通常のネットワーク接続が復旧するか確認してください。TUNを使っていた場合は、クライアントを再起動した後、通常の手順でTUNを無効にします。必要に応じてOSを再起動し、一時的なルートを削除してください。再インストールする前に、設定フォルダー、上書きルール、障害発生時のログをバックアップし、共有前にサブスクリプションURLと認証情報を削除します。その後、最小限の設定で起動し、機能を一つずつ戻して、どの設定や権限操作でクラッシュするか確認してください。モバイル端末では、VPNの許可、バッテリーによるバックグラウンド制限、ほかのVPNとの競合も確認します。調査の手掛かりを失わないよう、アプリのデータをすぐに消去しないでください。