Clashのよくある質問

まず、コアとインターフェースを区別しましょう。コアは設定の読み込み、ルールの照合、接続の転送を担います。GUIクライアントはサブスクリプションの管理やモード切り替え、システム設定を行います。mihomoはClash Metaから名称変更されたコアプロジェクトであり、特定のデスクトップアプリを指すものではありません。トラブル対処の際は、クライアント名とコアのバージョンを記録してください。画面が開いていても、クライアントが起動しただけで、コアが正常にポートを待ち受けているとは限りません。

まず、サービス提供元から有効なサブスクリプションを入手してください。サブスクリプションURLからサーバーアドレスや接続パラメーター、ポリシーグループを取得するのが一般的です。クライアント自体に利用可能なプロキシサービスは含まれていません。取り込む前に、有効期限やデータ通信量、対応形式を確認しましょう。URLに認証情報が含まれることがあるため、パスワードと同様に管理してください。問い合わせ時はURL全体やアカウント情報、サーバー認証情報を伏せ、公開コメント欄に貼り付けないでください。

通常はルールモードを使い、設定内のルールに従ってプロキシ経由か直接接続かを選択します。グローバルモードでは、グローバルポリシーで選んだ出口にトラフィックを送ります。短時間の比較テストには使えますが、コアに届いた通信だけが対象で、選んだ出口が必ずプロキシになるとは限りません。DIRECTモードでは、コアに届いたリクエストを宛先へ直接接続します。モードを切り替えても、システムプロキシは自動で有効になりません。テスト後は設定を元に戻し、一時的な設定を常用しないようにしましょう。

まずシステムプロキシを有効にし、ブラウザーが接続できることを確認します。システムプロキシはOSにプロキシアドレスを登録する仕組みで、各アプリが利用するかどうかはアプリの実装によります。TUNは仮想ネットワークインターフェースで、ルーティングと組み合わせることで、より多くのアプリの通信を取り込めます。ただし権限が必要で、ほかのVPNやルーティング、DNS設定と競合する場合があります。必要性が明確でなければ、まずTUNは無効のままにしてください。システムプロキシを使わないアプリの通信を取り込みたい場合に、個別にテストしましょう。

ローカルの入口とリモートの出口を分けて考えましょう。アプリが端末上の待ち受けポートに接続し、コアがルールに基づいて宛先へ直接接続するか、プロキシサーバーへ転送します。mixed-portはHTTPとSOCKSの両方のプロキシリクエストを受け付けるポートです。7890はよく使われる設定値ですが、利用中のクライアントの設定を確認してください。127.0.0.1はその端末自身を指します。スマートフォンに入力した場合、接続先はパソコンではなくスマートフォンです。

まずサブスクリプションの更新ログを開き、取得に成功したことを確認します。次に、その設定が選択され、有効になっているか確認してください。URLをコピーするときは前後の空白を取り除き、アカウント管理画面のURLを誤って使わないようにしましょう。取得成功と表示されてもノードがない場合は、ログインページが返された、形式に互換性がない、サービス提供元で内容が割り当てられていないなどの可能性があります。WebページのHTMLをYAML設定として取り込まないでください。サービス提供元にmihomo対応のサブスクリプション形式を確認し、復元に備えて元の設定を残しておきましょう。

まずサービスアカウントの期限切れやサブスクリプションのリセットを確認し、サービス提供元の管理画面からURLを再コピーしてください。401は通常、認証に関係します。403はアクセス制限のほか、Webサイトの保護機能によって返される場合もあり、ステータスコードだけで料金未払いとは判断できません。ブラウザーでは取得できるのにクライアントで失敗する場合は、更新時刻、リクエスト方式、サービス提供元が指定するクライアント識別情報を確認します。URL全体を何度も公開テストしたり、認証情報を見知らぬ変換サービスに送信したりしないでください。

まずクライアントの手順に従ってサービスコンポーネントをインストールするか、システムのネットワーク権限を許可してから、TUNを再度有効にします。Windowsではサービスがインストールされ、実行中か確認してください。macOSでは承認待ちのネットワーク拡張機能やVPN要求がないか確認します。AndroidではVPN接続を許可してください。次に、ほかのVPNが通信の取り込み経路を使用していないか確認します。システムの保護機能を無効にしたり、ネットワークアダプターを繰り返し削除したりせず、ログの具体的なエラーを確認して、権限、ドライバー、ルーティングの競合を切り分けましょう。

まず現在の設定をバックアップし、最後に正常に動作したバージョンへ戻します。YAMLはインデントで階層を表すため、スペースを使い、タブを混在させないでください。ログの行番号をもとに、コロンやリストのインデントも確認します。ログにaddress already in useと表示される場合は、別のプロキシプログラムが起動していないか調べ、競合するプロセスを停止するか、ローカルの待ち受けポートを変更します。ポートを変更したら、システムプロキシとアプリ内のプロキシアドレスも更新してください。

まず、編集したのがサブスクリプションの元ファイルか、クライアントのオーバーライド設定かを確認してください。サブスクリプションを更新すると設定が再ダウンロードされるため、ダウンロードしたファイルを直接編集すると上書きされることがあります。ポートやDNS、カスタムルールを維持したい場合は、クライアントが対応するオーバーライド、マージ、拡張設定機能を使い、ルールの挿入順も確認しましょう。マージ方法はクライアントごとに異なります。保存後はエディターの表示だけで判断せず、実際に適用された設定とコアのログを確認してください。

まずクライアントの接続一覧を開き、確認したいサイトにアクセスして、対象ドメイン、適用されたルール、最終的な出口を確認します。システムプロキシが有効でも、すべてのアプリがプロキシを使うとは限りません。接続一覧にリクエストが表示されても、必ずプロキシ経由とは限りません。curl -I -x http://127.0.0.1:7890 https://example.comでローカルのHTTP入口をテストできます。ポートは実際の設定に合わせて変更してください。結果が示すのは、そのリクエストの状態だけです。

まず単一のコマンドにプロキシを明示して、ローカルポートが使えることを確認してから、環境変数の設定を検討します。多くのコマンドラインツールはシステムプロキシを参照しません。curlでは-xでアドレスを指定でき、ほかのツールではそれぞれのプロキシオプションを確認してください。環境変数の書き方や読み込み方は、シェルやツールによって異なります。HTTP_PROXY、HTTPS_PROXY、ALL_PROXYがどの環境でも共通して使えるわけではありません。クライアントを終了したりポートを変更したりした後は、古い変数を削除し、ターミナルを開き直してください。

まずルールの順序を確認します。通常、ルールは上から順に照合され、先に一致すると後続のルールは評価されません。そのため、具体的なドメインのルールは、関連する広範なルールやMATCHのフォールバックより前に置きます。次に、ポリシーグループ名が存在するか、大文字と小文字が一致しているか、リクエストに照合可能なドメインが含まれているかを確認してください。接続一覧にIPアドレスしか表示されない場合は、DNSとドメイン識別も確認します。設定を保存して再読み込みし、新しい接続で検証しましょう。

まず、設定でGEOIPまたはGEOSITEルールが実際に使われていることを確認し、クライアントのデータ更新機能から更新します。GeoIPはIPアドレスの地理的な分類、GeoSiteはドメインのグループ分類に使われ、相互に置き換えることはできません。手動で設定する場合は、mihomoが対応するgeox-url、自動更新のオプション、現在のデータ形式に互換性があるか確認してください。ダウンロードに失敗した場合は具体的なログを確認します。更新後は関連データを再読み込みするかコアを再起動し、接続記録でルールが適用されたか確認しましょう。

まず信頼できるネットワークでLAN接続を許可し、バインドアドレス、ファイアウォール、プロキシ認証を確認します。ほかのデバイスにはパソコンのLAN内IPアドレスと実際の待ち受けポートを入力してください。127.0.0.1は指定できません。2台のデバイス間で通信できる必要があり、ゲストネットワークや無線クライアント分離によって接続が遮断されることもあります。待ち受けポートをインターネットに公開しないでください。共有を使い終えたら無効にしましょう。LAN内のデバイスがHTTPまたはSOCKSプロキシに対応しているかも、それぞれ確認が必要です。

まずコアが実行中で、ローカルポートとシステム設定が一致していることを確認します。次に、拡張機能、ブラウザー独自のプロキシ設定、組織のポリシーによって設定が上書きされていないか調べてください。プロキシ関連の拡張機能を一時的に無効にし、新しいブラウザーウィンドウでテストしながら、接続一覧にリクエストが表示されるか確認します。記録がない場合は、まず通信の入口を調べます。記録があるのにDIRECTになる場合は、モード、ルール、ポリシーグループを確認してください。最初からDNS、サブスクリプション、TUNを同時に変更すると、どの変更が効いたのか分からなくなります。

まずプロキシを無効にして、通常のWebサイトに接続できることを確認し、ログインが必要な公衆Wi-Fiを使っていないか調べます。次にサービスアカウントの状態、システム時刻、クライアントのログを確認し、別のネットワークでも比較してください。タイムアウトはテストが期限内に完了しなかったことを示すだけで、サブスクリプションの失効を証明するものではありません。テスト先に到達できない場合も結果に影響します。特定のノードだけ失敗するなら、そのサーバーを優先して確認します。すべてのノードが失敗する場合は、DNS、ネットワーク制限、ファイアウォールを調べてください。

まず、名前解決に失敗しているのが接続先サイトのドメインか、プロキシサーバーのドメインかを確認します。DNSはドメイン名をIPアドレスに変換します。プロキシサーバー自体の名前を解決できない場合、同種の別ノードに切り替えても解決しないことがあります。ログのタイムアウト、接続拒否、名前解決ループを確認し、上流のDNSサーバーに到達できるか調べてください。TUN利用時はDNSの取り込みが機能しているかも確認します。複数のアプリで同時にDNSの取り込みを有効にしないでください。変更前にバックアップを取り、一度に一項目だけ調整し、クライアントの手順でキャッシュを消去してから再テストしましょう。

まず、問題が発生しているのがアプリコンテナーの制限を受けるアプリであり、ストアからインストールしたすべてのアプリではないことを確認します。一部のUWPアプリにはループバック制限があり、ローカルのプロキシポートに接続できません。クライアントにループバック免除ツールがある場合は、必要なアプリだけに許可してください。Windows標準のCheckNetIsolation LoopbackExemptツールで確認し、正確なパッケージファミリー名を指定して免除する方法もあります。通常、管理者権限が必要です。操作後に対象アプリを再起動し、すべてのアプリをまとめて免除しないでください。

まず、接続設定の残留とネットワーク切り替えの問題を切り分けます。AndroidではVPNの状態、バックグラウンド実行の制限、VPNの常時接続設定を確認してください。iOSではシステムのVPN状態を確認し、接続を再確立します。Wi-Fiとモバイル通信を切り替えた後は、ネットワークが安定してから再接続してください。パソコンでクライアント終了後にネット接続できない場合は、システムプロキシが停止済みのローカルポートを参照したままになっていないか確認します。ネットワークが復旧してからクライアントを起動し、項目ごとにテストしてください。ネットワーク設定全体をすぐにリセットしないでください。