Clash 全プラットフォーム導入・設定ガイド

共通の準備：クライアント、カーネル、サブスクリプションの違い

導入するアプリと設定の入手元を確認

GUIクライアントはサブスクリプションの追加、プロキシグループの選択、システム設定の変更を担当します。カーネルはポートの待ち受け、プロトコルの処理、ルールの照合を担い、両者は別の役割です。mihomoはカーネルのプロジェクトで、Clash Verge RevやFlClashなどはGUIを提供します。同じClashの名前が付いたアプリでも、設定の実装は異なる場合があります。当サイトで扱うプラットフォームでは、まずClash Plusを候補にし、必要な機能に応じてほかのクライアントも確認してください。ソフト名だけを根拠にYAMLの項目が使えると判断しないでください。項目が反映されるかどうかは、実際に使われるカーネルとクライアント側の設定生成方法にも左右されます。

サービス提供元から発行されたサブスクリプションURL、または動作確認済みの設定ファイルを用意します。クライアント自体に接続先サービスが付属することは通常ありません。サブスクリプションからClash設定一式が返る場合もあれば、別形式のサーバー一覧だけが返る場合もあります。後者は完全なYAML設定としてそのまま使えません。提供元が案内する対応形式を確認し、Clash用サブスクリプションへの変換が必要な場合は、信頼できるローカル環境の方法を優先してください。URLのクエリパラメーターがアクセス権限を含むことがあります。公開の掲示板に投稿したり、トラブル対処のために元の設定ファイル全体をアップロードしたりしないでください。

元に戻せる状態を用意する

インストール前に、既存のVPN、システムプロキシ、手動設定したDNSを記録し、通信を取り込むほかのソフトは一時終了します。複数のツールがデフォルトルートやプロキシポートを同時に変更すると、ログに出るエラーは原因ではなく結果の場合があります。初回接続では、クライアント、設定、通信の取り込み方法をそれぞれ一つに絞って確認しましょう。成功してから自動起動、自動更新、LAN共有などを有効にします。既存の設定はエクスポートしてバックアップし、元のファイル名と用途も記録してください。テスト用の変更を長期利用する設定として保存しないよう注意します。

システム時刻、空き容量、デバイスのアーキテクチャを確認します。時刻が大きくずれているとHTTPS証明書の検証に失敗し、インストーラーのアーキテクチャが合わないと起動できなかったり、互換レイヤーによる負荷が増えたりすることがあります。サブスクリプションの更新失敗が、必ずしもプロキシの問題とは限りません。ネットワークのログイン認証が未完了、URLの失効、アカウントの期限切れなどを個別に確認します。まず利用可能なネットワークでシステムへのログインや必要な認証を済ませてから、クライアントを起動してください。トラブル対処では、操作の順序とエラー文を記録するほうが、接続ボタンを何度も押すより役立ちます。

最小構成でできることを把握する

以下はmihomoのローカル待ち受け部分のみを示す例です。ノード、プロキシグループ、ルールは含まず、サブスクリプションの代わりにはなりません。mixed-portはHTTPとSOCKSの両方の接続を受け付けます。ループバックアドレスにバインドし、LANからのアクセスを無効にすれば、単体での動作確認に適しています。ポートは必ずしも7890である必要はありませんが、クライアント、システムプロキシ、テストコマンドで同じ値を使ってください。初回起動時に外部制御インターフェースを不用意に公開したり、ローカルの接続問題を解決するために待ち受け先を全ネットワークインターフェースに変更したりしないでください。公開範囲が広がる一方で、問題が解決するとは限りません。

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

完全な設定では、通常ルールを上から順に照合し、該当した時点で処理を終了します。プロキシ名は既存のプロキシグループまたはノードに対応している必要があり、例の名称をそのままコピーしてはいけません。インポート後は、その設定が現在の設定として選択されていることを確認し、次にカーネルの起動を確認します。「ダウンロード成功」はファイルを取得できたという意味にすぎず、設定の構文が正しいことや、通信がプロキシを経由していることを示すものではありません。それぞれの状態を分けて確認すれば、トラブル対処の手戻りを減らせます。

Windows：インストール、システムプロキシ、サービスモード

適切なアーキテクチャのアプリをダウンロードして初回起動

Windowsインストーラー一覧からクライアントを選びます。まずはClash Plusがおすすめです。ほかにClash Verge Rev、FlClash、Clash Nyanpasuがあり、Clash for Windowsはすでにメンテナンスが終了しています。アーカイブされたクライアントは、互換性が必要な古い環境に限って検討し、新しい設定にはメンテナンス中のクライアントを使いましょう。「設定 → システム → バージョン情報」でシステムの種類を確認し、ダウンロードページに記載されたアーキテクチャと照合します。ARMデバイスでは、OS名だけを見て一般的なデスクトップ用インストーラーを選ばず、クライアントの対応状況を確認してください。

安定して使えるローカルフォルダーにインストールします。長時間稼働させるアプリを、ダウンロード用の一時フォルダー、圧縮ファイル内、自動削除される場所に置かないでください。初回起動時にファイアウォールやサービスのインストール許可を求められたら、まずアプリの配布元と用途を確認します。端末内だけで使う場合、LANからの受信接続をあえて許可する必要はありません。起動がブロックされたときは、ファイルの入手元、システム要件、セキュリティソフトの通知を確認してください。すべての保護機能を無効にすることを一般的なインストール手順として扱わないでください。

サブスクリプション追加後に設定と待ち受けを確認

クライアントのサブスクリプションまたは設定画面でリモート設定を追加し、完全なURLを貼り付けて更新します。複数の設定がある場合は、追加した項目が選択されていること、更新日時、ノード一覧を確認してください。設定名だけが表示され、ノードが空の場合は更新ログを開き、リクエスト失敗、ログインページの応答、設定の解析エラーを切り分けます。最初からDNSを変更する必要はありません。サーバーが正しくない内容を返しているなら、解析処理を工夫してもHTMLページしか読み取れません。機密性のあるURLはクライアント内だけに入力し、トラブル対処のスクリーンショットに全体を写さないでください。

ルールモードを選び、実際に使うプロキシグループで利用可能なノードを選択します。次にクライアント設定のローカルプロキシポートを確認してから、システムプロキシを有効にしてください。Windowsのプロキシ設定で、手動プロキシがループバックアドレスと同じポートを指しているか確認します。独自のネットワークスタックを使うアプリはシステムプロキシを参照しない場合があります。そのため、ブラウザーは接続できてもターミナルは失敗することがあります。まずPowerShellから明示的にプロキシを指定してテストし、「クライアントに接続できるか」と「システムの通信が取り込まれているか」を分けて確認しましょう。

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/
Get-NetTCPConnection -State Listen -LocalPort 7890

1つ目のコマンドはTCP接続が確立できるかを確認し、2つ目はプロキシ経由で対象サイトにリクエストします。PowerShell環境によっては同名のエイリアスが引数の解釈に影響するため、curl.exeを使うと回避できます。3つ目は待ち受け状態を確認するコマンドです。権限不足と表示された場合は、管理された環境でターミナルの権限を上げて確認してください。ポートが別のプログラムに使われている場合は、重複して起動しているクライアントを終了するか、現在のクライアントのポートを変更します。変更したポートはシステム設定にも反映してください。片方だけ変更すると、新たな接続トラブルにつながります。

TUNを有効にする手順とWindows固有の問題

システムプロキシが正常に動くことを確認してから、TUNを試します。仮想インターフェースの作成やルートの設定に、サービスコンポーネントのインストールと管理者権限が必要なクライアントもあります。サービスモードは、毎回GUI全体を管理者として起動することとは異なります。クライアントの説明に従ってサービスをインストールまたは起動し、ログで仮想デバイスの初期化完了を確認してからTUNを有効にしてください。すぐに通信できなくなった場合は、TUNを無効にしてネットワークを戻し、セキュリティソフト、ほかのVPN、仮想ネットワークアダプターとの競合を確認します。ネットワークスタック、DNS、MTUを同時に変更しないでください。

WSL、Docker、仮想マシンは追加のネットワーク環境です。Windowsの127.0.0.1が、それらすべてで共通のホストアドレスとして使えるわけではありません。実際の接続方法はネットワークモードとシステム設定によって異なります。別の環境からホストのプロキシに接続する必要がある場合は、到達可能なアドレス、アクセス制御、ファイアウォールの範囲を設定してください。コンテナを接続させるためだけに、プロキシをLAN全体へ公開しないでください。ゲームや音声アプリでUDPを使う場合は、上流のプロトコル対応も確認します。TUNを有効にしても、ノードの機能が補われるわけではありません。

クライアントを終了する前に、システムプロキシとTUNを無効にしてください。アプリが異常終了し、ブラウザーにプロキシエラーが出るようになった場合は、Windowsのプロキシ設定に戻って手動プロキシの残りを削除し、基本ネットワークが復旧したか確認します。自動起動と自動接続は通信経路全体の確認後に有効にし、実際に再起動してサービスがGUIより先に準備できるか試してください。スリープからの復帰やWi-Fi切り替え後に問題が出たら、まず現在の設定で再接続します。直らない場合にルートとDNSを確認し、原因の手がかりを消してしまう再インストールは最後に検討します。

macOS：チップのアーキテクチャ、ネットワーク権限、プロキシの復旧

インストーラーを選び、macOSの許可設定を確認

「このMacについて」でチップまたはプロセッサーの情報を確認し、macOSダウンロードへ進みます。まずはClash Plusがおすすめです。用途に応じてClash Verge RevまたはFlClashも選べます。ClashX Metaはメンテナンスが終了しているため、互換性が必要な場合のアーカイブとして扱ってください。Apple Silicon用とIntel用のインストーラーを正しく選びます。互換レイヤーで起動できるからといって、ネイティブ対応のアーキテクチャを無視しないでください。インストール前にクライアントの対応OSも確認します。インストーラーをダウンロードできても、古いOSで動作するとは限りません。

ディスクイメージで配布されるアプリは、まず「アプリケーション」フォルダーにコピーし、イメージを取り出してから正式な場所のアプリを起動します。こうすることで、更新、権限の関連付け、ログイン項目が一時的なマウント先を参照するのを防げます。初回起動時は、システムの案内に従って開発元と入手元を確認してください。セキュリティ機能にブロックされた場合は、「プライバシーとセキュリティ」に表示される具体的な理由を確認し、プロジェクトの案内に沿って対処します。出所不明のコマンドでファイル属性を一括削除したり、システム全体のアプリ検証機能を無効にしたりしないでください。

設定を追加し、現在のネットワークサービスを確認

クライアントにリモートサブスクリプションを追加して更新し、アクティブな設定として選択します。ローカルYAMLを使う場合は、読み込み場所と更新方法を確認してください。インポート時に設定のコピーを保存するクライアントでは、元のファイルを編集しても実行中の設定は変わりません。ルールを長期的にカスタマイズする場合は、クライアントが対応する上書きまたはマージ機能を優先し、最終的に生成された設定を確認します。サブスクリプションのキャッシュファイルを直接編集すると、次回の更新で変更が失われることがあります。保存できたことと変更が保持されることは別です。

システムプロキシを有効にした後、システム設定のネットワーク詳細でHTTP、HTTPS、SOCKSのプロキシ項目を確認します。macOSのプロキシ設定は特定のネットワークサービスに紐付くことが多いため、Wi-Fiと有線LANを切り替えた後は設定を見直してください。メニューバーのアイコンだけでは確認できません。ターミナルでは次のコマンドで現在の状態を確認し、明示的にプロキシを指定したリクエストも試せます。診断用のコマンドであり、システムプロキシを直接変更するものではありません。実際のポートが7890以外なら、テストにも同じ値を指定してください。

scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --proxy http://127.0.0.1:7890 https://example.com/

scutil --proxyはシステムプロキシの状態を表示しますが、すべてのアプリが設定に従うことを保証するものではありません。ブラウザーは使えるのにコマンドラインツールが接続できない場合は、ツールに明示的なプロキシ引数や環境変数が必要か確認します。特定のブラウザーだけ挙動が異なる場合は、拡張機能、独自プロキシ、セキュアDNSの設定を確認してください。複数の設定が重なると、リクエストがクライアントを迂回したり、プロキシを二重に経由したりすることがあります。まずはブラウザーのウィンドウ一つとターミナルのコマンド一つだけで試し、その後に拡張機能を一つずつ戻します。

TUN、補助サービス、ネットワーク切り替え

TUNを有効にする際、補助サービス、管理者権限、ネットワーク拡張が必要になる場合があります。仕組みは使用するクライアントによって異なります。システムの確認ダイアログではアプリ名を確かめ、許可後にクライアントへ戻ってログを確認してください。一度「許可」を押したことだけで、サービスが正常に動作しているとは判断できません。削除済みの古いアプリの場所を参照している場合は、更新後にクライアントの手順に従って補助コンポーネントを再インストールする必要があります。権限エラーとノード接続エラーは異なる段階の問題です。まず仮想デバイスを作成できない問題を解決してから、ルールやDNSを確認します。

macOSでは、ドメインごとの名前解決とネットワークサービスの優先順位がDNSの動作に影響します。社内ドメインが特定のインターフェースのDNSに依存している場合、全通信を取り込んだ後に社内サイトへ接続できなくなったら、まずそのドメインが元々使っていたDNSを確認し、必要に応じてドメイン別の名前解決や除外を設定してください。すべての通信にパブリックDNSを適用しないでください。スリープからの復帰、テザリングへの切り替え、ドッキングステーションの接続後は、インターフェースやルートが変わることがあります。再接続する前に現在のネットワークサービスを確認し、基本ネットワークの認証が未完了でないかも確認してください。

基本接続が復旧したことを確認してから、ログイン時の起動を有効にするか決めます。メニューバーへの常駐、ログイン項目、バックグラウンドサービスはそれぞれ別の状態です。画面が表示されてもカーネルが設定を読み込んだとは限らず、バックグラウンドサービスが存在してもサブスクリプション更新の成功は保証されません。確実に動作確認するには、再起動後の設定選択、プロキシの待ち受け、対象サイトへのリクエストを確認します。使わなくなったクライアントを削除する場合は、先に終了して通信の取り込みを停止し、アプリの手順に沿って補助サービスを削除してください。古いサービスが同じポートを奪い合うのを防げます。

Android：VPNの許可、バックグラウンド動作、アプリごとの設定

インストーラーのアーキテクチャとサブスクリプションの追加

Androidインストーラー一覧では、まずClash Plusを検討してください。Clash Meta for Android、FlClash、Surfboardも選べます。アプリによってインポート形式や機能範囲は異なり、特にSurfboardですべてのmihomo YAML項目がそのまま使えるとは限りません。提供元が対応を案内しているクライアントと形式を確認してから、インストールするアプリを決めてください。新しい端末ではARM64が一般的ですが、実際のアーキテクチャに合ったものを選びます。確認できない場合、ダウンロードページで汎用パッケージが提供されているクライアントに限り、汎用版を選択してください。

ブラウザーやファイル管理アプリからインストールする場合、Androidではその提供元からのアプリのインストール許可が必要になることがあります。実際に使う提供元だけに必要な権限を与え、インストール後はシステム設定から取り消せます。署名が一致しないという警告が出たら、別の提供元から入れた同名アプリがすでにないか確認してください。サブスクリプションを保存した旧アプリをすぐにアンインストールしないでください。エクスポート可能な設定やアプリの設定をバックアップしてから移行を判断します。クライアント間でバックアップ形式を復元できるとは限らないため、サブスクリプションURLとカスタムルールも分けて保存してください。

アプリ内でサブスクリプションを追加して更新し、現在の設定として選択します。更新中の表示が続く場合は、まず接続を一時停止し、そのURLにアクセスできる基本ネットワークを使って更新してみてください。HTTPエラーか解析エラーかを確認します。既存のプロキシ経由でないと取得できないサブスクリプションもあります。その場合は提供元の案内に沿って更新経路を選びますが、「その設定を取得するために、まず同じ設定を読み込む」循環状態にならないようにしてください。利用が認められた別のネットワークで初回追加を済ませ、以降の更新経路を確認する方法もあります。

システムVPNによる通信の取り込みとバックグラウンド維持

Androidのプロキシクライアントの多くは、システムのVPNインターフェースを使ってアプリの通信を取り込みます。初回起動時にシステムの許可画面が表示されます。ここでいうVPNはOSが提供する通信の取り込み方法であり、特定の従来型VPNプロトコルを使うという意味ではありません。通常、同じユーザー環境でこの種のVPNサービスを同時に実行できるのは一つです。そのため、広告ブロッカー、企業VPN、別のプロキシアプリと競合することがあります。ほかの通信取り込みアプリを停止してから使用するアプリを起動し、システムのステータスバーとクライアントのログの両方でサービスの確立を確認してください。

数分は正常でも、画面ロック後に接続が切れる場合は、バッテリー最適化、バックグラウンド動作の権限、メーカー独自の自動起動制限を確認します。クライアントのバックグラウンド動作を許可し、システムにフォアグラウンドサービスの通知が表示されるか確認してください。サービス維持に必要な権限を、通知を隠すために無効にしないでください。端末によっては、最近使ったアプリの一覧から消すとアプリが終了するため、バックグラウンドで固定する必要があります。設定項目の名前ではなく、画面ロック後しばらくしてからWebページを開き、クライアントのプロセス、VPNインターフェース、設定が維持されているかを基準に判断します。

「常時接続VPN」と「VPNを使用しない接続をブロック」はシステム全体に適用される設定です。初回設定時に両方を有効にするのは避けてください。後者を有効にすると、クライアントが起動していないとき、更新に失敗したとき、システムにサービスを終了されたときに通信が遮断され、スマートフォンのネットワーク自体が壊れたように見えることがあります。再起動、画面ロック、Wi-Fiとモバイルデータの切り替えを確認してから、実際のセキュリティ要件に応じて有効にしてください。有効化後に通信できなくなった場合は、システムのVPN設定でブロックポリシーを確認し、必要なら一時的に無効にして更新やトラブル対処を再開します。

アプリごとの設定、プライベートDNS、モバイルネットワークの違い

アプリごとの設定には、「選択したアプリのみプロキシを使用」と「選択したアプリを除外」という、意味が反対のモードがあります。保存前に現在のモードを確認してください。除外したアプリにはクライアント内部のドメイン振り分けルールが適用されません。ブラウザーを除外している場合、ブラウザーのドメインルールを変更しても効果はありません。まず取り込み対象にしたブラウザー一つでテストし、その後でアプリを追加します。システムアプリ、仕事用プロファイル、複製アプリは異なる環境で動作する場合があるため、選択したクライアントで取り込めるか個別に確認してください。

AndroidのプライベートDNS、ブラウザーのセキュアDNS、クライアント内蔵DNSが同時に名前解決へ関与することがあります。名前解決に失敗したら、まず元の設定を記録し、システムの自動DNSとクライアントの標準設定で比較したうえで、一つずつ元に戻します。いずれかの設定を無効にすることが、常に正解とは限りません。モバイルネットワークではIPv6やNAT経路が異なる場合もあります。Wi-Fiでは正常でモバイルデータでは失敗する場合、接続ログ、宛先のアドレスファミリー、ノードへの到達性を個別に確認し、Wi-Fiの結果をそのまま当てはめないでください。

最後に、実際にネットワークを切り替えてテストします。まずWi-Fiで接続し、次にモバイルデータへ切り替えて同じサイトにアクセスし、その後画面をロックして復帰します。各段階では到達性とログを確認し、疎通テストに表示される一つの数値だけで実際のサービス利用を保証しないでください。一つのアプリだけ失敗する場合は、アプリごとのルール、アプリ独自のネットワーク制限、プロトコル要件を優先して確認します。すべてのアプリで同時に失敗する場合は、VPNサービス、サブスクリプションの状態、DNSの順に確認してください。

iOS：App Storeからのインストール、設定の許可、オンデマンド接続

Clash Plusをインストールしてサブスクリプションを保存

iOSではClash Plusをおすすめします。App StoreのClash Plusページからインストールできます。製品情報は公式サイト clashplus.ioをご覧ください。当サイトのiOSダウンロードにも同じリンクを掲載しています。他のデバイスと比較する際にご利用ください。インストール前にApp Storeの互換性に関する説明を確認します。設定を追加する前に、OSが要件を満たしているか、デバイスが管理ポリシーによる制限を受けていないかを確認してください。インストール制限をサブスクリプションの問題と取り違えないためです。

選択したクライアントで使えるサブスクリプションURLを用意し、アプリの設定またはサブスクリプション管理画面からリモート設定を追加して、更新結果を確認します。画面の名称はクライアントの更新で変わる場合があります。「リモート設定の追加、更新、現在の設定として選択」という3つの操作を目印にしてください。追加後すぐにすべての自動機能を有効にせず、サーバー一覧とプロキシグループを確認して内容が正しく解析されたことを確かめます。提供元が特定のクライアント形式しか案内していない場合は、対応方法を問い合わせてください。ファイルの拡張子を変更するだけでは形式を変換できません。

別のデバイスからURLをコピーする際、チャットアプリが空白を挿入したり、クエリパラメーターを切り詰めたり、記号をリッチリンクに変えたりすることがあります。貼り付け後、プロトコルの先頭とURL全体を確認します。ただし、アクセス権限を含む内容をスクリーンショットに写さないでください。カメラでQRコードを読み取っても、入力ミスが減るだけで内容が信頼できるとは限りません。サブスクリプションを切り替える前に、元の設定名とカスタムルールをバックアップします。リモート設定が複数ある場合は、どれが現在選択されているか確認してください。新しいサブスクリプションを更新しても、古い設定で動作している可能性があります。

システムのVPN表示と実際のプロキシ経路を区別する

初回接続では、アプリによるVPN構成の追加を許可し、デバイスのパスコードや生体認証でシステム確認を行う場合があります。許可後にアプリへ戻って接続結果を確認し、システムのVPN設定で現在どのアプリが接続を提供しているかを確認します。システムにVPNの表示が出ても、トンネルインターフェースが確立したことを示すだけです。上流ノードに到達できることや、すべての宛先がプロキシを経由することを意味しません。次に、直結する想定の宛先とプロキシ経由の想定の宛先をブラウザーで開き、アプリが提供する接続ログやルール履歴を確認してください。

iOSでデスクトップ版のように「ローカルポートを設定してからシステムプロキシを有効にする」操作をしないでください。通常、アプリはシステムのネットワーク拡張機能で通信を処理します。画面上のルールモード、プロキシモード、接続スイッチもそれぞれ異なる階層の設定です。ルールモードはドメイン、アドレスなどの条件で経路を選び、グローバルモードはより多くの通信を選択中のプロキシに渡しますが、どちらもノードが正常に動作している必要があります。グローバルモードに切り替えて復旧しても、問題をルールまたはプロキシ選択に絞り込めるだけで、DNS、権限、ネットワーク環境に問題がないとは証明できません。

同じデバイスに別のVPN、コンテンツフィルター、組織から配布されたネットワーク設定がある場合は、まず有効状態を確認します。管理対象デバイスでは、新しい設定の追加や変更が禁止されていることがあります。その場合はデバイスの管理者に相談してください。システムプロファイルを何度も削除して試行錯誤しないでください。仕事用ネットワーク、証明書、アクセス要件が含まれている可能性があります。個人のデバイスで古いクライアントを削除する場合も、まず接続を切断し、アプリの案内に従って関連設定を削除します。現在使用中のネットワーク設定を誤って消さないよう注意してください。

オンデマンド接続、Wi-Fi、バックグラウンド制限

オンデマンド接続は手動接続が安定してから有効にしてください。条件に応じて接続を開始または再開する機能であり、失効したサブスクリプションを修復したり、ネットワークのログインページで自動認証したりするものではありません。ホテルや公共Wi-Fiに接続してログインページを開けない場合は、プロキシを一時切断してネットワーク認証を済ませてから再接続します。Wi-Fiとモバイルデータを切り替えた後は、それぞれ同じ宛先をテストし、特定のネットワークだけで問題が起きるか確認してください。ネットワークごとにDNS、IPv6、通信事業者の経路が異なることがあるため、アプリの接続表示だけで判断できません。

iOSのバックグラウンド動作はデスクトップの常駐プロセスとは異なり、アプリ画面を常に表示しておく必要はありません。システムのVPN状態と実際のリクエストで拡張機能の動作を確認してください。アプリを前面に戻すと復旧する場合は、クライアントのログ、システムの省電力状態、自動接続の条件を確認し、発生時のネットワーク種別を記録します。複雑すぎる設定、大きなルールリソース、外部リソースのダウンロード失敗も拡張機能の起動に影響します。まず提供元が対応するシンプルな設定で確認し、ローカルルールや追加リソースを少しずつ加えてください。

DNSのトラブル対処では、ブラウザーやシステムのほかのプライバシー機能によって、名前解決や通信経路が変わる可能性も考慮します。変更は一つずつ、元に戻せる形で行ってください。元の状態を記録し、設定を一項目だけ一時変更して再接続し、同じ宛先へリクエストしてから元に戻します。検査ページに表示されたDNSサービス名だけでは、通信が漏れているとは判断できません。クライアントの通信取り込み方式、問い合わせ経路、宛先への接続ログと合わせて確認します。詳しくはDNSリーク検査とfake-ipのトラブル対処メモをご覧ください。

Linux：デスクトップクライアントとmihomoのサービス運用

デスクトップへのインストールとGUIなしの運用を分けて考える

デスクトップ環境ではLinuxダウンロードからClash Verge RevまたはFlClashを選び、ディストリビューション、CPUアーキテクチャ、ダウンロードページで提供されるパッケージ形式を確認します。サブスクリプション管理や対話的なプロキシ切り替えにはデスクトップクライアントが適しています。サーバーやルーターでは、mihomo単体の導入を優先して検討してください。同じLinuxでも、一般的なデスクトップ、最小構成のコンテナ、ルーター向けOSを同じ実行環境と考えないでください。GUIの依存関係、権限モデル、サービス管理ツール、利用できるメモリーが異なる場合があります。

ディストリビューションのパッケージマネージャーを使い、対応する形式のGUIクライアントをインストールします。共有ライブラリやGUIコンポーネントが不足しているというエラーが出たら、具体的な依存関係を確認してください。見知らぬサイトから共有ライブラリを個別にダウンロードしないでください。GUIからサブスクリプションを追加して設定を有効にしたら、まずローカルプロキシの待ち受けを確認します。Linuxデスクトップでは、システムプロキシがすべてのアプリに適用されるとは限りません。GNOME、KDE、ターミナルツール、個別のアプリがそれぞれ独自の設定を使う場合があります。「システムプロキシを有効にした」ことだけで、すべての通信が取り込まれたと判断しないでください。

ターミナルとデスクトップのプロキシを個別に確認

以下のコマンドが影響するのは、現在のターミナルとそこから起動した子プロセスだけです。マシン全体のルートは変更しません。ここではHTTPとHTTPSの環境変数を、どちらもローカルのHTTPプロキシに向けています。https_proxyはHTTPS宛てのリクエストを示す変数名であり、プロキシアドレス自体をHTTPSにする必要はありません。ALL_PROXYはSOCKSを指定し、socks5hに対応するツールでは、宛先ドメインの名前解決をプロキシ側に任せます。環境変数への対応はツールごとに異なるため、それぞれのドキュメントも確認してください。

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
export no_proxy=localhost,127.0.0.1,::1
curl -I https://example.com/
unset http_proxy https_proxy ALL_PROXY no_proxy

まずは一時的に設定して動作を確認し、問題がなければシェルの起動ファイルに追加するか検討します。システムサービスは対話型ターミナルの環境変数を自動では引き継ぎません。また、sudoを使うと環境変数が削除されることがあるため、実行方法を変えただけで動かなくなるのは珍しくありません。パッケージマネージャー、コンテナのビルド、バージョン管理ツールが個別のプロキシ設定を持つ場合もあります。設定の出所を把握せずに重ねて指定しないでください。明示的に確認するときはcurl --proxyを使い、大文字表記の古い環境変数が残っていないかも調べます。

単体カーネルは設定を検査してから起動する

以下の例はsystemdを使うホスト向けです。ホストのアーキテクチャに合ったmihomo実行ファイルを/usr/local/bin/mihomoに配置済みであることを前提とします。専用ユーザーとアクセス制限された設定ディレクトリを作成し、手元の完全な設定を/etc/mihomo/config.yamlに保存して、必要なファイルをそのユーザーが読み込めるようにしてください。初回導入時の権限拡大を避けるため、この設定例ではTUNを有効にせず、ローカルプロキシだけを提供します。データベースやルールリソースについても、入手元と書き込み可能なディレクトリを明確にしてください。

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -m 750 -o mihomo -g mihomo /etc/mihomo
sudo chown mihomo:mihomo /etc/mihomo/config.yaml
sudo chmod 600 /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo

設定を保存してからファイルの権限を変更します。ユーザーがすでに存在する場合、再作成する必要はありません。ログインを禁止するシェルのパスはディストリビューションによって異なるため、実際の環境に合わせてください。設定の検査が通ったら、以下のユニットファイルを/etc/systemd/system/mihomo.serviceに保存します。サブスクリプションURLをサービスの起動引数に直接含めないでください。プロセス一覧や診断出力に表示される可能性があります。ログは通常の情報レベルで保存し、明確な問題がある場合に限って、短時間だけ詳細度を上げてください。

[Unit]
Description=Mihomo local proxy
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
UMask=0077
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo --no-pager
sudo journalctl -u mihomo -n 80 --no-pager
ss -lntp
curl -I --proxy http://127.0.0.1:7890 https://example.com/

このユニットはサブスクリプションを自動更新せず、透過プロキシも設定しません。設定を変更した後は、構文を再検査し、問題がないことを確認してからサービスを再起動します。起動ログにポートの競合が表示されたら、GUIクライアントや古いサービスの残りを優先して調べてください。重複プロセスを隠すためにポートを次々と変更しないでください。サーバー内だけで使う場合はループバックアドレスで待ち受けます。リモートアクセスには管理された安全な経路とアクセス制限を使い、オープンプロキシをインターネットに公開しないでください。

設定のよくある問題：リクエストの経路に沿って切り分け

サブスクリプションの更新、設定の上書き、YAMLの解析

トラブル対処では、直近で正常に動作した設定を保存し、エラーがどの段階で起きたかを記録します。サブスクリプションの更新失敗ではHTTPステータスと応答形式、設定の読み込み失敗では行番号と項目、カーネルの起動失敗ではポートとファイル権限を確認します。宛先への接続が失敗した場合に、ノード、ルール、DNSを調べてください。これらをすべて「インターネットに接続できない」と一括りにすると、サブスクリプションサーバーの応答が誤っているのにローカルルートを何度も変更することになりかねません。接続済みなのにアクセスできない場合のチェックリストも参考にし、変更は一度に一項目に絞ってください。

YAMLのインデントにはスペースを使い、タブを混在させないでください。リスト項目のハイフン、コロンの後のスペース、文字列内の特殊記号にも注意します。同じ階層でdnsやrulesを重複定義しないでください。どちらの値が残るかを解析ツール任せにすることはできません。クライアントのローカル上書きがサブスクリプションの値を置き換える場合があるため、最終的に有効な設定を基準に確認します。更新後にカスタムルールが消えた場合は、リモートキャッシュを直接編集していないか調べ、長期的な変更はクライアントが対応する上書き機能へ移してください。

DNS、fake-ip、ルールの依存関係

以下はmihomoのDNSとTUNの連携例です。既存の完全な設定に統合し、ポート、権限、使用するカーネルの対応状況を確認してください。切り分け範囲を狭めるため、この例ではIPv6を一時的に無効にしています。これはすべてのネットワークで推奨される設定ではありません。dns-hijackは、該当するTUN経路に入る従来型DNSリクエストを取り込むための設定です。ブラウザーが独自に送信する暗号化DNSも取り込まれるとは限りません。有効にする前にシステムプロキシの動作を確認し、問題が再発した場合はTUNだけを無効にして比較できるようにします。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

fake-ipは、後続の接続でカーネルがドメインとの関連を保てるようにマッピング用アドレスを返します。ノードを偽装することでも、システムDNSが必ず取り込まれていることを示すものでもありません。テストで予約済みアドレスが表示されても、それだけで異常とは判断できません。重要なのは、その後の通信が同じカーネルを通るかどうかです。アプリが古い名前解決結果をキャッシュしている場合は、アプリを再起動して再テストします。互換性の問題が確認されたドメインだけを適切な除外ルールに追加してください。最初からすべてのドメインを対象外にして機能を無効にしないでください。

respect-rulesを有効にすると、関連するDNS接続にも振り分けルールが適用されます。プロキシサーバーのドメイン自体をどう名前解決するかも考慮し、名前解決が循環依存しないようにしてください。この項目だけであらゆる漏えい経路を防げるわけではありません。nameserver、fallback、フィルター条件も、項目名だけを見て単純な優先・予備の順と判断しないでください。これらを組み合わせる場合は、mihomoのDNS設定項目の解説を読み、まずリクエストの経路を把握してから設定してください。

ルールの適用、プロトコル対応、復旧の順序

ルールモードでは、個別ドメインのルールを広範な地理ルールより前に置き、最後にフォールバックを残すのが一般的です。DOMAIN-SUFFIXは利用可能なドメイン情報に依存し、GEOIPは宛先アドレスとデータベースに依存します。リクエストがIPアドレスで行われる場合、ドメインルールに期待どおり一致しないことがあります。プロキシグループが存在していても、選択中のノードが有効とは限りません。接続可能なノードが選ばれているか確認します。データベースの読み込みに失敗した場合は、リソースの場所やダウンロードを先に確認してください。詳しくはGeoIP・GeoSiteデータベースの更新方法をご覧ください。

最後に、追加した変更を逆の順序で戻します。まず新たに有効にしたTUNや自動接続を無効にし、残ったシステムプロキシを削除して、記録しておいたDNS設定に戻し、基本ネットワークが正常なことを確認してから最小構成で再接続します。安定して再現できることを確認した後に、アプリごとの設定、ルールの上書き、バックグラウンドでの自動起動を追加してください。問い合わせ時は、OSの種類、クライアント名、エラーの発生時刻、機密情報を除いたログを共有すれば十分です。サブスクリプション全体やアカウントの認証情報は共有しないでください。接続手順を最初からやり直す場合はクイックスタートガイドへ、症状別の回答を探す場合はよくある質問をご覧ください。