PLATFORM SETUP / CONFIGURATION REFERENCE

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

Windows / macOS / Android / iOS / Linux
ダウンロード、サブスクリプション、システムプロキシ、TUNの設定ガイド

初めて接続する場合は、まず使い方ガイドのクイックスタートに沿って、設定の追加、プロキシグループの選択、接続まで進めてください。このページでは、OSごとの導入方法や権限、トラブル時の確認ポイントを解説します。問題が起きた場合は、該当するOSの項目から確認し、最後の章で関連項目をあわせてチェックしてください。インストーラーはクライアントのダウンロードページから入手できます。

GUIクライアント mihomo コマンドライン YAML設定接続トラブルの切り分け

01 / PREPARATION

共通の準備：クライアント、サブスクリプション、接続方法

画面・コア・サービスの役割を理解する

Clashエコシステムでは、GUIクライアントが設定一覧やプロキシグループの選択、システムへの接続を管理し、コアが設定の読み込み、ルール判定、接続の確立を担います。mihomoは広く使われているコアですが、クライアントによって利用できる機能や設定画面は異なります。クライアントをインストールしただけでは、利用可能なノードやプロキシサービスは用意されません。始める前に、サービス提供元のサブスクリプションURL、または有効なノード・プロキシグループ・ルールを含む完全な設定ファイルを用意し、アカウントの状態やデバイス数の制限も確認してください。

デスクトップとAndroidでは、まずダウンロードページからClash Plusを選ぶのがおすすめです。すでに安定した運用環境がある場合は、OSに合わせてClash Verge RevやFlClashなども比較してください。LinuxのGUIクライアントにはClash Verge RevまたはFlClashを選べます。設定を別のクライアントで再利用できるかは、サブスクリプション形式、プロトコル対応、実際に使われるコアによって異なります。名前が似ているだけで判断しないでください。アーカイブ版のクライアントは既存環境の維持には使えますが、新しいデバイスへの導入には推奨しません。詳しくはクライアントの選び方をご覧ください。

アーキテクチャとサブスクリプションの内容を確認する

ダウンロード前に、デバイスのCPUアーキテクチャを確認してください。デスクトップではx64とARM64、macOSではIntelとApple Siliconの区別が一般的です。インストーラーが起動するかどうかは、OS、アーキテクチャ、最低システム要件で決まり、サブスクリプションの有効性とは関係ありません。アプリが起動しないときにサブスクリプションを何度も変更したり、スマートフォン向けアプリとデスクトップ用インストーラーを取り違えたりしないようにしましょう。ダウンロードページのOSとシステム要件を、使用するデバイスの情報と照らし合わせてください。

サブスクリプションURLには通常、アクセス用の認証情報が含まれます。貼り付ける際はクエリパラメーターを含めて全文を保持し、前後の空白やチャットアプリが付け加えた句読点を取り除いてください。サービス提供元が配布しているのがClash YAML形式のサブスクリプション、単一ノードのリンク、ブラウザーでログインする管理ページのどれなのかを確認します。完全なYAMLには通常、ノードまたはプロバイダー、プロキシグループ、ルールが含まれます。エンコードされた文字列があるだけでは、現在のインポート機能で読み込めるとは限りません。変換が必要な場合は、サービス提供元が案内する対応URLを優先してください。詳しくはサブスクリプション形式と変換方法をご覧ください。

接続方法	対象となる通信	主な確認項目
システムプロキシ	システムプロキシ設定を利用するアプリ	ローカルの待ち受けポート、アプリが設定に従うか
TUNまたはVPNトンネル	仮想ネットワークアダプターやOSのトンネルを経由する通信	権限、ルーティング、DNS、アプリの除外設定
アプリごとの手動プロキシ設定	特定のブラウザー、ターミナル、アプリ	プロトコル、アドレス、ポート、環境変数の適用範囲

元に戻せる最小構成から始める

初期設定では、プロキシクライアントを1つ、接続方法を1つに絞ります。まずルールモードを使い、手動で選択したプロキシグループと、接続できることを確認したノードでWebページを開きます。その後、必要に応じてTUN、オーバーライド、ルールプロバイダー、複雑なDNS設定を追加してください。システムプロキシとTUNを必ず同時に有効にする必要はありません。併用すると、トラブル時の確認箇所が増える場合があります。スマートフォンでは通常、OSのVPN機能を使ってトンネルを確立します。デスクトップと同じ名前のスイッチがあるとは限りません。

以下の設定例は一般的な項目を理解するためのもので、リモートノードを含みません。サービス提供元のサブスクリプションの代わりにはならないため注意してください。mixed-portはHTTPとSOCKSの両方を受け付けます。ループバックアドレスだけで待ち受ければ、端末外からのアクセスを制限できます。例のポート番号は、すべてのクライアントで共通の既定値ではありません。実際の設定値を確認してください。GUIクライアントがこれらの項目を自動生成することもあり、生成されたファイルを直接編集しても、次回の保存時に上書きされる場合があります。

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

接続前に、現在のシステムプロキシ、DNS、ほかのVPNの状態を記録し、正常に起動する設定のコピーを保存しておきましょう。テストでは、「ノードの接続テストに成功」「リクエストがプロキシルールに一致」「目的のWebページが正常に表示」の3つを区別してください。それぞれ確認している段階が異なります。基本接続を確認した後は、実際に使うアプリでもテストしましょう。パネルに表示された一度の遅延測定だけで、ネットワーク全体が正常だと判断することはできません。

02 / WINDOWS

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

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

Windowsのダウンロードページを開き、まずClash Plusを選びます。既存の環境や用途に応じて、Clash Verge Rev、FlClash、Clash Nyanpasuも選択できます。Clash for Windowsはサポートが終了したアーカイブ版です。Windowsの「設定」から「システム」→「バージョン情報」を開き、システムの種類を確認して、アーキテクチャに合うファイルをダウンロードしてください。デバイス名に特定のCPUメーカー名が含まれていても、それだけでアーキテクチャを判断しないでください。インストーラーを実行できない場合は、まずシステム要件とファイルの種類を確認します。

インストーラーを実行したら、通常のユーザーとしてアプリを起動し、画面の案内に沿ってインストール先を選びます。システムサービスや仮想ネットワークアダプターが必要な場合は、クライアントの設定から該当機能をインストールし、OSの権限確認を読んで許可してください。パネルを開くためだけに、常に管理者としてアプリ全体を実行する必要はありません。初回起動時にセキュリティソフトにブロックされた場合は、検出項目とファイルの入手元を確認し、原因を調べずにシステムの保護機能をすべて無効にしないでください。

サブスクリプションを追加して使用する設定を選ぶ

「設定」「サブスクリプション」などの画面でリモート設定の追加を選び、URL全体を入力してダウンロードします。一覧に項目が表示された後、その設定を選択または有効化する必要があります。「ダウンロード完了」は、コアがその設定に切り替わったことを意味しません。プロキシ画面を開き、プロキシグループが表示され、グループ内にノードがあるか確認してください。「DIRECT」しか表示されない場合は、まずサブスクリプションの内容とインポート形式を確認し、続いてコアが未対応のプロトコルや項目を報告していないか調べます。すぐにシステムルーティングを変更しないでください。

まず、目的のサービスに対応するプロキシグループでノードを手動選択します。設定には、デフォルトのプロキシ、ストリーミング、ダウンロードなど、用途別のグループが複数含まれる場合があります。1つのグループを変更しても、すべてのグループが自動で切り替わるわけではありません。ノードを選んだらルールモードに切り替え、実際にアクセスした際の接続ログで、一致したルールと最終的な出力先を確認してください。遅延テストは接続できないノードの絞り込みに使えますが、Webページの速度やアプリとの互換性を示すものではありません。ノードの選び方はノードの遅延・倍率・地域の比較をご覧ください。

まずシステムプロキシを確認し、その後TUNを検討する

システムプロキシを有効にしたら、Windowsのプロキシ設定でローカルアドレスとポートがクライアントの設定と一致しているか確認します。自動構成スクリプトを使う環境では、そのスクリプトの設定先も確認してください。異なる接続方法を同じものとして扱わないようにしましょう。ブラウザーは通常システム設定を利用できますが、ターミナル、開発ツール、独自のネットワーク処理を行うソフトは設定に従わない場合があります。特定のアプリが直接接続している場合は、すべてのルールをグローバルプロキシに切り替えるのではなく、まずアプリ側のプロキシ設定を確認してください。

PowerShellからプロキシを明示してリクエストを送ると、システム設定の影響を切り分けられます。次のリクエストが有効なのは、クライアントが同じポートで実際に待ち受けている場合だけです。確認できるのはローカルHTTPプロキシの入口とその後の接続であり、すべてのアプリがプロキシ経由になったことではありません。明示的なプロキシ接続は成功するのにブラウザーで失敗する場合は、ブラウザーの拡張機能、個別のプロキシ設定、キャッシュを確認してください。ローカルポートへの接続に失敗する場合は、コアの起動状態、待ち受けアドレス、ポートの競合を先に確認します。

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

システムプロキシに従わないアプリもプロキシ経由にする必要がある場合は、TUNを有効にします。クライアントによっては、サービスのインストール、サービスモードの有効化、管理者権限の許可が必要です。画面の案内に従ってください。有効化後は、仮想ネットワークアダプターが表示されるか、コアのログにデバイス作成の成功が記録されているか、ルートが設定されているかを確認します。VPN、仮想マシン、コンテナ、企業向けセキュリティソフトはルート選択に影響することがあります。トラブルの切り分けでは、不要な同種のトンネルを一時停止し、同じリクエストで比較してください。

スリープ、アップデート、異常終了後の復旧

スリープから復帰した後に接続できなくなっても、サブスクリプションが無効とは限りません。まず物理ネットワークが復旧しているか確認し、ノードへの接続を更新してください。Wi-Fiや有線LANを切り替えた場合は、古いインターフェースのルートを再設定する必要があることがあります。クライアント終了後にすべてのWebページが開けなくなった場合は、システムプロキシが停止済みのローカル待ち受けポートを参照していないか確認します。正常に終了する前に接続機能を無効にしてください。異常終了後は、クライアントの問題を調べる前にプロキシ設定を元に戻し、ネットワークが切れた状態で新しいインストーラーをダウンロードしようとしないでください。

ポートが使用中の場合は、待ち受け結果からプロセスIDを確認し、重複しているクライアントを終了するか、現在のポートを変更します。変更後は、アプリの手動プロキシ、システムプロキシ、ターミナルの環境変数も合わせて更新してください。設定ファイルの一か所だけを変更すると、一部のアプリが古いポートに接続し続けることがあります。クライアントを更新する前に、サブスクリプションの入手元、オーバーライド、プロキシグループの選択をバックアップし、更新後にサービスの状態を確認してください。詳しい確認コマンドはローカルポートの競合を解消する方法をご覧ください。

03 / MACOS

macOS：CPUアーキテクチャ、ネットワークサービス、バックグラウンドコンポーネント

Apple SiliconとIntelのインストーラーを見分ける

「このMacについて」でチップまたはプロセッサの情報を確認し、macOSのダウンロードページを開きます。新しい環境にはClash Plusがおすすめです。Clash Verge RevまたはFlClashも選択できます。ClashX Metaはサポートが終了したアーカイブ版です。Apple Silicon用とIntel用のインストーラーは、それぞれ異なるアーキテクチャに対応しています。アーキテクチャの選択を避けるために、まず変換実行に頼るのはおすすめしません。特にネットワーク関連のバックグラウンドコンポーネントが必要な場合、画面が起動しても付属コンポーネントが適合するとは限りません。

ディスクイメージ形式のアプリは、「アプリケーション」フォルダにコピーしてから起動してください。マウントしたイメージ内から長期間実行するのは避けましょう。初回起動時にセキュリティ警告が表示された場合は、ダウンロード元、ファイルのダウンロードが完了しているか、システム要件を満たしているかを確認し、macOSの通常の認証手順に従ってください。セキュリティ属性を一括削除する方法を、標準のインストール手順にしないでください。組織管理のMacでは管理ポリシーによって制限されることがあるため、ネットワークツールをインストールできるか事前に確認します。

リモート設定を追加してメニューバーの状態を確認する

設定管理画面でサブスクリプションURLを追加し、取得完了後にその項目を明示的に有効化します。メニューバーにアイコンが表示されていても、通常はアプリが起動中であることを示すだけです。サブスクリプションの読み込み、ノードの選択、システムプロキシの有効化を意味するとは限りません。プロキシグループを開いて選択可能なノードがあるか確認し、接続画面で実際のリクエストを確認します。インポートに成功したのに想定したグループが表示されない場合は、サービス提供元がエラーページを返していないか、プランの有効期限が切れていないか、完全な設定と単一ノードリストのどちらをインポートする画面なのかを確認してください。

長期的に使うカスタムルールは、サブスクリプションのキャッシュを直接編集せず、クライアントが対応するオーバーライドまたはマージ機能に追加してください。リモート更新でキャッシュ内容が置き換わり、一時的な編集が次回の更新で消えることがあります。変更前にコピーを保存し、ルールの順序とプロキシグループ名が完全に一致していることを確認してください。設定内の名前は文字単位で一致する必要があります。末尾の空白、全角の句読点、名前変更後に更新されていない参照があると、ルールの出力先が意図どおりにならないことがあります。

現在のネットワークサービスに合わせてシステムプロキシを確認する

macOSのプロキシ設定は、ネットワークサービスごとに異なります。Wi-Fiと有線LANに別々の設定がある場合があるため、接続を切り替えた後は、直前に使っていたWi-Fiではなく、現在使用中のサービスを確認してください。まずクライアントのシステムプロキシを有効にし、システムのネットワーク設定でアドレスとポートを確認します。自動プロキシ設定、ブラウザーのプロキシ拡張機能、ほかのネットワークツールがある場合は、最終的な設定をどのコンポーネントが管理するのかを明確にし、複数のツールが互いの設定を上書きしないようにしてください。

次のコマンドでは、ネットワークサービスの一覧と、指定したサービスのプロキシ設定を確認できます。例では一般的なサービス名「Wi-Fi」を使っていますが、実際のサービス名が変更されている場合があるため、先に一覧を取得して置き換えてください。HTTPプロキシを経由するHTTPS通信では、通常CONNECTが使われます。そのため、システムの安全なWebプロキシ設定も確認が必要です。Webプロキシが有効になっているだけでは、HTTPSアプリにも同じ設定が適用されているとは限りません。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
curl --proxy http://127.0.0.1:7890 -I https://example.com

TUNの権限と開発環境の違い

TUNを有効にする前に、システムプロキシ経由の接続をテストしてください。その後、クライアントの案内に従って補助コンポーネントをインストールするか、ネットワーク機能を許可します。実装によって、特権ヘルパー、システム拡張、その他の接続方式が使われ、許可する場所も異なります。システム設定で該当機能の承認状態を確認し、完了後にトンネルを再度有効にしてください。ログにデバイスの作成エラーや権限エラーが表示される場合は、ノードを次々に変更してローカルの権限問題を覆い隠すのではなく、まずコンポーネントの状態を修復します。

ターミナルアプリは、GUIのシステムプロキシ設定を利用するとは限りません。一時的なテストでは、コマンドのプロキシ引数で接続先を指定できます。環境変数を使う場合は、必要なセッションやツールに限定し、変数名の大文字・小文字やツールごとの対応状況に注意してください。Docker、仮想マシン、リモート開発環境はそれぞれ独自のネットワーク環境を持ち、その中のループバックアドレスはホストを指しません。コンテナからホストのプロキシに接続できない場合は、まずどのマシンに接続しているのかを確認し、必要であればアクセスを制限したLAN向けの待ち受けを検討してください。

スリープからの復帰、ネットワークサービスの優先順位変更、会社のVPNは接続に影響することがあります。まず同じURLを使い、直接接続と明示的なプロキシ接続を比較してから、ルートとDNSを確認してください。LANプリンター、ファイル共有、開発用ドメインに接続できない場合は、ローカル名の解決やDIRECTルールを検討し、すべてのプライベートIPアドレスをリモートに送らないようにします。クライアントをアンインストールする前に、システムプロキシとトンネルを無効化し、クライアントの案内から補助サービスを削除してください。アプリだけを削除すると、コンポーネントが動作したまま残ることがあります。

04 / ANDROID

Android：アプリのインストール、VPNの許可、バックグラウンド動作

互換性のあるインストーラーを選び、移行手段を確保する

Androidのダウンロードページを開き、Clash Plus、Clash Meta for Android、FlClash、Surfboardの順に検討してください。初めて使う場合はClash Plusがおすすめです。インストールできるかどうかは、デバイスのアーキテクチャと最低システム要件で決まります。スマートフォンのメーカーだけで判断しないでください。新しいデバイスの多くはARM64ですが、古い端末や特殊なOSでは実際の情報を確認する必要があります。インストーラーに非対応と表示されたら、別のクライアントを試す前に、アーキテクチャとシステム要件を確認してください。

システムのファイルマネージャーでダウンロードしたファイルを開くと、Androidから現在の提供元によるアプリのインストール許可を求められることがあります。許可する対象は、今回使用するブラウザーまたはファイルマネージャーに限定し、インストール後に元の設定へ戻せます。上書きインストールに失敗する原因には、署名の違い、別の配布元からインストール済みのアプリ、バージョンを戻せない制限などもあります。アンインストール前に設定とオーバーライドをエクスポートし、サブスクリプションを再取得できることを確認してください。アプリを削除すると、ローカルのプロキシ選択や一部の動作設定も失われます。

サブスクリプションの更新と実行中の設定を区別する

設定画面でURLサブスクリプションを追加し、ダウンロード後にその設定へ切り替えます。成功したらプロキシ画面を開き、目的のプロキシグループにノードが表示されていることを確認し、1つ選んでテストしてください。ブラウザーからクイックインポートした場合も、クライアントに戻ってURL、設定名、現在有効な設定を確認します。同じ種類のリンクを開けるアプリが複数インストールされている場合、クイックインポート先が別のクライアントだと、現在実行中のアプリの設定は変更されません。

Clash Meta for Androidなどは、他のアプリとは設定の追加方法が異なる場合があります。また、Surfboardが対応する設定構文をClash YAMLと同じものとして扱うことはできません。サービス提供元が複数の形式を配布している場合は、現在のクライアントに対応する形式を選んでください。インポートに失敗したら、まず形式やプロトコルに関するエラーを確認します。同じURLを何度も別の項目として追加しないでください。ノードだけが含まれる場合は、クライアント側でルールとグループの設定も必要です。ノード一覧だけでは、完全なルーティングポリシーにはなりません。

VPN接続を許可し、通信の対象範囲を確認する

接続または起動をタップすると、通常はOSのVPN接続確認画面が表示されます。許可した後、クライアントがサービスの起動を報告しているか、システムのVPN状態がどうなっているかを確認してください。一般的な個人向け環境では、同じユーザー領域でVPNの接続先として使用できるのは通常1つです。広告ブロッカー、ファイアウォール、仕事用ネットワーク、その他のプロキシアプリが競合する場合があります。接続直後に切断される場合は、リモートノードの設定を変更する前に、別のVPNが動作していないか確認してください。

AndroidでVPN接続を使うからといって、「TUN」という名前の独立したスイッチを必ず有効にする必要はありません。多くのモバイルクライアントは、OSのVPNインターフェースを通じて通信をコアに渡し、ネットワークスタック、DNS、アプリごとの振り分けをアプリ内で管理します。システムスタックやユーザー空間スタックを選べる場合は、まず既定の設定を使い、明確な互換性の問題が起きたときだけ比較してください。デスクトップ向けのauto-routeなどの項目は、モバイルクライアントでそのまま使えるとは限りません。設定全体をコピーすると無視されたり、自動生成される設定と競合したりすることがあります。

「選択したアプリのみプロキシ」を使う場合、新しくインストールしたアプリが自動で対象に加わるとは限りません。除外モードでは、除外したアプリはトンネルを通りません。まず現在の設定が許可リストか除外リストかを確認し、対象アプリが正しい側に登録されているか確認します。ブラウザーは使えるのに他のアプリが使えない場合は、アプリごとの振り分け、プライベートDNS、アプリ内プロキシ、UDPの必要性を個別にテストしてください。すべてをサブスクリプションの無効化が原因だと決めつけないようにしましょう。

省電力制限とネットワーク切り替えに対処する

画面ロック後に接続が切れる場合は、まずシステムのバッテリー設定でバックグラウンド動作が制限されていないか、必要な自動起動が許可されているか、フォアグラウンドサービスの通知が維持されているか確認してください。メーカーによって設定名は大きく異なります。最近使ったアプリの画面でアプリをロックしても、完全なバックグラウンド動作の許可にはなりません。まず現在のクライアントのバッテリー設定を調整し、画面ロック中と復帰後のログを確認してください。再接続を繰り返してもプロセス終了の記録がない場合は、モバイル回線への切り替え、ノードへの到達性、トンネルの再確立を調べます。

Wi-Fiからモバイルデータ通信に切り替えると、外向きのIPアドレスと下位の接続が変わり、既存の長時間接続を再確立する必要が生じることがあります。ネットワークが安定するまで待ってから再接続し、同じ接続先をテストしてください。公衆Wi-Fiに認証ページがある場合は、プロキシを有効にする前にネットワーク認証を完了します。「VPNを常に使用」と「VPNを使用しない接続をブロック」が有効だと、クライアントの停止後に通信が遮断されることがあります。切り分けの前にこれらのシステム設定を記録し、想定された遮断をクライアントのクラッシュと誤認しないようにしましょう。

05 / IOS

iOS：App Storeからのインストール、サブスクリプション形式、トンネル設定

App StoreからClash Plusをインストールする

iPhoneとiPadでは、iOSのダウンロードページからClash PlusのApp Storeページを開けます。Clash PlusのApp Storeページを直接確認することもできます。アプリの公式サイトはclashplus.ioです。インストール前に、App Storeに記載されたデバイスとシステムの要件を確認し、インストール後にアプリを起動してください。iOSのシステム接続はOSのネットワーク機能が管理します。デスクトップのインストールサービス、バックグラウンドトレイ、システムプロキシのメニューと同じ操作があるとは限りません。

初めて使うときは、まずデバイス自体がインターネットに接続できることを確認し、現在のWi-FiのWeb認証を完了してください。サブスクリプションのダウンロードは通常、トンネルの確立前に行われます。下位ネットワークに接続できていないと、インポートがタイムアウトすることがあります。組織管理のデバイスでは、ネットワーク拡張機能、構成プロファイル、アクセス制限が設定されている場合もあります。システムからVPN構成を追加できないと表示されたら、サブスクリプションのノードプロトコルを変更するのではなく、まずデバイスの管理ルールを確認してください。

URL全体を追加し、設定の互換性を確認する

アプリの設定またはサブスクリプション管理画面でリモートURLを追加し、すべてのパラメーターを保持したまま取得します。クイックインポート機能がある場合も、アプリに戻って新しい項目が実際に追加されたか確認し、現在の設定として有効にしてください。1つのサブスクリプションが複数のクライアント形式を配布している場合は、サービス提供元が互換性を明示している形式を選びます。YAMLをテキストエディターで開けるからといって、すべての項目がモバイルOSに対応しているとは限りません。ファイル形式が正しいことと、機能がサポートされていることは別です。

取得に失敗した場合は、ネットワークのリクエストエラーと内容の解析エラーを切り分けてください。タイムアウトの場合は、現在のネットワーク、サブスクリプションのドメイン、サービス提供元の状態を確認します。解析エラーの場合は、返された内容がログインページ、エラーメッセージ、未対応の設定のどれなのかを調べてください。アクセス用の認証情報を含むURL全体を、知らないオンラインツールに渡してテストしてはいけません。サブスクリプションの変換が必要な場合は、サービス提供元の説明を読み、形式の違いによってプロキシグループ、ルール、プロトコルパラメーターが失われていないか確認します。

設定を有効にしたら、プロキシ選択画面を開き、目的のグループに利用可能なノードがあるか確認してください。まずノードを1つ手動で選び、接続を開始して、アクセス先が明確なWebページを開きます。自動テストグループは、ヘルスチェックを実行して初めて結果が利用可能になる場合があります。グループが空、またはテストに失敗する場合は、グループ内のノードとテスト条件を先に確認してください。1つのテスト先への接続失敗だけでサービス全体を否定したり、ノード1つの接続成功だけで各用途のグループ選択が正しいと判断したりしないでください。

トンネルを許可し、実際のルートを確認する

初めて接続を開始するときは、システムの案内に従ってアプリにVPN構成の追加を許可し、デバイスが求める方法で認証を完了してください。アプリに戻って接続状態を確認し、必要に応じてシステムのVPN設定で現在有効な項目を調べます。ステータスバーにVPNアイコンが表示されても、トンネルが動作中であることを示すだけです。すべてのリクエストがリモートプロキシを経由しているとは限りません。ルールモードでは、一部の接続先にDIRECTを適用できます。実際の出力先は、アプリの接続ログもあわせて確認してください。

ほかのVPNやネットワークフィルターアプリもインストールされている場合は、どの設定が現在有効なのかを確認します。オンデマンド接続では、ネットワーク状況の変化によってOSが自動的に再接続することがあります。手動で切断した後に接続が戻っても、ボタンが機能していないとは限りません。切り分けの際は、現在のアプリのオンデマンドルールを一時的に無効にし、ネットワークを固定して接続をテストします。基本の接続経路を確認した後、必要に応じて自動動作を戻してください。原因を特定しにくくなるため、ノード、ルール、オンデマンド条件を同時に変更しないでください。

DNS、LANサービス、Wi-Fiプロキシの違い

Wi-Fiの詳細画面で設定するHTTPプロキシと、アプリが作成するVPNトンネルは別の接続方法です。前者は該当ネットワークでその設定を利用する通信だけに影響し、後者はアプリとOSが連携して通信を受け取ります。トラブル時は、使っていないWi-Fiの手動プロキシを解除し、通信が古いローカルアドレスやLANアドレスに送られないようにしてください。スマートフォンで設定するループバックアドレスはスマートフォン自身を指し、パソコン上のプロキシには接続できません。別のデバイスから接続する場合は、パソコンの実際のLANアドレスと、明示的に公開した待ち受けポートが必要です。

LAN内のデバイス検索、画面共有、ローカル機器の操作には、ルーティングと名前解決の両方が影響します。インターネット上のWebページは開けるのにローカル機器へ接続できない場合は、ローカルアドレスが誤ってプロキシ経由になっていないか、ローカルドメイン名が適切でないDNS経路に送られていないか、アプリに必要なローカルネットワーク権限があるかを確認してください。OSのプライバシーやネットワーク設定を変更する前に、現在の状態を記録して項目ごとに比較します。特定の互換性問題を解決するために、すべての保護機能を恒久的に無効にしないでください。

iOSはバックグラウンドプロセスとトンネルのリソースを管理しているため、サブスクリプションの定期更新が想定どおり動くかは、アプリの実装とOSのスケジュールに左右されます。長期間アプリを開いていない場合は、まず手動で設定を更新して結果を確認し、その後に接続をテストしてください。Wi-Fiを切り替えた後や、モバイルデータ通信からWi-Fiに戻った後は、下位ネットワークとサブスクリプションの状態を確認してからトンネルを再確立します。既知の正常な設定を1つ保存しておきましょう。ただし、期限切れのサブスクリプションを恒久的なオフライン環境として扱わないでください。ノードや利用権限の変更は、サービス提供元との同期が必要です。

06 / LINUX

Linux：GUIクライアントとsystemdサービスの導入

デスクトップ環境ではGUIクライアントを使う

デスクトップ環境がある場合は、LinuxのダウンロードページからClash Verge RevまたはFlClashを選び、ディストリビューションのパッケージ形式に合ったファイルをインストールしてください。まずuname -mでアーキテクチャを確認し、ダウンロードページのパッケージ形式と照合します。パッケージが見つからない場合や依存関係が不足している場合は、ディストリビューションのバージョンとパッケージの対応範囲を確認してください。他のOS用のバイナリを単にリネームして実行しないでください。GUIを起動できたら、サブスクリプションとネットワーク接続を設定します。

デスクトップクライアントでリモート設定を追加し、サブスクリプションを有効にしてノードを手動選択した後、デスクトップ環境が対応するシステムプロキシを有効にします。GNOME、KDE、ターミナルツールではシステムプロキシの使われ方が異なるため、GUIのスイッチだけですべてのアプリに設定が反映されるとは限りません。まずプロキシを明示したリクエストでローカルポートを確認し、その後に開発ツールを個別に設定します。TUNの有効化にはデバイス権限とルーティング管理機能も必要です。クライアントのサービス導入手順に従い、ポートを競合させる別のコアを同時に起動しないでください。

サーバーではmihomoコアを単独で使う

デスクトップ環境のないサーバーでは、CPUアーキテクチャに合ったmihomoコアをダウンロードして展開します。以下のコマンド例は、現在のディレクトリに展開済みバイナリmihomoと、完全な設定ファイルconfig.yamlがあることを前提としています。設定には有効なノードまたはプロバイダーをあらかじめ記述してください。このページの設定例の一部だけでは、サービスの完全な設定になりません。ファイルにはサブスクリプションの認証情報が含まれる場合があります。設置時はディレクトリとファイルのアクセス権を制限し、公開Webサイトのディレクトリに置かないでください。

sudo install -m 0755 ./mihomo /usr/local/bin/mihomo
sudo install -d -m 0700 /etc/mihomo
sudo install -m 0600 ./config.yaml /etc/mihomo/config.yaml
sudo /usr/local/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

設定テストを実行し、構文エラー、プロキシグループの参照エラー、リソースファイルの問題を解決してから常駐サービスを起動してください。外部ルール、位置情報データベース、プロバイダーを使う設定では、実行ユーザーが該当ディレクトリにアクセスできることと、必要なリソースを取得できることも確認します。初回起動後に接続できなくても、ノードが原因とは限りません。ローカルに必要なリソースがない可能性もあります。リソースのダウンロードにプロキシが必要な場合は、事前にリソースを用意するか、明確な経路を作成してください。起動に必要なファイルを取得するために、コアが先に接続しなければならない状態にならないようにします。

systemdで起動とログを管理する

/etc/systemd/system/mihomo.serviceを作成します。以下の例はTUN管理権限が必要なローカル環境向けで、ユーザーを指定しない場合はrootでサービスが動作します。通常のローカルプロキシだけを提供する環境では、独立した低権限ユーザーの使用を検討してください。仮想ネットワークアダプターの作成、ルートの変更、制限付きリソースの利用には追加の権限が必要です。権限の要件を理解せずに制限パラメーターを一括でコピーすると、サービスは起動してもネットワークデバイスを作成できないことがあります。

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

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5

[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で実際の待ち受け状態を確認し、ローカルプロキシ経由のリクエストで出力先をテストします。コントロールAPIを有効にする場合は、ループバックアドレスにバインドし、アクセス認証情報を設定してください。リモート管理には、アクセスを制限したトンネルを優先します。コントロールAPIの公開とプロキシポートの公開は別々のリスクですが、どちらもインターネットへ直接公開しないでください。サーバー内のループバックアドレスには、リモートPCから直接アクセスできません。ブラウザーパネルの接続先が、実際の設置場所と一致していることを確認してください。

TUNの設定とメンテナンス時の切り戻し

LinuxのTUNには、カーネルデバイスとネットワーク管理権限が必要です。コンテナで動かす場合は、デバイスのマッピングと必要な権限も関係します。通常のコンテナプロセスからホストのルートを直接変更することはできません。以下の設定例は、テスト済みのmihomo設定に追加し、使用中のコアが該当項目に対応している場合だけ使ってください。auto-detect-interfaceは出力インターフェースの判別を補助しますが、複数のネットワークインターフェースやポリシールーティングを使う環境では、実際の結果を確認する必要があります。

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

リモートサーバーで自動ルーティングを有効にする前に、2つ目の管理セッションとコンソールからの切り戻し手段を確保し、管理用通信が誤って取り込まれないことを確認してください。ネットワークが正常なことを確認してから自動起動を設定し、設定を変更する前にはテストしてから再起動します。コマンドラインのコアは、GUIクライアントのサブスクリプション定期更新機能を自動で備えているわけではありません。更新スクリプトでは、一時ファイルへダウンロードし、設定をテストしてから成功時に置き換える手順を採用してください。導入方法とサービスの管理については、Linuxデスクトップとsystemdでの導入方法もご覧ください。

07 / DIAGNOSTICS

設定のよくある質問：ポート、ルール、DNS、切り戻し

すべてを一度に変更せず、接続経路に沿って切り分ける

トラブルシューティングでは、下位ネットワーク、設定の読み込み、ローカルの待ち受け、接続方法、ルールの一致、リモート接続の順に確認します。まずプロキシを無効にした状態で通常のWebページを開けるか確認し、次にコアの起動エラーがないことを確認したうえで、プロキシを明示したリクエストで待ち受けポートをテストします。この順序なら、ローカルの問題とリモート側の問題を切り分けやすくなります。前の段階が同じリクエストで確認できて初めて、次のテストに意味があります。DNS、ノード、モードを同時に変更すると、成功しても再現できなくなります。

ログはまず情報レベルに設定し、失敗したリクエストの時刻、接続先、エラーの種類を記録します。詳細なデバッグが必要な場合だけ一時的にログレベルを上げ、完了後は元に戻してください。アクセス内容を過剰に記録しないようにしましょう。接続拒否は、接続先ポートで待ち受けていない場合によく発生します。接続タイムアウトには、ネットワーク、ファイアウォール、リモートサービスが関係する場合があります。設定の解析エラーは、出力先への接続が始まる前に発生します。エラーの文言で原因候補を絞れますが、それだけで責任箇所を断定することはできません。同じ条件で行ったリクエストの比較も必要です。

症状	最初に確認する項目	次に確認する項目
ローカルプロキシのポートで接続拒否	コアの起動結果と待ち受けポート	使用中のプロセス、設定エラー、重複起動を確認
明示的なプロキシ接続は成功するが、アプリは失敗する	アプリが利用するプロキシ設定	個別プロキシ、アプリごとの振り分け、TUNの対象範囲を確認
一部のドメインで出力先が誤っている	実際に一致したルールとプロキシグループの選択	ルールの順序、グループ名、DNSの対応付けを確認
画面ロック後やネットワーク切り替え後に切断	バックグラウンドプロセスと下位インターフェースの状態	省電力制限、古いルート、トンネルの再確立を確認

ルールの順序とオーバーライドの保持

ルールは通常、上から順に照合され、最初に一致したルールのポリシーが適用されます。そのため、具体的なドメインルールを広範なルールより前に置き、フォールバックルールは末尾に配置してください。以下の例は、設定にPROXYというプロキシグループがあることを前提としています。実際のグループ名が異なる場合は、同じ名前に置き換えてください。存在しないグループ名をコピーすると、設定の読み込みに失敗したり、ルールが機能しなくなったりします。ルールを更新したら、エディターの保存成功だけで判断せず、接続ログで検証してください。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

ノードプロバイダーの更新とサブスクリプション全体の置き換えは、別の操作です。前者はノードの情報だけを更新する場合がありますが、後者はルールやプロキシグループも含めて置き換えることがあります。保持したいカスタム設定には、クライアントが明示的に対応するオーバーライド機能を使い、設定生成の前と後のどちらでマージされるか確認してください。グループ名が変更されると、以前の選択が新しいグループに引き継がれない場合があります。更新後に一部の用途で接続できなくなったら、現在有効な設定と関連する各グループを確認します。

DNSとTUNの連携範囲

TUNはIPパケットを受け取りますが、ドメインルールの適用には正確なドメイン情報が必要です。DNSの横取り、コア内DNS、Fake-IPなどの対応付け方式が、ドメインと接続をどのように関連付けるかに影響します。仮想ネットワークアダプターを有効にしただけで、すべてのアプリの名前解決がコアに渡されるわけではありません。アプリ内の暗号化DNS、OSのプライベートDNS、既存のキャッシュによって、名前解決の経路が変わることがあります。切り分けでは、同じドメインの名前解決結果と接続ログを比較し、必要に応じてアプリの説明に従ってキャッシュを消去してから再テストしてください。

DNS漏れを判断する前に、どのドメインを誰が名前解決する想定なのかを明確にしてください。DIRECT対象のドメインをローカルで名前解決するのは、意図した振り分けの場合があります。検出ページにローカルの通信事業者が表示されただけで、設定全体の誤りとは限りません。一方、プロキシ対象が想定外のDNS経路を通ると、プライバシーや互換性の問題につながる場合があります。あらゆる状況で同じパブリックDNSを使わないでください。社内ドメイン、LAN内の名前、リモートサービスには、それぞれ別の経路が必要なことがあります。詳しくはTUN、ルーティング、DNSの制御についてをご覧ください。

よくある原因の判断と復旧方法

サブスクリプションは更新できるのに、どのノードにも接続できない場合は？

サブスクリプションの取得とノードへの接続は別の経路です。まず利用権限、有効期限、通信量を確認し、次に地域やプロトコルの異なるノードをいくつか比較してください。システム時刻、現在のネットワーク制限、ログに表示されるハンドシェイクエラーも確認します。すべてのノードが同じ段階で失敗する場合は、共通する依存要素を優先して調べてください。同じ設定をノードごとに作り直す必要はありません。

ルールモードでは失敗するのにグローバルモードでは使える場合、グローバルモードを使い続けるべき？

ルールの適用経路または関連するプロキシグループの確認が必要な可能性があります。失敗した接続先に適用されたルール、選択中のグループ、DNS情報を比較し、DIRECTや空のグループに誤って送られていないか確認してください。グローバルモードは短時間の比較には使えますが、通常の振り分け範囲が変わります。原因を特定したら必要なモードに戻し、同じ接続先で修正結果を確認してください。

TUNを有効にした後、LANやリモート管理に接続できなくなった場合は？

まずTUNを無効にして管理経路を復旧し、ローカルネットワークの範囲、出力インターフェース、既存VPNのルートを確認します。ルールでDIRECTを選ぶ設定と、システムルートが通信を取り込む範囲は別の階層です。ドメインルールを1つ追加しただけでルーティングの競合が解決するとは限りません。サーバーではコンソールから切り戻し、デスクトップでは接続方法を1つに戻してから順に確認してください。

クライアントを終了してもネットワークに接続できない場合、再インストールするべき？

まずシステムプロキシが停止したローカルポートを参照したままになっていないか確認します。次に、VPNが遮断状態またはオンデマンド再接続の状態にないか、システムDNSに到達できないアドレスが残っていないかを調べてください。ネットワーク設定を元に戻してからクライアントを起動します。再インストールしてもユーザー設定が残ることが多く、問題を起こしているシステム状態が解消されるとは限りません。

修復後は、動作に必要な最小限の設定を残し、変更内容と検証結果を記録してから、自動更新、オンデマンド接続、追加ルールを段階的に戻してください。接続の基本手順をもう一度確認する場合はクイックスタートガイドへ、クライアントを変更する場合はクライアントの選び方をご覧ください。移行では、設定の管理元と接続範囲を明確にします。複数のクライアントで同じシステムネットワーク設定を同時に管理しないでください。