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

共通の準備と設定の範囲

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

ClashエコシステムのGUIクライアントは、設定のインポート、プロキシグループの管理、システムプロキシの設定、接続状況の表示を担います。mihomoなどのカーネルは設定を解析し、ローカルポートを待ち受けてルールを適用します。サブスクリプションは設定の取得元で、プロキシ、プロキシグループ、ルール、DNS設定などを含む場合があります。クライアントをインストールしただけで、利用可能なリモートプロキシが自動的に用意されるわけではありません。作業を始める前に、利用権限のあるサブスクリプションまたは設定ファイルを用意し、提供元が案内する形式、利用範囲、更新方法を確認してください。

このガイドでは、Windows、macOS、Android、iOSでは主にClash Plusの使い方を紹介し、LinuxデスクトップではClash Verge RevまたはFlClashを選択肢として取り上げます。サブスクリプション形式、拡張フィールド、設定のオーバーライドへの対応はクライアントによって異なり、ファイル名だけでは互換性を判断できません。ダウンロード前にプラットフォーム別のダウンロード विकल्पとシステム要件を確認し、デバイスのアーキテクチャも照合してください。デスクトップ版のボタン配置をモバイル版に当てはめたり、古いカーネルの対応フィールドをエコシステム全体の共通仕様と見なしたりしないでください。

準備するものとバックアップの手順

サブスクリプションを保存する際は、クエリパラメーターを含めてリンク全体を保管してください。ただし、公開チャットやスクリーンショット、問い合わせ報告に貼り付けないでください。リンク自体がアクセス権を持つ場合があり、漏えいしたら提供元で再発行してください。新しいクライアントをインストールする前に、現在使っているプロキシソフトの終了方法、システムプロキシの状態、独自DNSの設定を記録します。古いソフトを一時的に残しても構いませんが、テスト中は通信を制御するツールを1つだけ実行してください。組織管理のデバイスでは、プロキシの変更、ネットワーク拡張機能のインストール、仮想インターフェースの作成が管理ポリシーで許可されているか、事前に確認してください。

初回のインポートでは元の設定をできるだけ保ち、動作に必要な最小限の項目だけを変更してください。クライアント画面での変更は、アプリのデータベース、オーバーライドファイル、またはメモリ上の実行設定に保存される場合があり、サブスクリプションの原文が変わるとは限りません。バックアップにはサブスクリプションの取得元、ユーザー作成のオーバーライド、必要なアプリ設定を含めてください。キャッシュ内のYAMLだけをコピーすると、画面で選択したプロキシやサービスの状態が抜けることがあります。デバイスを移行する前にローカルバックアップをエクスポートできますが、機密情報が含まれる場合があるため、安全な場所に保管してください。

再現可能な検証手順を作る

カーネルを起動したら、ノードを切り替える前に、設定の解析エラー、ポート競合、権限不足がログに出ていないか確認してください。次の表にあるポート番号は一般的な例であり、固定値ではありません。テストにはクライアントが実際に待ち受けている値を使ってください。コントロールインターフェースはカーネルの管理用で、ブラウザーが使うプロキシの接続先ではありません。ブラウザーをコントロールインターフェースに向けても、ポートに接続できるだけで正常なプロキシ転送は行われません。待受アドレスをローカルのループバック範囲内に保つと、サービスが意図せずLANに公開されるリスクを抑えられます。

項目	例	確認ポイント
`mixed-port`	`7890`	HTTPとSOCKSプロキシの共通ポート
`external-controller`	`127.0.0.1:9090`	管理用インターフェース。プロキシポートの代わりにはならない
`allow-lan`	`false`	ほかのデバイスからの接続を許可するか
`mode`	`rule`	ルールに従って振り分ける。すべての接続がプロキシ経由になるわけではない

「カーネルの起動、明示的なプロキシリクエスト、アプリのシステムプロキシ、TUN」の4段階で順に確認してください。デスクトップでは、まずコマンドを1つ使ってプロキシポートを明示し、設定経路が機能することを確認してからシステムプロキシを有効にします。システムプロキシに従わないアプリを使う場合や、ほかの通信も制御する必要がある場合に限り、TUNを追加します。こうすれば、問題が起きたときにどの段階で変化したのかを特定できます。速度テストの成功で確認できるのは、そのテスト先への結果だけです。すべてのWebサイト、プロトコル、アプリの正常動作を証明するものではなく、接続ログの確認にも代わりません。

検証では対象アドレスとアプリを1つずつ決め、毎回変更する設定を1項目に絞り、変更前後のログを記録します。ブラウザーが既存の接続を再利用することがあるため、モードを切り替えた後はリクエストを再実行し、必要なら古い接続を終了してください。アカウントへのログインが必要なサイトは、地域や時刻、サービス側のポリシーの影響も受けます。アクセス制限のすべてをプロキシの問題と決めつけないでください。初回設定の目標は、動作の理由を把握でき、元に戻せる状態を作ることです。高度な機能を一度にすべて有効にすることではありません。

Windowsの導入と設定

クライアントをインストールしてカーネルの状態を確認する

Windowsのダウンロードから、まずClash Plusを選んでください。別の画面や使い方が必要な場合は、Clash Verge Rev、FlClash、Clash Nyanpasuも比較できます。Clash for Windowsはサポートが終了したアーカイブ版クライアントのため、新規導入では推奨しません。ダウンロード前にシステム設定の「システムの種類」でアーキテクチャを確認し、インストーラーの対応範囲を照合してください。インストール時にセキュリティ警告が表示されたら、ダウンロード元と公開情報を確認してください。インストールを続けるために、システムのセキュリティ機能を恒久的に無効にしないでください。

インストール後は、まず標準ユーザーとして起動し、クライアントが開くこと、設定フォルダーに書き込めること、カーネルが動作することを確認します。画面は表示されるのにカーネルが繰り返し終了する場合は、接続を何度も押すのではなく、ログに最初に出たエラーを確認してください。存在しないファイルを参照する古い設定、ほかのプロキシによるポートの使用、アクセス制限のある場所にあるフォルダーは、起動失敗の原因になります。サービスモードやTUNが必要な場合に、クライアントの案内に従って権限を昇格してください。普段の利用でアプリ全体を常に管理者として実行する必要はありません。

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

設定またはサブスクリプションの画面でリモート設定を追加し、リンク全体を貼り付けて、判別しやすい名前を付けてからダウンロードまたは更新を実行します。設定が一覧に追加された後、その項目が現在の実行設定に選ばれていることも確認してください。クライアントによっては複数のサブスクリプションを保存できますが、通常、実行に使われるのは選択中の設定とオーバーライドの結果です。プロキシが一覧にあるのにメイン画面に古いプロキシグループが表示される場合は、同じリンクを何度も追加するのではなく、現在の設定名とカーネルの再読み込み結果を確認してください。

サブスクリプションの追加に失敗したら、まずネットワークリクエストのエラーとコンテンツ解析のエラーを区別します。接続タイムアウトは有効な応答をまだ取得できていない状態です。YAMLの行番号エラーは、コンテンツを取得できたものの、書式または項目に問題があることを示します。リンク先がログインページ、権限に関する案内、JSON形式のエラーを返す場合、ファイルを保存できても設定として使えるとは限りません。更新前後のプロキシグループ名とログを比較してください。一覧の最終更新時刻だけで判断しないでください。提供元が形式を変更した場合は、対応する形式の追加方法を使い、エラー項目を適当に削除しないでください。

システムプロキシ、アプリごとの差、TUN

まずルールモードを選び、主要なプロキシグループで利用可能なプロキシを指定してから、システムプロキシを有効にしてください。通常、ブラウザーはWindowsのユーザープロキシ設定を使いますが、一部のターミナルプログラム、バックグラウンドサービス、独自のネットワーク設定を使うアプリは従いません。次のコマンドをPowerShellで実行すると、プロキシを明示したテストができます。コマンドの別名による引数の違いを避けるため、ここではcurl.exeを使用します。実際のポートが7890以外の場合は、値を合わせて変更してください。実際の接続先は、クライアントの接続ログと照合します。

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

最初のコマンドではアクセスできるのにブラウザーが失敗する場合は、システムプロキシのアドレスとポート、ブラウザー拡張機能を確認してください。ブラウザーは使えるのに特定のコマンドラインツールが失敗する場合は、そのツール固有のプロキシ引数や環境変数を確認します。Windowsのユーザープロキシ設定と、一部のサービスが使うWinHTTPの設定は別の仕組みです。最初からサービス全体のプロキシを変更することは避けてください。職場のPCでは組織のポリシーが設定を上書きし、プロキシが自動で戻る、またはアドレスを保存できないことがあります。その場合は、権限と管理ポリシーを先に確認してください。

TUNは、より多くのアプリのネットワーク接続を制御するための機能で、通常はサービスコンポーネント、仮想インターフェース、適切な権限が必要です。有効にする前に、システムプロキシ経由の接続が正常に動作することを確認し、クライアントのサービスインストール手順に従って許可を与えてください。有効化後にすべての接続が切れた場合は、仮想ネットワークアダプターが作成されたか、デフォルトルートに異常がないか、ほかのVPNが同時に動作していないかを確認します。出所の異なるネットワークドライバーを何度もインストールしないでください。まずTUNを無効にしてシステムプロキシの状態に戻し、DNS、ルート、除外するネットワークを順に確認できます。

UWP、終了時の設定復元、アップグレード

一部のストアアプリはローカルループバックの制限により、ローカルのプロキシポートへ直接接続できません。まずクライアントが提供するループバック管理ツールを使い、必要なアプリだけを例外にしてください。仕組みとコマンドはWindows UWPのループバック例外に関するメモを参照してください。ループバックの例外で解決できるのはローカルアクセスの制限だけです。無効なサブスクリプション、到達できないプロキシ、誤ったルールは修復できません。すでにTUNでアプリの通信を制御している場合は、2つの接続経路を混同しないよう、まず接続がカーネルに到達しているか確認してください。

終了またはアンインストールの前にシステムプロキシとTUNを無効にし、システム設定が元に戻っていることを確認してください。クライアントが異常終了した後にブラウザーで「プロキシサーバーが接続を拒否しました」と表示される場合は、Windowsのプロキシ設定が停止済みのローカルポートを指したままになっていないか確認します。アップグレード前にユーザーオーバーライドとサブスクリプションの取得元を保管し、アップグレード後は自動起動とサービスの状態を再確認してください。画面が開いても、バックグラウンドサービスが正常とは限りません。スリープから復帰した後に問題が起きた場合は、再インストールを検討する前に接続を再確立し、設定を再読み込みしてください。

macOSの導入と設定

アーキテクチャを確認して初回の許可を完了する

「このMacについて」でチップの種類を確認し、macOSのダウンロードから対応するインストーラーを選んでください。まずClash Plusを推奨します。使い方に応じてClash Verge RevまたはFlClashも選べます。ClashX Metaはサポートが終了したアーカイブ版のため、従来の使い方を続ける場合は互換性を別途確認してください。Apple Silicon用とIntel用のインストーラーは、ファイルサイズだけで判断できません。システムが一部のプログラムを変換実行できる場合でも、デバイスのアーキテクチャに合ったビルドを優先してください。

ディスクイメージからインストールする場合は、アプリを「アプリケーション」フォルダーに移してから起動してください。一時的にマウントした場所から常用するのは避けます。初回起動時にシステムの警告が出たら、ダウンロード元とセキュリティ設定の案内を確認してください。ダウンロードフォルダー全体のセキュリティ属性を一括で解除しないでください。クライアントからネットワーク設定の変更、補助ツールのインストール、ネットワーク拡張機能の追加を求められた場合は、要求元が起動中のアプリであることを確認してください。補助サービスをインストールしても起動できない場合は、アプリのログとシステムの許可状態を確認します。パスワードを入力できたことだけで成功と判断しないでください。

サブスクリプションの追加とユーザー設定の保持

設定管理からリモートサブスクリプションを追加し、ダウンロードと解析が完了するのを待ってから、その設定を選択してプロキシ選択画面を開きます。メニューバーに動作中と表示されても、それはクライアントまたはカーネルが動いていることを示すだけで、サブスクリプションが新しい項目に切り替わったとは限りません。初回追加後にプロキシグループとルールが揃っているか確認してください。設定が外部のルールセットやプロキシグループを参照している場合は、それらの読み込みを待つ必要があります。リソースのリクエストに失敗してもアプリ全体がすぐ終了しないことがありますが、該当するルールやプロキシの動作に影響します。

ローカルの変更は、更新のたびに置き換わるサブスクリプションのキャッシュを直接編集するのではなく、クライアントが対応するオーバーライド機能に保存してください。変更前に、オーバーライドがサブスクリプション解析の前に適用されるのか、実行設定の生成後に適用されるのか確認します。リストの統合方法はクライアントによって異なる場合があります。複数のDNSブロックや同名のプロキシグループがある場合、最終的な結果は実行設定で確認してください。設定を更新したらログを確認し、必要な項目が残っているか照合します。ファイルを保存できたことだけで、カーネルがその内容を使っていると判断しないでください。

システムプロキシとターミナルのプロキシを別々に確認する

システムプロキシを有効にすると、通常、ブラウザーは現在のネットワークサービスに設定されたプロキシを使います。このMacにWi-Fi、有線ネットワーク、ほかのネットワークサービスが同時にある場合、ネットワーク切り替え後にクライアントが正しいサービスを更新しているか確認してください。ターミナルのツールは通常、明示的な引数や環境変数が必要で、GUIの設定をすべて自動で読み込むわけではありません。シェルの起動ファイルを直接変更するより、まず1回だけ実行するコマンドで試すほうが簡単に元へ戻せます。次のコマンドでシステムプロキシの状態と実際のポートの使用状況を確認します。

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

現在のターミナルセッションでプロキシを使う場合は、http_proxyとhttps_proxyを一時的に設定できます。後者の値にHTTPプロキシのアドレスを指定しても構いません。HTTPSリクエストはCONNECTでトンネルを確立します。環境変数の大文字・小文字やSOCKSへの対応はツールによって異なるため、各ツールの説明を確認してください。必要性を確認してからシェルの設定ファイルに書き込み、削除方法も記録しておきます。記録しないままポートを変更したりクライアントを終了したりすると、ターミナルが古い環境変数を使い続け、「ブラウザーは正常だがコマンドはすべて失敗する」状態になることがあります。

TUN、LAN、スリープ復帰

システムプロキシに従わないプログラムの通信を制御する必要がある場合に、TUNまたはクライアントの拡張通信制御機能を検討してください。補助サービスのインストールやシステムネットワークコンポーネントの許可が必要な場合があります。許可の手順はmacOSのバージョンとクライアントの実装によって異なるため、実際の案内に従ってください。別のクライアントの許可手順をそのまま当てはめないでください。有効にしたら、まずDNSと接続ログを確認し、その後LAN機器、リモートデスクトップ、開発用サービスをテストして、LAN宛ての通信が誤ってリモートプロキシに送られていないか確認します。

プリンター、ルーターの管理画面、ローカルの開発サイトにアクセスできない場合は、すぐに全体モードへ切り替えず、LANのバイパス設定とルートの除外を確認してください。社内ネットワークでは内部DNSでしか解決できないドメインがよくあります。パブリックDNSで内部DNSを置き換えることはできません。オフィス、テザリング、家庭のネットワークを切り替えた後は、内部ドメインと直接接続のルールを再テストしてください。このような環境では、プロキシを何度も変えるより、ネットワーク変更前後のログとDNSの結果を残すほうが原因の特定に役立ちます。

画面を閉じてスリープした後は、既存のTCPセッションが無効になっている場合があります。カーネルの再起動を検討する前に、リクエストを再実行するか、古い接続を終了してください。メニューバーでは正常なのに新しい接続がすべて失敗する場合は、ネットワークが復旧しているか、システムプロキシが現在のポートを指しているか、補助サービスが動作中か確認します。アンインストールする前にシステムプロキシと通信制御機能を無効にし、クライアントの手順に従って補助サービスを処理してください。アプリのアイコンを削除しただけで、すべてのネットワーク設定が復元したと判断しないでください。

Androidの導入と設定

インストールファイル、システム権限、VPNインターフェース

Androidのダウンロードから、まずClash Plusを選んでください。Clash Meta for Android、FlClash、Surfboardも比較できます。対応するサブスクリプション形式や機能の範囲はクライアントごとに異なります。特にSurfboardの設定構文はmihomoのYAMLと同じではありません。通常、デバイスはARMアーキテクチャですが、OSとインストーラーの説明に従って選択してください。インストールに失敗した場合は、アーキテクチャ、システム要件、インストール済みアプリとの署名の整合性を確認します。出所不明のインストーラーを何度も上書きしないでください。

ブラウザーまたはファイルマネージャーからインストールする場合、システムでその提供元からのアプリのインストール許可が必要になることがあります。信頼できる現在の提供元だけに許可を与え、インストール後はデバイスの管理方針に応じて取り消せます。初回接続時にVPNの許可ダイアログが表示されるのは、Androidの通信制御機能によるものです。許可すると通常、システムのVPNアイコンが表示されます。これはサブスクリプションがシステムから提供されるという意味でも、すべてのアプリが想定どおり振り分けられるという意味でもありません。実際の制御範囲は、クライアントのアプリ選択、ルート、実行設定によって決まります。

サブスクリプションの追加と初回接続

設定画面でURL設定を追加するか、ファイルからインポートします。ダウンロードの完了後に現在の設定として選び、プロキシグループを選択できるか確認してください。共有メニューから追加する場合は、Webページのタイトルや途中で切れたテキストではなく、リンク全体が渡されていることを確認します。クリップボードをほかのアプリが読み取る場合があるため、機密性の高いリンクをインポート後も長く残さないでください。ログイン後のWebページでしか開けないリンクは、クライアントで使えるサブスクリプション用のURLを提供元に確認してください。ブラウザーのログイン状態をアプリのリクエスト認証の代わりにはできません。

初回接続はルールモードを使い、プロキシグループを明示的に選んでから、システムのVPN接続を許可してください。ブラウザーでテスト用のアドレスを開き、同時にクライアントの接続ログを確認します。新しい接続がログに出ない場合は、VPNサービスが起動しているか、ブラウザーが除外されていないか、実行中の設定が正しいかを先に確認してください。接続がカーネルに届いているのに失敗する場合は、ログを見てDNS、リモート側のハンドシェイク、ルール選択を確認します。ステータスバーの鍵アイコンだけで、リモートプロキシが使えると判断しないでください。

アプリの振り分けとバックグラウンド動作

Androidのアプリ選択には「選択したアプリのみプロキシを使う」と「選択したアプリを除外する」の2種類が一般的で、リストの意味は逆です。リスト内のアプリとリスト外のアプリをそれぞれ使って、クライアントがどちらの方式なのか確認してください。アプリの振り分けとドメインルールも別の層です。アプリがVPNの対象から除外されていると、その接続はカーネルのルールに届きません。この場合、MATCHの変更やプロキシグループの切り替えでは解決しないため、まずアプリの通信制御範囲を修正してください。

画面ロック後に接続が切れる場合は、まずバッテリー最適化、バックグラウンド動作制限、自動起動、システムのクリーンアップ設定を確認してください。メニュー名はメーカーによって異なるため、システムのアプリ情報画面でバッテリーとバックグラウンドの権限を確認します。継続動作が必要なクライアントだけを個別に調整してください。省電力機能全体を無効にする必要はありません。設定後は、画面ロック、待機、復帰、リクエストの再実行まで一通りテストし、サービスの再起動、設定の再読み込み、バックグラウンド通信の制限を確認します。

DNS、ほかのVPN、ネットワークの切り替え

多くのAndroid端末では、同じユーザー環境で通常のVPNサービスを同時に1つしか維持できません。広告ブロックやファイアウォールなどのネットワークツールが同じインターフェースを使う場合もあり、一方を起動するともう一方が切断されることがあります。クライアントが不規則に終了すると考える前に、ほかのVPN系ツールを停止してテストしてください。システムのプライベートDNS設定が名前解決の経路を変えることもあります。まず現在の値を記録し、比較のために一時的に自動設定へ戻してください。原因を確認してから長期設定を決め、すべてのセキュリティ設定を恒久的に無効にしないでください。

Wi-Fiからモバイルデータ通信に切り替えると、リモートアドレスの名前解決、IPv6の到達性、既存の接続状態が変わることがあります。古い接続だけが失敗する場合は、いったん切断して再接続してください。新しい接続もすべて失敗する場合は、サブスクリプションのネットワーク制限、アプリのモバイルデータ通信の許可、ログインが必要なネットワークかどうかを確認します。キャプティブポータルがある場合は、まず通常のネットワーク接続でログインしてください。この問題はプロキシグループの順序を変えても解決しません。ログインページにアクセスできる基本的なネットワーク状態か、先に確認してください。

システム設定の「VPNを常にON」と「VPNなしの接続をブロック」は、クライアント停止後の通信動作を変えます。ブロックを有効にしている場合、クライアントのサービスが停止して通信できなくなるのは、システムが想定する保護動作であり、別の故障とは限りません。リモートサポートを受ける前に解除方法を記録し、アンインストール後に制限を解除できなくならないようにしてください。サブスクリプションを定期更新する場合は、バックグラウンドリクエストの条件も確認します。画面ロック、省電力、モバイルデータ通信の制限で更新が遅れることがあります。詳しくはサブスクリプション更新の失敗と自動更新の設定を参照してください。

iOSの導入と設定

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

iPhoneとiPadではClash Plusを推奨します。iOSのダウンロードからApp Storeを開くか、Clash PlusのApp Storeページを直接開いてください。プロジェクトの公式サイトはclashplus.ioです。インストール前に、ストアに記載されたシステム要件と機能説明を確認してください。デスクトップ版に同じ名前の設定項目があっても、iOS版で同じように表示されるとは限りません。アプリの現在の画面とシステムの許可ダイアログに従って操作してください。

初回接続時は通常、VPN構成の追加を許可し、デバイスのパスコードまたはシステム認証で確認する必要があります。この構成は、該当する通信をアプリのネットワーク拡張機能に渡すためのもので、Wi-Fiのパスワードでもサブスクリプションのアカウントでもありません。許可する前に、ダイアログに表示されたアプリの提供元を確認してください。構成プロファイルや組織の管理によって制限されているデバイスでは、個人用VPNを追加できないことがあります。これはデバイスのポリシーによる制限であり、サブスクリプションのリンクを貼り直しても解決しません。システム設定で管理状態とネットワーク構成の許可を確認してください。

サブスクリプションを追加して設定の適用を確認する

アプリのサブスクリプションリンクまたはファイルからのインポート機能を使い、ダウンロード完了後に実行する設定を選択してください。Safariでリンクを開く場合は、サブスクリプションのデータとサービス提供元のアカウントページを区別します。Webページに内容が表示されても、コピーしたURLがサブスクリプションのリンクとは限りません。クエリパラメーターを含むリンクは全体を保ってください。入力時に記号が置き換わったり、共有アプリがパラメーターを省略したりすると、リクエストに失敗することがあります。個人用サブスクリプションが含まれた画面のスクリーンショットを公開の問い合わせ先に投稿しないでください。

追加に成功したら、まずプロキシグループと選択項目を確認してからVPN接続を開始してください。設定が複数ある場合は、以前テストに使ったローカルファイルが選択されたままではないか確認します。サブスクリプションの更新でプロキシ一覧が置き換わると、アプリに保存された選択状態が以前の名前に対応しなくなることがあります。更新後にメインのプロキシグループが意図した項目を選んでいるか確認してください。接続ログにDIRECTと表示されても、すぐノードの障害と判断しないでください。その接続先が直結ルールの対象か、ルールモードか直結モードかも確認します。

iOSの通信制御の仕組みを理解する

iOSのクライアントは通常、システムのネットワーク拡張機能を使って通信を制御します。Windowsのように「ローカルポートを入力してシステムプロキシを有効にする」手順をそのまま使うことはできません。Wi-Fiの詳細設定にあるHTTPプロキシは別の仕組みです。アプリを接続するために、デスクトップの例にあるアドレスを安易に入力しないでください。iPhone上の127.0.0.1はiPhone自身を指し、同じネットワーク上のPCではありません。PCクライアントのループバックアドレスをiPhoneにコピーしても、デバイス間のプロキシ接続は確立できません。LAN経由で共有するには、サーバー側で接続を許可し、アクセス制御を正しく設定する必要があります。

デスクトップ向けドキュメントのTUN、サービスモード、システムプロキシのスイッチは、それぞれの通信制御方式を説明するものです。iOSで同名のボタンを探さなければ動作しない、という意味ではありません。実際の制御範囲、DNS処理、利用できるルールは、クライアントの実装とシステムインターフェースの両方で決まります。特定のアプリだけで失敗する場合は、まず新しい接続が作成されているか、アプリ独自のプロキシやネットワークポリシーがないかを確認し、その後でルールを調べてください。ノードを切り替えても既存の長時間接続は以前の経路を使い続ける場合があります。比較するにはリクエストを再実行してください。

モバイルデータ、オンデマンド接続、復旧

初回の確認ではほかのVPN構成を無効にし、安定したネットワークで手動接続して基本の通信経路を確認してから、オンデマンド接続などの自動化機能を検討してください。自動接続ルールはネットワークの変化をきっかけに動作し、手動で切断した後に再接続することがあります。原因を調べる際は関連設定を記録し、自動起動を一時的に無効にしてください。システムまたは他社製のプライバシー系ネットワーク機能を同時に使う場合は、それぞれを個別にテストし、複数のネットワーク処理がリクエスト経路を分かりにくくしないようにします。機能は一度に1つだけ変更し、比較できる結果を残してください。

Wi-Fiからモバイルデータ通信に切り替えた後に失敗する場合は、Clash Plusのモバイルデータ通信が許可されているか、現在のネットワークが実際に利用できるか、リモートアドレスを名前解決できるか確認してください。画面ロック中はネットワーク拡張機能とアプリ本体で動作の仕組みが異なります。アプリが前面に表示されていないだけで、サービスが停止したとは判断できません。接続が繰り返し切れる場合は、アプリの診断情報とシステムのVPN状態を照らし合わせ、切断がローカル側かリモート側かを特定します。ルールの多い設定では、トラブル調査中にリソースを次々追加しないでください。まず動作が分かっている小規模な設定で検証します。

接続後にデバイス全体が通信できなくなった場合は、まずアプリで切断し、システムのVPN画面で状態を確認してください。必要ならオンデマンド接続を一時的に無効にし、切断直後に再接続されないようにします。基本ネットワークが復旧したら、直近のサブスクリプション更新、ルールのオーバーライド、DNSの変更を確認してください。アプリを削除する前に必要な設定をエクスポートし、ほかのデバイスからサブスクリプションの取得元にアクセスできることも確認します。段階的なトラブル対処はヘルプセンターを参照してください。診断情報を共有する際は、エラーの種類と必要な項目だけを残し、ログ内の機密情報を伏せてください。

Linuxデスクトップとサーバー

デスクトップとヘッドレス環境は別々に選ぶ

デスクトップではLinuxのダウンロードからClash Verge RevまたはFlClashを選び、ディストリビューションのパッケージ形式、アーキテクチャ、依存関係を確認してください。GUIクライアントはサブスクリプション管理やトレイ操作を担いますが、Linuxではデスクトップ環境によってシステムプロキシへの対応が異なります。デスクトップ環境に設定を書き込めても、すべてのプログラムがその設定を読み込むとは限りません。ヘッドレスサーバーではmihomoを直接実行し、設定ファイルとsystemdで管理できます。どちらか一方を主な管理手段として選び、GUIクライアントと独立したサービスが同じポートを同時に使わないようにしてください。

GUIクライアントをインストールしたら、まずサブスクリプションを追加して実行設定を選び、ログを確認してからデスクトッププロキシを設定します。ターミナルのコマンドがプロキシを使わない場合は、システム全体の環境設定ファイルをすぐに変更せず、まず単発のコマンド引数で経路を確認してください。サーバーでは先に設定ディレクトリと権限を整え、実行ユーザーが設定ファイルと参照先のルールリソースを読み込めることを確認します。サービスにホームディレクトリ全体を公開しないでください。1つの権限エラーを解消するために全ユーザーへ再帰的に書き込み権限を与えると、設定やサブスクリプションが漏えいするリスクが高まります。

コマンドラインでの起動と設定テスト

以下の例では、mihomoの実行ファイルが/usr/local/bin/mihomo、設定ファイルが/etc/mihomo/config.yamlにインストールされているものとします。これらは例で定めたパスです。実際の配置は異なっても構いませんが、コマンドとサービスファイルで同じパスを使ってください。まずテストを行い、次にフォアグラウンドで起動してから常駐サービスを設定します。次の最小設定で確認できるのは、ローカルでの待ち受けと直結通信だけです。リモートプロキシは含まれていないため、自分のサブスクリプションの代わりにも、特定のプロキシ出口の動作確認にも使えません。

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

/usr/local/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml
/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
curl --proxy http://127.0.0.1:7890 --head https://example.com

まずテストコマンドを実行して設定の解析エラーを解消し、次にフォアグラウンドで起動して待受ログを確認します。ルールリソース、地理データベース、プロキシグループには、追加ファイルやネットワークリクエストが必要な場合があります。設定構文に問題がなくても、外部依存のすべてが利用できるとは限りません。サービス提供元の設定を使う場合は全体を保存して再テストし、参照先のパスと実行ディレクトリも確認してください。フォアグラウンドでの検証が終わったらプロセスを停止してからsystemdに引き継ぎます。これを怠ると、サービス起動時にポート競合が発生し、設定ファイル自体が壊れていると誤解することがあります。

通常のプロキシサービスをsystemdで管理する

専用のシステムユーザーmihomoを作成し、そのユーザーに作業ディレクトリの読み取り権限と必要な書き込み権限を付与してから、次のサービスファイルを作成します。この例ではTUNを有効にせず、通常のユーザーとしてローカルプロキシを実行します。仮想インターフェースの権限が必要なサービスに、そのまま流用しないでください。ユーザー作成コマンドはディストリビューションごとに異なるため、システム標準のアカウント管理ツールを使ってください。設定とキャッシュのディレクトリを共用する場合は、更新が必要なファイルを明確にしてください。サブスクリプションやルールを更新する段階になってから権限不足が判明するのを防げます。

# /etc/systemd/system/mihomo.service
[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 -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
UMask=0077

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -b -n 80 --no-pager

設定を変更したら、サービスと同じユーザー、同じパスでテストしてからサービスを再起動し、今回の起動ログを確認してください。network-online.targetが実際に待機するかどうかは、ディストリビューションに適切なネットワーク待機サービスが設定されているかによります。任意のリモートリソースに必ず到達できるとは限りません。このunitだけではサブスクリプションの更新も行われないため、ダウンロード、テスト、入れ替えの手順を別途用意してください。新しい設定の検証に失敗した場合は古いファイルを残し、定期実行タスクがエラーページを正式な設定として上書きしないようにします。

TUNの権限、コンテナ、ターミナル環境

LinuxでTUNを使うには、仮想インターフェース用のデバイス、ネットワーク管理権限、適切なルート設定が必要です。YAMLにenable: trueを設定しただけで権限が揃ったと考えないでください。コンテナでは、デバイスの割り当て、ネットワーク名前空間、ケーパビリティによる制約も受けます。まずホスト環境で通信経路を理解してから、コンテナでの通信制御を設計してください。通常のプロキシサービスとTUNサービスでは必要な権限が異なります。変更前に必要なケーパビリティとその範囲を確認し、問題を隠すために環境全体を高権限で実行しないでください。

ターミナルのセッションでは必要に応じてプロキシ環境変数を設定できますが、バックグラウンドサービスは対話型シェルの環境をすべて自動で引き継ぐわけではありません。逆に、mihomo自身によるサブスクリプションやリソースのリクエストを、まだ起動していないプロキシポートへ誤って向けないようにしてください。リモートサーバーのデフォルトルートを変更する前に、2つ目の管理用セッションとロールバック手段を確保し、SSHの経路が切り替わって接続不能になるのを防ぎます。デスクトップとヘッドレス構成の詳しい比較はLinuxでのmihomo導入に関する技術メモを参照してください。

設定のよくある問題と復旧

設定ファイルの解析エラーとルール名

YAMLではインデントにスペースを使い、タブを混在させないでください。同じ階層ではインデントを揃え、リスト項目を正しい親フィールドの下に置きます。行番号のエラーが出たら、エラー行だけでなく、その前の行のコロン、引用符、インデントも確認してください。設定をリッチテキストエディターに貼り付けると、全角の記号や見えない文字が混入することがあります。プレーンテキストエディターを使ってください。エラーを隠すためにrules全体を削除しないでください。カーネルが起動することと、通信が期待どおりに振り分けられることは別の目標です。ルールを消すとすべての接続経路が変わる場合があります。

ルールは記述順に照合されます。具体的なドメインルールは、通常、汎用的なフォールバックより前に置きます。次はルールの一部であり、PROXYは実行設定に存在するプロキシまたはプロキシグループ名と一致している必要があります。サブスクリプションで別のグループ名が使われている場合は、空のグループを新しく作るのではなく、参照先を変更してください。設定内の名前は正確に一致させる必要があり、大文字・小文字、スペース、記号の違いでも参照先が見つからないことがあります。ルールに一致したかどうかと、プロキシグループで最終的に何が選ばれているかは別々に確認してください。プロキシグループに一致しても、そのグループでDIRECTが選択されている場合があります。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

システムプロキシは動くがTUNが失敗する

システムプロキシはアプリがプロキシ設定に従うことを前提とします。一方、TUNは仮想インターフェースとルートを使って、より広い範囲の接続を制御します。必要な権限、DNSの経路、影響する障害の範囲も異なります。システムプロキシは使えるのにTUNが失敗する場合は、サブスクリプションをすぐ変更せず、権限とルートを先に確認してください。次はmihomoのTUN設定項目の一部であり、単独で使える設定ではありません。クライアントが画面からこれらの項目を生成または上書きする場合もあります。有効にする前にDNSを含む設定全体を整えてください。この抜粋だけをコピーしても、すべてのプラットフォームで同じ動作が保証されるわけではありません。

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

DNSのリダイレクト設定は、対象となる従来型のDNSリクエストに対するものです。すべての暗号化DNSが同じようにカーネルへ届くとは限りません。ブラウザーのセキュアDNS、システムのプライベートDNS、IPv6のルート、アプリ内蔵のリゾルバーによって、確認結果が変わる場合があります。まずDNSの名前解決が失敗しているのか、接続自体が失敗しているのかを特定してから、resolver、fake-ip、ルート除外の変更を検討してください。詳しい仕組みはTUNモードとシステムプロキシの違いを参照し、1つのアプリの問題に対して複数のネットワーク層を同時に変更しないでください。

サブスクリプションの更新、オーバーライド、外部リソース

サブスクリプションの更新に失敗しても、前回正常に動作した設定を残し、ステータスコード、タイムアウトの種類、解析エラーの行番号を記録してください。リンク切れ、権限の期限切れ、Webページへの応答の置き換わり、リクエスト先へのネットワーク障害では、それぞれ対処方法が異なります。サブスクリプションの更新にプロキシが必要なのに、そのプロキシも同じサブスクリプションに依存する場合は、起動ループを避けるために確実な更新経路を事前に用意してください。自動更新の間隔は提供元の制限と実際の必要性に合わせ、ひとまずのエラーに対して短時間に何度もリクエストしないでください。

ルールセットとプロキシグループには、それぞれ別のキャッシュや更新時刻がある場合があります。メインのサブスクリプションを更新できても、すべてのリソースが更新されたとは限りません。オーバーライドを変更したら最終的な実行設定を確認し、特にポート、DNS、グループ名、ルールの順序、待受アドレスを照合してください。クライアントに設定のプレビューやエクスポート機能がある場合、出力にサブスクリプション情報や認証情報が含まれることがあるため注意してください。他者に相談する前に必ず機密情報を伏せます。解析エラーが再現する場合は、個人用設定全体を送るより、必要最小限の抜粋を共有するほうが役立ちます。

症状に合わせて次の確認項目を決める

症状	まず確認する項目	検証方法
ローカルプロキシへの接続が拒否される	カーネルの動作と待受ポート	起動ログとポートの使用状況を確認
プロキシを明示すると成功するが、アプリは失敗する	アプリの通信制御と個別のプロキシ設定	接続ログにリクエストが記録されているか確認
ドメインには接続できないが、一部のIPアドレスには到達できる	DNSと名前解決の経路	名前解決ログとシステムDNSを比較
更新後に初めて問題が発生した	グループ名、オーバーライド、外部リソース	以前の設定に戻して差分を確認

トラブルの記録には、プラットフォーム、クライアント名、現在のモード、通信制御の方式、エラーが発生した段階、関連ログの機密情報を伏せた抜粋を含めてください。ノードの速度テスト、ブラウザーでのアクセス、バックグラウンド更新を同じテストとして扱わないでください。対象やリクエスト経路が異なる場合があります。特定のWebサイトだけで失敗する場合は、サービス自体の状態、出口の地域に関するポリシー、アカウント制限も考慮してください。モードを手当たり次第に切り替えるより、リクエストが想定したプロキシグループに届いていることを確かめてから、リモート側への到達性を確認するほうが効果的です。

修復後は、検証できた最小限の変更だけを長期設定に反映し、バックアップも更新してください。クライアントのアップグレード、カーネルの切り替え、デバイスの移行後は、以前の環境での結果をそのまま当てはめず、基本の検証をやり直します。問題から対処方法を探す場合はヘルプセンター、設定項目の意味を調べる場合は用語集を参照してください。このページではプラットフォームをまたぐ設定の違いを扱います。初回設定はクイックスタートに沿って進め、基本接続が確立する前に高度な機能を追加しないことをおすすめします。