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

Clashは一般に、プロキシコアとその設定エコシステムを指します。mihomoは、そのエコシステムで継続的に開発されているコアプロジェクトです。Clash Verge RevやFlClashなどのクライアントは、設定のインポートやプロキシグループの選択、システム連携のための画面を提供し、実際の通信処理はコアが担います。同じ設定をインポートできるかどうかは、アプリ名だけでなく、クライアントに搭載されたコアのバージョンや設定項目への対応状況によって決まります。互換性の問題を報告するときは、クライアント名とそのバージョン、コアのバージョンを併せて記録してください。

クライアントは通信を取り込み、ルールを適用する機能を提供しますが、インストーラーだけでプロキシサービスを利用できるわけではありません。接続には通常、サービス提供元のサブスクリプションURL、または自分で管理するプロキシサーバーの設定が必要です。インポート後は、設定が有効になっていることを確認し、プロキシグループに選択可能なプロキシがあるか確認してください。一般のWebサイトのURLをサブスクリプションURLとして使ったり、出所不明のオンライン変換サイトにURLを入力したりしないでください。URLにアカウント情報へアクセスできる認証情報が含まれている場合があります。

ルールモードは、設定されたルールの順序に従って通信先を決めるため、Webサイトやアプリごとに振り分けたい場合に適しています。グローバルモードでは、コアが処理する接続にグローバルポリシーを適用しますが、通信を取り込まれていないアプリまでプロキシ経由になるとは限りません。ダイレクトモードでは、コアが処理する接続を宛先へ直接接続します。切り分けのため一時的にグローバルモードへ切り替えて比較してもかまいませんが、テスト後は元のモードに戻してください。グローバルモードでは接続できてルールモードではできない場合、ルールのマッチ状況と該当するプロキシグループを確認しましょう。

システムプロキシは、システム設定に従うアプリにプロキシのアドレスを通知します。一方、TUNは仮想ネットワークインターフェースとルーティングを使い、より多くの通信を取り込みます。両方を同時に有効にする必要はなく、機能も同じではありません。初めて設定するときは、まずシステムプロキシだけを有効にしてブラウザーが接続できることを確認し、その後、ゲームやコマンドラインなど必要なアプリに応じてTUNを試してください。両方を併用できるクライアントもありますが、不具合が起きた場合は切り分けやすいよう、一度に有効にする通信の取り込み方式を一つに絞り、ほかのVPNやプロキシツールとの併用も避けてください。

公開されているプロキシは突然使えなくなることがあり、運営元や通信ポリシー、メンテナンス期間も確認できない場合が多いため、長期利用を前提にしないでください。プロキシはWebサイト自体の暗号化を代替するものではありません。重要なアカウントにログインする際はHTTPSが正常に機能していることを確認し、出所不明の証明書をインストールするよう求められても応じないでください。接続できないときは、特定のプロキシが使えないのか、端末側の通信取り込みに問題があるのかを切り分けましょう。プロキシを変えるために、見知らぬクライアントを何度もインストールするのは避けてください。ネットワークサービスを利用する際は、利用地域の法律とサービス利用規約も守ってください。

まずサービス提供元のアカウントページで、サブスクリプションの有効期限やURLがリセットされていないか確認します。コピー時に空白が入ったり、クエリパラメーターが欠けたりしていないかも確認してください。403は通常、リクエストが拒否されたことを示しますが、アクセス制限やクライアントの識別情報が関係している場合もあります。提供元の案内と照らし合わせて判断しましょう。プロキシ経由の更新だけ失敗する場合は、クライアントが対応していればダイレクト接続で更新を試してください。ダイレクト接続でアクセスできない場合は、接続できると確認済みのプロキシを使います。それでも失敗する場合は、ステータスコードと発生時刻を記録して提供元に問い合わせ、サブスクリプションURL全体は公開しないでください。

まずファイル形式のエラーとコアの互換性の問題を切り分けます。YAMLはインデントで階層を表すため、タブではなくスペースを使い、コロン、リストのハイフン、引用符の対応も確認してください。ログに認識できない項目が示されている場合は、設定が必要とするコアの種類と現在のコアのバージョンを確認します。Webサイトからダウンロードしたログインページやエラーページは設定としてインポートできません。変更前に元ファイルを保存し、一度に一か所だけ修正して再検証してください。サブスクリプションから生成された設定は、更新で変更が失われないよう、クライアントのオーバーライド機能で編集するのがおすすめです。

まず、利用中のクライアントとOSが、選択したTUNの方式に対応しているか確認してください。Windowsでは通常、クライアントが提供するサービスモードをインストールして起動する必要があります。macOSではシステムの案内に従って補助サービスを許可し、Linuxではクライアントのドキュメントに沿って仮想インターフェースやルーティングに必要な権限を設定してください。すべてのプログラムにむやみに高い権限を与えないでください。許可した後にコアを再起動し、インターフェースが作成されたか確認します。それでも失敗する場合は、ほかのVPNを終了して再試行し、インターフェースの作成やルート追加時に出たエラーを記録してください。

システムプロキシのアドレスがlocalhostを指しているか、ポートが現在の設定の待ち受けポートと一致しているかを確認し、コアが起動中であることも確かめてください。ブラウザー拡張機能や個別のプロキシ設定、組織のポリシーがシステム設定を上書きすることがあります。競合する設定を無効にしてからテストしましょう。クライアントの接続履歴を開き、Webサイトにアクセスしても新しい接続が記録されない場合は、通信の入口を確認します。接続が記録されているのにダイレクト接続が選ばれている場合は、モードとルールを確認してください。出口IPの確認ページだけで判断しないでください。キャッシュやサイトごとの振り分け、ブラウザーの動作も結果に影響します。

ポートが使用中の場合は、重複して起動しているクライアントを終了するか、使用中のプロセスを特定したうえで、mixed-portに空いているポートを設定し、アプリ側のプロキシアドレスも更新してください。HTTPプロキシとSOCKSプロキシは任意に混在させず、アプリが対応するプロトコルを設定します。ターミナルのツールはシステムプロキシを参照しない場合があり、HTTP_PROXY、HTTPS_PROXY、またはALL_PROXYを個別に設定する必要があります。切り分け時はまず一時的に設定し、動作を確認してから永続化するか判断してください。クライアントを終了する前に、不要になった環境変数を削除しましょう。

プロキシグループの切り替えは通常、新しく作成される接続に反映されます。すでに確立した接続は、以前のプロキシを使い続けることがあります。再生を一時停止して該当ページを閉じ、開き直すか、クライアントの接続一覧で該当する接続だけを閉じてから、新しい接続履歴のルールチェーンを確認してください。アクセス先が、変更したプロキシグループに実際にマッチしているかも確認しましょう。動画、ダウンロードなどの通信に別々のグループを設定している場合があります。日常的にすべての接続を一括で閉じると、ファイル転送や会議など進行中の処理が中断されるため避けてください。

接続履歴から、アクセス先のドメイン名やアプリを手がかりに直近のリクエストを探し、マッチしたルール、プロキシグループ、最終的な接続先を確認してください。ルールは通常、上から順に評価されます。広い範囲にマッチするルールが前にあると、後続の詳細なルールより先に適用されることがあります。変更前に対象のドメイン名と現在のマッチ結果を記録し、必要な詳細ルールを適切な位置に移してください。MATCHは通常、最後のフォールバックとして使われます。GEOSITEやルールセットを使っている場合は、関連データファイルとrule-providersが正常に読み込まれているかも確認しましょう。

サブスクリプションから生成されたファイルを直接編集すると、次回の更新でリモート側の内容に上書きされることがあります。ルールを長期的に保持したい場合は、クライアントのオーバーライド、マージ、スクリプト拡張機能を利用し、適用順も確認してください。設定画面の場所やマージ方法はクライアントによって異なります。保存前にバックアップをエクスポートし、更新後はエディターの表示だけでなく、最終的に有効な設定を確認しましょう。追加したルールが参照するプロキシグループは実在している必要があります。存在しない場合、読み込みエラーや接続先の参照エラーが起きることがあります。

遅延テストで分かるのは通常、一度のリクエストの往復時間であり、持続的な通信速度や混雑状況、特定サイトへの接続品質を示すものではありません。同じダウンロード先を使い、ダイレクト接続と異なるプロキシを比較してから、Wi-Fiの状態、バックグラウンドのダウンロード、サーバー側の速度制限を確認してください。特定のサイトだけ遅い場合は、そのサイトに実際に適用されているプロキシと名前解決されたアドレスを確認し、テストボタンの結果だけで判断しないでください。原因を特定しやすくするため、テスト条件を揃え、DNS、モード、プロキシを同時に変更しないようにしましょう。

通常は必要ありません。ホテルや学校、交通機関のWi-Fiでは、Webページでのログイン認証が必要な場合があり、プロキシやTUNが認証ページの表示を妨げることがあります。いったん通信の取り込みを無効にして認証を完了し、通常のWebページにアクセスできることを確認してから、元の設定に戻してください。ネットワークを切り替えた後も一部の接続に問題がある場合は、該当する接続を作り直し、DNSの状態を確認しましょう。ネットワークを一度切り替えただけで元の設定を削除する必要はありません。アカウントのURLが無効になった場合や、提供元から変更を指示された場合に限り、サブスクリプションを再インポートしてください。

まずプロキシを無効にし、通常のネットワーク接続が使えることを確認します。次に、サブスクリプションが正常に更新できること、アカウントが有効であること、端末の日付と時刻が正確であることを確かめてください。その後、別のプロキシで同じ接続先にアクセスします。特定のプロキシだけ失敗する場合は、サービス提供元への問い合わせを優先してください。すべてのプロキシで失敗する場合は、ファイアウォールやプロキシのポート、ほかのVPNとの競合を確認します。最後にログを見て、サーバー接続のタイムアウト、名前解決の失敗、接続先サイトによる拒否を切り分けます。測定を何度も繰り返すだけで済ませたり、すべてのタイムアウトをクライアントのせいにしたりしないでください。

まず設定内のDNSアップストリームに接続できるか、プロキシサーバーへの接続に必要なドメイン名を解決できるか確認してください。まだ確立していないプロキシ経由で名前解決しようとすると、循環依存が起きることがあります。一部のアプリだけで問題が起きる場合は、アプリ内蔵の暗号化DNS、古いアドレスのキャッシュ、fake-ipへの対応状況を確認してください。設定を調整した後、クライアントが提供する手順でDNSキャッシュを消去し、接続を作り直します。複数のDNSハイジャックツールをむやみに重ねて使わないでください。DNSモードを切り替える前に元の設定を保存し、TUNのルートも同時に変わっていないか確認しましょう。

AppContainerで分離された一部のアプリは、既定ではローカルループバックアドレスにアクセスできません。ブラウザーが使えても、ローカルプロキシには接続できないことがあります。まず該当アプリがこの制限の対象か確認し、クライアントのUWPループバック例外設定から、必要なアプリだけを許可してください。管理者はシステムコマンドCheckNetIsolation LoopbackExempt -sで、現在の例外を確認できます。この問題はすべてのストアアプリに当てはまるわけではありません。許可しても接続できない場合は、アプリがシステムプロキシを参照しているか、通信がコアに届いているかを引き続き確認してください。

まず、システムにlocalhostを指す手動プロキシ設定が残っていないか確認してください。コアが終了していると、そのアドレスでは通信できません。残ったプロキシ設定を無効にするか、クライアントを再起動し、通信の取り込みを正常に解除してください。以前TUNを使っていた場合は、仮想インターフェース、ルート、DNSが元に戻っているか確認します。必要であればクライアントの修復機能を使い、ネットワークに再接続してください。職場のネットワークでは指定プロキシが必要な場合があるため、変更前に元の設定を記録しましょう。VPNや固定IP、職場のネットワーク設定を失わないよう、ネットワーク設定の全リセットは最後の手段にしてください。

まずOS、クライアントとコアのバージョン、使用中のモード、問題が発生した時刻を記録します。問題を一度再現し、その前後の関連ログを抜き出してください。ログレベルを一時的に上げた場合は、アクセスの詳細を長期間記録しないよう、速やかに元へ戻します。共有前にサブスクリプションURL、認証パラメーター、サーバーの認証情報、公開したくないドメイン名やIPアドレスを削除し、必要に応じてエラーの種類とルールチェーンだけを残してください。設定例は再現に必要な最小限の部分だけを提示し、削除した箇所があることを明記します。サブスクリプションURLを公開してしまった場合は、投稿を削除するだけでなく、サービス提供元でURLをリセットしてください。