MANUAL

Clash 全プラットフォーム インストール設定完全ガイド

Windows、macOS、Android、iOS、Linuxをそれぞれ1章で解説。ダウンロード・インストールから購読インポート、システムプロキシ・TUNモードまで手順を網羅し、注意点も個別に整理した。本ページはリファレンス用の完全マニュアルであり、最短ルートで初回接続を完了したい場合はまずスタートガイドを参照し、具体的な問題に当たったら本ページの該当章に戻ってほしい。

共通の事前準備

どのプラットフォームを使う場合でも、初回設定の前に確認すべきことは3つある。クライアントを決める、購読リンクを入手する、設定ファイルの基本構造を理解する、の3点だ。これはすべてのプラットフォームで共通なので、本章でまとめて説明し、以降の各プラットフォーム章では繰り返さない。

クライアントを決める

Clashはオープンソースのエコシステムであり、同じ設定ファイルを異なるクライアント間で共通利用できる。各プラットフォームの推奨構成は以下の通り。インストーラーはダウンロードページからまとめて入手できる。各クライアントの詳しい違いはブログ記事主要Clashクライアント比較を参照。

プラットフォーム推奨代替補足
WindowsClash PlusClash Verge Rev、FlClash、Clash NyanpasuClash for Windowsは開発終了、アーカイブとしてのみ存在
macOSClash PlusClash Verge Rev、FlClashClashX Metaは開発終了、アーカイブとしてのみ存在
AndroidClash PlusClash Meta for Android、FlClash、Surfboardarm64とarmv7のインストーラーを区別すること
iOSClash Plus(App Store)公式サイトはclashplus.io、ストアから直接インストール
LinuxClash Verge RevFlClashdebパッケージを提供、サーバー用途ではMihomoコアを直接実行可能

購読リンク

購読リンクはHTTP(S)形式のアドレスで、サービス提供元から発行され、Clashが解析できるノードとルールの一覧を含んでいる。クライアントは一定間隔でこのアドレスを取得し、自動的にノード情報を更新する。準備段階で確認すべき点は2つ。1つ目はリンクが完全であること――https://で始まり、チャットアプリによって途中で切断されたり改行が挿入されたりしていないこと。2つ目はリンクが機密情報であること――入手した人は誰でもトラフィック容量を使えてしまうため、公開グループへの投稿やスクリーンショットの流出は避けること。リンクが失効している場合や形式が合わない場合の症状と対処は設定トラブルの章を参照。

設定ファイルの基本構造

Clashの設定ファイルはYAML形式の文書で、通常は購読によって生成される。その骨格を理解しておくと後のトラブル対処に役立つ。中心となるフィールドは5つ:入力ポート、動作モード、ノードリスト、ポリシーグループ、ルール。最小限の読みやすい例を以下に示す:

mixed-port: 7890          # HTTPとSOCKSで共用する入力ポート
allow-lan: false          # LAN内デバイスの接続を許可するか
mode: rule                # rule / global / direct
log-level: info
external-controller: 127.0.0.1:9090

proxies: []               # ノードリスト、購読から自動入力される

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ルールは上から順に照合され、マッチした時点で処理が止まる。MATCHはすべてに当たらなかった場合の受け皿ルールなので必ず最後に置く。ポリシーグループのselecturl-testfallbackなどの種類ごとの挙動はブログ記事ポリシーグループの種類を徹底解説を参照。各フィールドの用語説明は用語クイックリファレンスで確認できる。

システムプロキシとTUNモード

クライアントを起動しただけでは、ローカルにプロキシポートが開かれるだけでトラフィックは自動的には流れ込まない。トラフィックを流し込む方法は2つ:システムプロキシとTUNモードだ。システムプロキシはOSのHTTP/SOCKSプロキシ設定をローカルポートに向ける方式で、実装は簡単だが、システムプロキシ設定を尊重するアプリにしか効かない。TUNモードは仮想ネットワークカードを作成し、ネットワーク層でトラフィックをすべて引き受ける方式で、システムプロキシを経由しないコマンドラインツールやゲームクライアントもカバーできるが、より高いシステム権限が必要になる。

選び方の目安

普段のブラウザや一般的なアプリならシステムプロキシで十分だ。コマンドラインツールやゲーム、システムプロキシ設定を読み取らないソフトを引き受けたい場合にTUNモードを有効にする。両方を同時に有効化する意味はなく、通常はクライアント側が排他制御を自動で行う。

3つの動作モード

設定内のmodeフィールドがルールエンジンの動作を決める。ruleはルールモードで、ルールリストに沿って1件ずつ振り分ける、日常使いのデフォルト。globalはグローバルモードで、すべてのトラフィックが同じポリシーグループを通る、ノードの一時的なテストに使う。directは直結モードで、すべてのトラフィックがプロキシを経由しない、「問題がプロキシに起因するかどうか」を調べるのに使う。トラブル対処の際は3つのモードを切り替えて比較するのが、問題箇所を特定する最も速い手段の一つだ。

Windowsのインストールと設定

ダウンロードとインストール

ダウンロードページのWindowsセクションからClash Plusのインストーラーを入手する。システム要件はWindows 10 64bit以上。インストーラーを実行すると、SmartScreenが「WindowsによってPCが保護されました」と表示する場合がある――これは商用のコード署名証明書を購入していないオープンソースソフトウェアではよくあることで、「詳細情報」→「実行」の順にクリックすれば続行できる。インストール先は既定のままにするのが望ましい。展開版(ポータブル版)を使う場合は、管理者権限が必要なディレクトリ(C:\Program Files配下などに手動で展開)には置かないこと。そうしないと設定の書き込みに失敗する。

購読のインポートと初回接続

初回起動後、購読(または「設定」)ページに入り、購読リンクを貼り付けてインポートをクリックする。クライアントが設定をダウンロードし、ノードリストを表示する。プロキシページに切り替え、「ノード選択」ポリシーグループから1つノードを選んでから、メイン画面に戻って「システムプロキシ」スイッチをオンにする。この状態でブラウザを開き、ルール内のサイトにアクセスして正常に表示されれば経路は問題ない。ノードがすべてタイムアウト表示になる場合は、ブログ記事ノードタイムアウトの調査順序にある5段階を順に確認する。

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

「システムプロキシ」スイッチの実体は、Windowsの設定 → ネットワークとインターネット → プロキシにあるアドレスを127.0.0.1:7890(ポートはクライアントの設定に従う)に書き換える処理だ。スイッチをオンにしてもプロキシ設定が反映されない場合、まずポートが他のプログラムに使われていないか確認する:

netstat -ano | findstr "7890"

出力に別のプロセスがすでにそのポートを監視していると表示された場合、クライアントの設定でmixed-portを7891など空いている値に変更し、クライアントを再起動してからシステムプロキシを再度オンにする。複数のプロキシソフトを同時に動かすとシステムプロキシ設定を互いに書き換え合うため、必ず1つだけを起動しておくこと。

TUNモードとサービスモード

Windowsで仮想ネットワークカードを作成するには管理者権限が必要になる。Clash Verge Revなどのクライアントは「サービスモード」を提供しており、システムと共に動作するバックグラウンドサービスをインストールすることで、以後TUNのオン・オフの都度UAC承認を求められることがなくなる。設定場所は通常「設定 → サービスモード → インストール」。サービスをインストールしたらTUNスイッチをオンにし、「設定 → ネットワーク接続」に新しい仮想ネットワークカードが表示されていれば有効化されている。TUNを有効にした後はシステムプロキシのスイッチをオフにして、トラフィックが二重にプロキシを経由しないようにするのが望ましい。

自動起動

クライアントの設定には通常「自動起動」と「サイレント起動」という2つのスイッチがある。前者はスタートアップ項目を登録し、後者は起動時にメインウィンドウを表示せず直接タスクトレイに常駐する。両方をオンにし、デフォルトで選択される購読と組み合わせれば、起動時に前回のプロキシ状態を手動操作なしで復元できる。自動起動が失敗する場合は、タスクマネージャー → スタートアップアプリでこの項目が無効化されていないか確認する。

プラットフォーム固有の問題

  • UWPアプリ(Microsoft Storeからインストールしたアプリ)は既定でローカルプロキシへのループバックが許可されておらず、一部のクライアントは「UWPループバック免除」ツールを提供している。対象アプリにチェックを入れると有効になる。
  • 初回起動時に表示されるWindowsファイアウォールの確認では「プライベートネットワーク」にチェックを入れて許可する。そうしないとallow-lanを使う場面でLAN内デバイスが接続できない。
  • 古いプロキシソフトをアンインストールした後、システムプロキシ設定に無効なポートが残っていることがあり、「ネットが切れる」症状として現れる。システムプロキシ設定で手動でオフにすれば復旧する。

macOSのインストールと設定

チップアーキテクチャの確認

左上のAppleメニュー → このMacについてをクリックする。チップの項目にApple M系列と表示されていればApple Silicon(arm64)版を、Intelと表示されていればIntel(x64)版をダウンロードする。アーキテクチャを間違えたパッケージはApple Silicon上でRosetta変換を経て動作するため使えないわけではないが、性能と消費電力が一段階落ちるので、正しい方を入れることを推奨する。インストーラーはダウンロードページのmacOSセクションにアーキテクチャ別に用意されている。

インストールと初回起動

dmgイメージを開き、アプリのアイコンをApplicationsフォルダにドラッグする。Launchpadまたはアプリケーションフォルダから起動する。初回起動時に「開発者を確認できません」と表示された場合は、システム設定 → プライバシーとセキュリティに移動し、画面下部にあるこのアプリの通知から「このまま開く」をクリックする。あるいはFinderでアプリのアイコンを右クリックして「開く」を選び、一度確認すれば以降はダブルクリックで通常起動できる。

権限の許可:ネットワーク拡張とキーチェーン

macOS版クライアントは初回実行時に2〜3個の許可ダイアログが連続して表示される。それぞれ正しく処理しないと機能が不完全になる:

  1. ネットワーク拡張/プロキシ設定のダイアログ:「許可」をクリックする。これはシステムプロキシとTUNを設定する前提条件で、拒否するとクライアントはローカルポートの提供しかできなくなる。
  2. キーチェーンアクセスのダイアログ:ログインパスワードを入力した後は「常に許可」をクリックする。「許可」をクリックすると起動するたびに同じダイアログが繰り返し表示される。
  3. 一部のクライアントは特権ヘルパー(Helper)のインストールも求めてくる。同様にパスワードを入力して1回確認すればよい。

誤って拒否してしまっても後から修正できる:システム設定 → ネットワーク → VPNとフィルタ、およびプライバシーとセキュリティ → フルディスクアクセスに移動し、クライアントに手動で権限を再付与する。ダイアログのスクリーンショットと項目別の解説はブログ記事macOSでのClashクライアント権限設定を徹底解説を参照。

システムプロキシと動作確認

購読をインポートしてノードを選んだら、クライアントの「システムプロキシに設定」スイッチをオンにする。実際にシステム設定へ書き込まれたかを確認するには、ターミナルで次を実行する:

networksetup -getwebproxy Wi-Fi

出力がEnabled: Yesで、ポート番号がクライアントの設定と一致していれば有効になっている。macOSのプロキシ設定はネットワークサービスごとに個別に保存される点に注意――Wi-Fiと有線イーサネットは別々の設定であり、ネットワークインターフェースを切り替えた後にプロキシが効かなくなった場合は、クライアントが一方のサービスにしか書き込んでいないことが多い。システムプロキシのスイッチを一度オフオンし直せば直る。

TUNモード

macOSでTUNを有効にするには、システム拡張の承認、または特権ヘルパーによる仮想ネットワークカード作成が必要で、初めてTUNスイッチをオンにすると再度許可ダイアログが表示される。有効化後、ターミナルでifconfig | grep utunを実行すると新しく追加されたutunインターフェースが確認できる。Windowsと同様、TUN有効時はシステムプロキシのスイッチをオフにして二重プロキシを避ける。

プラットフォーム固有の問題

  • OSのメジャーアップデート後、ネットワーク拡張の許可がリセットされることがあり、クライアントは正常に動作しているのにトラフィックがプロキシを通らない症状になる。許可の手順を最初からやり直せば解決する。
  • クライアントが異常終了してシステムプロキシがリセットされないと、「ソフトを終了したらむしろネットが切れる」症状になる。システム設定 → ネットワーク → 対象のサービス → 詳細 → プロキシで手動でチェックを外せば直る。
  • 複数のClashクライアントをインストールしている場合、同時に起動しないこと。システムプロキシが何度も書き換えられ、動作が予測できなくなる。

Androidのインストールと設定

インストーラーのアーキテクチャを選ぶ

近年の主流機種はarm64-v8a版を選べばよい。armeabi-v7a版が必要なのは一部の古い機種や入門機種のみ。判断がつかない場合はまずarm64版を入れてみて、「パッケージの解析エラー」や「アプリがインストールされていません」と表示されたらv7a版に切り替える。Clash Meta for Androidはuniversal版(汎用パッケージ)も提供しており、サイズは大きくなるが選択の手間がない。インストーラーはダウンロードページのAndroidセクションにアーキテクチャ別に用意されている。

インストールと購読のインポート

ブラウザでAPKをダウンロードしてインストールすると、システムが「不明なソースからのアプリのインストールを許可」を求めてくる。表示された設定ページでブラウザ(またはファイル管理アプリ)にこの権限を付与し、戻ってインストールを続行する。クライアントを初回起動したら、設定/購読ページに入り、新規設定を作成して購読リンクを貼り付ける。保存するとクライアントが自動的にダウンロード・解析する。リストにノードが表示されればインポート成功だ。

VPN権限の許可と接続

Android版クライアントはシステムのVpnServiceを通じてトラフィックを引き受ける。初めて接続をタップすると「接続のリクエスト」ダイアログが表示され、VPN接続を作成することが説明される。「OK」をタップする。この許可は一度だけで、ステータスバーに鍵アイコンが表示されれば有効化されている。以降の接続・切断はクライアントのメイン画面でワンタップで完了する。Androidには独立した「システムプロキシ」スイッチはなく、VpnService自体がデスクトップ版のTUNモードに相当する。

バックグラウンド維持とバッテリー最適化

各メーカーの独自カスタムOSはバックグラウンドプロセスの管理が厳しく、Androidで「使っているうちに切断される」原因の第一位になっている。個別に対処する:

  • システム設定 → バッテリーでクライアントを見つけ、バッテリー最適化のポリシーを「制限なし」または「最適化しない」に変更する。
  • 「自動起動管理」機能があるOS(MIUI、EMUIなど)では、クライアントに自動起動の許可を与える。
  • 最近使用したアプリの画面でクライアントをロックする(下にスワイプまたはカードを長押し、メーカーによって操作は異なる)。これでワンタップクリーンアップで終了させられるのを防げる。

アプリ単位のプロキシ

クライアントのネットワーク設定にある「アクセス制御」はアプリ単位でのトラフィック振り分けに対応している。ホワイトリストモードではチェックを入れたアプリだけがプロキシを通り、ブラックリストモードではチェックを入れたアプリがプロキシを通らない。銀行系アプリはプロキシ環境に敏感なので、ブラックリストに入れることで不正利用判定の誤検知を避けられる。ゲームをブラックリストに入れれば不要な遅延を減らせる。アプリ単位のリストを変更した後は、一度切断・再接続して初めて反映される。

プラットフォーム固有の問題

  • システムの「プライベートDNS」(設定 → ネットワーク → プライベートDNS)を特定のプロバイダに固定すると、DNSクエリがクライアントのfake-ip機構を回避してしまい、一部のルールが効かなくなる。「自動」に変更するか、オフにすることを推奨する。
  • Androidは同時に1つのVPN接続しか許可しないため、他のVPN系アプリと相互に切断し合うのはシステムの仕様であり故障ではない。
  • データ節約モードとVPNを併用すると一部の機種でバックグラウンドトラフィックが制限される。異常が起きた場合はまずシステムの省電力・データ節約設定を確認する。

iOSのインストールと設定

App Storeからのインストール

iOSではClash Plusを使用し、App Storeから直接インストールする:ストア内でClash Plusを検索するか、ダウンロードページのiOSセクションからストアの詳細ページに移動する。公式サイトはclashplus.ioで、機能説明と更新履歴は公式サイトを正とする。iPhoneとiPadで共通のバージョンを使う。

購読のインポート

アプリを開き、購読/設定ページに入って追加をタップし、購読リンクを貼り付けて保存する。一部のバージョンではクリップボードを読み取っての高速インポートに対応している:先にリンクをコピーしてからアプリを開き、表示に従って確認すればよい。インポートが完了するとプロキシページにノードリストが表示されるので、1つを選んで現在の出口とする。

VPN設定と許可

初めて接続をタップすると、システムが「"Clash Plus"がVPN構成を追加しようとしています」と表示する。「許可」をタップし、画面ロックのパスコードまたはFace IDで認証する。許可が済むと、システムは 設定 → 一般 → VPNとデバイス管理 → VPN に対応する項目を生成し、ステータスバーにVPNマークが表示されれば接続成功だ。以降の接続・切断はアプリ内で操作することもできるし、システム設定のVPNスイッチを直接操作することもでき、両方の状態は同期している。

利用上のポイント

  • 購読を切り替えたり設定を大きく変更した後は、一度切断してから再接続することで新しい設定を完全に反映させる。
  • システムによってアプリがバックグラウンドから終了させられても、VPNトンネル自体は通常システムのネットワーク拡張によって維持される。切断を確認した場合はアプリ内で再接続すればよい。
  • ルールモードやポリシーグループなどの概念はデスクトップ版と完全に共通しているため、本ページの事前準備の章と用語クイックリファレンスにある共通の設定知識をそのまま適用できる。

Linuxのインストールと設定

クライアントのインストール

デスクトップ環境ではClash Verge Revを推奨し、debとrpmパッケージを提供している。FlClashはdebパッケージを提供している。インストーラーはダウンロードページのLinuxセクションから入手し、システムのパッケージ管理ツールでインストールすると依存関係を自動解決できる:

# Debian / Ubuntu 系
sudo apt install ./clash-verge-rev_amd64.deb

# Fedora / RHEL 系
sudo dnf install ./clash-verge-rev_x86_64.rpm

インストール時にlibwebkit2gtkなどの依存関係が不足していると表示された場合は、まずsudo apt updateを実行してから再試行する。apt install ./パッケージ名という書き方(./付き)であれば依存関係もまとめて処理されるため、dpkg -iより手間が少ない。

デスクトップ環境のシステムプロキシ

Linuxの「システムプロキシ」はデスクトップ環境ごとに個別実装されている。GNOMEでは設定 → ネットワーク → ネットワークプロキシで「手動」を選び、HTTP/HTTPSに127.0.0.1:7890を入力する。Socksホストも同様。KDEではシステム設定 → ネットワーク設定 → プロキシで設定する。クライアントのシステムプロキシスイッチは通常GNOME/KDEにしか効かないため、他のデスクトップ環境や純粋なターミナル環境では環境変数を使う:

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

~/.bashrcまたは~/.zshrcに書き込めば長期的に有効になる。環境変数はそれを読み取るプログラムにしか影響しない点に注意――ブラウザの多くはデスクトップ環境の設定を読み取り、環境変数は読み取らない。

TUNモードと権限

TUNデバイスの作成にはroot権限、または対応するcapabilityが必要になる。Clash Verge Revはサービスモードを提供しており、システムサービスをインストールするとサービスプロセスが特権でネットワークカードを作成し、アプリ本体は一般権限のまま動作する。クライアントの設定でサービスをインストールし、TUNスイッチをオンにすればよい。手動でコアを実行する場合は、バイナリにcapabilityビットを付与すれば一般ユーザーでも実行できる:

sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo

サーバー用途:Mihomoコアを直接実行する

GUIのないサーバーやルーターの場合はGUIを必要とせず、Mihomoコアを直接実行する。コアのバイナリを/usr/local/bin/mihomoに置き、設定を/etc/mihomo/config.yamlに置いて、systemdで管理する:

[Unit]
Description=Mihomo core
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure

[Install]
WantedBy=multi-user.target

/etc/systemd/system/mihomo.serviceとして保存し、sudo systemctl enable --now mihomoを実行して起動と自動起動設定を行う。ログはjournalctl -u mihomo -fでリアルタイムに確認できる。設定内でexternal-controllerを有効にすれば、任意のClashパネルからリモート管理できる。コアの各アーキテクチャ向けパッケージもダウンロードページのコアセクションにある。

プラットフォーム固有の問題

  • ディストリビューション標準のsystemd-resolvedが53番ポートを監視しており、設定内のdns.listenで53を指定する書き方と衝突する。ClashのDNS監視ポートを1053など別のポートに変更するか、resolvedの設定を調整する。
  • ファイアウォール(ufw/firewalld)が有効な場合、allow-lanを使うには対応するポートを開放する必要がある。そうしないとLAN内デバイスが接続できない。
  • Waylandセッションでは一部のクライアントのトレイアイコンが表示されないことがあるが、機能には影響しない。アプリメニューからメインウィンドウを再度呼び出せばよい。

設定トラブル

購読のインポートに失敗する

次の順に確認する:リンクが完全であるか、改行やスペースで途切れていないか。ブラウザで直接そのリンクを開いてテキスト内容がダウンロードできればリンク自体には到達できている。ダウンロードした内容がYAMLではなく別の形式だった場合、その購読はClash形式ではないことを意味するので、サービス提供元で出力形式を切り替えるか、購読変換サービスを一度経由させる。一部の購読サーバーはリクエストのUser-Agentを検証しているため、別のクライアントでインポートするか、クライアント設定でUAを変更すれば回避できる。

ノードがすべてタイムアウトする

ノードが全部赤表示になっても、必ずしもノードが無効になったわけではなく、多くはローカル側の経路の問題だ。確認する順序は固定で5段階:購読が期限切れか → ローカルポートが使用中か → システムプロキシのスイッチが本当に有効になっているか → ノードのプロトコルとコアが対応しているか → DNSが汚染されていないか。各段階の判断方法と対処法は、ブログ記事ノードタイムアウトの調査順序で詳しく展開している。

ルールが効かない

最もよくある原因は3つ、発生確率の高い順に並べると:1つ目はmoderuleになっていないケース――グローバルモードや直結モードではルールリストが判定に一切関与しない。2つ目はルールの順序の問題――照合は上から順に行われマッチした時点で止まるため、カスタムルールをより広い範囲にマッチするルールの後に書いてしまうと永遠に順番が来ない。3つ目は対象のトラフィックがDNSで解決済みのIPで流れているケース――DOMAIN系のルールにマッチしないため、IP-CIDRルールを追加するかfake-ipを有効にする必要がある。ルールを変更したら設定の再読み込みを忘れないこと。

DNSとfake-ip

DNS汚染はドメイン名が間違ったIPに解決されることを引き起こし、「ノードは使えるのに一部のサイトだけ開けない」という症状として現れる。fake-ip拡張モードの有効化を推奨する:クライアントがまず予約されたアドレス帯の仮のIPを返し、実際の解決はプロキシ経路上で行うことで、根本からローカルの汚染を回避できる。設定例:

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

fake-ipモードでは、実際のIPに依存する一部のアプリ(LAN内デバイス検出、一部のゲームなど)について、fake-ip-filterに該当するドメインを列挙して本来のIP解決を使わせることができる。関連する用語の説明は用語クイックリファレンスの「ネットワークとDNS」カテゴリを参照。

ポートの競合

既定の入力ポート7890が他のプログラムに使われていると、クライアントが起動に失敗したり、システムプロキシが空のポートを指したままになったりする場合がある。対処法は共通:mixed-portを空いているポートに変更し、クライアントを再起動し、システムプロキシ設定のポートも合わせて更新されているか確認する。占有しているプロセスの確認は、Windowsではnetstat -ano、macOS/Linuxではlsof -i :7890で行える。

YAML構文エラー

設定を手動で編集した後に「設定の読み込みに失敗しました」と表示される場合、9割はYAMLの構文の問題だ。3つの原則を守る:インデントはスペースのみを使い、1段階につきスペース2つで統一し、タブとの混在は絶対に避ける。コロンの後には必ずスペースを1つ入れる。値にコロンやシャープ、あるいは特殊文字で始まる文字列が含まれる場合は、値全体を引用符で囲む。編集後はクライアントの「設定を検証」機能、またはコア側のmihomo -t -f config.yamlで構文チェックを行った上で正式に読み込ませる。

購読の更新方針

購読の内容はサービス提供元が管理しており、ノードの変更は更新によって受け取る。クライアントの自動更新を有効にし、間隔は24時間程度を推奨する。広範囲でタイムアウトが発生していたり、告知でノードが変更されたと案内されている場合は、手動で一度購読を更新してから再テストする。「購読を更新」は遠隔側の内容でローカルの設定を上書きする点に注意――カスタムルールは購読から生成されたファイルを直接編集するのではなく、クライアントが提供する上書き/マージ設定の機能に書くこと。

次のステップ

プラットフォーム別のインストールが完了したら、スタートガイドに戻ってインポート・モード選択・接続・動作確認の4ステップを一通り行い、経路が使えることを確認する。フィールドや用語の正確な定義が必要な場合は用語クイックリファレンスを、インストーラーと各クライアントのシステム要件はダウンロードページを参照。