CONFIG / 問い合わせキュー
まず、「通信がコアに取り込まれているか」と「取り込まれた後、どのルールが適用されるか」を切り分けます。以下の設定例は各項目の確認用であり、単独で動作する完全なサブスクリプションではありません。プロキシグループ名は既存の設定と一致させてください。例の PROXY は、実際に存在するグループ名に置き換えます。
ルールモードを使うと、1台のデバイスで直通とプロキシを使い分けられます。動作モードを rule に設定し、明示的に処理するドメイン、地理ルールの順に記述して、最後に MATCH で受けます。グローバルモードのようにすべての通信を同じプロキシグループへ送るのではなく、直通モードとは異なり、設定したルールに従って通信を振り分けます。対象サイトにアクセスしたら、接続ログで適用ルールと最終的な出口を確認してください。例でハイライトされた行に該当するのは、ほかのルールに一致しない宛先です。すべての通信がこの行を通るわけではありません。
mode: rule
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXYTUNは仮想ネットワークインターフェースを使って通信を取り込み、システムプロキシに対応していないアプリでも利用できます。ただし、TUNを有効にしてもすべての通信がプロキシ経由になるとは限らず、最終的にはルールに従います。デスクトップクライアントではサービスモードや管理者権限が必要な場合があり、モバイルではシステムのVPN許可を通じて動作します。まず通常のシステムプロキシで通信できることを確認してから、TUN、自動ルート、インターフェース検出を有効にしましょう。原因不明の設定を同時に増やさないことが大切です。ほかのVPNと併用している場合は、いずれかを停止して再確認します。LAN内のアドレスに接続できないときは、ノードを何度も変更するのではなく、ルートの除外設定を確認してください。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53DNS設定では、ドメイン名をどう解決するか、DNSリクエストをどこから送るかを指定します。fake-ipを有効にすると、コアはまず対応するアドレスを返し、接続時にドメイン名に基づいて通信を振り分けられます。実際のIPアドレスを直接返す方式とは異なります。拡張モードを変更するだけでは、システムのDNSが確実に取り込まれるとは限りません。TUNのDNSハイジャック設定、ブラウザーのセキュアDNS、アプリ内蔵のリゾルバーも確認してください。以下は基本項目です。上流DNSはネットワーク環境に応じて選びます。再確認時はDNSの解決ログと接続ルールの両方を確認しましょう。チェックサイトに表示されるリゾルバーの所在地は手がかりにすぎず、それだけでDNS漏れがあるとは判断できません。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://dns.alidns.com/dns-queryサブスクリプションの追加では、設定の取得元とその後の更新方法を確認します。GUIクライアントのリモート設定には通常、ノード、プロキシグループ、ルールが含まれます。一方、proxy-providersが提供するのはノードだけなので、2種類の追加方法を混同しないでください。設定画面でサービス提供元のURLを登録し、更新が成功したことを確認してから、現在の設定として選択します。URLをブラウザーで公開したり、見知らぬ変換サイトに貼り付けたりしないでください。以下はプロキシプロバイダーの更新構造を示す例です。URLは差し替えが必要で、参照するプロキシグループも別途定義します。更新に失敗したら、まずHTTPステータスを確認し、その後、有効期限とローカルキャッシュを調べます。
proxy-providers:
remote:
type: http
url: "https://example.com/proxies.yaml"
path: ./providers/remote.yaml
interval: 86400オーバーライドを使うと、ローカルのポート、DNS、ルール設定などを保持でき、サブスクリプションを更新するたびに編集し直す必要がありません。ただし、設定のマージ、拡張スクリプト、オーバーライドの場所はクライアントごとに異なります。特定のフロントエンドの操作手順を、コア共通の機能とみなさないでください。元の設定をバックアップし、変更が必要な項目だけを上書きしてから、起動後に最終的な実行設定を確認します。リスト項目は置き換えか追加かを必ず確認してください。意図したルールが最終ルールより後ろに移動する場合があります。リモートキャッシュを直接編集するより、独立したオーバーライドのほうが元に戻しやすく、問題が起きた場合は一時的に無効化して原因を絞り込めます。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info確認する順番：まず設定を読み込めるか、次に待ち受けポートを確認します。その後、アプリの通信がコアに取り込まれているかを確かめ、最後にルールとDNSを確認してください。該当する接続がログにない場合、「どのノードを選ぶか」を調べる段階にまだ達していないことがほとんどです。まず通信の入口を確認してから出口を調べると、遠回りを減らせます。
設定例はmihomoを基準にしていますが、GUIクライアントが一部の項目を生成または上書きする場合があります。各OSのインストール先、サービス権限、システム上の制限を確認するには全OS向けガイドをご覧ください。まず接続だけ試したい場合は、サブスクリプションの追加手順から始められます。
PACKAGES / OS別に選ぶ
クライアントは画面表示、設定管理、システム連携を担当し、コアはプロトコル処理とルール適用を担当します。選ぶ際は、まずOSとCPUアーキテクチャを確認し、次にメンテナンス状況と機能の対応範囲を比較してください。Clash チュートリアルではダウンロード先と設定方法をまとめていますが、各クライアントプロジェクトの公式サイトではありません。また、プロキシサービスやサブスクリプションアカウントは提供していません。
まずはClash Plusを検討し、使い方に合わせてClash Verge Rev、FlClash、Clash Nyanpasuも比較できます。ダウンロード前にOSとインストール権限を確認してください。初回起動後は設定を追加してからシステムプロキシを有効にします。TUNを使う場合はサービスモードが正しくインストールされているか確認し、権限エラーをサブスクリプションの失効と誤認しないようにしましょう。
ダウンロードページへ →「このMacについて」でApple SiliconかIntelかを確認し、対応するインストーラーを選んでください。Clash Plus、Clash Verge Rev、FlClashは画面やメンテナンス状況を比較して選べます。初回起動時にシステムのセキュリティ警告が表示された場合は、システム設定から許可してください。アプリ1つのためにセキュリティ保護全体を無効にする必要はありません。
ダウンロードページへ →まずClash Plusを確認し、Clash Meta for Android、FlClash、Surfboardとの設定互換性も比較できます。初回接続時にはシステムのVPN許可が必要です。バックグラウンドに移ると接続が切れる場合は、バッテリー最適化とバックグラウンド実行の制限を確認してください。インストールパッケージのアーキテクチャが端末に合っていること、設定形式がクライアントに対応していることも確認しましょう。
ダウンロードページへ →ダウンロードページにはClash PlusのApp Storeリンクと、公式サイトclashplus.ioを掲載しています。インストール後、対応するサブスクリプションまたは設定を追加し、VPN構成の追加を許可してください。VPN接続済みという表示は、トンネルが確立したことを示すだけです。実際に対象のWebサイトへアクセスし、ルールと出口が想定どおりか確認しましょう。
ダウンロードページへ →デスクトップ環境ではClash Verge RevまたはFlClashを選び、ディストリビューションに合ったパッケージを使います。GUIのないサーバーやルーターでは、mihomoコアを直接実行する方法が適しています。GUIのシステムプロキシ設定がターミナルのプログラムに反映されるとは限りません。環境変数、アプリ内のプロキシ設定、TUNを確認して実際の通信経路を判断してください。
ダウンロードページへ →アーカイブ済みのクライアントは過去の設定を理解する参考になりますが、使い慣れた旧画面だからという理由だけで、メンテナンス状況を無視して使い続けるのは避けましょう。mihomoエコシステムへ移行する際は、プロトコル項目、プロキシグループの参照、DNSパラメーターを確認してください。ファイルを読み込めても、すべての項目が適用されるとは限りません。複数のプロキシクライアントを同時に起動すると、ポートやルートが競合することもあります。初回の動作確認では1つだけ起動してください。
すべてのクライアントを見る → · クライアントの比較レビューを見る →QUICKSTART / 最小限の接続手順
まずは最小限の手順で接続し、オーバーライド、カスタムルール、TUNは後から追加しましょう。対応するサブスクリプションURL、インターネットに接続できる端末、元の設定のバックアップを用意してください。クライアントをインストールしただけでは利用可能なノードは作成されず、インストール完了とプロキシサービスの利用開始は別です。
クライアントの設定またはサブスクリプション画面でリモートURLを追加し、更新を実行します。ノードとプロキシグループが表示されたら、その設定を現在の使用項目に指定してください。一覧が空の場合は、更新ログのステータスコードと解析エラーを確認します。サブスクリプションURLにはアカウント情報が含まれる場合があるため、URL全体を公開スクリーンショットに載せないでください。この段階ではDNSを変更せず、元に戻せる状態を保ちましょう。
ルールモードを選択し、プロキシグループで使用可能な出口を指定してから、システムプロキシを有効にします。デスクトップのブラウザーでは通常、この方法で初回テストができます。モバイル端末では案内に従ってVPN権限を許可してください。システムプロキシを使わないアプリがある場合は、TUNを別途検討します。グローバルモードへの切り替えと、ポートやルートの変更を同時に行わないでください。設定が一度うまくいっても、どの変更が効いたのか分からなくなります。
プロキシ経由にしたい宛先と直通にしたい宛先へそれぞれアクセスし、接続画面でドメイン名、適用ルール、プロキシチェーンを確認します。Webページを開けない場合は、エラーの内容を記録してください。DNS解決エラー、接続タイムアウト、証明書エラーでは対処方法が異なります。テスト後はプロキシを無効にして再度アクセスし、システムプロキシが正常に戻ることも確認しましょう。スイッチの表示が変わっただけでは検証になりません。設定ファイルも保存しただけで正しくなるわけではありません。
SOURCE / コアとフロントエンドの役割
クライアントを長く使うか判断するには、どのコアに依存しているか、設定をどう更新するか、エラー発生時に実行ログを確認できるかを見ましょう。名前が似ていても同じメンテナーのプロジェクトとは限らず、機能や更新頻度も同じとは限りません。
オリジナルのClashプロジェクトがメンテナンスを終了した後も、コミュニティでは互換性のあるルール構文や設定構造を中心に開発が続いています。mihomoはClash.Metaの技術的な流れを引き継ぎ、プロトコル、ルーティング、DNSなどの機能をメンテナンスしています。解説に登場するClash、Clash Meta、mihomoには歴史的なつながりがありますが、同じソフトウェア名として扱うことはできません。古いガイドにある項目、独自機能、プラットフォーム上の制限は、現在のコアのドキュメントで確認してください。
Clash Verge Rev、FlClash、Clash Nyanpasuなどのフロントエンドは、サブスクリプション管理、トレイメニュー、システムプロキシ、サービス連携を提供します。実際に接続を確立し、ルールを解析して通信を処理するのはコアです。フロントエンドが更新されても、プロトコル実装が変わったとは限りません。反対に、コアを入れ替えても画面は変わらない一方、設定項目の対応状況が変わることがあります。エラーを報告するときは、クライアント名、OS、コアの情報を記録し、どの層の問題か特定できるようにしてください。
mihomoのリポジトリではGPL-3.0ライセンスのもとでコードが公開されています。機能の出所を確認する際は、ソースコード、コミット履歴、課題の議論を参照できます。コードを確認できるからといって、どのような設定でも安全とは限りません。待ち受けアドレスの公開、LANアクセス、コントロールインターフェースの公開には、利用者自身によるアクセス範囲の確認が必要です。ルールやサブスクリプションも入力データです。提供元が不明な場合は、長期利用している設定をそのまま上書きしないでください。また、コントロールインターフェースの認証情報を他人に渡さないでください。
アプリの更新は画面やコアの問題を修正し、サブスクリプションの更新はノードやルールを同期します。GeoIPやGeoSiteのデータ更新は、地理ルールによる振り分けに影響します。この3つは別の更新です。更新前に動作する設定を保存し、更新後は起動ログと主要サイトに適用されるルールを確認してください。サブスクリプションの応答エラーだけなら、クライアントを何度も再インストールしても解決しないことがほとんどです。設定項目に互換性がない場合は、実行中のコアがその設定に対応しているか確認しましょう。
症状から情報を探す：mixed-portとコントロールインターフェースの違いが分からない場合は用語解説をご覧ください。追加は成功したのに接続できない場合は、まずよくある質問を確認しましょう。OSごとのシステムプロキシ、権限、バックグラウンド実行の制限を確認するには全OS対応インストール・設定ガイドをご覧ください。当サイトでは再現可能な手順と設定の解説を重視し、ダウンロード数や評価を技術的な根拠の代わりにはしません。
FIELD NOTES / 最新のトラブル対処メモ
クイックスタートでは初回接続までを案内し、以下のメモでは接続後に起きる問題を扱います。読む前に、「ブラウザーでは閲覧できるがターミナルでは失敗する」「ルールは正しいがDNS解決がタイムアウトする」のように、症状を検証可能な問いに整理してください。設定全体を一度にコピーするより、根拠をもとに原因を絞り込めます。
サブスクリプションの有効期限、ノードへの接続、システムプロキシのポート、TUNの権限、ルールモード、DNSの汚染を順番に確認し、通信できない原因を特定します。
トラブル対処のメモを読む →default-nameserver、nameserver、fallback、fallback-filter、TUN使用時のdns-hijackについて、各項目の役割を解説。すぐに応用できる設定例も紹介します。
設定メモを読む →オリジナルコア、Premium、mihomoの変遷をたどり、Verge、FlClash、Nyanpasuなどのフロントエンドとコアの依存関係を整理。クライアント選びに役立つ情報を紹介します。
エコシステムのメモを読む →DNSを変更する場合は、変更前後の名前解決結果を保存し、ブラウザーでセキュアDNSが有効かどうかも記録しましょう。ルールを変更する場合は、対象ドメインと実際に適用された行を残してください。ログには赤いアイコンのスクリーンショットだけでなく、「どこで失敗したか」が分かる情報を含めます。共有前にアカウント情報を削除してください。再現手順が短いほど、問題を特定しやすくなります。
すべての記事を見る →