01 · 基本概念:コア・設定ファイル・サブスクリプション
まずこの3つの用語の境界をはっきりさせておきましょう。以降の章はすべてこの3つの概念の上に成り立っています。コアとは、実際に通信を処理するコマンドラインプログラムのことで、現在の主流は Mihomo(Clash Meta プロジェクトを継承)です。コアは設定ファイルを読み込み、そこに記載されたルールに従って各接続の出口を決定します。クライアントはコアを包む GUI で、サブスク導入、ノード切り替え、システムプロキシのオン・オフといった日常操作を担います。ダウンロードページで紹介している Clash Plus、Clash Verge Rev、FlClash はいずれもこの層に属します。サブスクリプションとは、サービス提供者が発行する1本の URL のことで、クライアントはここから定期的にノード一覧と初期ルールを取得し、コアに渡す最終的な設定を組み立てます。
コアが受け取れる入力形式は1つだけで、YAML 形式の設定ファイル、通常 config.yaml と呼ばれるものです。このファイルには決まった最上位構造があり、よく使う項目は大きく4つに分かれます。
mixed-port、allow-lan、mode、log-levelなどのグローバル設定で、リスンポートや動作モードを決定する項目proxies:ノード一覧。各項目はプロキシサーバーのアドレス、ポート、プロトコル、認証情報を表すproxy-groups:ポリシーグループ。ノードを「手動選択」「自動速度測定」といった切り替え可能な集合にまとめたものrules:振り分けルール。上から順に照合し、通信がどのポリシーグループに流れるかを決定する
最小構成で動作するグローバル設定は次のようになります。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infomixed-port: 7890 は、ローカルの 7890 番ポートで HTTP と SOCKS5 の両プロキシプロトコルを同時にリスンすることを表し、システムプロキシの設定先をここに指定すればOKです。allow-lan はLAN内の他デバイスからの接続を許可するかどうかを制御し、家庭用途では通常オフにします。mode は動作モードを決める項目で、第5章で詳しく説明します。log-level はログの詳細さに影響し、トラブル対処時は debug に、通常時は info のままにしておきます。
サブスクリプションと設定ファイルの関係については補足が必要です。サブスクリプションのリンクが返す内容は、完全な Clash YAML(そのまま使える)の場合もあれば、Base64エンコードされたノード一覧(クライアントや変換サービスでポリシーグループとルールを補う必要がある)の場合もあります。両形式の違いと相互変換については、記事「Clash サブスクリプション形式を徹底解説」で詳しく説明しています。日常的な利用では設定ファイルを手書きする必要はほとんどありません(クライアントが代わりに組み立てます)が、構造を理解しておくことが、後でルールを変更したり、TUNを有効化したり、差分修正を行ったりする際の前提になります。聞き慣れない用語に出会ったら、いつでも用語集を参照してください。「コアとプロトコル」「ルールと振り分け」「出口ポリシー」といったカテゴリ別によく使う用語をまとめています。
最後に混同しやすいポイントを1つ。Clash の元プロジェクトは更新が停止しており、今「Clash」と言う場合は通常、Mihomo コアと各社のGUIクライアントを含むエコシステム全体を指します。プロトコルの面では、Mihomo は Shadowsocks、VMess、VLESS、Trojan、Hysteria2 などの主要プロトコルに対応しており、サブスクリプションに含まれるノードがどのプロトコルであっても、コアはそのまま利用できます。プロトコルごとにソフトを切り替える必要はありません。これは Clash 系クライアントを選ぶ主な理由の1つでもあります。1つのサブスクリプションで複数プロトコルをカバーでき、ルール振り分けの機能も統一されています。
02 · クライアント選定:プラットフォームとニーズの対応表
クライアントは日常の操作性を、コアは機能の上限を決めます。現在主流のクライアントはすべて Mihomo コアを内蔵しており、機能面の差はさほど大きくないため、選定はプラットフォームの対応状況と画面の好みが基準になります。以下は各プラットフォームの選択肢と本サイトの推奨順で、ダウンロードページのラインアップと一致しています。
| プラットフォーム | 第一候補 | 代替候補 | 補足 |
|---|---|---|---|
| Windows | Clash Plus | Clash Verge Rev / FlClash / Clash Nyanpasu | Clash for Windows は開発終了、アーカイブとして掲載のみ。新規インストールは非推奨 |
| macOS | Clash Plus | Clash Verge Rev / FlClash | ClashX Meta は開発終了。Intel 版と Apple Silicon 版のインストーラーの取り違えに注意 |
| Android | Clash Plus | Clash Meta for Android / FlClash / Surfboard | いずれも VPN サービス方式で通信を制御。初回起動時に権限の許可が必要 |
| iOS | Clash Plus(App Store) | — | App Store からインストール、公式サイトは clashplus.io |
| Linux | Clash Verge Rev | FlClash | deb パッケージあり。デスクトップ環境のないサーバーでは Mihomo コアを直接実行 |
利用スタイルに応じた選定案を3つ紹介します。初めて使う・設定を細かく調べたくない場合:Clash Plus を導入するのが近道です。5つのプラットフォームすべてに対応し、サブスク導入、モード切り替え、ノードの速度測定が1つの画面に集約されており、デフォルト設定のまま問題なく動作します。複数デバイスを使う人でも各端末の操作感を統一できます。設定を細かく制御したい場合:Clash Verge Rev はコアのパラメータを最も広く公開しており、差分設定(第9章で扱う)に対応し、TUNのオン・オフやコアのログも画面上で直接扱えるため、ドキュメントを読み込める人向けです。Android で軽量さを重視する場合:Clash Meta for Android は画面が最もシンプルでバックグラウンド駐在の負荷も小さく、FlClash はクロスプラットフォームでの一貫性に優れ、1つの操作ロジックでデスクトップとモバイルの両方をカバーします。
逆方向の注意点を2つ挙げます。1つ目は、古い記事で人気だったからといって Clash for Windows や ClashX Meta を新規に導入しないことです。両者とも開発が終了しており、コアのバージョンは古いまま更新されず、新しいプロトコルのノード(Hysteria2 など)を認識できない可能性があり、問題が起きても今後修正されることはありません。2つ目は、1台のデバイスに複数のクライアントを同時に入れる必要はないということです。どのクライアントも 7890 番ポートをリスンしてシステムプロキシを制御しようとするため、同時実行は必ず競合します。比較検討したい場合は、1つを完全に終了してから別のものを起動してください。
選定の各観点(コアのバージョン方針、TUN対応の程度、設定方法の違い、「初心者/複数デバイス/カスタマイズ派」の3タイプ別の詳細な結論)については、クライアント比較ページと記事「主要 Clash クライアント徹底比較」を参照してください。本マニュアル以降の章の操作説明は Clash Plus と Clash Verge Rev を基準にしていますが、他のクライアントもメニューの表現が少し異なるだけで、概念と流れは完全に同じです。「サブスク/設定」入口を見つけて導入し、「モード」入口を見つけて切り替え、「システムプロキシ/TUN」のスイッチを見つけて通信を制御する、という流れです。
03 · インストールと初回起動
インストーラーは必ずダウンロードページから入手し、プラットフォームのタブを切り替えてから対応するクライアントとアーキテクチャを選んでください。本章ではプラットフォームごとのインストール手順、初回起動時に表示されるシステムの警告、各プラットフォームの主要な設定ファイルの場所を紹介します。
Windows
インストーラーを実行し、ウィザードに従って進めます。署名がないか比較的新しい署名のインストーラーを初めて実行すると、SmartScreen が「WindowsによってPCが保護されました」と表示することがあります。「詳細情報」をクリックし、続いて「実行」をクリックすれば続行できます。インストール完了後はスタートメニューから起動し、クライアントはタスクバーのトレイ領域に常駐します。ウィンドウが見つからないときはまずトレイを確認し、重ねて起動しないようにしてください。システムプロキシやTUNを初めて有効化する際にはUACのポップアップで管理者権限の要求が表示され、許可が必要です。起動時に bind: address already in use というエラーが出た場合、7890番ポートが他のプログラムに使われていることを意味します。対処の流れは「Clash のポート競合を解決する方法」を参照してください。設定とログのディレクトリは通常 %USERPROFILE%\.config かアプリのデータディレクトリ内にあり、クライアントの「ディレクトリを開く」メニューから直接アクセスできます。
macOS
dmg を開き、アプリケーションを「アプリケーション」フォルダにドラッグします。インストーラーには Intel 版と Apple Silicon 版の2種類があるので、「このMacについて」でチップの種類を確認してからダウンロードしてください。アーキテクチャを間違えると明らかに動作が遅くなったり起動できなくなったりします。初回起動時に Gatekeeper がインターネットから取得したアプリだと表示する場合は、ポップアップで「開く」をクリックするか、「システム設定 → プライバシーとセキュリティ」の下部にある「このまま開く」をクリックしてください。システムプロキシを有効化するとクライアントがネットワーク環境設定に書き込みを行うため、ログインパスワードの入力を求められることがあります。TUNを有効化する場合はシステム拡張機能のインストールまたは補助ツールの許可が必要になるので、表示に従って順に許可してください。設定ディレクトリはデフォルトで ~/.config 内のクライアント用サブディレクトリにあります。
Android
apk のインストール時に「不明なソースからのアプリはインストールできません」と表示された場合は、システム設定でブラウザまたはファイルマネージャーに「不明なアプリのインストール」権限を付与してください。初めて接続をクリックすると、システムがVPN接続のリクエストをポップアップ表示します。これは Android が通信を制御するための標準的な仕組みなので、必ず許可してください。許可しないとプロキシが機能しません。MIUI や ColorOS などの中国メーカー系 OS では、クライアントをバッテリー最適化の対象外に設定しバックグラウンド動作を許可してください。設定しないと画面ロック後しばらくしてプロセスが強制終了され、「使っているうちに切れる」現象が起きます。
iOS と Linux
iOS では App Store から Clash Plus をインストールし、初回起動時に構成プロファイル形式のVPN許可が表示されるので、同様に許可すればOKです。Linux デスクトップ環境では deb パッケージで Clash Verge Rev をインストールします(sudo apt install ./パッケージ名.deb)。TUNを有効化するにはコアにネットワーク権限を付与する必要がありますが、クライアントの設定にワンクリック認可のボタンがあります。デスクトップ環境のないサーバー用途では Mihomo コアのバイナリを直接ダウンロードし、systemd と組み合わせて運用します。これは第9章で扱う応用的な内容です。
プラットフォームを問わず、初回起動後に行うべきことは3つです。ログ画面を開いて赤いエラーが出ていないことを確認する。設定ディレクトリの場所を把握しておく(バックアップやトラブル対処で使います)。デフォルトのポートとDNS設定はしばらく変更しない(デフォルト値はほとんどの環境に適合しており、変更は理由を明確に理解した上で行うべきです)。クライアントを開いた瞬間に落ちる場合は、「起動時クラッシュ・強制終了への対処」の順序に従い、まずログを確認してください。
04 · サブスクリプションの導入と更新
サブスクリプションのリンクはサービス提供者から発行され、通常はユーザーパネルの「サブスクリプション/ワンクリック導入」欄にあり、https://example.com/api/v1/client/subscribe?token=xxxx のような形をしています。この URL はアカウントの認証情報と同等の意味を持ちます。他人に知らせるのはアカウントを共有するのと同じことなので、公開の場に貼ったり、スクリーンショットで写り込ませたりしないよう注意してください。
3つの導入方法
- URLでの導入(推奨):クライアントの「サブスクリプション/設定」ページにリンクを貼り付けて導入します。クライアントはこのアドレスを記憶し、以降はワンクリックで更新したり、定期更新を設定したりできます。ノードの変更内容も自動的に反映されます。「継続的に同期」できるのはこの方法だけです。
- ファイルでの導入:サービス提供者から受け取った YAML ファイルを直接ドラッグまたは選択して導入します。オフライン環境に向いていますが、ノードが更新されるたびに手動でファイルを入れ替える必要があります。
- クリップボード/QRコードでの導入:モバイル端末でよく使われる方法で、実質的にはURL導入と同じで、入力の手段が異なるだけです。
導入が成功したかどうかの判断基準は、サブスクリプション項目を展開してノード一覧が表示できること、ポリシーグループ画面でグループが確認できることです。導入時にエラーが出た場合は、次の3ステップで原因を特定します。まずブラウザで直接サブスクリプションリンクを開き、YAML または Base64 のテキストが表示されればリンク自体は有効です。次にクライアントのエラーメッセージのキーワードを確認します。invalid syntax のようなものは形式が非対応であることを示し、タイムアウト系はネットワークの問題を示します。最後にサブスクリプションの形式とクライアントが一致しているか確認します。サービス提供者によってはクライアントごとに異なる形式のリンクを用意していることがあるので、その場合は「Clash」用を選んでください。サービス提供者の中にはリクエストの User-Agent を確認し、Clash系のUAにのみ YAML を返す実装もあるため、ブラウザで開くと文字化けするのはよくある正常な現象です。
更新の方針
サブスクリプションは一度導入すれば済むものではありません。サービス提供者はノードのドメインやポートを随時変更するため、既存の設定内のノードは次第に無効になっていきます。クライアント側で自動更新の間隔を12〜24時間に設定しておくのがおすすめです。「昨日まで使えていたのに今日は全部タイムアウトする」といった状況に遭遇したら、まず手動でサブスクリプションを更新してみてください。更新に失敗する場合、鶏と卵のような問題に注意が必要です。サブスクリプションのアドレス自体がプロキシ経由でないとアクセスできない場合があります。多くのクライアントには「プロキシ経由で更新」というスイッチが用意されているので、ノードがまだ生きている間はこれをオンにしてください。すべてのノードが機能しなくなった場合は、ネットワーク環境を変える(スマホのテザリングなど)しかありません。
サブスクリプションの変換
サブスクリプションの形式がクライアントと合わない場合(例:汎用の Base64 ノード一覧を受け取ったが、クライアントは完全な YAML しか受け付けない)、サブスクリプション変換サービスによる加工が必要です。変換ツールが元のサブスクリプションを取得し、ルールのテンプレートを適用して、標準的な Clash 設定を出力します。変換の仕組み、公開の変換サービスを使う際のプライバシーリスク(変換ツールにサブスクリプションの内容が見えてしまう)、自前で構築する方法については、「Clash サブスクリプション形式を徹底解説」で詳しく説明しています。基本方針として、クライアントが直接読み込める形式のサブスクリプションであれば変換ツールを経由させない方が経路が短く、信頼性も高くなります。
複数のサブスクリプションを利用する場合の管理方法として、各サブスクリプションは独立した設定項目として扱い、複数のサービスのノードを手動で1つのファイルにまとめないようにしてください。まとめてしまうと個別に更新できなくなり、トラブル対処の際にどのノードがどのサブスクリプション由来か分からなくなります。複数のサブスクリプションのノードをまとめて使いたい場合は、proxy-providersの仕組み(第9章)を使い、実行時にコアが取得・統合するようにし、静的なファイルを手動で編集するのは避けてください。
05 · 動作モード:ルール・グローバル・直結
コアには3つの動作モードがあり、設定ファイルの mode 項目の3つの値に対応します。クライアントの画面上では通常ラジオボタンの形で選択できます。
| モード | mode の値 | 動作 | 適した場面 |
|---|---|---|---|
| ルール | rule | 各接続を rules リストと順に照合し、命中したルールに従って処理する | 日常使用のデフォルト。国内向けは直結、国外向けはプロキシ経由 |
| グローバル | global | ルールをすべて無視し、すべての通信を GLOBAL グループが指す出口に流す | ノードの動作確認や、ルールの誤判定が疑われるときの一時利用 |
| 直結 | direct | すべての通信をローカルから直接送信し、ノードを経由しない | プロキシを一時的に無効にしたいがクライアントは終了したくないとき |
日常的にはルールモードにしておくべきです。その価値は振り分けにあります。中国本土のサイトへの通信は直結にすることでノードの通信量を消費せず遅延も増やさず、海外向けの通信はルールに従ってプロキシ経由にし、広告用のドメインは直接拒否することもできます。グローバルモードは常用する状態ではなく、あくまでトラブル対処用のツールです。すべての通信がプロキシを経由すると、中国本土のサイトも大きく迂回することになり、速度が落ち通信量も倍増します。実用的な対処法として、あるサイトが開けないときは、まずグローバルモードに切り替えて試してみてください。開けるならルールが正しく命中していないことになるので第6章に戻ってルールを調整し、それでも開かないならノードの問題です(ノードを変えるか速度の分層調査を参照)。
モード以外の話:通信はどうやってコアに入るか
モードは通信がコアに入った後どう流れるかを決めますが、それとは別に、通信がそもそもコアに入れるかどうかを決めるスイッチがあり、それがシステムプロキシです。有効化すると、OSはHTTP/HTTPSの通信を 127.0.0.1:7890 に向けるようになり、ブラウザや大半のシステムプロキシ設定に従うアプリが機能するようになります。ただし一部のプログラム(コマンドラインツール、一部のゲームやクライアントソフト)はシステムプロキシを参照せず、それらの通信はコアを経由しません。これが「ブラウザは通るのにターミナルは通らない」現象の典型的な原因で、対処法は2つあります。プログラムごとにプロキシの環境変数を個別に設定する(例:HTTP_PROXY=http://127.0.0.1:7890)か、第7章のTUNモードで端末全体を制御することです。
接続確認
モードを切り替えたら、次の3点を順に確認してください。クライアントの「接続」ページに動作中の接続項目が表示されていれば、通信が確かにコアに入っていることを示します。その項目の出口欄に想定したポリシーグループとノードが表示されていれば、ルールが正しく命中していることを示します。ブラウザで海外のサイトが開ければ、経路が端から端まで機能していることを示します。この3ステップのどこで止まっているかによって、対処すべき層が分かります。これはサイト全体で使えるトラブル対処の基本的な考え方でもあり、まず層を特定してから手を動かすということです。ポリシーグループの選び方(手動でノードを選ぶか自動速度測定にするか)は体感に直結するため、グループの種類の違いは次章でルールと合わせて説明します。
06 · ルール振り分け:文法・優先順位・ポリシーグループ
ルールは Clash の中核機能で、設定の rules リストに記述します。各ルールは タイプ,マッチ対象,出口 の3要素からなります。コアは新しい接続ごとに上から順に照合し、命中した時点で止まります。この順序がそのまま優先順位になり、これがすべての振り分けの理解とデバッグの鍵になります。よく使うルールタイプは以下の通りです。
| タイプ | マッチ対象 | 例 |
|---|---|---|
DOMAIN | ドメイン完全一致 | DOMAIN,ads.example.com,REJECT |
DOMAIN-SUFFIX | ドメインのサフィックス(サブドメインを含む) | DOMAIN-SUFFIX,github.com,PROXY |
DOMAIN-KEYWORD | ドメインにキーワードを含む | DOMAIN-KEYWORD,google,PROXY |
IP-CIDR | 宛先のIPレンジ | IP-CIDR,192.168.0.0/16,DIRECT,no-resolve |
GEOIP | IPの所属地データベース | GEOIP,CN,DIRECT |
RULE-SET | 外部で管理されているルール集 | RULE-SET,streaming,PROXY |
MATCH | 無条件で命中。必ず末尾に置く | MATCH,PROXY |
構造が整ったルールの例です。コメントで並び順の考え方を示しています。
rules:
# 完全一致ルールを先頭に:優先度が最も高い手動オーバーライド
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,github.com,PROXY
# LANと予約アドレスは直結。no-resolve でドメイン接続のための不要な名前解決を回避
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
# 地理情報での兜底:中国本土のIPは直結
- GEOIP,CN,DIRECT
# 最終的な兜底:上記に一つも命中しなかった場合はプロキシ経由
- MATCH,PROXYよく使う文法の要点を3つ挙げます。1つ目、DOMAIN-SUFFIX,github.com は github.com と api.github.com の両方に一致しますが、github.io には一致しません。サフィックス一致はドット区切りが境界になります。2つ目、GEOIP と IP-CIDR は宛先のIPと比較するため、接続先がドメインの場合はコアが先にDNS解決を行う必要があります。イントラネット向けのルールに no-resolve を付けると、すべてのドメイン接続が不要に先行解決されるのを防ぎ、遅延とDNS漏出のリスクを減らせます。3つ目、MATCH より後に置かれたルールは実行されないため、新しいルールは必ずそれより前に挿入してください。「ルールを変更したのに反映されない」場合の最初の確認ポイントは、より前にあるルールに先に取られていないかどうかです。クライアントの「接続」ページには各接続がどのルールに命中したかが表示されるので、それを基準に確認してください。
ポリシーグループ:ルールの出口
ルールの3番目の要素である出口には、組み込みの DIRECT(直結)や REJECT(拒否)以外に、多くの場合ポリシーグループを指定します。ポリシーグループはノードを切り替え可能な集合にまとめたもので、よく使うのは4種類です。select は手動選択で、画面上で選んだノードがそのまま使われます。url-test は定期的にテスト用アドレスへリクエストを送り、遅延が最も低いノードを自動選択します。fallback はリスト順に最初に使えるノードを選び、優先ノードが落ちたら自動でフォールバックします。load-balance は接続を複数のノードに分散させます。例を示します。
proxy-groups:
- name: PROXY
type: select
proxies:
- AUTO
- HK-01
- JP-01
- name: AUTO
type: url-test
url: http://www.gstatic.com/generate_204
interval: 300
proxies:
- HK-01
- JP-01この構成はよく使われるベストプラクティスです。PROXY はルールが指す総入口で、種類は手動選択です。最初の選択肢は自動速度測定グループ AUTO で、通常はこれを選んで自動選優の恩恵を受け、特定の要件(地域を固定したいなど)がある場合は手動で個別のノードに切り替えます。interval: 300 は5分ごとに再測定することを意味します。サブスクリプションに付属する設定には通常この種のグループ構成が既に含まれているので、この構造を理解しておけば、どんなサブスクリプションの設定を読んでも理解できるようになり、第9章で自分で設定を編集する際の基礎にもなります。
07 · TUNモードとシステム全体の制御
第5章でシステムプロキシの限界について触れました。プロキシ設定を参照しないプログラムはコアを経由しません。TUNモードはさらに低い層でこの問題を解決します。コアが仮想ネットワークカードを作成し、OSのデフォルトルートをそこに向けることで、すべてのIP通信(プログラムがプロキシに対応しているかどうか、TCPかUDPかを問わず)が先にコアを経由し、ルールに従って振り分けられます。コマンドラインツール、ゲーム、UDPの音声通話まですべて対象になります。代償として、より高いシステム権限が必要になり、他のルーティングを変更するソフトとは排他的になります。
設定とパラメータ
主要なクライアントはいずれもTUNをスイッチとして提供しています(Clash Verge Rev は設定ページ、Clash Plus は接続方式のオプション内)。そのスイッチの裏側にあたる設定は次のようになります。
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53各項目の説明です。stack はプロトコルスタックの実装方式で、system はシステムのネットワークスタックを使うもので互換性が最も高く、通常はこれを第一候補にしてください。gvisor はユーザー空間スタックで、システムスタックで異常が出る特定の環境では試す価値があります。mixed は両者の折衷です。auto-route はコアがルーティングテーブルへ自動で書き込み、終了時にクリーンアップする機能で、必ず有効にしてください。無効だと通信が仮想ネットワークカードに入りません。auto-detect-interface は実際の出口ネットワークカードを自動識別し、通信が仮想ネットワークカード内でループしてしまうのを防ぎます。dns-hijack は53番ポート宛のすべてのDNSクエリをコアに横取りさせて処理する機能で、TUN配下でもドメインルールが正しく機能するようにするためのものです。DNSを横取りしないと、アプリが自分で解決したIPを使って直接接続してしまい、ドメイン系のルールが丸ごと機能しなくなります。
各プラットフォームでの権限のハードル
Windowsでは初回有効化時に管理者権限の要求と仮想ネットワークカードドライバのインストールが行われ、UACのポップアップで許可が必要です。有効化後に端末全体がネット接続不能になる場合は、たいていドライバのインストールが不完全なので、システムを再起動してから再度有効化してください。macOSではシステム拡張機能の許可が必要で、「システム設定 → プライバシーとセキュリティ」で許可します。新しいバージョンのシステムでは「ログイン項目と拡張機能」でも確認が必要な場合があります。Linuxではコアのバイナリに CAP_NET_ADMIN 権限を付与する必要がありますが、Clash Verge Rev の設定内にある認可ボタンが代行してくれます。Android と iOS のクライアントはそもそもVPNサービス方式で動作しているため、TUNと実質的に同等であり、追加の操作は不要です。
利用上の境界とよくある落とし穴
- TUNとシステムプロキシを同時に有効にする必要はありません。TUNを有効にしたらシステムプロキシは切っておくことをおすすめします。通信が二重に制御されるのを避け、トラブル対処の難易度が上がるのを防げます。
- TUNは他のVPNや仮想ネットワークカード系ソフトとは排他的です。2つのプログラムがデフォルトルートを奪い合うと、たいていネット接続不能になります。TUNを有効にする前に他のVPN系ソフトを終了させてください。
- 有効化後はすべての通信がコアを経由するため、ルールの質が体感に直結します。
GEOIP,CN,DIRECTのような直結の兜底ルールは必ず用意してください。ないと、システムの更新やオンラインストレージの同期といった大容量通信までプロキシ経由になってしまいます。 - クライアントを終了してもネット接続不能な状態が続く場合は、ルーティングのクリーンアップが不完全であることが原因です。ネットワークインターフェースまたはシステム自体を再起動すれば復旧します。この種の問題への対処についてはヘルプセンターのトラブル対処カテゴリーを参照してください。
一言でまとめると、ブラウザ中心の軽い使い方であればシステムプロキシで十分で権限もクリーンに保てます。コマンドラインやゲーム、任意のUDPアプリまでカバーしたい場合はTUNを使うのが直接的で、一度設定すれば「起動したら忘れていい」安定した状態になります。
08 · 日常メンテナンス:更新・バックアップ・トラブル早見表
設定が終わった後の Clash の日常メンテナンスはそれほど多くありませんが、いくつかの作業を周期的に行うことで、「突然使えなくなった」という事態のほとんどを避けられます。
3種類の更新
サブスクリプションの更新は最も頻度が高いものです。自動更新(12〜24時間)を設定しておくのはもちろん、「ノードがまとめてタイムアウトする」ような瞬間には、まず手動でサブスクリプションを更新してからトラブル対処に進んでください。GeoIP / Geosite データベースの更新は見落とされがちです。第6章の GEOIP,CN ルールはローカルのIP所属地データベースに依存しており、データベースが古すぎると、一部の中国本土のIPが誤って海外と判定され、プロキシ経由に迂回してしまいます。これは「中国本土のサイトがなぜか遅くなった」という形で現れます。主要なクライアントの設定にはワンクリック更新のボタンが用意されているので、1〜2ヶ月ごとに一度クリックすることをおすすめします。更新後はコアを再起動して反映させてください。クライアントとコアの更新:クライアントには通常アップデート確認機能があり、アップグレード前には次の項目のバックアップを行っておいてください。新機能を追う必要がなければ、安定して動いているバージョンを頻繁にアップグレードする必要はありません。
何を、どうバックアップするか
バックアップしておく価値があるのは3つだけです。サブスクリプションのリンク自体(パスワード管理ツールに保存しておけば、どんな新しいデバイスでもすべてを再構築できます)、自分で修正した設定やオーバーライドの断片、クライアントの設定エクスポート(クライアントにエクスポート機能がある場合)。設定ディレクトリをそのまままとめてバックアップしても構いませんが、キャッシュとログにはバックアップの価値はありません。機種変更時の標準的な流れは、新しいデバイスにクライアントを入れる→サブスクリプションのリンクを貼る→カスタムの断片を復元する、というもので5分で完了し、バイナリファイルの移行は一切不要です。
ログ:トラブル対処の第一現場
すべてのトラブル対処は推測からではなくログから始めるべきです。クライアント画面のログページにはコアの動作ログが表示され、error レベルの行には失敗の原因(ポート競合、設定の文法エラー、ノードとのハンドシェイク失敗)が直接表示されます。info レベルでは各接続の照合過程を確認できます。画面上のログで足りない場合は、設定ディレクトリ内に完全なログファイルがあります。log-level を一時的に debug にすると、DNS解決とルール照合の各段階を確認できます。確認が終わったら info に戻すことを忘れないでください。debugのログ量はかなり多くなります。
トラブル早見表
| 症状 | 最初に疑うべき原因 | 対処先 |
|---|---|---|
起動時に bind: address already in use と表示される | 7890番ポートが使用中 | 競合プロセスの特定とポート変更 |
| クライアントを開いた瞬間に落ちる | 設定ファイルの文法エラー / キャッシュの破損 | ログから始める対処リスト |
| 接続できるが速度が遅い | ノードの質 / 経路の混雑 / ローカル設定 | 分層調査:ノード→経路→ローカル |
| すべてのノードがタイムアウトする | サブスクリプションの期限切れ / システム時刻のズレ | まずサブスクリプションを更新し、次にシステム時刻を補正する |
| 一部のサイトがプロキシを経由しない | ルールが命中していない | 接続ページで命中ルールを確認し、第6章に戻って調整する |
表の4行目「システム時刻のズレ」は特に触れておく価値があります。VMessなどのプロトコルは時刻に敏感で、ローカルの時刻が約90秒以上ずれるとハンドシェイクが即座に失敗し、そのプロトコルのノードがまとめてタイムアウトします。この現象はサブスクリプションが失効したように見えるため紛らわしいものです。トラブル対処の際には「システム時刻が自動同期になっているか」を通常チェック項目に含めてください。より細かなQ&A形式の内容はヘルプセンターにまとめられており、基礎知識、インストール設定、使い方のコツ、トラブル対処の4カテゴリーで構成されています。
09 · 応用編:オーバーライド・外部制御・コマンドラインでのコア実行
第8章までを終えれば、日常使いには十分です。本章では、さらに深く踏み込みたい人向けに、投入コストの低い順に3つの方向性を紹介します。
方向性1:設定のオーバーライド(サブスクリプション本体は変更しない)
サブスクリプションから生成された設定ファイルを直接編集するのは初心者がよく陥る間違いです。次にサブスクリプションが更新されると、変更内容はすべて上書きされてしまいます。正しいやり方はオーバーライド(override)です。自分の変更を独立した断片として書いておき、クライアントがサブスクリプション更新のたびに自動でそれを最終的な設定にマージしてくれます。Clash Verge Rev は YAML マージとスクリプトの2種類のオーバーライド方式に対応しており、典型的な用途としては、サブスクリプションのルールの先頭に自分の優先度の高いルールを挿入する、自前で管理しているノードを追加する、サブスクリプション内の不適切な速度測定間隔を強制的に変更する、などがあります。ルール一覧の先頭に2行を追加する最小構成のマージ用オーバーライド例を示します。
prepend-rules:
- DOMAIN-SUFFIX,internal.example.com,DIRECT
- DOMAIN-KEYWORD,tracker,REJECTオーバーライドと同じ「管理を任せる」発想に属するのが proxy-providers / rule-providers です。実行中にコアがURLからノード集やルール集を取得し定期的に更新するようにし、メインの設定にはその参照だけを書きます。複数サブスクリプションの統合や、コミュニティが管理する広告ドメインリストなどのルール集は、手作業でコピー&ペーストするのではなく、この仕組みに頼るのが基本です。
方向性2:外部制御API
コアには標準でHTTP制御インターフェースが備わっており、設定に2行追加するだけで有効化できます。
external-controller: 127.0.0.1:9090
secret: "your-password"有効化すると、ノードの切り替え、モードの変更、接続の確認、遅延測定などがHTTPリクエストで行えるようになります。クライアントの画面は本質的にこのAPIのフロントエンドにすぎません。これを使いこなせるようになると、Web版ダッシュボード(クライアントに通常組み込まれています)でブラウザからコアを管理する、スクリプトで定期的に速度測定してポリシーグループを自動切り替えする、家庭用サーバーで画面のないコアを遠隔管理する、といったことが可能になります。守るべき安全上の基本ルールが2つあります。secret は必ず設定し、十分にランダムな値にすること。リスンアドレスは 127.0.0.1 のままにしておき、LAN内からのアクセスが本当に必要な場合はファイアウォールで接続元を制限すること。
方向性3:コマンドラインで Mihomo コアを直接実行する
サーバー、ルーター系機器、NASのようなデスクトップ環境のない場面では、GUIクライアントを使わずコアを直接実行します。ダウンロードページのコア欄で各アーキテクチャ向けのバイナリが配布されています。基本的な使い方は mihomo -d /etc/mihomo で、-d で指定するディレクトリに config.yaml と地理データベースを置きます。systemdでサービスユニットを書けば自動起動とクラッシュ時の再起動が実現でき、方向性2の制御APIで遠隔管理すれば、家全体をカバーする振り分けゲートウェイの原型になります。この方向性を実践するには、第1章から第6章までの設定構造を完全に理解している必要があります。ここまで来れば「ゼロから使いこなす」という一連の流れが完結します。
推奨される学習の順序
- 本ページ第6章のルール文法を、実際に自分の設定で確認してみましょう。ルールを1つ追加し、接続ページで命中していることを確認します。
- オーバーライドの仕組みを使って自分のよく使う変更を固定し、「サブスクリプションを更新しても変更内容が消えない」というワークフローを体感してみましょう。
- 外部制御を有効にして、1日だけクライアントの画面の代わりにブラウザのダッシュボードで操作し、コアと画面の境界を理解しましょう。
- 使っていない機器があれば、コマンドラインでコアをデプロイしてみて、デスクトップで得た経験をサーバー側に移してみましょう。
各ステップは前のステップの上に成り立っているので、飛び級で進む必要はありません。具体的な用語に出会ったら用語集に戻り、具体的な障害に出会ったら第8章の早見表に戻り、「どれを入れるべきか」で迷ったら比較ページに戻ってください。このマニュアルの使い方は、いつも手元に置いておく配線図のようなものだと考えてください。