完全ガイド · インストールから設定・メンテナンスまで

Clashクライアントとサブスクリプション設定の完全ガイド

基本からクライアント選び、導入、サブスクリプション、モード、ルール、TUN、メンテナンス、応用まで、章ごとに解説します。

初回接続はクイックスタートガイドに沿って基本操作を完了できます。このページでは、各手順の設定の関係や検証方法、切り戻しの範囲を解説します。例ではmihomoでよく使われる項目を取り上げます。クライアントによって画面上の名称や設定の上書き方法が異なる場合があるため、利用前に現在のコアと設定に関する説明を確認してください。

1. 基本用語：クライアント、コア、設定

通信はどのように処理されるか

Clashのエコシステムに、画面や機能が完全に共通した単一のプログラムがあるわけではありません。クライアントは設定のインポート、モード選択、システム設定、ログ確認などの操作画面を提供し、コアは接続を受け付け、ルールを解析して外部への接続を確立します。通常は両者が同じインストーラーで配布されますが、更新時期が一致するとは限りません。機能の対応状況を判断するには、画面にスイッチがあるかだけでなく、実際に動作しているコアが該当項目を認識するかも確認してください。クライアント名だけで判断することはできません。

通信の流れは、アプリ、接続方法、コア、ルール、アウトバウンドの順に考えると分かりやすくなります。アプリがローカルのプロキシポートを直接使う場合もあれば、システムプロキシ設定を通じて通信を渡す場合もあります。TUNを有効にすると、仮想ネットワークインターフェースが通信を取り込むこともあります。コアは通信を受け取ると、モードとルールに基づいて直結、拒否、またはポリシーグループへの振り分けを行います。この流れを把握すれば、Webページが開かない原因がアプリの接続、名前解決、リモート接続のどの段階にあるかを切り分けられます。

サブスクリプションだけで設定が完結するとは限らない

サブスクリプションURLはリモートリソースを取得するためのアドレスであり、接続を開始するスイッチではありません。返される内容は、設定一式の場合もあれば、プロキシプロバイダーが使うリソースファイルだけの場合もあります。設定一式には通常、プロキシ、ポリシーグループ、ルール、DNSなどが含まれますが、リソースファイルはその一部だけを担います。ノード一覧を設定一式として直接インポートすると、形式エラーになることや、リソースだけで使えるポリシーグループがないことがあります。インポート前に、提供元が案内する形式とクライアントが求める形式を確認してください。

設定ファイルでは階層をYAMLで表すことが多く、インデントにも意味があります。ルート階層の項目と子階層の項目は入れ替えられず、リスト項目は通常ハイフンで始まります。インデントにはタブではなくスペースを使います。同じ項目が重複した場合の扱いはパーサーによって異なるため、後の項目が前を上書きすると決めつけず、明示的に統合してください。テキストを解析できても、ポリシーグループの参照、リソースのパス、実行権限まで正しいとは限りません。構文チェックは最初の確認にすぎません。

設定の取得元と動作状態

クライアント画面では、元のサブスクリプション、上書きファイル、最終的に有効な設定を分けて考えてください。リモートサブスクリプションは更新時に再取得されることがあり、上書き機能はローカルのポート、ルール、DNSなどの変更を保持するために使います。最終設定はクライアントがこれらを統合し、コアに渡した結果です。設定が元に戻る、項目が反映されない、ルールの順序が変わるといった場合は、ダウンロードした一時ファイルを繰り返し編集するのではなく、まず最終設定を確認してください。配列の統合方法はクライアントによって異なり、上書きが常に追記されるとは限りません。

「設定を保存した」「コアが読み込んだ」「対象アプリがプロキシを使った」は、それぞれ別の状態です。エディターで保存できても、新しい内容をコアが受け付けたとは限りません。コアが設定を読み込んでも、ブラウザーなどのアプリが接続を渡しているとは限りません。確実に確認するには、読み込み結果と接続記録の両方を見たうえで、対象アプリから新しいリクエストを送ります。既存の接続は以前のアウトバウンドを使い続けることがあり、古いタブやセッションだけを見ていると、キャッシュの動作を設定未反映と誤解することがあります。

2. クライアント選び：プラットフォーム、コア、メンテナンス方法

OSと使い方から選ぶ

クライアント選びでは、まずOS、次にプロセッサのアーキテクチャと利用シーンを確認します。日常的にPCやスマートフォンで使うならGUIクライアント、サーバーやルーターならコアの直接実行を検討します。当サイトのダウンロードページでは、対応プラットフォーム向けにClash Plusを優先して掲載しています。デスクトップでの設定管理やmihomo関連機能が必要なら、Clash Verge RevやFlClashも比較できます。おすすめ順は、すべての機能が同じであることを保証するものではありません。サブスクリプション形式、接続方法、プラットフォームの権限を個別に確認してください。

Windowsでは、システム設定でシステムの種類を確認し、特にx64とARM64を区別してください。macOSではIntelかApple Siliconかを確認します。OS名だけでファイルを選ばないでください。Androidでは端末のアーキテクチャに合ったインストールパッケージを選び、不明な場合はダウンロードページに汎用パッケージがあるか確認します。Linuxではアーキテクチャに加えて、ディストリビューションのパッケージ形式やデスクトップ環境も関係します。インストールできても、トレイ表示、サービス管理、権限の確認方法が同じとは限りません。

プラットフォーム選択肢確認するポイント
WindowsClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuシステムアーキテクチャ、バックグラウンドサービス、システムプロキシの復元
macOSClash Plus、Clash Verge Rev、FlClashチップの種類、ネットワーク権限、スタートアップ項目
AndroidClash Plus、Clash Meta for Android、FlClash、Surfboardサブスクリプション形式、VPNの許可、バックグラウンド制限
iOSClash Plusストアの説明、ネットワーク拡張権限、設定の互換性
LinuxClash Verge Rev、FlClashパッケージ形式、アーキテクチャ、デスクトップ連携、サービス権限

名称だけで機能の互換性を判断しない

Clash、Clash Meta、mihomoには系譜上のつながりがありますが、常に同じ項目をサポートする別名として扱うことはできません。プロトコル、ルールの種類、DNSの選択肢はコアの実装に応じて変わり、オンラインの設定例も異なる系統向けの場合があります。クライアントを移行する際は、まず現在使っている主要機能を記録し、移行先で一つずつ対応状況を確認してください。特にプロキシプロバイダー、ルールプロバイダー、スクリプト関連機能、プラットフォーム固有の接続方法に注意し、過去の設定を一度にすべて移行しないでください。

スマートフォンでは設定形式も確認が必要です。Surfboardの設定形式はClash YAMLと同じではありません。ダウンロードページに同じプロキシクライアントとして掲載されているからといって、同じファイルをすべてのアプリにインポートできるわけではありません。iOSではダウンロードページからClash Plusのストア情報を確認でき、公式サイトclashplus.ioでも製品情報を確認できます。利用できるインポート方法は実際のアプリ画面を確認してください。デスクトップの設定項目をそのままモバイルの設定に当てはめることはできません。

アーカイブ版クライアントと移行の手間

Clash for WindowsとClashX Metaは、ダウンロードページにメンテナンス終了済みのアーカイブ版として掲載しています。旧環境との互換性確認や過去の設定の参照には使えますが、新規インストールの判断を古いチュートリアルの画面だけに頼るのは避けてください。メンテナンス中のクライアントを選ぶ場合も、設定の保存場所、ログのエクスポート方法、アンインストール後のシステム設定の扱いを確認しましょう。特に複数端末への移行や長期運用では、ボタンの数よりバックアップと復元のしやすさが重要です。

複数のクライアントを同時にインストールした後、そのまま重ねて起動するのは避けてください。ポート、システムプロキシ、VPN接続を複数のプログラムが取り合い、結果の切り分けが難しくなることがあります。クライアントを比較する場合は、同じ設定、同じネットワーク、同じアプリで順番にテストし、毎回前のプログラムを終了してください。動作条件を記録したうえで、使い続けるクライアントを決めましょう。インストーラーと各プラットフォームへのリンクはクライアントのダウンロードページにあります。コアの関係についてはClash、Clash Meta、mihomoの違いもご覧ください。

3. インストールと確認：権限、ポート、初回起動

戻せる状態を保ってからインストールする

インストールを始める前に、起動中の他のプロキシクライアントを終了し、システムの元のプロキシ設定を記録してください。社内ネットワークや学校のネットワークを使っている場合、または専用VPNを利用している場合は、業務上のルールを確認してから作業し、必要な接続を中断しないようにします。旧クライアントを使っていた端末では、バックグラウンドプロセスや自動起動項目も確認してください。ウィンドウを閉じただけでは、コアプロセスが終了していないことがあります。初回インストールでは、複雑なフォルダー権限や同期フォルダーの設定を加えず、通常のユーザー権限で管理できる場所を使いましょう。

Windowsではインストールウィザードを完了したら、初回起動時はTUNを無効のままにし、メイン画面、設定画面、ログ画面が開くことを確認します。Windowsの保護機能が警告を表示した場合は、セキュリティ機能全体を無効にするのではなく、ダウンロード元とリリース情報を確認してください。インストール先への書き込み権限と、実行データを保存するフォルダーへの書き込み権限は別です。クライアントが起動しても設定を保存できない場合は、データフォルダーの権限、ディスクの空き容量、同期ソフトやセキュリティソフトによるファイルの使用状況を確認してください。

macOSでは、現在のパッケージに記載された方法でインストールし、システムの案内に従って必要な権限を付与します。アプリの配置場所を変更すると、以前の場所を参照するスタートアップ項目やバックグラウンドサービスが残ることがあります。自動起動を有効にする前に、最終的な配置場所を決めてください。Linuxではディストリビューションに合ったパッケージ管理方法でインストールします。依存関係のエラーが出た場合は、パッケージマネージャーの出力を確認し、依存関係の不足、アーキテクチャの不一致、グラフィカル環境の問題を切り分けてください。起動失敗のすべてをサブスクリプションの問題と決めつけないようにしましょう。

モバイル端末の権限とバックグラウンド制限

Androidでは設定のインポート前後にVPN接続の許可が必要になることがあります。これはシステムが通信を取り込む経路を作るための権限であり、サブスクリプションの認証とは別です。初回の許可後も、クライアントで接続を開始する必要があります。画面ロック後に接続が切れやすい場合は、バッテリー最適化、バックグラウンド動作、メーカー独自の自動起動設定を確認してください。ただし、現在の機能に必要な権限だけを許可しましょう。iOSでもシステムの案内に従ってネットワーク設定を許可し、他のVPNアプリが接続経路を占有していないか確認してください。

ポートの競合とコアの起動

デスクトップでは、HTTP、SOCKS、または混合ポートをローカルで待ち受ける構成が一般的です。混合ポートは対応するHTTPプロキシ接続とSOCKS接続の両方を受け付けますが、すべてのプログラムが自動的に利用するわけではありません。例にある7890は任意のポートであり、すべてのクライアントで固定されている値ではありません。ログにアドレスの使用中と表示されたら、まず使用しているプロセスを特定し、古いプログラムを終了するかポートを変更します。アプリ側のプロキシアドレスだけを変更し、クライアントの待ち受け設定を変更し忘れないようにしてください。

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

# macOS：TCPの待ち受けプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：TCPの待ち受けポートとプロセスを確認
ss -lntp

確認コマンドの結果が空でも、該当する待ち受けが見つからなかったことを示すだけで、クライアントが壊れているとは限りません。ポートが異なる場合や、コアがまだ設定を読み込んでいない場合があります。プロセス情報の表示に高い権限が必要なこともあります。まずクライアント画面で実際のポートと動作状態を確認し、ログと照合してください。プロセスが繰り返し終了する場合は、再インストールを繰り返すのではなく、設定の解析エラー、リソースのパス、権限に関する警告を確認します。再インストールしても元のデータフォルダーが残り、問題の条件が変わらないことがあります。

4. サブスクリプションと更新：インポート、リソース間隔、上書き

内容に合ったインポート方法を選ぶ

クライアントの設定画面またはサブスクリプション画面で、新規追加、インポートなどの項目を選び、サブスクリプションURL全体を該当欄に貼り付けます。コピーしたURLがチャットアプリで改行されていないか、前後に空白が混ざっていないか、認証パラメーターが欠けていないか確認してください。インポート後は、その設定を現在使用するものとして選択する必要があります。リストに新しい項目が表示されたことは、登録されたことを示すだけです。ダウンロード、解析、コアへの読み込みが完了したかは、状態表示とログで確認してください。リスト上の名前だけで判断しないようにしましょう。

ローカルファイルをインポートする際は、YAMLをクライアントの管理フォルダーにコピーする場合もあれば、元ファイルへの参照を保持する場合もあります。動作はクライアントによって異なります。元のダウンロードファイルを編集しても、クライアント側に自動反映されるとは限りません。反対に、編集画面によっては管理中のファイルが直接変更されます。インポート後はどのファイルを編集しているか確認し、元ファイルのバックアップも残してください。提供元から渡されたものがエンコード済みのノード一覧や別形式の設定であれば、対応するインポート方法か信頼できる変換方法を使いましょう。拡張子を変更するだけでは変換できません。

設定全体の更新とリソースの更新

サブスクリプション全体を更新するとリモート設定の内容が置き換わります。一方、プロキシプロバイダーの更新では、通常そのプロバイダーのリソースだけが更新されます。ルールプロバイダーには別のダウンロード間隔が設定されることもあります。これらは異なる画面や操作で管理される場合があり、1つを更新しても残りが更新されたとは限りません。クライアント画面の更新間隔が分単位でも、mihomoのプロバイダーにあるinterval項目は通常秒単位です。画面への入力値をそのままYAMLに転記したり、1つの項目から設定全体の更新頻度を判断したりしないでください。

# ローカルプロキシプロバイダーの例：既存の設定に統合してください
# ファイルの内容は現在のコアが対応するプロキシプロバイダー形式にしてください
proxy-providers:
  local-resources:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: 手動選択
    type: select
    use:
      - local-resources

上の例はプロバイダーとポリシーグループの参照関係を示すもので、リソースファイルを自動作成するものではありません。利用前にコアの実際の作業ディレクトリにファイルを用意し、クライアントからそのパスにアクセスできることを確認してください。HTTP形式のプロバイダーでは、有効なリソースURL、保存先、更新間隔も必要です。URLは信頼できる提供元から入手してください。管理用WebページをリソースのURLとして使うことはできません。サブスクリプションからHTML、ログインページ、エラーメッセージが返された場合は、リクエスト自体が成功していてもYAMLリソースとして読み込めません。

ローカル変更は永続化できる場所に保存する

独自のポート、DNS、ルールは、クライアントが対応する上書き、マージ、拡張設定の仕組みを使って保存してください。リモートファイルを直接編集すると、次回の更新で変更が上書きされるおそれがあります。一方、サブスクリプション全体を手動でコピーすると、リモートリソースの更新機能を失います。上書きを設定した後は、最終設定で項目の階層や配列の順序を確認してください。特にルール一覧は、全体を置き換える仕組みもあれば、先頭や末尾に追加できる仕組みもあります。最終ルールへの影響は大きく異なります。

更新に失敗したら、まず対象とエラーの種類を記録してください。認証エラーならURLの有効性とアカウント状態、解析エラーなら返された内容と形式、タイムアウトならローカルネットワーク、名前解決、ダウンロード経路を確認します。サブスクリプションのダウンロードに現在のプロキシが必要なのに、そのプロキシも同じサブスクリプションに依存するという起動時の依存問題が起きることがあります。信頼できるネットワークで既知の正常な設定を復元してから更新してください。機密情報を含むURLを、公開変換サービスや一般公開のトラブル報告ページに貼り付けないでください。

5. プロキシモード：接続方法とアウトバウンドの選択

システムプロキシとルールモードは別の設定

システムプロキシ、TUN、ルールモードはそれぞれ異なる層の仕組みです。システムプロキシは、システム設定に対応するアプリからローカルポートへ接続を渡します。TUNは別の方法で通信を取り込みます。ルール、グローバル、直結の各モードは、コアが受け取った通信のアウトバウンドを選びます。そのため、グローバルモードにしてもプロキシを使っていないアプリの通信が自動的に取り込まれるわけではありません。システムプロキシを有効にしても、すべてのリクエストがリモートのアウトバウンドを通るとは限りません。トラブル対処では、まず通信がコアに届いているか確認してください。

通常の利用では、ドメイン、アドレス、その他の条件に応じて通信を振り分けるルールモードから始めます。グローバルモードは、特定のアウトバウンドが使えるか一時的に確認するのに便利ですが、ポリシーグループで接続先を正しく選ぶ必要があります。直結モードはリモート経路が問題かどうかを見分けるのに使えます。ただし、アプリがコアに接続していなければ比較しても診断にはなりません。モードを比較するときは、同じアプリと接続先で新しい接続を作り、ネットワーク環境の変化をモードの差と混同しないようにしてください。

項目役割の階層確認する場所
システムプロキシアプリにローカルプロキシの使用を通知システム設定、アプリのプロキシ設定
TUN仮想インターフェース経由で通信を取り込むインターフェース、ルート、クライアントのログ
ruleルールに基づいてアウトバウンドを選択接続の詳細、適用されたルール
globalグローバルポリシーを使って選択グローバルポリシーグループの現在の選択
directコアから接続先へ直接接続接続記録に表示されるアウトバウンド情報

再現できるテストリクエストを作る

システムプロキシを検証するには、まずクライアントの待ち受けアドレスとポートを確認し、次にアプリ固有のプロキシ設定がないか確認します。ブラウザー拡張機能、ターミナルの環境変数、開発ツールに組み込まれた設定が、システムの既定値を上書きしている場合があります。デスクトップでシステムプロキシを有効にしても、ターミナルコマンドが同じ経路を使うとは限らないため、明示的なパラメーターでテストしてください。次のコマンドは、本機の混合ポートを指定してリクエストを送信します。ポートが異なる場合は同じ値に変更してください。接続先は、簡単なHTTPSリクエストを送るためのものです。

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

応答が返れば、指定したポートを通じて今回の接続が完了したことを示しますが、リモートプロキシが使われたとは限りません。最終的なアウトバウンドは現在のモードとルールで決まるため、クライアントの接続画面で確認してください。コマンドがローカルポートへの接続時点で失敗する場合は、待ち受けとプロセスを調べます。証明書エラーが出た場合は、システム時刻、証明書環境、接続先を確認してください。日常的な解決策として証明書検証を無効にすることは避けましょう。ステータスコードも応答元に応じて解釈する必要があり、一律にノードの障害とは言えません。

モードの変更と接続のライフサイクル

モードやポリシーグループを切り替えても、主に影響を受けるのはその後に作られる接続です。既存の長時間接続は以前の経路を使い続けることがあります。ブラウザーの接続プール、メッセージアプリのセッション、ダウンロードタスクは、特に古い接続を維持しやすいものです。厳密に検証する場合は、対象アプリから新しいリクエストを送り、必要に応じて対象接続を閉じるかアプリを再起動してください。すぐに設定全体を消去する必要はありません。クライアントに接続を切断する機能がある場合は、重要な転送まで中断しないよう対象範囲を確認しましょう。

クライアントを終了した後にWebページが開けなくなる場合、システムプロキシが停止済みのローカルポートを参照したままになっていることがあります。まずシステムのネットワーク設定で残っているプロキシを無効にし、他のプログラムが設定を書き換えていないか確認してください。ターミナルの環境変数を使っている場合は、現在のセッションから該当するプロキシ変数も削除します。直結に戻せたらクライアントを再起動し、終了時の処理を調べましょう。ルールモードやグローバルモードを何度切り替えても、コア終了後にローカルポートへ接続できない問題は解決しません。

6. ルール分岐：マッチ順序とリソースの管理

最小限のルールから始める

ルールモードでは通常、一覧の先頭から順に判定され、最初に一致したルールで通信先が決まります。ルールの内容が正しくても、位置が不適切だと一度も実行されないことがあります。個別のドメインや優先して処理したい条件は、より広い条件より前に置いてください。最後に適用されるMATCHは末尾に配置します。ルールを追加する前に接続の詳細を見て、現在適用されているルールを確認してから挿入位置を決めましょう。元の順序を把握せずに末尾へ追加しても、ファイルが長くなるだけで結果は変わらないことがあります。

ドメインルールとIPアドレスルールは、解決する問題が異なります。DOMAINは指定したドメインに一致し、DOMAIN-SUFFIXはドメイン本体とサブドメインを対象にできます。IP-CIDRはアドレス範囲で判定します。アプリがIPアドレスへ直接接続する場合や、ドメイン情報がコアに渡らない場合は、想定したドメインルールに一致しないことがあります。このときは同じドメインのルールを重ねて追加するのではなく、接続記録に表示された接続先を確認してください。ルールの判定に必要な情報が、実際に取得できている必要があります。

# 最小限のルール例。リモートプロキシリソースは含みません
mode: rule
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

この設定例はルールの順序と構文を確認するためのもので、未一致の通信はすべて直結します。完全なプロキシ設定ではありません。特定の通信を独自のポリシーグループに渡すには、まずグループを定義し、ルールの適用先にグループ名を完全一致で指定します。名前に含まれる空白や大文字・小文字も設定内容どおりにしてください。no-resolveは、このアドレスルールのためだけに名前解決を開始しない設定です。リクエスト全体でDNS問い合わせが発生しなくなるわけでも、すべてのアドレスルールが無効になるわけでもありません。

ポリシーグループとルールセットは別々に管理する

ポリシーグループはアウトバウンドを選び、ルールは使用するポリシーグループを選びます。手動選択グループは接続先を明示的に制御したい場合に便利です。自動テストやフェイルオーバーのグループは、テスト先、間隔、判定方法に依存します。テスト先に接続できても、実際のサービスが正常に使えるとは限りません。アプリごとにプロトコル、地域、認証、接続先の制限が異なることがあります。1つのテスト結果だけで実際の利用状況を判断せず、表面的な即時反映を期待してテスト間隔を短くしすぎないようにしてください。

ルールが多い場合は、ルールプロバイダーで分割して管理できますが、リソースの形式と動作を合わせる必要があります。ドメイン一覧、IPアドレス一覧、完全なルール条件を含むリソースファイルでは形式が異なるため、ダウンロードURLだけを差し替えることはできません。プロバイダーを定義した後、対応するルールから参照しなければ、ファイルをダウンロードできても振り分けには使われません。パス、名前、動作の種類をまとめて確認してください。リソースの解析に失敗した際に古いリソースを維持するか、読み込みが失敗するかは、クライアントとコアの状態によって異なります。ログで実際の結果を確認しましょう。

適用結果からルールの問題を切り分ける

トラブル対処では、変更する前に対象ドメイン、実際の接続先アドレス、適用されたルール、最終的なポリシーグループを記録してください。Webページは、メインサイトのほか、静的リソースや認証APIなど複数のドメインにリクエストすることがあります。メインドメインだけを直しても、ページ全体が読み込めるとは限りません。サービス全体を同じサフィックスのルールにまとめるのではなく、リクエストごとに失敗した対象を確認します。LAN内の機器の場合は実際のネットワーク範囲も確認してください。例にあるプライベートアドレスの範囲が、すべての家庭、企業、仮想ネットワークをカバーするわけではありません。

ルール更新では、リソースの提供元が信頼できるかどうかも考慮してください。ルールがどのカテゴリを対象にしているか、更新によって通信先が変わるかを確認しましょう。大規模なルールセットを複数統合すると、重複や条件の重なりで管理が複雑になります。ルールを増やせば分岐が正確になるとは限りません。まず明確な要件に絞り、接続記録を見ながら必要な例外を追加してください。ルールを追加するたびに目的を記録し、更新後に重要なアプリが想定どおり動作するか確認しましょう。

7. TUNとDNS：通信の取り込みと名前解決の範囲

TUNが本当に必要か確認する

TUNは仮想ネットワークインターフェースを通じて通信を取り込み、システムプロキシ設定に従わないアプリにも対応します。ただし、ネットワーク障害を解決する万能スイッチではありません。有効にすると、ルーティング、権限、DNS、他のネットワークソフトとの連携が必要になり、ローカルポートを使うだけのプロキシより複雑になります。まず通常のプロキシ接続を動作させてからTUNを有効にし、取り込まれる通信の範囲を比較してください。モバイル端末のシステムVPN機能とデスクトップの仮想ネットワークカードでは、権限や実装が異なります。同じ操作手順をそのまま当てはめないでください。

デスクトップクライアントでは、サービスコンポーネントを使ってインターフェースの作成やルート変更に必要な権限を得ることがあります。有効化前にサービスの状態とシステムの確認画面を見てください。スイッチの表示が変わったかだけでは判断できません。企業VPN、コンテナネットワーク、他のトンネルを同時に使用すると、ルートの優先順位やDNSの取り込みが競合することがあります。テストではまず通信を取り込む方法を1つだけ使い、元のルートの動きを記録してください。遠隔操作している端末では、ルート変更後に管理接続を失わないよう復旧経路を用意しましょう。

# mihomo TUNの設定例：統合前にクライアントのサービスとプラットフォームの対応を確認
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この設定例は、すべてのプラットフォームで使える共通スイッチではありません。auto-routeは関連ルートの自動設定に使い、auto-detect-interfaceはアウトバウンドインターフェースの判定を補助します。実際の結果はOSやネットワーク環境にも左右されます。クライアントの画面ですでにこれらの項目を管理している場合は、永続化する設定方法を1つに決め、上書き設定同士が競合しないようにしてください。Wi-Fi、有線LAN、テザリングを切り替えた後に接続がおかしくなったら、サブスクリプションを変更する前にインターフェースの判定結果とルートの更新を確認します。

DNSとFake-IPの設定関係

DNSはドメインをアドレスに変換し、ドメインによる振り分けやアウトバウンドの選択に必要な情報も提供します。システムDNS、ブラウザーの暗号化DNS、クライアント内蔵のDNS、リモートでの名前解決が同時に使われることがあるため、まず実際の問い合わせ経路を確認してください。TUNで従来のDNSポートを取り込んでも、アプリ内の暗号化DNSまで取り込まれるとは限りません。特定の確認サイトでリゾルバーが1つ表示されたことだけを根拠に、すべてのリクエストで情報が漏れている、またはすべて正しく解決できていると判断することはできません。

Fake-IPモードでは、ドメインに仮想アドレスを割り当て、コアが対応付けを使ってドメインを特定してから接続を処理します。これらはWebサイトの実際のサーバーアドレスではないため、仮想アドレスが表示されても、それだけで名前解決のエラーとは言えません。一部のLAN内機器の検出、デバイス認証、特殊なプロトコルでは、この方式が適さない場合があります。互換性の問題を確認できたドメインだけに例外を設定し、すぐにモード全体を無効にしないでください。例外の範囲を広げるほど動作が分かりにくくなるため、まず個別の接続先で確認しましょう。

DNSの上流サーバー、プロキシサーバーのドメイン解決、直結リクエストの名前解決には、起動時の依存関係もあります。上流DNSへの接続にプロキシが必要なのに、そのプロキシのドメイン解決も同じ上流DNSに依存すると、循環が発生する場合があります。どの名前解決でプロキシ接続を確立し、どれを通常の通信に使うのかを明確にし、現在のコアが対応する項目で設定してください。出所の分からないDNSサーバー一覧をまとめてコピーしないようにしましょう。サーバーを増やしても結果が安定するとは限らず、遅延やトラブル対処の分岐が増えることがあります。

通信の取り込み範囲と終了後の復元を確認する

TUNを有効にした後は、これまでコアに接続していなかったアプリが接続記録に表示されるか確認し、次にルールとDNSの動作を見ます。LANへの接続に問題が出た場合は、ネットワーク範囲のルート、アドレスの競合、ドメインの例外を確認してください。ネットワーク切り替え後だけ問題が起きる場合は、アウトバウンドインターフェースとDNSキャッシュを調べます。TUNを無効にした後は、仮想インターフェース、自動ルート、システムDNSが元に戻ったことを確認してください。復元が済む前に新しいルールを重ねると、通信の取り込みの問題をルール分岐の問題と誤診するおそれがあります。

8. 日常のメンテナンス：更新、バックアップ、段階的なトラブル対処

更新対象を分けて管理する

日常のメンテナンスでは、クライアント、コア、サブスクリプション全体、プロキシプロバイダー、ルールリソースを区別してください。クライアントの更新は画面や連携機能、プラットフォーム対応に関わり、コアの更新はプロトコルやネットワークの挙動に影響します。リソースの更新では設定内容が変わります。ある更新画面に完了と表示されても、すべての対象が同じ状態になったとは限りません。1回のメンテナンスでは、まずリソースを更新して動作を確認し、その後にプログラムを更新することをおすすめします。複数の層を同時に変えると、互換性の問題がどこから生じたのか判断しにくくなります。

プログラムを更新する前に、現在の設定、上書き内容、重要な項目を保存し、接続方法とポートを記録してください。バックアップには復元に必要な情報を含めますが、公開リポジトリやチャットグループには置かないでください。クライアントのエクスポート機能に、システムサービスの状態、外部ファイル、環境変数が含まれないことがあります。復元前に対象範囲を確認しましょう。ファイル形式のプロバイダーを使う場合は、相対パスに対応するファイルもバックアップします。メインの設定だけを保存してリソースフォルダーを忘れると、移行後に構文エラーがないのにリソースを見つけられないことがあります。

問題が発生した段階から範囲を絞る

Webページが開けない場合は、まずクライアントを終了してシステム設定を元に戻し、通常のネットワーク接続を確認してください。通常の接続も使えない場合は、Wi-Fi、ゲートウェイ、認証画面、通信事業者のネットワークを先に調べます。通常の接続が使えるなら、ローカルポートが待ち受けているか、アプリの接続がコアに届いているか、ルールが適用されたか、アウトバウンドが成功したかを順に確認します。この手順なら、「接続が取り込まれていない」問題と「取り込み後の接続失敗」を分けられます。目的なくすべての設定を切り替える必要はありません。

サブスクリプションの更新失敗と、サービスへの接続失敗は別々に起きることがあります。サブスクリプションの認証が切れていても、既存の設定で接続できる場合があります。サービスへのアウトバウンドが使えなくても、サブスクリプションはダウンロードできることがあります。記録を取る際は、対象、操作、エラーの種類を明記してください。ログのタイムアウト、接続拒否、名前解決エラー、認証エラーはそれぞれ意味が異なり、すべてを「ネットワークが遅い」とまとめることはできません。ログが長い場合は、再現できる操作を1回に絞り、該当する時間帯の情報を確認しましょう。

速度、遅延、アプリの使用感

接続テストの遅延は、特定の接続先とテスト方法による1回の結果にすぎず、実際のダウンロード速度や安定性、すべてのWebサイトでの使い心地を表すものではありません。速度の問題を調べる場合は、ネットワークとテスト対象を固定し、直結、複数のアウトバウンド、対象アプリでの実際の転送をそれぞれ比較してください。無線の電波状況、並行するダウンロード、接続先の制限、経路の混雑がボトルネックになることがあります。測定を繰り返すとリソースを消費することもあります。単一のテスト数値を追うより、通常の利用状況を観察するほうが有用です。

1つのアプリだけに問題がある場合は、まずアプリ固有のプロキシ設定、名前解決、接続キャッシュを確認します。すべてのアプリで同時に問題が起きる場合は、コアの状態、接続経路、上流ネットワークを調べてください。ルールモードだけで問題が起き、グローバルモードでは使える場合は、適用ルール、ポリシーグループ、関連するDNS経路を重点的に確認します。比較する際は他の条件を変えず、復旧操作を記録してください。「再起動したら直った」だけでは一時的な回復にすぎません。原因の特定を続けるため、再起動前のエラー情報を残しておきましょう。

復元手順と日常の記録

動作確認済みの基準設定を1つ保存し、ローカル変更の目的、場所、取り消し方法を記録しておくことをおすすめします。問題が起きたら必要なログを先にエクスポートし、直近の変更を元に戻してください。データフォルダーをすべて削除するのは避けましょう。クライアントを終了できること、システムプロキシを無効にできること、TUNのルートを復元できることを確認してから、基準設定に戻します。新しい設定でのみ問題が起きる場合は、設定を一つずつ統合して原因の項目を特定してください。更新を止めて古いサブスクリプション全体に依存し続けるのは避けましょう。

9. 応用編：設定の分割とコアの運用

接続できる状態から、結果を説明できる状態へ

応用を目指すからといって、最初にパラメーターを増やす必要はありません。まず1つの接続について説明できるようにします。使い慣れたアプリを選び、どのように接続するか、どのドメインにアクセスするか、どのルールが適用されるか、どのポリシーグループが選ばれるか、想定したDNS経路を使うかを記録してください。これらを再現して確認できるようになってから、ルールプロバイダー、複雑なポリシーグループ、独立したコアを導入しましょう。機能を増やすほど依存関係も増えます。確認手段がなければ、機能の追加によって問題が見えにくくなるだけです。

設定はリソースの取得元、共通ポリシー、端末固有の設定に分けられます。リモートリソースは継続的に更新する内容を管理し、共通ポリシーは複数端末で共有する振り分け要件を表し、ローカル層ではポート、パス、インターフェース、権限など端末固有の項目を扱います。この方法なら、移行時に実行設定全体をコピーする必要がなくなり、サブスクリプションの更新でローカル設定が上書きされるリスクも減らせます。具体的な実装では、クライアントが提供する統合方法に従ってください。一般的な階層化の考え方を、すべてのクライアントで上書き構文が共通であるという意味に取り違えないようにしましょう。

コアを直接実行する前の準備

サーバーやルーターではmihomoを直接実行できますが、設定ディレクトリ、プロセス、ログ、権限、起動順序を自分で管理する必要があります。GUIクライアントが代わりに行っていた機能は自動では引き継がれません。特にシステムプロキシ、サービス管理、リソースのダウンロード状態表示には注意が必要です。まず最小限の設定をフォアグラウンドで検証してから、システムサービスに登録してください。起動に失敗したときは標準出力と標準エラー出力を残します。バックグラウンドで静かに終了し、ポートに接続できない状態だけが残るのを避けましょう。

# 現在のコアが対応するパラメーターを確認
mihomo -h

# 現在のディレクトリで設定を確認し、問題がなければフォアグラウンドで起動
mihomo -t -d . -f config.yaml
mihomo -d . -f config.yaml

このコマンドは、実行ファイルがシステムの検索パスにあり、現在のディレクトリに設定と関連リソースが含まれていることを前提とします。-dで指定する作業ディレクトリは相対パスの解決に影響します。また、サービスの実行ユーザーとターミナルのユーザーが異なると、ファイルを読み込めない場合があります。設定の検査で見つかるのは一部の構文や参照の問題です。リモートリソースへの接続、ルートを変更する権限、実際のサービスへの接続成功までは確認できません。サービスとして起動する前に、リクエストを一通り検証し、停止方法と切り戻し手順も明確にしておきましょう。

LAN、制御インターフェース、ルーターへの導入

他の端末から本機のプロキシを使う場合は、待ち受けアドレス、LANからの接続許可、ファイアウォールの範囲をあわせて検討します。ポートを開放しただけでは設定完了ではなく、プロキシポートをインターネットに直接公開してもいけません。接続を信頼できるネットワークに限定し、必要なら認証を設定して、クライアントが対応する方法を確認してください。外部から操作する制御インターフェースには個別の保護が必要です。設定管理機能と通常のプロキシ接続口を混同しないでください。制御インターフェースから利用できる機能は、コアの説明に従って確認しましょう。

ルーターへの導入では、メインルーターかサブルーターかという役割、クライアントのゲートウェイ、DNSの割り当て、戻り経路も検討します。サブルーターでコアを動かしても、LAN内の端末が自動的に通信を渡すとは限りません。まず端末がどこからゲートウェイとDNSを取得しているかを確認し、次に透過的に通信を取り込む経路を検証してから、ルール分岐を設定します。家庭内ネットワークにDHCPサーバーが複数ある場合は、IPアドレスの割り当てが競合していないか先に確認してください。導入方法の概要はOpenWrtとサブルーターでmihomoを動かす方法をご覧ください。デスクトップ向けの設定をルーター用の完全な設定としてそのまま使わないでください。

継続運用で確認する項目

自動更新は定期的にダウンロードして上書きするだけでなく、設定の検査、正常な読み込み、失敗時の切り戻しまでを一連の手順として実装してください。リソースのダウンロードに失敗した場合は、動作確認済みのファイルを維持します。設定検査に失敗したら公開を止め、再読み込み後に重要なリクエストを確認します。ルールの変更履歴は残してください。ただし、認証情報を含むリソースを公開リポジトリに登録してはいけません。バージョン管理が必要なら、機密情報を削除したルールと上書き設定だけを記録し、機密情報は保護されたローカル設定から渡します。