Clashのよくある質問

コアは接続の確立、ドメイン名の解決、ルールに基づく振り分けを担当します。GUIクライアントは設定のインポート、システムプロキシの切り替え、サービス管理、ログ表示を担い、サブスクはリモートからノードや設定データを提供します。mihomoはコアであり、対応クライアントによって画面やオーバーライドの仕組みは異なります。クライアントをインストールしても、利用可能なノードが自動で手に入るわけではありません。問題を切り分ける際は、クライアント名、コアの情報、設定の入手元をそれぞれ記録し、画面や機能の違いをプロトコルの不具合と取り違えないようにしましょう。

Clash之家は、クライアントや設定に関する情報を掲載するサイトであり、オリジナルのClashや各GUIクライアントの開発チームではありません。Clashのエコシステムには複数の独立したプロジェクトがあり、名前が似ているだけで同じ開発者が運営しているとは限りません。ダウンロード時は、クライアント名、対象OS、プロセッサのアーキテクチャを確認してください。プロジェクトの仕様を確認する際は、各プロジェクトの説明、リリース履歴、ライセンスを参照しましょう。当サイトのガイドは一般的な操作を解説するもので、サブスク提供元のアカウントサポートやソフトウェア開発者への問い合わせに代わるものではありません。

普段はルールモードから使い始めるのがおすすめです。接続はルールの順に照合され、指定されたポリシーで処理されます。グローバルモードでは、コアに入った接続をグローバルポリシーに渡すため、問題が振り分けルールにあるか一時的に切り分けるのに役立ちます。ただし、すべての端末の通信が対象になるわけではありません。DIRECTモードでは通常、コアに入った接続が宛先へ直接アクセスしますが、コアによる名前解決や待ち受け処理は引き続き行われる場合があります。テスト後は元のモードに戻し、スイッチの状態だけでなく、接続画面で実際に適用されたルールと出口を確認しましょう。

この2つは別のものです。クライアントのソフトウェアライセンスとノードサービスの利用方法は独立しており、ソフトウェアが無料でも、リモートサーバーまで無料で提供されるとは限りません。公開ノードは稼働状況や運営者、ログの取り扱いを確認しにくいため、機密情報の送信には適しません。見知らぬ設定をインポートする前に、リモートルール、DNS、スクリプトやオーバーライドの内容、ローカルの制御インターフェースが公開されていないかも確認してください。サブスクURLが漏えいした場合は提供元に再発行を依頼しましょう。クライアントから削除しただけで、漏えいしたURLを使い続けてはいけません。

まずOSに合う候補を選び、設定の互換性、コアの対応状況、サービスのインストール方法、ローカルオーバーライド機能を確認します。WindowsではClash Plusを確認したうえで、Clash Verge Rev、FlClash、Clash Nyanpasuと比較できます。Clash for Windowsは開発が終了しているため、新規設定の標準候補ではなく、既存環境からの移行対象として扱うのがよいでしょう。移行前にサブスクの入手元、ルール、ポリシーグループの選択内容をバックアップし、旧プログラムのフォルダーに上書きしないでください。新旧クライアントは個別にテストし、システムプロキシの同時変更や待ち受けポートの競合を避けましょう。

設定画面でサブスクURLを追加し、更新に成功したら、その設定を選択して現在の実行設定にします。次にプロキシ画面で、実際に使うポリシーグループのノードを選び、システムプロキシを有効にします。必要に応じてTUNも有効にしてください。最後に接続画面とログ画面を開き、テスト先へアクセスして、接続がコアに入り、想定したポリシーに一致することを確認します。設定一覧に項目が表示されても、データが保存されたことを示すだけで、設定が有効とは限りません。ノードの速度測定が成功しても、ブラウザーの通信がクライアント経由になっているとは限りません。

まず更新エラーを確認します。認証失敗やアクセス拒否の場合は、サブスクの期限切れや再発行の有無、URLを最後までコピーできているかを確認してください。Webページや空の内容が返る場合は、アカウント管理ページではなくサブスクURLをコピーしたか確認します。タイムアウトなら、まずローカルネットワークを確認し、更新リクエストがすでに使えないプロキシに依存していないかも調べましょう。サブスクURL全体を公開変換サービスや公開フォーラムに貼り付けてはいけません。以前の設定がまだ使えるなら、削除せずに残したうえで、提供元に形式とアカウントの状態を確認すると、利用可能な設定を失わずに済みます。

ログに表示された行番号とその前後を確認し、インデントにタブが混在していないか、リスト項目の前にハイフンがあるか、コロンの後にスペースがあるかを調べます。次に、ファイルがClashまたはmihomoで読み込めるYAMLであり、WebページやBase64形式のノード一覧、別のコア向けJSONではないことを確認してください。構文の解析に成功したら、ポリシーグループが参照するノード名や、ルールが参照するポリシー名が存在するか確認します。修正前に元ファイルを保存し、一度に一か所だけ直して再読み込みすると、構文エラーとフィールドの互換性問題を区別しやすくなります。

TUNは仮想ネットワークインターフェースの作成とルートの変更が必要なため、通常のシステムプロキシより高い権限を必要とします。まずクライアントの説明に従ってサービスや補助コンポーネントをインストールし、サービスが起動していることを確認してください。デスクトップOSでは管理者権限が必要な場合があり、AndroidではシステムのVPN接続リクエストを許可する必要があります。許可後も失敗する場合は、ほかのVPN、仮想NICツール、セキュリティソフトによるブロックがないか確認します。ドライバーの再インストールを何度も繰り返すのは避けてください。競合するアプリを終了し、関連サービスを再起動してから、ログで権限、インターフェース作成、ルート書き込みのどこで失敗しているか確認しましょう。

まず、システムのVPN権限が有効か確認し、次にクライアントのアプリ別振り分け設定を確認します。許可リストでは選択したアプリだけが接続対象になり、除外リストでは指定したアプリがプロキシを迂回します。また、そのアプリがアクセスするドメインをルールでDIRECTにしていないか確認してください。Androidでは通常、同時に維持できる一般的なVPNサービスは1つだけです。別のVPNやローカルフィルタリングツールが、現在の接続を置き換えることもあります。画面ロック後に切断される場合は、バッテリー最適化、バックグラウンド実行、自動起動の権限を確認します。設定を変えるたびに接続し直し、ログでリクエストがコアに入っているか確認しましょう。

クライアントの接続画面を開き、新しいアクセスを発生させて、その接続のドメイン、適用ルール、プロキシチェーンを確認します。ルールは通常、上から順に評価されるため、先にある広い条件のルールが、後の詳細なルールより先に適用されることがあります。MATCHは最後に置くフォールバックルールです。ルールやポリシーを変更しても、既存の長時間接続は元の出口を使い続ける場合があります。関連する接続を閉じるか、対象アプリを再起動してからテストしてください。接続画面に宛先IPしか表示されない場合は、ドメイン名の解決とスニッフィングの条件も確認します。Webサイトに表示された出口IPだけで、特定のルールが適用されたと判断しないでください。

クライアントに独立したオーバーライド、設定のマージ、拡張設定機能がある場合は、そちらを優先してください。サブスク更新で置き換えられるキャッシュファイルを直接編集しないでください。まずマージの順序と、リスト形式のフィールドが追加、先頭挿入、全置換のどれになるかを確認します。動作はクライアントごとに異なるため、すべてのソフトウェアで同じとは限りません。保存後は最終的な実行設定を開き、カスタムルールの位置、ポリシーグループの参照、DNSフィールドが維持されているか確認しましょう。クライアントを乗り換える場合は、オーバーライドの仕組みを改めて検証してください。以前のクライアントのスクリプトや拡張ファイルを、そのまま移行できるとは限りません。

共用できるかどうかは、サブスク提供元の端末数、同時接続数、利用規約によって決まり、クライアント側で制限を変えることはできません。同じURLを使っていても、プラットフォームによって対応プロトコル、TUNのパラメーター、オーバーライドの方法が異なる場合があります。ノードの提供元は共用し、OS固有の項目は各端末のローカルオーバーライドに保存するのが無難です。同期するのは必要な設定だけにし、アクセス情報を含むサブスクURLを公開リポジトリに置かないでください。一方の端末だけ使えない場合は、端末数の制限を疑う前に、コアの対応状況と最終設定を比較しましょう。

まずホストと接続先の端末が相互通信できるLANに接続されていることを確認します。ホストのクライアントでLAN接続を許可し、待ち受けアドレスと実際のHTTPまたは混合プロキシのポートを確認してください。ほかの端末にはホストのLAN内IPアドレスを入力します。127.0.0.1は各端末自身を指すため使えません。ホストのファイアウォールでは、必要に応じて信頼できるLANからのアクセスのみを許可し、必要ならプロキシ認証を有効にします。プロキシのポートや制御インターフェースをインターネットに公開してはいけません。ホストがスリープ状態になる、IPアドレスが変わる、またはクライアントを終了すると、ほかの端末からもプロキシに接続できなくなります。

まず、どのドメインをどのリゾルバーで解決し、どの接続をプロキシ経由にするのかを明確にします。テストサイトに表示されるリゾルバーは、再帰問い合わせを行うサービスの出口である可能性があります。所在地だけで漏れと判断しないでください。クライアントのDNSログ、システムの名前解決設定、ブラウザーのセキュアDNS、TUNによるDNSの引き受け設定を順番に確認します。ブラウザー内蔵の暗号化DNSは、想定したコアのDNS経路を迂回する場合があります。一方で、プロキシ経由で接続されていることもあるため、それぞれ確認が必要です。一度に変更する設定は1つにし、名前解決リクエストと宛先への接続経路を同時に確認しましょう。

まずプロキシを一時停止し、ローカルネットワーク、システム時刻、基本的なドメイン名解決が正常か確認します。クライアントを再開したら、設定が正しく読み込まれているか確認してください。次にノードのアドレス、ポート、認証情報、プロトコルの対応状況を確認し、利用可能と分かっている別のノードとテスト先で比較します。速度測定のタイムアウトは、測定先に到達できない場合や、タイムアウト値が短すぎる場合にも発生します。必ずしもノードが完全に停止しているとは限りません。すべてのノードで失敗する場合は、まず端末上のサービスとネットワークを確認してください。1つのノードだけ失敗する場合は、提供元に問い合わせましょう。エラーの種類と発生時刻を記録しておくと、何度も測定をやり直すより原因を特定しやすくなります。

まずコアが実行中か、システムプロキシに設定されたアドレスとポートがクライアントの待ち受け設定と一致しているか確認してください。次に対象アプリがシステムプロキシに従っているか確認します。ブラウザー拡張機能がプロキシ設定を上書きする場合があり、ターミナルツールではプロキシの引数や環境変数を個別に設定する必要があります。アクセス時に接続画面へ新しい記録がまったく追加されない場合、通信がコアに入る前に問題が起きている可能性があります。記録があるのに出口が想定と異なる場合は、ルールとポリシーグループを確認しましょう。調査中はシステムプロキシを管理するプログラムを1つに絞り、ほかのクライアント、拡張機能、VPNがバックグラウンドで設定を書き換えないようにしてください。

一部のWindowsパッケージアプリはネットワーク分離の制限により、ループバックアドレス上のプロキシに直接接続できない一方、通常のデスクトップブラウザーは使えることがあります。まず対象アプリが実際にこの制限を受けているか確認します。次にクライアントのUWPループバックツールを使い、必要なアプリだけに例外を追加してから、アプリを再起動してテストしてください。すべてのアプリに対して無条件に許可を追加しないでください。Windows標準のCheckNetIsolationでも例外を確認・管理できますが、操作前にアプリの正確なパッケージIDを確認する必要があります。ループバックの例外が解決するのはローカル接続の制限だけで、ノード、DNS、リモートサービスの障害は修復できません。

ポートが使用中の場合は、ほかのプロキシクライアントや残存するコアプロセスを終了し、対象ポートを使用しているプロセスを確認します。正体の分からないシステムプロセスを強制終了しないでください。現在のクライアントで空きポートに変更する方法もありますが、システムプロキシや手動設定したアプリのポートも合わせて更新する必要があります。クライアント終了後にネットにつながらない場合は、システムのネットワーク設定にローカルポートを指す手動プロキシが残っていないか確認してください。TUNを有効にしていた場合は、関連サービスとルートが正常に復元されているかも調べましょう。ネットワークが復旧したら、クライアントを1つだけ起動し、複数のインスタンスによる再発を防いでください。

OS、プロセッサのアーキテクチャ、クライアント名、コアの情報、現在のモード、再現手順、不具合の前後の短いログを伝えると役立ちます。すべての接続に影響するのか、特定のアプリだけなのか、TUNや特定のネットワーク、ルールでのみ発生するのかも説明してください。送信前にサブスクURL全体、認証パスワード、アクセストークン、ノードのアカウント情報、不要な個人用ドメイン名を削除します。スクリーンショットではアドレスバーや設定サイドバーも確認してください。機密情報を除いた最小限の設定を用意し、設定フォルダー全体はアップロードしないでください。ログに個人を特定できる情報が残っている場合は、公開前にさらに削除しましょう。