Clash をゼロから学ぶ完全ガイド

基本概念：Clash を通るリクエストの流れを理解する

クライアント、カーネル、設定ファイルの関係

Clash は単一の画面を指す名称ではなく、カーネル、GUI クライアント、設定ファイルで構成される仕組みです。カーネルはローカルポートの待ち受け、設定の解析、ルール照合、プロキシ接続、DNS 処理を担当します。GUI クライアントはインストール、更新、設定管理、システムプロキシの切り替え、ログ表示を担います。設定ファイルには待ち受けポート、プロキシノード、プロキシグループ、ルール、DNS の動作を記述します。mihomo は Clash Meta カーネルとも呼ばれ、Clash の設定体系を引き継ぎながら、プロトコル、ルール、システム通信制御を拡張しています。3 者の境界を理解すると、トラブル対処も明確になります。画面が開かないならクライアント層、設定の読み込みに失敗するならまず YAML、特定サイトの経路が誤るならルールとプロキシグループを確認します。

一般的なブラウザーのリクエストは、まずシステムプロキシまたは TUN 仮想インターフェースに入り、その後カーネルへ渡されます。カーネルはリクエストのドメイン、宛先アドレス、ポート、ネットワーク種別を読み取り、設定内の rules を上から順に調べて最初に一致する項目を使います。一致項目は通常、特定のサーバーではなくプロキシグループを指します。プロキシグループは、現在の選択、自動テスト、フォールバックのロジックに基づき、具体的なプロキシ、直接接続、拒否のいずれかを決定します。流れは「通信の入口 → ルール照合 → プロキシグループ → 出口接続」とまとめられます。どこか一層でも設定が一致しないと、「クライアントは接続済みなのに、期待した結果にならない」状態が起こります。

待ち受けポートとシステムプロキシ

Clash の代表的な入口には HTTP、SOCKS、mixed-port があります。HTTP プロキシはシステムプロキシや手動プロキシに対応するソフトに適し、SOCKS はより汎用的な TCP 通信を扱えます。mixed-port は同じポートで HTTP と SOCKS の両方を受け付けるため、ポート数を減らせます。システムプロキシの切り替えは、OS のプロキシ先をローカルの待ち受けポートへ向けるだけで、設定ファイルのルールを変更したり、システムプロキシを完全に無視するアプリを制御したりはできません。「ブラウザーは使えるのに特定のプログラムだけ使えない」場合は、まずそのプログラムがシステムプロキシを読むか確認してください。読み込まない場合は、アプリ内でプロキシを設定するか TUN を有効にします。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

上の最小設定は、カーネルがローカルで mixed-port を待ち受け、初期状態では LAN 上の他の機器に公開せず、ルールモードで動作し、標準レベルのログを記録することを示します。ポート番号は変更できますが、変更後はシステムプロキシやアプリ側のプロキシポートも合わせて変更してください。起動ログに待ち受け失敗が出る場合、別のプロセスがそのポートを使用していることが一般的です。Clash のポート競合を特定する手順でプロセスを確認し、競合プログラムを終了するかポートを変更します。

ノード、プロキシグループ、ルールは同じ階層ではない

ノードは、サーバー、ポート、プロトコル、認証情報などを含む具体的な出口接続の定義です。プロキシグループは複数のノードや他のグループをまとめる仕組みで、ルールはリクエストをプロキシグループへ振り分けます。普段経路を切り替えるときは、ルールを何度も編集するのではなく、プロキシグループを操作するのが基本です。たとえば「プロキシ選択」という手動グループと、「自動選択」という速度テスト用グループを作り、さらに上位の「デフォルト出口」にまとめられます。動画、ダウンロード、仕事用サービスなどのルールは、安定したグループ名だけを参照します。これにより、サブスクリプションやノードを入れ替えてもルールを書き直す必要がありません。

クライアントを選ぶ：プラットフォーム、カーネル、管理方法で比較

まずは高機能 GUI クライアントを選ぶ

多くのユーザーは GUI クライアントから始めるのが適しています。本サイトでは各プラットフォーム向けに Clash Plus を第一候補としています。主要な導入手順、設定管理、接続制御を備え、初回利用から日常管理まで使いやすいクライアントです。Windows、macOS、Android、iOS のユーザーは、まずダウンロードページで対象プラットフォームに切り替え、システム要件を確認してから導入してください。選ぶ際は見た目だけでなく、現在の OS と CPU アーキテクチャへの対応、設定と互換性のあるカーネル、Profile の更新と切り替え、必要に応じたシステムプロキシや TUN の管理という 4 点を確認します。

Windows と Linux では Clash Verge Rev や FlClash、Windows では Clash Nyanpasu も選べます。Android では Clash Meta for Android、FlClash、Surfboard、macOS ではアーカイブ状態の ClashX Meta が利用できます。Clash for Windows も保守が終了したアーカイブクライアントです。アーカイブだからといって既存設定が直ちに使えなくなるわけではありませんが、新規導入の長期的な基盤には向きません。旧クライアントを使い続けている場合は、移行前に設定と上書き設定をエクスポートし、新しいクライアントで一項目ずつ復元してください。クライアント、カーネル、DNS、TUN を同時に変更すると、原因を切り分けにくくなります。

CPU アーキテクチャを見分ける

インストールパッケージ名にある x64、AMD64、ARM64、Apple Silicon などの表記は、CPU アーキテクチャの違いを示します。従来型の Windows PC の多くは x64 ですが、Windows on ARM では ARM64 ビルドの有無を確認してください。新しい Mac は Apple Silicon が主流で ARM ビルド、古い Intel Mac は x64 ビルドを使います。Android 端末では通常 arm64 パッケージを優先し、アーキテクチャが不明、またはインストールに失敗した場合に汎用パッケージを検討します。Linux は AMD64 と ARM だけでなく、deb、rpm、圧縮されたカーネルファイルも区別が必要です。デスクトップ環境では対応するパッケージ形式、サーバーやルーターでは mihomo カーネルを直接実行する構成が一般的です。

GUI クライアントと単体カーネルの境界

単体の mihomo カーネルは、起動引数、設定ディレクトリ、サービス権限、ログ出力を細かく制御したい環境に適しています。デスクトップ GUI は自動では提供されず、システムプロキシも変更しません。サーバーでは通常、コマンドラインで設定ディレクトリを指定し、システムのサービス管理機能で実行状態を維持します。サブスクリプションを読み込んで接続するだけなら、デスクトップユーザーがカーネルの圧縮ファイルから始める必要はありません。GUI クライアントはカーネルのライフサイクル、Profile の切り替え、システム設定をまとめて扱えるため、問題を特定しやすくなります。

同じ端末で複数のクライアントに同じポートを同時に使わせたり、TUN を同時に有効にしたりしないでください。移行時は旧クライアントを終了し、バックグラウンドのカーネルも停止したことを確認してから新しいクライアントを起動します。新しいクライアントがポート競合を表示しても、無作為に複数のポートへ変更し続けるのではなく、まず残存プロセスを特定します。システムプロキシが旧ポートを指している場合は、旧プロキシを無効にしてから新しいクライアントに再設定させます。「稼働中のカーネルは 1 つ、現在の設定は 1 つ、入口は 1 つ」と保つことで、相互干渉を大きく減らせます。

プラットフォーム別導入：権限、入口、初回起動を確認

Windows と macOS の導入

Windows では導入前に、同種のクライアントを終了して旧カーネルが待ち受けポートを占有しないようにします。導入して初回起動したら、すぐにすべてのスイッチを有効にしないでください。設定画面でカーネルの状態、設定ディレクトリ、mixed-port を確認してから設定を読み込みます。システムプロキシを有効にすると、クライアントはシステムプロキシのアドレスをローカルループバックアドレスと待ち受けポートに向けます。ブラウザーが古い設定を使い続ける場合は、いったんシステムプロキシを無効にしてから再度有効にします。ストアアプリや UWP アプリだけが接続できない場合は、全体のルールを変更する前に、アプリがローカルループバックへのアクセスを許可されているか確認してください。

macOS では CPU に合わせて Apple Silicon または Intel ビルドを選びます。初回起動時にシステムのセキュリティ機能で阻止された場合は、システム設定でアプリの出所と表示内容を確認してください。システムプロキシの有効化にはネットワーク設定の変更許可が必要になることがあり、TUN やネットワーク拡張では追加の許可も表示されます。許可後は、システムのダイアログが消えただけで判断せず、クライアントに戻ってスイッチの状態を確認します。旧クライアントが補助サービスを導入していた場合は、移行前に旧クライアントから正常に停止し、2 つの補助コンポーネントが同時にネットワーク設定を変更しないようにします。

Android と iOS の導入

Android クライアントは通常、システム VPN インターフェースを通じて通信を制御します。初回接続時には VPN の許可画面が表示され、許可するとステータスバーに接続状態が表示されます。アプリを切り替えるとすぐ接続が止まる場合は、バッテリー最適化、バックグラウンド動作、省電力制限を確認してください。一部メーカーの OS では画面ロック後にバックグラウンドサービスが終了するため、バックグラウンド実行を許可するリストにクライアントを追加します。アプリごとのプロキシ、LAN のバイパス、IPv6 の動作はクライアントと設定の両方で決まります。初回テストでは設定を簡素に保ち、通常のウェブページが開くことを確認してからアプリ別ルールを追加してください。

iOS で Clash Plus を使う場合は、App Store からインストールし、初回接続時に VPN 構成の追加を許可します。システム上、同時に有効にできる VPN 構成は 1 つだけです。ほかのネットワークツールが接続中なら、先に切断してテストしてください。Wi-Fi とモバイル通信を切り替えた後も接続が維持されるか観察し、実際のアクセス結果でルールの適用を確認します。モバイル OS では低レベルのログが一部隠れるため、問題が Wi-Fi、モバイル通信、または両方で起きたのか、特定アプリだけに影響するのかを記録します。

Linux デスクトップとカーネルの導入

Linux デスクトップで deb や rpm パッケージを導入しても、デスクトップ環境がシステムプロキシ設定を読み込むか確認する必要があります。HTTP、HTTPS、SOCKS の設定入口はデスクトップ環境ごとに異なり、クライアントの「システムプロキシ」ボタンがすべてのセッションを制御するとは限りません。まずブラウザーでテストし、次にプロキシ環境変数に明確に対応するコマンドで確認します。単体カーネルを導入する場合は固定の設定ディレクトリを作り、初回はフォアグラウンドで起動して YAML のエラーを端末に直接表示させます。設定を読み込めることを確認してから、サービス管理機能へ移行します。

mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

-d は作業ディレクトリを指定し、カーネルはそのディレクトリから設定と関連データを読み込みます。実行ファイル名と配置場所はダウンロードパッケージに合わせてください。長期運用する場合は権限を制限した専用ユーザーを作り、設定ファイルとログディレクトリの所有者を明確にします。権限問題を回避するためにディレクトリ全体のアクセス範囲を広げないでください。サービスの起動に失敗した場合は、サービス状態だけを見るより、同じコマンドをフォアグラウンドで実行したほうが YAML の行番号、ポート競合、リソース不足を確認しやすくなります。

初回起動後に確認する 4 項目

導入後は決まった順序で確認します。第一に、クライアントでカーネルが起動済みと表示されること。第二に、現在の Profile が選択され、解析エラーがないこと。第三に、システムプロキシまたは VPN/TUN のうち、想定した入口だけが有効であること。第四に、プロキシグループに選択可能な出口があること。その後、通常のサイトへアクセスし、接続記録でリクエストがカーネルに入り、ルールに一致して出口接続が作られたことを確認します。クライアントのトップ画面に表示される状態だけで成功と判断しないでください。システムプロキシがまだ書き込まれていない、アプリがプロキシを回避している、DNS を別のネットワーク機能が処理している可能性があります。

サブスクリプションと設定：更新・復元できる Profile を作る

Profile は完全な設定の入口

Profile はローカルの YAML ファイルから読み込むことも、リモートのサブスクリプション URL から取得することもできます。単なるノード一覧ではなく、プロキシグループ、ルール、DNS、上書き設定を含む場合があります。リモート URL を読み込むと、クライアントは通常その内容をローカルコピーとして保存し、更新元も記録します。その後の更新で、同じ Profile に加えた手動変更が上書きされる可能性があるため、自動更新ファイルへ長期的なカスタマイズを直接書き込むのは避けてください。元のサブスクリプションを基盤として残し、クライアントの上書き機能、スクリプト、別管理のローカル設定でルールを追加する方法が安全です。

複数の Profile を管理する場合は、「日常ルール」「モバイル回線テスト」「ローカル最小構成」のように用途が分かる名前を付け、読み込み時刻だけを残さないようにします。Profile を切り替えるとカーネルが設定を再読み込みし、プロキシグループの選択はその Profile 固有の状態に戻ることがあります。切り替え後は現在のファイル名、モード、主要なプロキシグループを確認し、画面上は切り替わっていても実際には前の設定を使っている状態を防ぎます。複数設定の更新関係と切り替えについては、Clash Profile の読み込みと複数設定の管理も参照してください。

YAML の構造とインデント

Clash の設定には YAML を使います。インデントが階層を示すため、通常はスペースを使い、タブを混在させないでください。リスト項目はハイフンで始まり、キー名の後のコロンは値との構造を正しく保つ必要があります。名前にコロン、シャープ、コンマなどの特殊文字が含まれる場合は、引用符で囲むと安全です。設定の読み込みに失敗したら、まずログの行番号を確認し、その行と上の階層を調べます。実際の原因は、直前のリスト項目のインデント不足であることがよくあります。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: "プロキシ選択"
    type: select
    proxies:
      - "自動選択"
      - DIRECT

  - name: "自動選択"
    type: url-test
    proxies:
      - DIRECT
    url: "https://www.gstatic.com/generate_204"
    interval: 300

rules:
  - GEOIP,LAN,DIRECT
  - MATCH,プロキシ選択

この断片は階層関係を示すもので、「自動選択」グループには DIRECT しかないため、構文説明を目的としています。実際のノードは通常、サブスクリプションやプロキシプロバイダーから書き込まれます。MATCH は最後のフォールバックルールなので、ルール一覧の末尾に置きます。その前にあるルールが LAN やその他の明確な宛先を優先して処理します。プロキシグループ名は、スペースや大文字・小文字を含め、ルールで参照する名前と完全に一致させてください。名前を変更した後にルールを同期し忘れると、設定の読み込みに失敗したり、存在しないプロキシへ送られたりします。

リモート更新とローカル上書き

サブスクリプションの更新に失敗したら、まず「URL にアクセスできない」「サーバーがエラーを返した」「有効な YAML ではない」「クライアントの書き込みに失敗した」を切り分けます。更新ログのネットワーク状態と解析結果を確認してください。更新ボタンを連続して押しても、URL、権限、形式の問題は解決しません。古いコピーが使えるなら、まず現在のアクティブ設定を保持し、更新元を個別に調べます。更新後にノードだけ変わりルールが変わらないなら、設定の提供方式による違いです。プロキシグループ名まで変わった場合は、ローカルルールの参照も合わせて修正する必要があります。

上書き設定には、ローカルポート、LAN アクセス、DNS の優先設定、少数の固定ルールを置くのが適しています。ただし、上書きが読み込み前と読み込み後のどちらに適用されるかを記録してください。同名フィールドは後から適用されたものが前を上書きすることが多く、リスト項目は置換、先頭追加、末尾追加になる場合があります。具体的な動作はクライアントによって異なります。変更前に動作する設定をエクスポートし、変更後は一種類だけ変えてすぐ再読み込みします。ポート、DNS、ルール、TUN を同時に変更すると、障害の原因を特定しにくくなります。

プロキシモード：Rule、Global、Direct の適用範囲を理解する

日常利用の標準は Rule モード

Rule モードはルールを上から順に読み取り、リクエストを一致したプロキシグループへ渡します。LAN、通常の直接接続先、プロキシ対象、拒否対象を分けて処理できるため、長期利用に適しています。ルールは上から下へ調べ、最初に一致した時点で停止するため、数より並び順が重要です。完全なドメインはドメインサフィックスより前に、プライベートネットワークのアドレスは一般的な IP ルールより前に置き、最後に MATCH で未一致の通信を処理します。

Rule モードの「プロキシ選択」はモード切り替えではなく、プロキシグループの現在の出口です。グループ内では具体的なノード、自動テストグループ、DIRECT を選べます。特定サイトの経路が誤る場合は、まず接続記録で一致したルールとプロキシ名を確認し、Global モードへ切り替えないでください。Global モードはノード自体の可用性を素早く判断する用途には使えますが、元の分岐ロジックを迂回するため、ルール設定が正しい証明にはなりません。

Global モードはルール問題の切り分けに使う

Global モードでは通常、カーネルに入った通信をすべてグローバルプロキシグループへ送ります。短時間の診断に適しており、Rule モードでは失敗するが Global モードで同じノードにより成功するなら、原因はルール、DNS の解決結果、プロキシグループの参照にある可能性が高くなります。両方で失敗する場合は、ノード、宛先ネットワーク、待ち受け入口、システム権限を確認します。診断後は Rule に戻し、LAN、ソフトウェア更新、ローカルサービスまで不要にプロキシへ送らないようにします。

Global モードにしても、もともとカーネルに入っていない通信が自動的に入るわけではありません。システムプロキシを無視するアプリは、Global に切り替えても直接接続する場合があります。このとき接続記録にアプリのリクエストが表示されないことが一般的です。アプリ自身のプロキシ設定を確認するか、必要性を確認した上で TUN を有効にします。重要なのは、モードが決めるのは「カーネルに入った後の処理方法」であり、システムプロキシと TUN が決めるのは「リクエストがカーネルに入るかどうか」だという点です。両者は代替関係ではありません。

Direct モードと本当の終了

Direct モードでは通常、カーネルに入ったリクエストを宛先へ直接接続します。比較テストには適していますが、クライアントを完全に終了した状態とは異なります。システムプロキシが Clash を指したままの場合や、DNS をカーネルが処理している場合があり、アプリの接続記録も残ります。OS 本来のネットワーク経路へ戻すには、まずシステムプロキシまたは TUN を無効にしてからカーネルを停止します。クライアントに「システムプロキシを復元」機能がある場合は、クライアントから正常に実行し、無効なローカルプロキシアドレスを残さないようにします。

遅延値は相対的な目安として使う

プロキシグループの遅延テストは通常、固定 URL へ接続してノードの到達性を確認し、特定のテスト経路を比較するものです。すべてのサイトの実際の所要時間を示すわけではなく、帯域幅、パケットロス、接続再利用、DNS、混雑、宛先サーバーの状態も完全には反映しません。自動テストグループには、安定して応答本文が小さいテスト URL を選び、適切な間隔を設定します。間隔が短すぎると余分な接続が増え、長すぎると経路の変化を検知できません。詳しい仕組みはClash の遅延テスト値を読み解くを参照してください。

ルール分岐：一致順序からカスタムポリシーまで

代表的なルールタイプ

DOMAIN は完全なドメイン名に一致し、単一ホストの指定に適しています。DOMAIN-SUFFIX はドメインとサブドメインに一致し、同一系統のサービスをまとめて対象にできます。DOMAIN-KEYWORD はドメイン内のキーワードで一致するため範囲が広く、配置には注意が必要です。IP-CIDR と IP-CIDR6 はアドレス範囲、GEOIP は IP データベースによる分類、PROCESS-NAME は対応プラットフォームでプログラム名、RULE-SET は外部ルールセットを参照します。最後の MATCH は、それまでに一致しなかったすべてのリクエストを受け取ります。

ドメインルールは通常、DNS が宛先アドレスを返す前に判定できますが、IP ルールは解決結果や実際の宛先アドレスに依存します。ドメイン情報を持たず IP へ直接接続する通信は、IP ルールまたはフォールバックルールで処理します。no-resolve を有効にすると、一部の IP ルールが一致判定のために追加の名前解決を行うのを防げますが、適用可否はルールタイプと目的によって異なります。ルール作成では対象数を増やすことだけを目指さず、先にプロキシグループの役割を定義し、安定した役割名をルールから参照してください。

rules:
  - DOMAIN,updates.example.test,DIRECT
  - DOMAIN-SUFFIX,example.test,プロキシ選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,LAN,DIRECT
  - MATCH,プロキシ選択

例では予約されたテスト用ドメインを使って構文を示します。最初の完全なドメインルールが後続のサフィックスルールより優先されるため、更新ホストは直接接続し、同じサフィックスを持つ他のホストは「プロキシ選択」へ送られます。プライベートアドレス範囲は直接接続のままにし、最後は MATCH でフォールバックします。実際の設定ではローカルネットワークに必要なアドレス範囲を追加し、LAN サービスがリモート出口へ送られないことも確認してください。

ルールの順序が最終結果を決める

Clash はすべてのルールから「最も具体的な 1 件」を探すのではなく、最初に一致したルールを使います。そのため、広い範囲の DOMAIN-SUFFIX を前に置くと、後ろにある完全なドメインの例外は一致できません。MATCH を前方に置けば、それ以降のルールはすべて無効になります。ルールを調整するときは、まず接続記録で対象ドメイン、対象アドレス、現在の一致項目を確認し、競合する広域ルールより前に例外ルールを置きます。

ルールセットも、配置された位置の順序に従います。複数のルールセットを参照する場合は、それぞれの対象範囲と更新元を明確にしてください。役割が重複するセットを大量に読み込むと、同じドメインが前のセットに先に捕捉され、後続ルールを理解しにくくなります。「ローカルとプライベートネットワーク、明確な直接接続、明確なプロキシ、特定サービス、アドレスルール、最終フォールバック」のように分け、変更後は代表的な宛先で接続記録を確認します。

プロキシグループの設計はルールの積み重ねより重要

代表的なプロキシグループには select、url-test、fallback、load-balance があります。select はユーザーが手動で選び、url-test は候補の出口を定期的に比較し、fallback は利用可能な項目を順番に選び、load-balance は複数の出口へ接続を分配します。自動テストがすべての用途に適するわけではありません。固定出口が必要なログインセッションには手動グループが適し、継続性が重要なダウンロードも頻繁に切り替えるべきではありません。まず「手動選択」と「自動選択」を作り、仕事、メディア、ダウンロードなどの用途別に上位グループを構成するとよいでしょう。

プロキシグループは他のプロキシグループを参照して階層化できますが、深くしすぎるとトラブル対処の負担が増えます。業務ルールは少数の安定した上位グループだけを参照し、下位ノードの変化はサブスクリプションと自動グループに任せる構成がおすすめです。グループを削除する前に名前を全文検索し、ルール、プロキシプロバイダー、他のグループから参照されていないことを確認します。カスタムルールの詳しい編集方法は実際の設定に合わせて使い方ガイドを確認し、mihomo へ移行する場合はmihomo カーネルの機能と設定差分も参照してください。

DNS と TUN：システム制御と名前解決を扱う

システムプロキシに加えて TUN が必要な理由

システムプロキシの影響を受けるのは、明示的にプロキシ設定を読むアプリだけです。ゲーム、一部のコマンドラインツール、独立した更新プログラム、特殊なネットワークスタックを使うアプリは、直接接続することがあります。TUN は仮想ネットワークインターフェースを作り、ルーティング条件に合う IP 通信をカーネルへ送るため、より広い範囲を制御できます。その一方で、管理者権限、ルーティングテーブル、DNS ハイジャック、仮想インターフェース、他の VPN、セキュリティソフトが結果に影響します。初めて TUN を有効にする前に、まず通常のシステムプロキシを Rule モードで安定させ、TUN は別の段階としてテストしてください。

TUN を有効にしてウェブページがすべて開けなくなった場合は、まずカーネルログで仮想インターフェースの作成に成功しているか確認し、次にデフォルトルートと DNS を調べます。LAN 機器だけに到達できない場合は、プライベートアドレスが TUN をバイパスしているか、ローカルセグメントのルートが保持されているか、ルールで LAN アドレスを DIRECT にしているかを確認します。TUN を無効にしてもネットワークが戻らない場合は、クライアントを終了し、仮想インターフェースや無効なプロキシ設定が残っていないか確認してください。障害中に複数の VPN ツールを繰り返し切り替えると、同じルートを書き換え続ける可能性があります。

DNS モードとリクエスト経路

DNS はドメイン名をアドレスへ変換する方法を決め、ドメインルールが接続と正しく関連付けられるかにも影響します。システム DNS が Clash の外側で処理されると、名前解決が想定した上流を迂回することがあります。アプリが独自に暗号化 DNS を使う場合、カーネルからは宛先アドレスしか見えないこともあります。Clash の DNS 設定では、待ち受け、有効状態、IPv6、拡張モード、デフォルトリゾルバー、上流サーバーを指定できます。上流は到達性と用途の両方を考慮して選び、アドレスを無計画に増やさないでください。設定が複雑になるほど、各リゾルバーがどの段階を担当するかを記録する必要があります。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - "https://dns.alidns.com/dns-query"

fake-ip モードは、ドメインに予約アドレス範囲のマッピングアドレスを返し、後続の接続でもドメインとの関係を保持することでルール照合を容易にします。LAN サービス、デバイス検出、ログイン認証、解決結果に特殊な要件があるドメインでは fake-ip が適さない場合があり、フィルターリストへの追加が必要です。フィルター項目を無制限に増やさず、追加前に障害が本当に fake-ip マッピングによるものか確認し、対象ドメインを記録してください。redir-host に変更すると名前解決と接続の動作が変わるため、切り替え後はシステムとアプリの DNS キャッシュを消去して比較します。

TUN 設定の主要フィールド

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - "any:53"
    - "tcp://any:53"
  auto-route: true
  auto-detect-interface: true
  strict-route: false

stack は TUN が使うネットワークスタックの実装を決め、mixed は異なる通信を両立する用途でよく使われます。dns-hijack は標準の 53 番ポートへの DNS リクエストをカーネルへ渡し、auto-route は必要なルートを自動追加し、auto-detect-interface は現在の出口インターフェースを検出します。厳格なルーティングは一部の迂回を減らせますが、仮想マシン、コンテナ、LAN 共有、他の VPN と競合することがあります。これらの項目は一つずつ変更してテストし、プラットフォーム固有のパラメーターを大量に含む設定をそのままコピーしないでください。

Windows では TUN に権限昇格や補助サービスが必要になることがあり、macOS ではネットワーク拡張や შესაბამისする許可が必要です。Linux では TUN デバイスへのアクセスとルート変更の権限、モバイル端末では通常システム VPN インターフェースが必要です。同じ YAML でも、プラットフォームによって許可条件は完全には一致しません。問題が起きたら、「設定の構文が正しいこと」と「OS が実行を許可していること」を分けて確認します。

名前解決が想定どおり動いているか確認する

DNS のトラブル対処では、システム側とカーネル側を同時に観察します。まずシステムの DNS リクエストが Clash に入っているか確認し、次にカーネルがどの上流を選び、どの種類の結果を返したかを見ます。最後に、宛先接続がどのルールに一致したか確認します。検査サイトの単発結果は、ブラウザーのセキュア DNS、キャッシュ、IPv6、ネットワーク出口の影響を受けるため、1 つの結論だけで判断できません。ブラウザーを変える、ブラウザー独自の DNS を無効にするなどして再テストし、接続ログを比較してください。詳しい確認手順はClash の DNS 漏洩検査と防止設定を参照してください。

日常管理：更新、バックアップ、ログ、障害の切り分け

復元できる更新手順を作る

クライアント、カーネル、サブスクリプション、ルールセットは異なる 4 種類の更新対象です。これらを同時に更新しないでください。安全な順序は、まず現在動作している設定をバックアップし、主要なプロキシグループの選択を記録することです。その後、サブスクリプションだけを更新して検証し、必要に応じてクライアントやカーネルを更新し、最後に外部ルールセットを更新します。各段階で起動、解析、接続、ルール一致を確認します。互換性の問題が起きても、どの層が変わったのか特定でき、直前の正常状態へ戻せます。

バックアップには少なくとも、ローカル Profile、上書きルール、スクリプト、プロキシグループ名、重要な DNS/TUN 設定を含めます。サブスクリプション URL は更新元にすぎず、ローカルバックアップの代わりにはなりません。リモート内容が変わった後に再取得しても、元の状態へ戻せない場合があります。バックアップは用途と日付で整理し、クライアントが重複コピーを同時にスキャンしないようにします。復元時は、システムプロキシと TUN を無効にした状態で設定を読み込めることを確認し、段階的に通信制御を戻してください。

ログレベルと接続記録

info は日常利用に適しており、起動、設定の読み込み、主な接続情報を確認できます。ルールやネットワークの詳細を調べるときは一時的にログの詳細度を上げますが、大量の詳細ログを長期間残すとディスク書き込みと確認の負担が増えます。ログは時刻を軸に調べます。問題を起こした具体的な操作を記録し、同じ時間帯の DNS、ルール、プロキシ、接続エラーを探してください。最後の 1 行だけを切り取っても不十分なことがあります。根本原因が、その前の設定再読み込みやインターフェース作成にある場合があるためです。

接続記録は、3 つの疑問に答えるために役立ちます。リクエストがカーネルに入ったか、どのルールに一致したか、最終的にどの出口を使ったかです。記録がなければシステムプロキシ、TUN、アプリ自身のネットワーク設定を確認します。ルールが想定と違えば、ドメイン、アドレス、順序を確認します。出口が正しいのに接続できない場合は、ノード、宛先サービス、ネットワーク環境を調べます。断続的な問題では、発生時のネットワーク、Profile、モード、プロキシグループの選択を記録し、再現前に設定を何度も切り替えないようにします。

よくある障害を階層ごとに対処する

ポート競合は、起動時に最もよくある問題の 1 つです。ポートを変更する前に使用中のプロセスを確認してください。旧 Clash カーネルが占有している場合は、旧プロセスを正常に終了し、異なるポートで 2 つのインスタンスを長期共存させないようにします。DNS の問題は、一部のサイトだけ失敗する、ルール一致が不自然になる、ネットワーク切り替え後だけ一時的に直る、といった形で現れます。この場合は、名前解決の失敗、解決結果が想定外、宛先アドレスへの接続失敗を切り分けてください。3 つはそれぞれ対処すべき層が異なります。

読みやすく移行しやすい設定を保つ

プロキシグループ名は安定して分かりやすくし、ルールは役割ごとに分け、外部ルールセットには出所と用途を記録します。すでに無効なノード、重複ルール、未使用のプロキシグループを大量に残さないでください。整理後は設定チェックまたはクライアントの再読み込みで構文を確認し、代表的な宛先をいくつか検証します。クライアントを移行する場合は、旧クライアントのシステムプロキシと TUN を無効にし、設定をエクスポートしてから新しいクライアントへ読み込み、上書き機能を確認します。クライアントごとにデータベース、キャッシュ、画面状態の互換性が異なるため、アプリのデータディレクトリ全体をそのままコピーしないでください。

日常利用では、「最小限の動作設定」を診断基準として 1 つ残しておくと便利です。そこには待ち受けポート、明確な出口 1 つ、簡単なプロキシグループ、LAN の直接接続、MATCH だけを含めます。複雑な設定で障害が起きたら、まず最小設定でクライアントと通信入口が正常か確認し、その後 DNS、ルールセット、TUN を段階的に追加します。数千行の設定から無作為に項目を削除するより信頼性が高く、問題が基礎環境と追加設定のどちらにあるかも判断しやすくなります。

高度な設定への道筋：安定運用から保守しやすい構成へ

第 1 段階：基本の入口を固定する

高度な設定の出発点はルールを増やすことではなく、基本の入口を予測可能にすることです。mixed-port を固定し、LAN アクセスを許可するか明確にし、日常利用の Rule モードを決め、システムプロキシと TUN を複数クライアントが同時に制御しないようにします。最小限の Profile を作り、設定ディレクトリ、クライアント名、カーネル種別を記録します。完了後は、リクエストがどこから入り、現在どの設定を使い、デフォルトのプロキシグループが何で、クライアント終了後にシステムネットワークをどう復元するかを説明できる状態にします。

この段階ではテスト方法も確立します。LAN アドレス、直接接続が期待される宛先、プロキシ接続が期待される宛先を 1 つずつ選び、接続記録を観察します。テスト中はノードとネットワークを固定し、変更するパラメーターは 1 つだけにします。基本入口がまだ安定しないなら、リモートルールセット、複雑な DNS、プロセスルールを急いで追加しないでください。観察対象が増えてしまいます。

第 2 段階：プロキシグループとルールを再構成する

ノード層、選択層、業務層を分けます。下層ではサブスクリプションがノードを提供し、中層では手動選択、自動選択、障害時のフォールバックを作り、上層では「デフォルト出口」「仕事用サービス」「ダウンロード」など用途別の安定したグループを構成します。業務ルールは上層の名前だけを参照します。サブスクリプションのノードが変わっても中層と上層の構造を書き直す必要はなく、経路を一時的に切り替える場合もルールファイルではなくプロキシグループだけを操作できます。

次にルールの順序を整理します。まずプライベートネットワークと明確な例外、次に業務ルールセットとドメインルール、その後にアドレスルール、最後に MATCH を置きます。ルールセットを追加するたびに、対象範囲、更新頻度、使用するプロキシグループを記録します。2 つのセットの範囲が大きく重なるなら、役割が明確な一方だけを残します。頻繁に変わる例外は小さなローカルルールとして管理し、広範囲のルールセットより前に置きます。

第 3 段階：プロキシプロバイダーとルールプロバイダー

ノードとルールを別々に更新したい場合は、プロキシプロバイダーとルールプロバイダーを使い、大きなリモート内容をメイン設定から分離できます。メイン設定にはポート、DNS、プロキシグループ、参照関係を残し、プロバイダーが外部ファイルを一定間隔で更新します。分離すると保守しやすくなりますが、ダウンロード失敗、パスの権限、形式の互換性などの確認項目が増えます。プロバイダーの更新に失敗すると、カーネルは通常キャッシュを使おうとするため、キャッシュディレクトリを書き込み可能にし、直近の利用可能な内容を保持してください。

rule-providers:
  local-service:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/local-service.yaml
    url: "https://example.invalid/rules/local-service.yaml"
    interval: 86400

rules:
  - RULE-SET,local-service,DIRECT
  - MATCH,プロキシ選択

例の URL は構造を示すための予約テストアドレスです。実際に使う場合は、ルールファイルの動作タイプと内容を一致させます。domain はドメイン集合、ipcidr はアドレス範囲、classical は完全なルール式に適しています。パスはカーネルが書き込み可能な作業ディレクトリに置きます。プロバイダー名も安定したインターフェースなので、変更後はすべての RULE-SET 参照を同期して修正してください。

第 4 段階：プラットフォームごとにプロセスと LAN を扱う

プロセスルールは、OS とカーネルがプロセス情報を取得できるかどうかに依存し、プラットフォームによって対応状況が異なります。使用前に接続記録でプロセス名を確認できるか調べてから PROCESS-NAME ルールを作成してください。プロセスパス、ストアアプリのパッケージ、子プロセスが一致結果に影響するため、画面上のアプリ名だけで判断しないようにします。モバイル端末では、システム権限とアプリ識別子をクライアントが直接扱うため、クライアントのアプリ別プロキシ画面を使うほうが適しています。

LAN 共有では、allow-lan、待ち受けアドレス、ファイアウォール、アクセス制御を同時に考慮します。allow-lan を有効にしただけで他の端末から接続できるとは限りません。端末側のファイアウォールがポートを遮断することがあります。反対に、すべてのインターフェースで待ち受けるとアクセス範囲が広がります。本機だけで使うなら LAN アクセスは無効のままにしてください。共有が必要な場合は信頼できるネットワークに限定し、他の端末が使う本機の LAN アドレスとポートを明確にします。TUN 使用時もプライベートネットワーク範囲を直接接続にして、プリンター、ストレージ、開発サービスがプロキシへ送られないようにします。

第 5 段階：変更履歴と検証チェックリストを作る

長期運用する設定には、簡単な変更履歴が必要です。変更ごとに目的、項目、検証対象、復元方法を記録します。たとえば「特定の完全なドメインに直接接続の例外を追加し、対応するサフィックスルールより前に配置。トップページとダウンロード API を確認。異常時はその行を削除して再読み込み」のように書きます。説明のないコピーを複数保存するより、こうした記録のほうが役立ちます。問題発生時も、設定全体を読み直すのではなく変更順に原因を追えます。

最終チェックリストには、クライアント起動、Profile の読み込み、システムプロキシ、TUN、DNS、LAN、直接接続先、プロキシ接続先、プロキシグループ切り替え、サブスクリプション更新、ルールセット更新を含めます。小さな変更のたびにすべてを実行する必要はありませんが、入口、DNS、TUN を変更した場合は完全な確認を行ってください。テスト後はログに継続的な再試行、名前解決失敗、インターフェースエラーがないか確認します。表面上アクセスできても、繰り返し発生するエラーはネットワーク切り替え時に一気に現れる可能性があるため、解消しておきます。

次に読む記事と実践の順序

このガイドを終えたら、目的に応じて次の手順を選べます。基本接続を早く整えたい場合は使い方ガイドに戻って最短手順を確認します。クライアントを入れ替える場合はプラットフォーム別ダウンロード入口でアーキテクチャとシステム要件を確認します。ポートエラーは待ち受けポートのトラブル対処、DNS の異常はDNS の検査と修正、複数設定の管理はProfile の管理方法、旧設定の移行はmihomo の設定差分を参照してください。

ゼロから安定運用へ進む鍵は、最初から複雑な設定を完成させることではありません。層ごとに進めることです。まずクライアントとカーネルを安定して起動し、更新できる Profile を作ります。次に Rule、Global、Direct を理解してカスタムルールを記述します。その後、システムプロキシを動かしてから TUN を有効にし、DNS のリクエスト経路を確認してから拡張モードを調整します。最後にプロバイダー、プロセスルール、自動管理を導入します。各層で復元可能な状態を残せば、クライアント、サブスクリプション、ネットワーク環境が変わっても設定を保守できます。