Clashのよくある質問
とヘルプセンター

クライアントは設定の読み込み、プロキシグループの選択、システムプロキシの切り替えなどを行う画面を提供します。コアは接続を受け付け、ドメインを解決し、ルールに照らして処理します。mihomoはClashエコシステムで開発が続くコアで、以前はClash Metaという名称でした。サブスクリプションは通常、サービス提供元が用意する設定取得用のURLで、ノードや設定一式を取得できます。クライアントをインストールしただけではノードを利用できず、互換性のある設定と有効なサービスが必要です。問題を調べる際は、クライアント名、コア名、サブスクリプションの種類をそれぞれ記録し、画面の機能とコアの機能を混同しないようにしましょう。

ルールモードは設定内のルールを上から順に適用し、接続先を振り分けます。日常的な使い分けに適しています。グローバルモードでは、通常、コアに入った接続がGLOBALポリシーに渡されますが、そのポリシーで利用可能なノードを選ぶ必要があります。ダイレクトモードでは、コアに入った接続を宛先へ直接接続します。モードが決めるのは、コアが受け取った接続の処理方法です。すべてのアプリの通信を自動的にコアへ取り込む機能ではありません。初めて使う場合はルールモードから始め、必要に応じて短時間だけグローバルモードに切り替えて比較します。テスト後は元のモードに戻し、実際に適用されたルールを確認しましょう。一時的な設定をそのまま使い続けないよう注意してください。

システムプロキシを使うのは、主にOSのプロキシ設定を参照するアプリです。ブラウザーは通常この設定を利用しますが、一部のゲームやコマンドラインツール、独自のネットワーク処理を行うアプリは無視することがあります。アプリ側で個別のプロキシや除外リストを設定している場合もあります。そのため、ブラウザーで接続できても、ほかのアプリがプロキシを経由しているとは限りません。まずクライアントの接続一覧を開き、対象アプリの通信が記録されているか確認しましょう。記録がなければ、通信が取り込まれているかを優先して調べます。アプリごとにローカルプロキシを設定する方法もあります。TUNモードを使う場合は、ルーティングと権限の要件を理解したうえで有効にしてください。

まずOSで候補を絞り、CPUアーキテクチャ、OSのバージョン、必要な機能を確認します。当サイトのダウンロードセンターでは、対応プラットフォーム向けにClash Plusを優先して掲載し、Clash Verge RevやFlClashなども案内しています。クライアントによって画面、設定の上書き方法、サービスのインストール手順、TUNの切り替え方は異なります。別のクライアントのメニュー手順をそのまま当てはめないでください。安定して使えている設定がある場合は、移行前に元のファイルを保管し、新しいクライアントが使用するコアも確認しましょう。画面の見た目だけで比べるより、現在のOSに対応し、保守が続いているバージョンを選ぶことが大切です。

遅延テストで確認できるのは、通常、ノードから指定されたテスト先への1回のリクエストです。すべてのWebサイト、プロトコル、アプリに接続できることを示すものではありません。ルールで誤ったプロキシグループが選ばれている、接続先の制限、DNSの名前解決エラー、アプリがプロキシを使っていないといった原因でもWebページは開けません。まず対象ページへの通信が接続一覧に表示されるか確認し、適用されたルールと実際のノードを調べましょう。別のWebサイトと同じグループの別ノードでも試し、どの範囲で失敗するか記録します。遅延の数値だけを根拠にDNSを何度も変更したり、テストが一度成功しただけで接続経路全体に問題がないと判断したりしないでください。

サービス提供元からClashまたはmihomo向けの設定URLを取得し、クライアントの設定画面またはサブスクリプション画面でURLからの読み込みを選びます。URL全体を貼り付けて保存してください。URLには個人用のアクセス情報が含まれることがあるため、公開グループへの投稿やスクリーンショットでの共有は避けましょう。読み込み後は設定を有効にし、プロキシグループが表示されることを確認してノードを選び、適切な通信の入口を有効にします。ノードだけが読み込まれてルールがない場合は、クライアントが対応する方法で設定を補います。メニュー名はクライアントによって異なるため、まず当サイトのガイドに沿って接続を一通り確認してください。

mixed-portは、HTTPとSOCKSの両方のプロキシ接続を受け付けるローカル待受ポートです。設定がmixed-port: 7890の場合、同じ端末上のアプリには通常、ホスト127.0.0.1、ポート7890を指定し、アプリに応じてプロキシプロトコルを選びます。実際の値は使用中のクライアント画面で確認してください。起動ログにアドレスが使用中と表示される場合は、別のプロキシソフトを終了するか、空いているポートに変更し、アプリ側の設定も合わせます。外部コントロール用ポートをプロキシポートとして指定しないでください。自分の端末だけで使う場合は、LANからのアクセスを無効にして、待受サービスを誤って公開しないようにしましょう。

まずログを確認し、権限不足、サービス未インストール、ドライバーの読み込み失敗のどれかを切り分けます。Windowsのクライアントでは通常、サービスコンポーネントのインストールまたは起動が必要です。管理者権限での実行に対応するクライアントもありますが、各クライアントの案内に従ってください。macOSでは補助サービスの許可が必要な場合があり、Linuxではネットワーク管理に必要な権限が求められます。サービスをインストールしたらクライアントを再起動し、仮想アダプターとルートが作成されたか確認します。それでも解決しない場合は、ほかのVPNやTUNソフトを一時的に終了して比較してください。複数の仮想アダプターを何度も作成したり、システム保護を恒常的に無効にしたりするのは避けましょう。

TUNはネットワーク通信を取り込み、DNS設定は名前解決とドメインの関連付けを担います。両方をあわせて確認してください。Fake-IPは一部のドメインに対応するマッピング用アドレスを返し、後続の接続でコアが本来の宛先に戻します。公開DNSサーバーのアドレスではありません。まずクライアントの標準TUN・DNS構成を使い、設定のdns.enable、dns.enhanced-modeと、TUNのDNS取り込み設定を確認しましょう。拡張モードの項目だけをコピーしないでください。LAN上の端末や特定のアプリで互換性の問題がある場合は、症状に応じてFake-IPの除外項目を追加します。変更後は関連アプリを再起動し、古い接続を解消してください。

クライアントの起動、コアサービスの起動、プロキシ設定の復元はそれぞれ別の項目です。いずれか一つを有効にしても、すべての手順が完了するとは限りません。デスクトップでは、スタートアップ設定、有効な設定ファイル、システムプロキシまたはTUNの復元動作を個別に確認し、再起動後に実際に接続できるか試してください。Androidではバックグラウンド動作、バッテリー最適化、VPN権限も確認します。iOSではシステム上のVPN状態を確認してください。モバイルOSで同時に有効にできるVPNは通常1つです。別のVPNやフィルタリングアプリが接続を置き換えることがあります。サブスクリプションの問題と決めつけず、まずOSの状態を確認してからノードを調べましょう。

クライアントのルール上書き、設定のマージ、拡張設定機能を使い、ローカルの変更とリモートのサブスクリプションを分けて保存するのがおすすめです。ルールは上から順に照合されるため、具体的なドメインルールは通常、広範なルールやMATCHより前に置きます。たとえばDOMAIN-SUFFIX,example.com,DIRECTは、そのドメインとサブドメインへの接続を直接接続にします。指定するポリシー名が設定内に存在し、表記と大文字・小文字が一致していることも確認してください。変更を再読み込みしたら、接続一覧で実際に適用されているか確認します。サブスクリプションから取得したファイルを直接編集すると更新時に置き換わることがあるため、先にコピーを保管し、クライアントのマージ順も確認しましょう。

selectはノードや子プロキシグループを手動で選択する方式で、出口を明確に固定したい場合に適しています。url-testは指定したテスト先への結果に基づいて自動選択します。テスト間隔や許容差などの設定で切り替わり方は変わりますが、ダウンロード速度のランキングではありません。fallbackは通常、リストの順に利用可能な候補を選びます。優先回線を維持し、失敗時に切り替えたい場合に適しています。グループ内の項目、テスト先、実際にアクセスするWebサイトのすべてが結果に影響します。特定のサイトで問題が起きたら、まずselectでノードを固定して比較し、自動選択の調整が必要か判断しましょう。複数のグループを同時に変更するのは避けてください。

クライアントの接続画面を開き、対象アプリから通信を発生させます。プロセス名、ドメイン、宛先アドレスで該当する接続を探し、ルールの種類、ポリシーの経路、最終的な出口を確認してください。既存の長時間接続は古いポリシーを使い続けることがあります。設定を切り替えた後は、その接続を閉じるかアプリを再起動してから試しましょう。記録がまったくない場合は、rulesを直接変更せず、まずアプリの通信がプロキシに取り込まれているか確認します。ログが少なすぎる場合は、一時的にログレベルを上げ、調査後に元へ戻してください。ログを共有する前にサブスクリプションURL、認証情報、個人のアクセス履歴を隠し、問題の特定に必要なエラー部分だけを残しましょう。

ほかの端末からこの端末のプロキシを使う必要がある場合に限り、allow-lanを有効にしてbind-address、プロキシポート、ファイアウォールの受信規則を確認してください。接続する端末には127.0.0.1ではなく、このPCのLAN内アドレスを指定します。PCのアドレスが変わった場合は、接続先の設定も更新してください。アクセス範囲をできるだけ限定し、クライアントが対応している認証を設定しましょう。ルーターでプロキシポートをポートフォワードし、インターネットに公開するのは避けてください。外部コントロール用インターフェースとプロキシの待受は別のサービスとして管理します。テスト後は不要になった共有設定を無効にし、知らない端末にネットワーク出口として利用されないようにしましょう。

プロキシのスイッチだけでは、DNSリクエストの送信先は判断できません。アプリがシステムのリゾルバー、内蔵の暗号化DNS、独自のネットワーク設定を使う場合があります。TUNやDNSの取り込みが機能しているかどうかも設定次第です。まず対象アプリのリクエストがコアに入っているか確認し、コアのDNSログ、上流のリゾルバー、そのルーティングポリシーを調べます。ブラウザーでセキュアDNSが有効なら、その設定も確認対象です。DNSテストサイトに表示される名前解決の出口は手がかりにすぎず、端末全体の通信経路を証明するものではありません。接続記録と実際のネットワーク設定をあわせて判断してください。

まず、ダウンロードと解析のどちらの段階で失敗したか確認します。HTTP 401や403は認証やアクセス制限、404はURLの無効化が原因の可能性がありますが、具体的な意味はサービス提供元の案内を確認してください。タイムアウトする場合は、現在のネットワークからサブスクリプションURLにアクセスできるか調べます。ダウンロードできても解析に失敗する場合は、取得した内容がログインページになっていないか、現在のコアに対応する形式か、YAMLのインデントが正しいか確認しましょう。User-Agentは提供元から明確な指定がある場合に限り変更してください。前回使えた設定を残し、新しいURLを取得してから更新します。認証情報を含むURLを、出所の分からない変換サイトに渡さないでください。

まずプロキシを無効にして、通常のネットワークが使えるか確認します。次に設定が有効か、アカウントのサービスが利用可能か、ノード情報がそろっているかを調べてください。ノードを1つ選んで接続エラーを確認し、DNSの名前解決失敗、接続タイムアウト、認証失敗、プロトコル非対応を切り分けます。テスト先に到達できないためにすべてタイムアウトすることもあるので、実際のWebページへのアクセスでも確認しましょう。ほかのプロキシやVPNを終了し、別のネットワークでも試します。同じ設定が別の端末で動くなら、ローカルのポート、ファイアウォール、通信の取り込み口を重点的に確認してください。設定、DNS、システムネットワークを一度にリセットすると原因を特定しにくくなるため、同時に変更しないでください。

OSのプロキシ設定が、クライアントで実際に待ち受けているローカルアドレスとポートを指しているか確認し、コアが動作中であることも確かめます。ブラウザーの拡張機能、個別のプロキシ設定、ほかのネットワークツールがシステム設定を上書きすることがあります。一時的に無効にして、ブラウザーを再起動して比較してください。クライアントを終了した後にネットへ接続できない場合、OSに終了済みのポートを指すプロキシ設定が残っていることがよくあります。まずシステムプロキシを無効にするか、元の設定に戻してから直接接続を試します。再び有効にする場合は、先にコアを起動してからプロキシをオンにしてください。組織のポリシーで管理されている端末では、その指示に従い、ポリシーを強制的に上書きしないでください。

AppContainerを使う一部のWindowsアプリにはローカルループバック制限があり、127.0.0.1上のプロキシに接続できない場合があります。まず通常のブラウザーで接続できることと、対象アプリがシステムプロキシを使っていることを確認してください。その後、クライアントに付属するUWPループバックツールを使い、必要なアプリだけに許可を与えます。WindowsにはCheckNetIsolationツールもありますが、アプリのパッケージIDと操作権限を確認し、すべてのアプリを一括で許可しないでください。許可した後は対象アプリを再起動します。Microsoft Storeからインストールしたアプリすべてにこの制限があるわけではありません。また、ループバックの許可ではノード、DNS、サーバー側の問題は解決しないため、接続記録も確認してください。

速度が遅い場合は、直接接続とプロキシ経由を比較し、ノードを固定して同じ接続先を試します。ノードの負荷、回線の変動、端末側の設定を切り分けましょう。遅延が小さくても通信速度が速いとは限りません。特定のアプリだけ遅い場合は、そのアプリに適用されたルールと通信の取り込み口を確認します。クライアントがクラッシュする場合は、設定とログを保管したうえで、直前に使えていた設定へ戻し、最近追加したルール、プロバイダー、コアとの互換性を確認してください。起動直後に終了する場合は、クライアントの説明に従って設定ディレクトリを一時的に別の場所へ移し、動作を確認します。OSに対応したクライアントへの更新も検討してください。データをすべて削除したり、原因を調べずに再インストールを繰り返したりしないでください。