Clashのよくある質問と接続トラブルの対処法

Clashは一般に、ルールベースのプロキシツールとその設定エコシステムを指します。mihomoはプロトコル接続、ルール照合、DNS処理を担うコアです。デスクトップクライアントは、設定の読み込みやプロキシグループの選択、システムプロキシ、ログ表示などのGUIを提供します。同じコアを使うクライアントでも、メニューの場所やサービスのインストール方法、オーバーライド機能は異なる場合があります。問題を調べる際は、Clashを使っているという情報だけでなく、クライアント名とクライアント・コアそれぞれのバージョンを記録してください。設定項目が使えるかどうかは、実際に動作しているコアの対応範囲で判断します。

クライアントは設定を読み込んで接続を確立します。インストールしただけでは、利用可能なプロキシサービスが使えるとは限りません。通常は、用意したYAML設定ファイルを読み込むか、サービス提供元からサブスクリプションURLを入手し、設定画面からダウンロードして有効にします。ルールだけがあり、利用可能なプロキシ項目がないファイルでは、リモート接続を確立できません。読み込み後は設定が選択されていることを確認し、プロキシ画面でプロキシグループに選択可能な項目があるか確認してください。サブスクリプションURLは機密情報です。画面を共有する際は、URL全体、ユーザー識別情報、アクセス用パラメーターを隠してください。

ルールモードは、設定内のルール順に従ってポリシーを選択します。ドメインやアドレス、地域ごとに通信を振り分ける日常的な使い方に適しています。グローバルモードでは通常、コアに入った接続をグローバルプロキシグループに渡します。ダイレクトモードでは、コアに入った接続が宛先へ直接アクセスします。グローバルモードでも、端末上のすべての通信が自動的にプロキシされるわけではありません。アプリの通信がシステムプロキシやTUNなどを通じてコアに入る必要があります。特定のサイトで問題が起きたら、一時的にグローバルモードに切り替えて比較し、その後ルールモードに戻してください。グローバルでは接続できてルールモードでできない場合は、適用されたルールとプロキシグループを優先して確認します。

必ずしも必要ではありません。システムプロキシはOSの設定にプロキシアドレスを書き込み、その設定を参照するアプリに主に適用されます。TUNは仮想ネットワークアダプターとルーティングを使って条件に合う通信を取り込み、システムプロキシを参照しないプログラムで使われます。初めて設定する場合は、まずシステムプロキシだけを有効にし、サブスクリプション、プロキシグループ、接続が正常なことを確認してから、必要に応じてTUNを試してください。両方を有効にできるクライアントもありますが、同時使用ですべての問題が解決するわけではありません。他のVPNやプロキシツールも動作している場合は、ルーティングやDNSの競合を避けるため、まずどちらか一方を停止してください。

クライアントの設定画面を開き、新しい設定、リモート設定、またはサブスクリプションの読み込み項目を探します。サービス提供元から受け取ったURL全体をURL欄に貼り付け、読み込みを実行してください。ダウンロード後は、その設定を有効化または選択し、プロキシ画面でプロキシグループから利用可能なプロキシを選びます。最後に設定画面でシステムプロキシを有効にし、ブラウザーから対象サイトにアクセスして確認します。ボタン名はクライアントによって多少異なります。ローカルのYAMLファイルを読み込む場合は、ファイルからの読み込みを選択してください。ファイルパスをサブスクリプションURL欄に入力してはいけません。

まず設定画面で手動更新を一度実行し、同じ時刻のログを確認してください。リクエストがタイムアウトする場合は、現在のネットワークと、サブスクリプション更新時に使われるプロキシ経路を確認します。401や403などの応答がある場合は、URLの利用権限と有効期限をサービス提供元に確認してください。Webページやログイン画面が返された場合、それをYAML設定として読み込むことはできません。ログに行番号が示されている場合は、インデント、コロンの後のスペース、重複した項目、コアが対応していない設定項目を確認します。元のエラーを見失わないよう、複数の設定を一度に変更しないでください。サブスクリプションURL全体を含むログを公開するのも避けてください。

7890は混合ポートの例としてよく使われる値です。実際のポートは、クライアントの設定または有効な設定ファイル内のmixed-portを確認してください。ログにアドレス使用中のエラーが出た場合は、まず他のプロキシクライアントを終了し、古いプロセスがバックグラウンドで残っていないか確認します。競合が続く場合は、未使用のローカルポートに変更して設定を適用してください。その後、ブラウザー拡張機能、ターミナルの環境変数、手動で設定したほかのプロキシアドレスも更新します。設定ファイルだけを変更してアプリ側に古いポートを残さないでください。システムプロキシが自動で更新されたかどうかも、OSの設定で確認します。

まず、クライアントが提供するサービスモードがインストールされ、起動しているか確認してください。Windowsでは通常、サービスのインストールを許可するか、管理者権限で関連操作を行う必要があります。macOSではクライアントの実装によって、システム設定でネットワーク機能拡張や補助サービスを許可する場合があります。権限、ドライバー、ネットワークアダプターの作成に関するログのエラーを記録し、クライアントの案内に従ってサービスを修復してください。提供元が不明なドライバーを繰り返しインストールしないでください。組織の管理ポリシーで制限されている端末は、管理者に相談してください。修復するまではTUNを無効にし、システムプロキシで基本的な接続を確認できます。

速度テストでは通常、設定で指定されたテスト用アドレスにアクセスします。そのテストが成功しても、すべてのサイト、プロトコル、DNSリクエストが使えるとは限りません。まず現在のプロキシグループでどのプロキシが選択されているか確認し、HTTPSサイトにアクセスして接続画面を見てください。対象ドメインに適用されたルール、最終的に使われたポリシー、名前解決エラーや接続リセットがログにないかを確認します。必要であれば別のプロキシと比較しますが、一度に変更するのは一項目だけにしてください。ほかのアプリは使えるのにブラウザーだけ失敗する場合は、ブラウザー拡張機能、独自のプロキシ設定、安全なDNSも確認します。

まずクライアントのローカルルールまたはオーバーライド機能を使い、対象ドメインのルールを、より広範なルールや最後のMATCHルールより前に追加します。DOMAINは完全一致のドメインに、DOMAIN-SUFFIXは指定したドメインとそのサブドメインに使います。ルール末尾のポリシー名は、現在の設定にあるプロキシグループ名と一致させてください。保存して適用したら、新しい接続を発生させ、接続画面で適用結果を確認します。Webページが別のリソース用ドメインにもアクセスする場合は、必要に応じて個別に追加してください。リモートサブスクリプションが生成したファイルを直接編集すると、次回の更新で変更が上書きされることがあります。

クライアントの設定でLAN接続を許可し、待ち受けアドレスが127.0.0.1だけに限定されていないことを確認します。パソコンのLAN内アドレスと実際の混合ポートも控えてください。他の端末には、その端末自身のループバックアドレスではなく、プロキシを動かしているパソコンのLAN内アドレスを入力します。両方の端末が相互に通信できる必要があります。接続できない場合は、ホスト側のファイアウォール、ゲストネットワークの端末間通信制限、Wi-Fiアクセスポイントの分離設定を確認してください。信頼できるLAN内だけで公開し、必要に応じて認証を設定してアクセス範囲を制限してください。プロキシポートをインターネットに公開してはいけません。パソコンがスリープしたり、IPアドレスが変わったりすると、他の端末からの接続も切断されます。

リモートサブスクリプションを更新すると、設定ファイルが再生成されることが多く、ダウンロードしたファイルに直接書き込んだルール、DNS、プロキシグループの設定は上書きされる場合があります。まず有効な設定をバックアップし、クライアントが対応するローカルオーバーライド、設定のマージ、スクリプト拡張機能などを使って独自の設定を保存してください。マージ順序はクライアントごとに異なり、追加したルールが自動的にMATCHより前に配置されるとも限りません。適用後は、最終的に有効な設定を確認し、ルールの適用結果をテストしてください。複数のオーバーライドを有効にしている場合は、項目の重複定義や相互上書きを避けるため、一つずつ無効にして比較します。

まずシステムプロキシのアドレスとポートが現在のクライアントを指しているか確認し、コアが実行中で設定が有効になっていることを確かめてください。ブラウザー拡張機能がシステムプロキシを上書きしている場合があります。ターミナルツールの中にはHTTP_PROXY、HTTPS_PROXY、または独自のプロキシ引数だけを参照するものもあるため、別途設定が必要です。対象のアドレスにアクセスするとき、クライアントの接続画面を確認します。該当する接続が見つからない場合は、まず通信の取り込み経路を調べます。接続はあるのにポリシーが違う場合は、ルールを確認してください。調査中は他のプロキシソフトを一時終了し、対象ドメインやアドレス範囲がシステムのプロキシ除外リストに入っていないかも確認します。

AppContainerで分離されている一部のUWPアプリは、既定ではローカルのループバックアドレスにアクセスできません。そのため、ブラウザーは使えても、ストアやメールアプリでは接続に失敗することがあります。クライアントにUWPループバック例外ツールがある場合は、案内に従って管理者権限で起動し、必要なアプリだけに例外を設定してください。その後、アプリを完全に終了してから再起動します。Windowsに詳しいユーザーであれば、CheckNetIsolationで例外リストを管理する方法もあります。すべてのアプリを一括で許可するのは避けてください。例外設定後も、接続がコアに入っているのに失敗する場合は、ルール、DNS、アプリ自体のサービス状態を引き続き確認します。

まずプロキシを無効にし、通常は直接接続できるサービスに基本ネットワークからアクセスできるか確認してください。それも失敗する場合は、Wi-Fi、ゲートウェイ、ネットワーク認証を先に確認します。基本ネットワークが正常なら、設定を有効にし、選択可能なプロキシを2つ試して、ドメインの名前解決、ハンドシェイク、接続タイムアウトに関するログを確認します。一つのプロキシだけ失敗する場合は、リモートサービスの状態を重点的に確認します。すべて失敗する場合は、サブスクリプションの有効性、システム時刻、ネットワークの外向き通信制限、他のVPNとの競合を確認してください。速度テストのタイムアウトだけで設定が壊れたと判断しないでください。テスト用アドレス自体に接続できない場合も、テストは失敗します。

まず、ドメインを名前解決できないのか、名前解決後の接続に失敗しているのかを切り分け、最終的に有効なDNS設定を確認してください。Fake-IPがマッピング用アドレスを返すのは仕様です。名前解決結果がグローバルIPアドレスではないという理由だけで、障害と判断することはできません。DNSリクエストが想定した名前解決経路に入っているか、ダイレクト接続とプロキシ経由それぞれの名前解決経路が使えるか、ブラウザーのセキュアDNSがクライアントの設定を迂回していないかを確認します。変更後はテスト接続をいったん切断して再接続し、必要であればOSとブラウザーのキャッシュを削除してください。互換性のないLAN内サービスには、必要に応じてFake-IPのフィルタールールを設定します。DNSとTUNのパラメーターを一度にすべて変更しないでください。