Clash Meta全プラットフォームのインストール・設定

第01章 · 事前準備

共通の準備と設定の基本

クライアント・コア・サブスクリプションの違い

Clash Metaは、このエコシステムで使われてきた名称です。関連するコアは現在、一般にmihomoと呼ばれています。クライアントは設定の表示、ノードの管理、システム権限の要求、コアの起動を担当します。コアはプロキシプロトコル、DNS、ルール判定を処理し、サブスクリプションはノードや設定一式を提供します。クライアントをインストールしただけでは、利用可能な接続先があるとは限りません。利用権のあるサブスクリプション、または自分で構築したノードが必要です。サブスクリプションの有効性、対応プロトコル、接続台数の制限は提供元の案内を確認してください。インストールが成功しても、サブスクリプションの利用可否は判断できません。

デスクトップとモバイルでは、まずClash Plusを検討してください。LinuxではClash Verge RevまたはFlClashから始めるとよいでしょう。すべてのダウンロード先はダウンロードセンターにあります。選ぶ前にOS、CPUアーキテクチャ、インストール方法を確認し、パッケージ名のプラットフォーム表記だけで判断しないでください。GUIクライアントは画面上で操作したい場合に便利です。mihomoコア単体は、設定、プロセス、サービスを自分で管理したい場合に適しています。GUIによってサブスクリプションの管理方法は異なります。以下では操作の目的を説明しており、すべての画面に同じ名前のボタンがあるとは限りません。

互換性のある設定と復元手段を用意する

手元のファイルがClash YAML設定、ノード一覧、または別のソフト向けの設定形式のどれに当たるか確認しましょう。完全な設定には通常、プロキシ、グループ、ルールが含まれます。ノードだけのファイルには、対応するグループとルールも必要です。Base64形式のノードリンクは、そのまま完全なClash設定として使えるわけではありません。sing-boxのJSONも、拡張子を変えるだけでは読み込めません。形式の見分け方とローカル変換の注意点はサブスクリプション形式の比較メモをご覧ください。変換前に元ファイルを保管し、アクセス情報を含むリンクを信頼できないサービスに送信しないでください。

初回設定の前に、ほかのプロキシクライアントを終了し、現在のシステムプロキシとVPNの状態を記録してください。会社や学校の管理端末では、プロキシの変更、ネットワーク拡張のインストール、ルートの追加が許可されているか事前に確認します。システム時刻、サブスクリプションのアカウント状態、現在のネットワークから配布URLにアクセスできるかも確認してください。インポート時は見分けやすい名前を付け、使用する設定として選択します。設定一覧にファイルが表示されても、実行中のコアがその設定に切り替わったとは限りません。

まず最小限の接続を確立し、次に通信の対象範囲を広げる

設定をインポートし、ルールモードを選び、対象のグループでノードを指定してから、システムプロキシを有効にしてブラウザーで試すのがおすすめです。ルールモードはコアに届いた通信の振り分けを決め、システムプロキシはOSの設定に従うアプリをコアへ接続します。TUNは仮想ネットワークインターフェースを使って通信の対象を広げる機能で、追加の権限が必要になり、ルートやDNSにも影響する場合があります。まず最小限の接続を確認してからTUNを有効にすると、ノード、権限、ルートの問題を切り分けやすくなります。

以下は設定項目の例であり、ノード情報は含まれていません。このままではプロキシ接続を確立できません。ポート番号は使用中のクライアントに合わせてください。クライアントがこれらの項目を管理している場合は、実行時に生成されるファイルを直接編集せず、用意された設定画面や上書き機能を使いましょう。まずはローカルからの待ち受けに限定するのが安全です。LAN内で共有する場合は、認証とファイアウォールも確認してください。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

第02章 · Windows

Windowsのインストールと通信の取り込み

インストーラーを選んで初回起動する

WindowsのダウンロードページからClash Plusを選びます。別の操作画面が必要な場合は、Clash Verge Rev、FlClash、Clash Nyanpasuも確認してください。Clash for Windowsは開発が終了したアーカイブ版のため、新しい端末での利用にはおすすめしません。設定アプリの「バージョン情報」でCPUの種類を確認し、ダウンロードページに記載された対応範囲と照らし合わせてください。ARM端末を一般的なx64インストーラーと混同しないようにしましょう。ファイルをダブルクリックできるかどうかだけで、アーキテクチャの適合性を判断することはできません。

インストーラーを実行する際は、システムの警告を読み、配布元を確認してから続行してください。展開して実行する形式の場合は、固定のフォルダーに解凍してから起動します。圧縮ファイルのプレビュー画面から直接起動しないでください。初回起動後、タスクトレイのアイコンとメイン画面が開くことを確認し、ログに設定の解析エラーやポートのバインドエラーがないか確認しましょう。インストール時の権限と、普段の実行権限は別です。サービスや仮想ネットワークアダプターのインストールなど、明確に管理者権限が必要な操作だけ許可し、通常のシステムプロキシのテストで常に管理者として実行する必要はありません。

サブスクリプションを追加して使用中の設定を確認する

設定またはサブスクリプションの画面を開き、URLからインポートする機能に完全なサブスクリプションURLを貼り付けて、取得と解析が終わるまで待ちます。ローカルのYAMLを読み込む場合は、拡張子が非表示になって二重になっていないか確認してください。追加した設定を選択し、プロキシの画面に想定したグループが表示されることを確認します。更新に成功してもノード一覧が変わらない場合は、使用中の設定、サブスクリプションの期限、提供元からの応答を先に確認してください。すぐに再インストールする必要はありません。提供元がエラーページを返している場合、再インストールしても解決しません。

ルールモードでは、ルールが実際に参照するグループを見つけ、利用可能なノードを手動で選びます。グループが別のグループを含む場合、最終的な出口は最後の階層で選択された内容によって決まり、画面で目立つノード名とは限りません。クライアントの遅延テストを実行し、結果が出た候補を選んでから実際の接続を試してください。テストに失敗した場合、そのテストのリクエストが完了しなかったことは分かりますが、すべてのプロトコルや接続先が使えないとは限りません。

システムプロキシの確認とTUNの段階的な導入

システムプロキシを有効にしたら、Windowsのネットワーク設定でプロキシサーバーのアドレスがローカルの待ち受け先を指していること、ポート番号がクライアントと一致していることを確認します。一般的なブラウザーはシステムプロキシを使いますが、ターミナル、ゲーム、一部のダウンロードツールは独自のネットワーク設定を持つ場合があります。振り分け結果が分かりやすいサイトを開き、クライアントの接続一覧も確認しましょう。対応する通信が追加されない場合は、ルールの順序ではなく、まずアプリからプロキシへの入口を調べてください。ブラウザー拡張機能がシステム設定を上書きすることもあるため、テスト中は一時的にその影響を除きます。

システムプロキシを使わないアプリの通信も取り込みたい場合に、TUNを有効にします。クライアントからサービスのインストールや権限の許可を求められた場合は、その操作を完了し、ログで仮想ネットワークアダプターの作成、ルートの追加、DNSの取り込みを確認してください。会社のVPN、仮想マシンのネットワークアダプター、セキュリティソフトがデフォルトルートに影響する場合があります。有効化後にすべての通信が止まったら、まずTUNを無効にして元の環境に戻し、原因を一つずつ調べましょう。システムプロキシとTUNを最初から同時に有効にする必要はありません。個別に試すと、どの入口で変化が起きたか分かりやすくなります。

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com

上記のPowerShellの例では、混合ポートを7890としています。実際の設定に合わせて変更してください。ポートのテストに成功しても、確認できるのはTCPで待ち受け先に接続できることだけです。その後のリクエストには、ノード、DNS、接続先、ルールも関わります。curl.exeを使うと、コマンドラインプログラムを明示的に呼び出せます。一部のPowerShell環境で同名のエイリアスが使われることによる引数の違いを避けられます。この方法はプロキシを明示してリクエストするため、アプリがシステムプロキシを参照するかどうかに左右されず、ローカルの待ち受けとシステム設定のどちらに問題があるかを切り分けるのに役立ちます。

終了、スリープ、ポート競合への対処

終了する前にシステムプロキシを無効にし、システム設定が元に戻ったことを確認してからクライアントを終了してください。異常終了後にブラウザーがインターネットへ接続できない場合は、ローカルのプロキシアドレスが残っていないか確認します。その場合はシステムプロキシを元に戻せばよく、ネットワーク設定をすべて削除する必要はありません。スリープから復帰後にノードへ接続できない場合は、まず接続を再確立するかコアを再起動し、その後でサブスクリプションの更新が必要か判断します。ポートが使用中の場合は、既に待ち受けているプロセスを特定しましょう。起動が重複している問題を、ポート番号の変更だけで隠さないでください。初回接続の確認方法はノード選択とプロキシ接続の確認をご覧ください。

第03章 · macOS

macOSの権限とネットワークサービス

チップに合ったクライアントを選ぶ

「このMacについて」を開き、Apple SiliconとIntelのどちらのプロセッサか確認してから、macOSのダウンロードページで対応するインストーラーを選びます。まずClash Plusを検討してください。Clash Verge RevやFlClashも利用できます。ClashX Metaは開発が終了したアーカイブ版として掲載しています。ダウンロードページにあるアーキテクチャとシステム要件を併せて確認し、クライアント名だけで互換性を判断しないでください。変換レイヤーを使った実行とネイティブ実行では制約が異なる場合があります。端末のアーキテクチャに合うパッケージを優先してください。

配布形式がディスクイメージの場合は、インストーラーの案内に従ってアプリを「アプリケーション」フォルダーに移し、固定の場所から起動してください。一時的にマウントした場所から使い続けないようにしましょう。システムのセキュリティ警告は、配布元とアプリの署名を確認して判断してください。配布元が不明、ファイルが破損している、表示内容が想定と異なる場合は、セキュリティ機能を無効にせずダウンロードページに戻って確認します。初回起動ではメニューバーのアイコンとログを確認し、アプリとコアが正常に動作してから、システムプロキシやネットワーク拡張の権限を設定してください。

設定のインポートとローカル上書き

設定管理画面からサブスクリプションを追加し、ダウンロードと解析が終わったら使用中の設定にします。プロキシの画面でグループ、ノード、ルールがそろっているか確認してください。サブスクリプション名だけ表示され、プロキシ項目がない場合は、形式と応答内容を確認します。macOSアプリの設定データは通常、ユーザーディレクトリ内のアプリデータ領域に保存されますが、場所はクライアントによって異なります。他のソフトと同じパスだと推測するより、クライアントの「設定フォルダーを開く」などの機能を使うのが確実です。

サブスクリプションを更新すると、リモート設定の内容が置き換わります。ダウンロードしたファイルを直接編集しても、次回の更新で変更が失われることがあります。個人用ルールの追加、DNSやポートの変更には、クライアントが対応する上書き、マージ、拡張設定の機能を使い、反映後の設定を確認してください。配列を置き換えるか追加するかはクライアントによって異なります。カスタムルールがフォールバックルールより前に適用されることも確認しましょう。変更前に復元可能なローカルコピーを保存し、認証情報を含むバックアップを公開リポジトリに同期しないでください。

現在のネットワークサービスのプロキシ設定を確認する

システムプロキシを有効にしたら、システム設定で現在使用中のWi-Fiまたは有線ネットワークサービスを開き、プロキシの設定を確認してください。ネットワークサービスごとに設定が分かれている場合があるため、有線からWi-Fiに切り替えた後は、現在のサービスを改めて確認します。HTTP、HTTPS、SOCKSの設定方法はクライアントによって異なります。他のクライアントのスクリーンショットを見ながら、項目をそのまま入力しないでください。システムコマンドで反映状態を確認できますが、出力に環境情報が含まれる場合があります。公開する前に個人情報を取り除いてください。

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

明示的にプロキシを指定したリクエストは成功するのに、ブラウザーの接続が一覧に表示されない場合は、ブラウザーのプロキシ拡張機能、個別のプロキシ設定、使用中のネットワークサービスを確認してください。ターミナルのコマンドは、通常、GUIのシステムプロキシ設定をすべて自動で引き継ぐわけではありません。使用するツールに応じて、プロキシ引数または環境変数を設定しましょう。環境変数を参照するのは、その設定を読み込むプロセスだけです。新しいターミナルと、起動済みの開発ツールで環境が異なることもあるため、同じターミナルから再度テストしてください。

TUNの許可、ネットワーク切り替え、復旧

TUNを使う場合は、クライアントの案内に従ってネットワーク拡張やヘルパーサービスに必要な権限を許可してください。具体的な方法は実装によって異なります。許可画面が消えても、通信の取り込みが完了したとは限りません。ログでインターフェースの作成、ルートの設定、DNSの起動に成功したか確認しましょう。会社のVPNを併用している場合、相手側からルートやDNSが強制的に設定されることがあります。組織のネットワークポリシーに従って対処し、管理対象の設定を上書きしないでください。まず片方だけを有効にして結果を確認し、併用可能か判断します。

スリープからの復帰、テザリングへの切り替え、ポータル認証が必要なネットワークでは、デフォルトルートが変わることがあります。ホテルや公共Wi-FiでWeb認証が必要な場合は、まず通信の取り込みを一時停止して認証を完了し、その後プロキシを再開して確認してください。TUNを無効にしても接続できない場合は、現在のネットワークサービスにシステムプロキシが残っていないか、ほかのVPNが動作していないか確認します。ネットワークサービスの削除、DNSのリセット、クライアントの再インストールを一度に行わないでください。一度に一つだけ条件を変えれば、復旧した理由を特定でき、次の調査に必要な情報も残せます。

第04章 · Android

Androidの権限とバックグラウンド動作

インストールと設定の入手先

Androidのダウンロードページから、まずClash Plusを選びます。必要に応じてClash Meta for Android、FlClash、Surfboardも確認してください。端末のCPUアーキテクチャを確認してからインストーラーをダウンロードします。Android端末がすべて同じアーキテクチャとは限りません。現在のブラウザーやファイル管理アプリからアプリをインストールする許可が必要な場合は、今回のインストールに必要な範囲だけ許可し、完了後に元の設定へ戻せます。インストール時に競合が起きたら、署名の異なる同名アプリが既に入っていないか確認してください。すぐに古いアプリのデータを削除しないでください。

初回起動後、サブスクリプションURLまたはローカル設定ファイルをインポートします。システムのファイル選択画面から読み込む場合は、ファイル名が見えているだけでなく、クライアントにファイルの読み取り権限が与えられていることを確認してください。設定のダウンロードが終わったら選択し、プロキシ画面にグループが表示されるか確認します。元の設定に現在のクライアントが対応しない項目やプロトコルが含まれていると、解析エラーや機能の一部欠落が起きる場合があります。インポートログを確認し、どのクライアントもプロキシに対応しているから設定も完全に共通だとは考えないでください。

VpnServiceと通信をコアに取り込む仕組み

Androidのプロキシクライアントは通常、VpnServiceでローカルVPNインターフェースを作成し、端末の通信をアプリ内で処理します。システムに表示されるVPN接続の許可は、アプリにネットワークを取り込む権限を与えるものです。リモートノードに接続したことを意味するわけではありません。最終的な出口は、設定、グループ、ルールによって決まります。許可したら接続を開始し、システムのVPN状態とクライアントのログを確認してからテスト先へアクセスしてください。鍵やVPNのアイコンが表示されているだけでは、サブスクリプション、ノード、DNSがすべて正常とは判断できません。

デスクトップの「システムプロキシ」スイッチを、そのままAndroidに当てはめることはできません。Wi-Fiの手動プロキシ設定は、対象となるネットワークやアプリにのみ影響し、VpnServiceによる通信の取り込みとは異なります。Androidでは通常、一般的なVPNアプリを二つ同時に同じVPN接続枠で動かすことはできません。別のVPN、VPNを使うフィルターアプリ、ファイアウォールを起動すると、現在のクライアントが置き換えられる場合があります。接続が切り替わったら、ノードを何度も変更する前にシステムのVPN設定を確認し、入口の競合を調べましょう。

ルール、アプリごとの設定、バックグラウンド制限

まずルールモードで標準設定をテストし、その後にアプリごとの設定を検討してください。対象アプリをVPNに通すかどうかはアプリ別設定で決まり、通過後の出口はドメインルールで決まります。この二つは別のレイヤーです。対象アプリをVPNの対象外にすると、そのアプリがアクセスするドメインにプロキシルールを追加しても適用されません。許可リストや除外リストを変更した後は、クライアントによってVPNインターフェースの再作成が必要です。接続経路に古い設定が残らないよう、対象アプリの接続を一度終了してから開き直してください。

省電力設定によって、画面ロック後にクライアントの動作が制限されることがあります。バックグラウンドでのみ接続が切れる場合は、アプリのバッテリー設定、バックグラウンド実行、自動起動、メーカー独自のアプリ固定機能を確認してください。設定画面への入口は端末によって異なります。まず必要なバックグラウンド動作を許可し、画面をロックしてしばらくした後もログが続いているか確認しましょう。すべてのアプリを制限対象外にする必要はありません。メーカー別の設定方法はVpnServiceの許可とバッテリー最適化の除外設定をご覧ください。VPNを常時動作させるとリソースを消費するため、すべての端末で同じ動作を保証することはできません。

プライベートDNS、ネットワーク切り替え、更新

Androidでは、プライベートDNS、ブラウザーのセキュアDNS、クライアントのDNS、モバイル回線の名前解決が同時に使われる場合があります。設定でDNSの取り込みを有効にしている場合は、まず追跡できる経路を一つに保ち、プライベートDNSの元の状態を記録してから比較テストを行いましょう。名前解決エラーが出たからといって、サーバー、Fake-IP、すべてのDNSスイッチを同時に変更しないでください。まずリクエストがコアに届いているか確認し、次に特定のドメインだけでエラーが起きているかを調べます。IPv6はルートの取り込み能力と併せて確認してください。ネットワークアイコンだけでは判断できません。

Wi-Fiからモバイル回線に切り替えた後に接続が一時的に失われた場合は、ネットワークが確立するまで待ってからクライアントを再接続し、その回線からサブスクリプションURLにアクセスできるか確認します。テザリングで接続した端末の通信が、スマートフォンのVPNを通るとは限りません。スマートフォン本体から接続できても、テザリング先で成功するとは限りません。サブスクリプションの自動更新も、バックグラウンド制限やネットワーク状況の影響を受けます。必要に応じてアプリを前面に出して手動更新し、使用中の設定を確認してください。アプリを更新する前に必要な設定を保存し、古いデータを削除するのは移行や署名競合の解消に本当に必要な場合だけにしましょう。

第05章 · iOS

iOSの設定インポートとVPN

Clash Plusを入手し、設定の対応範囲を確認する

iOSのダウンロードページからClash PlusのApp Storeページを開けます。アプリの情報は公式サイト clashplus.ioでも確認できます。インストール前に、App Storeに記載されたシステム要件と機能説明を読んでください。Clash設定はエコシステム内で使われる形式ですが、インポートに対応していても、すべてのクライアントがmihomoの全項目に対応しているとは限りません。高度なDNS設定、スクリプト、特定のプロトコルを使う場合は、現在のアプリの対応範囲を確認してください。デスクトップ向け設定の前提をそのまま当てはめないようにしましょう。

iOSのプロキシアプリはシステムのネットワーク拡張を通じて通信を取り込みます。デスクトップでコアのプロセスを直接起動する方法とは異なります。Windowsと同じサービスインストールボタンを探したり、デスクトップの仮想ネットワークアダプターの設定をスマートフォンに当てはめたりしないでください。設定が読み込まれるか、VPN拡張が正常に起動するか、対象の通信が想定どおりにルーティングされるかを確認しましょう。同じ名前のスイッチが画面にない場合は機能説明を確認し、不明な構成プロファイルをインストールして補おうとしないでください。

サブスクリプションURL、ファイル、QRコード

設定画面でURLからのインポートを選び、完全なサブスクリプションURLを貼り付けて取得を実行します。入力後、プロトコル、パス、クエリパラメーターがすべて含まれているか確認し、末尾の空白や改行が混入しないようにしてください。ファイルのインポートに対応している場合は、システムのファイル選択画面または共有メニューからYAMLを選びます。クラウド上のファイルがまだ端末にダウンロードされていない場合は、読み取れる状態になるまで待ってください。インポート後は使用中の設定として選び、サブスクリプションの記録だけでなく、想定したノードがグループに表示されていることも確認します。

QRコードは通常、サブスクリプションURLやノードリンクを別の形で表示したものです。形式の非互換性を解決するものではありません。読み取りの前後に配布元を確認し、サブスクリプションのQRコードを公開の掲示板に投稿しないでください。システムの共有メニューにクライアントが表示されない場合は、アプリに用意されたインポート方法を使いましょう。ブラウザーでYAMLを直接開く操作を何度も試す必要はありません。サブスクリプションの取得時にログイン画面やエラー説明が返されると、アプリが解析に失敗する場合があります。まずサブスクリプションへのアクセス権を解決し、その後でアプリの形式対応を確認してください。

VPNの許可と初回接続の確認

使用する設定とノードを選んで接続を開始すると、VPN構成の追加を許可し、端末の認証を求められる場合があります。この許可はアプリが管理するVPN接続を作成するためのもので、サブスクリプションが有効だという意味ではありません。許可後にアプリへ戻って起動結果を確認し、ブラウザーでテスト先にアクセスします。接続やログの画面があれば、対象ドメイン、ルール、出口を確認してください。十分な情報が表示されない場合は、明らかに直接接続するサイトと、プロキシ経由のサイトを比較できます。ただし、一つのサイトでの失敗だけで全体を判断しないでください。

ルールモードは標準的なテスト環境として適しています。グローバルモードでは、アプリに届いた接続をグローバルポリシーに渡すのが一般的ですが、名前だけを根拠にすべてのシステム通信が取り込まれると判断しないでください。実際の範囲はシステムとアプリの実装によって異なります。ダイレクトモードでもVPNが終了するとは限らず、DNSやルートの取り込みが続く場合があります。元のネットワークに戻して比較するには、アプリのVPN接続を停止してから同じ接続先をテストし、通信の取り込み状態だけを変えて比較してください。

ネットワーク切り替え、DNS、メンテナンス

別のVPNアプリ、管理対象端末のネットワークポリシー、システムのプライバシー関連機能が、実際の接続経路に影響することがあります。接続が互いに置き換わる場合は、まずシステムのVPN一覧を開き、どのアプリが有効になっているか確認してください。現在のクライアントに関係のない企業向け設定は削除しないでください。公共Wi-Fiのポータル認証が必要な場合は、一時的にプロキシを停止してログインし、接続を再開してからドメインの名前解決を確認します。ネットワークへの接続手順が未完了のまま、ノードの変更を繰り返さないでください。

画面ロック後や、Wi-Fiとモバイル回線の切り替え後に問題が起きた場合は、まずアプリで再接続し、特定のネットワークだけで発生するか確認します。バッテリー残量、システムのバックグラウンド制御、ネットワーク拡張の状態が重なって影響する場合があります。画面を開き続けているかどうかだけでは判断できません。サブスクリプションの更新後は、現在のグループ選択が維持されているか確認します。ノードが削除または改名されると、選択し直す必要があります。詳しい手順はiOSアプリの入手と設定インポートに関するメモをご覧ください。トラブルシューティングでは、現在のクライアントが実際に対応している項目を基準にしてください。

第06章 · Linux

Linuxのデスクトップとコアのサービス

GUIクライアントかコア単体かを選ぶ

デスクトップで使う場合は、LinuxのダウンロードページからおすすめのClash Verge Revを選ぶか、FlClashを利用してください。ディストリビューションのパッケージ管理方式、CPUアーキテクチャ、デスクトップ環境、インストーラーの要件を確認します。DEBに対応していても、すべてのLinux環境に対応しているとは限りません。サーバーやルーターに導入する場合は、mihomoコアのダウンロード欄を確認してください。コア単体にはGUIがないため、サブスクリプション、システムプロキシ、起動権限を自分で管理する必要があります。設定ディレクトリと実行ユーザーも把握しておきましょう。

デスクトップクライアントをインストールしたら、まず一般ユーザーで起動し、ログや設定画面が使えることを確認してください。GUIに必要なシステムコンポーネントは、ディストリビューションがサポートする方法でインストールします。関係のないサイトから同じ名前の共有ライブラリをダウンロードしないでください。デスクトップメニューにアイコンが表示されない場合は、まず配布パッケージの起動方法でエラーを確認してから、デスクトップへの登録を調べます。サーバーでは、起動時サービスとして登録する前に、コアと設定をフォアグラウンドで検証しましょう。エラーを確認しやすくなり、サービスの再起動で最初の原因が見えなくなるのを防げます。

設定のインポート、パス、構文チェック

GUIクライアントでは設定画面からサブスクリプションをインポートし、使用中の設定にします。コア単体を使う場合は、完全なYAMLを場所が明確なディレクトリに置き、ファイルの読み取り権限を確認してください。認証情報を含む設定は、他のローカルユーザーから読み取れないようにし、バックアップにも同じ対策を適用します。相対パスは通常、コアの作業ディレクトリまたは設定ディレクトリを基準に解決されます。ルールセット、地理データ、ローカルプロバイダーファイルが見つからない場合は、同じファイルを複数の場所にコピーするのではなく、まずパスの解決方法を確認してください。

mkdir -p "$HOME/.config/mihomo"
chmod 700 "$HOME/.config/mihomo"
mihomo -t -d "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

このコマンド例では、実行可能なmihomoがインストール済みで、完全な設定を同じディレクトリのconfig.yamlとして保存していることを前提とします。まず設定テストを実行し、成功してからフォアグラウンドで起動してください。テストに成功しても、リモートノードへ接続できるとは限りません。また、外部のルール用リソースが以後の実行時に更新できることも保証されません。権限エラーが発生したら、ディレクトリの所有者とプロセスの実行ユーザーを確認してください。設定ディレクトリ全体をすべてのユーザーが書き込めるようにするのは避けましょう。

デスクトップのプロキシ設定とターミナルの環境を別々に確認する

Linuxのデスクトップ環境では、システムプロキシの保存方法が統一されておらず、アプリがその設定をどの程度使うかも異なります。GUIでシステムプロキシを有効にしたら、現在のデスクトップのネットワーク設定を確認し、対象アプリの接続が表示されるか観察してください。コマンドラインツールでは、通常、引数または環境変数の明示的な設定が必要です。ブラウザーが使えてパッケージ管理ツールが使えなくても、ノードの障害とは限りません。すべてのシェル起動ファイルをすぐに変更するより、一時的な環境変数で試すほうが元に戻しやすくなります。テスト後に設定を永続化するか判断しましょう。

curl --proxy http://127.0.0.1:7890 --head https://example.com
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1
unset http_proxy https_proxy no_proxy

ここで設定するhttps_proxyは、HTTPプロキシの入口です。HTTPSの接続先には、この入口を使ってトンネルを確立します。ローカルのプロキシポート自体にTLSが必要という意味ではありません。大文字・小文字の環境変数名や除外リストへの対応はツールによって異なります。権限を昇格してコマンドを実行すると、現在の環境変数が引き継がれない場合もあります。一つのツールを動作させるために、すべてのシステムサービスへプロキシ変数を設定しないでください。ツールの説明と実行ユーザーを確認し、必要な範囲に限定しましょう。

TUN、サービス管理、ファイアウォール

TUNは仮想ネットワークデバイス、ルート、DNSを扱うため、通常はネットワーク管理に必要な権限が求められます。コンテナでは、ホスト側から必要なデバイスへのアクセスと適切な権限も必要です。コンテナ内の設定が正しくても、ホストの通信が取り込まれるとは限りません。デスクトップクライアントにサービスモードがある場合は、指定された手順で設定してください。コア単体では、権限の範囲を理解したうえでディストリビューションのサービス管理機能を使います。手軽だからといって、すべてのGUIアプリをrootで常時実行しないでください。

サービスとして登録する場合は、実行バイナリのパス、設定ディレクトリ、実行ユーザーを明示してください。フォアグラウンドでのテストを終えてから自動起動を設定します。トラブル時は、まず別のコアがポートを使用していないか確認し、サービスログで終了理由を調べます。システムのファイアウォール、別のVPN、コンテナネットワークはルートに影響する場合があります。混合ポートを開けても、インターネットから接続できるようにする必要があるとは限りません。通常はローカルで待ち受けてください。LAN内で共有する場合は、接続元の範囲、認証、ホストのファイアウォール、信頼できないネットワークを考慮し、プロキシを不特定の接続元に公開しないようにしましょう。

第07章 · 設定に関するよくある質問

設定に関するよくある質問とトラブルシューティング

まず、どのレイヤーで失敗しているか確認する

まず問題の範囲を記録します。設定をインポートできないのか、コアが起動しないのか、すべてのアプリで失敗するのか、特定の接続先だけで問題が起きるのかを切り分けてください。インポートの失敗では、サブスクリプションの応答、ファイル形式、解析エラーを確認します。起動の失敗では、ポート、パス、権限を確認します。接続があるのにアクセスできない場合は、ルール、DNS、ノード、接続先からの応答を調べます。一度に一つだけ条件を変え、前後のログを保存してください。サブスクリプションの更新、モード変更、TUNの有効化、DNSの変更を一度に行うと、一時的に復旧しても原因が分からず、次に再発したときも対処しにくくなります。

ログのタイムアウトは、すべて同じ原因を示すわけではありません。サブスクリプションの取得、DNSリクエスト、ノードとのハンドシェイク、接続先へのアクセスのどの段階で起きたか、前後に表示された対象アドレスと併せて確認してください。接続拒否は待ち受け状態やポートの確認が必要な場合があります。証明書エラーでは、まず時刻、接続先の名前、ネットワーク環境を確認します。一時的にログレベルを上げると手がかりが増えますが、診断後は適切なレベルに戻してください。ドメインや接続情報を過剰に記録しないためです。ログを公開する前に、必ず機密情報を取り除いてください。

ルールの適用先とグループの実際の出口

ルールは通常、記述された順に照合され、最初に一致したルールのポリシーが使われます。カスタムルールを最後のMATCHより後ろに置くと、通常は参照されません。存在しないグループを指定した場合も、設定エラーになることがあります。以下の例では、現在の設定にPROXYというグループが既に定義されていることを前提としています。示しているのはルールとの対応関係だけで、単独で完全なサブスクリプションとして使えるものではありません。GEOIPの判定結果は、必要なデータと名前解決の条件に依存します。接続先のサイト名だけでは、ドメインルールとIPルールのどちらが一致するか判断できません。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

プロキシルールに一致しているのに直接接続される場合は、そのグループでDIRECTが選ばれていないか、別の直接接続グループにネストされていないか確認してください。グローバルモードに切り替えた場合も、先ほど選んだノードが自動的に使われると考えず、グローバルポリシーの選択を確認します。ルール、グローバル、ダイレクトの違いは3つのプロキシモードの解説をご覧ください。新しいルールをテストする際は、古い接続を閉じてから再アクセスしてください。既存の長時間接続は、ルールを変更してもすぐに新しい出口へ切り替わらない場合があります。

Fake-IP、DNS、TUNの関係

Fake-IPでは、DNSが対応付け用の仮想アドレスを返し、コアがその対応情報からドメインを復元して通信を振り分けます。これはリモートノードのアドレスではなく、DNSが改ざんされた証拠と単純に判断できるものでもありません。アプリに仮想アドレスがキャッシュされた後でクライアントが終了したり、通信の取り込み経路が変わったりすると、名前解決とルーティングが一致しないことがあります。まずDNSと通信の取り込み設定を整合させてから、対象アプリを再起動するか関連キャッシュを削除してください。仮想アドレスを長期間使うホスト設定に直接追加しないでください。

TUNを有効にしても、すべてのDNSリクエストが想定どおりに処理されるとは限りません。アプリ内蔵の暗号化DNS、システムのプライベートDNS、IPv6のルート、別のVPNが接続経路に影響します。リクエストとルールの適用を実際に確認してから、設定が有効か判断してください。LAN内の機器名、プリンター、社内ドメインには、ローカルのDNSサーバーへのアクセスが必要な場合があります。必要に応じて対象を絞ったDNSルールやFake-IPの除外を設定し、すべてのドメインを直接接続にしないでください。用語の説明はDNSとネットワークスタックの用語集をご覧ください。

復元できる設定と更新範囲を保つ

サブスクリプションの自動更新前にローカルの上書きルールを保管し、更新後はグループ名、ノードの選択、DNSの生成結果を確認してください。上流側でグループ名が変更されると、以前の上書き設定が存在しない項目を参照する場合があります。設定の読み込みは成功しているのに動作が変わった場合は、編集元ファイルだけでなく、最終的に適用された設定を比較するほうが有効です。クライアント、コア、サブスクリプションの更新は別々の経路です。一つの更新に成功しても、ほかも変わったとは限りません。トラブルの記録には、どの対象を更新したかそれぞれ明記してください。