Clash完全ガイド

ステップ01 / 基本を理解する

基本概念：クライアント、コア、通信経路

画面と実際に通信を中継するプログラムを区別する

Clashのエコシステムでは、クライアントは通常、ウィンドウやトレイメニュー、設定管理機能を備えたアプリを指します。コアは設定を読み込み、プロキシ接続を確立し、ルールを照合してDNSを処理します。mihomoは、このエコシステムで継続的に開発されているコアです。クライアント画面のスイッチがコアの全機能を表すとは限らず、同じコアでもクライアントによって項目名が異なる場合があります。チュートリアルの画面と違うときは、同じ場所を探すのではなく、設定の意味を確認しましょう。

通信をいくつかの段階に分けて考えましょう。アプリがリクエストを発生させ、システムやアプリの設定によってローカルプロキシへ渡されるかが決まり、コアが現在のモードに応じて経路を選び、プロキシポリシーが実際の出口を決定します。サブスクリプションは設定やノード情報を提供するもので、これらの段階を置き換えるものではありません。読み込み成功はクライアントが設定を受け付けたこと、プロキシ有効化は入口が設定されたことを示すだけです。Webページが表示されて初めて、関連する通信経路が概ね確立したと判断できます。これら3つの状態は互いに代用できません。

ノード、プロキシグループ、ルールを区別する

ノードにはサーバーアドレス、プロトコル、認証情報が含まれ、リモートサービスへの接続方法を示します。プロキシグループはノードや別のグループをまとめ、手動選択、自動チェック、フェイルオーバーなどの動作を提供します。ルールは、接続をどのグループに渡すかを決めます。手動グループでノードを選んでも、すべての接続がそのノードを使うわけではありません。そのグループに振り分けられた通信だけが選択の影響を受けます。トラブル対処では、適用されたルールと最終的な出口の両方を確認してください。

完全な設定には通常、ローカルの待受ポート、プロキシノード、プロキシグループ、ルール、DNSなどが含まれます。一方、ノードリストにはサーバー情報しか含まれていない場合があります。どちらもリンクから取得できることがありますが、同じものとして扱わないでください。クライアントが特定形式のノードリストを読み込めても、期待どおりのルール分岐が自動で補われるとは限りません。サブスクリプション形式を選ぶ前に、提供元が完全なClash設定を配布しているのか、整理が必要なノード一覧を配布しているのか確認しましょう。

ローカルプロキシとリモートサービスを分けて考える

ローカルの混合ポートは、アプリとコアが通信をやり取りする入口であり、リモートサーバーのポートではありません。例として mixed-port: 7890 がよく使われますが、実際の値は現在の設定とクライアントの設定によって決まります。チュートリアルにこの数字が載っているからといって、使用中のポートをそのまま上書きしないでください。リモートサービスの利用には、アカウントの状態、プロトコルへの対応、ネットワーク到達性も必要です。ローカルのプログラムが正常に動いていても、リモート側の正常性は保証されません。

システムプロキシは、システムのプロキシ設定を参照するアプリに主に影響します。TUNは仮想ネットワークインターフェースを介して、ルーティング条件に合う通信を取り込みます。どちらもルールモードの代わりではなく、通信をコアに渡す異なる入口です。入口とルール分岐は別々の観点として考えましょう。まずリクエストがコアに入っているかを確認し、次に入った後の経路を確認します。この順序なら、入口の問題をルールの誤りと取り違えにくく、不要なDNS変更も避けられます。

操作を始める前に、OS、クライアント名、設定の入手元、変更したい通信動作を記録しましょう。たとえば「ブラウザーにはプロキシを使い、LAN内の機器は直接接続する」と決めれば、「すべての機能を有効にする」よりも検証しやすくなります。プロキシソフトは匿名化ツールではありません。リモートサービス、接続先のWebサイト、ローカルアプリは、それぞれ関連データを処理します。信頼できる設定だけを読み込み、利用地域の法令やネットワーク管理規則に従ってください。不要な機器にネットワークの入口を公開しないようにしましょう。

ステップ02 / ツールを選ぶ

クライアント選び：OSを確認してから設定との互換性を確認

まず現在のデバイスでの使い方を確認する

新しく導入する場合はClash Plusから試し、ダウンロードページで利用するOS向けの項目を選んでください。OSのアーキテクチャ、対応バージョン、サブスクリプション形式、必要な権限も確認し、ソフト名だけで判断しないようにしましょう。デスクトップクライアントは設定管理や接続確認に向いています。モバイル端末では、OSが提供するネットワーク拡張機能やVPNインターフェースへの依存度が高くなります。サーバーやルーターで常時稼働させる場合は、コアを直接導入する方法もありますが、サービスと設定の管理は自分で行う必要があります。

Windowsでは、Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuを順に検討できます。Clash for Windowsはメンテナンスが終了したアーカイブ版です。Clash for Windowsの代替を探す場合は、まず既存のサブスクリプション元とカスタムルールを保存し、新しいクライアントが同等の設定に対応しているか確認しましょう。以前のソフトのフォルダー構成や画面設定をそのまま移せるとは限りません。移行ではアプリのデータを丸ごとコピーするのではなく、設定内容を引き継ぐことが重要です。

macOSではClash Plus、Clash Verge Rev、FlClashを選べます。ClashX Metaはメンテナンスが終了したアーカイブ版です。Apple Silicon用とIntel用のインストーラーを区別し、システム情報でチップの種類を確認してください。クライアントを切り替える際は、古いアプリがログイン時に起動する設定のままになっていないかも確認しましょう。複数のトレイアプリがシステムプロキシを繰り返し変更するのを防げます。システム設定を一貫させ、終了後の復元動作を確認しやすくするため、プロキシの管理元は1つに絞りましょう。

モバイル版とLinux版の違いを理解する

AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardを検討できます。SurfboardはClash YAMLとは異なる設定形式を使うため、あらゆるサブスクリプションリンクを読み込めるわけではありません。選ぶ前に、提供元の形式説明を確認してください。システムにVPNアイコンが表示されても、ローカルのネットワークインターフェースが作られたことを示すにすぎません。通信が想定したプロキシ出口まで届いているかは、そのアイコンだけで判断せず、アプリの通信結果も確認しましょう。

iOSでは、まずClash Plusのストア掲載ページを確認し、公式サイト clashplus.ioで製品情報を確認してください。OSのネットワーク拡張、バックグラウンド動作、アプリのサンドボックスが設定手順に影響するため、デスクトップ版のサービス導入手順をそのまま使うことはできません。Linuxのデスクトップ環境ではClash Verge Revを優先的に検討し、次にFlClashを確認しましょう。ディストリビューションに合うパッケージ形式を選び、システムプロキシ設定とシステム全体のルーティング制御を区別してください。

実際に必要な機能で選ぶ

設定に新しいプロトコル、ルールプロバイダー、DNSパラメーターが含まれる場合は、クライアントに搭載されたコアが該当フィールドを読み取れるか確認しましょう。名前にClashが含まれていても、すべての拡張構文に対応しているとは限りません。読み込み時に「未対応のフィールド」と表示されたら、コアのドキュメントと現在の設定形式を照合してください。内容をよく確認せずに一括削除するのは避けましょう。パラメーターを削除すれば読み込みエラーは解消するかもしれませんが、元のセキュリティ設定や通信の振り分けまで変わる可能性があります。

多くの新規ユーザーにとっては、設定を簡単に読み込めること、エラー表示がわかりやすいこと、システムプロキシを元に戻せることが、スイッチの数より重要です。アプリごとのルール分岐を調べるなら、接続の詳細、適用ルール、プロセス識別機能を重視しましょう。ノートPCやスマートフォンでは、スリープからの復帰、ネットワーク切り替え、バックグラウンド動作もテストに含めてください。実際のニーズを整理してから候補を1つインストールし、動作を確認しましょう。画面を比較するためにすべてのクライアントを一度に入れる必要はありません。

クライアントを決めたら、現在使えるインストーラーとエクスポートしたカスタム設定を保存し、サブスクリプションの更新方法を記録してください。移行時は、まず新しいアプリで設定が正しく読み込まれることを確認し、次に古いアプリの通信入口を無効にしてから、新しいアプリの入口を有効にします。この順序なら通信断を減らし、ポート競合を新しいソフトの不具合と取り違えにくくなります。パッケージ形式、OS別のダウンロード先、メンテナンス状況は、ダウンロードページの最新情報を確認してください。過去のスクリーンショットから推測しないようにしましょう。

ステップ03 / 実行環境を整える

インストールと権限：コアの起動とポートの使用状況を確認

まず通常起動を確認し、高度な権限は後から設定する

OSのアーキテクチャに合ったインストーラーをダウンロードし、同種のクライアントが起動中なら終了してから、システムの案内に従ってインストールしてください。初回起動ではTUN、LANアクセス、自動起動などを有効にせず、画面が開くこと、コアが動作すること、設定画面にアクセスできることを確認します。インストール、設定の読み込み、システムの通信制御を別々に進めれば、問題が起きた際にどの層で変化したかを特定しやすくなります。複数の設定を同時に有効にして手当たり次第に試すのは避けましょう。

Windowsでは、GUIとバックグラウンドサービスが別々に動作することがあります。TUNや一部のシステム操作には、クライアントのサービスモードや管理者権限が必要です。ただし、そのために通常の画面を常に最高権限で実行する必要はありません。サービスのインストールに失敗したら、まずアプリのログとシステムの表示を確認し、セキュリティソフトが操作を妨げていないか調べましょう。出所不明の修復スクリプトはダウンロードせず、インストールを通すためにシステム保護全体を無効にしないでください。

macOSでは、アプリを長期利用に適した場所に置いてから起動し、提供元の確認やネットワーク関連の権限をシステムの案内に従って設定してください。システムプロキシの変更にはネットワークサービスの設定が必要です。TUNには追加の権限が必要な場合があり、詳細はクライアントの実装によって異なります。起動できない場合は、アプリの入手元、チップのアーキテクチャ、OSの対応範囲を確認しましょう。Webで見つけた権限回避コマンドをそのまま実行するのは避けてください。権限の設定場所はOSのバージョンによって異なる場合があります。

モバイルの権限とLinuxのサービスを確認する

Androidでは初回接続時にVPN接続の許可を求められることが一般的です。使用中のクライアントからの要求であることを確認してから許可してください。システムのVPN機能を使う別のアプリがすでに動作している場合、両方で同時に通信を制御できないことがあります。どちらを使うか先に決めましょう。iOSでも、システムの案内に沿って関連するネットワーク設定を許可してください。許可後はクライアントに戻り、実行状態を確認します。システムの確認ダイアログが表示された時点で、サブスクリプションや通信先まで準備できたと判断しないでください。

Linuxでは、GUIアプリが起動しても、デスクトップのプロキシ設定を変更したり仮想インターフェースを作成したりできるとは限りません。使用するクライアントの説明に沿ってサービス権限を設定し、インストール先全体への過剰な書き込み権限付与は避けましょう。コアを直接導入する場合は、サービス用アカウント、設定ディレクトリ、作業ディレクトリ、ログの所有者を明確にしてください。ダウンロードしたパッケージを長期運用の作業ディレクトリにしないでください。ダウンロードファイルを整理する際に、参照中のルールや設定まで削除してしまう可能性があります。

混合ポートを確認し、数字を何度も変更しない

起動ログにアドレスの競合が表示されたら、まず使用中のプロセスを特定してください。終了していない古いクライアント、同じアプリの別インスタンス、無関係なサービスが原因かもしれません。特定したら、必要なインスタンスだけを残すか、現在のクライアントに未使用ポートを割り当てます。ポートを変えた場合は、ブラウザー拡張、コマンドラインの環境変数、手動プロキシ設定も合わせて変更してください。コア側だけ変更すると、アプリが古い入口へ接続し続けることになります。

# Windows PowerShell：ポートのリッスン状態を確認する例
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux：ポートのリッスン状態を確認する例
ss -ltnp 'sport = :7890'

# macOS：ポートのリッスン状態を確認する例
lsof -nP -iTCP:7890 -sTCP:LISTEN

これらのコマンドで確認できるのはローカルの待受状態です。プロセス情報の一部は、追加の権限がないと表示されない場合があります。待受記録が見つかったら、プロセス名とクライアントのログを照らし合わせて所有元を特定してください。見慣れないシステムプロセスをすぐ終了しないようにしましょう。待受記録がなくても、インストールの破損とは限りません。有効な設定を待っている場合や、別のポートを使っている場合もあります。設定画面とログの現在値を確認してから、実行環境を変更するか判断してください。

最後に、終了後の復元を確認します。短時間の通信中断が許容できるときにクライアントを終了し、システムプロキシが正しく解除されるか確認してから、アプリを再起動してください。終了後にブラウザーへ接続できず、システムがローカルプロキシのポートを指したままなら、入口が復元されていません。まずシステムのネットワーク設定から残ったプロキシを無効にし、その後クライアントの終了処理を調べましょう。設定を完成させる前に一度このテストを行えば、後になって正常な終了後の問題をネットワーク障害と取り違えずに済みます。

ステップ04 / 有効な設定を用意する

サブスクリプションと設定：読み込み、有効化、ローカル変更の保持

読み込み前に入力形式を確認する

クライアントの設定画面またはサブスクリプション画面を開き、URLから読み込む項目を選択して、信頼できる提供元から取得した完全なリンクを貼り付けます。ダウンロードを実行する前に、前後の空白や改行、チャットアプリが追加した句読点が含まれていないか確認してください。サブスクリプションURLにはアカウントの認証情報が含まれる場合があります。公開掲示板に投稿したり、信頼できないオンライン変換サイトに貼り付けたりしないでください。スクリーンショットを撮る際はURL全体を隠し、特にドメインの後ろにある機密パラメーターも見えないようにしましょう。

ローカルファイルを読み込む場合は、有効なYAML設定を選び、Webページを保存したものではないこと、OSによってテキスト拡張子が追加されていないことを確認してください。完全な設定、Base64形式のノード一覧、単一の共有リンクはそれぞれ構造が異なります。読み込みできるかどうかはインポーターの機能によります。形式の違いを確認するには、サブスクリプションURL・ローカルYAML・Base64形式の解説を参照してください。拡張子を何度も変えて互換性を試すのは避けましょう。

ダウンロードが終わったら、設定一覧から対象の設定を選んで有効にします。クライアントによっては複数のサブスクリプションを保存できますが、コアが実際に読み込むのは、現在選択されている設定またはその結合結果だけです。画面上の選択中マークを確認し、プロキシ画面に想定したプロキシグループが表示されるか見てください。設定名が表示されていても、設定が保存されたことしかわかりません。コアが読み込みエラーを報告する場合は、ログからフィールド、インデント、参照名の問題を特定してください。

YAMLの構造とプロキシの参照関係を理解する

YAMLではスペースで階層を表すため、タブを混在させないでください。配列の項目は通常ハイフンで始まり、フィールド名と値は文法に合った区切り方で記述します。特殊文字を含む文字列は引用符で囲めますが、開始と終了が対になっているか確認しましょう。エラー対処では、まずログに示された位置とその前後数行を確認してください。原因は直前の行で記号が抜けていることもよくあります。設定全体を公開サービスに貼り付けないでください。ノードのパスワードや認証情報が、深い階層に含まれている場合もあります。

# 最小限の直接接続サンプル：階層の理解用。リモートプロキシノードは含みません
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選択

この例では構造を確認できますが、すべての接続が最終的に直接接続されます。リモートサービスへの接続を想定したサブスクリプションの代わりには使わないでください。ルールで指定するポリシー名は設定内に存在し、表記と大文字・小文字が一致している必要があります。日常的な変更には、クライアントが提供する上書き、マージ、拡張の仕組みを利用しましょう。項目名はアプリによって異なります。ダウンロードされた設定を直接編集すると、次回のサブスクリプション更新で変更が上書きされ、「設定が勝手に消えた」ように見えることがあります。

更新スケジュールを設定し、失敗時の対処を決める

自動更新の間隔はメンテナンス用の設定であり、接続速度を調整するものではありません。画面によって分単位だったり秒単位だったりするため、入力前に単位を確認しましょう。単位が分と明記された画面なら、1440は1日に相当します。この値を秒単位で指定するプロバイダーのフィールドにそのままコピーしてはいけません。サービスへのリクエストが絶えないよう、極端に短い間隔も避けてください。頻繁に更新しても形式の不一致は直らず、提供元のリクエスト制限にかかる可能性もあります。

更新に失敗したら、ネットワークのタイムアウト、認証エラー、Webページの返却、設定の解析エラーを切り分けます。タイムアウトでは接続経路を確認し、認証エラーではアカウントとサブスクリプションURLを確認してください。Webページが返る場合は、ログインページやエラーページの可能性があります。解析エラーなら形式とコアの対応範囲を確認しましょう。「プロキシ経由で更新」は、現在のプロキシが使える場合にのみ役立ちます。設定がすでに無効なら、一時的に直接接続で取得するか、提供元が対応する別の更新方法を試す必要があります。

更新に成功したら、現在の設定が引き続き有効か確認し、プロキシグループの選択が想定どおり保持されているかテストしてください。公開しない形で使用可能な設定を1つバックアップし、カスタムルールも別に保存しましょう。エラー対処の詳細は、サブスクリプション更新エラーと自動更新間隔の設定を参照してください。サブスクリプションを何度も削除して作り直すより、まず接続を復旧し、その後で原因を整理するほうが手がかりを残しやすくなります。

ステップ05 / 通信の入口を確認する

プロキシモード：システムプロキシ、ルール、グローバルを区別する

まずリクエストをコアに渡す方法を決める

設定を読み込んだら、まず使用可能なプロキシを選び、システムプロキシを有効にして、通常のブラウザーから新しいリクエストを送信します。接続一覧を開き、該当するドメインと適用されたポリシーが表示されるか確認してください。ページが開かず接続記録もない場合は、ルールを変更する前に、システムプロキシとブラウザー独自のプロキシ設定を確認しましょう。ブラウザー拡張、アプリ独自のプロキシ、システム設定が互いに上書きし合うことがあるため、現在のリクエストがどの入口を使っているか特定してください。

システムプロキシは、対応アプリをローカルのアドレスとポートに接続させますが、すべてのプログラムがその設定に従うとは限りません。コマンドラインツール、ゲーム、バックグラウンドサービス、一部のストアアプリは独自のネットワークスタックを使うことがあります。WindowsのUWPアプリではループバックアクセスの制限が関係する場合があり、関連するエラーすべてをサブスクリプションの問題と判断することはできません。必要に応じてクライアントのループバック設定やシステムの説明を確認し、実際に必要なアプリだけを調整してください。すべてのアプリの権限をまとめて緩和しないようにしましょう。

用途に応じてルール、グローバル、直接接続を選ぶ

ルールモードでは、設定内の条件に従って接続を振り分けます。日常的な通信の振り分けに適しています。グローバルモードでは通常、コアに入った接続をグローバルポリシーに渡し、直接接続モードではコアに入った接続を宛先へ直接送ります。ここでの「グローバル」は、システムのすべての通信が制御されるという意味ではありません。コアに入っていないリクエストは、グローバルモードを選んでも経路が変わりません。まず入口を確認してからモードを選ぶことが、このガイドで重要なトラブル対処の順序の1つです。

グローバルモードは短時間の比較テストに適しています。ルールモードで失敗し、グローバルモードでは成功する場合、ルールや関連ポリシーを確認する価値があります。ただし、出口の変更によってDNSや接続の再利用に差が出ている可能性もあるため、特定のルールだけが原因とは限りません。テスト後は元のモードに戻し、既存の接続を閉じるか、テスト対象のアプリを再起動して、新しい設定でリクエストが作られるようにしましょう。古いセッションが判断を妨げるのを防げます。

明示的なプロキシ接続で比較する

ローカルの混合ポートが実際に7890の場合は、次のコマンドでプロキシを明示的に指定できます。宛先は接続を確認するための公開サンプルサイトです。Windows PowerShellでは curl.exe を使うと、環境によって異なる同名コマンドのエイリアスを回避できます。ポートが異なる場合は現在の値に置き換えてください。コマンドが成功しても、そのリクエスト経路が使用可能だとわかるだけです。すべてのアプリや接続先が正常とは限りません。

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

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

明示的なプロキシではアクセスできるのにブラウザーで失敗する場合は、ブラウザー拡張、独自のプロキシ設定、キャッシュされた接続を確認してください。どちらも失敗し、ログにリクエストがある場合は、ポリシーの選択、ノードの状態、接続先側の制限を調べます。ログにリクエストがなければ、ポート、コアの動作状態、コマンドの実行状況をもう一度確認しましょう。ブラウザーの汎用エラーページだけで判断しないでください。同じメッセージが、名前解決の失敗、接続拒否、リモート側からの切断で表示されることがあります。

コマンドラインの環境変数に、以前のプロキシ設定が残っている場合もあります。トラブル対処では、現在のターミナルに HTTP_PROXY、HTTPS_PROXY、ALL_PROXY が設定されているか、アプリがこれらの変数を参照するか確認しましょう。変数を変更しても、通常は新しく起動したプロセスにしか反映されません。すでに動作中のプログラムには以前の値が残る場合があります。1つのターミナルでプロキシを使うために、すべてのセッションを一括変更しないでください。まず単一のターミナルで確認し、必要なら永続化を検討しましょう。

この章を終えたら、どのアプリがシステムプロキシを使うのか、どのアプリに個別設定が必要か、現在のモードがどこまで影響するのか説明できるはずです。「接続済みなのにページを開けない」場合は、システムプロキシ・ポート競合・ルールのトラブル対処チェックリストを順に確認してください。一度に変更する項目は1つにし、変更前後の結果を記録しましょう。モード、ノード、DNSを同時に切り替えると、比較の根拠を失うおそれがあります。

ステップ06 / 通信経路を制御する

ルール分岐：順に照合し、実際の適用結果を確認する

条件を書く前に、ルールの順序を理解する

ルールは通常、上から順に照合され、最初に条件に一致したルールが適用ポリシーを決めます。最後にフォールバック用のルールが残りの通信を処理します。条件が具体的であるだけで自動的に優先されるわけではなく、配置順も重要です。対象範囲の広い条件を前に置くと、その下の細かい条件が適用されないことがあります。変更前に、どのドメインを直接接続し、どれをどのプロキシグループに渡し、一致しない場合はどう処理するのかを明確にしましょう。

ドメインルールとIPルールでは照合対象が異なります。DOMAIN は指定したドメインに一致し、DOMAIN-SUFFIX はドメインのサフィックスを対象にします。IP-CIDR はIPアドレスの範囲を対象にし、GEOIP は地理データベースを利用します。ドメインサフィックスルールは、任意の文字列を含むかどうかの判定とは異なります。また、サイトに関連するすべての個別リソースのドメインを自動で処理するわけではありません。1つのページがログイン、画像、APIなど異なるホストへ接続する場合もあります。実際の接続記録をもとに確認してください。

まず理解しやすい最小限のルールから始める

次の例はよくあるルールの順序を示しています。既存の完全な設定に追加して使い、PROXY はあらかじめ定義されたポリシーまたはプロキシグループに置き換えてください。この例では、ドメインサフィックスをプロキシに渡し、プライベートネットワークは直接接続にし、中国本土のIPアドレスにも直接接続ルールを適用した後、残りをプロキシへ送ります。学習用の分岐例であり、あらゆるネットワーク環境にそのまま適用できるとは限りません。特にLANのルーティングやサービス提供元の案内に合わせて調整してください。

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

no-resolve は、このIPルールとの照合のためにドメインの名前解決を新たに開始するのを防ぐオプションです。設定全体のDNSを無効にするものでも、宛先にIPアドレスが割り当てられなくなるものでもありません。接続に利用可能なアドレスがすでにある場合は、引き続きアドレスとの照合が行われることがあります。使用するかどうかは、ドメインリクエストや名前解決の負荷をどう扱うかに応じて判断してください。地理データベースを使う場合は、利用可能なデータソースが必要です。データベースが存在しない、または古い場合、関連ルールの動作が想定と異なることがあります。

LANアクセスとサービス検出を維持する

ルーターの管理画面、プリンター、ファイルサーバー、社内ネットワークでは、直接接続を維持する必要があることがよくあります。ただし、いくつかのプライベートIPアドレスだけですべて解決できるとは限りません。LANでは独自ドメイン、振り分け用DNS、別のアドレス範囲が使われる場合があり、サブネットをまたぐ通信は実際のルーティングにも左右されます。LAN内のドメインに接続できない場合は、名前解決と宛先への到達性を分けて確認してください。関係のないサービスまで経路を変更しないよう、トップレベルドメイン全体を安易に直接接続へ追加しないでください。

ルールプロバイダーは大規模なルールセットの管理に便利ですが、ルールの動作タイプとファイル形式を区別する必要があります。ドメインの一覧、IPアドレスの一覧、クラシック形式のルールでは記述方法が異なり、参照時のタイプも内容に合わせなければなりません。利用前に提供元の信頼性、更新間隔、ダウンロード失敗時にローカルのデータが使えるかを確認してください。内容を理解せずに大規模なルールセットを重ねて追加しないでください。重複条件、過剰に広い範囲、更新による上書きが重なると、適用結果の把握が難しくなります。

設定テキストだけでなく接続の詳細で確認する

ルールを変更したら、設定が再読み込みされたことを確認してから、対象への新しい接続を作成してください。接続の詳細でドメイン、宛先アドレス、適用されたルール、最終的なポリシーを確認します。アプリが長時間接続を再利用している場合、ルールの変更だけでは既存の接続の出口はすぐに変わりません。必要に応じて該当する接続だけを閉じるか、テスト対象のアプリを再起動してください。システムのネットワーク設定をすべてリセットする必要はありません。確認結果は、すでに読み込み済みのページではなく、新しいリクエストで判断しましょう。

宛先が想定どおりに振り分けられない場合は、まずリクエストにドメイン情報があるか確認し、次にルールの順序、ポリシー名、サブスクリプション更新による上書きを確認してください。プロセスルールはOSの機能やプロセス識別の条件にも依存するため、あらゆるデバイス間でそのまま同期するのには向きません。追加するルールは小さな範囲にとどめ、用途をコメントに記録しましょう。根拠がなくなった一時的なルールは、例外を積み重ねるよりも削除したほうが保守しやすくなります。

ステップ07 / 通信の制御範囲を広げる

TUNとDNS：まず通信を取り込み、次に名前解決を確認

TUNが必要な場面を明確にする

システムプロキシを参照しないアプリの通信をコアに渡す必要がある場合に、TUNを検討しましょう。仮想ネットワークインターフェースとルーティング設定によって通信の制御範囲を広げますが、特定の通信を取り込めるかは、システム権限、ルート、プロトコル対応、クライアントの実装によって異なります。TUNを「すべてのネットワーク問題を直すスイッチ」として扱わないでください。システムプロキシで通信できる状態を確認してから有効にすれば、結果を比較しやすく、問題発生時にも元の入口へすぐ戻せます。

有効にする前に、使用中のVPN、コンテナー、仮想マシン、社内ネットワーク用ツールを記録しましょう。これらもルーティングやDNSを変更することがあり、併用時はデフォルトルートとLANアクセスをどれが担当するか明確にする必要があります。有効化後にLANへ接続できない、またはリモート接続がループする場合は、まずTUNを無効にして元の状態へ戻し、ルートの競合を確認してください。ネットワークアダプターの優先順位、ファイアウォール、名前解決サービスを同時に変更すると、どの操作が結果を変えたのか判断しにくくなります。

よく使われるTUNパラメーターを理解する

auto-route は関連するルートをコアに自動設定させる項目です。auto-detect-interface は出口インターフェースの選択を補助し、dns-hijack は条件に合うDNSリクエストを取り込みます。これらはOSの条件に関係なく有効になるスイッチではありません。ノートPCを有線から無線に切り替えると、出口の検出やルートを再設定する必要が生じる場合があります。サブスクリプションを再読み込みするのではなく、クライアントの手順に従って再接続するか、コアを再起動してください。

# これらのオプションに対応するmihomo設定に追加
# 対応するシステム権限が必要です。有効化する前に元の設定を保存してください
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

この断片は完全なサブスクリプションではなく、クライアント独自のTUN管理機能を回避して貼り付けるものでもありません。設定内の名前解決サービスには現在のネットワークから接続できる必要があり、コアはそのサービスのドメインを最初に解決できなければなりません。サンプルの仮想アドレスプールは内部マッピング用であり、リモートプロキシサーバーのアドレスではありません。環境内でアドレス範囲が重なる場合は、設定の説明を読んでから範囲やフィルター条件を変更してください。

名前解決の失敗と接続の失敗を区別する

DNSはドメイン名と接続先を対応付ける仕組みです。DNSサーバーを変更しただけでは、ノードの認証エラーやポート競合は解消できません。fake-ipモードではリクエストにマッピング用のアドレスを割り当て、コアがドメインとの関連付けを保持できるようにします。redir-hostでは通常、名前解決で取得した実際のアドレスを返します。互換性や処理経路が異なるため、すべてのデバイスに使える一律の正解はありません。LAN内の一部のアプリ、特殊な検出プログラム、直接接続するサービスには例外設定が必要な場合があります。

nameserver、fallback、関連するフィルター設定にはそれぞれ役割があります。予備のDNSは、単に「プライマリーが停止したときだけ一度問い合わせる」ものではありません。最終結果の選択にはフィルター条件が関わるため、設定前に現在のコアの処理方法を理解しましょう。DNSアドレスをいくつも無造作に追加して、数が多いほど安定すると考えるのは避けてください。各フィールドの役割を確認するには、mihomoのDNS設定とfake-ipの解説を読み、明確な問題の範囲内で変更しましょう。

ブラウザーやアプリ独自の暗号化DNSは、通常のポート53を使う通信経路を迂回することがあります。そのためDNSハイジャックを有効にしても、すべての名前解決を制御できるとは限りません。トラブル対処では、アプリ独自のDNSが有効か記録し、システム側の名前解決経路と比較してください。ログを確認するためだけにアプリのセキュリティ機能をすべて長時間無効にしないでください。管理されたテストで違いを確認し、影響がわかってから、DNSを統一するかアプリ独自の設定を残すか判断しましょう。

有効化後は3段階で確認します。まず通常のWebページが表示されるか、次にこれまでシステムプロキシを使わなかったアプリが接続一覧に表示されるか、最後にLAN接続とスリープからの復帰を確認してください。モバイル端末ではバックグラウンド動作や電池消費も確認しましょう。詳しくはモバイルのバックグラウンド動作とTUN常時稼働についてを参照してください。TUNを有効にしたときだけ問題が起きる場合は、まず検証済みの入口に戻し、ルートとログを手がかりに調べましょう。

ステップ08 / 復元できる状態を保つ

日常のメンテナンス：バックアップ、更新、トラブル対処の手順

正常に動作する状態を復元できるようにする

メンテナンス対象を、アプリ、コア、サブスクリプション、ローカルの上書き設定の4種類に分けましょう。アプリの更新では画面やシステム連携が変わることがあり、コアの更新ではフィールドへの対応やデフォルト動作が変わる場合があります。サブスクリプションの更新ではリモートの内容が置き換わり、ローカルの上書き設定には個別のルールが保存されます。4種類を別々に記録し、一度にすべて更新しないでください。問題が起きたとき、最後に変更した対象を特定できることは、整理されていない大量のログより役立ちます。

バックアップするのはサブスクリプションURLだけではありません。現在のプロキシ選択、カスタムルール、DNSの例外、混合ポート、クライアントのシステム連携設定も記録してください。エクスポート機能によっては、システムサービス、ログイン時の起動設定、ローカルのルールファイルは含まれません。アプリの説明に従って補完しましょう。バックアップには認証情報が含まれることがあります。管理された場所に保存して公開しないでください。クラウドの公開リンクを長期的な設定配布に使わないようにしましょう。

更新を検証できる変更として扱う

更新前に現在の設定を保存し、短時間の通信断を許容できる時間帯に作業しましょう。更新後はコアの起動、設定の読み込み、通常のブラウザー通信、重要なアプリ、LAN内のサービスを確認してから、古いファイルを削除するか決めてください。フィールドの廃止や解析動作の変更があった場合は、変更内容を読んで該当する設定部分を特定します。すべての機能を有効にしようとして、新しいオプションを同時にいくつも有効にしないでください。安定して動作する基準状態のほうが、機能一覧より参考になります。

自動起動では、起動順も確認が必要です。ログイン時にアプリが起動しても、ネットワークの準備が完了しているとは限りません。ネットワーク接続前にサブスクリプションやルールプロバイダーの更新が失敗しても、設定が壊れたとは限りません。ネットワーク復旧後に再更新できるか確認し、必要ならクライアントが対応する起動遅延や再試行を使いましょう。ノートPCがスリープから戻った後に失敗する場合は、出口インターフェース、システムプロキシ、コアの状態を比較してください。すべてのサブスクリプションをすぐに削除する必要はありません。

入口、コア、出口、宛先の順にトラブル対処する

最初に入口を確認します。コアが動作しているか、ポートが待ち受けているか、アプリが実際にその入口を使っているかを調べます。次に設定を確認します。有効な設定はどれか、解析エラーがないか、プロキシグループの参照が有効かを調べてください。3番目に出口を確認します。同じポリシーを使うリモートサービスに接続できるか、認証やプロトコルのエラーがないかを調べます。最後に宛先を確認します。他のWebサイトやアプリは正常か、特定のドメインやネットワークだけで起きる問題かを切り分けてください。

再現可能な失敗を対象にログを収集しましょう。まず時刻と操作を記録し、リクエストを発生させて、関連する前後の行を保存します。一時的にログレベルを上げると確認しやすくなりますが、詳細ログを長期間有効にすると書き込み量が増え、アクセス先のドメインが含まれることもあります。トラブル対処後は日常利用に適したレベルへ戻してください。共有する前にサブスクリプションURL、認証情報、公開したくないドメインを隠しましょう。最後の汎用エラーだけを切り取って、その前の原因を省かないでください。

ネットワークの切り替えと終了後の残留設定に対処する

自宅のネットワークから職場のネットワークへ切り替えると、DNS、認証ポータル、アクセス制限が同時に変わる場合があります。まずネットワーク側で必要なログインを完了し、必要ならプロキシの入口を一時的に無効にして、直接接続で通信できることを確認してから設定を戻してください。企業ネットワークではプロキシやVPNの使用が明示的に制限されることがあります。管理規則に従い、ポート変更を繰り返したり、プロセスを隠したりして規則を回避しないでください。現在のネットワークで許可された経路が使えることを確認してから、クライアントを検証しましょう。

クライアント終了後に通信できなくなった場合は、まずシステムに残ったプロキシ設定を確認してください。再起動後に通信できなくなった場合は、自動起動アプリと永続化された環境変数も調べましょう。障害時には、システムプロキシを無効にする、またはTUNを停止するといった明確な復旧手順を確保し、すぐにネットワーク関連の設定をすべてリセットしないでください。一般的な質問はFAQも参照できます。問い合わせる際はOS、クライアント、通信の入口、再現手順、実施した比較内容を添えてください。設定全体を公開する必要はありません。

ステップ09 / 段階的に応用する

応用へのステップ：プロバイダー、自動選択、導入時の注意点

自動化を加える前に設定の階層を理解する

安定して使えているからといって、機能を増やし続ける必要はありません。応用設定は具体的な課題に沿って学びましょう。ノードが多い場合はプロキシプロバイダー、ルールの更新頻度が高い場合はルールプロバイダー、リモート機器を常時稼働させる場合はサービス管理を学びます。各段階で最小限の設定と個別のテスト項目を残してください。内容がわからないフィールドを大量に含む設定をWebからコピーし、ランダムにスイッチを切り替えて動作を推測するのは避けましょう。

プロキシプロバイダーはノードの入手元をメイン設定から分離でき、更新や再利用がしやすくなります。一方で、入力形式、保存先、更新間隔、どのプロキシグループが参照するかを明確にする必要があります。プロバイダーからダウンロードできても、そのノードが使われるとは限りません。プロキシグループから対応する名前を参照する必要があります。ヘルスチェックには到達可能なテスト先が必要で、結果が示すのは特定のテスト経路の状態だけです。テストが成功しても、すべての通信が成功するとは限りませんし、実際の通信速度を示すものでもありません。

自動選択で測定される範囲を理解する

手動選択のグループは動作を確認しやすい一方、自動テストグループ、フェイルオーバーグループ、ロードバランシンググループにはそれぞれ用途があります。自動選択はテスト条件に、フェイルオーバーは利用可能性の判定に依存します。ロードバランシングでは、複数の接続をどのように振り分けるかも関係します。名前だけで判断して、すべてのグループを重ねないでください。セッションを維持する必要があるサービスなど、アプリが安定した出口に依存するかを確認してから、自動切り替えによる再ログインや接続中断の可能性を検討しましょう。

テスト間隔、タイムアウト、許容範囲は自動選択の動作に影響します。間隔が短すぎるとネットワークリクエストやモバイル端末の電力消費が増えることがあり、長すぎると経路の変化に気付くのが遅れます。現在のネットワークからテスト先に接続できないと、グループ全体の結果が不正確になります。まず手動選択で基本的な接続を確認してから、自動検出を有効にしてください。問題が起きたら、すべてをノードの品質のせいにせず、テスト先と実際の通信先を比較しましょう。

コマンドライン版のコアを独立した導入作業として扱う

サーバーやルーターへの導入では、実行アカウント、サービス起動、設定ファイルの権限、ログのローテーション、通信転送も管理する必要があります。デスクトップのシステムプロキシに関する経験だけでは対応できません。コアを直接実行しても、設定で有効にした機能が使えるだけで、LAN全体が自動的にプロキシ化するわけではありません。中継やゲートウェイとして使う場合は、デフォルトゲートウェイ、転送、ファイアウォール、戻り経路を含めて機器構成に沿って設計する必要があります。本番ネットワークで試しながら変更しないでください。

# mihomoがインストール済みの環境で設定の構文を確認
mihomo -t -f ./config.yaml

# 指定した作業ディレクトリから起動する。設定に必要なリソースをそのディレクトリに準備
mihomo -d ./profile

構文テストに成功しても、コアが設定を受け付けたことしかわかりません。リモートサービス、DNS、ルールのダウンロードが実行環境で利用できるとは限りません。確認にはできる限り本番と同じコアと作業ディレクトリを使い、相対パスの参照にも注意してください。サービスとして起動すると、環境変数、権限、カレントディレクトリが対話型ターミナルと異なる場合があります。「手動起動は成功するのにサービス起動は失敗する」場合は、まずこれらの環境の違いを比較しましょう。

管理インターフェースとLANへの公開を制限する

管理インターフェースはパネルや自動化ツールから制御できますが、プロキシの状態を変更する権限があります。必要な場合だけ有効にし、まずはローカルループバックアドレスに限定して、コアが対応する認証方式を設定してください。混合プロキシポート、管理インターフェース、DNSの待受ポートはそれぞれ別の入口です。どれか1つにLANアクセスが必要だからといって、他の入口まで全インターフェースにバインドしないでください。外部に公開する場合は、ホストのファイアウォールで接続元も制限する必要があります。

他の機器にプロキシを使わせる場合は、待受アドレス、LANアクセス設定、認証、ファイアウォールルールを個別に確認してください。共有ネットワーク上の機器すべてを信頼できるとは限りません。ポートをそのままインターネットに公開しないでください。ルーターに常設する場合は、再起動時の動作、ストレージ容量、ルールなどのリソース更新に失敗した場合の動作も考慮しましょう。長期的なネットワーク入口にする前に隔離された環境でテストし、設定ミスがネットワーク全体に影響するのを防いでください。

学習は、まず現在の設定を読み解き、次にルールを個別に変更し、その後DNSとTUNを理解してから、最後にプロバイダーとサービス運用を扱う順序で進められます。各段階で「何を解決するのか」「どう有効性を確認するのか」「どう元に戻すのか」の3点を確認しましょう。基本の手順を見直すには入門ガイドを、ツールを選び直すにはクライアントのダウンロードページを参照してください。接続の入口、適用ルール、最終的な出口を説明できることが、使える状態から保守できる状態へ進む鍵です。