Mihomo設定ガイド

1. 基本概念とクライアントの選び方

コア、インターフェース、サービスの違い

Mihomoは、設定の解析、ルールの照合、アウトバウンド接続の確立を担うプロキシコアです。Clash Metaは、そのエコシステムで広く使われてきた名称です。クライアントは、グラフィカルな操作画面、設定管理、システム連携を提供します。画面でシステムプロキシやプロキシグループを操作すると、最終的にコアの動作状態やシステム設定が変わります。そのため、画面上で起動中と表示されていても、確認できるのはプロセスの稼働だけです。サブスクリプションの有効性、出口の利用可否、すべてのアプリがプロキシ経由になっていることまでは証明できません。

通信の流れは、アプリ、トラフィックの入口、ルール、プロキシグループ、出口から成ります。アプリはシステムプロキシまたはTUNを通じてリクエストをコアに渡します。コアはモードに応じてルールを使うか判断し、該当ルールに従って接続を直接接続、拒否、またはプロキシグループへ渡します。プロキシグループが実際の出口を選択します。サブスクリプションには通常、出口のパラメーターや一部のルールが含まれますが、クライアント自体がネットワークサービスを提供するわけではありません。クライアントをダウンロード・インストールした後も、利用可能な設定の入手先を用意するか、必要なサービスを自分で構築・運用する必要があります。

プラットフォームに合ったインストール先を選ぶ

初めて選ぶ場合はClash Plusを候補にし、利用するプラットフォームや使い方に合わせて他のクライアントと比較しましょう。WindowsではClash Verge Rev、FlClash、Clash Nyanpasuも選べます。macOSではClash Verge RevとFlClash、AndroidではClash Meta for Android、FlClash、Surfboardを比較できます。Surfboardの設定形式はMihomoと完全には一致しないため、どちらもプロキシツールだからといって同じYAMLをそのまま読み込めるとは限りません。各プラットフォームのダウンロード先はダウンロードセンターにまとめています。

メンテナンス状況と機能の範囲

Clash for WindowsとClashX Metaはメンテナンスが終了しています。古い環境の確認や過去の設定からの移行には使えますが、古いガイドに載っているという理由だけで使い続けるのは避けましょう。Linuxデスクトップでは、まずClash Verge RevとFlClashを比較してください。サーバーやルーターでは、Mihomoコアを直接動かす方法もあります。ただし、プロセス、設定ディレクトリ、リッスンアドレス、ルーティングを自分で管理する必要があり、GUIクライアントのようにシステム連携をすべて自動で処理するわけではありません。

iOSでClash Plusを使う場合は、公式サイト clashplus.ioでアプリの情報を確認し、App Storeのページからインストールできます。同じ名前のクライアントでも、プラットフォームによって画面の項目やシステム機能は異なる場合があります。学習時はボタンの位置を機械的に探すのではなく、各設定が何をするのかを理解しましょう。

この段階を終えたら、次の3点を説明できるか確認してください。現在使っているクライアントは何か、接続を処理しているコアやネットワークコンポーネントは何か、設定の提供元と更新担当は誰か。さらに比較する際は、画面の見た目だけでなく、サブスクリプションの互換性、ルールの適用方法、ログの確認しやすさ、設定のバックアップ機能を確認しましょう。「このプロトコルに対応」と書かれていても、利用中のプラットフォームと実装が、サブスクリプションで使われている具体的なパラメーターに対応しているか確認が必要です。同じプロトコル名でも、拡張フィールドをすべて相互利用できるとは限りません。

2. インストール、権限、初期環境

インストール前にアーキテクチャと既存設定を確認

まずシステム情報でデバイスのアーキテクチャを確認し、対応するインストーラーを選びます。Windowsでは一般的なx64のほか、ARMデバイスもあります。macOSではApple SiliconとIntelを区別してください。Linuxではアーキテクチャだけでなく、ディストリビューションが対応するパッケージ形式も確認します。ファイルサイズから互換性を推測しないでください。インストーラーが起動しても、同梱のコアが現在のシステムで動くとは限りません。起動直後に終了する場合は、サブスクリプションをすぐ変更するのではなく、まずアーキテクチャとシステム要件を確認し、次にアプリのログを調べましょう。

他のプロキシクライアントをインストールしたことがある場合は、古いクライアントを終了し、システムプロキシが古いポートを参照したままになっていないか確認してください。ウィンドウを閉じてもバックグラウンドプロセスが終了するとは限りません。通知領域やメニューバーのアイコン、システムサービスが動作を続けている場合があります。初回の確認では、トラフィックを制御するクライアントを1つに絞り、複数のプログラムによるシステムプロキシの変更や、複数のTUNデバイスによるデフォルトルートの競合を避けましょう。古い設定はバックアップとして残せますが、状態が分からないまま同時に有効にしないでください。

デスクトップ環境での権限設定

Windowsでは通常の方法でインストールして起動し、まず基本画面が開くことを確認します。サービスのインストールや、昇格権限が必要なネットワーク機能を有効にする場合に限り、クライアントの指示に従って許可してください。システムプロキシの利用だけなら、アプリ全体を常に管理者として実行する必要は通常ありません。一方、TUNやサービスモードでは、特権を持つ補助コンポーネントが必要な場合があります。ポート競合が表示されたら、どのプロセスがリッスンしているかを調べ、片方のポートを変更したうえでシステムプロキシの接続先も更新してください。YAMLだけ変更してシステム側の古い接続先を残してはいけません。

macOSで初めて起動するときは、システムの案内を確認し、アプリの入手元と権限の用途を確かめてください。クライアントによっては補助サービスをインストールし、ネットワーク拡張機能を使う場合もあります。具体的な手順はアプリによって異なります。キーチェーンの確認画面とネットワーク拡張機能の許可は別のものです。前者は機密情報の保存に、後者はシステムネットワークの制御に使われる場合があります。ダイアログが表示されたら、要求元を確認してから判断し、すべての確認を一律に許可しないでください。詳しくはmacOSの権限とキーチェーンの解説をご覧ください。

LinuxのGUIクライアントがシステムプロキシを設定できるかどうかは、デスクトップ環境とアプリの実装によります。コマンドラインのプログラムがデスクトップのプロキシ設定を読み取るとも限りません。インストール後は、コアのプロセスが存在すること、設定の読み込みが成功していること、ローカルポートがリッスンしていることを確認してから、プロキシに対応したアプリでテストします。コアを直接実行する場合は、設定ディレクトリに適切な読み書き権限を設定してください。手間を省くためにディレクトリ全体をすべてのユーザーから書き込み可能にするのは避けましょう。サービスアカウント、作業ディレクトリ、相対パスの不一致があると、対話的な実行では動くのにバックグラウンド起動では失敗することがあります。

モバイル端末と最小限の起動設定

Androidで初めてVPN接続を確立するときは、システムから許可を求められます。これはトラフィックの入口が許可されたことを示すだけで、リモートの出口が利用可能であることを意味しません。通常のVPN接続を占有できるアプリは1つだけのため、企業VPNや他のネットワークツールが競合する場合があります。省電力設定によってクライアントが停止することもあります。切断が実際に発生する場合に限り、該当する制限を調整してください。iOSでもアプリの案内に従ってVPN設定を許可し、その後クライアントに戻って設定の読み込みエラーがないか確認します。

# ローカルの入口の例。プロキシの出口は含みません
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

上の例は基本的なパラメーターを理解するためのもので、プロキシサービスを提供する完全な設定ではありません。mixed-port はHTTPとSOCKSのリクエストを受け付けます。allow-lan: false はLANからのアクセスを制限する設定ですが、実際のリッスンアドレスとファイアウォールも確認し、公開範囲を判断してください。まずはこの端末内だけで使い、LAN共有は有効にしないでください。インストール完了の目安は、画面、コア、ローカルの入口が正常に動作し、クライアント終了後に元のネットワーク状態へ戻せることです。

3. サブスクリプションの読み込みと設定の管理

サブスクリプションURLと実際の設定を区別する

サブスクリプションURLは設定を取得するための入口で、ダウンロードした内容がコアによって解析される設定です。URLから完全なYAMLが返る場合も、プロキシの出口だけが返る場合も、別のクライアント向けの形式が返る場合もあります。読み込む前に、提供元が現在のクライアントとコアを明確にサポートしているか確認しましょう。ブラウザーでURLを開けても、レスポンスが有効な設定とは限りません。ログイン画面、残高の案内、アクセス制限ページが通常のWebページとして返されることもあります。

クライアントで設定またはサブスクリプションの管理画面を開き、リモート設定を追加します。提供元が分かる名前を付けてURLを貼り付け、ダウンロードを実行してください。完了したら、更新時刻、解析結果、プロキシグループが作成されたかを確認し、その設定を現在の設定として選択します。クライアントによっては「ダウンロード成功」と「有効化成功」が別の操作です。ファイルが保存されただけでは、コアが切り替わったとは限りません。現在の設定名と起動ログを照合し、無効なファイルを編集し続けないようにしましょう。

設定の提供元と役割を分ける

リモートサブスクリプションは通常、提供元が管理します。ダウンロードされたキャッシュを直接変更しても、次回の更新で上書きされる可能性があります。長期的に残すルール、DNS、入口の設定には、クライアントが提供するオーバーライド、マージ、拡張機能を使いましょう。機能名や適用順序はクライアントによって異なります。対象の項目を全置換するのか、元のリストの前後に追加するのか、まず確認してください。ルールリストの末尾に追加したルールがMATCHの後ろに入ると、構文が正しくても適用されない場合があります。

設定を提供元の層、個人用オーバーライドの層、実行時の状態の3つに分けると、トラブルを切り分けやすくなります。提供元の層ではサブスクリプションの取得内容、オーバーライドの層ではローカルでの追加・置換内容、実行時の状態では最終的にコアへ渡された内容を確認します。画面の表示とYAMLが一致しないときは、サブスクリプションの原文だけでなく、最終設定やログを確認してください。一部のクライアントは起動時にポートやコントロールインターフェースなどの項目を追加します。そのため、実行時の設定がリモートの元ファイルと異なっていても、必ずしも異常ではありません。

# 部分的な例：よく使われるトップレベル項目を2つ
mode: rule
log-level: info

# ルールが参照する PROXY は、完全な設定内で定義済みである必要があります
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

読み込みや更新の失敗に対処する

解析エラーが表示された場合は、まずエラーに示された項目名と行番号を記録します。YAMLではインデントにスペースを使い、タブを混ぜてはいけません。リスト項目の前のハイフン、コロンの後のスペース、文字列内の特殊文字も解析に影響します。エラー行は、解析器が問題を検出した位置にすぎないことがあります。実際の原因が前の行の引用符の不足やインデントの誤りである場合もあります。エラー付近を少しずつ確認し、ファイル全体を整形し直して最初の手がかりを失わないようにしましょう。

ダウンロードに失敗した場合は、ドメインの名前解決失敗、接続タイムアウト、証明書エラー、認証の失効、レスポンス内容の不一致を切り分けます。サブスクリプションのリクエストは、クライアント自身またはコアが送信する場合があり、ブラウザーと同じネットワーク経路を通るとは限りません。提供元が特定のリクエスト識別情報を必要としている場合に限り、User-Agentを変更してください。無作為に変更しても万能な解決策にはなりません。詳しい切り分け方法はサブスクリプションの解析失敗を確認するチェックリストを、初回の読み込み手順はサブスクリプションの読み込み手順をご覧ください。

更新前に、直近で正常に使えた設定をバックアップしてください。更新後は、プロキシグループの参照先が有効か確認します。提供元が出口名を変更すると、固定選択していた古いメンバーが無効になることがあります。クライアントに以前の選択が残っている場合は、プロキシグループを開き直して確認してください。更新操作が成功しただけで完了と判断せず、実際に接続し、どのルールが適用されたかを確認しましょう。サブスクリプションが頻繁に変わる場合は、個人用ルールから変更されやすい出口名を直接参照せず、安定したプロキシグループ名を参照するのがおすすめです。

4. プロキシモードとプロキシグループ

入口とアウトバウンドの判断を区別する

システムプロキシ、TUN、Ruleは同じ階層の設定ではありません。最初の2つはアプリの通信をどうコアに入れるかを決め、Ruleは通信がコアに入った後の振り分けを決めます。そのため、「Globalに切り替えてもプロキシを通らないアプリがある」という状況は起こり得ます。そのアプリがシステムプロキシを使わず、別の入口からも取り込まれていない可能性があります。トラブル時は、まず接続パネルに該当するリクエストがあるか探してください。接続がまったく表示されない場合は、出口やルール順ではなく、入口を確認します。

日常利用では、まずRuleモードを使うのが一般的です。Globalは短時間の比較・診断に適していますが、サブスクリプションの失効、入口の競合、DNSの問題を自動で解決するものではありません。Directにしてもクライアントが終了するわけではなく、入口からの通信の取り込みやコアによる名前解決が続く場合があります。プロキシ環境全体が原因か判断するには、クライアントを終了してシステム設定を戻したうえで確認してください。Directに切り替えるだけでは、TUNのルーティングやクライアントのDNS処理が引き続き関与していないか確認できません。

プロキシグループの参照関係を理解する

プロキシグループは、ルールと実際の出口の間にある中間層です。selectはメンバーを手動選択し、url-testはテスト結果に基づいてメンバーを選びます。fallbackは指定順に利用可能なメンバーを探し、load-balanceは設定された分散方式で接続を割り振ります。自動選択グループのテスト結果が示すのは、テスト先とテスト方法に対する結果だけです。特定のWebサイトが必ず使えることを示すものではなく、表示された値だけですべての用途における品質を判断することもできません。

# このグループを、既存の完全な設定の proxy-groups リストに追加
# DIRECT のみを選択肢とする構造例です。プロキシの出口は追加されません
proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選択

この例では、ルールからグループ名を参照し、そのグループが組み込みのDIRECTを参照しています。実際のサブスクリプションでは、定義済みの出口をメンバーに追加することも、別のプロキシグループを参照することもできますが、相互参照によるループは避けてください。通常、名前は大文字・小文字、スペース、記号を含めて正確に一致させる必要があります。グループ名を変更した場合は、rules内の参照と他のグループのメンバーも同時に変更してください。表示名だけ変えると参照先が見つからず、設定の読み込みに失敗することがあります。

1つのリクエストで選択結果を検証する

プロキシグループを切り替えると、新しい接続には通常、新しい選択が適用されます。ただし、すでに確立した長時間接続は、以前の出口を使い続ける場合があります。ブラウザーの接続プール、ダウンロード、メッセージアプリの接続などが該当します。検証時は関連するページやタスクを閉じてから新しいリクエストを送り、接続パネルで適用ルール、プロキシグループの経路、出口を確認してください。必要なら該当する接続だけを閉じます。毎回すべての接続を切断して他の作業に影響させる必要はありません。

画面には、全体用のプロキシグループとサブスクリプション独自のプロキシグループが同時に表示されることがあります。Ruleモードで実際に使われるのは、該当ルールが参照する接続先であり、最上部に表示されたグループとは限りません。出口を変更しても接続先の挙動がまったく変わらない場合は、クライアントが選択を保存しなかったと決めつけず、接続記録にあるプロキシグループの経路を順に確認しましょう。同じ名前を持つ別の設定に切り替えた場合は、グループのメンバーも確認してください。

この段階を終えたら、条件をそろえた比較テストを少なくとも1回行います。入口は変更せず、同じWebサイトをRuleとGlobalでそれぞれ試し、接続先を記録します。Globalでは接続できてRuleでは失敗する場合、ルールの適用結果とグループの選択を確認してください。両方失敗する場合は、出口や名前解決を先に検証します。この比較は長期的な設定を勧めるものではなく、問題の範囲を通信経路の一部分に絞るためのものです。用語はプロキシグループの解説もご覧ください。

5. ルールによる通信の振り分けと優先順位

最初に一致したルールで接続先が決まる

Mihomoの通常のルールは上から順に評価され、最初に一致したルールの接続先が使われます。優先順位を決めるのは、まず配置順です。ルールの種類名によって優先順位が自動的に上がるわけではありません。上にある広範なルールが先に一致すれば、ドメインを指定したルールが優先されるとは限りません。末尾のMATCHは、どのルールにも一致しない接続を処理します。ルールを書くときは、まず明確な例外を置き、次に対象範囲の広い分類、最後にデフォルトの出口を置き、接続パネルで実際に適用されたルールを確認しましょう。

DOMAINは完全一致するドメインを対象とし、DOMAIN-SUFFIXはドメインとそのサブドメインに一致します。DOMAIN-KEYWORDはキーワードで照合するため対象範囲が広く、意図しない接続にも一致しやすくなります。IPルールは接続先アドレスを対象とします。プロセスルールはプラットフォームの対応状況やプロセス識別条件に依存します。あるWebサイトのIPアドレスが分かっているからといって、単一のIPルールを固定してはいけません。CDN、IPアドレスの変更、共有ホスティングによって対象が不十分になったり、別のサービスに影響したりする可能性があります。

# 部分的なルール例。PROXY は定義済みのプロキシグループである必要があります
rules:
  - DOMAIN,router.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,geolocation-!cn,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ここでのexample.comは構文説明用の予約ドメインです。実際の用途に合わせて置き換えてください。no-resolveは、このIPルールのためにドメイン名の名前解決を開始しない設定です。すべてのDNSリクエストを無効にするものではありません。接続に対象アドレスがすでにある場合は、そのアドレスで照合されることがあります。GEOSITEとGEOIPはローカルのデータファイルを使うため、分類名が実在する必要があります。設定の読み込みに成功しても、構文とデータが使えることを確認できるだけで、分類内容が実際の用途に合っているとは限りません。

組み込み分類からルールセットへ移行する

手書きのルールが増えてきたら、rule-providersを使ってルールデータをメイン設定から分けられます。プロバイダーには取得元、保存先、更新間隔、コンテンツ形式を設定し、rulesからRULE-SETで参照します。domain、ipcidr、classicalでは内容の形式が異なるため、拡張子を変更するだけで相互に利用できるわけではありません。ルールセット内の項目には通常、最終的な接続先は含まれません。接続先はrulesの参照行で指定します。

# ローカルルールセットの例：相対パスはコアの作業ディレクトリを基準にします
rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,PROXY

# rules/local-domains.yaml として保存
payload:
  - '+.example.com'

ローカルファイルを使えば、リモートのダウンロードを同時に調べなくても、まず形式と照合結果を確認できます。正しく動くことを確かめてからリモートの取得元を検討し、更新方法と適用範囲を確認しましょう。リモートのルールセット更新に失敗しても、古いキャッシュが使われ続ける場合があります。キャッシュがなければ、読み込みに失敗することもあります。メイン設定の更新成功とルールセットの更新成功は別なので、それぞれのログを確認してください。用途が大きく重複するルールセットを無計画に重ねると、どのセットが結果を決めたのか分かりにくくなります。

根拠を確認して振り分けのずれを特定する

まずリクエストがコアに入っているかを確認し、対象のドメイン名とアドレス、適用されたルール、接続先のグループを順に記録します。接続にIPアドレスしか表示されない場合は、アプリ自身が名前解決しているか、DNSがコアを経由しているか、ドメインスニッフィングの条件を満たしているかを確認してください。スニッフィングでドメイン情報を補える場合はありますが、すべてのプロトコルから元のホスト名を復元できるわけではありません。ドメインルールが動かないときに、スニッフィングの有効化だけで解決しようとしないでください。ルールを追加する前に、コアが実際にどの情報を取得できているかを把握しましょう。

Webサイトによっては、ログイン、リソース、API、メディアのために複数のドメインへ接続します。トップページのドメインだけにルールを設定しても、一部しか直らない場合があります。具体的な操作を行い、失敗した接続を確認して必要な範囲だけ追加してください。対象範囲の広いキーワードで無関係な通信まで振り分けないようにしましょう。ルールの種類と優先順位はカスタムルールと優先順位を、分類を組み合わせる場合はGEOSITEとルールセットによる通信の振り分け設定をご覧ください。

6. DNS、Fake-IP、TUN

名前解決と接続は関連する別の経路

DNSはドメイン名をアドレスに変換し、プロキシはその後の接続を中継します。両者が同じ経路を通るとは限りません。ブラウザーが暗号化DNSを使う場合や、システムに古い結果がキャッシュされている場合、アプリが独自の名前解決機能を持つ場合もあります。そのため、Webサイトに接続できないからといって、すぐに出口の問題とは限りません。まずアドレスを取得できているか、次に接続がコアに入っているか、最後に実際のアウトバウンド経路を確認します。ネットワークを比較するときは、同じクライアント設定を使い、ネットワークと設定を同時に変更して原因が分からなくならないようにしましょう。

Fake-IPはドメイン名に仮想アドレスを割り当て、後続のトラフィックがコアに届いたときに元のドメインと対応付けます。この仮想アドレスはWebサイトの実際のアドレスではないため、位置情報の判定に使うことはできません。redir-hostは名前解決で取得した実アドレスを返します。実アドレスの動作が必要な特定の環境に適していますが、ルール判定ではドメインの対応付けと名前解決結果への依存が高まる場合があります。どちらかがすべてのアプリにとって常に優れているわけではありません。LAN、ゲーム、企業内ネットワークなど、実際の要件に合わせて検証してください。

# DNSの部分的な例。ローカルホストのみでリッスン
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - 'localhost'
  nameserver:
    - https://1.1.1.1/dns-query

上の例はローカルのDNSリッスン先を作るだけで、システムからそのポートへ自動的に問い合わせる設定ではありません。システムDNS、TUNによる傍受、クライアントの統合機能は別途接続する必要があります。例にあるアップストリームも実際のネットワークから到達できなければなりません。暗号化プロトコルであることだけで接続可能とは限りません。fake-ip-filterは指定ドメインに仮想アドレスを返さないための設定です。互換性の問題が実際にあるドメインだけを例外にしてください。対象を広げすぎると、従来の通信振り分けが変わり、トラブルの切り分けも難しくなります。

TUNの前提条件と制限

TUNは仮想ネットワークインターフェースでIPトラフィックを受け付けるため、システムプロキシに従わないプログラムにも適しています。有効にする前に、必要な権限、ドライバー、補助サービスが準備できているか確認し、他のVPNが動作中でないか調べてください。auto-routeは対応するルートを設定し、auto-detect-interfaceはアウトバウンドインターフェースの検出を試みます。複数のネットワークアダプター、テザリング、企業ネットワークでは、実際の設定結果を確認する必要があります。TUNは権限、出口プロトコルの制限、ファイアウォールを回避する万能なスイッチではありません。

# TUNの部分的な例。プラットフォームとDNS設定に合わせて使用
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns-hijackで一般的なDNSポートを対象にしても、アプリが独自に確立するすべての暗号化DNS接続を傍受できるわけではありません。システムプロキシとTUNを同時に有効にする必要があるとは限りません。クライアントの推奨に従って入口を選び、複数の入口を重ねて経路が分からなくならないようにしましょう。有効化したら、まず通常のWebサイトを試し、次に対象アプリとLANサービスをテストします。プリンター、共有フォルダー、企業内ネットワークに問題があれば、すべての通信を直接接続にするのではなく、ルートの除外やドメインの例外が必要か確認してください。

DNS漏れと社内ネットワークの競合を見分ける

DNS漏れは、想定する名前解決の経路を基準に判断します。どの問い合わせをどのリゾルバーが処理するべきか、その経路を通らないリクエストがあるかを確認してください。テストサイトにリゾルバー名が表示されても、それだけではすべての問い合わせがプロキシを通った、または通らなかったことの証明にはなりません。システムDNS、クライアントのログ、ブラウザーのセキュアDNS設定、必要に応じてネットワークキャプチャを照合し、個別のリクエストがどこへ送られたかを確認します。テスト時はIPv4とIPv6を区別し、片方のアドレスファミリーだけで結論を出さないでください。

企業内ネットワークで専用DNSを使っている場合、パブリックリゾルバーでは内部ドメインを解決できないことがあります。その場合は内部ドメインのサフィックスに応じた名前解決ルールを設定し、DNSアドレスへ正しいインターフェースから到達できるようにします。名前解決のリクエストがプロキシに依存する一方で、プロキシサーバーのドメインも同じ未確立の経路に依存すると、ループが起こることがあります。プロキシサーバーの名前解決には、独立して動作する経路を用意してください。Fake-IPの詳細な制約はFake-IPとredir-hostの違いをご覧ください。

7. 日常のメンテナンスとトラブル対処

復元できる設定の基準を作る

安定して使えるようになったら、クライアントの設定、個人用オーバーライド、ルールファイルを含むバックアップを保存します。サブスクリプションURLだけでは完全なバックアップになりません。リモートの内容は変わる可能性があり、ローカルのグループ選択や追加ルールがサブスクリプションに含まれないこともあります。バックアップは公開してもよいルールとアカウント認証情報を含む設定に分け、機密情報はアクセスを制限した場所に保存してください。使用中の入口、DNSモード、特別なルートを記録しておけば、画面のスクリーンショットだけより環境を復元しやすくなります。

更新は、クライアント、コア、サブスクリプション、ルールデータの項目に分けて行います。クライアントの更新では画面やシステム連携が変わることがあり、コアの更新では対応する設定項目が変わる可能性があります。サブスクリプションの更新は、主に出口と設定内容に影響します。一度に更新する項目を1つに絞り、基本的な動作を確認すれば、異常が起きたときに何を戻せばよいか分かります。作業を中断されたときに全コンポーネントを同時に更新し、その後「更新したら使えなくなった」という情報だけで復元しようとしないでください。それでは互換性の問題とサービス側の変更を区別できません。

通信できないときは経路に沿って調べる

まず影響範囲を確認します。すべてのアプリか、特定のプログラムか、Webサイトの一部機能だけかを切り分けてください。次に、クライアントを経由しない場合にネットワークが正常か確認します。基本のネットワークも使えない場合は、Wi-Fi、モバイル回線、認証ポータル、システムのネットワーク状態を先に確認してください。クライアントの動作中は、コアの起動、現在の設定、ポートのリッスン状態を確認します。対象のリクエストが接続一覧に現れない場合は、出口を変更するのではなく、システムプロキシ、アプリのプロキシ設定、TUNを優先して調べましょう。

リクエストがコアに入っている場合は、名前解決の結果、適用ルール、最終的な出口を確認します。複数のサイトで同じ出口が失敗するなら、サービスの稼働状況、認証パラメーター、リモートへの接続性を調べてください。特定のサイトだけ失敗する場合は、ルール、サイトが依存するドメイン、プロトコルの違いを確認します。HTTPエラー応答が返っているなら、アプリケーション層の応答を受け取れています。「ネットワークがまったくつながらない」と単純に分類しないでください。証明書エラーが出た場合も、証明書の検証を無効にして原因を隠すのではなく、システム時刻、接続先ドメイン、中間機器を確認しましょう。

# ローカルのHTTPプロキシ入口を検証。ポートは実際の設定に合わせる
curl -I --proxy http://127.0.0.1:7890 https://example.com

# SOCKS入口を検証し、ドメイン名の解決はプロキシ側で行う
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

これらのコマンドで確認できるのは、指定した入口とサイトだけです。すべてのプログラムがプロキシを経由することを示すものではありません。PowerShellでコマンドのエイリアスに違いがある場合は、curl.exeを使ってください。socks5hと一般的なSOCKSアドレスの書き方では、ドメインを解決する場所が異なります。比較時は使用した形式を記録しましょう。2つのコマンドの成否だけでなく、ログで適用されたルールも確認してください。一方が直接接続、もう一方がプロキシ経由なのに、同じ条件のテストだと誤認しないようにしましょう。

ログ、キャッシュ、終了後の復元

日常のログレベルにはinfoなど適切な値を使い、詳しい調査が必要な間だけ詳細レベルに上げます。ログを大量に長時間保存するより、失敗した操作の時刻、接続先、エラー内容を記録するほうが有効です。ログを共有する前に、サブスクリプションURL、認証情報、内部ホスト名、業務情報が分かる可能性のあるリクエストパスを削除してください。詳細ログはリソースを多く使う場合もあります。調査が終わったら元のレベルに戻し、不要な接続情報を長期間保存しないようにしましょう。

DNSやモードを変更しても、既存のキャッシュや長時間接続によって結果がすぐに変わらないことがあります。まず関連する接続を閉じ、必要に応じてシステムやアプリのキャッシュを更新してください。クライアントのディレクトリ全体を削除する必要はありません。クライアント終了後も接続できない場合は、システムプロキシが停止中のローカルポートを参照したままになっていないか、TUNのルートが元に戻ったか、DNSが利用できないアドレスを参照していないか確認します。簡単な確認方法はシステムプロキシの設定と接続の確認をご覧ください。

8. 応用設定と検証の進め方

まずモジュール化し、その後に自動化する

応用設定とは、すべての機能を有効にすることではありません。設定の各部分について、入力、出力、失敗時の挙動を説明できることが重要です。安定して使える設定ができたら、個人用ルールをサブスクリプションから分離し、次に大きなルール一覧を独立したプロバイダーにまとめ、最後に出口プロバイダーや自動選択のプロキシグループを検討します。モジュールを分けるたびに、パス、名前の参照、読み込み順序を確認してください。モジュール化の目的は変更箇所を絞ることであり、単純な設定を追跡しにくい多層参照にすることではありません。

proxy-providersとrule-providersは、それぞれ異なる問題を解決します。前者はプロキシの出口一覧を、後者は照合条件の一覧を提供します。通常、前者はプロキシグループから、後者はrulesから参照します。クライアント用の完全なサブスクリプションを確認せず、そのまま出口プロバイダーのファイルとして使わないでください。proxiesを含んでいても、クライアントに必要な他のセクションを含む場合があり、実際の解析方法を確認する必要があります。提供元が不明なリモートファイルは、まずローカルで構造を確認してから自動更新に組み込みましょう。

プロキシのテストマトリクスを作成する

1つのよく使うWebサイトだけでなく、異なる種類の接続をテストします。ローカルゲートウェイ、LAN内のサービス、直接接続が必要なサイト、プロキシが必要なサイト、対象の業務アプリを用意し、想定する入口、ルール、出口をそれぞれ記録してください。IPv6を使う場合はアドレスファミリーの選択も確認します。UDPを使う場合は入口とリモート側の両方が対応しているか確認してください。Webページが開けても、確認できたのはTCP接続の一部だけです。音声、ゲーム、その他のUDP通信も正常とは限りません。

テストでは、同じページを再度開く、音声接続を作り直す、決まったLAN内サービスにアクセスするといった、繰り返し実行できる操作を使いましょう。設定を変える前に期待する結果を書いておけば、「速くなった気がする」「たまに成功する」といった印象を、正しい設定だと誤認しにくくなります。自動選択グループでは、テスト失敗時の動作、メンバー更新後の参照、ネットワーク切り替え後の復旧も確認します。画面に正常と表示されるだけでなく、自動化が実際の要件に合っているかを確かめてください。

コマンドラインでのコア実行とコントロールインターフェース

GUIを使わずにコアを実行する場合は、まず作業ディレクトリと設定ファイルのパスを把握します。相対パスは通常、作業ディレクトリを基準とし、ルールファイル、キャッシュ、データファイルにも影響する場合があります。サーバーに設定をコピーしても、ローカルのプロバイダーファイルをコピーし忘れることは、よくある移行の失敗です。まずフォアグラウンドで設定とログを確認してから、サービスとして管理する方法を設定します。サービスの起動アカウントは、対話ログイン中のアカウントと権限が異なる場合があります。ディレクトリの読み書き権限とネットワーク機能をそれぞれ確認してください。

# mihomo をインストール済みの環境で設定を検証
mihomo -t -d ./mihomo-work -f ./mihomo-work/config.yaml

# 検証に成功したらフォアグラウンドで実行
mihomo -d ./mihomo-work -f ./mihomo-work/config.yaml

設定の検証では、構文や一部の参照エラーを見つけられますが、サブスクリプションURL、DNSのアップストリーム、すべての出口に実行時も接続できることまでは証明できません。フォアグラウンドでテストを終えたら、同じパラメーターを使用中のシステムのサービス設定に反映します。外部コントロールインターフェースを有効にする場合は、リッスン範囲を制限し、アクセス保護を設定してください。リモートパネルの利便性のために、パブリックネットワークへ直接公開しないでください。インターフェースの権限で実行時の状態を変更できる場合、そのリスクは通常の読み取り専用Webページとは異なります。

トラブルの調査結果を変更記録に残す

変更するたびに、理由、対象フィールド、検証内容、元に戻す手順を記録します。複雑な設定でも、入口が明確で、プロキシグループが少なく、ルールのパスが分かりやすい、最小限で動作する基準設定を残してください。異常が発生した場合は、新しい機能を一つずつ外して基準設定と比較します。出所の分からない設定をネット上から次々に追加しないでください。設定形式に疑問があればサブスクリプションと設定形式を、初回の操作を確認したい場合はクイックスタートガイドをご覧ください。

このガイドのゴールは、すべての設定項目を暗記することではありません。アプリの入口、ドメインの名前解決、ルールの適用、プロキシグループの選択、実際の出口という流れに沿って、1つの接続を説明できることです。次は、独立したルールセット、ドメインごとのリゾルバー指定、サーバープロセスの管理など、現在の用途に必要な機能だけを学びましょう。設定を読みやすく保ち、結果を検証でき、変更を元に戻せる状態にしておくことが、パラメーターを増やし続けるより長期的な運用に役立ちます。