Clash 完全ガイド:インストール設定からルール分流まで

Clash 系クライアントを分解すると、本質的にやっていることは3つだけです。ローカルにポートを開いて通信を受け取る、ルールに従って各接続の振り先を判断する、プロキシ扱いになった接続をリモートノードへ転送する。以降の章で出てくる設定項目は、すべてこの3つのいずれかに対応しています。この章では実際の操作は行わず、後の章で必要になる概念だけを整理します。

プロキシクライアントの仕組み

クライアントを起動すると、ローカルに1つ以上のポートを開いて待ち受けます。よくあるのは HTTP と SOCKS5 を兼ねる混合ポートです。OS やブラウザがこのポートに通信を送ると、クライアントはルール表を確認します。直連ルールに合致すればローカルの network interface からそのまま送信し、プロキシルールに合致すればリモートのプロキシサーバーへ転送し、サーバー側が代わりに接続先へアクセスします。他のアプリから見るとクライアントは普通のローカルプロキシですが、アクセス先のサイトから見るとアクセス元はリモートノードになります。

初心者がよく混同するポイント:クライアントを入れただけではプロキシ機能は使えません。クライアント自体はノードを持たず、あくまで「振り分け役」です。ノードは購読や手動追加によって初めて手に入り、それが通信の「出口」になります。両方がそろって初めて機能します。ノードの導入方法は第4章で詳しく解説します。

カーネル:現行の主流は mihomo

Clash のエコシステムには2つのカーネル系統があります。オリジナルの Clash カーネルは開発が停止しアーカイブ扱いとなり、コミュニティ主導の Clash Meta が後に mihomo と改名され現行の主流となりました。本サイトのダウンロードセンターで配布しているグラフィカルクライアントはすべて mihomo ベースです。mihomo はオリジナル版をベースに、対応プロトコルやルールタイプ、TUN 機能を拡張しつつ、設定ファイルの記法は後方互換性を保っているため既存の設定はほぼそのまま移行できます。両系統の詳しい違いはブログの「Clash カーネルの違い:オリジナル Clash・Clash Meta・mihomo」で個別に解説していますので、結論だけ言えば新規導入は mihomo 系クライアントを選べば間違いありません。

ノード・ルール・購読の3要素

ノード(Proxy)とは、リモートのプロキシサーバーと、そこに接続するためのパラメータ(アドレス、ポート、プロトコル、認証情報)の組み合わせです。よく使われるプロトコルには Shadowsocks、VMess、Trojan、Hysteria などがあり、パケットのカプセル化はクライアントが処理するため、通常のユーザーが詳細を意識する必要はありません。

ルール(Rule)とは分流の判断条件で、「ドメインの末尾がある値なら直連にする」といった形をとります。ルール表は順序付きリストで、第6章で詳しく扱います。

プロキシグループ(Proxy Group)はルールとノードの間にある中間層です。ルールはノードを直接指すのではなくプロキシグループを指定し、グループ内でどのノードを使うかを決定します。手動選択も自動測速による選択も可能です。第5章で詳しく扱います。

購読(Subscription)は、定期的に設定テキストを返す URL で、そのテキストにはノード、プロキシグループ、ルールがまとめて含まれています。購読を導入するだけで上記の3要素が一度にそろいます。第4章で詳しく扱います。

1回のリクエストが通る道筋

ブラウザでサイトにアクセスする場合を例にすると、まずブラウザがシステムのプロキシ設定で指定されたローカルポートへリクエストを渡し、クライアントが接続を受け取ってルール表を上から順に照合します。ルールが「プロキシ」グループに合致すると、そのグループが自身のポリシーに基づいてノードを選び、クライアントはそのノードと暗号化接続を確立してリクエストを転送します。応答は同じ経路を逆にたどって戻ってきます。この一連の処理はすべてローカルで完了し、ブラウザ側からは何も意識されません。

クライアントに絶対的な優劣はなく、プラットフォームや使い方との相性がすべてです。本章ではプラットフォーム別の結論を提示します。各クライアントの機能比較はクライアント比較ページを、インストーラーの入手はダウンロードセンターをご覧ください。

5つのプラットフォームでの選択

Windows:第一候補は Clash Plus。UI とカーネルが同期更新されます。代替候補は Clash Verge Rev(機能パネルが充実)、FlClash(クロスプラットフォームで操作感が統一)、Clash Nyanpasu(独特な UI デザイン)。

macOS:第一候補は Clash Plus。Apple Silicon と Intel 両方の専用インストーラーが用意されています。代替候補は Clash Verge Rev と FlClash で、いずれもチップアーキテクチャ別に配布されており、間違ったアーキテクチャを選ぶと起動はしても性能が落ちます。

Android:第一候補は Clash Plus。代替候補は Clash Meta for Android(カーネルと同名のクライアントで更新頻度が高い)、FlClash、Surfboard(UI がシンプル)。

iOS:Clash Plus は App Store で公開されており、検索してそのままインストールできます。公式サイト clashplus.io にプラットフォーム別の説明があります。iOS ではプロキシクライアントがシステムレベルの構成として動作するため、体験はデスクトップ版と同等です。

Linux:デスクトップ環境では Clash Verge Rev や FlClash を使用し、deb と rpm パッケージが提供されています。サーバーやルーターなど GUI のない環境では mihomo カーネルを直接導入し、設定ファイルと外部コントローラーで管理します。詳細は第9章で解説します。

カーネル系統:オリジナルと mihomo

オリジナルの Clash カーネルの更新が止まったことで、それをベースにしていた代表的なクライアントも開発終了となりました。Windows の Clash for Windows、macOS の ClashX Meta です。ダウンロードページにこの2つを残しているのはあくまで参考用のアーカイブとしてで、カードには「開発終了」の表示があります。新規導入するなら過去の経緯を気にする必要はなく、開発が続いている mihomo 系クライアントを選べば、対応プロトコルもルールタイプも最も充実しています。

開発終了クライアントからの移行

Clash for Windows や ClashX Meta を現在も使っている場合、短期的に使い続けても問題はありませんが、新しいプロトコルやルールタイプには対応しません。ノードにつながらない場合はまずこの点を疑ってください。移行コストは低く、現在の購読リンクを控えて mihomo 系クライアントを導入し、購読を再インポートするだけです。購読内のプロキシグループやルールも自動的に引き継がれるため、手動で書き写す必要はありません。

本章ではプラットフォームごとのインストール手順とインストール後の確認項目を解説します。ダウンロードリンクは重複させず、ダウンロードセンターから各プラットフォーム版を入手してください。主要4プラットフォームの初回インストールの一般的な流れと初心者が陥りやすいポイントについては、ブログの「Clash 初回インストールと初期設定」も参考になります。

Windows

ダウンロードした .exe インストーラーをウィザードに従ってインストールします。多くのクライアントはポータブル版も用意しており、解凍してすぐ使えレジストリを汚さないため、USB メモリでの利用や複数端末への移行に便利です。システム要件はダウンロードページの各カードに記載の内容が最新で、主要クライアントは Windows 10 以降を要求します。初回起動時にファイアウォールの許可を求められたら、専用ネットワークでの通信を許可してください。ローカル利用のみでも許可しておくことをお勧めします。後々のトラブル調査で余計な要因を増やさないためです。

macOS

使用するチップに対応した dmg をダウンロードしてください。Apple Silicon は arm64 版、Intel 搭載機は x64 版を選びます。アプリを「アプリケーション」フォルダにドラッグして初回起動する際、「開発元を検証できません」と表示された場合は「システム設定 → プライバシーとセキュリティ」から「このまま開く」を選んでください。メニューバーにクライアントのアイコンが表示されれば起動成功です。

Android と iOS

Android はダウンロードページから apk を入手して直接インストールします。「不明なアプリのインストールを許可」を求められますが、インストール後にこの許可は無効にして構いません。初回接続時に VPN 接続のリクエストが表示されますが、これは Android 版プロキシクライアントの標準的な動作方式なので必ず許可してください。許可しないとクライアントは通信を一切処理できません。iOS では App Store から Clash Plus をインストールし、初回に設定を追加する際も同様にシステムが表示する VPN 設定リクエストを許可する必要があります。

Linux

デスクトップ版の Linux ディストリビューションでは deb や rpm パッケージで Clash Verge Rev や FlClash を導入し、インストール後はアプリケーションメニューから起動します。サーバーやルーターなど GUI が不要な場面では、対応アーキテクチャの mihomo カーネルのバイナリをダウンロードし、config.yaml を用意して systemd でプロセスを管理し、外部コントローラーで運用します。詳しい考え方は第9章を参照してください。

初回起動時の4つの確認項目

インストール直後にすぐ購読をインポートせず、まず次の4点を2分ほどで確認してください。

• 表示言語:多くのクライアントは初回起動後に設定から日本語表示に切り替えられます。
• 自動起動:設定で有効にしておくと、起動のたびに手動で立ち上げる必要がなくなります。
• システムプロキシのスイッチの位置:まずどこにあるかを把握しておきましょう。第4章で購読をインポートした後にオンにすることで、通信が実際にクライアントを通るようになります。
• 混合ポート番号:控えておいてください(デフォルトはよく 7890)。今後コマンドラインツールを一時的にプロキシ経由で使う場合や、LAN 共有をする際にこのポート番号が必要になります。

4つの確認が済めばインストール作業は完了です。次は第4章の購読インポートに進みます。

ノード、プロキシグループ、ルールという3要素は、購読リンク1つで一括して手に入ります。本章では購読とは何か、どうインポートするか、どう更新するか、更新に失敗した場合はどの順で確認すべきかを解説します。

購読リンクとは

購読リンクとは、設定テキストを返す URL のことで、その内容にはノード一覧、プロキシグループ、ルール表が含まれます。クライアントは定期的にこの URL にアクセスして最新の設定を取得します。購読リンクはノードを提供する事業者から発行されるもので、クライアント自体にはノードが含まれていません。リンクには通常ユーザー固有の認証情報が含まれ、パスワードと同じ扱いをすべきです。公開の場に貼らない、出所不明の購読を導入しない、機種変更時は自分で手元に控えて転送・共有しないことが重要です。

購読を導入する3つの方法

URL インポート(最も一般的):購読リンクをコピーし、クライアントの「設定/購読」ページを開いて新規作成、URL を貼り付けて名前を付けて保存します。クリップボードからのインポート:一部のクライアントはクリップボード内の購読リンクを検知し、コピー後にクライアントを開くとワンタップでインポートできます。ローカルファイルからのインポート:すでに config.yaml がある場合は、設定ページから「ローカルファイルをインポート」を選ぶか、ファイルをクライアントの設定フォルダに直接置きます。

インポートしただけでは一覧に表示されるだけで、実際に使うには「有効/アクティブ」な設定として選択する必要があります。複数の購読を共存させておき、アクティブな設定を切り替えることで、ノードとルールのセット全体を切り替えられます。

購読の更新と自動更新

ノードは増減し、ルールも改訂されるため、購読は定期的に更新する必要があります。クライアントには通常、手動更新ボタンと自動更新の間隔設定が両方用意されているので、24時間ごとの自動更新を有効にしたうえで、「ノードの様子がおかしいと感じたらまず手動で更新する」習慣をつけましょう。更新に失敗しても、クライアントは古い設定のまま動作を続けるため即座にネットが切れることはありませんが、更新が長期間失敗し続けると、ノード一覧が古いまま滞留し、無効なノードがどんどん増えていきます。

購読更新に失敗した場合:4ステップで確認

①ネットワークの到達性:購読先アドレス自体にアクセスできるか。まずシステムプロキシを切って直連で試してください。一部の購読アドレスはプロキシ経由だとむしろブロックされます。②リンクの有効性:リンクの期限切れ、リセット、プラン期限切れの可能性があるので、提供元に確認します。③クライアント識別情報:一部の事業者はクライアントの UA によって配布形式を変えているため、別のクライアントに切り替えたり最新版に更新したりして再試行します。④システム時刻:TLS 証明書の検証はシステム時刻に依存しており、時刻が大きくずれるとハンドシェイクに失敗します。時刻を修正して再度更新してください。

購読で返される設定テキストは次のような形式です(抜粋):

proxies:
  - name: "ノード-サンプル"
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["ノード-サンプル", "DIRECT"]

rules:
  - GEOSITE,cn,DIRECT
  - MATCH,PROXY

設定を受け取った際にこの3つの見分けがつけば、以降の章での設定変更も安心して進められます。proxies はノード、proxy-groups はプロキシグループ、rules はルール表です。

3つのプロキシモードは「ルール表を使うか、どう使うか」を決めます。切り替え入口は通常クライアントのホーム画面かトレイメニューにあり、いつでも切り替え可能で即時反映されます。クライアントの再起動は不要です。現在どのモードかは、ホーム画面やトレイアイコンのモード表示で確認できます。

ルールモード(Rule)

常用が推奨されるデフォルトモードです。各接続はルール表を上から順に照合し、プロキシに合致すればノード経由、直連に合致すればローカルの network interface から送信されます。中国本土サイトは直連で速度を確保し、海外サイトはプロキシ経由で到達性を確保でき、両者は互いに干渉しません。購読に付属するルール表は主要なシナリオをすでにカバーしているため、多くの人は長期間手を加える必要がありません。

グローバルモード(Global)

すべての接続が無条件でプロキシグループが選んだノードを経由し、ルール表全体は無効化されます。用途は2つです。ノードが使えるかを一時的に検証する場合と、全経路を同一の出口に統一する必要があるサービスにアクセスする場合です。長期的にグローバルモードを使い続けると中国本土向けの通信まで海外ノードを経由することになり、速度が落ちたりサイトの規制に引っかかりやすくなったりするため、用が済んだらルールモードに戻すのを忘れないでください。

直連モード(Direct)

すべての接続がノードを経由せず、クライアントは通信を受け取るだけで転送しません。用途は次の通りです。「ノードが壊れているのかクライアントが壊れているのか」を切り分ける対照テストとして、直連にしてアクセスできればクライアントとルールに問題はなく、原因はノード側にあるとわかります。完全に信頼できるネットワークで一時的にプロキシを無効にする場合にも使えます。

プロキシグループ:ノードのグループ化コンテナ

プロキシグループはルールとノードの間にある中間層です。ルールはノードを直接指定せずプロキシグループを指定し、グループが自身のタイプに応じて最終的に使うノードを決定します。よく使われる4種類のタイプは次の通りです。

• select 手動選択:グループ内のノードを一覧表示し、ユーザーが手動で切り替えます。最も一般的で、「メインノード+バックアップノード」の固定構成に向いています。
• url-test 自動測速:一定間隔でグループ内ノードへ測速リクエストを送り、遅延が最小のノードへ自動的に切り替えます。ノード数が多く手動管理したくない場合に向いています。
• fallback フェイルオーバー:リストの順序で先頭から使える最初のノードを使用し、落ちたら次のノードへ自動切替します。速度より安定性を重視する場合に向いています。
• load-balance 負荷分散:接続をグループ内の複数ノードに振り分けます。大容量ダウンロードなどのシナリオに向いています。

プロキシグループは設定上では次のような形になります:

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["自動選択", "ノード-サンプル", "DIRECT"]
  - name: 自動選択
    type: url-test
    proxies: ["ノード-サンプル"]
    url: http://example.com/generate_204
    interval: 300

購読に付属するプロキシグループは通常それだけで十分です。手動選択グループが日常用、自動測速グループが保険用として機能します。地域別・用途別に自分でグループを分けたい場合は、第9章の手書き設定の内容になります。

ルール分流は Clash 系クライアントの核心機能であり、「全体をトンネルに通す」タイプのツールとの決定的な違いでもあります。本章ではルールの種類を網羅し、マッチング順序を徹底的に解説したうえで、中国本土/海外の実践的な分流設定と検証方法を紹介します。より細かいルール記述例はブログの「Clash ルール分流の設定実践」も参考にしてください。

ルールタイプ一覧

mihomo が対応するルールタイプは多岐にわたりますが、日常的によく使うのは次のいくつかです。

• DOMAIN:単一のドメインを完全一致で判定します。例:DOMAIN,example.com,PROXY。このドメイン自体にのみ一致します。
• DOMAIN-SUFFIX:ドメインの末尾に一致します。例:DOMAIN-SUFFIX,example.com,PROXY。そのドメインとすべてのサブドメインに一致し、最もよく使われるドメインルールです。
• DOMAIN-KEYWORD:ドメインに特定のキーワードが含まれていれば一致します。例:DOMAIN-KEYWORD,example,PROXY。カバー範囲が広い分、誤検知も多いので慎重に使ってください。
• GEOSITE:ドメイン分類データベースによる一致判定です。例:GEOSITE,cn,DIRECT は中国本土のドメイン集合に一致し、1行で数万件分のルールを代替できます。
• IP-CIDR:対象 IP レンジに一致します。例:IP-CIDR,192.168.0.0/16,DIRECT は LAN アドレスすべてを直連にします。no-resolve パラメータ付きのルールは DNS 解決をトリガーせず、純粋な IP 接続のみ一致します。
• GEOIP:IP の所属地域による判定です。例:GEOIP,CN,DIRECT。ドメインはまず IP に解決されたうえで所属地域データベースに照合されます。
• PROCESS-NAME:接続元のプロセス名で判定します。デスクトップ環境で使え、特定のダウンロードツールを常にプロキシ経由にする、といった用途があります。
• DST-PORT / SRC-IP-CIDR:宛先ポート、送信元 IP レンジで判定します。LAN 共有やゲートウェイのシナリオでよく使われます。
• MATCH:兜底ルールで、すべてに一致します。必ずルール表の最終行に置く必要があります。

マッチング順序:上から順に、最初に一致したところで停止

ルール表は順序付きリストです。新しい接続ごとに先頭から順に照合され、最初に一致したルールが適用され、以降のルールは確認されません。この仕組みから2つの鉄則が導かれます。①より具体的で特殊なルールを前方に、より広範なルールを後方に置く。②MATCH の兜底ルールは必ず最後に置く。前方に置いてしまうと以降のルールはすべて機能しなくなります。「あるサイトの経路が想定と違う」場合は、まず順序を確認するのが正解です。より広いルールが前方にあってそのサイトを横取りしていないか確認してください。

ルールが指す先はプロキシグループでも予約語でも構いません。DIRECT は直連、REJECT は接続拒否(広告や追跡ドメインのブロックによく使われます)、プロキシグループ名を指定すればそのグループが出口を決定します。

GEOSITE と GEOIP のデータファイル

GEOSITE と GEOIP のルールは2つの分類データファイル(geosite.dat と GEOIP 系データ)に依存しており、これらはクライアントとともに配布され、コミュニティによって継続的に更新されています。データファイルが古くなると新しいドメインの分類が不正確になり、「本来直連すべきものがプロキシ経由になる」といった現象や、その逆の現象が起こります。主要クライアントは設定内にデータファイルの更新入口を用意しているので、購読更新と合わせて月次メンテナンスに組み込むことをお勧めします。詳細は第8章を参照してください。

実践:中国本土/海外の分流設定

典型的な中国本土/海外の分流ルール表(抜粋、順序がそのままマッチング順序です):

rules:
  # LANと予約アドレスは直連
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # 中国本土のドメインとIPは直連
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  # 残りはすべてプロキシグループに委ねる
  - MATCH,PROXY

この骨組みをベースに加減してください。特定の海外サイトを強制的にプロキシ経由にしたい場合は、GEOSITE 行の前に DOMAIN-SUFFIX,対象ドメイン,PROXY を追加します。広告系ドメインを直接遮断したい場合は GEOSITE,category-ads-all,REJECT を先頭付近に追加します。購読にルール表が付属している場合は、購読ファイルを直接編集するのではなく、クライアントの「オーバーライド/カスタムルール」機能から追記することを優先してください。購読が更新されると手動編集した内容は失われてしまいます。

分流結果の検証

ルールを変更したら必ず検証してください。クライアントの「接続」パネルを開き、対象サイトへアクセスして新しく発生した接続を確認します。パネルには、その接続が一致したルール、最終的に経由したプロキシグループとノードが表示されます。期待通りでない場合は、パネルに表示されているルール名を基に順序を見直してください。クライアントのログを debug レベルにすると、ルール判定の過程が1件ずつ出力されるため、より細かい調査に向いています。

システムプロキシには構造的な死角があります。それは「システムプロキシ設定に従う」アプリにしか効かないという点です。ブラウザや多くのデスクトップソフトはシステムプロキシを読みますが、コマンドラインツール、一部のゲーム、独自のネットワークスタックを持つアプリ、さらにほぼすべての UDP 通信はシステムプロキシを迂回して直接通信します。TUN モードはこの死角を解決するものです。

TUN とは

TUN モードはシステム内に仮想ネットワークインターフェースを作成し、ルーティングテーブルを書き換えることで、システム全体の TCP/UDP 通信をまずこの仮想インターフェース経由でクライアントに取り込み、クライアントがルールに基づいて分流します。この接管はネットワーク層で発生するため、アプリ側の対応の有無に関係なく、コマンドライン、ゲーム、システムサービス、UDP アプリすべてが分流対象になります。Android ではクライアントはもともと VPN サービスとして動作するため TUN と同等の効果があります。TUN は主にデスクトップ環境(Windows/macOS/Linux)向けの強化スイッチです。

システムプロキシとの役割分担

両者は競合せず併用できます。システムプロキシは「素直に従うアプリ」を、TUN は「従わないアプリ」を担当します。多くのクライアントは TUN を有効にするとシステムプロキシとの関係を自動的に処理するため、手動で二択にする必要はありません。普段はブラウジング中心でたまにコマンドラインを使う程度なら、システムプロキシだけで十分です。コマンドラインツールを頻繁に使う、海外サーバーのゲームをする、UDP 転送が必要という人は、TUN を常時オンにすることをお勧めします。

有効化の条件

TUN はシステムのネットワークスタックを操作するため、通常のプロキシより高い権限が必要です。Windows では主要クライアントが「サービスモード」で実現しています。クライアントの設定画面の指示に従ってサービスをインストールすれば、以降は TUN スイッチが正常に使えるようになり、クライアント本体を毎回管理者権限で起動する必要はありません。macOS では初回有効化時にシステムのパスワード入力を求められ、ヘルパープログラムのインストールを許可します。Linux デスクトップ環境でも同様の許可が必要です。サーバー上でカーネルから直接 TUN を有効にする場合は、プロセスに相応のネットワーク権限が必要です。

設定例

グラフィカルクライアントでは TUN は通常単純なスイッチですが、内部的には設定ファイルの tun セクションに対応し、手書きで書くと次のようになります:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

いくつかの重要な項目を説明します。stack は仮想インターフェースのプロトコルスタック実装で、mixed は互換性とパフォーマンスを両立させる一般的な値です。auto-route はクライアントに自動でルーティングテーブルを設定させます。auto-detect-interface は出口となる network interface を自動判定し、通信のループを防ぎます。dns-hijack はシステム内で53番ポートへ送られるすべての DNS クエリをクライアントの DNS モジュールへ横取りし、第9章の DNS 設定と組み合わせて使います。

注意事項

①他の VPN/アクセラレータとの競合:システム内に同時にルーティングテーブルを書き換える仮想インターフェースが2つ存在すると、通信の流れが予測不能になります。同時には1つだけ残してください。②ファイアウォールによる遮断:一部のセキュリティソフトは仮想インターフェースのドライバをブロックすることがあります。TUN を有効にした後にネットが切れたら、まずこの点を確認してください。③終了はきちんと:異常終了するとルーティングテーブルの項目が残ってネットが切れることがあります。クライアントを再起動して TUN を一度オフオンするか、システムを再起動すれば回復します。④すべての場面で必要なわけではない:Web ブラウジングしかしないなら TUN を有効にしないほうが、接管層が1つ減りトラブルの種も減ります。

クライアントを導入した後、実際に時間がかかるのは設定ではなくメンテナンスです。購読は更新され、データファイルは古くなり、ノードは失効し、クライアント自体も更新されていきます。本章では実践しやすいメンテナンスチェックリストと、よくある不具合の自己診断の手順を紹介します。FAQ ページにはさらに細かい問答が収録されているので、本章では体系立ったメンテナンス作業のみを扱います。

メンテナンスチェックリスト

購読の更新:24時間ごとの自動更新を有効にしておきます。ノードに大量につながらなくなった場合は、まず手動で購読を更新するのが最初の一手です。「クライアントが期限切れのノード一覧を持っている」という最も多い原因を排除できます。

GEOSITE / GEOIP データの更新:月に1回。入口はクライアントの設定内にあります。データファイルはドメインと IP の分類精度を決めるもので、長期間更新しないと分流結果が実態から徐々にずれていきます。

クライアントの更新:クライアント内に更新通知が表示されるので、それに従って更新すれば問題ありません。カーネルの更新にはプロトコル対応やセキュリティ修正が含まれることが多く、旧バージョンに長く留まることは推奨されません。更新前に旧バージョンをアンインストールする必要はなく、設定はそのまま残ります。

設定のバックアップ:購読リンクはパスワード管理ソフトや暗号化メモに別途控えておきます。手書き設定(カスタムルール、オーバーライド)はコピーをエクスポートしておきます。機種変更や再インストールの際、購読リンクとオーバーライドのバックアップがあれば完全に復元できます。

ノード失効時の対処

単一のノードにつながらない場合は、まずプロキシグループ内で手動でバックアップノードに切り替え、設定変更に走らないでください。グループ全体がタイムアウトする場合は次の順で確認します。手動で購読を更新する → グローバルモードに切り替えてルールの誤判定でないか確認する → 直連モードに切り替えてローカルネットワークが正常か確認する → ネットワーク環境を切り替える(スマホのテザリングなど)して固定回線の出口側の問題を排除する。4ステップを終えても通信できない場合は、ノード提供元に問い合わせてください。

ログと接続パネル

クライアントには2つの強力な診断ツールがあります。接続パネル:各接続のプロセス、宛先、一致したルール、出口ノード、通信量をリアルタイムに表示するので、「なぜこのサイトがプロキシを通っていないのか」がここで一目で分かります。ログ:デフォルトの info レベルでは主要なイベントのみ記録されますが、難しい問題の調査時には debug レベルに切り替えると、ルールの判定過程や DNS 解決の詳細まで確認できます。調査が終わったら info に戻してください。debug ログは量が多く、アクセス先まで記録されるため常時オンには適しません。

よくある不具合の自己診断表

自己診断表で解決しない問題はFAQ ページでカテゴリ別に確認してください。ブログのトラブルシューティングタグにも症状別にまとめた専門記事があります。例えば「Clash DNS リーク検出」など。

前8章まで進めば、日常使用に支障はありません。本章ではさらに深く学びたいユーザーに向けて、取り組む労力の少ない順にロードマップを示します。それぞれのステップには明確な目標と対応する本サイト内の資料があります。

ステップ1:購読設定のオーバーライド

購読に付属する設定は提供元が管理しているため、直接編集すると次回更新時に上書きされてしまいます。正しい方法はクライアントの「オーバーライド/Mixin」機能を使うことです。ルールの追加、プロキシグループの調整、ポート変更などの補足片段を自分で定義しておくと、購読更新のたびにクライアントが自動的にその片段を合成してくれます。「購読を使う」から「設定を管理する」への最初のステップで、労力は少なく効果はすぐに現れます。

ステップ2:ルールプロバイダー rule-providers

ルールが増えてくると、すべてを rules リストに並べるのは管理が難しくなります。mihomo は rule-providers に対応しており、あるカテゴリのルール(例えば特定アプリのドメイン全体)を独立した外部ルールセットファイルやオンラインアドレスとして用意し、設定内で名前を指定して参照できます。ルールセットは個別に更新できます。プロキシグループと組み合わせることで、「1つのアプリに1つのルールセット、1つの出口」というすっきりした構造を組み立てられます。

ステップ3:DNS モジュール

DNS は分流の正確さを支える基盤です。クライアント内蔵の DNS モジュールがドメイン解決を担い、nameserver は通常の解決サーバーを指定し、fallback は海外ドメイン向けの代替解決経路を指定し、enhanced-mode は拡張解決動作を制御します。適切に設定すれば、DNS 汚染が GEOIP 判定に与える干渉を排除し、解決リクエストがプロキシ経路の外へ漏れることを防げます。この分野は内容が多いため、ブログの2記事を直接参照してください。パラメータについては「Clash DNS 詳解」、検証と修正については「Clash DNS リーク検出」で解説しています。

ステップ4:LAN 共有とゲートウェイ

設定の allow-lan: true を有効にすると、LAN 内の他の端末(スマホ、タブレット、テレビ)がこの端末の IP と混合ポートをプロキシ先に指定して、同じクライアントを共有できるようになります。さらに踏み込んで、常時稼働するソフトルーターや常時起動端末にクライアントを配置し、TUN でセグメント全体を接管させれば、家庭用ゲートウェイ方式になります。ネットワーク内のすべての端末が個別設定なしで分流の対象になります。

ステップ5:サーバーとルーターへの mihomo デプロイ

GUI のない環境ではカーネルを直接使います。対応アーキテクチャの mihomo バイナリをダウンロードし、完全な config.yaml を用意し、systemd でプロセスを管理して自動起動とクラッシュ時の再起動を実現します。external-controller を有効にすれば、API や Web ダッシュボード経由でリモート管理できます。ノードの切り替え、接続状況の確認、ログの確認もサーバーにログインせずに行えます。ユニットファイルの例:

[Unit]
Description=mihomo proxy core
After=network.target

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

[Install]
WantedBy=multi-user.target

設定フォルダ /etc/mihomo に config.yaml と GEOSITE/GEOIP のデータファイルを配置します。設定を変更したら systemctl restart mihomo で反映し、journalctl -u mihomo でログを確認します。

継続的な学習の道筋

応用的な内容は本サイト内の3か所で継続更新されています。FAQ ページでは「基礎知識/インストール設定/使い方のコツ/トラブルシューティング」に分類してよくある質問をまとめています。ブログではカーネル、設定、DNS、トラブルシューティングの4カテゴリの専門記事を継続的に更新しています。チュートリアルページは新しい同僚や新しい端末に手順を一気通貫で説明するのに向いています。本ガイドで扱っていない場面に遭遇したら、まず FAQ のカテゴリ別ナビゲーションを確認し、次にブログのタグを確認してください。