Windows
デスクトップでの日常利用に適しており、Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuを選べます。 インストール後はシステムプロキシの権限を確認してください。UWPアプリを使う場合は、ループバック制限がローカルプロキシへのアクセスに影響していないかも確認します。
Clash クライアントのインストーラー、mihomo コアの設定、YAML によるルール分岐をまとめています。まずOSに対応するGUIクライアントを選び、項目の説明に沿ってサブスクリプションを追加し、DNSの動作とルールのマッチ結果を確認してください。
Clashのリクエスト処理は単一のスイッチではなく、リスニング入口、DNS、ルールマッチング、プロキシグループ、アウトバウンド接続で構成される処理チェーンです。 以下のインデックスでは実際の設定関係に沿って分解して説明し、各項目がどの層に位置し、変更によってどのリクエストに影響するかを確認できます。
rules は上から下へ実行される順序付きリストです。ドメイン、IP、プロセス名、ルールセットをマッチ条件に指定できます。
ルールに一致すると、コアはその項目で指定されたプロキシグループ、DIRECT、または
REJECT にリクエストを渡し、後続の項目は判定しません。そのため、具体的なドメインルールを先に置き、対象範囲の広い
GEOIP、GEOSITE、最終フォールバックルールを後ろに配置します。
分岐結果を調べるときは、まずリクエストが実際に一致したルールを確認し、次にそのルールが指すプロキシグループを確認してください。いきなりノードを変更するのは避けます。
よくあるずれの原因は、ルール順、ドメインサフィックスの範囲、ルールセットの未更新、またはDNSの応答結果がIPルールの想定と異なることです。
設定項目ページでは、DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCH などの構文と適用範囲も解説しています。
プロキシグループはルールとプロキシノードの間に位置します。固定の出口を使いたい場合は手動選択グループが適しています。自動テストグループは、設定されたテスト先、間隔、許容値に基づいて利用可能な項目を選びます。フォールバックグループはメンバー順に接続可能なアウトバウンドを探します。プロキシグループには別のプロキシグループも含められるため、地域、用途、切り替え方式を明確な階層に分け、ルールファイルでノード名を重複して記述する必要を減らせます。
設定時は type、メンバーの取得元、ヘルスチェック、参照名を同時に確認します。ルール内のプロキシ名は
proxy-groups の名前と一字一句一致させてください。サブスクリプション更新後、グループが固定名に依存していると、旧名が無効になることもあります。
多くのGUIクライアントでは、日常の切り替えで変わるのはプロキシグループの現在の選択だけで、元のサブスクリプション内容は書き換えません。
DNSモジュールはアプリの問い合わせを受け、上流サーバーを選択し、ドメインの結果を後続のルール判定へ渡します。
fake-ip を有効にすると、コアはまず予約アドレスプールから対応アドレスを返し、アプリが接続すると対応関係から元のドメインを復元します。
これによりドメインルールに必要な情報を保持できます。LAN機器、接続性チェック、実アドレスを必要とする一部のアプリは、
fake-ip-filter で例外に設定できます。
DNSの障害では、「ドメインを解決できない」場合と「解決は成功するが接続できない」場合を分けて考えます。確認する順番は、リスニングアドレス、デフォルトリゾルバー、 プロキシサーバーのドメインを解決する経路、暗号化DNSへの到達性、そしてシステムが別のインターフェースへ問い合わせを送っていないかです。上流アドレスだけを変更しても解決しない場合があります。 起動時の名前解決、ルール判定、プロキシ経路で異なるサーバー群が使われることがあるためです。
DNSとFake-IPの用語を見る →GUIクライアントは通常、リモートサブスクリプション、ローカル設定のコピー、現在の実行設定を保存します。サブスクリプション更新ではサービス提供元が公開したノードと基本ポリシーを取得し、ローカル上書きではDNS、ルール、画面関連の設定を追加します。実行設定はクライアントがマージを完了した後、コアへ渡す最終結果です。3つは同じファイルではないため、キャッシュのコピーを直接編集すると次回更新で置き換えられることがあります。
設定を管理するときは、まずクライアントが対応する上書き方式を確認し、前置き、後置き、項目単位のマージから選びます。YAMLのインデントは統一し、同名キーの上書き規則はクライアントの実装に従います。配列項目も追加ではなく置換されることがあります。インポートに失敗したら、最小構成で構文を検証してから、プロキシ、プロキシグループ、DNS、ルールを段階的に戻すと、非対応項目を早く特定できます。
上書きとマージの方法を見る →トップページではプラットフォームへの入口だけを案内します。インストーラー形式、クライアントの違い、システム要件、メンテナンス終了状況はダウンロードページにまとめ、異なるアーキテクチャのファイルが混在しないようにしています。該当するタブを開き、デバイスのアーキテクチャと用途に応じてクライアントを選んでください。
デスクトップでの日常利用に適しており、Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuを選べます。 インストール後はシステムプロキシの権限を確認してください。UWPアプリを使う場合は、ループバック制限がローカルプロキシへのアクセスに影響していないかも確認します。
Apple SiliconとIntelでは対応するアーキテクチャのファイルをダウンロードしてください。初回起動時にシステム設定でネットワーク拡張やプロキシの権限を許可する場合があります。 メニューバーに接続状態が表示されているのにリクエストがコアを経由しない場合は、システムプロキシと拡張モードの設定を確認します。
Clash Plus、Clash Meta for Android、FlClash、Surfboardを選べます。サブスクリプションを追加すると、システムから VPN接続の作成を求められます。省電力設定、バックグラウンド制限、メーカー独自のネットワーク管理機能が常時接続を中断することがあるため、端末ごとに確認してください。
iPhoneとiPadではApp StoreからClash Plusを入手できます。初回接続時はVPN構成の追加を許可し、 サブスクリプションを追加したら先にプロキシグループを選んでから接続を開始します。システムステータスバーのVPN表示はトンネルが確立したことを示すだけで、実際のアクセス結果はルールとアウトバウンドに左右されます。
デスクトップ環境ではClash Verge RevまたはFlClashを利用できます。サーバー、ルーター、コンテナ環境では通常、mihomoコアを直接デプロイします。 ファイルを選ぶ際はパッケージ形式とCPUアーキテクチャを区別し、サービス管理、作業ディレクトリ、設定ファイルの読み取り権限を自分で設定してください。
現在のデバイスにクライアントが適しているか判断するには、GUI、プロキシコア、設定形式の3つの層を分けて考える必要があります。 これらは別々のプロジェクトが保守していても、近い設定構造と制御インターフェースを通じて連携できます。
Clashエコシステムでは、広く使われる設定モデルが形成されています。プロキシノードは proxies で記述し、プロキシの選択は
proxy-groups で構成します。リクエストは rules に従って順番にマッチし、DNSモジュールが名前解決とドメインのマッピングを担います。
元のClashプロジェクトが継続的な開発を停止した後も、コミュニティの派生プロジェクトが互換項目を拡張しており、mihomoは現在も保守されている代表的なコアの一つです。
そのため、多くの新しいクライアントは名称が異なっていても、近い設定構造、制御インターフェース、ルールの意味体系を基盤に動作します。
Clash Plus、Clash Verge Rev、FlClashなどのGUIクライアントは、主にサブスクリプション管理、設定切り替え、システムプロキシ制御、 ログ表示、コアのライフサイクル管理を担当します。DNS処理、ルールマッチング、アウトバウンド接続を実行するのは、クライアントに内蔵または呼び出されるコアです。 問題が起きたら、まずGUI層とコア層のどちらに原因があるか判断します。画面で設定を保存できない場合はクライアントの動作、設定の解析失敗は項目またはコアの互換性、 接続後も特定サイトだけ出口を誤る場合はルールとプロキシグループを確認します。
オープンソースリポジトリのコミット履歴、リリース、課題の議論、設定ドキュメントを相互に確認できます。クライアント名だけを見るより、 最近も継続的にコミットされているか、インストーラーが現在のアーキテクチャをカバーしているか、コアのバージョンが設定項目に対応しているか、 重大な変更に移行手順が添えられているかを確認する方が有効です。Clash 中国語サイトではクライアント比較ページで保守中のプロジェクトとアーカイブ済みプロジェクトを区別し、 ダウンロードページでも各カードにメンテナンス終了状況を明記しているため、インストール前に選択できます。
クライアントのアップグレード、コアのアップグレード、サブスクリプションの更新は別々の操作です。クライアントのアップグレードでは画面や上書き方式が変わることがあり、コアのアップグレードでは項目が追加・変更されることがあります。サブスクリプション更新は主にノードとサービス提供元のルールを置き換えます。変更前に現在使える設定をエクスポートし、利用中のプロキシモードを記録してから、一度に1つの層だけ更新してください。解析エラーが出た場合は古い設定へ戻し、ログに示された項目位置を順に修正します。クライアント、コア、サブスクリプションを同時に置き換えるのは避けてください。
以下の質問は、最初の切り分けに役立ちます。詳しい項目、クライアントごとの差異、段階的なトラブル対処が必要な場合は、対応するヘルプページへ進んでください。 ログや設定の状況を確認せず、複数の項目を一度に変更するのは避けましょう。
Clashは通常、設定モデルと関連エコシステムを指します。mihomoは継続的に保守されている互換コアの一つです。Clash Plus、Clash Verge Rev、 FlClashなどはGUIクライアントに分類されます。GUIクライアントは設定とシステム連携を担当し、コアは解析、マッチング、接続を担います。 より詳しい層構造は用語マニュアルで確認できます。
まず基本のネットワークが利用できることを確認し、クライアントがコアを起動しているか、システムプロキシまたはVPNの権限が有効か、プロキシグループで利用可能なアウトバウンドを選んでいるか、 DNSが名前解決できるか、リクエストが最終的にどのルールへ一致したかを順に確認します。最初からDNS、モード、サブスクリプションを同時に変更しないでください。 層ごとに確認する方が手がかりを残しやすくなります。詳しい手順はヘルプセンターのトラブル対処をご覧ください。
ルールモードは設定ファイルのルールに従って各リクエストの行き先を決めるため、通常の利用に適しています。グローバルモードは大半のリクエストを指定したプロキシグループへ渡し、 プロキシ経路を一時的に検証するときに使います。ダイレクトモードは、問題の原因がプロキシ経路にあるか確認する際に役立ちます。トラブル対処が終わったら通常はルールモードに戻し、 ログで主要ドメインが想定したプロキシグループに一致していることを確認します。
リモートサブスクリプションを更新すると、通常はローカルのキャッシュコピーが置き換えられます。長期的に保持したいDNS、ルール、プロキシグループの変更は、 サブスクリプションのキャッシュを直接編集せず、クライアントが対応する上書きファイルまたはマージ設定に記述してください。 配列の追加、同名キーの上書き、スクリプトによる上書きへの対応はクライアントごとに異なるため、まず上書きとマージの章を確認します。
インストール、サブスクリプション、自動起動、Fake-IP、UWPループバックの問題をさらに調べる場合は、 ヘルプセンターのカテゴリ別Q&Aを見る →
記事では具体的な作業ごとに、再現可能な確認手順、項目の適用範囲、プラットフォームごとの差異を解説しています。 まず基本チェックを済ませ、ログや設定の状況に応じて該当する章へ進んでください。
リンクの状態、レスポンス内容、YAMLのインデント、項目の互換性、ローカルキャッシュを順番に確認し、サブスクリプションの追加に失敗した原因を特定します。 サーバー側のレスポンス異常とクライアント側の解析問題も切り分けます。
記事を読む →iPhoneとiPadでクライアントを入手し、設定を追加してVPNを許可し、プロキシグループを選択して初回接続の状態を確認するまでの流れを解説します。
記事を読む →遅延テストと実際の利用可能性を区別し、通信量の倍率、目的地域、プロトコルの特徴、一定期間の安定性を踏まえてノードを選びます。
記事を読む →