Clashのトラブルシューティング

クライアントはサブスクリプション一覧やプロキシグループの選択、システムプロキシの切り替えなど、画面上の操作を担います。カーネルは設定の読み込み、接続処理、ルール判定、DNSの制御を行います。mihomoはClashエコシステムで使われるカーネルの一つですが、Clashを冠するすべてのクライアントが同じカーネルを使うわけではありません。設定の互換性を調べる際は、画面の製品名だけで対応状況を判断せず、クライアント名とカーネルのバージョンを記録してください。

信頼できる提供元のサブスクリプションURL、または利用可能なプロキシノードを含むローカルのYAML設定を用意します。クライアントは通信を管理するツールであり、インストールしただけでは接続先は使えるようになりません。設定を読み込んだら、選択状態とプロキシグループ内のノードを確認し、システムプロキシを有効にするか、必要に応じてTUNを使います。サブスクリプションURLにはアカウントの認証情報が含まれることがあるため、公開フォーラムに貼ったり、出所不明のオンライン変換サービスに渡したりしないでください。

出所が不明な無料ノードを、アカウントへのログインや機密性の高い用途に長期間使うことはおすすめしません。公開ノードは、運営者や保守状況、通信量の制限、ログの取り扱いを確認しにくく、今つながっていても安定して使えるとは限りません。クライアントが無料で使えることと、プロキシサービスが有料かどうかは別の話です。公開ノードにつながらない場合は、提供元とサービス状況を確認してください。接続を復旧するためにブラウザーの証明書検証を無効にするのは避けましょう。

通常はRuleを選ぶと、カーネルに届いた接続がルールに従って経路を選びます。ルールの影響を切り分ける場合は、一時的にGlobalへ切り替え、利用可能と分かっているノードを選びます。Directでは、カーネルに届いた接続が宛先へ直接アクセスします。モードが適用されるのはカーネルを経由する通信だけで、すべてのアプリが自動的に対象になるわけではありません。Globalでは接続できてRuleではできない場合、ルールの順序、該当したプロキシグループと選択中のノードを確認し、テスト後はRuleに戻してください。

通常、最初から両方を有効にする必要はありません。ブラウザーなどシステムプロキシに対応したアプリなら、まずはシステムプロキシだけを有効にします。ゲームや一部のコマンドラインツールなど、システムプロキシを使わないアプリにはTUNを検討してください。両方を有効にしても必ず競合するわけではありませんが、問題の切り分けが複雑になります。初回設定では一度に一つの方式だけを使い、接続ログに対象アプリが表示されることを確認してから、必要に応じて併用しましょう。

まず、サービスのログインページやアカウント管理ページではなく、サブスクリプションURLをコピーしたか確認します。次に、読み込み時のメッセージを見て、ダウンロード失敗と形式の解析失敗を区別してください。URLからWebページや認証画面が返された場合、または対応していないノード一覧の場合、クライアントが設定を生成できないことがあります。サービス提供元が案内するClash形式またはmihomo形式のURLを使いましょう。読み込みに成功してもノードが表示されない場合は、設定の手動選択が必要か、契約に利用可能なノードが含まれているかを確認してください。

まず、サービスのアカウントページで契約の有効期限、通信量の残量、URLがリセットされていないかを確認します。401や403の場合は認証やアクセス制限、404の場合はURLの誤りや欠落を確認してください。タイムアウトする場合は、サブスクリプションを取得する際のネットワーク経路を調べます。現在のプロキシ経由で更新できるクライアントもありますが、利用可能なノードが残っていることが前提です。短時間に何度も更新せず、エラー内容を記録し、必要な設定を直してから手動で一度更新してください。

Windowsでは、サービスモードをインストールして有効にするか、クライアントの案内に従って管理者権限を許可します。macOSではヘルパーサービスやネットワーク拡張の許可が必要な場合があります。Linuxでは適切なネットワーク管理権限を確認してください。スイッチを何度も押すのではなく、クライアントのサービスインストール画面とカーネルの起動ログを確認しましょう。AndroidではローカルVPNの許可も必要です。同じユーザー環境でVPNインターフェースを使うアプリを二つ同時に動かせない場合があります。

7890はmixed-portとして使われることが多く、アプリ向けにHTTPとSOCKSのプロキシ接続を提供します。9090はexternal-controllerとして使われることが多く、クライアントやパネルからカーネルを制御するためのポートです。いずれもよくある設定例で、すべての設定で固定されているわけではありません。ブラウザーやコマンドラインツールにプロキシを設定する際は、現在有効な設定のプロキシポートを確認し、制御用ポートを指定しないでください。ローカルだけで使う場合は、待ち受けアドレスをループバックアドレスに限定し、管理インターフェースをほかの端末に公開しないようにします。

まずログに記載されたフィールド名、行番号、エラーの種類を確認し、該当箇所のインデント、コロン、リストの階層、プロキシグループの参照先を調べます。YAMLのインデントにはスペースを使い、タブを混在させないでください。プロキシグループが参照するノードや別のグループが実際に存在することも確認します。カーネルによって対応フィールドが異なるため、インデントだけ直して互換性の問題を見落とさないようにしましょう。最後に使えた設定へ戻し、変更を一つずつ加えて、保存のたびにカーネルが起動することを確認してください。一度に複数の項目を変更するのは避けます。

まずはサービス提供元が推奨する間隔に設定します。案内がない場合は、数時間から1日おきの更新を目安にし、ノードの変更頻度に合わせて調整してください。クライアント全体のサブスクリプション更新と、proxy-providersのintervalは対象が異なります。画面上の時間単位もクライアントによって違う場合があります。設定後はスイッチがオンかだけでなく、最終更新時刻が変わったかを確認しましょう。モバイル端末はバックグラウンド動作が制限され、更新が遅れることがあります。重要な接続の前には手動で更新してください。

Ruleモードのまま接続一覧を開き、対象のドメインまたはIPアドレスを探して、適用されたルール、プロキシグループ、最終的な接続先を確認します。ルールは通常上から順に評価されるため、前方の広範なルールが後方の詳細なルールより先に一致することがあります。MATCHは通常末尾に置きます。IPだけが表示されてドメインが見つからない場合は、DNSの制御やドメインの識別状況も確認してください。ルールを変更した後は既存の接続を閉じて再接続します。確立済みの長時間接続は、ルール変更だけでは接続先がすぐに切り替わらないことがあります。

まず元の設定をバックアップし、クライアントが正式に対応している上書き、設定のマージ、拡張スクリプトの機能を使ってください。ダウンロードしたサブスクリプションファイルを直接編集すると、次回の更新で変更が上書きされることがあります。リストへの追加、フィールド全体の置換、スクリプト対応の有無はクライアントによって異なるため、別のソフトの手順をそのまま使わないでください。保存後は最終的に有効な設定を確認し、カスタムルールの順序とプロキシグループ名を確かめます。サブスクリプションを手動で更新し、変更が保持されるか検証してください。

まず、対象のアプリがシステムプロキシを参照するか確認します。コマンドラインツールでは、個別のプロキシオプションや環境変数の設定が必要な場合があります。HTTPプロキシ対応ツールなら、たとえば http://127.0.0.1:7890 を指定します。ポートは実際の設定を確認してください。HTTPとSOCKSの指定方法は互換ではありません。また、ドメイン名をローカルで解決するか、プロキシ側で解決するかを選ぶツールもあります。アプリにプロキシ設定がない場合はTUNを検討し、接続ログで経路を確認してください。ブラウザーで接続できるだけで、すべてのアプリがプロキシ経由だと判断しないようにしましょう。

まずクライアントの接続一覧にテスト通信が表示されることを確認し、適用されたプロキシグループと最終的なノードを調べます。次に、信頼できる接続元IPアドレスの確認ページを使い、必要に応じて有効にする前後の結果を比べてください。接続元IPが変わらなくても、対象がルールにより直接接続されている可能性があります。反対にIPが変わっても、すべてのアプリが対象になったとは限りません。プロキシが必要なアプリごとに検証し、ログと照合できるようテスト時刻とドメイン名を記録しましょう。

必ずしもそうではありません。まず、端末から通常のネットワークに直接接続できるか確認し、サブスクリプションの有効性、システム時刻、ノードのドメイン名を解決できるかを調べます。遅延テストは指定されたテスト先にアクセスするため、そのテスト先が使えないだけでも全ノードがタイムアウトする場合があります。クライアントが対応する別の信頼できるテスト先でも確認してください。一部のノードだけ使える場合は、プロトコルとサービス状況を比較します。すべて使えない場合は接続エラーログを確認し、テストのタイムアウトをすぐにインストールの問題と決めつけないでください。

まずカーネルが起動していること、プロキシポートが待ち受けていることを確認し、システムプロキシのアドレスとポートを照合します。次に、ブラウザーの拡張機能、個別のプロキシ設定、企業ポリシー、ほかのプロキシソフトがシステム設定を上書きしていないか確認してください。対象によってはシステムプロキシの除外リストに含まれ、カーネルに届かないことがあります。ほかの通信制御ツールを一時的に無効にし、ブラウザーを再起動して試します。それでもログが空なら、まずアプリからローカルのプロキシ入口までを調べ、リモートのノードを急いで変更しないでください。

一部のUWPアプリはAppContainerのループバック制限により、ローカルのループバックアドレス上にあるプロキシへ直接接続できません。まず通常のブラウザーが同じポートで使えることを確認し、クライアントにループバック制限を解除するツールがあれば、必要なアプリだけを許可してください。案内に従って管理者権限も取得します。ストアからインストールしたアプリすべてに同じ制限があるとは限らず、企業ポリシーで変更を制限される場合もあります。ループバック解除ツールがなければTUNを検討し、接続ログで実際の経路を確認してください。

まずTUNを無効にして比較し、問題が通信の取り込みに関係しているか確認してから、ルーティング、DNS、接続ログを調べます。LAN機器に接続できない場合は、プライベートネットワーク向けの直接接続ルールとルート除外設定を確認してください。ドメインへのアクセスに問題がある場合は、Fake-IPのマッピング、DNSリゾルバーへの到達性、アプリ独自の暗号化DNSを調べます。互換性のないドメインには必要なものだけfake-ip-filterを設定し、すべてのドメインを除外しないでください。変更は一つずつ行い、接続し直して結果を比較します。

まずシステムプロキシが終了済みのローカルポートを参照したままになっていないか確認し、残っているプロキシ設定を解除します。次にTUNの仮想インターフェース、ルート、DNSが元に戻っているか確認してください。クライアントを再度開き、システムプロキシとTUNを無効にして正常終了してから、現在のネットワークに接続し直す方法もあります。改善しない場合は、ほかのVPN、ブラウザー拡張機能、手動のDNS設定を確認します。ネットワークのリセットは既存の設定に影響するため、カスタム設定を記録してから行い、ネットワークアダプターの一括削除を最初の手段にしないでください。