Clash 設定完全ガイド

基本概念：通信の流れを理解する

Clashはアプリからの通信を受け取り、設定に基づいて送信方法を選ぶソフトウェアです。通常は、GUIクライアント、プロキシコア、設定ファイル、リモートのプロキシサービスで構成されます。クライアントをインストールしただけでは、接続先となるリモートノードを利用できるとは限りません。それぞれの役割を把握しておけば、問題がインストール、サブスクリプション、ルール、ネットワークのどこにあるかを切り分けやすくなり、接続失敗をすべてクライアントの不具合と決めつけずに済みます。

クライアントは操作、コアは通信を担当

GUIクライアントはサブスクリプションの管理、モード切り替え、ログの確認、システム連携を担います。コアは設定の解析、DNS処理、ルール適用、接続の確立を担当します。mihomoはClashのエコシステムで開発が続くコアで、Clash Metaという名称はその系譜に関係しています。クライアントによって採用するコアや実装方法は異なるため、画面上の項目名が似ていても、同じ設定項目に対応するとは限りません。トラブル対処では、クライアント名とコアの情報をあわせて記録しましょう。

設定ファイルには、ローカルの待受ポート、ノード、プロキシグループ、ルール、DNSの動作などを記述します。サブスクリプションは設定やノード情報を取得するためのURLですが、提供元によって返される内容は異なります。完全なYAMLを提供する場合もあれば、ノード一覧だけの場合もあります。クライアントが一方の形式を読み込めても、あらゆる形式を自動認識できるとは限りません。解析エラーが出たら、ローカルのネットワーク設定を何度も切り替える前に、提供元が案内する形式を確認してください。

アプリから送信先までの通信経路

ブラウザーでWebページを開く場合、通信はシステムプロキシまたはTUN経由でコアに入り、ルールに従って直接接続するか、プロキシグループに渡されます。プロキシグループが具体的なノードを選び、そのノードから接続先のサービスへ通信します。DNSは取り込み方法や設定によって、経路上の複数の箇所で名前解決に関わることがあります。この流れを理解すれば、ログを確認する順番も明確です。まず通信が取り込まれたか、次にどのルールに一致したか、最後にどの送信先が選ばれたかを確認しましょう。

直接接続とは、現在の端末が接続しているネットワークから接続先へ直接アクセスすることです。ローカルのルール判定を経ないという意味ではありません。プロキシ接続は指定した送信先に通信を渡すことですが、接続先のWebサイトに必ずアクセスできるわけではありません。リモートサーバーの障害、アカウントの制限、接続先サービスによる拒否、ローカルDNSの異常などがあれば、プロキシ経由の通信でも失敗することがあります。遅延テストの成功は、そのテストリクエストが完了したことを示すだけで、実際のアプリでの動作確認の代わりにはなりません。

最小限の動作確認を行う

学習中は、クライアントを1つ、利用可能な設定を1つ、手動選択できるプロキシグループを1つだけ使いましょう。プロキシを有効にする前のネットワーク状態を記録してからシステムプロキシをオンにし、再現性のあるWebページにアクセスします。接続一覧で該当ドメインを確認してください。接続と送信先が表示されれば、ローカルで通信を取り込む経路が確立したと判断できます。複数のプロキシツールを同時に起動すると、ポート、システムプロキシ設定、デフォルトルートを奪い合い、結果の切り分けが難しくなります。

以降の章でも、この確認手順を使います。通信が表示されない場合は入口の設定に戻ります。通信は表示されるものの送信先が違う場合は、モードとルールを確認します。送信先が正しいのにリクエストが失敗する場合は、ノードと接続先のネットワークを調べます。設定を手当たり次第に切り替えるより、この順で確認すれば有効な情報を残しやすく、正常な設定を誤って変更するリスクも減らせます。

クライアント選び：OSと設定要件で絞り込む

初めて使う場合は、まずClash Plusでインストール、サブスクリプション登録、接続確認まで行い、その後に別の画面や管理方法を検討しましょう。選定では、クライアントの名称より、端末のOS、CPUアーキテクチャ、設定形式、必要なシステム連携機能を重視してください。各OSのインストーラーや選択肢はダウンロードページで確認できます。複数のクライアントを比較する場合は、クライアントの比較レビューも参考になります。

端末に合わせて候補を絞る

WindowsではClash Plus、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を選べます。iOSではClash Plusのストア掲載ページを確認してください。Linuxではディストリビューションに合ったClash Verge RevまたはFlClashのパッケージを選びましょう。

Clash for WindowsとClashX Metaは開発が終了しています。旧設定の確認や既存環境の対応には使えますが、新しい端末での利用はおすすめしません。アーカイブされたクライアントは、新しいプロトコルやOS互換性の修正、設定拡張に対応していない場合があります。移行する場合は、まずサブスクリプションの入手元と個人ルールをバックアップし、新しいクライアントに個別に読み込んで動作を確認してください。古いフォルダーをそのまま上書きせず、新しい環境で接続できることを確かめてから旧プログラムを削除しましょう。

CPUアーキテクチャとパッケージを正しく選ぶ

CPUアーキテクチャによって、インストーラーを実行できるかどうかが決まります。Windowsではシステム情報でシステムの種類を確認してください。macOSでは「このMacについて」でチップまたはプロセッサを確認します。Androidでは端末が対応するABIに合ったパッケージを選びます。LinuxではAMD64とARM64だけでなく、パッケージ形式も確認してください。同じOS向けでも複数のパッケージがあるため、ファイルサイズだけで判断してはいけません。ダウンロードページに該当するアーキテクチャがない場合も、別のアーキテクチャ向けのパッケージで代用しないでください。

「Clashの設定に対応」とあっても、すべての項目を共通して使えるとは限りません。ルールプロバイダー、特定のDNSオプション、プロトコルのパラメーターには、対応するコアが必要です。GUIが一部の項目を書き換える場合もあります。Surfboardは別の設定方式を採用しているため、読み込む前に対応形式を確認してください。完全なClash YAMLをそのまま渡せるとは限りません。クライアントを替えて解析エラーが出た場合は、サブスクリプションの破損を疑う前に形式と対応機能を確認しましょう。

同じ条件で移行前後を比較する

クライアントを比較するときは、端末、ネットワーク、サブスクリプション、ノード、テスト対象を同じにし、通信を取り込むツールは1つだけ起動してください。同じノードに接続できるかを確認してから、必要な機能が使えるかを見ます。1回の遅延測定だけで優劣を決めないでください。テストURL、タイムアウト、接続の再利用、測定時のネットワーク状態は結果に影響します。日常利用で重要なのは、接続の安定性、ルールの分かりやすさ、メンテナンスのしやすさです。

サーバー、ルーター、またはプロセスを自分で管理する環境では、Mihomoコアを直接実行する方法もあります。ただし、サービス管理、権限、管理インターフェースの保護が必要になります。一般的なデスクトップ利用では、状態を確認しやすいGUIクライアントから始めるのがおすすめです。iOSではダウンロードページでClash Plusを確認し、公式サイトclashplus.ioで製品情報を確認できます。インストール後は、設定の読み込みと接続の許可が必要です。

インストールと確認：ローカルの接続口を整える

インストール段階では、クライアントが起動し、コアが動作し、ローカルポートが待ち受けていることを確認します。ネットワーク機能をすべて有効にする必要はありません。ダウンロードページでOSとアーキテクチャが合ったものを選び、初期設定のままインストールしてください。他のプロキシツールは一時的に終了します。初回起動時に、データフォルダー、現在の混合ポート、ログの確認場所を記録しましょう。これらは設定の読み込み、ポート競合の解消、バックアップの移行で繰り返し必要になります。

デスクトップでのインストール手順

Windowsでは通常どおりインストールして起動し、メイン画面にコアの起動失敗が表示されていないことを確認してから、サブスクリプションを登録します。ネットワークアクセスの許可を求められた場合は、利用範囲に合ったネットワークを選んでください。LAN内の別端末と共有しないなら、他の端末向けのプロキシ入口を開放する必要はありません。ポータブルフォルダーにインストールする場合は、現在のユーザーに設定とログの書き込み権限があることを確認します。読み取り専用の場所に置くと、設定を保存できない、再起動後にサブスクリプションが消える、更新に失敗するといった問題が起きることがあります。

macOSでは、インストーラーの形式に従ってアプリを適切な場所に配置し、初めて起動します。システムにブロックされた場合は、ダウンロード元と表示内容を確認してください。セキュリティ機能を一括で無効にして解決しようとしないでください。TUNやバックグラウンドサービスに追加の許可が必要な場合は、基本の接続確認を終えてから対応しましょう。Linuxではディストリビューションに合ったパッケージを使い、インストール時の依存関係エラーを確認します。画面は起動するのにコアがすぐ終了する場合、ログに権限や設定のエラーが記録されていることがあります。

モバイルでは接続の許可を先に確認

Androidで初めてローカルVPNインターフェースを作成すると、システムの許可画面が表示されます。この入口から通信を取り込むには許可が必要です。通常、システム上で同時に有効にできるVPNサービスは限られているため、別のVPN、ファイアウォール、VPNベースのフィルタリングアプリと競合する場合があります。iOSではClash Plusをインストールした後、システムの案内に従って接続設定を追加し、許可してください。どちらのOSでも、まずアプリを前面に表示した状態で動作確認を行い、その後、画面ロック、ネットワーク切り替え、バックグラウンド動作の影響を確認しましょう。

モバイル端末にVPNの表示があっても、リモートノードへの接続成功を意味するわけではありません。システム側のネットワーク拡張やインターフェースが動作していることを示す表示です。ノードに接続できない、サブスクリプションが有効でない、ルールの設定を誤っている場合でも、表示が残ることがあります。実際のリクエストとクライアントの接続記録で確認してください。Androidで画面ロック後に頻繁に切断される場合は、省電力設定、バックグラウンド動作の制限、自動起動の設定を確認します。最初から複数のシステム権限を同時に変更するのは避けましょう。

ポート競合と起動失敗を確認する

混合ポートは通常、HTTPとSOCKSのプロキシリクエストを受け付けます。ポート番号はクライアントの現在の設定で確認してください。例にある7890が、すべての端末で使う固定値というわけではありません。ログに待受アドレスが使用中と表示されたら、まず他のプロキシプログラムを終了し、古いコアのプロセスが残っていないか確認します。空いているポートに変更する方法もありますが、プロキシを手動設定したブラウザー、ターミナル、開発ツールのポートもあわせて変更してください。クライアント側だけ変更しても接続できません。

# Windows PowerShell：ローカルポートの待受状態を確認
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux：指定したTCPポートを待ち受けているプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

これらのコマンドは状態を確認するだけで、競合を自動修復するものではありません。ポートが待ち受けていない場合は、コアが起動しているか、設定の解析に成功しているかを確認してください。待ち受けている場合は、別のサービスをClashと誤認しないよう、プロセスを確認します。ターミナルでコマンドを実行できない場合は、OS標準のネットワーク管理ツールやプロセス管理ツールで同様に確認できます。例を実行するためだけに、関係のないソフトウェアをインストールする必要はありません。

インストールの確認を終えたら、ログの場所、コアの状態、ローカルのプロキシポートを把握できているはずです。続けてサブスクリプションを登録し、TUNはまだ有効にしないでください。Windowsのファイアウォール、自動起動、サービスモードについてはWindowsのインストールと設定手順を、OSを問わない初回起動時の確認は初回設定チェックリストをご覧ください。

サブスクリプションの登録：取得・解析・有効化を区別する

サブスクリプションの利用には、クライアントがデータを取得できること、コアがデータを解析できること、現在の環境でその設定を使っていること、という3つの段階があります。一覧に名前が表示されただけでは、設定項目が作られたことしか確認できず、実際に有効になったとは限りません。まず利用できる元のサブスクリプションを1つ保存し、ローカルの上書き設定は少しずつ追加しましょう。サブスクリプションURLにはアカウント情報が含まれることがあるため、パスワードと同様に扱い、公開スクリーンショットや問い合わせ文に載せないでください。

登録から有効化まで

クライアントの「サブスクリプション」「設定」「設定ファイル」などの画面を開き、URLからインポートする項目を選びます。完全なURLを貼り付けて保存してください。URLの前後の空白や改行、チャットアプリが付けた句読点が原因で、リクエストに失敗することがあります。登録後に更新し、ダウンロード結果と解析メッセージを確認します。次に一覧からその項目を選び、現在の設定として有効化してください。ボタン名はクライアントによって「有効化」「使用」「適用」など異なります。現在の設定を示す表示とノード一覧が切り替わったかで判断しましょう。

ローカルファイルからの読み込みは、URLを使うサブスクリプションとは異なります。ファイルから読み込むと、その時点の内容がコピーされ、通常はリモートのノード変更を自動取得しません。URL登録では、更新時に再取得できます。受け取ったものが圧縮ファイル、Webページ、ログイン画面の場合、YAMLとしてそのまま読み込まないでください。拡張子だけで内容が正しいと判断するのも避けましょう。ステータスが正常なWebページでも、解析時に項目不足や予期しない文字が報告されることがあります。

失敗した段階から原因を絞り込む

ダウンロードに失敗した場合は、まずエラーの種類を確認します。タイムアウトなら現在のネットワークとサブスクリプションサーバー間の接続、証明書エラーなら端末時刻とリクエスト経路を確認します。認証エラーは、サブスクリプションURLの期限切れやアカウント状態の変更が原因かもしれません。解析エラーなら、対象の形式、インデント、コアの対応状況を調べます。データの取得と解析が済んでから、プロキシグループとノードを確認してください。サブスクリプションの問題をすべてノードの接続不可とみなすのは避けましょう。

ネットワークによっては、サブスクリプションサーバーへの接続に既存のプロキシが必要な一方、新しい端末にはまだ使えるプロキシがなく、初期設定に行き詰まることがあります。サブスクリプション提供元が案内する接続可能な入口を使うか、以前保存した有効な設定を読み込んでから、更新リクエストのプロキシ設定を検討してください。アカウント情報を含むURLを、知らないオンライン変換サービスに渡さないでください。変換サービスは元のURLと返された内容を確認できるため、設定形式だけの問題ではありません。

個人設定をリモートの内容から分けて管理する

リモートのサブスクリプション更新で設定ファイルが再生成され、直接編集したルール、ポート、グループ名が上書きされることがあります。クライアントの上書き、マージ、拡張設定の機能を優先して使い、更新後に適用されることを確認してください。マージ方法はクライアントによって異なるため、リストが追加されるのか置き換わるのかを特に確認しましょう。まずは明確なテストルールを1つ追加して動作を確かめてから、個人用の振り分け設定を広げてください。

サブスクリプションに含まれるプロキシグループ名は、設定内で一致させる必要があります。提供元が削除または改名したグループをローカルルールが参照すると、設定を読み込めないことがあります。更新後は、グループが残っているか、手動選択が維持されているか、ノード名が変わっていないかを確認します。画面に残った古いキャッシュだけで更新結果を判断しないでください。必要に応じて設定を再読み込みし、コアが実際に読み込んだ内容を確認します。ただし、その前に現在動作している状態を保存しましょう。

サブスクリプションを正常に更新できてもアクセスできない場合は、プロキシモードの章に進んでください。よくあるエラーはよくある質問で確認できます。問い合わせの際は、エラーの種類、クライアント名、機密情報を除いた設定の構造だけを伝え、サブスクリプションURL全体は公開しないでください。

プロキシモード：通信の入口と送信先を分けて考える

ルール、グローバル、直接接続は、コアに入った通信をどのように送信するかを決めます。システムプロキシとTUNは、アプリの通信をコアに取り込むかどうかを決めます。これらは別の設定です。グローバルモードを有効にしても、システムプロキシを使わないアプリが自動的に取り込まれるわけではありません。システムプロキシを無効にしても、TUNが取り込んだ通信は止まらないことがあります。「モードを変えたのにアプリの動作が変わらない」場合は、ノードを替える前に、アプリがどの入口を使っているか確認しましょう。

日常利用ではルールモードを使う

ルールモードでは、設定内のルールを上から順に確認し、各通信に適用するプロキシを決めます。接続によって直接接続になる場合も、プロキシグループを経由する場合もあります。どのルールに一致するかは、ドメイン、IPアドレス、プロセスなどの条件によります。日常利用に適していますが、ルールが揃っていて、参照するグループ名が有効であることが前提です。初回の動作確認では、まず手動選択できるプロキシグループで利用可能なノードを選び、対象ドメインがどのルールに一致したかを確認してください。ルールの送信先選択ミスを、ノードの障害と取り違えないためです。

グローバルモードでは通常、コアに入った通信がグローバル用のプロキシ設定に渡されます。そこでも適切なノードやグループを選ぶ必要があります。ルールの影響を一時的に切り分ける際に便利です。同じ接続先がルールモードでは失敗し、グローバルモードでは成功するなら、ルールによる振り分けを重点的に確認します。ただし、アプリの通信が実際にコアへ取り込まれていることを確認し、グローバル設定と元のプロキシ設定で同じノードが選ばれている必要があります。そうでなければ2つの条件を同時に変えたことになり、比較結果を判断できません。

直接接続モードでは、コアに入った通信を直接送信します。基本的なネットワーク状態の確認によく使われます。クライアントを終了することと同じではなく、ローカルの待受や仮想インターフェースが停止するとも限りません。クライアントによるシステムネットワークへの影響を完全に解除するには、TUN、システムプロキシの順にオフにしてから、通常の方法でプログラムを終了してください。直接接続に切り替えただけでは、システムプロキシの設定が残っていないか確認できません。

明示的なプロキシ指定で比較する

ターミナルのツールはデスクトップのシステムプロキシを参照しないことがあります。また、ブラウザーの拡張機能がシステム設定を上書きする場合もあります。ローカルの入口を確認するには、1回のコマンドで混合ポートを明示的に指定できます。これにより、システムプロキシの参照動作とコアの送信処理を切り分けられます。以下のコマンドでは、混合ポートが7890であることを前提としています。ポートを変更している場合は、同じ値に変更してください。Windows PowerShellでは、実行ファイル名を明示するとコマンドエイリアスとの混同を避けられます。

# Windows PowerShell
curl.exe --proxy http://127.0.0.1:7890 -I https://example.com

# macOS / Linux
curl --proxy http://127.0.0.1:7890 -I https://example.com

レスポンスが返れば、そのリクエストが指定した入口を通ったことは確認できますが、他のアプリも同じ経路を使うとは限りません。テスト中は接続一覧も開き、リクエストのドメイン、ルール、送信先を確認してください。コマンドがローカルポートへの接続失敗をすぐに返す場合は、インストールの章に戻って待受状態を確認します。ローカルポートには接続できてもリモート側でタイムアウトする場合は、ノードを調べてください。テスト対象自体に制限がある場合もあるため、必要なら正常に動作することが分かっている別の対象でも再確認しましょう。

切り替え後は接続を作り直す

モードを切り替えても、通常は新しい接続から設定が反映されます。すでに確立した長時間接続は、以前の送信先を使い続ける場合があります。設定変更後はページを再読み込みするか、関連する接続を閉じるか、テスト対象のアプリを再起動してください。接続の再利用を設定未反映と誤認せずに済みます。動画、メッセージアプリ、ブラウザーの接続プールでは、動作が変わるまで時間がかかることがあります。すべての接続を閉じると通信中のデータ転送も中断するため、影響のないタイミングで実行してください。

ルールによる振り分け：条件の順序とプロキシグループ

ルールによる振り分けでは、上から順に一致する条件を探し、通常は最初に一致したルールで送信先を決めます。ルールを作る前に、どの通信に一致させるか、一致後にどこへ渡すか、どのルールより前に実行する必要があるかを確認してください。ルールの数は品質の指標ではありません。明確な順序と、安定したプロキシグループの参照が重要です。外部ルールセットを使う前に、まず設定内のルールを理解しましょう。一度に条件を増やしすぎると、原因を追いにくくなります。

よく使われる3種類のマッチ条件

DOMAINはドメイン名の完全一致、DOMAIN-SUFFIXは指定したドメインとそのサブドメインへの一致、IP-CIDRはIPアドレスの範囲への一致に使います。MATCHは最後に適用するフォールバックルールです。後に実行する必要があるルールより上に置かないでください。ドメインルールの適用には、コアが接続先のドメイン名を把握している必要があります。アプリがIPアドレスに直接接続する場合、一部のドメイン条件は一致しないことがあるため、実際の接続情報を確認しましょう。

プロキシグループはルールそのものではなく、ルールから参照される送信先の選択肢です。手動選択型のグループは、動作確認や送信先の固定に便利です。自動テスト型のグループは指定したテスト先の結果に基づいて選択し、フォールバック型のグループは候補の利用可能性と順序を重視します。実際に使える機能はコアの対応状況によって異なります。自動テストの結果が示すのはテスト先への接続状況だけであり、すべてのWebサイト、地域限定サービス、長時間の通信で同じノードが使えるとは限りません。

# ルール設定の例：既存の設定に追加する断片で、サブスクリプション全体ではありません
# DIRECT は組み込みの直接接続先です
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.net,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

この例はルールの順序と構文を示すものです。ノードがない環境でも動作を理解できるよう、すべての送信先に組み込みの直接接続を指定しています。実際にプロキシを使う場合は、該当する送信先を、現在の設定に存在するプロキシグループ名に変更してください。例示用のグループ名をそのまま使わないでください。最後のフォールバックを直接接続にすることも、常に適切とは限りません。一致しない通信を既定でプロキシ経由にしたい場合は、検証済みのプロキシグループを指定し、影響する通信の範囲を確認しましょう。

no-resolveとDNSの関係を理解する

IPアドレスを使うルールのno-resolveは、そのルールに一致させるためだけにドメイン名をIPアドレスへ名前解決しない、という指定です。すべてのDNS通信を禁止するわけでも、すでに分かっている接続先IPへの一致を無効にするわけでもありません。プライベートネットワークの範囲に適用すれば、その範囲の判定だけを目的とした余分な名前解決を抑えられます。名前解決の結果に基づいて通信を振り分ける場合は、DNS設定との兼ね合いを確認し、すべてのIPアドレスルールに機械的に同じパラメーターを付けないようにしましょう。

DNSの応答はIPアドレスによるルールや実際の接続先に影響します。一方、ドメインルールは接続先のIPアドレスを先に解決しなくても適用できる場合があります。fake-ipモードでは、ドメインと通信の対応を維持するための合成アドレスが使われます。これはリモートサーバーの実際のアドレスではありません。合成アドレスが表示されても、すぐにDNS汚染だと判断しないでください。コアが認識したドメイン、適用されたルール、最終的な送信先を確認してから、DNSの調整や特定アプリの除外が必要か判断します。

ルール変更後に一致状況を確認する

まず現在の設定をバックアップし、ローカルの上書き設定には対象を明確にしたルールを1つだけ追加します。再読み込み後、該当ドメインにアクセスし、接続の詳細で実際に一致したルールを確認してください。一致しない場合は、より上に広い条件のルールがないか、アプリが古い接続を再利用していないか、上書き設定が実行中の設定に適用されているかを調べます。設定を読み込めない場合は、インデント、カンマ、グループ名を確認してください。まず動作していた内容に戻し、それから一つずつ修正しましょう。

ルールセットは、同じ種類のドメインをまとめて管理するのに便利です。提供元の形式、ルールの動作タイプ、更新間隔、ローカルキャッシュの保存先を確認してください。ダウンロードに失敗したときにキャッシュを利用できるかどうかは、設定の動作に影響します。用途が重複し、提供元も明確でない複数のルールセットを同時に追加するのは避けましょう。同じドメインが異なる条件に先に一致することがあります。まず分類方針を明確にしてから、それに合うルールを選んでください。

一致する順序、サブドメインの範囲、フォールバックの書き方は、Clashのカスタムルールと優先順位を詳しく解説をご覧ください。個人ルールを管理するときは、各変更の用途と確認方法を記録しておくと、後で移行しやすくなります。

TUNモード：通信の取り込み範囲を広げ、DNSを扱う

TUNは仮想ネットワークインターフェースを通じて通信を受け取り、システムプロキシに従わないアプリにも対応できます。ただし、あらゆる問題を解決する機能ではありません。有効にする前に、通常のシステムプロキシ経由で接続できることを確認してください。そうしないと、局所的な設定ミスが端末全体の通信障害に広がることがあります。また、TUNインターフェースが存在すること、ルートが取り込まれていること、DNSが取り込まれていることは、それぞれ別の状態です。すべてが同時に有効とは限りません。

必要な権限と競合の有無を確認する

デスクトップでは、インターフェースの作成やルートの変更に、サービスモード、補助サービス、管理者権限が必要になることがあります。具体的な方法はクライアントによって異なります。まず画面に表示されるサービスの状態を確認し、必要な場合だけ許可してください。端末で会社のVPN、仮想マシンやコンテナのネットワーク、別のプロキシを使っている場合は、その状態を記録しておきます。複数のツールがデフォルトルートやDNSを変更すると、ループ、競合、一部の接続不能が起きる場合があります。テストでは、ネットワーク環境をできるだけ単純にしましょう。

モバイル端末の通信取り込みは、OSが提供するVPNやネットワーク拡張の仕組みで管理されます。画面にデスクトップと同じTUN設定が表示されるとは限りません。デスクトップ用YAMLにあるネットワーク設定をすべてスマートフォンへそのままコピーしないでください。OSの制限、クライアントの実装、設定の上書き方法はそれぞれ異なります。同じサブスクリプションを使う場合でも、Wi-Fi、モバイル通信、画面ロック、ネットワーク切り替え後の動作を個別に確認しましょう。

代表的なパラメーターの役割を理解する

# mihomo のTUN設定例。既存の設定に統合してください
# まずクライアントの画面で同じ設定が生成されていないか確認してください
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

enableはインターフェースの有効化、stackはネットワークスタックの選択、auto-routeはコアがプラットフォームに応じてルートを設定する指定、auto-detect-interfaceは送信インターフェースを自動判定する指定です。この例は設定全体ではなく、どの環境でも同じ組み合わせが適切とは限りません。クライアントの画面でこれらの項目を管理している場合は、そのマージ方法に従い、設定ファイルと画面の内容が互いに上書きしないようにしてください。

dns-hijackは対象となるDNS通信を取り込むための設定ですが、アプリ内蔵の暗号化DNSをすべて自動的に取り込むわけではありません。ブラウザーのセキュアDNS、アプリ独自の名前解決、固定IP、システムキャッシュによって、確認結果が変わることがあります。有効にした後は、一般的なWebページだけでなく、ローカルネットワーク名や実際に使うアプリもテストしてください。1つのWebサイトが開けたというだけで、DNS経路がすべて想定どおりだと判断しないでください。

元に戻せる順序で有効にする

現在使える設定を保存し、クライアントの終了方法を確認してから、画面でTUNを有効にします。まずコアのログでインターフェースが正常に作成されたかを見て、日常的に使うWebサイトとLAN内のリソースにアクセスし、接続記録を確認してください。LANプリンター、ルーターの管理画面、社内アドレスに影響がある場合は、該当ネットワークのルートと直接接続ルールを確認しましょう。ルートの除外とルールによる直接接続は別の仕組みです。ドメインルールを追加するだけで、すべてのルート設定を代用することはできません。

端末全体の通信が切れた場合は、まずTUNをオフにし、クライアントは起動したまま通常のシステムプロキシ経由で接続が戻るか確認します。復旧したら2つの入口の違いを比較し、サービスの状態、デフォルトインターフェース、DNS、他のVPNを確認してください。接続できない状態で、ネットワークスタック、DNS、ルール、ノードを同時に変更しないでください。復旧しても原因が分からなくなります。リモートで管理するサーバーでは、デフォルトルートを変更して操作不能にならないよう、別のアクセス経路を確保しましょう。

UDPを使うアプリは別途確認が必要です。Webページが表示されても、正常なのは一部のTCPリクエストだけかもしれません。リアルタイム通信、ゲーム、特定のUDPプロトコルが使えるとは限りません。ノードの対応状況、サーバー側の制限、現在のネットワーク、クライアント設定を確認してください。ネットワークスタックの切り替えは最初に試す方法ではありません。まずログで該当する通信とエラーを探し、必要に応じて送信先や通信の取り込み方を見直しましょう。

システム時刻、パケットキャプチャツール、DNS経路に起因する証明書エラーについては、Clash有効化後にWebページで証明書エラーが出たときの確認手順をご覧ください。確認が終わったら、必要な通信取り込み方法だけを有効にしておきましょう。

日常のメンテナンス：更新、バックアップ、復元

安定して使い続けるには、変更内容を記録し、元に戻せるようにすることが大切です。クライアント、コア、サブスクリプションの更新と、個人ルールの変更はそれぞれ別の操作です。同時に実行しないでください。現在動作している状態を記録してから、一度に1つだけ変更し、同じ手順で動作を確認します。問題が起きても、複数の設定、ノード、通信取り込みスイッチを手当たり次第に試さず、明確な起点に戻せます。

役立つバックアップの内容

少なくとも、サブスクリプションの入手元、現在有効な設定、個人用の上書きルール、プロキシグループの選択、重要なネットワーク設定を保存してください。クライアントのデータフォルダーには、アクセス用の情報や管理インターフェースの設定が含まれることがあります。バックアップはアクセスを管理できる場所に保管し、公開リポジトリにアップロードしないでください。別の端末に移行する前に、エクスポートされる内容を確認しましょう。ルールだけを出力するものもあれば、実行用フォルダー全体を含むものもあり、プライバシーと復元できる範囲が異なります。

サブスクリプションの元データと個人ルールは分けて保存するのがおすすめです。前者はリモートから再取得できますが、後者は端末内にしかない場合があります。ポート番号、LANからの接続許可、TUNの状態、自動起動の設定も記録してください。クライアント画面に保存され、エクスポートしたYAMLに含まれないことがあります。復元後はノード名だけでなく、システムプロキシの接続先、待受アドレス、ローカルの上書き設定が実際に反映されているかも確認しましょう。

更新の前後で同じチェックリストを使う

更新前に、利用中のOSと機能に関係する変更内容を確認してください。新しいパッケージが公開されたからといって、すべての端末へすぐに一斉導入する必要はありません。更新後は、プログラムの起動、コアによる設定の解析、サブスクリプションの読み込み、ルールの適用、TUNの状態を確認します。さらに、プロキシ経由の接続先と直接接続の接続先を1つずつテストしてください。新しい環境が不安定なら、保存しておいた設定と状態に戻します。異なるコアのキャッシュや拡張項目は、そのまま古いバージョンで使えるとは限りません。

日常の遅延テストは、明らかに接続できないノードを見つけるのに役立ちますが、最小値を追い求めてサブスクリプション全体を何度も更新する必要はありません。同時に多数のテストを行うと、ネットワーク資源を消費し、サーバー側の制限を受けることもあります。ダウンロード速度、初回接続にかかる時間、長時間接続の安定性は別の指標です。よく使うプロキシグループには確認済みの候補を1つ残し、異常時に比較対象として使いましょう。1回のテスト結果に応じて頻繁に切り替えるより、原因を判断しやすくなります。

ログを記録してトラブル対処に活用する

ログのレベルは通常の設定を基本とし、問題を再現する短時間だけ詳細度を上げてください。発生時刻、アプリ、接続先ドメイン、通信の入口、モード、適用ルール、エラー内容を記録します。タイムアウト、接続拒否、解析失敗、認証エラーはそれぞれ異なる段階の問題です。単に最後の「失敗」という行だけを抜き出さないでください。ログを共有する前に、サブスクリプション情報、ノードのアドレス、内部ネットワークのアドレス、ローカルの保存先が含まれていないか確認し、必要に応じて伏せてください。

環境の変化も記録してください。新しいWi-Fiへの接続、社内ネットワークへの接続、セキュリティソフトの有効化、仮想マシンの起動後に問題が発生したなら、デフォルトルート、DNS、ファイアウォールルールが変わった可能性があります。まず以前のネットワーク環境に戻して比較し、クライアントの設定変更が必要か判断しましょう。同じネットワーク上の複数の端末で同時に問題が起きた場合は、各端末のクライアントを再インストールするより、共通のネットワークやリモートサービスを先に確認してください。

終了時とアンインストール前に確認すること

終了する前にTUNとシステムプロキシをオフにし、通常の手順でプログラムを終了してください。異常終了後にブラウザーが接続できない場合は、システムプロキシが停止済みのローカルポートを参照していないか確認します。ポートが使われていないと分かった場合に限り、現在のネットワークに合わせて残った設定を解除しましょう。入手元が不明なネットワークリセット用スクリプトを実行しないでください。全体をリセットすると、社内プロキシ、固定IPアドレス、その他の有効なネットワーク設定まで消える可能性があります。

応用へのステップ：設定の利用から管理まで

応用とは、設定項目を増やすことではありません。変更による影響を予測し、記録をもとに結果を確認できることです。前の8段階を終えたら、設定の構造、ルールプロバイダー、DNS、実行環境の管理の順に学びましょう。一度に追加する機能は1つにし、元に戻せるテスト用設定で確認してから日常環境に反映します。用途がはっきりしない項目は、最初は初期値のままにするほうが、設定の最適化をうたう一式をそのままコピーするより安全です。

まず設定どうしの依存関係を把握する

設定は、入口、送信先、プロキシグループ、ルール、DNSから成る依存関係のネットワークとして捉えられます。ルールはプロキシグループを参照し、グループはノードや別のグループを参照します。プロバイダーは外部コンテンツを取得し、システム連携によってアプリの通信が入口に送られます。名称を変更するときは参照元を順に確認してください。ノードの提供元を削除する前に、プロキシグループから参照されていないか確認しましょう。設定を読み込めたことは最初の確認にすぎません。最終的な送信先が本来の目的に合っているかも検証してください。

ルールプロバイダーを学ぶときは、まず内容が分かっている小規模なルールセットを作り、形式、動作タイプ、更新結果を確認します。外部リストを大量に取り込み、説明できない組み合わせに通信の振り分けを任せないでください。更新間隔も適切に設定しましょう。数秒ごとに取得し直す必要のないルールを頻繁に更新しても、ネットワークへの依存が増えるだけです。初回起動でキャッシュがない場合と、普段の更新に失敗したもののキャッシュが残っている場合の違いも理解しておきましょう。

次にDNSと接続メタデータを調べる

DNSを学ぶときは、まずシステムによる名前解決、コアによる名前解決、アプリ独自の名前解決の違いを把握し、fake-ipと実際のアドレスを返す方法を比較します。テストごとに、リクエストのドメイン、名前解決の結果、一致したルール、通信の送信先を記録してください。ある方式が特定のアプリの問題を解決しても、LAN内の機器を見つけにくくしたり、独自の名前解決を行うアプリに影響したりすることがあります。特定のWebサイトだけで判断せず、よく使うケースを再確認できるようにしましょう。

トラフィックのスニッフィングで条件によってドメイン情報を補える場合がありますが、すべてのアプリの通信内容を確認できるわけではなく、あらゆる接続で接続先を正しく補えるとも限りません。効果はプロトコル、暗号化方式、アプリの動作に左右されます。まずスニッフィングを使わない状態の接続情報を把握し、必要に応じて有効化を検討してください。正しいDNSの取り込みやルール設計の代わりとして使わないようにしましょう。機密性の高い業務では、利用中のネットワークの管理ルールにも従ってください。

コマンドラインでコアを使う場合は、公開範囲に注意する

コアの直接実行はサーバーやルーターに適していますが、設定ファイルの保存先、作業ディレクトリ、プロセスの再起動、ログの保持、権限を自分で管理する必要があります。まずフォアグラウンドで設定を確認してから、システムサービスとして実行してください。以下のコマンドは実行可能なmihomoがインストール済みで、現在のディレクトリに設定ファイルがあることを前提としています。設定のテスト用であり、ダウンロードやインストールは行わず、すべてのリモートノードに接続できることを確認するものでもありません。

# 現在の設定の構文と読み込み可否を確認
mihomo -t -f ./config.yaml

# 指定した設定をフォアグラウンドで実行
mihomo -f ./config.yaml

設定テストに成功しても、実際の動作環境でルールと接続を確認する必要があります。サービス環境と対話形式のターミナルでは、作業ディレクトリ、環境変数、ユーザー権限が異なる場合があります。フォアグラウンドで動作しても、サービスから同じファイルを読み込めるとは限りません。絶対パスと明確なデータディレクトリを指定すると、取り違えを減らせます。ただし、実際の設置場所に合わせて設定し、他の端末のパスをそのまま使わないでください。

LANからの接続を許可すると、ローカルのプロキシ入口にアクセスできる範囲が広がります。外部制御インターフェースでは、より強力な設定管理が可能になる場合もあります。どちらもインターネット上に無制限で公開してはいけません。共有や管理が必要な場合に限って有効にし、待受アドレスとネットワークの接続範囲を制限して、クライアントが対応する認証機能を使ってください。スマートフォンから管理画面を開くために、ルーターのポートを安易に公開しないでください。設定する前に、アクセス可能な範囲と無効化の方法を確認しましょう。

トラブル対処の手順を自分用にまとめる

よく使う環境のために、直接接続する基本の確認先、プロキシが必要なサービス、LAN内のリソース、ターミナルからの明示的なプロキシ接続、必要なUDPアプリを含む定型テストを用意してください。設定を変えた後は、同じ項目を一つずつ再確認し、印象ではなく結果を記録します。問題が起きたら、入口、名前解決、ルール、送信先、リモートの5段階で原因を絞り込みましょう。記録を積み重ねれば、移行時に役立ち、再現可能な問題を他の人にも説明しやすくなります。

それぞれの変更目的と確認結果を説明でき、以前の状態に戻せるなら、設定を自分で管理するための基礎が身についています。今後機能を選ぶときも、まず問題がどの段階にあるかを確認し、それに合った機能を選んでください。設定項目を増やすこと自体を目的にして、不要な複雑さを持ち込まないようにしましょう。