Clashのトラブル対処

クライアントは設定のインポート、モード切り替え、ログ確認のための画面を提供します。コアは接続を受け付け、ルールに基づいて通信を振り分けます。サブスクリプションには通常、プロキシ情報または設定一式が含まれます。クライアントをインストールしただけでは通信できず、利用可能な設定のインポートが必要です。また、クライアントを更新してもサブスクリプションは更新されません。問題を切り分けるときは、画面操作、コアの動作、リモートのリソースのどこに原因があるかを確認し、すべてをクライアントのバージョンのせいにしないようにしましょう。

ルールモードはルール一覧に従って接続先を振り分けるため、日常的な使い分けに適しています。グローバルモードでは、コアに届いた接続をグローバルのプロキシグループに渡すため、短時間の比較テストに使えます。ダイレクトモードでは、コアに届いた接続を宛先へ直接接続します。グローバルモードにしても端末全体の通信が自動的にプロキシ経由になるわけではありません。アプリの通信をコアに渡すには、システムプロキシまたはTUNが必要です。テスト後はルールモードに戻し、ほかのアプリの接続経路が変わらないようにしましょう。

システムプロキシはアプリにプロキシのアドレスを知らせる仕組みで、実際に使うかどうかはアプリのネットワーク実装によります。ブラウザーは通常システム設定を参照しますが、一部のゲームやコマンドラインツール、独自のネットワーク機能を持つアプリは参照しません。まずクライアントの接続画面に対象の通信が表示されるか確認し、次にアプリがHTTPまたはSOCKSプロキシを個別に設定できるか調べましょう。より多くの通信をプロキシ経由にする必要がある場合はTUNを検討し、グローバルモードの切り替えだけで解決しようとしないでください。

どちらも設定のインポートに使えますが、管理方法が異なります。リモートのサブスクリプションはクライアントの設定に従って内容を再取得できますが、ローカルファイルは通常、保存時点の内容のままで、リモート側の変更は反映されません。ノード一覧が完全なClash設定とは限らないため、インポート前に提供元が対応形式を確認してください。変換が必要な場合は、信頼できるローカルツールを優先しましょう。サブスクリプションURLにはアクセス用の認証情報が含まれることがあるため、見知らぬ変換サービスに送信しないでください。

よく使われるモードや基本的なルール項目には共通点がありますが、プロトコル、ルールの種類、DNS設定はすべて互換というわけではありません。mihomoはClash Metaの開発を引き継ぎ、多くの拡張機能を備えているため、旧版コアでは一部の項目を認識できない場合があります。設定の解析エラーが出たら、ログに記載された項目名を確認し、コアのドキュメントと照らし合わせてください。エラー項目を削除して使い続けるのではなく、設定形式とクライアントの組み合わせを見直しましょう。

設定画面でサブスクリプションをインポートしたら、対象の設定を選択し、コアが正常に読み込まれ、ログに解析エラーがないことを確認します。次にルールモードへ切り替え、該当するプロキシグループで利用可能な接続先を選びましょう。デスクトップではシステムプロキシを有効にしてブラウザーでテストし、モバイルでは画面の案内に従ってVPN接続を許可します。最後に接続履歴で適用されたルールと接続先を確認し、通信がコアに届いていることを確かめてから、自動更新やTUNなどの設定を検討してください。

まずログを確認し、権限不足、仮想ネットワークアダプターの作成失敗、ルート設定の失敗を切り分けます。Windowsのデスクトップクライアントでは、通常、サービスモードをインストールして起動するか、プロジェクトの手順に従って管理者権限で実行します。macOSとLinuxでも、それぞれ必要な権限を確認してください。続いて、ほかのVPNがネットワーク機能を使用していないか確認します。ネットワークアダプターの削除や複数のルート変更を一度に行わず、まずTUNを無効にして基本の接続を復旧し、項目ごとに検証しましょう。

まず、クライアントを二重に起動していないか、古いコアのプロセスが残っていないか確認します。別のサービスがポートを使用している場合は、クライアントの設定で未使用のローカルポートに変更し、設定を適用してからシステムプロキシをいったんオフにして再度オンにします。プロキシを手動設定しているブラウザー、ターミナル、ほかのアプリでもポートを更新してください。YAMLだけを変更してクライアント側の上書き設定を見落とさないようにし、最終的には実行中の設定と実際の待ち受け状態を確認しましょう。

AppContainerで隔離された一部のWindowsアプリは、初期設定ではローカルのループバックプロキシに接続できません。まず通常のブラウザーが同じプロキシで接続できることを確認し、必要なアプリに限ってクライアント付属のUWPループバックツールでループバックの例外を設定します。操作には管理者権限が必要な場合があります。すべてのストアアプリに当てはまるわけではありません。例外を有効にしても解決しない場合は、アプリのプロキシ対応状況、DNS、接続ログを確認してください。

設定をインポートしただけではリソースが保存されるだけなので、クライアントで接続を開始し、システムのVPN許可画面で接続を許可する必要があります。ほかのVPNが動作していないか確認し、現在の設定が選択され、正常に読み込まれていることも確かめてください。Androidで切断を繰り返す場合は、バッテリー最適化とバックグラウンド動作の制限を確認します。iOSではシステムのVPN設定で接続状態を確認できます。クライアントの画面を閉じても接続が停止するとは限りません。システムとクライアントの表示で実際の状態を確認しましょう。

同じではありません。クライアントの設定画面にある自動更新は通常、リモート設定全体を再ダウンロードする機能で、時間の単位はクライアントによって異なります。proxy-providersのintervalは通常、秒単位で、コアが対象のプロキシ一覧を取得する間隔を指定します。ルールセットにも独立した更新間隔が設定されている場合があります。更新対象が設定全体、プロキシ一覧、ルールのどれなのかを確認してから、該当する項目を変更してください。画面上の分数を、そのままコアの設定項目に入力しないようにしましょう。

リモートのサブスクリプションからダウンロードしたファイルを直接編集している場合、次回の更新で変更が上書きされることがあります。ルールを継続して使うには、クライアントが対応する上書き、マージ、スクリプト機能を使い、ルールの挿入位置も確認してください。ルールは上から順に評価されるため、最終的なフォールバックルールの後に追加しても適用されないことがあります。変更前にバックアップを取り、更新後はエディターの表示だけでなく実行中の設定を確認し、接続履歴で新しいルールが適用されたか確かめましょう。

クライアントの接続画面を開いた状態で対象のWebサイトにアクセスし、ドメイン名またはプロセス名で新しい接続を探します。適用されたルールの種類、プロキシグループ、最終的な接続先を確認してください。ブラウザーのキャッシュや既存の長時間接続があると、ルールを変更してもすぐに結果へ反映されない場合があります。該当する接続を閉じてから再試行しましょう。Webサイトは複数のドメインを使うことが多いため、アドレスバーのメインドメインだけで判断しないでください。接続画面に記録がない場合は、システムプロキシまたはTUNがアプリの通信を取り込んでいるか確認します。

信頼できるLAN内で「LAN接続を許可」を有効にし、待ち受けアドレスとファイアウォールの受信ルールを確認します。ほかの端末には、クライアントを実行している端末のLAN内アドレスとプロキシポートを入力してください。127.0.0.1は各端末自身を指すため、使用しないでください。必要なプロキシポートだけを開き、コントロール用インターフェースは公開しないようにしましょう。公共のネットワークではこの機能を無効にし、認証が必要な場合はコアが対応する方法でアクセスを制限してください。

通常は必要ありません。まず端末の基本的なネットワーク接続が復旧していることを確認し、システムプロキシまたはTUNをいったんオフにして再度オンにすると、クライアントが通信の取り込み状態を再構築できます。古い接続が残っている場合は、接続を切ってから再試行してください。Wi-Fiの切り替えでゲートウェイ、DNS、利用可能なルートが変わることがあります。再インポートするより、ログに記録された名前解決や接続エラーを確認するほうが有効です。リモート設定の変更、無効化、読み込み異常が確認できた場合に限り、サブスクリプションを更新または再インポートしてください。

まず、サブスクリプションURLが最後までコピーされているか、アカウントが有効か、クライアントがその形式に対応しているか確認します。次に更新ログを確認してください。401や403は認証またはサーバー側のアクセス制限、404はURL、タイムアウトは現在のネットワークや更新リクエストの接続経路に関係することがあります。クライアントがプロキシ経由の更新に対応している場合は、経由の有無を比較してテストしましょう。短時間に何度も更新を試さないでください。提供元に問い合わせる際は、サブスクリプションの認証情報を隠し、ステータスコードとエラーの概要だけを伝えましょう。

必ずしもそうではありません。遅延テストの失敗は、テスト用リクエストが制限時間内に完了しなかったことを示すだけです。テスト先、DNS、プロトコルの対応状況、利用中の回線などが原因になることがあります。同じ設定内のほかの接続先と比較し、実際のWebアクセスやコアのログも確認してください。特定の接続先だけ失敗する場合は、別の接続先に切り替え、リソースの提供元に問い合わせましょう。すべての接続先が同時に失敗する場合は、ローカルネットワーク、システム時刻、コアの動作を確認します。テスト結果だけを見てサブスクリプションを削除しないでください。

まず、コアが設定されたポートで待ち受けているかを確認し、OSのプロキシ設定とアドレス・ポートが一致しているか照合します。プロキシ設定を書き換える可能性のあるブラウザー拡張機能や、ほかのプロキシクライアントを一時的に無効にしてから、接続画面でリクエストを確認してください。接続記録がない場合は通信の取り込み経路を、記録があるのに失敗する場合は適用ルール、名前解決の結果、接続先のエラーを確認します。クライアント終了後にネットワーク異常が起きた場合は、停止済みのポートを指すプロキシ設定がOSに残っていないかも確認してください。

まず、どのような動作を想定しているか確認しましょう。振り分け設定によって一部のドメインを意図的にローカルDNSで解決する場合があり、ローカルのリゾルバーが表示されても必ずしも異常ではありません。コアのDNSログ、システムの名前解決設定、ブラウザーのセキュアDNSを照らし合わせ、実際の経路を確認してください。Fake-IPモードでは、一部のデバイス検出機能や特殊なアプリが非対応の場合があります。ドキュメントを参照し、該当ドメインにフィルターを設定してください。設定を変更したら、システムとブラウザーのDNSキャッシュを消去して接続し直します。複数の名前解決設定を同時に変更しないでください。

クライアント名、コアのバージョン、OS、プロキシモード、再現可能な操作手順を記録し、問題発生の前後に関係するログを抜き出します。ステータスコード、エラーになった項目、接続の段階を残せば、設定の解析、DNS、通信転送のどこに問題があるかを切り分けやすくなります。共有前にサブスクリプションURL、認証情報、コントロール用インターフェースのキー、プライバシーに関わるドメインやアドレスを隠してください。設定ファイル全体をそのまま公開しないでください。調査後は通常のログレベルに戻し、不要な接続情報を長期間記録しないようにしましょう。