Clashの全プラットフォーム導入・設定ガイド：サブスクリプション、システムプロキシ、TUN

事前準備と設定の基本

まず、端末のOSとプロセッサのアーキテクチャ、利用可能なサブスクリプションを確認してからクライアントをダウンロードします。デスクトップではシステム情報、スマートフォンではOSのバージョンと機種を確認してください。クライアントは画面表示や設定管理、通信の振り分けを担い、mihomoなどのコアは設定の読み込みや通信の転送を担います。両者は別の役割です。インストールが完了してもサブスクリプションが使えるとは限らず、サブスクリプションを追加できても端末の通信がコアに届いているとは限りません。以降の確認では、この3つの段階を分けて検証します。

クライアントとサブスクリプション形式を選ぶ

Windows、macOS、Android、iOSではClash Plus、LinuxではClash Verge RevまたはFlClashをまず検討してください。クライアントによって機能の場所や設定の保存方法は異なります。このガイドでは「設定」「プロキシグループ」「システムプロキシ」などの機能名で説明し、特定の画面にあるボタンの位置を共通の手順とはしません。ダウンロード前にメンテナンス状況も確認しましょう。Clash for WindowsとClashX Metaは開発終了済みのアーカイブ版で、新しい端末向けの標準的な選択肢ではありません。

利用権限のあるサブスクリプションURLまたはローカル設定ファイルを用意します。サブスクリプションURLにはアカウントを識別できる情報が含まれることがあるため、公開の掲示板やスクリーンショット、オンライン変換サービスに貼り付けないでください。完全なClash YAMLには通常、プロキシノード、プロキシグループ、ルールが含まれます。ノード一覧だけの場合は、クライアントのテンプレートや配信元が出力する互換形式が必要になることがあります。形式エラーが出たら、取得したものが設定テキストかを確認してください。ログイン画面、アクセス拒否のメッセージ、期限切れの案内を取得していないかも確認し、拡張子だけで内容を判断しないでください。

設定、モード、通信の取り込みを区別する

設定を一覧に追加したら、その項目を選択して有効にします。次にプロキシグループで出口を選び、通常はRuleモードから試します。Ruleはルールに基づいて直結かプロキシかを決定します。Globalはコアに届いた通信をグローバルポリシーに渡し、Directは直接接続します。いずれもコアに入った後の通信処理を決めるもので、すべてのアプリの通信をコアへ送る機能ではありません。Globalに切り替えても、システムプロキシが無効な問題は解決しません。また、TUNに必要なシステム権限の代わりにもなりません。

方式	主な役割	注意点
システムプロキシ	システム設定に従うアプリにプロキシのアドレスを通知します。	一部のターミナル、ゲーム、独自のネットワーク機能を持つアプリでは利用されません。
TUN / VPN	仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。	システムの許可が必要で、ほかのVPNやルーティングツールと競合することがあります。
アプリ内プロキシ	個々のアプリからローカルのプロキシポートへ直接接続します。	プロトコル、アドレス、ポートをクライアントの待ち受け設定に合わせる必要があります。

元に戻せる状態を確保する

初回設定では通信の取り込み方式を1つだけ有効にし、動作を確認してから機能を追加します。元のシステムプロキシ設定、ほかのVPNの状態、クライアントのポートを記録してください。DNS、TUN、ルール、サブスクリプションを一度に変更すると、問題の原因を特定しにくくなります。試験用に設定をコピーし、普段使うサブスクリプションは元のまま残しましょう。自動更新で直接編集した内容が上書きされることがあります。変更を保持するには、クライアントが対応するオーバーライド、マージ、スクリプトの設定を使い、実行中の設定に反映されていることを確認してください。

設定後は、プロキシ経由にするサイトと直結させるサイトを1つずつ選んでアクセスします。接続画面で対象ドメイン、適用ルール、最終的な出口を確認してください。遅延テストはその時点での疎通確認にすぎず、すべての通信プロトコルが正常に使える証明にはなりません。手順を追って設定する場合はサブスクリプションの追加手順を、用語を確認する場合はプロキシグループの解説を参照してから、該当するOSの章へ進んでください。

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

Windowsクライアントのダウンロードを開き、まずClash Plusを確認して、端末のアーキテクチャに合ったインストーラーを選びます。「設定 → システム → バージョン情報」でプロセッサとシステムの種類を確認できます。x64とARM64は自由に置き換えられるものではありません。互換レイヤーでアプリが起動しても、ネットワークサービスのコンポーネントが対応しているとは限りません。インストール前に古いクライアントを終了してください。特にタスクトレイで動作中のものがあると、複数のプログラムがローカルの待ち受けポートを奪い合ったり、システムプロキシを繰り返し変更したりすることがあります。

インストールを完了し、コアの動作を確認する

インストーラーの案内に従ってインストールし、スタートメニューから起動します。ポータブル版を使う場合は、先に安定した場所へ展開してください。圧縮ファイルのプレビューから直接起動したり、削除される可能性のある一時フォルダーに長期間置いたりしないでください。初回起動後はステータス画面やログで、コアが繰り返し終了していないか確認します。ウィンドウが開いてもコアの起動に失敗する場合は、エラーに示されたパス、ポート、設定項目を確認してください。接続ボタンを何度も押しても、この種の問題は解決しません。

ネットワークサービスのインストールと通常の画面起動は別の作業です。クライアントがサービスのインストールを求めたら、現在使っているプログラムからの案内か確認し、システムの指示に従って許可します。管理者権限のない業務用端末では、まずシステムプロキシを試してください。組織のポリシーを回避してドライバーやサービスをインストールしてはいけません。セキュリティソフトにブロックされた場合は、イベントの詳細と対象ファイル、入手元を確認してください。保護機能全体を無効にすることを、常に必要なインストール手順にしないでください。アップグレード前に設定フォルダーとオーバーライドの内容を記録し、アンインストール時の削除を通常の更新と取り違えないようにします。

サブスクリプションを追加してシステムプロキシを有効にする

設定またはサブスクリプションの画面でURLからの追加を選び、完全なアドレスを貼り付けて保存し、更新します。ダウンロードに成功したら設定を選択し、プロキシグループで利用可能な出口を選びます。ローカルのYAMLを読み込む場合はファイルのインポート機能を使い、ファイルパスをサブスクリプションURL欄に入力しないでください。QRコードはアドレスの入力方法が違うだけです。読み取った内容の提供元も確認してください。3つの追加方法の違いはURL・QRコード・ローカルYAMLのインポート方法を参照してください。

まずRuleモードのままクライアントのシステムプロキシを有効にし、Windowsのプロキシ設定でアドレスがローカルを指しているか、ポートが実行中の設定と一致しているか確認します。ローカルアドレスには127.0.0.1がよく使われますが、ポートはクライアントに表示される値に合わせてください。ブラウザー拡張機能が独自のプロキシルールを持つことがあります。切り分けの際は、重複して通信を取り込む拡張機能を一時的に無効にし、古いページの接続を閉じてから再アクセスします。ウェブページが開くかどうかだけでなく、クライアントの接続一覧に該当するリクエストがあるかも確認してください。

TUNの権限とよくある競合

システムプロキシに従わないアプリを使う場合は、TUNの有効化を検討します。クライアントの案内に従ってサービスをインストールまたは有効化し、仮想ネットワークインターフェースとルートが正しく作成されたことを確認してください。初回のテストではシステムプロキシを無効にし、TUNだけで通信を取り込む方法を試します。動作確認後、クライアントの推奨に沿って併用してください。有効にした後、すべてのサイトに接続できなくなった場合は、すぐにTUNを無効にし、別のVPN、仮想マシンのネットワークツール、システム全体の通信フィルターが動作していないか確認します。端末が直結で復旧するかどうかは、通信の取り込みと上流ノードのどちらに問題があるかを切り分ける重要な手掛かりです。

netstat -ano | findstr ":7890"
netsh winhttp show proxy

1つ目のコマンドで例示したポートの使用状況を確認できます。出力がある場合は、待ち受け状態とプロセスIDを照合して、どのプログラムが使っているか特定してください。2つ目のコマンドではWinHTTPのプロキシ設定を確認できます。これは現在のユーザーのシステムプロキシとは別の設定です。そのため、結果が直接接続でも、クライアントのシステムプロキシが機能していないとは限りません。表示を揃えるためにWinHTTPを安易に変更しないでください。WinHTTPに依存するアプリがある場合に限って個別に設定し、元に戻す方法も記録しておきましょう。

クライアント終了後もブラウザーでプロキシ接続エラーが出る場合は、Windowsのプロキシ設定にローカルプロキシが残っていないか確認します。スリープ復帰後やネットワーク切り替え後にだけ問題が起きるなら、まず接続を確立し直し、クライアントのサービス状態を確認してから通信の取り込みを再起動してください。設定をすべて削除するのは避けましょう。元のログと失敗したリクエストの時刻を残しておくと、ローカルポート、DNS、ルール、ノードの出口のどこに問題があるかを特定しやすくなります。

macOSへのインストールと権限

macOSダウンロードからClash Plusを選び、「このMacについて」に表示されるチップの種類に合わせてApple Silicon用またはIntel用のインストーラーを選択します。別のクライアントとしてClash Verge RevやFlClashも選べます。ClashX Metaはアーカイブ版です。アプリアイコンやファイル名に「Mac」とあるだけで、アーキテクチャを判断しないでください。別のクライアントに切り替える前に、以前のアプリのシステムプロキシとバックグラウンドサービスを無効にします。古いアプリがネットワーク設定を制御したままでは、新しいアプリが正常に起動しても通信が正しく切り替わらないことがあります。

安定した場所にインストールし、アクセス許可を設定する

ダウンロードしたディスクイメージを開き、アプリを「アプリケーション」フォルダーへドラッグしてから、そのフォルダー内のアプリを起動します。マウントしたイメージから長期間実行しないでください。システムの再起動後やイメージの取り出し後に、ログイン項目や補助プログラムが元の場所を見つけられなくなることがあります。ダウンロード元について警告が出たら、保存場所とアプリの提供元を確認してから、「プライバシーとセキュリティ」で利用できる操作を確認します。セキュリティ属性の削除やシステムの保護機能の無効化を、一般的なインストール方法として扱わないでください。明示された許可の要求と、出所の分からないファイルは別々に判断します。

補助サービス、ネットワーク拡張機能、VPN構成の許可は、システムレベルの変更です。表示される案内はクライアントの実装によって異なります。現在使っているアプリの案内に従って許可したら、システムのダイアログが消えたかだけでなく、クライアントに戻ってサービスの準備が完了したか確認してください。端末管理の制限により、ネットワークコンポーネントをユーザーが許可できない場合があります。その際は管理ポリシーに従ってください。インストールに失敗した場合は、システムに表示されたメッセージ、アプリの保存場所、チップの種類を記録します。同じファイルを再インストールするだけでは、権限の問題が解決しないことがあります。

設定を追加し、使用中のネットワークサービスを確認する

設定管理でサブスクリプションURLを追加し、更新後に項目を有効にして、プロキシグループの出口を選びます。初回はシステムプロキシでブラウザーの接続を確認し、ほかのVPNは無効にしてください。macOSのプロキシ設定はネットワークサービスごとに適用されます。Wi-Fi、Ethernet、ドッキングステーションのネットワークアダプターは、それぞれ異なるサービスとして扱われることがあります。ネットワークを切り替えた後にプロキシが動作しない場合、以前設定したWi-Fiだけでなく、現在利用中のネットワークサービスを確認してください。クライアントにシステムプロキシの自動設定機能がある場合も、現在のサービスに適用されているか確認します。

scutil --proxy
networksetup -listallnetworkservices

scutil --proxyでシステムプロキシの情報を確認でき、もう一方のコマンドでネットワークサービス名を一覧表示できます。確認時は有効状態、プロキシサーバー、ポートがクライアントと一致しているかに注目してください。ターミナルのコマンドラインツールは、システムのプロキシ設定を参照するとは限りません。ブラウザーが使えてコマンドが使えない場合も、ただちにノードの異常とは判断できません。まず対象プログラムが対応するプロキシ方式を確認してから、適切な環境変数やコマンドオプションを使います。HTTPプロキシのアドレスを、対応していない方式の入力欄に指定しないでください。

TUN、スリープ復帰、設定の保持

より多くのアプリの通信を取り込む必要がある場合にTUNを有効にし、クライアントの案内に従って関連サービスを許可します。起動ログに権限不足、デバイス作成失敗、ルート設定失敗が表示された場合は、該当するシステム操作を解決してください。サブスクリプションを何度も入れ替えても解決しません。TUNの確立後はDNSが想定した経路を通っているかも確認します。仮想インターフェースが存在しても、名前解決が正しいとは限りません。企業VPN、仮想化ソフト、ほかのネットワーク拡張機能が同時にルートを変更していることもあります。原因を特定しやすくするため、テスト時は必要なコンポーネントだけを有効にしてください。

設定変更時は、サブスクリプションの元ファイルと実行時に生成されるファイルを区別してください。前者はサブスクリプション更新で置き換わり、後者は起動のたびに再生成されることがあります。どちらを直接編集しても、変更が長期間保持されるとは限りません。クライアントの永続化に対応したオーバーライド機能を使い、適用後に最終的な設定を確認してください。アップグレード前にはサブスクリプションの参照元、オーバーライドの内容、必要なローカルルールをバックアップします。サブスクリプションURLは機密情報として扱い、設定フォルダー全体を公開リポジトリへ同期しないでください。

アンインストールやクライアントの切り替え前に、システムプロキシとTUNを無効にしてからアプリを終了します。アプリをゴミ箱に移動しただけでは、許可済みのネットワーク構成やバックグラウンドの補助コンポーネントが削除されないことがあります。クライアントにサービスの削除機能がある場合はそれを使い、システムのネットワーク設定に残りがないか確認してください。直結に戻したことを確認してから別のクライアントを起動すると、2つのプログラムがプロキシの状態を上書きするのを防ぎ、新しい問題がどの段階で発生したかも判断しやすくなります。

Androidへのインストールとバックグラウンド動作

Androidダウンロードでは、まずClash Plusを選んでください。設定との互換性に応じてClash Meta for Android、FlClash、Surfboardも選べます。最近の端末は通常ARM64ですが、実際のアーキテクチャとインストーラーの説明を確認してください。古い端末では別のアーキテクチャやユニバーサル版が必要な場合があります。異なるファイルを次々にインストールして確認するのではなく、先に端末の仕様を確認しましょう。既存アプリとの競合が表示されたら、アプリ名、入手元、署名に関する案内を確認し、設定をバックアップしてから入手元の変更を検討してください。

インストール許可とローカルVPNの仕組み

ブラウザーやファイル管理アプリからインストーラーを開くと、その入手元からのアプリインストールを許可するよう求められることがあります。実際に使用する入手元だけを許可し、インストール後は元の制限に戻せます。インストールに失敗した場合は、空き容量、OSの互換要件、異なる署名のアプリを上書きしようとしていないかを確認してください。アンインストールするとアプリの専用データが消えるため、サブスクリプションやオーバーライドをバックアップせずに最初の対処として削除しないでください。ローカルのYAMLも識別しやすいフォルダーに別途保存し、ダウンロードファイルの整理時に一緒に削除しないようにします。

初回のプロキシ接続時に、AndroidはVPN接続の許可を求めます。これはシステムのインターフェースを通じて、アプリがローカルの仮想ネットワーク経路を作成するための許可です。サブスクリプション提供元の設定が成功したことを意味するものではありません。スマートフォンのほかのVPN、一部のファイアウォールやネットワークフィルターアプリも同じシステム機能を使うため、通常は同時に独立して動作できません。別のアプリが切断された場合は、まず既存のVPNの状態を確認してください。Clashが強制終了した、またはノードが不安定だと誤解しないようにしましょう。

サブスクリプションの有効化とアプリごとの適用範囲

設定一覧でリモートサブスクリプションを追加し、名前と完全なURLを入力します。更新に成功したら有効な設定に切り替え、プロキシグループで出口を選択してください。QRコードで追加する場合は、読み取り結果が想定したサブスクリプションURLか確認します。URL全体が写ったスクリーンショットをそのまま公開しないでください。追加できても利用可能なプロキシグループが一覧にない場合、サブスクリプションにノード情報しか含まれていないか、クライアントのテンプレートが必要な可能性があります。Surfboardの設定形式とClash YAMLは同等ではありません。クライアントを切り替える前に、提供元が対応形式を配信しているか確認してください。

接続を開始したら、まずブラウザーでリクエストを1つ試し、接続ログを確認します。モバイルでは通常VPN経由で通信を取り込むため、デスクトップのシステムHTTPプロキシの手順をそのまま使う必要はありません。アプリごとのプロキシ設定がある場合は、「選択したアプリのみ」と「選択したアプリを除外」のどちらが有効か確認してください。意味が逆のため、選択を誤るとブラウザーは使えても対象アプリの通信が記録されません。適用範囲を変更したら対象アプリを完全に終了して再起動し、新しい接続を開始させます。既存のセッションはすぐに切り替わらないことがあります。

バッテリー制限、ネットワーク切り替え、自動起動

画面ロック後に接続が切れ、画面を点灯すると復旧する場合は、バックグラウンド動作、バッテリー使用、自動起動に関するシステム制限を優先して確認します。設定画面の場所はメーカーによって異なるため、アプリ情報から関連項目を探し、必要な範囲でクライアントの継続動作を許可してください。バックグラウンドのタスクロック、通知表示、バッテリー最適化は別の仕組みです。1つを有効にしただけで、ほかの制限も解除されたとは限りません。すべてのアプリの制限を一律に緩めず、バックグラウンドからの終了が原因かを確認してから、プロキシクライアントだけを調整しましょう。

Wi-Fiからモバイルネットワークへ切り替えると既存の接続が切れ、アプリがセッションを再確立することがあります。モバイルネットワークでのみ失敗する場合は、アプリのモバイルデータ通信が禁止されていないか、サブスクリプションの更新が現在のネットワークに依存していないか、ノードのプロトコルがそのネットワークで使えるか確認します。AndroidのプライベートDNSとクライアントのDNS設定が同時に名前解決に関与することがあります。ドメインに問題がある場合は両方の状態を記録し、一度に1項目だけ変更して比較してください。すべての名前解決機能を同時に無効にするのは避けましょう。

アプリの通信問題を調べる際は、まずプロキシの適用対象かを確認し、該当ドメインの接続が記録されているかを見ます。記録があり出口が違う場合はルールを確認し、出口が正しいのに失敗する場合はノード、DNS、アプリ側のネットワーク要件をさらに調べます。遅延値が正常でも、実際の通信に制限がないとは限りません。サブスクリプションの更新失敗はプロキシ接続の失敗と分けて考えます。原因はサブスクリプション更新の失敗と自動更新の設定を参照し、有効な設定を何度も削除して作り直さないようにしましょう。

iOSへのインストールとVPN設定

iOSではClash Plusを利用できます。App StoreのClash Plusページからインストールしてください。製品情報は公式サイトのclashplus.ioで確認できます。インストール前にストアの対応端末要件と、端末の空き容量を確認してください。アプリのインストールとネットワークプロキシの有効化は別の手順です。初回起動時は、設定管理と接続画面の場所を確認しましょう。有効なサブスクリプションがない状態で、システムVPNの構成を何度も許可したり削除したりしないでください。

サブスクリプションを追加して設定を有効にする

クライアントに対応したサブスクリプションURLを用意し、設定管理のリンク追加から登録します。貼り付け後、URLの前後に空白や改行、チャットアプリが付けた句読点が入っていないか確認してください。アカウント情報を含むURLは、省略せずそのまま保持します。更新に成功したら設定を選び、想定どおりプロキシグループが表示されるか確認してから、利用可能な出口を選びます。YAMLをファイルから追加する場合は、クライアントのファイル選択または共有機能を使います。読み込み後に設定を有効にしてください。スマートフォンにファイルを保存しただけでは、クライアントで使われているとは限りません。

サブスクリプションURLとノード共有URLは、形式が異なることがあります。単一のノード情報には完全なルールやプロキシグループが含まれない場合があるため、すべての追加方法を相互に置き換えられるテキスト欄として扱わないでください。提供元が専用のクライアントリンクを案内している場合は、最終的にどの設定形式になるかを確認します。ダウンロードに失敗したら、URLにアクセスできないのか、内容が非対応なのか、サブスクリプションが無効なのかを切り分けてください。RuleとGlobalを何度切り替えても、サーバーが返すファイル内容は変わりません。ログイン画面を設定として読み込んでしまった問題も解決しません。

VPNを許可して実際の出口を確認する

初めて接続する際は、システムの案内に従ってVPN構成の追加を許可し、端末で求められる認証を完了します。この許可によってクライアントがシステムのネットワーク経路を作れるようになりますが、すべてのドメインが必ずプロキシを通るわけではありません。アプリでRuleモードを維持したままテストサイトにアクセスし、接続履歴で適用ルールと出口を確認します。ステータスバーやシステム設定にVPN接続中と表示されても、確認できるのは経路が接続状態にあることだけです。設定のルールが直結を選んでいる場合や、選択したノードが対象のリクエストを処理できない場合もあります。

企業VPN、ほかのプロキシアプリ、ネットワークフィルターを併用している場合は、現在どの構成が接続を確立しているかを確認します。切り替える際は元の接続を終了してからClash Plusを起動し、システムの状態を誤って判断しないようにしてください。ネットワークの変化に応じて元の構成を再接続するシステム動作もあるため、VPN設定もあわせて確認します。管理対象端末ではネットワークポリシーにより設定変更が制限される場合があります。端末管理の構成を削除して個人用プロキシを復旧させようとせず、管理要件に従ってください。

バックグラウンド動作、DNS、ローカルネットワークへのアクセス

iOSではネットワーク拡張機能とアプリ画面は別々に動作します。アプリを閉じてもプロキシが必ず停止するわけではなく、タスク一覧にアプリが残っていても接続が有効とは限りません。現在のVPN状態と、新しく発生した接続の記録をもとに判断してください。切断を防ぐために画面を開いたままにするのではなく、サブスクリプションの更新エラー、拡張機能の終了、ネットワーク切り替えの有無を確認します。モバイルデータ通信が制限されている場合は、Wi-Fiだけで何度も試すのではなく、クライアントの実際の動作も確認してください。

LAN上の端末、プリンター、ローカルサービスにアクセスできない場合は、宛先アドレスがプロキシルールに一致しているか、クライアントにLAN通信の除外や関連ルートの設定があるかを確認します。直結ルールを追加する前に、対象ネットワークの範囲を確認してください。見慣れないアドレス範囲全体を直結にしないでください。ドメインを解決できても端末に接続できない場合、ローカルネットワークへのアクセス許可、宛先ポート、LAN内の分離設定が原因のこともあります。ウェブページを開けるかどうかだけで判断せず、変更のたびに接続し直して実際に適用されたルールを確認してください。

自動更新の間隔は、サブスクリプション提供元の要件とクライアントの対応状況に合わせて設定します。モバイルOSのバックグラウンド処理はシステムのスケジュールに左右されるため、間隔を指定しても毎回その時刻に更新が完了するとは限りません。外出前に手動で更新し、設定を引き続き有効にできるか確認してください。切り替え前に利用可能な設定も残しておきます。接続後も特定のアプリが使えない場合は、「新しいリクエストが記録されているか」「ルールが正しいか」「出口が利用可能か」の順に確認し、すぐに再インストールしないでください。詳しい動作確認手順は初回接続とプロキシの動作確認を参照してください。

Linuxデスクトップとコアの導入

LinuxデスクトップではClash Verge RevとFlClashを、サーバーやルーターではmihomoコアを確認してください。GUIクライアントには通常、設定、トレイ、サービス管理が統合されています。コアを単体で実行する場合は、設定ディレクトリ、プロセス管理、ログ、通信の取り込みを自分で用意する必要があります。GUIクライアントが管理するファイルと手動で配置したファイルを同じディレクトリに混在させず、2つのコアで同じアドレスとポートを同時に待ち受けないようにしてください。

アーキテクチャとインストール依存関係を確認する

uname -mでプロセッサのアーキテクチャを確認し、ディストリビューションに合ったパッケージ形式を選びます。DebianやUbuntuなどでは通常debパッケージを、RPM系のディストリビューションでは対応するパッケージを使います。形式が同じでも、実行に必要な依存関係がすべて同じとは限りません。ダウンロードページにないアーキテクチャを、ファイル名の変更で対応させようとしないでください。ディストリビューションのパッケージマネージャーでローカルパッケージをインストールすれば、依存関係の問題を明確に確認できます。コンポーネントが不足している場合は、現在のシステムのリポジトリから解決し、別のディストリビューションの動的ライブラリを安易にコピーしないでください。

GUIアプリが起動しない場合は、ターミナルから該当プログラムを実行してエラー出力を確認し、ディスプレイ環境、デスクトップ統合、コア設定のどこに問題があるかを切り分けます。リモートのSSHセッションには完全なデスクトップ環境がないため、デスクトップクライアントの手順をそのまま使うのには適しません。サーバーでは通常、コアと必要なアプリのプロキシ設定だけで足ります。TUNが必要かどうかは通信の取り込み範囲で決まり、導入成功の必須条件ではありません。システムサービスをインストールする前に実行ユーザーと設定パスを決め、一時ダウンロードフォルダーに依存しないようにしてください。

GUIクライアントの設定追加とデスクトッププロキシ

GUIクライアントでサブスクリプションを追加し、更新して有効化した後、プロキシグループの出口を選びます。システムプロキシを有効にしても、GNOME、KDE、個々のアプリがプロキシ設定を参照する方法は異なる場合があります。デスクトップのスイッチ1つですべてのターミナルアプリに設定が反映されるとは限りません。まずブラウザーの通信が接続一覧に記録されるか確認し、プロキシが必要なコマンドラインツールは個別に設定してください。標準的な環境変数に対応するアプリでは、現在のシェルに一時的に設定し、動作を確認してから永続設定への追加を検討します。

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

上の例では、ローカルのHTTPプロキシまたは混合プロキシが、例示したポートで実際に待ち受けている必要があります。https_proxyのHTTPアドレスは、プロキシへの接続に使うプロトコルを示すもので、宛先のHTTPSを通常のHTTPに変えるという意味ではありません。環境変数の名前や大文字・小文字、SOCKSへの対応はプログラムごとに異なるため、各プログラムの説明を確認してください。新しいターミナルや起動済みのサービスに、後から設定した変数が自動で反映されることはありません。ブラウザー、ターミナル、システムサービスをそれぞれ確認し、1か所のテストだけで全体に反映されたと判断しないでください。

コア単体の利用、権限、サービスの範囲

mihomoを単体で使う場合は、アーキテクチャに合ったコアを展開し、専用の設定ディレクトリを用意して、実際に使用する設定をその中のconfig.yamlとして保存します。以下のコマンドは、実行ファイルが現在のディレクトリにあり、設定をユーザーのホームディレクトリ内のmihomo-configに置いたことを前提としています。まず構文を確認し、前景で起動してログを監視します。待ち受けが正常なことを確認してから、サービス管理ツールでの起動を検討してください。構文が正しくても、ノード、ルールの参照先、リモートリソースにアクセスできるとは限りません。

chmod +x ./mihomo
./mihomo -t -d "$HOME/mihomo-config"
./mihomo -d "$HOME/mihomo-config"

systemdサービスを作成する場合は、安定した絶対パスを使い、作業ディレクトリ、実行ユーザー、再起動ポリシーを明確にします。通常のローカルプロキシに管理者権限が必要とは限りませんが、TUNインターフェースの作成、ルート変更、DNSの取り込みには適切な権限やケーパビリティが必要な場合があります。手間を省くためにGUI全体をrootで実行しないでください。サービスの起動に失敗したら、サービスのログを確認し、設定ディレクトリの権限とリソースファイルのパスを重点的に調べます。前景で起動できても、別のサービスユーザーから同じファイルを読めるとは限りません。

TUNを有効にした後は、デフォルトルート、DNSの管理方法、ほかのVPNの状態を確認します。NetworkManager、systemd-resolved、クライアントがそれぞれネットワークの一部を管理している場合があります。DNSの設定ファイルを直接上書きすると、再接続後に変更が失われることがあるため、まずDNSの管理元を特定し、対応する連携方法を使ってください。サーバーではファイアウォールも確認します。ローカルプロキシやコントロールインターフェースは通常ローカル利用向けです。遠隔操作を簡単にするためにインターネットへ公開しないでください。サービスを停止したら、ルートと名前解決が元に戻ったことを確認してから、次の通信取り込みをテストします。

設定の確認と問題の切り分け

再現できる失敗リクエストを1つ起点に調査します。対象ドメイン、発生時刻、使用中の設定、通信の取り込み方式を記録し、リクエストがコアに届いているか確認してください。接続記録がない場合は、システムプロキシ、アプリ内プロキシ、TUNの適用範囲を調べます。記録はあるものの出口が違う場合は、ルールの順序とプロキシグループを確認します。出口が正しいのにリクエストが失敗する場合は、ノード、名前解決、接続先のサービスを調べてください。サブスクリプションの更新だけが失敗し、以前の設定が使えるなら、まずサブスクリプションの取得経路を確認します。両方の問題を「インターネットに接続できない」と一括りにしないでください。

ポート設定とコントロールインターフェース

mixed-portはHTTPとSOCKSの両方のプロキシリクエストを受け付ける待ち受けポートです。external-controllerはコントロールインターフェースであり、通常のプロキシ用ポートではありません。ブラウザーにコントロールインターフェースを指定するとエラーになります。プロキシモードを変更しても解決しません。以下は確認用の基本設定です。適用する際は完全な設定に統合してください。この例には直結の出口しかなく、プロキシノードはありません。ポート番号は例です。すでに使用中の場合は、実行設定、システムプロキシ、アプリ内プロキシの3か所を一貫して変更してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: LOCAL
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,LOCAL
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

待ち受けアドレスとLANからのアクセス許可はセキュリティ境界であり、速度を上げるための設定ではありません。自分の端末だけで使う場合は、ループバックからのアクセスに限定してください。信頼できる端末にプロキシを提供する必要がある場合も、バインドアドレス、認証、ファイアウォール、接続先のネットワークを確認します。コントロールインターフェースは、管理画面に接続できないからといって、すべてのネットワークインターフェースに公開してはいけません。待ち受けポートが競合したら、使用中のプロセスを特定して古いコアか確認してから、停止またはポート変更を判断します。正体の分からないシステムプロセスを安易に終了しないでください。

ルールの順序、DNS、Fake-IP

ルールは通常、上から順に評価されます。具体的なルールは関連するフォールバックルールより前に置き、MATCHは末尾に配置します。ルールが参照するプロキシグループ名は、実際に存在している必要があります。大文字・小文字やスペルも一致させてください。サブスクリプションにノードが含まれていても、ルールが自動的にそのノードを使うとは限りません。最終的な出口は、一致したプロキシグループと、そのグループで選択中のノードによって決まります。変更後は対象の接続を確立し直してください。既存の長時間接続は以前の出口を使い続けることがあります。手順はルールによる振り分けの設定を参照してください。

Fake-IPは予約済みアドレスとドメインの対応関係を作り、ルール判定にはコアが保持するドメイン情報が使われます。よく見かけるグローバルIPではないアドレスが返ってきたというだけで、名前解決に失敗したとは判断できません。互換性の問題がある場合は、対象ドメインを適切なフィルター設定に追加し、現在のコアが使っているフィルターモードを確認します。出所の分からないリストを大量にコピーしないでください。システムキャッシュ、ブラウザー独自の名前解決、クライアントのDNSがそれぞれ別の経路を使うことがあります。切り分けでは一度に1項目だけ変更します。詳しい仕組みはFake-IPによるDNSマッピングの解説を参照してください。

GeoIPの更新と設定の上書き

まず設定が従来のGeoIPデータファイルを使うのか、geodataモードを有効にしているのかを確認します。モードによって必要なリソースやパスは異なります。画面上の更新操作が現在使用中のデータを上書きするかどうかは、ログと実行中の設定で確認してください。GeoIPを更新しても、すべてのルールの問題が解決するわけではありません。ドメインルールのほうが先に一致することがあり、ルールセットには独自の更新間隔がある場合もあります。マッチ条件の書き方によって、名前解決を行うかどうかも変わります。データベースの読み込みに失敗したら、ダウンロードの完了状況、ディレクトリの権限、設定パスを確認し、再起動を繰り返すだけで済ませないでください。

リソースの更新とサブスクリプションの更新は、別々に記録してください。リモートルールセットの更新に失敗した場合は、取得経路とキャッシュが使えるかを先に確認します。サブスクリプションを置き換えても、ルールセットの状態が変わるとは限りません。長期的に保持するカスタムルールはオーバーライド設定に記述し、サブスクリプションの更新後に実行中の設定へ反映されているか確認します。YAMLではスペースでインデントし、リスト、キー名、階層構造を正しく保ってください。構文チェックに通った後も起動ログを確認し、リモート参照先とルールグループが実際に読み込まれたことを確かめます。

変更後にネットワークへまったく接続できなくなった場合は、現在の通信取り込みを無効にして直結で接続できる状態へ戻し、最後に変更した項目を元に戻します。手順全体は接続済みなのにウェブページを開けないときのチェックリストを、一般的な質問はよくある質問を参照してください。復旧後は直結とプロキシの両方で再確認し、ブラウザーキャッシュや以前からの接続が一時的に使えただけではないことを確かめます。