From zero to advanced

Clashをゼロから使いこなす：クライアント・サブスクリプション・ルール分岐

実際の操作手順に沿って構成したリファレンスです。プロキシクライアントとmihomoカーネルの関係から始め、インストール、サブスクリプション、モード選択、ルール分岐、TUNによるシステムトラフィックの取り込み、メンテナンスとトラブル対処まで段階的に解説します。基本的なインストールを終え、全体像を理解したい方に適しています。

体系的な解説 設定ファイルとYAML Windows · macOS · Linux · Android
クイックスタートを見る クライアントを選ぶ
まず読み方を決める

初回接続だけを完了したい場合は、まずクイックスタートガイドをご覧ください。「インストール、導入、接続、確認」の4ステップで操作をまとめています。この記事は初回起動後に章ごとに読み進め、各設定項目の動作を理解したり、問題が起きた際に該当箇所を確認したりするのに適しています。

1. 基本概念：クライアント、カーネル、通信経路

Clashを理解する第一歩は、設定項目を暗記することではなく、クライアントの画面、プロキシカーネル、外部サブスクリプションサービスという3つの層を区別することです。クライアントは設定ファイル、ポリシーグループ、接続状態、システム設定を表示・操作します。mihomoはYAMLの解析、ルール照合、プロキシ接続の確立を担う実際のカーネルです。サブスクリプションサービスは、1つまたは複数のノードとポリシー設定を提供します。ソフトウェアによって画面上の名称が似ていても、カーネル、設定形式、システムトラフィックの取り込み方が異なれば、操作結果も変わる可能性があります。

通常のウェブリクエストは、まずアプリケーションからシステムのネットワークスタックへ渡され、クライアントで有効にしたシステムプロキシ、拡張モード、またはTUNによる取り込み方式に応じてカーネルへ入ります。カーネルは現在の設定を読み込み、DNS、ルール照合、ポリシーグループの選択、送信接続の順に処理し、最後に応答をアプリケーションへ返します。ルールモードでは、ドメインを先にDNS解決する場合もあれば、ドメイン名のまま照合する場合もあります。実際の動作はDNSモード、スニッフィング設定、設定ファイルの書き方によって決まります。そのため、「クライアントが起動している」ことは、すべてのアプリがプロキシ経由になっていることを意味しません。

1.1 設定ファイル、プロキシグループ、ノードの違い

ノードは、サーバーアドレス、ポート、プロトコル関連のパラメーターを含む具体的な送信接続の定義です。プロキシグループは、複数のノードや他のポリシーグループから選択する仕組みで、手動選択、自動選択、フォールバック、ロードバランシングなどがあります。設定ファイルは、プロキシ、プロキシグループ、ルール、DNS、ポートなどをまとめたものです。1つのノードを複数のプロキシグループから参照でき、プロキシグループを別のプロキシグループのメンバーにすることもできます。ポリシーグループ名は表示されるのに利用可能な選択肢がない場合、ノードの解析に失敗しているか、グループ内の参照名と実際のプロキシ名が一致していない可能性があります。

「プロキシポート」と「混合ポート」も混同してはいけません。HTTPポートはHTTPプロキシリクエストのみを受け付け、SOCKSポートはSOCKSリクエストを受け付けます。混合ポートは通常、代表的な2種類のプロトコルを同時にサポートします。システムプロキシには、混合ポートまたはクライアントが明示するHTTPポートを指定すれば十分です。制御ポートを誤ってシステムプロキシに指定すると、ブラウザーには接続失敗と表示されても、クライアント自体は動作し続けることがあります。制御ポートは外部APIや画面との通信に使うもので、通常のウェブトラフィックは処理しません。

1.2 観察可能な確認手順を先に作る

トラブル対処では、「アプリがリクエストを送ったか、システムがリクエストをクライアントへ渡したか、クライアントがルールにマッチさせたか、ポリシーグループが有効な送信先を選んだか、リモート接続が成功したか」の順に確認するのがおすすめです。最初からDNSやルールを大量に変更しないでください。まずクライアントの接続一覧、ログ、リクエスト一覧で対象ドメインを確認します。一覧に記録がまったくなければ、システムプロキシ、TUN、またはアプリ自体のプロキシ対応に問題がある可能性が高いです。リクエストはあるもののルールがDIRECTにマッチするなら、現在のルールどおりの動作なので、ルールの順序を確認します。プロキシグループにマッチしてもすべて接続に失敗する場合は、ノード、ネットワーク、TLSの確認へ進みます。

概念の境界

Clashクライアントは、設定に従ってネットワーク接続を処理する役割を担います。サブスクリプションサービスの可用性、ノードの利用権限、サービス規約は各サービス提供者の責任範囲です。設定が空、期限切れ、または解析不能で返される場合は、まずサブスクリプションURLとアカウント状態を確認してください。

2. クライアントの選定：プラットフォーム、カーネル、取り込み範囲で選ぶ

クライアントは、まずプラットフォームと利用範囲を確認し、その後に画面の好みを検討します。Windows、macOS、Linuxでは、システムプロキシ、設定管理、ログ確認に対応したデスクトップクライアントが一般的です。AndroidではモバイルOSのVPNインターフェースへの対応が必要で、iOSではApp StoreからClash Plusをインストールします。サーバー、透過ルーター、長時間のバックグラウンド動作が必要な環境では、mihomoカーネルを直接使う方法が適しています。ただし、デスクトップクライアントのGUI設定画面はないため、運用の難度は高くなります。

当サイトのダウンロードページでは、各プラットフォームの先頭にClash Plusを掲載しています。対応範囲が比較的広く、統一した操作方法を使いたいユーザーに適しているためです。Clash Verge Rev、FlClash、Clash Nyanpasu、ClashX Metaなど、他のクライアントにもそれぞれ得意なプラットフォームがあります。開発が終了したソフトウェアが旧端末で動作する場合でも、新規インストールの第一候補にはしないほうがよいでしょう。インストール前にシステムアーキテクチャとパッケージ形式を確認してください。Windowsではインストーラーや圧縮ファイル、macOSではIntel版とApple Silicon版、Linuxではディストリビューションが対応する形式を区別します。

2.1 インストール前に確認する3項目

1つ目はプラットフォームのアーキテクチャです。WindowsのARM64端末では、AMD64専用プログラムをそのまま使えません。macOSでもApple Silicon版とIntel版を混在させないでください。2つ目はクライアントの実行権限です。システムプロキシ、スタートアップ起動、TUNには追加のシステム権限が必要な場合があります。インストーラーが起動できても、これらの権限が許可されているとは限りません。3つ目は設定の入手元です。信頼できるサブスクリプション画面からURLだけをコピーし、ウェブページのURL、管理画面のURL、説明文を含む全文をサブスクリプション欄へ貼り付けないようにします。

ダウンロードが完了したら、まずクライアントを起動し、システムプロキシ、TUN、ブラウザー拡張機能を同時に有効にしないでください。画面が読み込まれ、設定ファイルまたは空の設定一覧が表示されることを確認してから、次の設定へ進みます。こうすると各手順で変数が1つに絞られ、インストール、導入、システムによる取り込みのどこで問題が起きたかを特定しやすくなります。インストール先、ログ、設定の保存場所はクライアントごとに異なります。端末を移行する場合は、クライアントのエクスポート機能を優先し、形式不明のキャッシュディレクトリを直接コピーしないでください。

2.2 GUIクライアントとカーネルの直接実行

GUIクライアントは、設定更新、ポリシーグループの切り替え、接続ログ、システムプロキシの操作ができるため、個人用パソコンに適しています。カーネルの直接実行は、ルーター、サーバー、コンテナ環境に向いています。設定をファイルとコマンドで管理でき、デスクトップ層への依存を減らせる一方、プロセス監視、ファイル権限、ログローテーション、ルーティング転送を自分で処理する必要があります。両者の設定概念は共通していますが、デスクトップ画面のすべてのボタンが、そのまま使えるコマンドライン引数に対応するとは限りません。

利用シーン 優先する選択肢 インストール後にまず確認すること
WindowsまたはmacOSの日常利用 Clash Plus、Clash Verge Rev、FlClash システムプロキシ、設定の読み込み、ログの場所
Linuxデスクトップ Clash Verge Rev、FlClash デスクトップのプロキシ環境変数、権限、ディストリビューションのパッケージ形式
Androidスマートフォン Clash Plus、Clash Meta for Android、FlClash VPN権限、バッテリー制限、アプリごとのプロキシ範囲
サーバーまたはルーター mihomoカーネル プロセス監視、待受アドレス、転送、ファイアウォールルール

3. サブスクリプションの導入：設定の生成、更新、ロールバック

サブスクリプションURLは、本質的には設定内容を返すURLです。クライアントがURLへアクセスすると、完全なYAML、エンコードされたノード一覧、またはクライアント種別に応じてサーバーが生成した設定が返されます。導入時はクライアントの「サブスクリプション管理」「設定ファイル」などの入口を使い、URLを通常のノードとして1つずつ追加しないでください。初回導入後は、設定名、プロキシ数、ポリシーグループ、ルールが表示されることを確認してから有効化します。

サブスクリプションを導入する前に、現在利用できる設定を1つ保存しておくことをおすすめします。多くのクライアントは更新時に古いファイルを上書きするため、新しい内容が空、形式不正、またはポリシーグループ名の変更を含む場合、バックアップから動作状態へ戻せます。更新時は更新ボタンの成功表示だけで判断せず、設定の詳細を開いて更新日時、解析状態、プロキシグループのメンバーを確認してください。サーバーがHTTP成功を返していても、本文がログインページやエラーメッセージの場合があります。この場合、クライアントは解析失敗としか報告しないことがあるため、実際の原因はサブスクリプションURLのレスポンス内容から判断します。

3.1 導入後に行う最小限の確認

1つ目は、プロキシグループにメンバーがあるかです。代表的なグループ名には「ノード選択」「Proxy」、サービス提供者が設定した独自名などがあります。名前が違っても機能が異なるとは限りません。2つ目は、グループの現在の選択先が実在するノード、または利用可能な子ポリシーグループになっているかです。削除済みの名前を選んだままにしないでください。3つ目はルールの有無です。ルールのない設定でもグローバルモードなら動作しますが、ルールモードでは多くのリクエストがデフォルトのポリシーへ流れる可能性があります。4つ目はDNS設定が現在のネットワーク環境に適合しているかです。特にfake-ipを有効にすると、LAN機器や一部のローカルサービスに追加ルールが必要になる場合があります。

サブスクリプション更新は、頻繁であるほどよいわけではありません。更新では設定の再ダウンロード、プロキシグループの再構築、ノードのヘルスチェックが行われる場合があります。日常利用ではサービス提供者の推奨に従って更新し、設定が安定しているなら画面に通知が出るたびに操作する必要はありません。更新に失敗したら古い設定を使い続け、失敗時刻とエラーテキストを記録してから、ネットワーク接続、サブスクリプション権限、URLのエンコード、サーバーのレスポンス形式を確認します。

3.2 設定ファイルを階層で考える

設定は、ベースファイル、サブスクリプションの内容、ローカル上書きの3層として考えられます。ベースファイルはポート、ログ、DNSなどの共通設定を定義し、サブスクリプションはノードとポリシーグループを提供します。ローカル上書きは、ルールの調整、LANへの直接接続の追加、モードの変更に使います。上書き機能の名称やマージ規則はクライアントによって異なるため、編集前に最終生成設定を確認し、編集欄の一部だけを見て判断しないでください。設定検証に対応している場合は、保存後に検証してから有効化します。

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

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

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,ノード選択

上の断片は設定の骨格を示したものです。混合ポートはローカルのHTTPおよびSOCKSリクエストに使われ、ルールモードはリクエストを順番に処理し、LANアクセスはデフォルトで外部公開せず、最後のMATCHがフォールバックになります。これは特定のサブスクリプションサービスの完全な設定ではなく、サービス提供者が用意したノードの代わりにはなりません。YAMLを編集するときは、インデント、コロン後のスペース、リストの階層に特に注意してください。余分なTabや誤ったインデント1つで、ファイル全体を解析できなくなることがあります。

更新前にロールバックポイントを保存

正常に接続できる現在の設定をコピーまたはエクスポートしてから、サブスクリプションを更新します。解析エラーが起きたら、障害状態で複数の項目を連続して変更せず、まず古い設定へ戻してください。

4. プロキシモード：ルール、グローバル、直接接続の確認方法

プロキシモードは、リクエストをポリシー選択へ渡す方法を決めます。ルールモードでは、設定ファイルのrulesを上から順に照合し、マッチした時点で右側に指定されたポリシーグループへ渡します。グローバルモードでは通常、リクエストを特定のプロキシグループへ一律に渡し、ドメインルールによるDIRECTまたはプロキシの判定に依存しません。直接接続モードではプロキシを経由せずに接続します。クライアントによってボタン名に多少の違いはありますが、現在のモード、現在のポリシーグループ、個々のリクエストの実際のマッチ結果を同時に確認する点は共通です。

ルールモードは、LAN、日本国内でよく使うサービス、プロキシが必要な宛先を分けて処理できるため、日常利用に適しています。グローバルモードは短時間のテストに向いています。ルール結果が不明なとき、既知の利用可能なプロキシグループへ一律に渡すことで、問題がルールにあるのか接続自体にあるのかを切り分けられます。直接接続モードは、元のネットワーク状態の確認や、プロキシが証明書、DNS、ログインに影響しているかの調査に使えます。テスト後は適切なモードへ戻してください。戻し忘れると、ブラウザーの動作が普段と異なる場合があります。

4.1 ログでモードの有効性を確認する

モードを選択したら接続ログを開き、明確なテストURLへアクセスするか、既存ページを再読み込みします。通常、ログにはリクエストドメイン、マッチしたルール、ポリシーグループ、最終的な送信先が表示されます。DIRECTにマッチした場合は、現在がルールモードか、ルールが直接接続を明示しているかを確認します。プロキシグループにマッチしてもページを開けない場合は、グループ内の別の利用可能なノードへ切り替え、エラーが変わるかを確認します。ログにリクエストが現れない場合は、トラフィックがまだクライアントへ入っていません。システムプロキシ、ブラウザー独自のプロキシ設定、TUNの状態、アプリが独自のネットワーク経路を使っていないかを確認してください。

「ウェブページが開く」ことだけを唯一の確認基準にしないでください。ブラウザーがキャッシュ、IPv6、アプリ独自のプロキシ設定、または既存の接続を使っている可能性があります。キャッシュを無効にして再読み込みするか、クライアントの接続記録で新しいリクエストが実際に発生したことを確認します。コマンドラインで確認する場合は、システム環境変数に依存するより、プロキシポートを明示するほうが確実です。

curl --proxy http://127.0.0.1:7890 https://example.com/
curl --socks5-hostname 127.0.0.1:7890 https://example.com/

1つ目のコマンドはHTTPプロキシを使い、2つ目はSOCKS5を使ってドメイン名をプロキシ側で解決します。HTTPコマンドが失敗してSOCKS5が成功する場合は、ポートのプロトコルまたはクライアントの待受設定が一致していない可能性があります。両方とも失敗する場合は、ノード接続とログを確認します。例のドメインはコマンド形式の確認用です。実際のテストでは、正常にアクセスでき、コマンドラインからのリクエストを許可している対象を選んでください。

4.2 システムプロキシ、アプリプロキシ、TUNの違い

システムプロキシは、システムのプロキシ設定に従うブラウザーやデスクトップアプリに適用されます。変更が小さく、簡単に無効化できるのが利点ですが、システムプロキシに従わないプログラムは直接接続する可能性があります。アプリプロキシはプログラム内部の設定で、ブラウザー拡張機能、開発ツール、ターミナルがそれぞれ異なる入口を使う場合があります。TUNはより低いネットワーク層でトラフィックを取り込むため、対象範囲が広い一方、仮想NIC、システム権限、ルーティング、DNSが関係し、設定ミスの影響も大きくなります。トラブル対処ではシステムプロキシから始め、対象アプリが取り込み対象になっていることを確認してからTUNを検討してください。

モード切り替えの安全な手順

現在のモードとポリシーグループを記録してから、グローバルまたは直接接続へ切り替えて比較テストを行い、終了後に元のモードへ戻します。ルール、グローバル、直接接続を短時間に連続して切り替えると、ログの接続結果と設定を対応づけにくくなります。

5. ルール分岐：照合順序、ポリシーグループ、カスタムルール

ルール分岐で重要なのは順序です。カーネルは最初のルールから判定し、リクエストがマッチするとそこで処理を止め、ルールの右側に指定されたポリシーグループやDIRECT、REJECTなどの動作へ渡します。そのため、範囲の広すぎるルールを前に置くと、後ろのより具体的なルールが適用されないことがあります。カスタムルールを設定するときは、まず対象と範囲を定め、次にルール種別を選び、最後に正しい位置へ配置します。特定のドメインが開けないからといって、MATCHを無計画に追加しないでください。

よく使うルール種別には、1つのドメインを完全一致させるDOMAIN、ドメインとサブドメインを照合するDOMAIN-SUFFIX、キーワードで照合するDOMAIN-KEYWORD、IPv4ネットワークを照合するIP-CIDR、IPv6ネットワークを照合するIP-CIDR6、IPの地理情報データベースで照合するGEOIP、プロセス名で照合するPROCESS-NAMEがあります。プロセス名、ネットワークスタック、スニッフィングへの対応は、カーネルのバージョンやプラットフォームによって異なる場合があります。利用前に現在のクライアントが対応する機能を確認してください。ルールの範囲が広いほど誤マッチの可能性が高くなるため、まずは正確なドメインや明確なサフィックスを使います。

5.1 ルールグループの構成方法

ポリシーグループは「手動選択」と「用途別分岐」の2層に分けるのがおすすめです。手動選択グループには具体的なノードまたは自動選択グループを含め、現在の送信先を決めます。用途別分岐グループは、カテゴリごとのリクエストを手動選択、DIRECT、その他のグループへ振り分けます。広告ブロック、LAN、ストリーミング、フォールバックのリクエストをそれぞれ別グループにする構成が考えられます。こうしておけばノードを変更するときも手動選択グループだけを調整でき、ルール側の構造を安定させられます。各業務グループに大量のノードを直接記述すると、サブスクリプション更新後の名称変更で複数箇所の保守が必要になります。

ポリシーグループ名は設定内で参照されるキーのため、大文字・小文字、スペース、句読点を含めて完全に一致させる必要があります。以下の例は小規模な構成を示したものです。

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

  - name: 自動選択
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - ノード1
      - ノード2

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,example.org,ノード選択
  - GEOIP,LAN,DIRECT
  - MATCH,ノード選択

url-testグループは、設定に従って利用可能性をテストし、結果のよいメンバーを選択します。ただし、テスト先へ到達できることがすべての宛先への到達性を保証するわけではなく、intervalも短くしすぎないでください。selectグループは利用者が手動で選択します。例にあるノード名はproxies領域に実在している必要があり、それらのノードがない設定へそのままコピーすることはできません。

5.2 カスタムルールの検証手順

ルールを1つ追加したら、すぐに2つ目を追加しないでください。まず保存して設定を再読み込みし、対象範囲に明確に含まれるドメインへアクセスしてから、ログでルールの内容とポリシーグループを確認します。マッチしない場合は、実際に使われているドメインのサフィックスが異なる、リクエストがIPで行われている、DNS結果がスニッフィングされていない、前のルールで先に処理されている、といった可能性があります。マッチしても接続できない場合、ルール照合は成功しています。次に確認すべきなのはポリシーグループと送信接続であり、ルールをさらに変更することではありません。

ルールが多い場合は、用途ごとにコメントで区切ると管理しやすくなります。ただし、解析できない説明文を重要なフィールドへ書き込まないでください。サブスクリプションが自動生成するルールセットを使う場合は、まずルールセットの更新状態と参照名を確認してからローカルルールを追加します。ローカルルールとサブスクリプションのルールが競合する場合は、どちらを優先するかを明確にし、更新後に最終設定を再確認してください。当サイトのよくある質問では、空のポリシーグループ、ルールが反映されない問題、サブスクリプション更新エラーなど、頻出する確認項目をまとめています。

6. TUNモード：仮想NIC、DNS、システムトラフィックの取り込み

TUNモードは、仮想ネットワークインターフェースでシステム層のトラフィックを受け取り、カーネルの設定に従って転送します。システムプロキシに従わないプログラムも対象にできるため、端末の通信を一元的に取り込みたい場合に適しています。一方、通常のシステムプロキシよりシステムネットワークの底層に近く、ルーティングやDNSの動作が変わります。TUNは「より速いプロキシモード」ではなく、異なるトラフィック入口です。有効化する前に、通常のシステムプロキシが利用できることと、クライアントに仮想インターフェースを作成する権限があることを確認してください。

TUNを有効にすると、通常はデバイス権限、ルーティングの取り込み、DNSという3つの問題に対処します。デスクトップOSでは管理者権限の確認が表示される場合があり、AndroidではシステムVPN権限を使ってローカルVPNを構築します。Linuxではカーネルモジュール、capability、root権限が必要になることがあります。ルーティングの取り込みは、どの宛先をTUNへ入れるかを決めます。auto-route、strict-routeなどの意味は、クライアントやカーネル設定によって異なります。DNSの処理を誤ると、ドメイン解決がローカルネットワークへ流れ、ルール判定と実際の接続が一致しなくなったり、LANドメインを解決できなくなったりします。

6.1 推奨する有効化手順

まず不要なサードパーティVPN、ネットワーク高速化ツール、ブラウザーのプロキシ拡張機能を無効にし、複数の仮想インターフェースが競合しないようにします。通常のシステムプロキシモードでクライアントからテスト対象へアクセスできることを確認してから、TUNを有効にし、システム権限を許可します。有効化後は、LANゲートウェイ、通常のウェブページ、明確にプロキシが必要な対象を順にテストし、解決できるか、接続ログが出るか、ルールのマッチ結果が変わったかを確認します。LANだけが使えない場合は、LANルール、ルーティング除外、DNSを優先して確認します。すべてのネットワークが使えない場合は、まずTUNを無効にしてシステムプロキシへ戻し、その後に権限と仮想インターフェースを確認します。

モバイル端末では、VPNアイコンが表示されても、システムVPNが確立したことを示すだけで、現在の設定にあるノードが利用可能とは限りません。アプリごとのプロキシ機能によって一部のアプリがVPNを迂回する場合もあれば、バッテリー最適化によってバックグラウンドで停止する場合もあります。Androidではバックグラウンドのバッテリー制限、VPNを常時オンにするシステム設定、アプリ分岐リストを確認してください。iOSのネットワーク取り込み機能はアプリが提供するシステム拡張に依存するため、デスクトップのTUN概念をそのままモバイル端末へ当てはめないでください。

6.2 DNSの動作とfake-ipの判断

fake-ipモードはドメインに仮想アドレスを割り当て、カーネルがドメイン名に基づくルール処理を続けられるようにします。ドメイン識別を安定させたい場面に適していますが、一部のLANドメイン、ローカルプリンター、企業内ネットワーク、実アドレスを必要とするプログラムとは互換性がない場合があります。このような問題では、LANのサフィックス、プライベートアドレス、特定ドメインにDIRECTまたはfake-ip-filterを設定できます。具体的なフィールドは現在の設定とクライアントのドキュメントを確認してください。1台のLAN機器を直すために、DNS処理全体を無効にするのではなく、まず問題の範囲を限定します。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"

この設定例は一般的なフィールド同士の関係を説明するためのもので、プラットフォームに必要な完全なDNSサーバー一覧の代わりにはなりません。stack、auto-route、enhanced-modeが利用できるかどうかは、現在のカーネルの対応範囲に従ってください。設定を変更したら、まず構文を確認し、その後は一度に1つのフィールドだけを変更します。TUNを特定のプラットフォームで起動できない場合は、クライアント設定で拡張モードを無効にし、システムプロキシ経路へ戻して日常利用を続けられます。

全体の通信が切れたら、まず入口を復旧する

まずTUNを無効にし、システムプロキシを復元するかクライアントを終了して、端末を既知の状態へ戻します。その後、権限、ルーティング、DNSを順番に確認してください。接続できない状態で、サブスクリプションを連続更新したり設定全体を置き換えたりしないでください。

7. 日常メンテナンス、トラブル対処、ステップアップ

安定した運用には、ロールバックできること、観察できること、変更を最小限にすることの3原則が重要です。ロールバックとは、直近で正常に接続できた設定を保存しておくことです。観察可能にするとは、ログ、ルールのマッチ結果、システムプロキシの状態を確認できる場所を把握することです。変更を最小限にするとは、毎回関係する設定を1つだけ調整することです。この3原則を守れば、多くの障害を設定解析、システムによる取り込み、ルール判定、リモート接続のいずれかに絞り込め、クライアントを何度も再インストールせずに済みます。

7.1 再現可能なトラブル対処手順

1つ目は、クライアントのプロセスと現在の設定を確認します。設定を正常に読み込めていない場合は、まず解析可能な前回のファイルへ戻します。2つ目は待受ポートを確認し、他のプログラムがポートを使用していないか、アプリがHTTP、SOCKS、混合ポートのどれを使っているかを確認します。3つ目はリクエストがクライアントへ入っているかです。接続一覧やログを確認し、記録がまったくなければ、先にノードを変更しないでください。4つ目はルールのマッチ結果とポリシーグループの選択を確認し、DIRECT、REJECT、プロキシグループ、空のグループを区別します。5つ目に、ノード接続、DNS、TLS、リモートサービスの状態を調べます。

ブラウザーにプロキシ接続失敗と表示されたら、まずシステムプロキシのアドレスがローカルホストと正しいポートを指しているか確認します。1つのアプリだけが失敗する場合は、そのアプリが独自プロキシを使っていないか、独自DNSを有効にしていないか、ファイアウォールに阻止されていないかを確認します。すべてのアプリが失敗し、クライアントログにもリクエストがない場合は、問題は取り込み層にあります。ログに接続拒否が記録されている場合は、ポリシーグループまたはノードを確認します。接続確立後に証明書やウェブページの内容に問題が出る場合に限り、TLS、システム時刻、証明書チェーン、対象サイトのレスポンスを調べます。

7.2 設定更新とログ管理

サブスクリプションを更新する前に、設定名と現在のポリシーグループを記録し、更新後にグループ名、ノード数、ルール状態を照合します。ノード数を品質の指標にしたり、更新後に一覧が増えたから設定が必ずよくなったと判断したりしないでください。トラブル対処時はログレベルを一時的に上げ、原因を確認したら適度なレベルへ戻します。長期間高いログレベルを維持すると大量のファイルが生成されます。デスクトップクライアントのログ保存場所はプロジェクトによって異なります。エラーが繰り返される場合は、時刻、対象、原因を含む一部の記録をコピーすれば十分で、設定全体やアカウント情報を含むサブスクリプションURLを渡す必要はありません。

設定ファイルには、サブスクリプションが生成した機密情報が含まれる場合があります。ログを共有したり助けを求めたりする前に、サブスクリプションURL、認証情報、ノードアドレスの不要な識別情報、ローカルパスを削除してください。フィールド名、ルール順序、ポート種別、エラーテキストは構造を理解するために残せますが、完全なアクセスURLを公開してはいけません。サブスクリプションURLの漏えいが疑われる場合は、ブラウザー履歴を削除するだけでなく、サービス側でURLを再生成します。

7.3 パソコン利用から高度な設定へ

基本操作を終えたら、次の順序でステップアップできます。まずルールモードとポリシーグループの参照を習得し、次にDNSとfake-ipの適用範囲を理解します。その後、TUN、ルーティング、LANの除外を学び、最後にルーター、透過ルーター、サーバーへの導入を検討します。各段階は、前の段階を検証できる状態で進めてください。複雑な設定をそのままローカルへコピーすると、複数の未知の変数が同時に入り、障害時に原因がカーネルの機能、プラットフォームの権限、設定構文のどれなのか判断しにくくなります。

ルーターへの導入では、転送経路、ゲートウェイの位置、DHCP、IPv6、ファイアウォール、端末を迂回させる範囲も考慮する必要があります。カーネルの待受アドレスがローカルホストだけにバインドされていると、LAN上の端末からアクセスできません。一方、信頼できないネットワークへ直接公開すると、管理入口とプロキシ入口の範囲が広がります。サーバー運用では、プロセス監視、ログローテーション、アップグレード時のロールバックを設定してください。クライアント画面の「システムプロキシ」ボタンは、ルーターのトラフィック転送ルールの代わりにはなりません。この領域は、まず隔離環境で検証してから家庭内ネットワークへ段階的に移行することをおすすめします。

7.4 トラブル記録テンプレート

トラブル対処のたびに、プラットフォーム、クライアント名、現在のモード、TUNの有効状態、設定を直前に更新したか、対象ドメイン、ログのエラーテキスト、試した変更を1つ記録します。「突然使えなくなった」よりも原因を特定しやすく、同じ手順を繰り返すことも防げます。さらに確認する場合は、まずよくある質問の分類別回答を読み、この記事の該当章へ戻ってください。Windows UWPのループバック制限、HTTPS証明書エラー、プロキシモードの違いなどは、Windows UWPアプリでClashプロキシを使えない場合とHTTPS証明書エラーのトラブル対処も参照できます。

このガイドを終えた後のチェックリスト

  • クライアント画面、mihomoカーネル、サブスクリプション設定の役割を説明できる。
  • プラットフォームとシステムアーキテクチャに応じて、Clash Plusまたは適切な別のクライアントを選べる。
  • サブスクリプションを導入し、ロールバック用の設定を保存し、ポリシーグループとルールが揃っているか確認できる。
  • ログを使って、取り込み層、ルール層、ポリシーグループ、リモート接続の問題を切り分けられる。
  • ルール、グローバル、直接接続、TUNの適用範囲を説明できる。
  • YAMLを変更する前に、インデント、参照名、ルール順序を確認できる。
  • 全体の通信が切れたとき、まずシステムネットワークを復旧し、その後TUN、ルーティング、DNSを順番に確認できる。

Clashの設定機能は複数の層で構成されています。信頼できる使い方は、変わらないテンプレートを暗記することではなく、観察と検証の習慣を身につけることです。まず基本接続を安定させ、次にルール、DNS、TUNを段階的に追加します。変更のたびに記録を残し、更新のたびにロールバックポイントを保存してください。インストールパッケージが必要な場合はClashダウンロードページでプラットフォームを選び、初回設定はクイックスタートガイドに戻って基本手順を完了します。