Clash設定ファイル構造を徹底解説:port、dnsからrulesまで各セクションの役割
設定ファイルを上から順に読み解きながら、共通フィールド、proxies、proxy-groups、rulesの役割分担を解説し、最小構成のサンプルで各セクションの連携を示します。
全文を読む →オープンソースエコシステム · 5プラットフォーム対応インストーラーとドキュメントを継続更新
Windows / macOS / Android / iOS / Linux 各プラットフォーム向けClashクライアントのインストーラーを収録し、日本語チュートリアル、YAML設定マニュアル、トラブル対処索引を用意しています。インストールからサブスクリプション導入、ルール分流の調整まで、ダウンロードと情報収集を同じサイト内で完結できます。
左側で機能項目を選ぶと、右側に説明と対応する設定スニペットが表示されます。各項目の完全なフィールド仕様はYAMLマニュアルに収録しています。
ルールルーティングは、Clashを一般的なグローバルプロキシと区別する中核メカニズムです。すべてのネットワークリクエストは rules リストの上から順に照合され、一致した時点で指定された出口——直接接続、プロキシ経由、または拒否——に振り分けられます。マッチング条件はドメインサフィックス、ドメインキーワード、IPの所属地域、プロセス名、ポート番号までカバーし、ブラウザ・ゲーム・ダウンローダーをそれぞれ別の経路に振り分けられる粒度です。ブラウザ拡張でサイトごとに手動切り替えするのに比べ、ルールを設定ファイルに書き込めばシステム全体に適用され、デバイスを変えても同じYAMLを持っていくだけで済みます。ルール記法の完全な一覧はサイト内のYAMLマニュアルに収録しています。
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
プロキシグループは複数のノードを1つの切り替え可能な出口としてまとめ、rules はグループ名だけを参照するため、グループ内の具体的なサーバーを意識する必要がありません。url-test グループは設定した間隔でテストURLにリクエストを送り、遅延が最も低いノードを自動的に選択します。fallback グループは並び順に従って最初に利用可能なノードを採用するため主副線の構成に向いています。select グループは手動選択を維持し、relay グループはチェーン転送に対応します。これらの種類は互相にネストできるため、まず地域でグループ化し、グループ内でさらに自動速度テストを行う構成が、サブスクリプションのノード数が多い場合の最も一般的な組み方です。
proxy-groups:
- name: AUTO
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
proxies: [HK-01, JP-01, SG-01]
システムプロキシは、プロキシ設定を積極的に読み取るアプリケーションにのみ有効で、コマンドラインツールやゲームクライアント、多くのデスクトップソフトはそのまま迂回してしまいます。TUNモードはシステム内に仮想ネットワークカードを作成し、全トラフィックをネットワーク層で捕捉してカーネルにルール処理させるため、アプリ側の対応状況に依存しません。有効化する際は通常、名前解決待ちを減らすためfake-ipのDNSモードと組み合わせます。初回有効化には管理者権限またはroot権限が必要で、Windowsでは仮想ネットワークカードのドライバーコンポーネントのインストールも必要です。具体的な手順はチュートリアルページの該当章をご覧ください。
tun:
enable: true
stack: system
auto-route: true
dns-hijack:
- any:53
サブスクリプションとは、サービス提供者がノードリストをまとめた1本のURLのことで、クライアントが定期的に取得するだけで最新のノードに同期でき、サーバーパラメータを手打ちする必要がありません。設定ファイルでは、proxy-providers によってサブスクリプションを外部リソースとして宣言し、更新間隔やローカルキャッシュパス、ヘルスチェックをカスタマイズできるほか、複数のサブスクリプションを同時に読み込んで相互バックアップにすることもできます。形式が非対応のサブスクリプションに遭遇した場合は、サブスクリプション変換サービスを利用すればBase64、Clash YAML、sing-boxなどの形式間で相互変換できます。具体的な方法はサイト内の技術ノートで詳しく解説しています。
proxy-providers:
main:
type: http
url: https://example.com/sub.yaml
interval: 86400
path: ./providers/main.yaml
GEOIPとGEOSITEという2種類のルールの背後には、それぞれ独立して更新できる2つのデータベースがあります。前者はIPの所属地域でマッチングし、特定地域のトラフィックを直接接続させる用途によく使われます。後者は用途別に分類されたドメインリストを収録しており、GEOSITE,category-ads の1行だけで数千件に及ぶ手書きの広告ドメインルールを代替でき、設定を簡潔に保てます。データベースファイルは手動でダウンロードして置き換えることもできますし、設定内にミラーアドレスと更新間隔を宣言してカーネルに定期的に自動取得させることもできます。各ディストリビューションの違いや更新方法の書き方は、技術ノートの比較記事をご覧ください。
geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
インストーラーはOSごとにグループ化されており、プラットフォームカードをクリックするとダウンロードページの該当タブに直接移動します。バージョン番号はダウンロードページでリアルタイムに取得され、各プロジェクトの最新正式版に対応します。
インストールから接続確認まで、通常10分以内で完了します。各ステップの詳細説明とスクリーンショット付きガイドはチュートリアルページに掲載しています。
ダウンロードページで使用中のOSに対応したインストーラーを選び、インストール完了後にクライアントを起動して、サービス提供者から発行されたサブスクリプションリンクを「設定 / Profiles」ページに貼り付けて読み込みます。クライアントがノードリストを取得して設定ファイルを生成し、リストにノードが表示されれば導入成功です。
動作モードを「ルール / Rule」に設定し、設定内のrulesに従ってトラフィックを自動振り分けさせます。次にプロキシグループから遅延の低いノードを選ぶか、自動速度テストグループを使ってクライアントに判断させます。グローバルモードと直接接続モードは、トラブル対応時に一時的に使う程度にとどめてください。
クライアントの「システムプロキシ」スイッチをオンにし、これまで開けなかったサイトにアクセスして接続を確認します。コマンドラインやゲームなどシステムプロキシを経由しないアプリを対応させたい場合は、チュートリアルに従ってTUNモードを有効にしてください。確認に失敗した場合は、チュートリアルページ末尾のチェックリストを順に確認してください。
本サイトに掲載しているクライアントはすべて公開リポジトリに由来し、ソースコード・Issue・リリース履歴はホスティングプラットフォーム上で個別に確認できます。
Clashはもともとgo言語で書かれたルールベースのプロキシカーネルで、明快なYAML設定形式と柔軟な振り分けルールによって完成度の高いオープンソースエコシステムを形成しました。オリジナルのリポジトリがメンテナンスを終了した後、コミュニティのフォークであるClash Metaが開発を継続し、mihomoへと改称。より多くのプロトコルとルールタイプを補完し、現在では各GUIクライアントで使われる共通カーネルとなっています。
Clash Verge Rev、FlClash、Clash Nyanpasuなどのグラフィカルクライアントはいずれもmihomo上に構築されており、それぞれ独自のリリース周期とUIスタイルを維持しています。設定形式は相互に互換性があり、同じYAMLファイルをクライアント間で使い回してもほとんど変更は不要です。本サイトは固定リストに基づいて各プロジェクトの正式版リリースを追跡し、ダウンロードページのバージョン番号はバージョンリストからリアルタイムに取得することで、アップストリームのリリースと同期を保っています。
サーバーやルーター上でカーネルを直接実行したい、あるいは実装の詳細を読みたいユーザーは、mihomoリポジトリをクローンして自分でビルドできます。Issueやコミット履歴は、カーネルレベルの問題を調査する際に最も直接的な一次情報です。
git clone https://github.com/MetaCubeX/mihomo.git
リポジトリはGPL-3.0ライセンスで公開されており、数千個のスターと継続的なコミット履歴はホスティングプラットフォーム上で公開確認できます。一般利用者は自分でビルドする必要はなく、ダウンロードページのビルド済みパッケージをそのまま使用すれば十分です。
頻出する4つの質問への一言結論です。詳しい回答や他の項目はFAQページと基礎知識ページをご覧ください。
設定構造、データベース更新、トラブル対処をテーマにした長文記事を公開日時の新しい順に掲載しています。
設定ファイルを上から順に読み解きながら、共通フィールド、proxies、proxy-groups、rulesの役割分担を解説し、最小構成のサンプルで各セクションの連携を示します。
全文を読む →証明書エラーの原因をカテゴリ別に整理し、システム時刻のズレ、ノードによるハイジャック、TUNモードでのDNS汚染へのフォールバック、ローカルのパケットキャプチャソフトが残した証明書などを説明。優先度に沿った対処手順も示します。
全文を読む →URLテストの全体的な仕組みと測定対象を分解し、ハンドシェイク方式・テストURL・キャッシュが結果に与える影響を説明。低遅延が高帯域幅を意味しない理由を解説し、実際の体感に近いノード選びの方法を紹介します。
全文を読む →