Clashのよくある質問
設定と接続のトラブルシューティング

クライアントはサブスクリプション管理や画面操作、システム連携を担い、コアはプロトコル接続、DNS処理、ルール判定を担います。Clash.MetaはClashのエコシステムで発展したコアの派生版で、現在はmihomoの名称で開発が続いています。元のClashとmihomoを同じ機能セットと考えることはできません。プロトコルが使えるかどうかは、アプリ名だけでなく、クライアントが実際に使用するコアと対応プロトコル一覧を確認してください。同じYAMLでもコアによって結果が異なる場合があります。移行前に設定をバックアップし、ログに未知の項目や非対応プロトコルの警告がないか確認しましょう。

新規導入では、Clash Plus、Clash Verge Rev、FlClash、Clash NyanpasuのOS対応状況、コアの更新方法、サービスモードを比較し、使い方に合うものを選びましょう。Clash for Windowsは開発が終了しており、旧バージョンが起動しても新しいプロトコルに対応しているとは限らず、今後のOS変更にも対応できるとは限りません。移行時はサブスクリプションURLと手動追加したルールを書き出し、新しいクライアントに再度読み込みます。ポート、TUN、自動起動の設定も確認し、プログラムのフォルダー全体をそのまま上書きするのは避けてください。新しいクライアントで接続できることを確認してから、古いクライアントの自動起動とバックグラウンドサービスを停止し、プロキシの二重使用を防ぎましょう。

ルールモードは、設定したルールの上から順に判定して接続先を決めるため、普段使いに適しています。グローバルモードは、コアに届いた接続をグローバルポリシーに従って処理するため、問題がルール設定に起因するか一時的に確認するときに便利です。DIRECTモードは、コアに届いた接続をそのまま直接接続する比較テストに使えます。グローバルモードでも端末の全通信が必ず経由するわけではなく、システムプロキシやTUNを通らないアプリはコアを迂回する場合があります。トラブル時はルールモードとグローバルモードの結果を比べ、接続ログで適用されたルールを確認してください。ルールモードに戻した後も、対象のプロキシグループで利用可能なノードが選択されているか確認しましょう。

システムプロキシはOSにローカルプロキシのアドレスを登録し、通常はその設定に従うブラウザーやアプリが利用します。TUNは仮想ネットワークインターフェースとルーティングを使って対象の通信を取り込み、システムプロキシを参照しない一部のアプリにも対応できます。必ず両方を有効にする必要はなく、適切な組み合わせはクライアントの実装やアプリの要件によって異なります。初回設定では、まずシステムプロキシでサブスクリプションとノードを確認し、必要に応じてTUNを有効にしてください。切り替え後に二重で通信を取り込んだり接続に問題が起きたりした場合は、入口を一つずつ有効にして比較し、ほかのVPN、仮想ネットワークインターフェース、セキュリティソフトが同じルートを変更していないか確認しましょう。

クライアントのサブスクリプションまたは設定画面でURLからの読み込みを選び、サービス提供元から案内されたURLをすべて貼り付けます。ダウンロード後、その設定を現在の設定として選択してください。サブスクリプション一覧に項目が表示されても、URLが保存されただけで、コアに読み込まれているとは限りません。プロキシグループにノードがあるか、コアのログに解析エラーがないかを確認し、ノードを選んで必要な通信入口を有効にします。ボタン名はクライアントによって異なるため、実際の画面に従ってください。サブスクリプションURLには認証情報が含まれることがあるため、公開スクリーンショットや掲示板、信頼できないオンライン変換サービスに載せないでください。

まず更新ログでHTTPステータスとエラーの種類を確認します。401や403は認証、URLの有効期限、サーバー側のアクセス制限が原因の可能性があります。404の場合はURLが変更されていないか確認し、タイムアウトの場合は端末からサブスクリプションサーバーに接続できるか調べます。クライアントによっては、更新時の接続方法をDIRECTまたはプロキシから選べます。利用可能な接続がある場合は、両方を比較してみましょう。ダウンロードできても解析に失敗する場合は、ログイン画面やエラーメッセージが返された、または形式が非対応の可能性があります。Clashまたはmihomo向けのサブスクリプションか、提供元に確認してください。利用できる設定はバックアップし、更新失敗後すぐに元の設定を削除したり、短時間に何度も更新したりしないでください。

まず、使用中のクライアントとOSが、そのクライアントのTUN実装に対応しているか確認します。そのうえで、クライアントの手順に従ってサービスコンポーネントをインストールするか、必要な権限を付与してください。Windowsではクライアントのサービスモードを有効にする方法が一般的です。macOSでは管理者の許可やネットワークコンポーネントの承認が必要な場合があります。Androidでは初回起動時にVPN接続の要求を承認します。Linuxではサービスの権限や仮想ネットワークインターフェースが利用可能かどうかによって異なります。許可したらコアを再起動してログを確認し、スイッチを何度も押すだけの対応は避けましょう。ほかのVPNが動作中なら、競合する接続を先に停止します。管理対象の端末では、管理者が定めた権限ポリシーに従ってください。

自動起動、コアの起動、システムプロキシの有効化は別々の設定です。アプリが起動しても、プロキシの通信入口が自動で有効になるとは限りません。まず、OSのスタートアップ管理でクライアントの自動起動が無効にされていないか確認し、現在の設定が残っているか、プロキシグループが利用可能なノードを指しているか調べます。サービスモードに依存するTUNでは、バックグラウンドサービスが正常に起動していることも確認してください。ログイン直後だけ問題が起きる場合は、ネットワークの準備が整っていないか、別のVPNが後からルートを書き換えている可能性があります。ネットワークが安定してから手動で再試行し、ログを比較しましょう。クライアントを移行した後は、旧プログラムの自動起動タスクを削除し、古いポートやプロキシ設定が再適用されないようにしてください。

selectはユーザーがメンバーを選びます。url-testは設定された確認先と測定結果に基づいてメンバーを選び、fallbackは通常、メンバーの順序に従って利用可能なものを選択します。自動選択の結果は、測定先、間隔、許容差、ノードの状態に左右され、すべての通信が速くなるわけではありません。グループ内から別のプロキシグループを参照している場合もあるため、最終的な接続先を調べる際は参照関係をたどってください。接続元を固定したいログインやセッションでは、ポリシー変更による出口の切り替わりを避けるため、手動選択が適しています。グループの種類やメンバーを変更する前に設定を保存し、サブスクリプションの更新でローカルの変更が上書きされないか確認しましょう。

遅延テストで測定するのは、通常、指定したアドレスへの一度のリクエストにかかる時間です。接続確立やTLSネゴシエーションを含むかどうかは実装によって異なり、帯域幅、継続的な転送速度、Webサイトの応答速度をそのまま示すものではありません。ノードから測定先までの経路と、実際に利用するサイトまでの経路も異なる場合があります。まずブラウザーの接続が実際にそのノードを通っていることを確認し、同じ測定先、同じネットワーク、近い時間帯で複数のノードを比較してください。ダウンロード速度は、サーバー側の速度制限、パケットロス、混雑、ローカルネットワークの影響も受けます。一度の測定だけでノードを除外したり、タイムアウトをノードの恒久的な停止と判断したりせず、接続ログと複数回の測定結果を確認しましょう。

ルールは通常、上から順に判定されます。先にある広範なルールが適用されると、後にある具体的なルールはその接続の判定に使われません。まず接続ログでドメイン、宛先IP、適用されたルール、最終的なポリシーを確認してください。アプリがIPアドレスへ直接接続したり、既存の接続を再利用したりする場合もあります。no-resolveは、GEOIP,CN,DIRECT,no-resolveのような、対応するIP系ルールで使えます。ルール適用のためだけにドメインを積極的に名前解決しないようにする指定であり、DNS全体を無効にするものではありません。具体的なドメインルールは広範なルールより前に置き、MATCHによるフォールバックは最後に配置します。変更後は接続を張り直して結果を確認してください。

AppContainerで動作する一部のWindowsアプリは、既定でローカルのループバックアドレスへのアクセスが制限されており、127.0.0.1で待ち受けるプロキシポートに接続できないことがあります。ただし、すべてのストアアプリがこの制限を受けるわけではありません。まずアプリがシステムプロキシに従うか、コアの接続ログにアプリの通信が記録されるか確認してください。ループバック制限が原因と確認できた場合は、クライアントのループバック除外機能を使い、必要なアプリにだけ権限を付与します。案内に従って管理者権限で操作してください。すべてのアプリに一括で制限を解除するのは避けましょう。TUNに切り替えた場合は、そのアプリの通信がルーティング対象になっているか改めて確認してください。ループバック除外は、あらゆる接続問題を解決する方法ではありません。

まずコアが動作中であることを確認し、システムプロキシのアドレスとポートがクライアントの待ち受け設定と一致しているか比べます。ほかのプロキシツール、ブラウザー拡張機能、企業ネットワークのポリシーがシステム設定を上書きする場合があり、ブラウザー独自のプロキシ設定が使われていることもあります。対象ページを開き、クライアントの接続ログを確認してください。ログがまったくない場合は、通信の入口、プロキシのバイパスリスト、ポートの競合を優先して調べます。ログがあり接続先がDIRECTの場合は、システムプロキシのスイッチを何度も切り替えるのではなく、出力モードと適用ルールを確認しましょう。古い接続を切るためブラウザーを再起動し、競合する設定を一つずつ無効にしてください。システムプロキシを取り込むクライアントを複数同時に起動しないでください。

すべてのノードがタイムアウトする場合は、まず端末自体がインターネットに接続できるか、システム時刻が正しいか、サブスクリプションの認証が有効かを確認します。次に、ファイアウォールがクライアントを遮断していないか、測定先に接続できるか調べてください。1つのノードだけ失敗する場合はほかのノードと比較し、そのノードのサーバー状態、アドレス、ポート、プロトコルの対応状況を重点的に確認します。QUICを使うプロトコルでは、現在のネットワークで必要なUDP通信が許可されているかも確認してください。測定先の障害でも複数のノードが失敗することがあるため、実際のアクセス結果とログの接続段階を照らし合わせましょう。最初からクライアントを再インストールせず、名前解決の失敗、接続拒否、接続待ちのタイムアウトを区別して原因を絞ります。

まずログで名前解決の失敗、上流DNSのタイムアウト、接続先の異常を確認します。次に、そのリクエストがコアに届いているか、DNSクエリをシステムとクライアントのどちらが処理しているか調べてください。ノードを変えるだけで復旧するなら、ノードから接続先までの経路が関係している可能性があります。複数のノードに切り替えても名前解決の段階で失敗する場合は、上流DNSのアドレス、アクセス経路、設定の互換性を確認しましょう。fake-ipを使用する場合、一部のLAN内サービスやアプリでは、ドキュメントに従って除外ルールを設定する必要があります。DNSのリダイレクト設定をむやみに重ねたり、ドメインの代わりにIPアドレスへ長期間直接アクセスしたりしないでください。HTTPS証明書や仮想ホストに起因する別のエラーが発生する場合があります。

まず、システムがクライアントのローカルプロキシポートを参照したままになっていないか確認します。プログラムが異常終了すると待ち受けは停止しても、システムプロキシの設定が残る場合があります。クライアントを再度開き、システムプロキシとTUNを無効にしてから通常の手順で終了するか、OSのネットワーク設定で不要になった手動プロキシを無効にしてください。それでも改善しない場合は、バックグラウンドサービス、VPN接続、DNSがほかのツールに制御されていないか確認します。手動DNSを使っている端末では、記録しておいた元の設定に戻してください。正体のわからない仮想ネットワークインターフェースやルートを、いきなり削除しないでください。ネットワークに再接続して一般的なWebサイトを確認し、通常の方法で復旧できない場合に限り、OSのドキュメントに従ってネットワークのリセットを検討しましょう。