TRACK 01
Windows
Windowsデスクトップ環境向けです。ダウンロードページではClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、アーカイブ版クライアントを順に掲載し、推奨項目と対応アーキテクチャを示しています。導入後は通常、システムトレイからメイン画面を開き、サブスクリプションまたはYAMLファイルを読み込みます。
ルール分岐・クライアントと設定ドキュメント
OSに合ったクライアントを選び、サブスクリプションまたはローカル設定を読み込んだら、ルールでトラフィックの経路を決めます。本サイトではマルチプラットフォーム対応クライアント、YAML設定、トラブルシューティングをまとめ、導入からポート、DNS、ポリシーグループ、ルール順序まで確認できます。
Platform entrance
トップページではプラットフォームへの入口のみを案内し、対応クライアント、アーキテクチャ、メンテナンス状況、パッケージ形式はダウンロードページにまとめています。現在の端末のOSとプロセッサを確認してから、GUIクライアントまたはコマンドラインのコアを選ぶと、パッケージの不一致や設定ディレクトリの混同を防げます。
TRACK 01
Windowsデスクトップ環境向けです。ダウンロードページではClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、アーカイブ版クライアントを順に掲載し、推奨項目と対応アーキテクチャを示しています。導入後は通常、システムトレイからメイン画面を開き、サブスクリプションまたはYAMLファイルを読み込みます。
TRACK 02
Intel搭載MacおよびApple Silicon Mac向けです。パッケージを選ぶ際はx64とARMを区別してください。初回起動時にシステムのセキュリティ確認、ネットワーク拡張の許可、システムプロキシ権限が求められる場合もあります。ダウンロードページではアーキテクチャ別に入口を分けているため、「このMacについて」の情報に合わせて選べます。
TRACK 03
スマートフォン、タブレット、一部のAndroid TV端末向けです。クライアントは通常、システムVPNインターフェースで通信を引き継ぐため、初回接続時にVPNリクエストを確認する必要があります。端末のアーキテクチャが不明な場合は汎用パッケージを優先し、容量を抑えたい場合はARM64またはARM向けを選んでください。
TRACK 04
iPhoneとiPadのユーザーはApp StoreからClash Plusのページを開けます。インストール後、クライアント画面からサブスクリプションを読み込み、初回接続時にシステムVPN設定を確認してください。ダウンロードページにはApp Storeへの入口とclashplus.io公式サイトも掲載し、製品情報を照合できるようにしています。
TRACK 05
デスクトップではGUIクライアント、サーバー、ソフトウェアルーター、コンテナ環境ではmihomoコアが適しています。ダウンロード前にディストリビューション、CPUアーキテクチャ、インストール形式を確認し、起動後は設定ディレクトリ、ログ出力先、サービス管理方法も把握してください。
クライアントの違いが分からない場合は、まず各プラットフォームの推奨項目を確認し、TUN、システムプロキシ、トレイ管理、コマンドライン実行の要否に応じて選ぶとよいでしょう。
すべてのクライアントを見る →Rule switchyard
Clashは設定内のルールを上から順にリクエストへ適用します。マッチすると、トラフィックは直接接続、プロキシ、遮断のいずれかのポリシーへ送られます。マッチしなければ下のルールへ進み、最後にフォールバックルールへ到達します。この処理チェーンを理解すると、特定クライアントのボタンを覚えるよりも問題を切り分けやすくなります。
RULE ENTRY
ルールの順序が結果を直接左右します。具体的なドメインやプロセスのルールを前に置き、地域ルールや汎用ルールを後ろに置き、最後にMATCHでフォールバックポリシーを指定します。
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
DIRECT
直接接続ポリシーではプロキシノードを経由せず、現在のネットワークから対象へ直接アクセスします。LANアドレス、ローカルサービス、アクセス元地域の影響を受けるサイト、プロキシが不要と確認できたドメインに適しています。一般的な設定では、まずプライベートアドレス、次にローカル地域のIPまたはドメイン集合をマッチさせます。直接接続はルールを無視するという意味ではありません。リクエストはClashのマッチ処理を通過し、最終的な出口だけがローカルネットワークになります。プロキシモードでログインに失敗する、ダウンロード速度が低下する、LAN機器に接続できないといった場合は、DIRECTに入るべき通信か確認してください。変更後は接続ログでルール名とポリシー結果を確認し、ページが開くかどうかだけで判断しないことが重要です。
PROXY
プロキシポリシーは通常、単一ノードの名前ではなくポリシーグループです。ルールがPROXYにマッチすると、クライアントはグループの種類に応じて、手動選択、自動テスト、フォールバック、負荷分散の結果を使います。これにより「どのリクエストをプロキシに通すか」と「プロキシ通信でどのノードを使うか」を2層に分けて設定でき、ノード交換時にルール全体を書き直す必要がありません。Webページは開くのにアプリが接続できない場合は、ルールへのマッチ、ポリシーグループの存在、グループ内ノードの稼働状況、システムプロキシまたはTUNによるアプリの引き継ぎを順に確認してください。接続ログのルール名、ポリシー名、宛先アドレスが経路を特定する主な手掛かりです。全体モードを何度も切り替えるだけでは、元の問題が隠れてしまうことがあります。
REJECT
遮断ポリシーは、既知のトラッキングドメイン、異常なリクエスト、アクセスしたくない宛先など、特定の接続を明示的に終了するために使います。ローカルのルール層で失敗結果を返し、そのリクエストに直接接続やプロキシの出口を選択しません。遮断ルールは対象を明確にし、上書きする可能性のある広範なルールより前に置いてください。広すぎるドメイン集合や誤ったワイルドカードは、ログイン、認証コード、プッシュ通知、アプリ更新に影響する場合があります。ページ本文は表示されるのに画像、ボタン、ログイン手順が欠けるときは、ログのREJECT該当項目を一時的に確認し、具体的なドメインに合わせてルールを調整します。ブラウザー拡張機能と比べ、ClashのルールはシステムプロキシやTUNで引き継ぐ多くのアプリを対象にできますが、マッチ範囲を慎重に管理する必要があります。
A / 仕組み
ルールはリクエストの種類を判定し、ポリシーは実際の出口を決めます。両者を一緒に考えると、ノード変更のたびにルールまで修正しがちです。分けて管理すれば、ポリシーグループのメンバーや選択結果だけを調整できます。
B / シナリオ
トラブルシューティングでは、まずリクエストがクライアントに引き継がれているかを確認し、次にどのルールにマッチしたか、最後に対応するポリシーとノードを確認します。この順序で調べると、ポート、DNS、ルール、上流接続の問題を切り分けられます。
C / 設定
ルールリストの末尾には、明確なフォールバック先を用意してください。フォールバックがない、存在しないポリシーグループを参照している、広範なルールを早すぎる位置に置いているといった状態では、前半で細かく設定したドメインルールが機能しなくなります。
Quick start
以下は、動作する基本環境をすばやく構築するための手順です。クライアントによってボタンの位置は多少異なりますが、基本の順序は同じです。まずパッケージとOSの互換性を確認し、次に有効な設定を読み込み、最後にログと実際のリクエストで引き継ぎ範囲を検証します。
Windowsユーザーは通常x64デスクトップ版を選びます。Apple Silicon MacはARM版、Intel Macはx64版を選択し、Android端末はプロセッサのアーキテクチャに合うパッケージを選んでください。導入後はクライアントを起動し、メイン画面、設定ディレクトリ、ログ領域が正常に開くことを確認します。ネットワーク拡張、VPN、ファイアウォールの権限が表示された場合は、現在のクライアント機能に必要か確認して許可してください。許可しないとシステムプロキシやTUNが通信を引き継げないことがあります。
サブスクリプションは、サーバー側でノードやルールを継続的に管理する場合に適しています。ローカルYAMLは、自分で作成してバージョン管理したい場合に向いています。読み込み後は、クライアントに構文エラーが表示されていないか確認し、ポリシーグループ、ノード、ポート、DNS項目が認識されていることを確認してください。更新に失敗しても既存の設定をすぐ削除せず、URLが完全か、配信元へ接続できるか、応答内容が本当に設定テキストかを確認し、ログでネットワークエラーとYAML解析エラーを区別します。
デスクトップブラウザーでは、まずシステムプロキシで検証できます。システムプロキシ設定を読み取れないアプリではTUNを検討してください。接続後、クライアントのログまたは接続一覧を開き、対象ドメインが想定どおりDIRECT、PROXY、REJECTのいずれかに入っているか確認します。ブラウザーは使えるのに他のアプリが使えない場合は引き継ぎ方式を重点的に確認し、すべてのアプリが接続できない場合はリスニングポート、設定の読み込み状態、ポリシーグループを優先して調べます。特定ドメインだけに問題がある場合は、ルール順序とDNSの解決結果に戻って確認します。
Open source context
Clash関連の名称は、元のコア、後継実装、GUIクライアント、汎用設定フォーマットを同時に指す場合があります。これらの層を理解すると、各項目をどのコンポーネントがサポートするのか、障害を画面側とコア側のどちらで処理すべきか判断しやすくなります。
01 / プロジェクトの歴史
Clashは、YAML設定、ポリシーグループ、順序付きルールを中心とする利用モデルを築きました。元のプロジェクトがメンテナンスを停止した後も、エコシステム内のクライアントと設定が同じ更新経路をたどったわけではありません。現在、多くのデスクトップ・モバイルクライアントはmihomoコアを採用し、DNS、TUN、ルールプロバイダー、プロキシプロトコル、ネットワークスタック関連の機能を拡張しています。チュートリアルを読む際は、対応するコアとクライアントのバージョンに注意してください。古い項目は互換性があっても、新しい項目を古いコアが認識できるとは限りません。同じ設定が端末によって異なる動作をするときは、設定自体が無効だと決めつけず、まず両端のクライアント名、コア名、設定読み込みログを記録します。
02 / オープンソースエコシステム
GUIクライアントは主に設定管理、サブスクリプション更新、システムプロキシ切り替え、TUN権限、ログ表示、コアのライフサイクルを担当します。コアはリスニングポート、設定解析、接続確立、DNS処理、ルールマッチを担います。両者は別プロジェクトで管理できるため、画面の更新がコア項目の変更を意味するとは限らず、コアが機能をサポートしていても、すべてのクライアントに対応する切り替え項目があるとは限りません。本サイトのダウンロード一覧ではクライアントをプラットフォーム別に分類し、設定ドキュメントでは項目名を使って低レイヤーの動作を説明しています。高度な機能を確認するときは、画面に項目があるかだけで判断せず、クライアントのコア情報と設定読み込み結果を併せて確認してください。
03 / コアの関係
リスニングポート、動作モード、プロキシノード、ポリシーグループ、ルールなどの基本項目は、実装が異なっても比較的判別しやすいものです。一方、DNSポリシー、TUNネットワークスタック、ルール集合の形式、特定プロトコルの項目は、コアのバージョンに左右されやすくなります。サーバー環境ではファイル権限、サービスユーザー、作業ディレクトリ、システムルートも影響し、デスクトップ環境ではシステムプロキシが無効、TUN権限が未確認、別のネットワークツールがポートを使用しているといった問題がよくあります。設定を移行する前に、最小限の動作ファイルから始め、ポートと基本ルールが正常であることを確認してから、DNS、ルールプロバイダー、オーバーライドを段階的に追加してください。複雑な設定を一度に読み込むより、問題を特定しやすくなります。
04 / 更新の仕組み
クライアント、コア、サブスクリプション内容、ユーザーのオーバーライドは、それぞれ別に更新される場合があります。クライアント更新後に異常が出たら、まずコアも同時に変わったかを確認します。サブスクリプション更新後にポリシーグループが消えた場合は、リモート設定の内容とローカルオーバーライドの順序を確認してください。ルールセット更新後にアクセス経路が変わった場合は、実際にマッチしたルールを確認します。動作確認済みの基本設定を1つ保管し、複雑な項目はモジュール単位で変更し、変更のたびに設定を再読み込みしてエラー行、ポート使用状況、対象リクエストの結果を確認することをおすすめします。安定したロールバックポイントがあれば、複数の更新が同時に起きた後に最初から推測するのではなく、直近の変更に問題を絞れます。
SOURCE REFERENCE
以下のコマンドは公開ソースリポジトリをクローンするためのものです。実装の確認、コアのビルド、設定項目の動作確認が必要なユーザーに適しています。一般的なデスクトップユーザーは、ダウンロードページからGUIクライアントを選べます。
git clone https://github.com/MetaCubeX/mihomo.git
Configuration notes
記事では実際の設定作業を中心に、多端末同期、Linux導入、異なるコア名称の関係を解説しています。Fake-IP、地域ルーティング、ルール順序を扱う場合は、ブログで詳しい例を確認できます。
サブスクリプションURL、オーバーライドファイル、プライベートリポジトリという3つの同期方法を比較し、認証情報の分離、競合処理、更新順序を解説します。共有に適したルール内容と、各端末に残すべきローカルポート、パス、認証情報を明確に分けます。
記事を読む →デスクトップ環境からGUIのないサーバーまで、設定ディレクトリ、起動コマンド、systemdサービス、端末のプロキシ変数を整理します。ログ、リスニングポート、サービス状態から、起動失敗や設定パスの誤りを切り分ける方法も説明します。
記事を読む →メンテナンス状況、設定項目、ルール機能、クライアント対応の関係から、オリジナルClash、Clash Meta、mihomoという名称の変遷を解説し、設定移行時に優先して確認すべき項目範囲を示します。
記事を読む →