Clashの使い方ガイド
基礎から応用まで

1. 基本概念：クライアント、コア、通信の入口を理解する

操作はクライアント、通信の転送はコアが担当

Clashのエコシステムは、1つのインストーラーですべての機能を提供するものではありません。GUIクライアントはサブスクリプションの読み込み、設定画面、プロキシグループの選択、ログの確認などを担います。コアは設定を読み込み、名前解決やルール照合、通信の転送を実行します。mihomoは、このエコシステムで広く使われているコアの一つです。似たコアを使うクライアントでも、設定の上書き方法やシステム連携、設定の保存場所は異なることがあります。画面上のボタンが同じだからといって、動作まで同じとは限りません。

設定ファイルはクライアントとコアをつなぐ取り決めで、通常はYAML形式です。プロキシノード、プロキシグループ、振り分けルール、待ち受けポート、DNS設定などが含まれます。サブスクリプションは、こうした設定を取得する方法の一つです。完全な設定を返すURLもあれば、ノード一覧だけを提供するものもあります。読み込みに成功しても、ルールが正しいこと、出口が利用できること、すべてのアプリがプロキシを経由することまでは保証されません。それぞれ個別に確認しましょう。

接続の流れを3つの問いで整理する

アクセスの問題を調べるときは、まず通信がコアに届いているか、次にどのルールに一致したか、最後に選択した出口から接続できるかを確認します。システムプロキシは、システム設定に従うアプリにHTTPまたはSOCKSの接続先を提供します。アプリ側でプロキシを設定する場合は、ローカルの待ち受けポートに直接接続することもできます。TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。入口によって対象範囲もトラブル対処の方法も異なるため、ブラウザーで接続できたからといって、すべてのアプリで問題ないとは限りません。

通信がコアに届くと、通常は上から順にルールを確認し、一致したルールに設定されたポリシーへ渡します。ポリシーは直接接続の場合もあれば、プロキシグループの場合もあります。プロキシグループが使用するノードを選び、そのノードを通じてリモートのプロキシサービスに接続します。つまり「ルールモード」はノードのプロトコルではなく、「システムプロキシ」もプロキシグループではありません。異なる階層の設定を混同すると、通信の入口に問題があるのにノードを何度も切り替える、といった行き詰まりにつながります。

機能の範囲を理解してから設定する

クライアント自体が、利用可能なリモートプロキシサービスを提供するわけではありません。ノードのアドレスやポート、認証情報、利用可能な範囲は設定の提供元によって異なります。サブスクリプションの期限切れや認証の失効、サービス側の制限は、通常TUNを有効にしても解決しません。一方、プロキシは接続先サイトのログイン制限やサービス障害を解決するものでもありません。動作確認には利用権限のあるサービスを使い、居住地域の法律やネットワーク管理規則、サービスの利用規約を守ってください。サービス側の拒否をクライアントの不具合と誤認しないようにしましょう。

作業を始める前に、OS、クライアント名、設定の入手元、現在の入口、対象にしたいアプリを簡単に記録します。サブスクリプションのキーは公開メモに残さないでください。まずブラウザーで接続を確認し、次にほかのアプリへ対象を広げ、最後に全通信の取り込みを検討します。変更は一度に一つに絞ると、問題が起きたときに直前の正常な状態へ戻しやすくなります。コアとGUIの関係についてはClashエコシステムの系統ガイドもご覧ください。

2. クライアント選び：まず対応OSを確認し、必要な設定機能で選ぶ

初めて使うなら、操作の流れが統一されたクライアントを選ぶ

この配布ページでは、対応プラットフォームでClash Plusを第一候補として紹介しています。サブスクリプション、ポリシー、接続管理を一つの製品で学びたい方に適しています。実際には、デバイスの対応状況と必要な機能を基準に選んでください。デスクトップではサービスモードやルールの上書き、ウィンドウ管理が重要になる場合があります。モバイルではVPNの許可、バックグラウンド動作、バッテリー消費が気になるでしょう。先に解決したい問題を書き出してから比較すると、複数の製品を同時にインストールするより安定した環境を作りやすくなります。

Windowsのダウンロード欄にはClash Verge Rev、FlClash、Clash Nyanpasu、開発終了済みのClash for Windowsも掲載しています。macOSではClash Plus、Clash Verge Rev、FlClash、開発終了済みのClashX Metaを提供しています。アーカイブ版は古い環境の確認や移行には役立ちますが、過去のチュートリアルと画面が同じという理由だけで、新規インストールの標準として選ぶのはおすすめしません。移行時はサブスクリプションの入手元とカスタムルールを先にバックアップし、新しいクライアントでシステム連携の設定を作り直してください。

画面の見た目よりプラットフォームの制約を重視する

Androidでは、設定の互換性に応じてClash Plus、Clash Meta for Android、FlClash、Surfboardから選べます。Surfboardの設定形式はClash YAMLと異なるため、任意の完全なYAMLファイルをそのまま読み込めるとは限りません。iOSのダウンロード欄にはClash Plusのストアへのリンクと、公式サイトclashplus.ioを掲載しています。モバイルOSでは一般に、OS標準のVPN機能を使ってトンネルを構築します。デスクトップのシステムプロキシポートを使う手順をそのまま流用しないでください。

LinuxのGUIクライアントにはClash Verge RevとFlClashがあります。サーバーやルーターで使う場合や、自分でサービスを管理したい場合は、mihomo単体での運用も検討できます。単体運用では起動オプション、実行ディレクトリ、権限、ログ、サービス管理を自分で扱う必要があり、GUIクライアントのようなサブスクリプションボタンが自動で用意されるわけではありません。日常的なデスクトップ利用が目的なら、まずGUIで動作する設定を作り、その後にコアの導入を学ぶと、同時に扱う要素を減らせます。

設定の互換性があっても、すべての拡張機能に対応するとは限らない

クライアントを比較するときは、ノードのプロトコル、ルールの構文、クライアント独自の拡張をそれぞれ確認してください。あるコアが認識するフィールドを、別のコアが拒否することがあります。GUIクライアントで使えるスクリプトや上書き形式も、標準設定とは限りません。チュートリアルにフィールドの追加が求められたら、対象の製品とコアを確認しましょう。エラーを消すためにDNSやプロキシグループの設定をまとめて削除すると、ファイルを読み込めても、意図した振り分けが変わるおそれがあります。

システムの通信を主に取り込むクライアントは一つに絞りましょう。ほかの製品を比較に使う場合は、テスト前に古いクライアントを終了し、システムプロキシを無効にして、バックグラウンドサービスの状態も確認してください。ポートやルートの競合を防げます。インストーラーとアーキテクチャの情報はクライアント一覧ページから確認できます。旧版を使っている方は開発終了クライアントからの移行ガイドを先に読み、引き継げる設定と作り直すべき設定を確認してください。

3. インストールと初期確認：元に戻せるローカル環境を作る

アーキテクチャと既存環境を確認する

ダウンロード前にシステム情報を確認し、PCのメーカーだけでCPUアーキテクチャを判断しないでください。macOSではApple SiliconとIntelを区別します。Androidではデバイスが対応する命令セットに合ったパッケージを選び、Linuxではアーキテクチャに加えてディストリビューションのパッケージ形式も確認します。ダウンロードできても、その端末に適合するとは限りません。実行できない、形式が非対応、アーキテクチャが一致しないといった場合は、同じファイルを何度もインストールするのではなく、まずシステム情報を見直してください。

インストール前に、現在のシステムプロキシ設定、稼働中のVPN、会社ネットワークの要件を記録します。別のプロキシクライアントを使っていた場合は、その画面から通信の取り込みを停止して正常に終了し、必要に応じてバックグラウンドサービスも確認してください。用途がわからないまま古い設定ディレクトリを削除しないでください。移行時に必要なカスタムルールやサブスクリプションの入手元が残っている可能性があります。端末内だけで参照できる場所にバックアップを保管し、新しいクライアント用の設定を別途作るのが安全です。

機能に応じて必要な権限を付与する

Windowsでは、通常のシステムプロキシと高い権限が必要なTUNは別の機能です。サービスモードは、権限が必要な処理をバックグラウンドサービスに任せるために使われますが、具体的な操作方法はクライアントによって異なります。サービスをインストールする前に、許可を求めているのが対象の製品であることを確認してください。ブラウザーを接続するだけなら、画面全体を常に管理者として実行する必要はありません。組織のポリシーでインストール先が制限されている場合は、セキュリティ機能を無効にして回避せず、デバイス管理者に対応を依頼してください。

macOSでは初回起動時にアプリの許可やネットワーク拡張の承認が求められることがあります。AndroidやiOSでも、通常はシステムのVPN構成を確認する画面が表示されます。許可したらクライアントに戻り、実際に接続状態になっているか確認してください。LinuxのGUIクライアントは、デスクトップ環境のコンポーネントやシステムサービスの権限に依存する場合があります。依存関係の不足や権限エラーが表示されたら、エラー全文を記録し、ディストリビューションとクライアントの説明に沿って対処します。起動時の問題をすべてサブスクリプションのせいにしないでください。

初回起動では基本項目だけ確認する

設定、プロキシグループ、接続、ログの画面を見つけ、各項目の場所を確認してからサブスクリプションを読み込みます。待ち受けポートは現在のクライアント設定を基準にしてください。このガイドの7897は例であり、すべての製品の標準ポートを示すものではありません。ポートが使用中の場合は、使用しているプロセスを特定し、古いサービスを終了するか新しいポートに変更します。変更後は、プロキシを手動設定したアプリも更新し、古いアドレスへの接続が残らないようにしてください。

初期トラブル対処では、ローカル端末の環境変数を確認し、コマンドラインツールが古いプロキシ設定の影響を受けていないか調べます。確認方法はシェルによって異なります。以下のコマンドは現在のプロセスから見える変数を読み取るだけで、システムを変更しません。プロキシ変数が見つかった場合は、現在のターミナルセッション、ユーザーの設定ファイル、開発ツールのどこから設定されたかを確認してください。GUIのスイッチを切っただけで、環境変数まで消えたとは限りません。

# Linux / macOS：一般的なプロキシ環境変数を確認
env | grep -iE '^(http|https|all|no)_proxy='

# Windows PowerShell：現在のプロセスのプロキシ環境変数を確認
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP|HTTPS|ALL|NO)_PROXY$'

インストール完了の判断基準は、画面が開くことではありません。設定を読み込める、待ち受け入口が競合していない、通信の取り込みを停止できる、ログを正常に確認できることが重要です。先に基本項目を確認しておけば、後で問題が起きたときの比較基準になります。Windowsのサービス許可やスタートアップ設定についてはClash Verge Revのインストールガイドも参考にしてください。ほかのクライアントに同じ名前のメニューがあっても、手順をそのまま流用しないでください。

4. サブスクリプションと設定：リモートの入手元とローカルの変更を分ける

まず読み込むデータの種類を確認する

サブスクリプションURLが返すものは、完全なClash設定、ノード一覧、エンコードされたリンク集、ほかの製品向けの形式などさまざまです。読み込む前に提供元の形式説明を確認し、現在のクライアントに対応すると明記されたURLを優先してください。クライアントのサブスクリプションまたは設定画面でリモート設定を追加し、URLを貼り付けて取得したら、読み込み結果を確認します。解析エラーが出た場合は、ノードを何度も更新するのではなく、返された内容が設定ファイルかどうかを先に確認しましょう。

サブスクリプションURLにはアカウントを識別できる情報が含まれることが多いため、認証情報と同様に扱ってください。スクリーンショットや公開質問、ログの共有時にはURL全体と認証フィールドを隠します。形式変換のために、個人用のサブスクリプションを詳細のわからないデータ処理サービスへ渡さないでください。説明用にはhttps://example.com/sub?token=xxxxのようにURLの構造を示せますが、これは実際のサブスクリプションではなく、接続には使えません。実際のURLは、利用権限のある提供元から取得してください。

読み込み後に確認する順序

ダウンロード後、まず新しい設定に切り替え、実際に現在の設定として使われているか確認します。続いてプロキシグループがあるか、グループ内に選択できる出口があるか、ルールが有効なポリシーを参照しているかを確認してください。クライアントによっては「サブスクリプションを更新しました」と表示されても、ファイルが保存されただけで、構文や参照エラーによりコアが再読み込みを拒否する場合があります。更新ボタンの成功表示だけではなく、現在の設定の表示とログで実際の反映を確認しましょう。

YAMLはインデントと構造が重要です。スペースを使い、タブを混在させないでください。リスト項目は通常ハイフンから始まり、同じ階層ではインデントを統一します。特殊文字を含む文字列は引用符で囲めます。エラー表示の行が実際の問題箇所の次の行になることもあるため、前後の構造も確認してください。以下は設定の構造例で、プロキシノードを含まず、サブスクリプションの代わりにそのまま使える完全なファイルではありません。実際の設定では、提供元の有効なノードとポリシーを残してください。

# 構造の例：実際のサブスクリプションと統合して使用
mixed-port: 7897
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

サブスクリプションの更新と個別設定を分ける

リモートのサブスクリプションファイルを直接編集すると、次回の更新で変更が上書きされるおそれがあります。長期的に残したいルール、DNS、ポートの調整は、クライアントが対応する上書き設定、マージ設定、独立したルールファイルに追加し、適用順序も確認してください。設定をマージしてから最終ファイルを生成する製品もあれば、スクリプトで設定オブジェクトを変更する製品もあります。こうした仕組みは共通ではありません。変更後は最終的に有効な設定を確認し、サブスクリプション内の同名項目に再度上書きされていないか調べましょう。

更新に失敗したら、ネットワーク、応答内容、設定の解析の3つに分けて調べます。タイムアウトや証明書エラーは、通常データの取得段階で発生します。ダウンロードはできてもYAMLエラーになる場合は、応答内容がログインページ、期限切れの案内、エラーテキストに変わっていないかを確認します。ノードがあるのに接続できない場合は、認証と出口の動作を調べましょう。現在使える設定があるなら、まず残しておいてください。入手元が一時的に利用できないからといってローカルのキャッシュを消すと、最後に動作していた環境を失うおそれがあります。

サブスクリプション変換は形式の互換性を補うもので、無効になったノードを復旧させたり、すべてのフィールドを完全に変換したりするものではありません。変換後は特に、プロキシグループ名、ルールの順序、DNS設定を確認してください。ノードだけが残り、元のポリシーが失われていることがあります。最終確認では再読み込みと実際のアクセスを行います。簡単な手順から始めたい場合はサブスクリプションの読み込みガイドへ。よくある失敗の原因はよくある質問で確認できます。

5. プロキシモードと動作確認：通信がどの経路を通るか確かめる

ルール、グローバル、直接接続で変わるのはポリシー

ルールモードは設定内のルールに基づいて出口を選ぶため、ローカルサービスとリモートのリソースを併用する日常環境に適しています。グローバルモードでは、通常コアに届いた通信をグローバルポリシーに渡すため、特定の出口が使えるか一時的に比較するのに便利です。直接接続モードでは、コアに届いた通信を接続先へ直接送ります。どのモードも、すべてのアプリが自動的にコアを経由するわけではありません。Clashのグローバルモードを有効にしても、アプリがクライアントを完全に迂回することがあります。その場合、まず通信の入口を確認してください。

動作確認の最初は、主要な入口を一つだけ使います。デスクトップではシステムプロキシを有効にし、ルールモードを選んで、よく使うプロキシグループから出口を一つ選びます。モバイルではまずシステムVPNに接続してください。既知の接続可能なテスト先を開き、接続一覧で対象ドメイン、一致したルール、最終的なポリシーを確認します。ページが表示されても接続一覧に該当する記録がない場合は、ブラウザーのキャッシュ、接続の再利用、アプリが想定した入口を使っていない可能性を調べましょう。

比較テストで原因を絞り込む

ブラウザーとターミナルが同じプロキシ設定を参照するとは限りません。コマンドラインでローカルのHTTPプロキシを明示すると、環境変数の違いを避けて待ち受け入口の動作を確認できます。以下の例では混合ポートを7897としています。実行前に現在の設定に合わせて置き換えてください。公開されているサンプルドメインにアクセスするだけなので、このリクエストの経路を確認する用途に限られます。すべてのサイト、プロトコル、アプリが正常だと判断する根拠にはなりません。

# ローカルのHTTPプロキシを明示して接続
curl -I --proxy http://127.0.0.1:7897 https://example.com

# プロキシを明示的にバイパスして比較
curl -I --noproxy "*" https://example.com

最初のコマンドでローカルポートに接続できない場合は、クライアントが起動しているか、ポートが正しいか、待ち受けが確立しているかを確認します。ローカルには接続できてもリモートへのリクエストが失敗する場合は、選択したノード、ルール、ログを調べましょう。直接接続が正常でプロキシ接続が失敗するなら、動作が確認済みの別の出口でも比較します。両方とも失敗する場合は、接続先のサービス、現在のネットワーク、システム時刻も確認してください。一度のテストでノード、DNS、入口、ルールを同時に変更すると、どの変更が有効だったか判断できません。

プロキシグループと接続の再利用を理解する

手動選択型のグループは出口を固定したい場合に向いています。自動テスト型は設定されたテスト条件に従って候補を選び、フェイルオーバー型は現在の候補が使えないときに切り替えます。テスト先、間隔、許容値によって選択結果は変わります。テストに成功しても、すべてのサービスにアクセスできるとは限りません。トラブルの切り分け中は一時的に出口を手動で固定すると、自動切り替えの影響を抑えられます。経路を特定できたら、自動ポリシーに戻しましょう。

モードやノードを切り替えても、確立済みの長時間接続がすぐに移行するとは限りません。ブラウザーの接続プール、ダウンロード、メッセージアプリなどが古い接続を使い続ける場合があります。新しいポリシーを確認するには、まずリクエストを再実行してください。必要ならクライアントで該当する接続を閉じるか、対象アプリを再起動します。毎回デバイス全体を再起動する必要はありません。プロキシグループで選択されている項目だけを見るより、接続時刻と実際の出口を確認するほうが、サービスがどの経路を使ったか把握しやすくなります。

アクセスできることと、プライバシー上の目的を達成できることは別です。通信がプロキシを通っていても、DNS、アプリのテレメトリー、アカウントの利用状況が同じ範囲で保護されるとは限りません。ブラウザーのセキュアDNS、アプリ独自の名前解決、UDP通信も別途確認が必要です。ストアアプリが想定したプロキシを使わない場合はWindows UWPのループバック免除ガイドを参照し、まずアプリの種類と制約を確認してから、ループバック免除を使うか入口を調整するか決めてください。

6. ルール振り分け：アクセスの意図を順序立てて記述する

例外を先に、汎用ルールを後に置く

振り分けルールは通常、上から順に評価され、最初に一致したルールのポリシーが適用されます。そのため、順序自体が設定のロジックです。よくある構成は、明確なサービス別の例外、LANなどのアドレス範囲、広範囲のルールセット、最後にフォールバックの順です。範囲の広い直接接続ルールやプロキシルールを細かいルールより先に置かないでください。後続のルールは構文が正しくても、一致する機会がなくなることがあります。

ドメインルールはサービスの用途を表すのに適し、アドレスルールはネットワーク範囲を表すのに適しています。DOMAINは完全一致のドメインを照合します。DOMAIN-SUFFIXは指定したドメインとサブドメインを対象にできます。IP-CIDRはアドレス範囲で照合し、GEOIPは地理情報データを使って判定します。MATCHは最後のフォールバックに使います。ドメインのサフィックス照合は、単純な部分文字列検索ではありません。実際のドメイン境界を指定し、パスやプロトコルの接頭辞、クエリパラメーターをドメイン欄に含めないでください。

まずポリシー名、次に構文を確認する

ルールの最後の項目は、実際に存在するポリシーを参照する必要があります。以下のPROXYはプロキシグループ名の例です。使う前に、現在の設定に同じ名前のグループが存在するか確認してください。存在しない場合は、有効な名前に置き換えます。DIRECTは組み込みの直接接続ポリシーです。この例は具体的なルールからフォールバックへ進む順序を示すもので、すべての人に適した完全なルール一覧ではありません。既存のサブスクリプションに詳細なサービス別ルールがある場合は、統合時に必要なロジックを残してください。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolveは、特定のアドレスルールでドメイン照合のために追加の名前解決が発生するのを避けるための指定です。DNS全体を無効にするものではありません。不要な名前解決を減らせますが、想定どおりに判定するには、宛先アドレスなどの条件がすでに満たされている必要があります。また、地理情報データはサービスの実態を絶対的に示すものではありません。コンテンツ配信ネットワーク、複数地域にまたがるサービス、アドレスの割り当て変更などにより、GeoIPだけでは実際のアクセス要件に合わないことがあります。

ルールセットとローカル上書きを使い分ける

ルール数が増えたら、ルールプロバイダーでセットを管理し、RULE-SETで参照できます。プロバイダーでは通常、ルールの種別、取得方法、保存先、更新間隔を指定します。セットの内容は宣言した種別と一致している必要があります。ドメインセットを任意のルールテキストとしてそのまま使うことはできません。まず手書きのルールをいくつか理解してからセットを導入しましょう。仕組みがわからないまま使うと、誤振り分けが起きた際に、参照設定、ダウンロード失敗、セット自体のどこに問題があるのか判断しにくくなります。

ルールを追加したら、まず最終的に有効なファイル内の位置を確認し、対象にアクセスして接続の詳細を調べます。一致しない場合は、実際のドメイン、前のルールに先に拾われていないか、アプリがアドレスしか示していないか、古い接続が再利用されていないかの順に確認してください。ウェブサイトは複数のドメインを使うことが多く、トップページがプロキシ経由でもログイン用のAPIが直接接続になると、サービスが動かない場合があります。すべての通信を同じポリシーに変えるのではなく、実際の接続に必要な範囲だけルールを追加しましょう。

長期的に管理するため、カスタムルールには理由を明記し、サブスクリプションの内容とは分けて保存してください。古い例外設定により、サービスが新しいポリシーを長期間迂回することがあります。サービスが復旧したときやルールセットを更新したときに、例外を残す必要があるか見直しましょう。ClashのGeoIP更新はデータのメンテナンスとして扱い、通信障害全般の万能な解決策とは考えないでください。用語は用語集で確認できます。各ルールについて「なぜここに置くのか」「何に一致させるのか」「最終的にどこへ渡すのか」を説明できることが大切です。

7. TUNとDNS：通信の取り込み範囲を広げる前に名前解決を理解する

TUNは通信の入口を補う機能であり、出口の設定に代わるものではない

TUNは仮想ネットワークインターフェースとルーティングを使って通信をコアに渡します。システムプロキシに従わないプログラムや、より多くのプロトコルの通信をまとめて扱いたい場合に便利です。動作にはシステム権限、ネットワークスタック、クライアントの実装が関係し、どのプラットフォームでも同じスイッチやパラメーターが使えるわけではありません。デスクトップで有効にする前に、まずシステムプロキシ経由の接続が動作することを確認し、ルートを変更するほかのVPNツールを一時停止してください。出口の基本動作を確認しないまま、別の障害要因を重ねないようにしましょう。

有効にしたら、仮想インターフェースが作成されたか、対象の通信が接続一覧に表示されるか、ルールに一致しているか、LANのリソースに引き続きアクセスできるかを順に確認します。会社のVPN、コンテナネットワーク、仮想マシンを同時に使っている場合、自動ルーティングがそれらのアドレス範囲と競合することがあります。実際のネットワークに合わせて除外範囲を決めるか、別の入口を選んでください。ネットワークスタックをむやみに切り替え続けるのは避けましょう。遠隔管理中のデバイスでは、ルート変更によって現在の管理接続が切れる可能性があるため、特に注意が必要です。

DNSはドメイン名を接続先に変換する

アプリによって、システムDNS、ブラウザーのセキュアDNS、アプリ内蔵の名前解決が使われます。クライアントのDNS設定が作用するのは、クライアントの処理経路に入った問い合わせだけです。そのため「DNSサーバーを設定した」ことと「すべての問い合わせがそこを経由する」ことは同じではありません。ClashでDNSリークが起きているか調べる前に、どの問い合わせをどの経路に通したいのかを明確にし、クライアントのログとシステム設定で確認してください。一つのウェブテストだけでデバイス全体の動作を断定することはできません。

Fake-IPでは、ドメイン名に対して予約済みアドレス範囲のアドレスを割り当て、コアがドメイン名と接続の対応関係を保持することで、その後の振り分けを行います。これは接続先サーバーの実アドレスではないため、この種のアドレスが見えても名前解決の異常とは限りません。LAN内のデバイス検出や機器操作、実アドレスの検証を行うアプリは、この方式に対応できない場合があります。用途に合わせてフィルターを設定するか、別の名前解決モードを使ってください。影響がわからないままDNS処理全体を無効にするのではなく、例外範囲を必要最小限に絞りましょう。

# mihomoの部分設定例：待ち受けポートとプラットフォームの対応を確認
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

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

この設定は有効なmihomo設定に統合して使うもので、すべてのGUIクライアントに適用できるわけではありません。クライアントの画面操作によって、これらのフィールドが再生成されることもあります。DNSをローカルポートで待ち受けさせても、システムの名前解決設定が自動で変更されるわけではありません。TUNでDNSを取り込めても、アプリが独自に確立する暗号化DNSの通信まで取り込めるとは限りません。例にある上流DNSは任意の設定で、すべてのネットワークに適しているとは限りません。利用前に到達性、信頼性、地域のネットワーク要件を考慮してください。

影響範囲に応じて設定を戻しながら対処する

TUNを有効にしてすべてのアクセスが失敗した場合は、まずTUNを無効にし、動作確認済みの入口に戻します。基本ネットワークが復旧するか確認してから、権限、ルート、DNSのログを調べてください。イントラネットのドメインだけ失敗するなら、リモートノードを変更するのではなく、社内DNS、検索ドメイン、ルートを確認します。特定のアプリだけ異常なら、システムの名前解決、アプリ独自の名前解決、Fake-IPの例外設定を比較して違いを絞り込みます。モバイルではバックグラウンド動作も考慮してください。詳しくはAndroidのバッテリー消費とバックグラウンド動作の対処法をご覧ください。

8. 日常メンテナンス：更新、バックアップ、トラブル記録

4種類の更新対象を区別する

クライアント、コア、サブスクリプション、ルールデータの更新はそれぞれ別の操作です。クライアントの更新は画面やシステム連携に影響します。コアの更新はプロトコル対応やフィールドの動作を変える場合があります。サブスクリプションの更新ではノードや提供元の設定が変わり、GeoIP、GeoSite、ルールセットの更新は照合結果に影響します。変化があったら、まずどの種類の更新が行われたかを確認し、すべてを一括して「ソフトウェアのアップグレード」とまとめないようにしましょう。簡単な記録で構いませんが、変更前後の主な差をたどれるようにしてください。

環境が安定しているときは、すべてのコンポーネントを一度に更新し、そのついでにDNSを書き換えるのは避けてください。バックアップを取ってから一つずつ変更し、その都度、よく使うサービスで動作を確認します。デスクトップクライアントでコアを個別に切り替えられる場合も、実行ファイルを名前だけ見て置き換えるのではなく、互換性の説明を先に読んでください。出所のわからない古いインストーラーを大量に保管するより、以前に動作した設定を残すことが重要です。戻すときは設定構文も考慮してください。古いコアでは新しいフィールドを読み込めないことがあります。

設定ファイルだけでなく、設定の意図もバックアップする

有効なバックアップには、サブスクリプションの入手元、カスタムルール、上書き設定、プロキシグループの選択、必要なシステム連携の手順を含めます。クライアントが出力する設定にはノードのパスワードやサブスクリプションの認証情報が含まれることがあります。アクセスを制限して保管し、公開コードリポジトリには登録しないでください。エクスポートファイルにシステムプロキシ、スタートアップ、サービスのインストール状態が含まれない場合もあるため、別のデバイスに移行したら再認証してポートも確認します。バックアップファイルがあるだけでは、復元できることを確認したことにはなりません。

日常利用に影響しない範囲で、一度復元テストをしておくと安心です。仮の設定を作り、バックアップを読み込み、ポリシーの参照先とルールの順序を確認してから元の設定に戻します。別のクライアントへ移行する場合は、まず汎用的なYAML設定を復元し、その後、新しい製品の方法に合わせて上書き設定とシステム設定を作り直してください。新しいクライアントのデータディレクトリ全体を上書きしないでください。古いキャッシュ、データベース、クライアント固有のフィールドは互換性がない場合があります。移行後も、よく使う機能をすべて確認するまでは元のバックアップを残してください。

具体的な失敗を中心にトラブルを記録する

問題が起きたら、発生時刻、対象アプリ、対象ドメイン、現在の入口、選択したポリシーを記録してから再現します。調査のため一時的にログを詳細化する場合は、ディスク使用量と機密情報の漏えいに注意し、終了後は適切なレベルに戻してください。公開して相談するときは必要なエラー情報だけを残し、サブスクリプション、認証情報、個人のファイルパスを隠します。一方でエラーの種類は残してください。「接続に失敗」だけになるまで情報を削ると、原因を判断できなくなります。

Clashのスタートアップも個別に確認してください。再起動後にクライアントが起動するか、バックグラウンドサービスが使えるか、設定が読み込まれるか、通信の取り込みが想定どおりかを確かめます。ログイン後に起動するアプリもあれば、デスクトップより先にサービスが起動するものもあるため、共通の基準では判断できません。サブスクリプションの自動更新では、最初のネットワーク接続が成立するかも考慮してください。サブスクリプション取得に、まだ復旧していないプロキシ経路が必要な場合は、起動時に設定の取得と接続の確立が互いに依存する状態を避けるため、ローカルに有効な設定を残しておきましょう。

問題を解決したら、一時的なグローバルモード、デバッグログ、範囲の広すぎる例外ルールを元に戻し、原因と対応結果を一言記録します。トラブル対処のための設定を、そのまま恒久的に残さないでください。同じ問題が繰り返し起きる場合は、まずよくある質問で基本知識、インストールと設定、使い方、トラブル対処の各項目を確認します。さらに相談する場合は、失敗画面のスクリーンショットだけでなく、再現手順と機密情報を隠した設定の抜粋を共有すると役立ちます。

9. 応用への道筋：使える設定から、維持しやすい設定へ

スイッチの数ではなく、検証できる目標で進める

前の8章を終えた後に目指すのは、すべての機能を有効にすることではなく、説明、移行、ロールバックができる設定です。まず、仕事で使うサービスを特定のポリシーに固定する、複数のデバイスに別々の出口を割り当てる、重複するルールをセットにまとめるなど、明確な目標を一つ決めます。目標の達成条件を書き出してから、必要なフィールドを選んでください。既存のルールで問題が解決しているなら、スニッフィング、スクリプト、複雑なグループ構成を追加すると、メンテナンスの負担とトラブルの切り分け範囲が増えることがあります。

まず設定を基本の待ち受け、DNS、ノードの入手元、プロキシグループ、ルールの5つに分け、各項目の管理担当を明記します。リモートサブスクリプションはノード、ローカル上書きは個別の要件、ルールプロバイダーは再利用可能なセットを管理する、と役割を分けると、巨大なファイル一つにまとめるより構造を把握しやすくなります。クライアントが設定を生成する方式なら、入力ファイルと最終ファイルの違いも理解しておきましょう。最終ファイルは結果の確認には使えますが、長期的な編集元として適しているとは限りません。

まず静的チェック、次に実際の動作確認

mihomoを単体で使う場合は、実際にネットワークを取り込む前に設定テストを実行し、構文と参照関係を確認できます。以下のコマンドは、実行ファイルがコマンド検索パスに含まれ、現在のディレクトリに確認対象の設定ファイルがあることを前提としています。テストに通っても、コアがファイルを受け付けたことがわかるだけで、ノードの認証情報が有効か、上流の名前解決が可能か、ルートが要件に合うかまでは証明できません。GUIクライアントに設定検証機能がある場合は、対応する画面から実行してください。内部の作業ディレクトリを不用意に操作しないでください。

# mihomo単体：現在の設定を確認
mihomo -t -f ./config.yaml

# mihomo単体：設定ファイルを指定して実行
mihomo -f ./config.yaml

続いて、小規模な回帰テストのリストを作ります。直接接続先、プロキシ接続先、LAN内のサービスに加え、実際に必要なUDPや長時間接続を含めてください。変更のたびに入口、ルール、出口をそれぞれ確認し、想定どおりか記録します。テスト先は実際の利用環境に合わせて決め、公開テストアドレスの結果をそのまま業務上の品質とみなさないでください。ログイン、決済、接続地域を固定する必要があるサービスでは、出口を切り替えた際のアカウント保護やセッション切断にも注意が必要です。

自動化とリモート管理ではアクセス範囲を絞る

コントロールインターフェースや管理パネルを使う前に、待ち受け範囲とアクセス認証を確認してください。ローカル管理だけが必要なら、ループバックアドレスに制限します。スマートフォンからパネルにアクセスするためだけに、管理ポートをすべてのネットワークインターフェースへ公開しないでください。LANからの管理が必要な場合は、アクセス制御とファイアウォールを併用し、プロキシの待ち受けとコントロールインターフェースが別のサービスであることも理解しておきましょう。LAN接続を有効にしても、任意のデバイスに利用を許可したことにはなりません。実際の要件に合わせてネットワークへの公開範囲を制限してください。

サーバーやルーターに導入する場合は、サービスのライフサイクルも理解する必要があります。どのユーザーで実行するか、どのディレクトリからデータを読むか、再起動後に復旧するか、ログをどうローテーションするか、異常終了時にどう対応するかを確認してください。透過プロキシ、ファイアウォール転送、ポリシールーティングを設定する場合は、個別にロールバック方法を用意します。遠隔管理中のデバイスで、慣れていないルーティングルールをそのまま試さないでください。まず手元で操作できるテスト環境で確認してから長期運用するデバイスへ移すと、接続不能になるリスクを抑えられます。

学習を続ける際は、使用中のコアとクライアントの設定ドキュメントを優先して確認してください。特に、フィールドが属する階層、標準動作、互換性の制限に注目します。古い記事は仕組みの理解には役立ちますが、現在の有効な設定を確認する代わりにはなりません。復習するときは、このページの基本概念に戻り、通信経路を描き直してください。環境を作り直すときはクイックスタートの手順に戻りましょう。各設定の目的、確認方法、元に戻す方法を説明できることが、「一時的に使える設定」から「長期的に維持できる設定」へ進んだ証です。