ALL-PLATFORM SETUP / MIHOMO

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

クライアントの選択、サブスクリプションの取り込み、システムプロキシ、TUN、DNSまで、Windows、macOS、Android、iOS、Linuxの設定手順を章ごとにまとめています。

継続的に参照できる体系的なマニュアルです。初めて使う方や、まず一度だけ接続を完了したい方は、はじめにの短い手順から確認してください。プラットフォームの権限、ポート競合、DNS異常、ルールの挙動差が気になる場合は、このページの該当章に戻って確認します。

クライアントのインストーラーはクライアントダウンロードページから入手できます。各プラットフォームではまずClash Plusを推奨しつつ、Clash Verge Rev、FlClash、Clash Meta for Android、ClashX Metaなど、システムに応じた選択肢も用意しています。このページでは固定バージョン番号を記載していません。画面上の名称はクライアントの更新で変わる場合がありますが、設定対象と判断方法は変わりません。

PLATFORMS
Windows / macOS / Android / iOS / Linux
CORE
mihomo
CONFIG
YAML / Subscription / RULE-SET

CHAPTER INDEX

CHAPTER 01 / PREPARATION

共通の準備：クライアント、サブスクリプション、権限の範囲

まずクライアント、カーネル、サブスクリプションを区別する

Clash Metaの実際の通信経路は、3つの要素で構成されます。mihomoはプロトコル接続、ルール照合、DNS処理、トラフィック転送を担うカーネルです。Clash Plus、Clash Verge Rev、FlClashなどはカーネルを管理するGUIクライアントです。サブスクリプションはサービス提供者が生成するリモート設定で、通常はプロキシノード、プロキシグループ、基本ルールが含まれます。クライアントをインストールしただけでは利用可能な回線は用意されず、サブスクリプションURLもインストーラーではありません。両者を別々に入手し、クライアント内で組み合わせる必要があります。

クライアントを選ぶときは、まずOSとプロセッサーのアーキテクチャを確認します。Windowsの一般的なPCではx64版を使用します。ARMプロセッサー搭載機では、対応ビルドが提供されているか確認してください。macOSではIntelとApple Siliconを区別します。Androidのインストールパッケージはarm64、arm、ユニバーサル版などに分かれる場合があります。最近の端末は通常arm64ですが、判断できない場合はダウンロードページにあるユニバーサル版を選びます。Linuxではディストリビューションのパッケージ形式、CPUアーキテクチャ、デスクトップ環境の有無も確認が必要です。

GUIクライアントは、日常的なデスクトップやモバイル端末での利用に適しています。mihomoカーネルを直接使う方法は、サーバー、ルーター、コンテナ、自作のサービス管理スクリプトが必要な環境に向いています。両方式の基本的な設定解釈は近いものの、GUIクライアントではシステムプロキシ、TUN、設定のオーバーライド、サブスクリプション更新が個別のスイッチとしてまとめられている場合があります。トラブル対処では、問題が画面層、カーネル層、上流のサブスクリプションのどこで起きているかを切り分け、原因に触れないまま再インストールを繰り返さないことが重要です。

取り込み前にサブスクリプションの応答内容を確認する

サブスクリプションURLはサービス提供者の管理ページからコピーし、チャット画面で改行されたアドレスを手作業で切り取らないでください。URLにはアクセス資格情報が含まれることが多いため、機密情報として扱い、公開画像、コードリポジトリ、共有ドキュメントに載せないようにします。取り込みに失敗した場合は、まずシステムブラウザでURLへ直接アクセスします。YAMLテキストが表示されるか設定ファイルのダウンロードが始まれば、少なくともURLには到達できます。ログイン画面、期限切れの通知、アクセス拒否、空の応答が表示される場合は、先にサブスクリプション側の問題を解決します。

同じサービスからClash YAML、汎用共有リンク、他クライアント向け形式が同時に提供される場合があります。mihomoクライアントでは通常、Clashまたはmihomo互換の設定が必要です。形式を間違えると、解析エラーが出るだけでなく、取り込み後にノードだけが表示され、プロキシグループがないこともあります。形式を変更する前に、まだ使える旧設定を削除しないでください。新しい設定には別名を付け、プロキシグループ、ルール、DNSセクションが揃っていることを確認してから置き換えます。

復元可能な設定の基準を作る

初回起動後はデフォルトのポートと動作モードを維持し、設定を1つだけ取り込み、プロキシノードを1つ選んでブラウザ接続をテストします。この順序なら基準状態を作れます。デフォルト状態で動作していれば、その後の障害はTUN、オーバーライドルール、DNS、複数設定の同時有効化などが原因である可能性があります。初回テストでシステムプロキシ、TUN、LAN共有、カスタムDNSを同時に有効にしないでください。異常が起きた際に、どの層が通信経路を変えたのか分からなくなります。

システムプロキシとTUNは同じ入口ではありません。システムプロキシは通常、OSのプロキシ設定に従うアプリだけに作用し、HTTPまたはSOCKSポートを利用します。TUNは仮想ネットワークインターフェースを作成し、システムプロキシを参照しないプログラムも広く取り込めます。モバイルOSのVPNスイッチは、通常TUNに近い役割を担います。両者は用途に応じて使い分けられますが、日常のデスクトップ閲覧ではまずシステムプロキシを使い、ゲーム、コマンドラインツール、挙動が異なるアプリで必要に応じてTUNを検討します。

対象 主な役割 優先確認項目
GUIクライアント 設定、カーネル、システムプロキシ、画面状態を管理 システムアーキテクチャ、権限、現在の設定
mihomoカーネル プロトコル接続、ルール、DNS、トラフィック転送を実行 設定構文、待受ポート、実行ログ
サブスクリプション設定 ノード、プロキシグループ、ルールを提供 URLへの到達性、形式、更新日時
システムのネットワーク入口 アプリの通信をクライアントへ渡す システムプロキシ、VPN/TUN、その他のネットワークツール

CHAPTER 02 / WINDOWS

Windows：インストール、システムプロキシ、TUNによる通信の取り込み

インストールと初回起動

WindowsユーザーはWindowsダウンロード欄からClash Plusを選ぶか、画面の使い勝手に応じてClash Verge Rev、FlClash、Clash Nyanpasuを利用できます。Clash for Windowsはメンテナンスが終了しており、アーカイブ用途の選択肢です。ダウンロード前に「設定 → システム → バージョン情報」でシステムの種類を確認します。一般的なIntel・AMD搭載PCでは通常x64ビルドを選びます。インストーラー版とポータブル版ではデータディレクトリの場所が異なる場合があります。設定を長期保存する場合は、インストール後にポータブル版のディレクトリを不用意に移動しないでください。

初回起動時にWindowsセキュリティセンターやファイアウォールの確認が表示された場合は、利用範囲に応じて許可します。このPCだけで使うなら、プロキシ機能のためにパブリックネットワークへのアクセスを許可する必要はありません。LAN上の端末から本機のポートへ接続する場合のみ、該当するプライベートネットワークへのアクセスを検討します。ウィンドウを閉じた後もタスクトレイに常駐するかは設定によって異なります。動作中かどうかは、ウィンドウが消えたかではなく、タスクトレイのアイコンやタスクマネージャーで確認してください。

インストーラーがディレクトリに書き込めない場合は、まずダウンロードファイルがローカルに完全に保存されていることを確認し、ユーザーに書き込み権限のある場所で実行します。管理者権限は、ドライバーのインストール、サービス登録、TUNインターフェース作成などに使います。「常に管理者として実行」をあらゆる障害の標準対処にしないでください。通常のシステムプロキシモードでは継続的な管理者権限は不要で、過剰な権限はプログラムとブラウザの実行境界を変えることがあります。

サブスクリプションを取り込み、設定の有効化を確認する

クライアントの設定、サブスクリプション、Profilesページで「URLから取り込む」入口を探し、URLを貼り付けて識別しやすい名前を付けます。取り込み完了後は、その設定を明示的に選択してください。リストに表示されただけでは読み込み済みとは限りません。続いてプロキシまたはProxiesページを開き、少なくとも1つのプロキシグループがあることを確認し、最終出口のグループでノードを選びます。ノード一覧だけが表示され、一般的な選択グループがない場合は、サブスクリプション形式が不完全か、正しい設定が読み込まれていない可能性があります。

選択が終わったら、まずシステムプロキシを有効にします。Windowsのシステムプロキシには、ローカルループバックアドレスを指すプロキシサーバーが表示され、ポートはクライアントの現在の待受値と一致するはずです。サブスクリプションのサーバーアドレスをWindowsのシステムプロキシへ直接入力しないでください。システムプロキシの接続先はローカルのクライアントであり、クライアントが設定に従って遠隔サーバーへ接続します。テスト時はブラウザを新しいウィンドウで開き、以前の経路を再利用しないようにします。クライアントを終了するとウェブも見られなくなる場合は、システムプロキシが残っていないか確認してください。

ポートの代表的なフィールドにはport、socks-port、mixed-portがあります。GUIクライアントでは通常、mixedポートでHTTPとSOCKSの両方を受け付けます。他のプログラムがポートを使用していると、ログに待受失敗が記録されます。クライアントは起動済みに見えても接続を処理できないことがあります。その場合は、まず同種のプロキシソフトを終了し、未使用のローカルポートへ変更したうえで、システムプロキシの接続先が自動更新されているか確認します。

TUNを有効にするタイミング

一部のゲームプラットフォーム、コマンドラインプログラム、ストアアプリ、独自のネットワークスタックを持つソフトは、Windowsのシステムプロキシを読み取りません。ブラウザは使えるのに特定のプログラムだけが常に直接接続する場合は、TUNを有効にできます。初回有効化では仮想ネットワークアダプターやサービスのインストールが必要になることがあるため、クライアントが明示的に求めるシステム権限を許可します。有効化後は、ログでインターフェースの作成成功を確認し、システムのルーティングテーブルに対応する経路が現れているかも確認してください。画面上のスイッチだけを見て判断してはいけません。

TUNは、他のVPN、仮想マシンのネットワークアダプター、ネットワーク高速化ツール、企業向けセキュリティソフトと同時にルートを変更することがあります。テスト中は通信を取り込むツールを1つだけ残し、基本接続を確認してから順番に戻します。TUN有効化後にLAN共有、プリンター、社内ネットワークが使えなくなった場合は、ルールでプライベートアドレスをDIRECTにしているか、実際に使う社内ネットワークのセグメントがバイパスリストに含まれているか確認します。TUNを無効にした後は、インターフェースと古い接続が解放されるまで待ってから再テストしてください。

netsh winhttp show proxy
ipconfig /flushdns
netstat -ano | findstr LISTENING

CHAPTER 03 / MACOS

macOS：アーキテクチャの選択、ネットワークサービス、システム拡張

Apple Silicon版とIntel版を選ぶ

macOSではダウンロード前に「このMacについて」を開き、チップ情報を確認します。Appleチップと表示された場合はApple Siliconまたはarm64ビルドを、Intelプロセッサーと表示された場合はx64ビルドを選びます。macOSダウンロード欄ではClash Plusを優先して選べます。Clash Verge RevやFlClashも利用できます。ClashX Metaはメンテナンスが終了しているため、既存の設定を一時的に引き継ぐ環境に適しています。アーキテクチャを間違えると起動できない、または変換レイヤー経由で動作して挙動に差が出る場合があります。

ダウンロード後はアプリを「アプリケーション」フォルダへ移動し、その場所から起動します。ダウンロードしたディスクイメージや一時ディレクトリから直接実行すると、更新、データディレクトリ、権限の状態が不安定になることがあります。ネットワーク経由で入手したアプリを初めて開くときはセキュリティ確認が表示されます。本サイトのダウンロード入口から案内されたクライアントであることを確認してください。開くのをブロックされた場合は、「システム設定 → プライバシーとセキュリティ」でブロック履歴を確認し、システムが用意した明確な入口から許可します。

クライアントのデータディレクトリは通常、ユーザーのライブラリ内にあります。アプリ本体をアンインストールしても、サブスクリプションや設定が同時に削除されるとは限りません。クライアントを変更する前に、サブスクリプションの取得元、現在のポリシー、カスタムオーバーライドを記録してから旧クライアントを終了します。2つのクライアントで同時にシステムプロキシを設定しないでください。後から起動したプログラムがプロキシポートを上書きし、終了時にすでに無効な別の値へ戻すことがあります。

システムプロキシとネットワークサービス

macOSのシステムプロキシはネットワークサービスごとに保存されます。Wi-Fi、有線ネットワーク、その他のインターフェースでは設定が別々の場合があります。クライアントでシステムプロキシを有効にすると、通常は現在のサービスにWebプロキシ、安全なWebプロキシ、SOCKSプロキシが設定されます。Wi-Fiから有線接続へ切り替えた後に状態が崩れた場合は、新しいネットワークサービスもクライアントに引き継がれているか確認します。企業ネットワークの自動プロキシ設定ファイルが手動設定と併存することもあるため、どちらを有効にするかを先に決めてください。

プロキシ状態はシステムのネットワーク詳細で確認でき、コマンドで現在の設定を読み取ることもできます。プロキシサーバーは127.0.0.1などの本機ループバックアドレスで、ポートはクライアントと一致している必要があります。クライアント終了後にネットワークが切れる場合は、クライアントを再起動してシステムプロキシを無効にするか、システム設定で残った項目を削除します。アプリだけを削除してシステムプロキシを戻さないと、ブラウザが待受プログラムのないローカルポートへリクエストを送り続けます。

scutil --proxy
networksetup -listallnetworkservices
lsof -nP -iTCP -sTCP:LISTEN

ターミナルのcurl、パッケージマネージャー、開発ツールは、GUIのシステムプロキシに完全には従わないことがあります。一時的にテストする場合は、現在のターミナルセッションだけにプロキシ環境変数を設定し、テスト後に削除します。ポートはクライアントの実際のmixedポートに置き換えてください。例の値を固定値として扱わないようにします。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

curl -I https://example.com

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

TUN、システム拡張、ローカルネットワーク

システムプロキシを読み取らないアプリも取り込みたい場合は、クライアントでTUNを有効にします。macOSでは管理者資格情報の入力、ネットワーク拡張の許可、VPN構成の追加を求められることがあります。権限はシステムのダイアログに表示された対象を1つずつ確認して許可してください。以前に拒否した場合は、「プライバシーとセキュリティ」、ネットワーク拡張、VPN設定を再確認します。スイッチはオンなのにインターフェースを作成できない場合、ログには通常、権限、サービス、ルートに関するエラーが記録されています。

macOSで企業VPN、コンテナネットワーク、仮想マシンソフトを同時に動かすと、複数の仮想インターフェースがデフォルトルートやDNSを奪い合うことがあります。まず他の通信取り込みツールを終了し、Clashだけを動かした結果を確認してから、必要なソフトを戻します。社内ネットワークが指定DNSや検索ドメインに依存している場合、TUNのDNS取り込みで名前解決経路が変わることがあります。社内ドメインとネットワークセグメントをDIRECTルールに追加し、内部名を解決できるサーバーで問い合わせるようにします。

LANアクセスに異常がある場合、すべてのプライベートアドレスをプロキシへ送らないでください。家庭用ルーター、プリンター、ファイル共有、開発機器は通常DIRECTにします。設定のallow-lanは他の端末が本機のプロキシポートへ接続できるかを制御するもので、本機からLANへアクセスできるかは決めません。LANをDIRECTにするかどうかは、主にルールとルートで決まります。プロキシを共有する明確な必要がある場合だけLAN待受を有効にし、システムファイアウォールでネットワーク範囲を制限してください。

CHAPTER 04 / ANDROID

Android：アプリのインストール、VPNによる通信取り込み、バックグラウンド動作

インストールとサブスクリプションの取り込み

AndroidではAndroidダウンロード欄からClash Plusを優先して選べます。Clash Meta for Android、FlClash、Surfboardも利用できます。パッケージがアーキテクチャ別の場合、最近の主流端末は通常arm64です。古い端末ではarmビルドが必要なことがあります。アーキテクチャが分からない場合は、クライアントが提供するユニバーサル版を優先してください。インストール時にブラウザやファイルマネージャーからのアプリインストールを許可するよう求められた場合は、今回使う提供元だけに権限を付与し、完了後は必要に応じて無効にします。

初回起動後、設定ページでURLからの取り込みを選び、サブスクリプションURLを貼り付けて解析を待ちます。モバイルネットワークでは初回リクエスト時に短い切り替えが起きることがあるため、取り込みに失敗したらWi-Fiとモバイルデータの両方で試します。設定のダウンロードが成功しても、それをアクティブ設定に指定し、プロキシグループでノードを選ぶ必要があります。設定名が表示されるだけではVPN接続済みとはいえません。ステータスバーにVPNアイコンが表示され、クライアントのログで接続処理が始まって初めて通信の取り込みが確立します。

QRコードで取り込む場合は、その内容が単一ノードの共有リンクではなく、サブスクリプションURLであることを確認します。単一ノードのリンクは認識されることがありますが、通常は完全なルールやプロキシグループを含みません。スキャンにはカメラ権限、アルバムから読み取る場合は写真へのアクセス権限が必要です。これらの権限を与えたくない場合は、URLを直接コピーする方が分かりやすい方法です。取り込み後は、サブスクリプションQRコードを含む一時的なスクリーンショットを削除し、写真の同期先に長く残さないようにします。

Android VPNとアプリごとのルーティング

Androidクライアントは通常、システムVPNインターフェースを通じて通信を取り込みます。初回接続時にはシステムのVPN許可画面が表示され、確認後にクライアントがインターフェースを作成できます。システム上、通常のVPNは同時に1つしか有効にできないため、他のVPN、フィルタリングツール、ローカルVPNインターフェースを使うファイアウォールは切断されます。接続ボタンが何度も停止状態へ戻る場合は、別のアプリがVPN権限を継続的に競合していないか確認してください。

一部のクライアントには、アプリごとのプロキシ設定やバイパスリストがあります。ルールモードはドメイン、IP、ルールセットから出口を選ぶ仕組みで、アプリごとのルーティングはどのアプリをVPNに入れるかを決める仕組みです。両者は異なる層にあります。アプリをバイパスに指定すると、その接続はmihomoへ入らず、後続のドメインルールでも処理されません。特定アプリだけ使えない場合は、まずアプリの振り分けリスト、次にルールのヒット状況、最後に選択したノードがアプリに必要なプロトコルとネットワーク環境に対応しているかを確認します。

LAN機器の検出、画面ミラーリング、印刷はマルチキャストやローカルネットワークに依存するため、VPNの取り込み後にシステム制限を受けることがあります。まずプライベートアドレスがDIRECTになっているか確認し、クライアントが対応していればLANアクセスを許可します。ルールが正しくても、Android VPNの状態によって検出動作を変えるアプリがあります。その場合は一時的にVPNを切断して比較し、ルールの問題か、アプリ自身の仮想ネットワーク制限かを切り分けます。

バックグラウンド、省電力、ネットワーク切り替え

Android端末メーカーの省電力機能により、画面消灯後にクライアントのバックグラウンドプロセスが停止することがあります。接続直後は使えるのに、しばらくロックするとVPNアイコンが消えたり、直接接続に戻ったりするのが典型例です。システムのアプリ設定でバックグラウンド動作を許可し、バッテリー設定を「制限なし」または同等の項目に変更し、可能なら最近のタスクに固定します。設定名は端末によって異なりますが、画面消灯後やネットワーク切り替え後もVPNサービスが維持されることを基準に判断します。

Wi-Fiからモバイルデータへ切り替えると、既存のTCP接続は元のネットワーク経路を引き継げないため、短時間の切断は通常の再接続処理です。長時間復旧しない場合は、機内モードを何度も切り替えるのではなく、クライアント内で再接続します。「常時接続VPN」を有効にしていると、VPNを経由しない接続をブロックする設定も同時に有効になることがあります。クライアントが正常に起動できないと、すべてのネットワークが遮断されます。この種のシステム設定は、再起動後もクライアントが安定して自動起動できることを確認してから有効にしてください。

モバイル端末のDNS異常は、一部のアプリではIPにアクセスできるのにドメイン名では失敗する、または同じサイトの結果がWi-Fiとモバイルデータで異なる、といった形で現れます。まずプライベートDNSやブラウザのセキュアDNSなど、追加の要因を一時的に無効にして比較し、その後クライアントのDNSモードを確認します。競合元を特定してから残す層を決めてください。システムのプライベートDNS、アプリ内DNS、複数のフィルタリングツールを重ね、すべてに名前解決を書き換えさせる状態を長期運用しないようにします。

CHAPTER 05 / IOS

iOS：Clash Plus、VPN設定、オンデマンド接続

インストールと設定の入口

iPhoneとiPadではiOSダウンロード欄からClash PlusのApp Storeページへ進めます。クライアントの関連情報は公式サイト clashplus.ioでも確認できます。インストール後は、システム設定で端末の日付、ネットワーク、App Storeのログイン状態が正常であることを確認します。iOSの通信取り込みはシステムのVPNフレームワークが管理するため、クライアントがシステムの許可を迂回して他のアプリの接続を直接変更することはできません。

Clash Plusを開き、設定ページからサブスクリプションの取り込みを選び、サービス提供者から受け取ったClash互換URLを貼り付けます。クリップボードからURLを渡すと、システムが貼り付け許可を表示する場合があります。拒否した場合は入力欄に戻り、貼り付けを手動で実行できます。取り込み後はプロキシグループとノードが表示されることを確認し、その設定を現在の設定に指定します。サブスクリプション一覧の更新日時は最後のリクエスト結果を示すだけで、ノードの疎通確認を意味しません。

初回接続時、iOSはVPN設定の追加を求め、端末のパスコードまたは生体認証で確認します。この処理はシステムが行い、成功後はステータスバーやコントロールセンターでVPN状態を確認できます。システム設定に別のVPNが存在する場合、Clash Plusの起動時に通常は現在の設定が切り替わります。企業管理端末では管理ポリシーにより新しいVPNの追加が制限されることがあります。この制限は端末管理者が対応する必要があり、アプリを再インストールしてもシステムポリシーは変わりません。

ルールモード、プロキシグループ、オンデマンド接続

日常利用ではまずルールモードを使うことをおすすめします。ルールモードは、設定内のドメイン、IP、ルールセット、最終MATCHルールに基づいてDIRECTまたはプロキシの方針を決めます。グローバルモードは接続を1つのプロキシグループへ集約するため、ノードの一時的な検証には向きますが、すべての問題を恒久的に回避する方法ではありません。ルールモードでは異常なのにグローバルモードでは正常な場合、単純にノードの障害と判断せず、ログでその接続がどのルールにヒットしたかを確認します。

プロキシグループには、自動選択、フォールバック、手動選択、DIRECTなどがあります。自動選択の結果は、サブスクリプションで定義されたテスト先と間隔に左右され、常にすべての用途に適しているとは限りません。安定性を優先する場合は、手動グループでノードを1つ固定し、自動切り替えの影響を除きます。接続が安定したことを確認してから自動方針に戻します。ノード切り替えの影響は新しい接続に限られ、既存セッションが古い経路を使い続けることがあります。テスト時は対象アプリを完全に終了して再起動してください。

オンデマンド接続は、特定のネットワーク条件でVPNを自動的に有効化できますが、ルールが広すぎると帰宅時、社内ネットワーク接続時、モバイル通信への切り替え時に頻繁な再接続が発生します。初期設定では手動接続を使い、サブスクリプションとルールが安定してから、信頼できるWi-Fiやモバイルネットワークなどの条件でオンデマンド設定を作ります。設定後は、画面ロック、ロック解除、機内モードからの復帰、ネットワーク切り替えを実際にテストし、スイッチの状態だけで判断しないでください。

iOSのDNSとLAN権限

iOSはアプリによるローカルネットワークへのアクセスを制限します。NAS、画面ミラーリング機器、LAN上の管理ページへアクセスする場合は、システムのプライバシー設定でクライアントや対象アプリのローカルネットワーク利用を許可し、設定でプライベートアドレスがDIRECTになっていることを確認します。クライアント自身に権限があっても、他のアプリへ自動的に権限が付与されるわけではありません。実際のアクセス可否は対象アプリとシステムのネットワークポリシーにも左右されます。

fake-ipモードでは、DNSが返したアドレスをカーネルがドメインへ対応付け、その後ルールに従って処理します。一般的なウェブ閲覧には適していますが、LAN検出、特殊なドメイン解決、IPアドレスを直接検証するアプリではfake-ipフィルターへの追加が必要な場合があります。フィルターを変更したら設定を再読み込みし、新しい接続を作成してください。古いDNSキャッシュは設定テキストを変更しただけでは消えません。特定のWi-Fiだけで問題が起きる場合は、キャプティブポータル認証が必要なネットワークかどうかも確認します。

接続は正常に見えるのにウェブが開けない場合は、まずSafariで通常のHTTPページを開き、ホテル、空港、学校ネットワークの認証ページが表示されていないか確認します。認証が完了するまで、VPNは外部への有効な接続を確立できないことがあります。認証後に接続を再起動し、ログでDNSタイムアウト、ルート失敗、ノードのハンドシェイクエラーを確認します。モバイル通信では正常で特定のWi-Fiだけ異常な場合は、すぐにサブスクリプションを変更せず、そのネットワークの認証、DNS、IPv6条件を先に確認します。

CHAPTER 06 / LINUX

Linux：デスクトップクライアント、mihomoサービス、環境変数

デスクトップクライアントとパッケージの選択

デスクトップ環境のあるLinuxでは、Linuxダウンロード欄からClash Verge RevまたはFlClashを選べます。ダウンロード前にuname -mを実行してアーキテクチャを確認します。一般的なデスクトップPCはx86_64、ARM端末はaarch64と表示されることが多いです。ディストリビューションのパッケージ形式も確認してください。Debian、Ubuntu系は通常debを使い、その他のディストリビューションでは明確に対応した形式か、端末に適したインストール方法を選びます。

GUIクライアント起動後のサブスクリプション取り込み、プロキシグループ選択、システムプロキシの考え方は、他のデスクトッププラットフォームとほぼ同じです。主な違いはデスクトップ環境にあります。GNOME、KDE、軽量ウィンドウマネージャーではシステムプロキシの実装が一致せず、一部のコマンドラインプログラムはデスクトッププロキシを完全に無視します。まずクライアント内でmixedポートが待受中であることを確認し、ブラウザ、ターミナル、プロキシが必要なアプリを個別にテストします。1つのブラウザの結果をシステム全体の結果とみなさないでください。

パッケージをインストールしてもアプリが起動しない場合は、ターミナルからプログラムを実行し、不足している依存関係、権限、グラフィカルセッションに関するエラーを確認します。WaylandとX11では、トレイアイコン、ウィンドウの拡大率、自動起動の挙動が異なる場合がありますが、画面上の問題がカーネルの動作に影響するとは限りません。待受ポート、プロセス一覧、ログからプロキシサービスの動作を確認し、デスクトップ統合は別に対処します。

mihomoカーネルを直接実行する

サーバー、ルーター、デスクトップ環境のない端末では、通常mihomoを直接実行します。ダウンロードページのカーネル欄にはアーキテクチャ別のビルドがあります。必ずuname -mの結果に合うものを選んでください。設定ファイルにはサブスクリプション展開後の認証情報が含まれる場合があるため、権限を管理したディレクトリに保存します。初回は前面で起動して、構文チェック、ポート待受、ルール読み込みの成功を確認してからsystemdサービスを作成します。最初のエラーが見えないままサービスが再起動を繰り返す状態を避けられます。

mkdir -p ~/.config/mihomo
mihomo -d ~/.config/mihomo

ss -lntp
journalctl --user -u mihomo --no-pager -n 100

systemdのユーザーサービスを使う場合、作業ディレクトリ、実行ファイルのパス、設定ディレクトリはすべて絶対パスで記述します。サービスアカウントには、設定の読み取りとキャッシュディレクトリへの書き込み権限が必要です。低位ポートへのバインド、ルート変更、TUN作成が必要な場合はシステムサービスを使い、必要な能力だけを明示的に付与します。権限設定を省くために、関係のないディレクトリを長期間すべてのユーザーから書き込み可能にしないでください。

[Unit]
Description=mihomo proxy core
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

ターミナルのプロキシ、TUN、ファイアウォール

コマンドラインツールを接続する最も分かりやすい方法は、現在のセッションに環境変数を設定することです。HTTPツールは通常http_proxyとhttps_proxyを読み取り、SOCKSが必要な場合はツールの対応状況に応じてall_proxyを使います。環境変数の大文字・小文字を区別するかはプログラムによって異なるため、スクリプトでは必要な形式を明示してください。プロキシ変数をすべてのシステムサービスのグローバル環境へ永続的に書き込まないでください。ソフトウェア更新、社内ネットワーク、ローカル管理作業まで意図せず転送される可能性があります。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5h://127.0.0.1:7890

curl -I https://example.com
env | grep -i proxy

LinuxのTUNは、カーネルのTUNデバイス、ルート権限、ファイアウォールルールの連携が必要です。コンテナ環境では/dev/net/tunとネットワーク管理機能の公開が必要になることもあります。有効化前に、現在のデフォルトルート、ポリシールート、DNS設定を記録してください。問題が起きたときに復元できます。nftables、iptables、firewalld、ディストリビューションのネットワーク管理ツールを使う場合は、複数の仕組みが同じ転送ルールを同時に管理しないようにします。

サーバーでallow-lanを有効にしたり、すべてのアドレスで待ち受けたりすると、プロキシポートがネットワークインターフェースへ公開されます。他の端末からの接続が明確に必要な場合だけ設定し、ホストのファイアウォールで送信元アドレスを制限してください。本機だけで使うなら127.0.0.1での待受で十分です。ポートを確認するときは待受アドレスも確認します。ポートが存在してもアクセス範囲が適切とは限らず、ループバックアドレスと全インターフェースでは境界がまったく異なります。

DNSをsystemd-resolved、NetworkManager、コンテナランタイム、手動のresolv.confが管理している場合、TUNの取り込み結果が互いに上書きされることがあります。まずresolvectl statusで各インターフェースのDNSを確認し、問い合わせがmihomoへ入っているか判断します。コンテナ内だけで名前解決に失敗する場合は、ホスト、コンテナDNS、転送ルールを分けて確認してください。ホストのブラウザのプロキシ設定だけを変更しても解決しません。

CHAPTER 07 / CONFIGURATION

共通設定：ポート、DNS、ルール、サブスクリプション更新

読みやすい最小構成と待受範囲

GUIクライアントは通常、サブスクリプションから設定を生成するため、ユーザーがYAMLをゼロから書く必要はありません。ただし主要フィールドを理解しておくと、画面上のスイッチが実際に何を変更したのか判断しやすくなります。以下の例は、本機のmixedポート、ルールモード、ログレベル、管理インターフェース、DNSの基本的な関係を示すものです。完全なサブスクリプションではなく、proxiesとproxy-groupsがないため利用可能な回線は生まれません。実際にはサブスクリプションからノードを取得し、構造を保ったままオーバーライドします。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-portはHTTPとSOCKSの接続を同時に受け付け、デスクトップのシステムプロキシとコマンドラインツールで1つの入口を共有できます。allow-lan: falseとループバックへのバインドを組み合わせると、本機だけがアクセスできます。同じLANのスマートフォンや他の端末にポートを使わせる場合は、待受アドレス、ファイアウォール、アクセスルールを同時に変更する必要があります。1つのスイッチだけを変えても接続できない場合があり、逆に公開範囲を意図せず広げることもあります。

external-controllerは管理インターフェースであり、通常のプロキシポートではありません。GUIクライアントはこれを通じて接続情報を読み取ったり、ポリシーを切り替えたりすることがあります。LANへ直接公開する場合は認証を設定し、アクセス元を制限してください。本機のクライアントだけで使う場合はループバックで待ち受けます。ポート競合時に管理インターフェースを不用意に削除しないでください。画面とカーネルの通信が失われる可能性があります。まず競合しているのがmixed、DNS、controllerのどのポートかを確認します。

DNSモードとfake-ipフィルター

DNSはドメイン名の解決方法を決め、ドメインルールが識別するための基盤にもなります。fake-ipモードでは予約アドレスを返し、カーネルが接続を元のドメインへ対応付けるため、アプリがIP宛てに接続した場合でもドメインルールの情報を維持できます。redir-hostは従来の名前解決に近く、一部の特殊なプログラムでは互換性が高い場合がありますが、ドメインの対応付けやキャッシュの挙動は異なります。速度の印象だけで切り替えず、アプリの挙動に基づいて選んでください。

LAN内ドメイン、疎通確認用ドメイン、時刻同期、一部の特殊なアドレス検証を行うアプリでは、fake-ip-filterへの追加が必要になることがあります。フィルターに入れると実際の名前解決結果を取得しますが、自動的にDIRECTになるわけではありません。最終的な出口はrulesが決めます。変更後はシステムのDNSキャッシュを消去し、設定を再読み込みして接続を作り直します。ページを更新するだけではブラウザ内部のキャッシュが残り、設定が反映されていないように見えることがあります。

システムの暗号化DNS、ブラウザ独自のDNS、クライアントのDNSを同時に使うと、問い合わせが想定した入口を迂回することがあります。トラブル対処では追加の層を一時的に無効にし、mihomoのDNSだけを残して、ログにドメインとルールヒットが表示されるか確認します。基本経路を確認してから、必要なセキュアDNS設定を1つずつ戻してください。漏えいチェックと設定検証については、Clash DNS漏えい検査と防止設定の実践ガイドも参照できます。

ルールの順序とプロキシグループ

ルールは上から順に照合され、最初に一致した時点で処理が終了します。具体的なドメイン、プロセス、ルールセットは前方に置き、範囲の広いGEOIP、GEOSET、最終MATCHは後方に置くのが一般的です。MATCHを前に置くと、後続のルールは永遠に実行されません。ルールを変更したら、接続ログで「リクエストのドメイン—ヒットしたルール—対象ポリシー」の3点を確認し、最終的にウェブが開くかだけで判断しないでください。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-KEYWORD,example,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

RULE-SETは独立したルール集合を参照するためのもので、更新と再利用に便利です。ルールプロバイダーのダウンロードに失敗しても、既存キャッシュで動作し続ける場合がありますが、新規インストールやキャッシュ削除後に問題が表面化します。providerのURLへの到達性、behaviorの種類、ルール内容の整合性、ポリシー名が実在するかを確認します。存在しないプロキシグループにルールがヒットすると、通常は設定読み込み時にエラーになります。

プロキシグループ名はサブスクリプションによって決まり、例にあるPROXYがすべての設定に存在するとは限りません。オーバーライドルールでは、現在の設定にある実際のグループ名を使用します。グローバルモードは大部分のルール判定を迂回し、指定したグローバルグループへ通信を渡します。DIRECTモードはプロキシ出口を使いません。3つのモードの違いは、ルール・グローバル・DIRECTの3モード解説で確認できます。

サブスクリプション更新とオーバーライドの関係

サブスクリプションを更新すると、通常はリモート設定が再ダウンロードされて置き換えられます。サブスクリプションから生成されたYAMLを直接編集すると、次回更新で変更が上書きされる可能性があります。オーバーライド、スクリプト、Mixinに対応したクライアントでは、ローカルポート、DNS、追加ルールを専用のオーバーライド層に入れてください。非対応の場合は変更内容を記録し、更新後に再確認します。1か所の変更を守るために更新を恒久的に無効にしないでください。ノード、ポリシー、ルールの更新まで失われます。

自動更新の間隔は、頻繁にリクエストするほど短くせず、サービス提供者の変更を適時取得できないほど長くもしません。更新に失敗した場合は、HTTPリクエストの失敗、応答内容の変化、解析エラー、プロキシループを切り分けます。クライアントが現在のプロキシ経由でサブスクリプションを取得し、サブスクリプションのドメインが誤ったルールで利用不能なノードへ送られると、更新ループが起きることがあります。詳しい手順はサブスクリプション更新失敗の対処と自動更新設定を参照してください。

CHAPTER 08 / TROUBLESHOOTING

設定のよくある問題：通信経路に沿って段階的に切り分ける

クライアントは起動するがネットワークに接続できない

実際の通信経路に沿って確認します。対象アプリがリクエストをローカルプロキシへ渡しているか、ローカルポートが待受中か、カーネルが現在の設定を読み込んでいるか、ルールが想定したポリシーへ接続を渡しているか、ノードが遠隔接続を確立できるか、DNSが利用可能な結果を返すか、という順序です。クライアント画面に「実行中」と表示されても、プロセスの存在しか示さず、各層の成功を証明するものではありません。

まずTUNを無効にし、システムプロキシだけを残してブラウザで通常のサイトへアクセスします。ブラウザも失敗する場合は、システムプロキシのアドレスが本機を指しているか、ポートがクライアントと一致しているかを確認し、ログに接続記録があるか調べます。ログがまったくない場合は通信がクライアントに入っていない可能性があります。リクエストはあるのに直ちに拒否される場合は、ポートの誤りやカーネル未起動がよくある原因です。ルールにはヒットするが遠隔ハンドシェイクに失敗する場合は、ノードとネットワーク条件を確認します。

システムプロキシを無効にしてもウェブへ接続できない場合は、残ったプロキシ設定、DNSキャッシュ、他のVPNルートが原因かもしれません。Windowsではシステムプロキシ、macOSでは現在のネットワークサービス、モバイルOSではVPN状態、Linuxでは環境変数とデフォルトルートを確認します。再起動で一部の一時状態を消去できますが、再起動前に設定とログを記録してください。そうしないと再発後も、どの層が変わったのか分からなくなります。

サブスクリプションを更新できない、または解析に失敗する

サブスクリプションの更新に失敗したら、まず元のURLをブラウザで開き、応答状態を確認します。URLに到達できない、期限切れ、ログインページが返る場合は、サービス提供者側でURLを更新します。ブラウザではアクセスできるのにクライアントだけ失敗する場合は、クライアントのネットワーク権限、現在のプロキシルール、システム時刻を確認します。証明書接続は正確な時刻に依存するため、端末の時刻が大きくずれると、ネットワーク障害に見える安全な接続エラーが発生することがあります。

解析失敗は、応答内容が互換YAMLではない、現在のクライアントが認識できない構造になっている、またはウェブ認証ページやエラーページに置き換わっていることを示す場合が多いです。HTTPステータスだけを見ないでください。成功が返っていても内容がHTMLのことがあります。応答内容をローカルに保存し、先頭が設定フィールドになっているか、インデントと文字コードが正しいか確認します。項目別の確認手順はサブスクリプション無効化・解析失敗のセルフチェックリストを参照してください。

取り込み後にノードが空の場合は、他ツール専用のサブスクリプションではなく、Clashまたはmihomo形式を選んでいるか確認します。ノードはあるのにプロキシグループが空なら、設定変換でproxy-groupsが欠落している可能性があります。大量のノードを手作業で新しいファイルへコピーせず、まずサブスクリプションの提供元から正しい形式を取得してください。コピーによる認証フィールドやプロトコルパラメータの破損を防げます。

一部のウェブサイトやアプリだけ失敗する

一部のサイトだけ失敗する場合は、まず接続ログのドメイン、ヒットしたルール、ポリシーを確認します。誤ってDIRECTに一致しているなら、具体的なルールを調整し、より広いルールより前に置きます。すでにプロキシへ入っているのに失敗する場合は、検証済みのノードを1つ固定して再試行し、自動切り替えの影響を除きます。ブラウザは正常で特定のアプリだけ失敗する場合は、そのアプリがシステムプロキシを読むか確認し、必要に応じてTUNやモバイル端末のアプリ振り分けを試します。

ウェブサイトは開くのに画像、ログイン、動画だけ失敗する場合、メインドメインとリソースのドメインが異なるポリシーに一致していることがよくあります。開発者ツールや接続一覧で関連ドメインを確認し、同じポリシーにすべきか判断します。広すぎるDOMAIN-KEYWORDルールで似た名前をすべて覆わないでください。無関係なサービスまで変更される可能性があります。保守状態のよいルールセットを使うか、明確なドメインサフィックスにルールを追加する方が安全です。

ノードを切り替えても短時間問題が残る場合は、DNS、HTTP/2、QUIC、アプリのセッションキャッシュが原因かもしれません。対象アプリを完全に終了し、必要なキャッシュを削除して接続を作り直してから再テストします。ブラウザのプライベートウィンドウで減らせるのは一部のキャッシュだけで、システムDNSの更新の代わりにはなりません。比較テストでは毎回1つの変数だけを変更し、モード、ノード、ネットワーク、ヒットしたルールを記録します。

DNS、ポート、TUNの競合

DNS障害の典型的な症状は、IPには到達できるのにドメインだけ失敗する、ログに問い合わせタイムアウトが続く、同じドメインの結果がアプリによって食い違う、といったものです。まずローカルDNSの待受ポートが使用されていないか確認し、ブラウザ独自のDNSとシステムの追加DNSツールを無効にして比較します。fake-ipモードで予約アドレスが表示されるのは設計上の動作であり、そのアドレス自体を遠隔サーバー障害とみなさないでください。

ポート競合が起きると、プロキシや管理インターフェースが待受できません。ログにあるbind、address already in useなどの情報を確認し、システムツールで使用中のプロセスを特定します。ポートを変更したら、システムプロキシ、ターミナルの環境変数、ブラウザ拡張、LAN上の端末もすべて更新する必要があります。クライアントのフィールドだけを変更して古いシステムプロキシを残すと、「カーネルは正常に動作しているのにリクエストが入らない」状態になります。

TUNを有効にして全ネットワークが切断された場合は、まずTUNを無効にして基準状態へ戻し、仮想インターフェースの権限、デフォルトルート、DNSの強制、他のVPNを確認します。デスクトップの仮想マシン、コンテナ、ゲーム高速化ツール、企業向けネットワークソフトがネットワークフィルタードライバーを導入していることもあります。競合するツールを順番に無効にし、毎回1つだけ戻します。スリープ復帰後だけ起きる場合は、TUNインターフェースを作り直し、古いルートが残っていないか確認します。

ログの読み方と復元のタイミング

日常のトラブル対処にはinfoレベルで十分です。debugログは短時間だけ詳細を収集したい場合に使います。大量の接続記録が生成されるため、常時有効にしないでください。設定読み込みエラー、待受失敗、DNSタイムアウト、ルールヒット、遠隔ハンドシェイク、ルート作成の情報を重点的に確認します。ログを共有する前に、サブスクリプションURL、認証フィールド、ノード資格情報、公開したくないアクセス先ドメインを削除してください。

変更を重ねて判断できなくなった場合は、最小状態へ戻します。TUNとオーバーライドを無効にし、元のサブスクリプションを1つだけ読み込み、デフォルトのローカルポートを使い、ノードを1つ固定して、システムプロキシ経由でブラウザをテストします。基準状態が戻ったら、「カスタムDNS—追加ルール—TUN—LAN共有」の順で1つずつ戻します。ある段階を追加した直後に再現すれば、調査範囲をその層に限定できます。

元のサブスクリプションが複数のネットワーク、複数のクライアントで接続できず、URLの応答内容も正常な場合は、サービス提供者へノード状態を確認してください。同じサブスクリプションが他の端末で使えるなら、まず本機の権限、ポート、DNS、ルートを確認します。クライアントの再インストールはプログラムファイルやシステム統合の破損を直す場合に限って有効で、サブスクリプション形式、ルールの論理、遠隔ノードの状態を自動修正するものではありません。

症状 最初の確認点 次の手順
クライアントは動作しているが、ログにリクエストがない システムプロキシ、VPN/TUN、アプリのプロキシ設定 本機のアドレスとmixedポートを確認する
すべてのノードで接続に失敗する 現在のネットワーク、システム時刻、サブスクリプションの状態 ネットワークを変更してハンドシェイクログを確認する
一部のドメインだけ失敗する ルールのヒット状況とDNS結果 ノードを固定して関連ドメインを確認する
TUNを有効にするとネットワークが切れる 仮想インターフェース、ルート、他のVPN TUNを無効にしてシステムプロキシの基準状態へ戻す
サブスクリプションは成功を返すが解析できない 応答内容とサブスクリプション形式 ログインページやエラーページではないことを確認する

トラブル対処が終わったら、最終的に動作したクライアント、設定名、プロキシモード、DNSの選択、必要なオーバーライドをローカルに記録します。次回の更新ではこの基準と比較するだけでよく、通信経路全体を再び推測する必要はありません。再インストールや別のプラットフォームへの移行が必要な場合は、クライアントダウンロードページに戻り、システムアーキテクチャと利用可能なクライアントを確認してください。