MANUAL

Clash 完全マニュアル

全9章 ・ 順を追って解説 ・ 目次アンカーで参照可能

このページはサイト内で最も情報量の多い長編記事です。「コア概念 → クライアントを選ぶ → インストール → サブスクリプション → プロキシモード → ルールによる振り分け → TUN → 日常メンテナンス → 上級者向けの道筋」の順に章を進め、各章で1つの段階の課題を解決します。10分でプロキシを動かしたいだけなら、まずクイックスタートを読んでください。そちらが最短の操作ルートです。このページはその本線で省略された原理・パラメータ・プラットフォームごとの違いを補うためのもので、設定に不安があるときはいつでも戻って確認してください。インストーラーはインストーラーページから入手し、細かい疑問はよくある質問で確認できます。

01コア概念:コア、クライアント、設定ファイル

Clash はルールベースのネットワークプロキシ方式です。正確には2つの層で構成されています。実際の通信転送を担うコアと、グラフィカルなインターフェースを提供するクライアントです。最初のコアプロジェクトは開発が停止しており、現在エコシステム内で継続的にメンテナンスされているコアは mihomo(コミュニティでは今も Clash Meta コアと呼ばれることが多い)です。既存の設定形式と互換性があり、より多くの伝送プロトコルに対応しています。普段「Clash を入れる」と言うときは、実際には mihomo コアを内蔵したグラフィカルクライアントを入れることを指します。Clash Plus、Clash Verge Rev、FlClash はいずれもこの系統に属し、見た目は異なりますが、内部で読み込む設定形式は同一です。

設定ファイルの構造

コアの全ての動作は1つの YAML 設定ファイルで決まります。その骨格を理解することが、以降すべての章の基礎になります。最小限で動作する設定はおおむね次のような構成です。

mixed-port: 7890        # HTTP と SOCKS を共用するローカル待ち受けポート
allow-lan: false        # LAN内の他デバイスからの接続を許可するか
mode: rule              # 動作モード:rule / global / direct
log-level: info

proxies: []             # ノード一覧。通常はサブスクリプションから生成される
proxy-groups: []        # ポリシーグループ。「どの通信がどのノードを通るか」を決める
rules:
  - MATCH,DIRECT        # ルール一覧。上から順にマッチングする

このうち proxies は利用可能なノードを記述し、proxy-groups はノードを切り替え可能なポリシーグループとしてまとめ、rules は各接続がどのグループに該当するかを決めます。この3つを手動で維持するのは煩雑なので、ほとんどのユーザーはサブスクリプションを利用します。サービス提供者が URL を提供し、クライアントが定期的に取得することで、完成した設定ファイル一式を得られます。サブスクリプションは本質的に「リモートで管理される設定ファイル」であり、これは第4章で詳しく説明します。

ローカルポートとシステムプロキシ

コアが起動すると、本機でポート(デフォルトでよく使われる値は 7890)を待ち受け、アプリケーションが 127.0.0.1:7890 に通信を送ると、コアがルールに従って直接接続かプロキシ転送かを判断します。クライアントの「システムプロキシ」スイッチが行っているのは、OSのプロキシ設定をこのポートに向けることです。「待ち受けポート + システムプロキシ」の関係を理解しておくと、後で「Clash をオンにしたのに効かない」という問題を調査しやすくなります。

その他の用語(ポリシーグループの種類、GEOIP、DNS 振り分けなど)は本文中で最初に登場する箇所でその都度説明します。先に用語を覚える必要はなく、章の順に読み進めれば十分です。

02クライアントを選ぶ:プラットフォーム対照表と推奨順

利用できるクライアントはプラットフォームごとに異なり、機能の重点にも差があります。下表は本サイトのインストーラーページに掲載されているクライアントをプラットフォーム別に並べたもので、ダウンロードページと同じ順序です。

プラットフォームクライアント(推奨順)備考
WindowsClash Plus、Clash Verge Rev、FlClash、Clash NyanpasuClash for Windows はメンテナンス終了、アーカイブとしてのみ残存
macOSClash Plus、Clash Verge Rev、FlClashClashX Meta はメンテナンス終了。既存ユーザーはアーカイブ版を継続利用可
AndroidClash Plus、Clash Meta for Android、FlClash、SurfboardCPUアーキテクチャに合わせて APK を選ぶこと。第3章参照
iOSClash Plus(App Store 配信)公式サイトは clashplus.io。ストアのページ表記を優先すること
LinuxClash Verge Rev、FlClashdeb / rpm パッケージ提供。サーバー用途ではコアを直接動作させることも可能

どう選ぶか

Clash Plus は全プラットフォーム共通の第一選択です。主要な5つのプラットフォームすべてに対応版があり、インターフェースが統一されていて、サブスクリプション導入・ポリシーグループ切替・TUNスイッチなどよく使う機能が見やすい位置にあり、初心者の学習コストが最も低い選択肢です。Clash Verge Rev はデスクトップ版の機能がより充実しており、設定オーバーライド、Merge スクリプト、外部コントロールパネルなど上級機能に対応しているため、細かくカスタマイズしたいユーザーに向いています。本サイトにも Clash Verge Rev 向けの解説記事があります。FlClash は Flutter で構築されており、デスクトップとモバイルで体験が一貫しているため、シンプルな UI を好む場合に選ぶとよいでしょう。Clash Nyanpasu は Windows 版のみで、位置付けは Verge Rev に近いです。

Clash for Windows と ClashX Meta はいずれもメンテナンスが終了しており、新しいプロトコルへの対応やOS互換性の修正は行われません。新規インストールでは選ばないことを推奨します。現在も使い続けているユーザーがプロトコル未対応やOSアップデート後の不具合に遭遇した場合、上表にある現在もメンテナンスされているクライアントへ移行することが唯一確実な対処法です。

クライアントを決めたら、以降の章で説明する操作はクライアントごとに呼び方がやや異なる場合があります(例:「サブスクリプション」「設定」「Profiles」)が、流れは共通です。本マニュアルでは一般的な呼び方で記述し、必要な箇所ではクライアント間の違いを個別に補足します。

03インストール:プラットフォーム別のポイントとよくあるブロック

インストール自体は難しくありませんが、各OSのセキュリティ機構でつまずきやすいです。本章はプラットフォームごとのインストール手順と、対応するブロック解除方法をまとめます。

Windows

インストーラーページから exe インストーラーをダウンロードし、ダブルクリックで実行します。初回実行時に SmartScreen が「Windows によってPCが保護されました」と表示することがありますが、これは未署名またはダウンロード数の少ないプログラムに対する一般的なブロックで、「詳細情報 → 実行」をクリックすれば続行できます。インストール先はデフォルトのままで問題ありません。アンチウイルスソフトがコアファイルを不審として検知した場合は、インストールディレクトリを信頼済みとして追加する必要があります。コアは仮想ネットワークカードとローカルプロキシポートを作成するため、こうした挙動はヒューリスティック検知の誤検知を招きやすいのです。インストール完了後はクライアント設定で「起動時に自動起動」を有効にし、管理者権限で一度実行しておくと、後でTUNモードを有効にする際にスムーズです。

macOS

dmg または zip をダウンロードしたら「アプリケーション」フォルダにドラッグします。チップの種類に注意してください。Apple Silicon 機は arm 版、Intel 機は x64 版を選びます。誤ったバージョンを選ぶと起動できないか、変換レイヤーを経由して動作が遅くなります。初回起動時に「開発元を確認できません」と表示された場合は、「システム設定 → プライバシーとセキュリティ」ページの下部から「このまま開く」を選択してください。「ファイルが破損しています」と表示される場合は、ダウンロードファイルにシステムが隔離属性を付与していることが多く、ターミナルで次のコマンドを実行してから再度開いてください。

xattr -dr com.apple.quarantine /Applications/クライアント名.app

クライアントで初めてシステムプロキシまたはTUNをオンにするとき、システムがヘルパープログラムまたはネットワーク拡張機能のインストールを求めます。案内に従ってパスワードを入力し許可すれば、この操作は一度だけで済みます。

Android

APK をダウンロードする際はCPUアーキテクチャで選択します。近年の主流機種は arm64 版を選び、古い端末やアーキテクチャが不明な場合は universal 汎用パッケージ(サイズは大きいが全アーキテクチャに対応)を選びます。インストール時にシステムが「不明な提供元のアプリのインストールを許可」を求めるので、表示された設定画面でブラウザまたはファイルマネージャーに一度権限を付与すれば十分です。初回プロキシ起動時にVPN接続のリクエストが表示されるので、必ず許可してください。Androidクライアントはシステムの VPN インターフェースを通じて通信を引き継ぐため、このリクエストを拒否するとプロキシが機能しません。一部メーカーのシステムはバックグラウンドアプリを積極的に終了させるため、バッテリー管理でクライアントを「制限なし」に設定し、バックグラウンドをロックしておくことをお勧めします。

iOS

iOS では App Store から Clash Plus をインストールします。ストア内で検索するか、ダウンロードページのストアリンクから直接アクセスしてください。アプリの詳細は公式サイト clashplus.io を参照できます。インストール後、初回のプロキシ起動時にもVPN構成の追加許可が必要になるので、システムのポップアップで確認してください。

Linux

Debian/Ubuntu 系は deb パッケージを使用します:sudo apt install ./パッケージ名.deb。Fedora 系は rpm パッケージを使用します:sudo dnf install ./パッケージ名.rpm。グラフィカルクライアントはデスクトップ環境に依存します。デスクトップのないサーバーでは、mihomo コアを直接デプロイする方が適しています。方法は第9章を参照してください。TUN を有効にするには、プログラムにネットワーク管理権限を付与するか root 権限で実行する必要があります。クライアント設定には通常ワンクリックの権限付与機能が用意されています。

インストール完了の判断基準:クライアントが正常に起動し、メイン画面が表示され、システムトレイまたはステータスバーにアイコンが表示されること。この時点ではまだノードがないので、次章でサブスクリプションを導入して初めて実際にネットへアクセスできるようになります。

04サブスクリプション導入:取得・導入・更新戦略

サブスクリプションリンクはプロキシサービス提供者(いわゆる「機場」)がユーザーパネルで提供するもので、通常「Clash サブスクリプション」または「Clash 設定」と表記されています。コピーする際は、パネルのURLではなく完全なリンクを取得していることを確認してください。一部のサービスは複数の形式を同時に提供しているので、Clash / mihomo 形式を選べば問題ありません。

導入手順

  1. サービスのパネルでサブスクリプションリンクをコピーします。このリンクには認証トークンが含まれており、アカウント情報と同等です。他人に送ったり公開の場に貼ったりしないでください。
  2. クライアントの「サブスクリプション」または「設定」ページを開き、追加/導入をクリックし、リンクを貼り付けて確定します。クライアントはすぐにダウンロードと解析を行い、成功すると一覧にトラフィックと有効期限情報付きの設定項目が表示されます。
  3. その設定項目をクリックして現在使用する設定ファイルとして選択します(一部のクライアントは導入後に自動で選択されます)。「プロキシ」ページに切り替えるとポリシーグループとノード一覧が表示されるはずで、これで解析が成功したことがわかります。

更新設定

サブスクリプションの内容はサービス側のノード調整に伴って変化するため、長期間更新しないとノードが全てタイムアウトすることがあります。クライアント内の更新関連設定は3つあります。更新間隔(12〜24時間ごとの自動取得を推奨)、起動時に更新(クライアントを開くたびにサブスクリプションを一度更新する)、プロキシ経由で更新(サブスクリプションのドメイン自体がブロックされている場合、現在使用可能なノードを経由して取得する)です。この3つの組み合わせ方や典型的なエラー事例は、ブログのサブスクリプション更新失敗の対処法で項目別に解説しています。

導入失敗の切り分け方

導入エラーの原因はおおむね6種類に分類されます。リンクの期限切れまたはトラフィック消費済み、コピーしたのが Clash 形式ではない、サービス側がリクエストのUAを制限している、YAML の内容に文法エラーがある、ローカルネットワークがサブスクリプションのドメインをブロックしている、クライアントのバージョンが古く新しいフィールドを認識できない、のいずれかです。個別の確認方法はサブスクリプション失効・解析失敗チェックリストを参照してください。エラーメッセージに「yaml」「parse」といった文字列が含まれる場合はまず形式の問題を疑い、別のクライアントで交差検証すればリンク側かローカル側の問題かを素早く特定できます。

同じサブスクリプションは複数のクライアントで同時に導入して使用でき、互いに影響しません。ただし多くのサービスはアカウント単位で同時接続デバイス数やIP数を制限しているため、超えると一時的に接続が制限されます。

05プロキシモード:ルール・グローバル・ダイレクト

設定ファイル内の mode フィールドには3つの値があり、それぞれクライアント画面上の3つのモードに対応し、コアが各接続をどう処理するかを決定します。

モード動作適用シーン
rule(ルール)各接続を rules 一覧に従って上から順にマッチングし、該当したルールのポリシーに従う日常的なデフォルト。中国本土のサイトは直接接続、海外サイトはプロキシ経由で、速度と使い勝手を両立できる
global(グローバル)ルールを無視し、全通信を GLOBAL グループで選択したノードに委ねる「ルールが該当していないのでは」という一時的な検証、または短時間全ての通信にプロキシが必要な場合
direct(ダイレクト)ルールを無視し、全通信をノードを経由せず直接送信するクライアントを終了せずに一時的にプロキシを止めたい場合、またはローカルネットワーク自体の状態を確認したい場合

よくある誤りは、グローバルモードを常時使い続けることです。これでは中国本土向けの通信も海外ノードを経由することになり、本土のサービスへのアクセスがむしろ遅くなり、サブスクリプションのトラフィックも無駄に消費します。グローバルモードの正しい使い方は診断ツールとしての利用です。ルールモードでは開けないサイトがグローバルに切り替えたら開けた場合、それはルールが該当していないことを意味し、常用するのではなく第6章に沿ってルールを補うべきです。

システムプロキシと適用範囲

モードを選んだ後は、通信をコアに届ける仕組みも必要です。デスクトップで最もよく使われる入口は「システムプロキシ」スイッチで、これを有効にするとシステムレベルのプロキシ設定がコアの mixed-port を向くようになり、ブラウザや大半のシステムプロキシに従うアプリは自動的にプロキシを経由するようになります。ただしシステムプロキシは「紳士協定」であり、一部のコマンドラインプログラムやシステム設定を読まないソフトウェアはこれを回避します。こうした通信は第7章のTUNモードで引き継ぐ必要があります。ターミナルでは環境変数で手動指定できます。

export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

プロキシが有効か確認する

3ステップで確認します。まずクライアントのノード一覧で遅延テストを行い、選択中のノードがタイムアウトしていないことを確認します。次にIP帰属確認サイトにアクセスし、表示される出口IPがそのノードの地域であることを確認します。最後に目的のサイトを開いて到達できることを確認します。この3ステップはそれぞれ「ノードが使用可能か」「通信が本当にノードを経由しているか」「ルールが正しく該当しているか」を検証するもので、いずれかで失敗すれば問題の範囲を絞り込めます。

06ルールによる振り分け:ポリシーグループとルールの連携

ルールによる振り分けは、Clash を単純なプロキシツールと区別するコア機能で、proxy-groupsrules の2つのセクションが連携して実現します。ポリシーグループは「どの出口を使えるか」、ルールは「どの通信がどのグループを通るか」を決めます。サブスクリプションが生成する設定にはすでに一組の振り分けが組み込まれていますが、本章ではその動作原理を解説し、既存の設定を読み解き必要に応じて変更できるようにします。

よく使われる4種類のポリシーグループ

  • select:手動選択グループ。クライアント画面でクリックして選ぶ、最も一般的な「ノード選択」がこれです。
  • url-test:自動速度測定グループ。設定した間隔でテストURLにリクエストを送り、常に遅延が最も低いノードを選びます。
  • fallback:フェイルオーバーグループ。一覧の順に最初に使用可能なノードを使い、失敗すると次のノードへ自動で切り替わります。
  • load-balance:負荷分散グループ。接続を複数のノードに分散させます。

ルールの文法と優先度

各ルールの形式は「タイプ,マッチ値,対象ポリシー」で、よく使うタイプには DOMAIN-SUFFIX(ドメイン接尾辞)、DOMAIN-KEYWORD(ドメインキーワード)、GEOIP(IPの帰属地域)、IP-CIDR(IP範囲)があり、最後の行には必ず兜底ルールの MATCH を置きます。ルールは上から順にマッチングし、該当したら停止するため、順序がそのまま優先度になります。厳密なドメインルールを前に、GEOIP のようにIPを解決してからでないと判断できないルールを後ろに、最後にMATCHで締めます。典型的な構造を示す例です。

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動テスト
      - DIRECT
  - name: 自動テスト
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 香港ノード
      - 日本ノード
  - name: ストリーミング
    type: select
    proxies:
      - ノード選択
      - 日本ノード

rules:
  - DOMAIN-SUFFIX,netflix.com,ストリーミング
  - DOMAIN-KEYWORD,youtube,ノード選択
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

この例は3層の意図を実現しています。動画配信サービスのドメインは専用の「ストリーミング」グループに任せる(特定地域のノードを固定選択すれば解禁を安定させられる)、cn 接尾辞のドメインおよび中国本土のIPに解決される接続は直接接続する、それ以外の通信は「ノード選択」で兜底する、というものです。グループはグループを参照できるため(「ストリーミング」の中に「ノード選択」を入れている)、設定に階層構造を持たせられ、上流のグループを1箇所変更すればそれを参照している全ての場面に影響が及びます。

地域ごとの振り分けの実践例(動画配信プラットフォームごとに個別グループを作る方法やルール順序の落とし穴を含む)は、ブログのルール振り分け実践:中国本土直結と海外プロキシ経由のグループ設計を参照してください。

サブスクリプションが生成した設定ファイルを直接編集すると、次回の更新で全体が上書きされます。長期的に保持したいカスタムルールは、クライアントの「オーバーライド」または「Merge」機能(Clash Verge Rev の実装が最も充実しています)を使い、変更をサブスクリプション外に宣言することで、更新のたびに自動で重ね合わされるようにします。詳細は第9章を参照してください。

07TUNモード:全通信を引き継ぐ

第5章で触れたように、システムプロキシは全てのプログラムを制御できません。システムプロキシ設定を読まないソフトウェア、一部のゲームクライアント、コマンドラインツールの通信はコアを直接回避してしまいます。TUNモードの解決策は、システム内に仮想ネットワークカードを作成し、デバイスの全ての送信通信をネットワーク層で捕捉してコアに処理させることです。アプリケーションから見れば完全に透過的で、個別にプロキシを設定する必要はありません。Android と iOS クライアントの VPN インターフェースも本質的には同じ考え方であるため、モバイル端末には「TUNをオンにする」という追加の手順はありません。本章は主にデスクトップ向けです。

有効化の手順

  1. 権限を付与する。仮想ネットワークカードの作成には権限の昇格が必要です。Windows は管理者権限でクライアントを実行します(または設定でシステムサービスをインストールし権限昇格を不要にします)。macOS は初回オン時のポップアップに従いネットワーク拡張機能をインストールします。Linux はクライアント設定でコアにワンクリック権限付与を行います。
  2. クライアント設定でTUNスイッチをオンにします。オンにするとシステムのネットワーク接続一覧に utun または Clash という名前を含むネットワークカードが追加され、これが有効化のサインです。
  3. システムプロキシのスイッチをオフにします。TUN はより下位のレイヤーで通信を引き継いでいるため、システムプロキシを重ねても利点がなく、ループバック問題を起こす可能性があります。

DNS設定

TUNモードでは DNS 解決もコアが引き継ぐため、設定ファイルには利用可能な dns セクションが必要です。サブスクリプションが生成する設定には通常含まれており、典型的な形は次の通りです。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query

fake-ip はTUN配下で推奨される拡張モードです。コアはまず予約範囲の仮想IPを返し、実際に接続が確立される時点でドメイン名によるルールマッチングを行うため、実際の解決を1回省略でき、ルールの該当精度も高まります。実際のIPに依存する一部のシナリオ(一部のLANサービス探索など)で異常が出た場合は、該当ドメインに fake-ip-filter の除外設定を行えます。

TUNを有効にすべきかの簡単な判断基準:ブラウザのプロキシは正常だが、あるデスクトッププログラム・ゲーム・端末コマンドがプロキシを経由しない場合はTUNをオンに。ブラウザと通常のアプリだけを使うなら、システムプロキシで十分で複雑さを増やす必要はありません。

08日常メンテナンス:更新・バックアップ・トラブル速見表

設定が一度通ってしまえば、日常的にやることは多くありませんが、いくつかの習慣を持つことで突発的な障害を大幅に減らせます。

3つのものを常に最新に保つ

サブスクリプション:第4章の手順で自動更新間隔を設定し、ノードが広範囲でタイムアウトしている場合はまず手動でサブスクリプションを一度更新してから他の原因を調べます。クライアント:継続メンテナンスされているクライアントはコアやOS互換性の更新に追随し続けるので、インストーラーページで新しいバージョンを取得し上書きインストールすれば、設定とサブスクリプションは失われません。地理データベース:GEOIP ルールは GeoIP/GeoSite のデータファイルに依存し、多くのクライアントは設定にワンクリック更新機能を用意しているので、数か月に1回更新すれば十分です。

何を、どうバックアップするか

バックアップする価値があるのは「サブスクリプションリンク + カスタムオーバーライドの内容」の2つで、これらがあれば新しいデバイスでも数分で環境を復元できます。サブスクリプションが生成する設定ファイル自体はバックアップ不要で、いつでも再取得できます。デスクトップクライアントの設定ディレクトリ(オーバーライドファイルとクライアント設定を含む)は丸ごとコピーして保存しておくことができ、各クライアントの設定ページには通常ディレクトリの場所が表示されています。

ログで問題を特定する

クライアントのログページはリアルタイムで各接続のマッチング結果を出力し、形式はおおむね「ドメイン/IP → 該当したルール → 最終的な出口」です。あるサイトの挙動が期待と異なる場合、ログでそのドメインを検索すれば、どのルールに該当してどのノードを経由したかが即座にわかり、当てずっぽうにノードを切り替えるより効率的です。ログレベルは設定内の log-level で制御され、調査中は一時的に debug に、通常時は info に保つとよいでしょう。

トラブル速見表

症状優先的に確認すべき点
全ノードの遅延テストがタイムアウトするサブスクリプションが期限切れ/トラフィック消費済みか、ローカルネットワークが直接接続できるか、サブスクリプション更新後に再テスト
ノードの遅延は正常だがサイトが開けないグローバルモードに切り替えてルールが該当していないか検証、システムプロキシまたはTUNがオンか確認
中国本土のサイトが遅くなった誤ってグローバルモードのままになっていないか、GEOIP,CN,DIRECT ルールが存在し前段のルールに横取りされていないか
サブスクリプション更新でエラーが出る第4章の3つの更新スイッチに沿って確認、または「プロキシ経由で更新」を先に有効にして再試行
起動後プロキシが効かないクライアントが自動起動に設定されているか、システムプロキシ/TUNが起動時に有効になる設定か

この表で網羅していない問題はよくある質問ページに分類整理されているので、まずそちらで検索してください。

09上級者向けの道筋:使えるから使いこなすへ

ここまでの8章を終えれば、日常的な利用に支障はなくなります。以下は実用性の高い順に並べた発展方向で、必要に応じて掘り進めてください。

LAN共有

設定内の allow-lantrue に設定すれば(クライアント画面には通常対応するスイッチがあります)、同じLAN内のスマホ・テレビ・ゲーム機などがこのPCのLAN内IPと mixed-port のポートをプロキシアドレスとして入力するだけで、同一のプロキシとルールを共用できます。各デバイスに個別にクライアントを入れる必要はありません。ファイアウォールの許可や各種デバイスへの設定方法は、ブログの混合ポートとLAN共有の設定を参照してください。

オーバーライドとMerge

第6章で触れたように、サブスクリプションの設定を直接編集すると更新で上書きされてしまいます。オーバーライド機能は、あなたの変更(ルールの追加、DNSセクションの置き換え、ポートの調整)を独立したファイルとして書き出し、クライアントがサブスクリプションを読み込むたびに自動で重ね合わせることで、「サブスクリプションは通常通り更新され、カスタム設定は永続的に有効」を実現します。Clash Verge Rev の実装が最も充実しており、YAMLマージとスクリプトの2つの方式に対応しています。まずはシンプルなケースから練習するのがおすすめです。例えば、サブスクリプションでカバーされていないドメインに DOMAIN-SUFFIX ルールを1つ追加してみましょう。

外部コントロールインターフェース

コアには RESTful のコントロールインターフェースが内蔵されており、設定に external-controller: 127.0.0.1:9090 を宣言すれば、HTTPリクエストでコアを照会・制御できます。Web版のコントロールパネルもこれを利用して実装されています。例えば現在の全ポリシーグループを照会するには次の通りです。

curl http://127.0.0.1:9090/proxies

スクリプトと組み合わせれば、定時でのノード切替や自動速度測定の統計など、開発の基礎知識があるユーザーに向いた活用ができます。

GUIなしでコアをデプロイする

ルーターやサーバー用途ではグラフィカルクライアントは不要で、mihomo コアを直接実行します。ダウンロードページのコア配布セクションから対応アーキテクチャのバイナリを取得し、完全なYAMLを用意し、systemd でプロセスを管理すれば、ネットワーク全体に透過的なプロキシを提供できます。この方法はルーティングと iptables/nftables の知識が必要になるため、デスクトップでルール体系を十分理解した後に挑戦することをお勧めします。

次に読むもの

実際の操作はクイックスタートに戻って本線に沿って進めてください。概念の見落としがあればよくある質問を活用し、ブログの初心者向け10の質問に即答はこのマニュアルのダイジェスト版として、入門したばかりの人に共有するのに適しています。クライアントとコアは継続的に進化しているため、このページもエコシステムの変化に合わせて更新していく予定です。ブックマークしていつでも参照してください。

クライアントをダウンロード