CONFIG.YAML / 全プラットフォーム設定マニュアル

Clash全プラットフォーム設定ガイド。

ダウンロードとアーキテクチャの選び方、サブスクリプションの追加、システムプロキシとTUN、各プラットフォームの権限、接続確認を解説します。

この完全ガイドでは、OSごとの手順を紹介します。インストール前の確認や、移行時の違いのチェック、接続トラブルの原因を順に調べる際にご利用ください。初めて使う方や、まず接続を一度確立したい方はクイックスタートガイドをご覧ください。特定のプラットフォームで権限、通信の引き継ぎ、バックグラウンド動作に問題が起きた場合は、該当する章を参照すれば、設定を最初からやり直す必要はありません。

読み進め方：まず共通の準備を済ませ、次に利用するプラットフォームの章を確認してください。TUN、カスタムDNS、ルールの上書きは、基本の接続が正常に動作してから追加します。設定例はmihomoの構文を前提としています。画面上の項目名や利用できる設定項目は、実際に使うクライアントの対応状況を確認してください。

共通の準備：設定の入手元と通信を引き継ぐ範囲

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

クライアントは設定画面の表示や設定の管理、システム権限の取得を担います。コアは設定の読み込み、ルール判定、接続の確立を行います。サブスクリプションにはノードやプロキシグループが含まれ、DNS設定やルールも提供される場合があります。この3つは別のものです。クライアントをインストールしただけでは接続先のサービスは使えず、サブスクリプションを入手しても、どのクライアントでも読み込めるとは限りません。利用前に有効期限や対応形式、サービス提供元が現在のクライアント向けの追加方法を用意しているかを確認してください。

一般的なデスクトップやスマートフォンで使う場合は、まずダウンロードページからClash Plusを選び、OSの要件に応じてほかのクライアントも比較してください。サービスのプロセス、ルーティング、設定ディレクトリを自分で管理する場合は、mihomoコア単体の利用を検討できます。Clash、Clash.Meta、mihomoには名称の変遷がありますが、古い設定がすべて互換性を持つわけではありません。プロトコル、ルールの項目、DNS機能は実際のコアに対応しているか確認してください。詳しくはコアと設定の互換性ガイドをご覧ください。

端末と現在のネットワーク状態を記録する

ダウンロード前にOS、プロセッサのアーキテクチャ、インストーラの形式を確認します。デスクトップでは、VPNやプロキシソフト、仮想マシンのネットワークアダプター、企業向けセキュリティソフトがすでに動作していないかも確認してください。ほかのプロキシツールを終了し、プロキシを使わない状態で通常のWebページを開けるかテストします。通常の接続にも問題がある場合は、まずネットワークを復旧してください。テスト後に元に戻せるよう、既存のプロキシ設定とDNS設定を記録しておきます。ネットワークアダプターの削除、ルート変更、DNSサーバーの差し替えを一度に行わないでください。

サブスクリプションURLには、設定にアクセスするための権限が含まれることがあります。ログやスクリーンショットを共有する前に、URL全体、ユーザー識別情報、クエリパラメーターを隠してください。追加するときは信頼できる入手元からURL全体をコピーし、メッセージアプリによる改行や末尾の空白、全角の句読点が混ざらないようにします。設定ではなくWebページが表示される場合は、ログインが必要か、URLの有効期限が切れていないか、クライアントが返される形式に対応しているかを確認します。個人情報を含むサブスクリプションを、信頼性の不明な変換サイトに入力しないでください。

システムプロキシとTUNの使い分け

システムプロキシは、OSのプロキシ設定に従うアプリの通信を、ローカルの待ち受けポートに送ります。ブラウザーで基本的な動作確認ができますが、一部のゲーム、コマンドラインツール、独自のネットワーク処理を行うアプリは設定に従わない場合があります。TUNは仮想ネットワークインターフェースを作成し、ルートを通してより多くの通信を引き継ぎます。より高い権限やDNS処理、ネットワークアダプターの設定が必要になることがあります。デスクトップでトラブルを調べる場合は、まずシステムプロキシを確認し、必要に応じてTUNに切り替えてください。モバイルでは通常、OSのVPN拡張機能を通じて通信を引き継ぐため、デスクトップの切り替え方をそのまま当てはめないでください。

方式対象範囲最初に確認する項目
システムプロキシシステム設定に従うアプリ待ち受けアドレス、ポート、除外リスト
TUNによる通信の引き継ぎ仮想ネットワークアダプターとルートを通る通信サービスの権限、ルート、DNS、ほかのVPN
アプリごとのプロキシプロキシを明示的に設定したアプリプロキシのプロトコルとアプリ独自の設定

最小限の設定で動作を確認する

以下は基本項目の例です。利用可能な設定に追加して使うもので、ノードやプロキシグループは含まれていません。ポートはクライアントに表示される実際の値を使ってください。クライアントによっては、設定画面のポートがサブスクリプション内の値より優先されます。ローカルアクセスとルールモードを維持し、最初はLANへの公開を避けてください。YAMLではインデントにスペースを使い、コロンの後にスペースを入れ、同じ階層の項目をそろえます。読み込みエラーが出たら、まず該当行を確認してください。構文エラーを隠すためにルール全体を削除しないでください。

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

設定を追加したら、3段階で動作を確認します。設定を読み込めるか、選択したノードに接続できるか、宛先へのリクエストが想定したポリシーに一致するかを順に確認してください。ノードを1つ選び、頻繁な自動速度測定は有効にせず、直接接続する宛先とプロキシ経由にする宛先へアクセスします。接続画面でポリシーと出口を確認してください。成功したら設定のコピーを保存し、通信を引き継ぐ方式を記録します。その後ルールやDNSを追加するときは、一度に1項目だけ変更すれば、どの変更が影響したか判断できます。

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

アーキテクチャに合った方法でインストールし、移行用の設定を保存する

「設定」→「システム」→「バージョン情報」でシステムの種類を確認し、一般的なx64とARMデバイスを区別します。まずWindowsのダウンロードページでClash Plusを確認してください。そのほかの候補はClash Verge Rev、FlClash、Clash Nyanpasuです。Clash for Windowsは開発が終了しているため、明確な互換性の要件がある場合に限り、アーカイブを参照してください。名称に見覚えがあるからといって、古いクライアントを新しい端末の標準にしないでください。異なるアーキテクチャのインストーラを混在させ、何度も試すのも避けましょう。

古いクライアントから移行する前に、サブスクリプションの入手元、手動で選んだプロキシグループ、カスタムルール、アプリ専用のプロキシ設定を記録してください。エクスポートできるローカル設定は別のフォルダーに保存します。ただし、データディレクトリ全体を新しいクライアントにそのまま上書きしないでください。データベース、画面設定、サービスの状態は互換性がない場合があります。新規インストールでは標準のデータディレクトリを使い、基本接続ができてからカスタム設定を1つずつ移します。移行時の判断についてはClash for Windowsからの移行手順をご覧ください。

インストーラの入手元とシステムの警告を確認してから起動します。インストール後はまず一般ユーザーとしてクライアントを開き、日常的な操作すべてに管理者権限を使う必要はありません。セキュリティ機能が実行をブロックした場合は、ブロックされた項目と組織のポリシーを確認してください。起動のためにシステムの保護機能を丸ごと無効化しないでください。会社管理の端末では、プロキシ、ドライバー、サービスのインストールが制限されている場合があります。こうした制限は端末の管理者に確認してください。許可を何度もクリックしても、ポリシーによる制限は解決しません。

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

設定またはサブスクリプションの管理画面でリンクから追加し、URL全体を貼り付けてダウンロードが完了するまで待ちます。設定が一覧に表示されたら、現在の設定として選択し、プロキシ画面でプロキシグループとノードが読み込まれているか確認してください。サブスクリプション名が表示されただけでは、コアが切り替わったとは限りません。一覧が空の場合は、更新結果と設定読み込みのログを確認します。更新に失敗したら元の設定を残し、削除と再作成を何度も繰り返さないでください。動作しているキャッシュまで消えることがあります。

ルールモードを選び、手動選択が必要なプロキシグループでノードを選んでから、システムプロキシを有効にします。Windowsの「ネットワークとインターネット」→「プロキシ」で、アドレスとポートを確認してください。通常はローカルのループバックアドレスと、クライアントに表示される待ち受けポートを指定します。ブラウザーにプロキシ拡張機能を入れている場合は、拡張機能による通信の引き継ぎを一時的に無効にしてください。拡張機能に保存された古いポートを使うと、システム設定が正しくても現在のコアにリクエストが届かないことがあります。

テストページを開きながら、クライアントの接続一覧を確認します。ページを開けず、対応するリクエストも一覧に表示されない場合は、まずブラウザー独自のプロキシ設定、システムの除外リスト、ローカルの待ち受けを確認してください。リクエストが表示されるのに接続できない場合は、ノード認証、接続先への到達性、ルールの選択を確認します。システムプロキシを読み直すため、アプリの再起動が必要な場合もあります。コマンドラインツールは環境変数しか参照しないことがあるため、ブラウザーで成功しても、すべてのアプリが通信を引き継いでいるとは限りません。

TUNを有効にして権限エラーを確認する

システムプロキシに従わないアプリがある場合に、TUNを有効にします。クライアントによっては、サービスモードのインストールや補助プロセスへの許可が必要です。画面の案内に従い、スイッチがオンになったかだけでなく、サービスが起動しているかも確認してください。最初のテストではシステムプロキシを無効にし、TUNだけを有効にすると、通信経路を確認しやすくなります。仮想ネットワークアダプターを作成できない場合は、権限やドライバーのエラーを確認します。ルートの追加に失敗した場合は、ほかのVPN、仮想マシンのネットワーク、残存サービスを確認してください。

ローカルのポートが使用中の場合は、PowerShellで待ち受けプロセスを確認できます。以下のコマンドは例示したポートを調べるだけで、プログラムを終了しません。設定画面のポートが異なる場合は、実際の値に置き換えてください。プロセスIDが分かったら、タスクマネージャーでアプリを確認します。古いツールを通常の方法で終了してから、現在のクライアントを再起動してください。ポートが使用中というだけで、正体の分からないプロセスをまとめて終了しないでください。システムサービスや開発ツールがローカルポートを使っている場合もあります。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

スリープから復帰したときや、有線LANからWi-Fiに切り替えた後に接続が途切れた場合は、通信の引き継ぎを一度オフにしてから再びオンにし、コアがデフォルトのネットワークアダプターを認識しているか確認します。TUNだけが不調でシステムプロキシは正常なら、ノードのプロトコルを適当に変更したり、サブスクリプションを買い直したりせず、ルートとネットワークアダプターを調べてください。ファイアウォールの許可範囲は、必要なアプリとネットワークに限定します。allow-lan: falseのままなら、同じ端末のブラウザーからアクセスするためにLAN全体への着信を許可する必要はありません。

最後に終了時の動作を確認します。クライアントでシステムプロキシまたはTUNをオフにしてから通常終了し、ブラウザーで直接接続できることを確かめてください。異常終了後にインターネット全体へ接続できなくなった場合は、システムにローカルプロキシのアドレスが残っていないか確認し、事前に記録した設定に戻します。接続が安定した後で自動起動を検討してください。ログイン時の自動起動、サービスの起動、自動接続は別々の設定です。端末へのログイン時に複数のクライアントが同時にプロキシ設定を変更しないよう、それぞれ個別にテストしてください。

macOS：チップの種類、補助サービス、ネットワーク環境

チップに合ったインストーラを選び、初回起動時の設定を確認する

Appleメニューの「このMacについて」を開き、AppleシリコンかIntelプロセッサかを確認してから、macOSのダウンロードページで対応するアーキテクチャを選びます。まずClash Plusを検討し、Clash Verge RevやFlClashも比較できます。ClashX Metaは開発が終了しているため、過去の動作を確認する必要がある場合を除き、移行時に注意してください。互換レイヤーで動作しても、長期利用に最適とは限りません。余計な互換処理を避けるため、端末のチップに合ったパッケージを優先してください。

ディスクイメージからインストールする場合は、アプリを「アプリケーション」フォルダーにコピーしてから起動してください。イメージをマウントしたまま、またはダウンロードフォルダーから長期間実行しないでください。更新や補助サービスのパス、システム権限の情報を整合させやすくなります。初回起動がブロックされたら、まず入手元を確認し、「プライバシーとセキュリティ」に表示された手順に従います。出所の不明なターミナルコマンドで全アプリのセキュリティ属性を削除したり、起動できない原因をすぐにサブスクリプションの問題と決めつけたりしないでください。

補助サービスが必要な場合は、クライアント本体とバックグラウンドコンポーネントを区別してください。システムプロキシの変更、仮想ネットワークアダプターの作成、ルートの管理には、管理者の許可が一度必要な場合があります。許可した後は、クライアントに戻りサービスの状態を確認します。アプリの場所を移動したり、同種のツールに切り替えたりした場合は、古いサービスのパスが無効になっていることがあります。クライアントの修復またはアンインストール機能で対応し、アプリのアイコンをゴミ箱に入れるだけでバックグラウンドコンポーネントを残さないようにしてください。

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

設定画面でサブスクリプションURLを追加し、ダウンロードと解析が完了したら、その設定を選択します。まずプロキシグループがあるか、選択中のノードが有効かを確認し、ルールモードを維持してください。クライアントが未対応の項目を含む場合、ログに項目名やプロトコルが表示されることがあります。設定の入手元に互換性のある形式を問い合わせるか、その項目に対応するクライアントを使ってください。エラー行をそのまま削除すると、リモート接続に必要な設定まで失われるおそれがあります。

システムプロキシを有効にし、「システム設定」の「ネットワーク」で、現在使用中のネットワークサービスを開き、詳細情報のプロキシ項目を確認します。Wi-Fiと有線ネットワークでは設定が別々の場合があります。実際に通信している接続を選んでください。アドレスは通常ローカルのループバックアドレスで、ポートはクライアントと同じです。ブラウザーでは接続できてもターミナルでは失敗する場合は、ターミナルのツールがシステムプロキシを参照するか確認します。どちらも失敗する場合は、待ち受けプロセスと設定の読み込み状態を調べてください。

システムプロキシの除外リストによって、ローカルプロキシを経由しない宛先が決まります。社内ネットワーク、プリンター、ローカルの開発用アドレスは直接接続が必要な場合があるため、テストのためにすべての例外を恒久的に削除しないでください。逆に、ドメインやアドレス範囲を広く指定しすぎると、プロキシを経由するはずのリクエストまで迂回することがあります。変更前の値を記録し、特定の宛先で再テストして、接続画面にリクエストが表示されるか確認してください。メニューバーのスイッチを見るだけでは、実際の通信経路は分かりません。

TUN、スリープ復帰、DNSキャッシュ

TUNを有効にする前に補助コンポーネントを許可し、ほかのVPNを一時停止します。クライアントによって通信の引き継ぎ方法やサービス管理が異なり、システムの権限確認画面も同じとは限りません。使用中のアプリの説明に従ってください。最初の確認ではシステムプロキシを一時的にオフにし、ルールログで通信がTUN経由で届いていることを確認します。起動時にデフォルトのネットワークアダプターやルートのエラーが出た場合は、そのときのインターフェースとほかのネットワーク拡張機能の状態を記録してから、補助サービスの再起動を検討してください。

ノートPCがスリープから復帰したとき、テザリング先を切り替えたとき、Web認証が必要な公共Wi-Fiに接続したときは、以前の接続やDNSの結果が一時的に使えなくなる場合があります。まずプロキシをオフにしてネットワーク認証を済ませ、接続し直してください。一部のドメインだけ名前解決に失敗する場合は、DNS設定を確認してからシステムのキャッシュを更新します。以下のコマンドには管理者権限が必要です。削除するのは端末内のキャッシュだけで、サブスクリプション、リモートノード、誤ったDNS設定は修復しません。あらゆる問題に対する最初の手段として使わないでください。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

ブラウザーによっては独自の暗号化DNSを使い、アプリが既存の接続を長時間保持する場合もあります。DNSのルールを変更した後は、テスト中のタブを閉じるかアプリを再起動して、新しいリクエストを確認してください。fake-ipを使っている場合、キャッシュにある仮想アドレスを実在するサーバーのアドレスとみなして手動で接続テストしないでください。仮想アドレスは対応するコアが解釈する必要があります。名前解決の動作と通信先の出口は、接続ログと合わせて判断してください。コマンドラインで一度確認しただけで結論を出さないでください。

移行後は、ブラウザー、プロキシが必要なデスクトップアプリ、直接接続すべきLAN内サービスの順に確認します。最後に通信の引き継ぎをオフにしてクライアントを終了し、ネットワークが正常に戻るか確認してください。特定のネットワーク環境だけで問題がある場合は、すべてのネットワークサービスを削除せず、その環境に保存されたプロキシ設定とDNS設定を比べます。元に戻せる設定を保存しておくと、OS、クライアント、サブスクリプションのどの更新が影響したか切り分けやすくなります。

Android：アーキテクチャ、VPNの許可、バックグラウンド動作

ダウンロードとインストールの前に端末を確認する

まずAndroidのダウンロードページでClash Plusを確認し、次にClash Meta for Android、FlClash、Surfboardを検討してください。一般的なスマートフォンではARM64が使われていますが、古い端末や特定のOSでは別のパッケージが必要な場合があります。端末情報とダウンロードページの説明に従って選んでください。インストールに失敗したら、OSが表示する原因を確認します。アーキテクチャの不一致、OSの要件不足、ストレージ不足、署名の不一致では対処方法が異なります。同じファイルを何度もダウンロードするだけでは解決しません。

ブラウザーやファイル管理アプリからインストールする場合、OSでその入手元からのアプリインストールを許可する必要があることがあります。利用する入手元だけを許可し、完了後は必要に応じて許可を取り消してください。旧版と新版で署名が異なると、上書きインストールが拒否される場合があります。アンインストールする前にサブスクリプションとローカルルールをエクスポートし、設定を再入手できることを確認してください。通常、アンインストールするとアプリ専用データも削除されます。バックアップをチャットグループや公開クラウドに置かないでください。サブスクリプションURLだけでアカウントの設定にアクセスできる場合があります。

SurfboardとClashシリーズの設定は、同じ形式としてそのまま使えるとは限りません。インポート前に、サービス提供元が対応形式を用意しているか確認してください。両方のアプリに同じプロトコル名が表示されても、ルール構文やサブスクリプションの内容に互換性があるとは限りません。クライアントは画面の使い勝手より先に、設定の入手元が対応しているかを確認して選びましょう。形式の変換は確認項目を増やすため、基本接続を確立するまでは、サービス提供元が明示的にサポートする標準の追加方法を使ってください。

設定を追加してVPN接続を許可する

設定管理画面でリモートサブスクリプションを新規追加し、URLを貼り付けてダウンロードした後、その項目を有効な設定として選択します。QRコードで追加する場合は、読み取った内容がサブスクリプション、単一ノード、Webログイン用URLのどれかを確認してください。読み取りに成功しただけでは設定が有効とは限りません。ダウンロードできない場合は、端末の時刻、ネットワーク認証の要否、サブスクリプションの有効期限を確認します。追加できてもプロキシグループがない場合は、設定形式と解析結果を調べてください。

初回接続時にAndroidのVPN接続リクエストが表示されるのは、システムのインターフェースを使って端末の通信を引き継ぐためです。インストールしたクライアントからのリクエストであることを確認してから許可してください。一般的な端末では、同じユーザー環境で同時に利用できるアクティブなVPNは通常1つです。ほかのVPN、ファイアウォール、ローカルVPNを使うフィルタリングアプリによって、現在の接続が置き換えられる場合があります。ステータスバーのVPNアイコンはトンネルが存在することを示すだけで、リモートノードやDNSが正常とは限りません。

ルールモードを維持してノードを選び、ブラウザーを開いて接続画面で適用されたルールを確認します。スマートフォンでVPN経由の通信を引き継ぐ場合、デスクトップ向けの手順どおりにシステムHTTPプロキシを設定する必要はありません。Wi-Fiの詳細設定にある手動プロキシは、そのWi-Fiだけに適用される設定です。2つの方式を混在させると原因を特定しにくくなります。別の端末のプロキシに接続するなど明確な理由がない限り、Wi-Fiのプロキシ設定を元に戻してから、クライアントのVPN接続をテストしてください。

アプリごとの通信設定とバックグラウンド制限

アプリごとのプロキシ設定には、「選択したアプリだけをプロキシ経由にする」と「選択したアプリを除外する」という逆の意味の方式があります。設定前に画面の説明をよく読んでください。初回はアプリの絞り込みを設定せず、通信全体が引き継がれることを確認してから例外を追加すると簡単です。特定のアプリが接続一覧に表示されない場合は、除外されていないか、仕事用プロファイルや別のユーザー環境で動作していないか、別のVPNが通信を引き継いでいないか確認してください。すぐにノードの問題と決めつけないでください。

画面を消した後に接続が切れる場合、OSのバッテリー最適化、バックグラウンド動作の制限、メーカー独自の自動起動管理が原因としてよくあります。まずクライアントをバックグラウンド実行の許可対象に加え、必要なフォアグラウンドサービスの通知を表示したままにしてください。設定メニューの名称はメーカーによって異なるため、OSの検索でバッテリーとバックグラウンドの管理項目を探します。すべてのアプリの制限を一度に解除しないでください。許可後も、画面消灯、ネットワーク切り替え、システムのアプリ整理の3つを個別に試し、どの動作でサービスが止まるか確認します。

「常時接続VPN」と「VPN未接続時の通信をブロック」は、端末全体に適用される設定です。後者を有効にするとクライアント切断中の通常通信もブロックされるため、基本接続が安定する前に有効にしないでください。スマートフォンのプライベートDNS、ブラウザーの暗号化DNS、クライアントのDNSは、それぞれ異なる経路で名前解決する場合があります。現在の設定を記録してからログで実際のリクエストを確認し、すべてのDNS設定を同時に変更して比較できなくならないようにしてください。

バッテリー消費を調べるときは、自動速度測定の頻度と不要なログを減らし、通信が続いているのか、頻繁に再接続しているのか、バックグラウンド更新で端末が起動しているのかを確認します。ヘルスチェックの間隔を短くしても安定性が上がるとは限りません。ネットワークの切り替え時に測定を繰り返すと、かえって負荷が増えることがあります。スマートフォンのバックグラウンド動作とバッテリー設定の比較も参考に、項目ごとに調整してください。接続に必要な最小限の機能に絞り、OSのアップデート後はバックグラウンド権限を再確認します。

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

App Storeでアプリと設定形式を確認する

iPhoneとiPadでは、当サイトではClash Plusをおすすめしています。iOSのダウンロードページからApp Storeを開くか、Clash PlusのApp Storeページへ直接アクセスしてください。製品の公式サイトはclashplus.ioです。インストール前に、App Storeに記載されている最新のOS要件を確認し、端末が対応していることを確かめてください。デスクトップ向けのファイルインストール手順をスマートフォンに当てはめないでください。モバイルでは権限や設定の保存方法が異なります。

サブスクリプションを用意する前に、Clash Plusが現在対応している追加形式を確認してください。ファイルの拡張子が同じでリンクがHTTPSから始まっていても、内容に互換性があるとは限りません。デスクトップ向けの設定には、ローカルパス、外部スクリプト、特定のコア専用の項目が含まれることがあり、モバイルでは実行できない場合があります。サービス提供元が専用のサブスクリプションを提供している場合は、対応するものを優先してください。単一ノードの情報だけがある場合は、アプリのノード追加手順に従って入力します。リモート設定のURL欄に貼り付けないでください。

iOSではアプリのサンドボックスとバックグラウンド拡張に明確な制限があり、PCで直接編集できる設定ディレクトリをそのまま使うことはできません。ローカルファイルを追加する場合は、アプリが対応するファイル読み込みまたは共有機能を使います。追加後に独立したコピーが作成されるか、自動更新されるか確認してください。「ファイル」アプリに表示されていても、クライアントがその場所を継続して読み込むとは限りません。PCでファイルを変更すればスマートフォンにも反映される、という意味ではありません。

サブスクリプションを追加してVPN設定を許可する

アプリの設定またはサブスクリプション管理画面からリモートサブスクリプションを追加し、内容が読み込まれるまで待ちます。プロキシグループ、ノード、ルールが表示されたら、有効な設定として選択してください。更新が止まった場合は、通常のネットワークで端末がインターネットに接続できるか、公共Wi-Fiのログイン画面が残っていないかを確認します。続いてURLの有効期限と必要な形式を確認してください。同じテスト中にWi-Fi、サブスクリプションの入手元、アプリの設定を同時に変えると、どの変更が効果をもたらしたか分かりにくくなります。

初回接続時は、通常システムからVPN設定の追加を求められます。画面の案内に従って認証してください。許可したらアプリに戻って接続状態を確認し、システムのVPN管理画面で有効になっている設定が該当アプリのものか確かめます。古いVPN、組織から配布された設定、ほかのネットワーク拡張機能がある場合は、それぞれの用途を先に確認してください。管理対象の端末では設定変更が制限される場合があります。用途が分からない企業設定を削除して接続を試すのではなく、端末の管理者に許可範囲を確認してください。

接続ボタンが有効でも、アプリが通信の引き継ぎを試みていることしか分かりません。プロキシポリシーを選んで実際にリクエストを送り、アプリの接続画面やログで結果を確認してください。直接接続する必要があるローカルサービスも、個別にテストします。モバイルのVPN拡張は、デスクトップのシステムプロキシを同じ名前で置き換えるものではありません。通常、Wi-Fi設定にローカルポートを追加する必要はありません。以前に設定した手動プロキシがあれば、記録してから元に戻し、経路の判断に影響しないようにします。

オンデマンド接続、ネットワーク切り替え、LANアクセス

オンデマンド接続機能がある場合は、基本接続が安定してから設定し、条件を1つずつ確認してください。ネットワークの種類やWi-Fiの条件で判定する方式もあれば、ドメインへのリクエストをきっかけに接続する方式もあります。「自動」という表示だけから動作を推測しないでください。初回テストでは、画面ロック後の復帰、Wi-Fiからモバイル通信への切り替え、モバイル通信からWi-Fiへの復帰を確認します。切り替え後に短時間だけ通信が途切れる場合は、拡張機能の再接続とDNS更新を確認し、すぐにすべてのルールをグローバルに変更しないでください。

公共ネットワークでWeb認証が必要な場合は、自動再接続を一時停止してログインし、その後接続を再開してください。オンデマンドルールが、まだ使えないネットワークに通信を送り続けることがあります。家庭内ストレージ、プリンター、画面ミラーリング機器にアクセスする場合は、アプリのLANアクセス権限と設定の直接接続ルールを確認します。機器の検出にはブロードキャストやマルチキャストも関係するため、ドメインルールを1つ追加するだけでは不十分な場合があります。機器の検出に失敗しているのか、既知のアドレスへの接続に失敗しているのかを切り分けてください。

mihomoのTUNやDNS設定を丸ごとスマートフォンの設定に貼り付けて、動作すると思い込まないでください。モバイルクライアントは設定方式が異なる場合や、一部の項目にしか対応していない場合があります。インポート結果と機能の説明を確認してください。ブラウザー独自の名前解決、システムのプライバシー機能、VPN拡張の連携も確認結果に影響します。比較のために設定を変えるときは、一度に1項目だけ一時的に変更し、元の状態を記録してください。テスト後は関係のない設定を元に戻します。

画面消灯後にバッテリー消費が増えた場合は、頻繁な速度測定、継続的なログ出力、更新頻度の高さ、不安定なネットワークによる再接続がないか確認してください。バックグラウンド拡張が動作を続けられるかどうかは、OSのスケジュール管理やリソースにも左右されます。デスクトップの常駐プロセスと同じように動作すると考えないでください。アプリを何度も強制終了して再起動するより、必要な範囲で更新間隔を調整すると原因を見つけやすくなります。詳しくはモバイルのバックグラウンド動作とバッテリー管理をご覧ください。

端末を交換する前に、サブスクリプションの入手元と必要なカスタムルールを別々に保存してください。システムのバックアップにすべての機密設定が含まれるとは限りません。移行後は有効なサブスクリプション、プロキシグループの選択、オンデマンド条件を確認し、2種類のネットワークでテストします。長期間使わない場合はアプリ内で切断し、システムのVPN状態を確認してください。Webページに問題があるときは、オンデマンド接続が自動で再開していないか先に確認します。アプリ画面を閉じただけでは通信の引き継ぎが停止していないことがあります。

Linux：デスクトップへのインストール、コアの実行、ルートの確認

デスクトップクライアントとパッケージ形式を選ぶ

Linuxデスクトップでは、まずLinuxのダウンロードページでClash Verge Revを確認し、次にFlClashを検討してください。ディストリビューションに合わせてDEBまたはRPMを選び、プロセッサのアーキテクチャも確認します。パッケージ形式とアーキテクチャは別の要素です。Linuxであるというだけで、異なるパッケージを使い回せるわけではありません。サーバー、ルーター、GUIのない端末ではコアの利用も検討できますが、設定ディレクトリ、プロセス管理、ログ、ルートを自分で管理する必要があります。ファイルが小さいからという理由だけで、コア単体を優先しないでください。

インストール前に、以下のコマンドでアーキテクチャとディストリビューションの情報を確認できます。一般的なx86_64は通常AMD64、aarch64は通常ARM64に対応します。ルーターでは浮動小数点演算や命令セットの条件が異なることもあるため、端末ごとの仕様を確認してください。ダウンロードページに掲載されたデスクトップ用パッケージは、すべてのアーキテクチャを網羅していません。対応しない場合に依存関係を無視して強制インストールすると、起動時にエラーが出るだけです。

uname -m
cat /etc/os-release

ディストリビューションのパッケージ管理ツールでローカルパッケージをインストールし、不足している依存関係やGUI環境に関する警告を確認してください。クライアントの画面が開いてから、プロキシやサービスの権限を設定します。ディスプレイサーバーやデスクトップライブラリの不足と、ネットワークの問題を混同しないためです。同種のツールを複数インストールしている場合は、ほかのプロセスとバックグラウンドサービスを停止してください。同じポートを取り合ったり、複数のサービスが同時にルートを変更したりすると、起動直後に接続が切れることがあります。

サブスクリプションを追加してデスクトップのシステムプロキシを設定する

GUIクライアントでリモートサブスクリプションを追加し、ダウンロードが終わったら現在の設定に指定して、プロキシグループを確認します。Linuxデスクトップのシステムプロキシの動作は、デスクトップ環境やアプリの実装によって異なります。ブラウザーはデスクトップの設定を参照しても、ターミナルのツールは環境変数しか参照しない場合があります。システムプロキシを有効にしたら、まずブラウザーをテストし、次に明示的なプロキシ指定を使ってターミナルから確認します。これにより、コア自体が使えないのか、アプリがデスクトップのプロキシ設定を使っていないのかを切り分けられます。

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

ポートはクライアントが実際に待ち受けている値に合わせてください。テスト用URLはリクエストを送るためのもので、HTTPステータスが返ってもすべての通信が正常とは限りません。接続ログでリクエストが記録され、どのプロキシポリシーが適用されたかを確認します。環境変数を一時的に設定する場合は、まず現在のターミナルだけでテストし、すぐにシステム全体の設定へ書き込まないでください。ツールによって環境変数の大文字・小文字やSOCKS・HTTPプロキシへの対応が異なり、個別の設定が優先される場合もあります。

コア単体での実行と最小限の権限

mihomoを単体で使う場合は、専用の設定ディレクトリを作り、動作確認済みの設定をconfig.yamlとして保存します。設定から参照されるルールファイルなども用意してください。以下では、展開した実行ファイルの名前をmihomoとし、ユーザーディレクトリ内の専用フォルダーに設定を置くものとします。設定をテストした後、まずフォアグラウンドで起動してエラーを確認してください。構文チェックに通る前に、自動起動サービスを作成しないでください。

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

基本的なプロキシの待ち受けには管理者権限が不要な場合がありますが、TUNの作成、ルートの変更、一部のDNS操作には追加の権限が必要です。GUIクライアントにはサービス管理機能が用意されていることがあります。コア単体で使う場合は、ディストリビューションのサービス管理と権限の仕組みに合わせてください。デスクトップのセッション全体で高い権限を使い続けたり、十分に確認していないサブスクリプションを幅広いシステム権限を持つプロセスに読み込ませたりしないでください。リモート管理インターフェースは必要な場合だけ有効にし、待ち受け範囲とアクセス権を制限します。

TUN、DNS管理、リモート端末での復旧手段

TUNを有効にする前に、システムが必要な仮想ネットワークデバイスに対応しているか確認し、現在のルート、ほかのVPN、ファイアウォールのルールを調べてください。システムの名前解決はNetworkManager、systemd-resolvedなどが管理している場合があります。/etc/resolv.confを直接上書きすると、管理ツールにすぐ書き戻されたり、既存の設定を壊したりすることがあります。まずこのファイルがシンボリックリンクかどうかを確認し、DNSの管理元を特定してから、クライアントが対応する方法で設定してください。互いの設定を上書きするDNSハイジャック方式を複数同時に有効にしないでください。

SSHでサーバーを遠隔操作している場合は特に注意が必要です。デフォルトルートを変更すると、管理用の接続までプロキシに入り、セッションが切断されるおそれがあります。コンソールなどの復旧手段を確保し、管理先への直接接続ルールを確認してから通信の引き継ぎ範囲をテストしてください。ip routeとip ruleで変更を確認し、クライアントのログで実際のリクエストを検証します。仮想ネットワークアダプターが表示されても、ポリシールーティングや名前解決が正しいとは限りません。

基本動作が安定してからサービス管理ツールに登録します。実行ファイル、作業ディレクトリ、設定ファイルのパスを固定し、更新時に一時ダウンロード先を参照しないようにしてください。サービスは実行ユーザー、環境変数、対話型ターミナルの条件が手動実行と異なります。手動では動くのにバックグラウンドでは失敗する場合、ノードを変更するのではなく、パス、読み取り権限、ログを確認してください。最後にサービス停止後にルートが元に戻り、DNS設定が復旧するかを確認します。動作する設定を保存し、以降は一度の更新で変更する要素を1つに絞ってください。

設定でよくある問題：サブスクリプション、ルール、DNS、動作確認

サブスクリプションの更新失敗と設定の上書き

まず「URLからダウンロードできない」場合と「ダウンロード後に設定を解析できない」場合を区別します。前者はネットワーク、端末の時刻、ネットワーク認証、サブスクリプションの権限、サービス提供元の状態を確認してください。後者は返された形式、プロトコルの対応状況、YAMLの行番号を調べます。ログイン画面やエラーページが返された場合、ダウンロード要求が応答を受け取っていても、有効な設定ではありません。一部のクライアントでは更新時に直接接続かプロキシ経由かを選べますが、比較するのは利用可能な設定がすでにある場合だけにしてください。まだ確立していないプロキシ経由で、唯一のサブスクリプションを更新しようとしないでください。

サブスクリプションを更新したらカスタムルールが消えた場合、リモート設定のキャッシュを直接編集していた可能性があります。継続して使う設定はクライアントの上書きまたはマージ機能に移し、ルールが先頭に追加されるのか、末尾に追加されるのか確認してください。一般的なルールは上から順に最初に一致したものが適用されるため、末尾に置いたカスタムルールは判定されないことがあります。リモートの元設定とローカルの拡張設定を別々に保存し、問題が起きたらまず拡張を一時的に無効にして確認します。ほかの対処方法はサブスクリプション更新時によくある問題をご覧ください。

ルールモード、グローバルモード、ノードのテスト

ルールモードではルールに応じてプロキシポリシーを選び、グローバルモードではコアに入った通信をグローバルのプロキシグループへ送ります。直接接続モードでは通常、通信がそのまま接続先に送られます。これらのモードが制御するのは、すでにコアに届いている通信です。通信が引き継がれていないアプリを自動的にプロキシへ接続する機能ではありません。グローバルモードでは使えるのにルールモードでは失敗する場合は、ルールが直接接続や空のポリシーグループを選んでいないか確認してください。両方で失敗する場合は、ノードと通信の引き継ぎを確認します。グローバルモードでDNSや権限の問題まで解決するわけではありません。

ノードテストで分かるのは、特定のテスト先に対する一度のリクエスト結果にすぎません。実際のダウンロード速度、すべてのWebサイトへの接続、長期的な安定性が保証されるわけではありません。テストは成功しても目的のサイトを開けない場合は、適用ルール、リモートサービスの制限、接続プロトコルを確認してください。テストが失敗してもWebページを開ける場合は、テスト先とタイムアウト条件を確認します。一度の結果でノードをまとめて削除せず、同じネットワーク、同じ接続先で比較してください。詳しくはノードの遅延時間についてと通信速度を段階的に調べる方法をご覧ください。

fake-ip、DNSハイジャック、アプリのキャッシュ

fake-ipはドメインに仮想アドレスを割り当て、その後の通信が同じコアに入ると、ドメイン名に対応付けてルール判定に使います。目的はドメイン名と接続を関連付けることであり、有効にするだけですべての名前解決が同じ出口を通るわけではありません。アプリがシステムの名前解決を迂回したり、ブラウザーが独自の暗号化DNSを使ったり、古いキャッシュに実際のIPアドレスが残っていたりすると、確認結果が異なります。以下はmihomo向けの設定例です。既存の設定とクライアントの対応状況に合わせて追加してください。モバイル共通のテンプレートではありません。

dns:
  enable: true
  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

例にある上流DNSは、現在のネットワークとルーティングポリシーで到達できる必要があります。上流DNS自体に接続できない場合、キャッシュを何度消しても解決しません。53番ポートの通信を横取りしても、あらゆる暗号化DNSを引き継げるわけではありません。ドメインに応じて上流DNSを選ぶ場合は、上流のドメイン名を最初にどう解決するか、リモートノードのドメイン名との間で名前解決のループが起きないかも確認します。LAN内のドメイン名、機器の検出、特定アプリには必要に応じて例外を設定できますが、対象を具体的に絞り、すべてのドメインを迂回させないでください。

DNSを確認するときは、システムの名前解決、アプリのリクエスト、接続ログを合わせて見てください。検査ページに特定の地域が表示されたというだけで、DNS漏えいと決めつけないでください。再帰DNSサーバーの所在地とWebサイトから見える出口IPアドレスは、必ずしも一致しません。キャッシュ、パブリックDNSの振り分け、検査方法も結果に影響します。DNSの漏えいを調べる場合は、想定する経路を明確にしてから特定のクエリを確認してください。手順はDNSテストとfake-ip設定の実践ガイドをご覧ください。

すべてをリセットせず、問題の層ごとに切り分ける

症状優先して確認する項目確認方法
接続画面にリクエストが表示されないシステムプロキシ、アプリの除外設定、TUNのルートローカルプロキシを明示してテストする
リクエストは届くが接続に失敗するノード認証、接続先への到達性、プロキシポリシー接続先を固定してノードを1つ変更する
ドメイン名だけ接続に失敗する上流DNS、キャッシュ、DNSの引き継ぎDNSクエリとコアのエラーログを確認する
クライアントを終了してもネットワークに接続できない残存プロキシ、ルート、端末レベルのVPNポリシーインストール前に記録したネットワーク設定に戻す

速度が遅い場合は、まず接続先のサービス側で速度制限がないか確認し、同じノード、同じネットワーク、近い時間帯の結果を比べます。大容量通信の一部だけが止まる場合は、MTU、UDPの経路、ネットワーク機器との相性を調べてください。ネット上で見つけた固定のMTU値を、すべてのプラットフォームに使わないでください。一時的にログの詳細度を上げると原因を調べやすくなりますが、再現できたら通常のレベルに戻します。ログを外部に共有する前に、サブスクリプション、認証情報、個人のアクセス履歴を削除してください。

クイックスタートに戻って確認するタイミング

設定のどこを変更したか分からなくなったら、まず現在の状態をバックアップします。有効なサブスクリプションを1つ選び、通信を引き継ぐ方式を1つだけ有効にして、サブスクリプションの追加とモードの選び方に沿って比較できる状態を作り直してください。基本接続が成功したら拡張設定を1つずつ戻し、追加のたびに動作を確認します。ネットワーク設定全体をリセットするより、原因を追いやすく、手がかりも残せます。

最終確認では、プロキシ経由の接続、直接接続、LAN内サービス、ネットワークの切り替え、通信の引き継ぎ停止の5項目をテストしてください。正常時の待ち受けポート、有効な設定、モード、権限の状態を記録しておくと、後で変化が起きたときに比較できます。このガイドでは設定の範囲と分岐を説明しています。個別の問題はよくある質問もご覧ください。安定して使えているなら、必要を満たす設定に項目を増やすためだけの変更は不要です。