Clash 全対応OSインストール・設定ガイド

PREPARE / INPUT CHECK

インストール前の共通準備

OSのアーキテクチャ、設定の入手元、通信の入口を先に確認しておけば、パッケージの選択ミス、サブスクの不具合、システムプロキシが反映されない問題を混同せずに済みます。

OS、アーキテクチャ、クライアントの役割を確認する

ダウンロード前に、OS名、バージョン、プロセッサのアーキテクチャを控えてください。一般的なWindows端末はx64、一部の新しい端末はARM64です。macOSではIntelとApple Siliconを区別します。AndroidのパッケージはARM64、ARM、ユニバーサル版に分かれる場合があります。Linuxではアーキテクチャに加え、deb、rpm、圧縮ファイルの違いも確認が必要です。アーキテクチャが合わない場合、インストーラーが起動しない、OSに非対応と表示される、起動直後に終了するといった症状が発生します。ファイル名に「64」とあるだけで判断せず、システム情報でプロセッサの種類を確認してから、ダウンロードページで対応する項目を選んでください。

Clashのエコシステムは、一般に「コア」と「GUIクライアント」の2層で構成されます。コアはYAML設定の読み込み、接続の確立、ルールの実行、プロキシポートの提供を担当します。GUIクライアントはサブスク管理、モード切り替え、システムプロキシ、ログ表示を担当します。通常のデスクトップやモバイル端末ではGUIクライアントを優先し、サーバー、ルーター、またはサービスとして動かすLinux環境でのみMihomoコアを直接導入します。本サイトでは各OSともClash Plusを第一候補としています。WindowsとmacOSではClash Verge Rev、FlClash、AndroidではClash Meta for Android、FlClash、Surfboardも選択できます。Clash for WindowsとClashX Metaはメンテナンスが終了しており、既存環境の移行用途に限られます。新規の長期運用には推奨しません。

サブスクまたはローカルYAML設定を準備する

クライアントをインストールしただけでは接続できません。別途、設定のインポートが必要です。主な入力方法は、サブスクURLとローカルYAMLファイルの2種類です。サブスクURLは設定の提供元が発行し、クライアントはそこからノード、ポリシーグループ、ルールを取得します。ローカルファイルは、オフライン編集、ルールの検証、管理された環境での固定設定の保存に向いています。インポート前にURLが完全であり、コピー時に空白、改行、日本語の句読点が混入していないことを確認してください。サブスクURLは機密情報です。公開スクリーンショット、掲示板の投稿、公開設定のブラウザブックマーク、共有文書には掲載しないでください。

初回の検証用として、構成が単純で過去に正常に読み込めた設定を1つ残しておくことをおすすめします。複雑な設定には、プロキシプロバイダー、ルールプロバイダー、スクリプト、スニッフィング、DNS上書き、多段のポリシーグループが含まれることがあり、リモートリソースのどれか1つに接続できないだけでも読み込みに影響します。まず基本設定でクライアント、OS権限、プロキシの入口を確認し、その後に複雑なルールを段階的に追加するほうが、すべての機能を一度に取り込むより原因を特定しやすくなります。サブスクを更新する前には、現在正常に使える設定名も覚えておいてください。新しい設定の解析に失敗しても、すぐ以前の設定へ戻せるため、通信が切れた状態で編集を続けずに済みます。

システムプロキシとTUNの違いを理解する

システムプロキシは通常、HTTPおよびSOCKSプロキシのアドレスをOSに設定します。システムのプロキシ設定に従うブラウザやアプリは通信をClashへ渡します。導入が簡単でオン・オフも分かりやすい一方、コマンドラインツール、ゲーム、ストアアプリ、独自のネットワークスタックを使うソフトウェアは迂回することがあります。TUNモードは仮想ネットワークインターフェースを作成し、より多くのTCP、UDP、システムプロキシを参照しないアプリの通信をルール処理へ取り込みます。対象範囲が広い反面、より高い権限が必要で、他のVPN、仮想NIC、エンドポイントセキュリティソフト、社内ネットワークポリシーと競合しやすくなります。

確認項目	システムプロキシ	TUNモード	初回の推奨手順
必要な権限	システムのプロキシ設定を変更	仮想インターフェースまたはサービスを作成	まずシステムプロキシで動作確認
対象アプリ	プロキシ設定に従うアプリ	より広いシステム通信とUDP	アプリの要件に応じて拡張
主な競合要因	ブラウザ拡張機能、手動プロキシ	他のVPN、仮想NIC、ファイアウォール	通信の入口は一度に1つだけ有効化

導入記録と基準状態を作る

インストール前に他のプロキシやVPNツールを一時終了し、普段使うサイトへ直接アクセスできるか記録してください。インストール後はTUNを有効にせず、設定をインポートし、ルールモードを選択してシステムプロキシを有効にします。その後、一般的なWebページへアクセスしてログを確認します。これにより、クライアントが起動するか、設定を解析できるか、プロキシポートが待ち受けているか、システムプロキシを書き込めるか、ルールに一致するかという明確な基準状態を作れます。各手順を1つずつ進めれば、異常が起きても対象を1つの段階に絞れます。会社、学校、管理対象の端末では、サービスのインストール、VPN設定の追加、ネットワーク設定の変更が制限されることもあります。現在のアカウントに必要な権限があるか、事前に確認してください。

WINDOWS / DESKTOP

Windows：インストール、システムプロキシ、TUN

Windowsで重要なのは、インストーラーのアーキテクチャ、ネットワーク権限、システムプロキシの残存設定、仮想NICサービスです。

インストーラーを選び、初回起動を完了する

Windowsへの新規導入ではClash Plusを優先してください。操作画面の好みに応じてClash Verge Rev、FlClash、Clash Nyanpasuも選択できます。Clash for Windowsはメンテナンスが終了しています。既存ユーザーは設定をエクスポートするか記録したうえで、現在もメンテナンスされているクライアントへ移行してください。「設定 → システム → バージョン情報」を開き、システムの種類がx64かARM64かを確認します。ダウンロードページで現在提供しているアーキテクチャは各カードの説明を基準にしてください。macOSやLinux向けの圧縮ファイル、MihomoコアのファイルをWindows用GUIクライアントと取り違えないよう注意してください。

インストーラーを実行すると、ユーザーアカウント制御の確認が表示される場合があります。通常のアプリケーション用フォルダーへインストールして起動し、まずメイン画面が正しく開くことを確認してから、ファイアウォールの確認に対応してください。家庭や職場のLANで使う場合、通常はプライベートネットワークのアクセス許可で十分です。パブリックネットワークを許可するかは、端末を使う環境に応じて判断してください。ダブルクリックしても画面が表示されない場合は、タスクマネージャーでプロセスが起動済みか確認し、システムトレイも確認します。一部のクライアントは初期状態でトレイへ最小化されます。それでも画面が表示されない場合は、異なるクライアントを何度もインストールするのではなく、セキュリティポリシーがアプリをブロックしていないか確認してください。

サブスクを登録してポリシーを選ぶ

クライアントの設定、サブスク、またはProfilesページでインポート項目を探し、完全なサブスクURLを貼り付けてダウンロードします。正常に取り込めると、通常は設定名、更新日時、ポリシーグループの一覧が表示されます。サブスクの記録だけが表示され、ポリシーが1つもない場合は、リモートコンテンツを取得できていない、返された内容がClash YAMLではない、または設定の解析に失敗している可能性があります。ログでHTTPステータス、YAMLの行番号、providerエラーを確認してください。設定レイヤーの問題は仮想NICとは関係がないため、この段階でTUNを有効にしないでください。

設定を有効化したら、プロキシまたはポリシーのページを開きます。ルールモードは設定内のrulesを上から順に照合するため、通常利用に適しています。グローバルモードは通信を指定したポリシーへ送るため、特定ノードが動作するか短時間で確認する用途に向いています。DIRECTモードは、プロキシを使わない状態でローカル回線が正常か確認するために使います。初回確認では、まずルールモードを選び、主要なポリシーグループで利用可能なノードを明示的に1つ選択してください。自動ポリシーグループはヘルスチェックの完了後に候補を決定します。チェック先へ到達できない場合、自動グループはすべてタイムアウトと表示されることがありますが、必ずしもすべての実通信が利用不能とは限りません。ブラウザでのアクセス結果と接続ログも併せて判断してください。

システムプロキシを有効にしてポートを確認する

「システムプロキシ」を有効にすると、クライアントはローカルのループバックアドレスと待受ポートをWindowsのプロキシ設定へ書き込みます。この時点でWindowsのプロキシ設定を開くと、セットアップスクリプトまたは手動プロキシの状態が変わっているはずです。ブラウザでサイトへアクセスした後、クライアントの接続一覧から対象ドメイン、ルール名、最終ポリシーを探します。ブラウザではアクセスできてもコマンドラインツールでは失敗する場合、そのツールがWindowsのシステムプロキシを参照していない可能性があります。PowerShellでは現在のセッションに環境変数を明示的に設定できます。ポートはクライアント画面に表示される実際のmixed-portへ置き換えてください。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe https://example.com

テスト後にターミナルウィンドウを閉じれば、このセッションの変数は消去されます。恒久設定にする場合は、ツールが対応する変数の範囲を先に確認し、使用をやめたローカルポートをシステム環境変数に残さないようにしてください。netstat -anoまたはPowerShellのネットワーク接続コマンドを実行し、該当ポートが待ち受けているか確認することもできます。ポートが使用中の場合、クライアントのログには通常、bindまたはaddress in useエラーが表示されます。使用中のプロセスを特定するか、設定ファイルとクライアント設定の両方でポートを統一して変更してください。画面上の設定だけを変え、設定ファイルに古いポートを残してはいけません。

TUNの有効化とWindows固有の競合対処

TUNを使うには通常、サービスのインストールまたは管理者権限での実行が必要です。まず他のVPN、ゲーム向けアクセラレーター、旧Clashクライアントを終了し、クライアントの案内に従ってサービスをインストールしてTUNを有効にします。正常に動作すると、ネットワークアダプターの一覧に対応する仮想インターフェースが現れ、システムプロキシを参照しないアプリの通信も接続ログへ記録されるようになります。有効化後にシステム全体がオフラインになった場合は、まずTUNを無効にして基本通信が戻ることを確認してください。その後、DNSモード、デフォルトルート、サービスの状態、ファイアウォールを確認します。オフラインのままネットワークのリセット、ドライバーの削除、設定変更を同時に行うと、比較できる基準状態を失うため避けてください。

Windowsがスリープから復帰したとき、有線からWi-Fiへ切り替えたとき、社内VPNへ接続したときには、ルートやDNSが変化することがあります。復帰後に通信できない場合は、システムプロキシ、TUN、クライアントの順に終了し、再起動後に1項目ずつ有効にしてください。システムプロキシを無効にしてもアクセスできない場合は、Windowsのプロキシ設定にアドレスが残っていないか確認します。必要に応じてWinHTTPプロキシも確認しますが、ブラウザのプロキシとWinHTTPを同じものとして扱わないでください。また、クライアントを管理者として実行することと、システムサービスをインストールすることは別です。前者は現在のプロセスの権限を上げるだけですが、後者はバックグラウンドコンポーネントが継続的に仮想インターフェースを管理できます。クライアントが用意するサービスのインストール手順を優先してください。

MACOS / NETWORK SERVICE

macOS：チップの種類、システム拡張、ネットワークサービス

macOSではチップのアーキテクチャを正しく選び、アプリの隔離、ネットワーク拡張の許可、ネットワークサービスごとのプロキシ設定に注意する必要があります。

Apple SiliconとIntelを区別する

Appleメニューの「このMacについて」をクリックし、チップまたはプロセッサの欄を確認します。Apple製チップが表示される場合はApple SiliconまたはARM版、Intelと表示される場合はx64版のパッケージを選んでください。新規導入ではClash Plusを優先し、Clash Verge RevまたはFlClashも選択できます。ClashX Metaはメンテナンスが終了しており、残しておく主な目的は旧設定の移行です。新しい環境の標準クライアントには適していません。アーキテクチャを間違えると、アプリが起動しない場合や、互換レイヤー経由で動作して余分なリソースを消費する場合があります。最初から端末に合うファイルを選んでください。

GUIクライアントは一般にディスクイメージまたは圧縮ファイルとして配布されます。イメージを開いたらアプリを「アプリケーション」フォルダーへドラッグし、そのフォルダーから起動してください。ダウンロードフォルダーや読み取り専用のイメージ内で常用しないでください。初回起動時に提供元の確認が表示された場合は、システム設定の「プライバシーとセキュリティ」でブロックされたアプリを確認します。本サイトのダウンロード先から入手したファイルであることを確認したうえで、macOSの許可手順を進めてください。1つのアプリを開くためにシステム全体のセキュリティ機能を無効にしないでください。通常の許可手順でインストールでき、後からネットワーク拡張やバックグラウンド項目も管理しやすくなります。

設定をインポートしてシステムプロキシを許可する

クライアントを起動し、Profiles、設定、またはサブスクの画面でURLを貼り付けて更新します。macOSによってURL内の特殊文字が自動変換される場合は、まず標準テキスト形式のエディターへ貼り付けて1行全体を確認してから、クライアントへコピーすることをおすすめします。設定を正常にダウンロードできたら、アクティブな設定として選択し、ポリシーグループにノードやDIRECT、REJECTなどが表示されるか確認してください。YAMLの解析に失敗すると、ログには通常、インデントやフィールド型の問題が示されます。リモートproviderの失敗は一部のルールやノードだけに影響する場合があるため、メイン設定の読み込みと追加リソースの更新を分けて判断してください。

システムプロキシを有効にする際、macOSから現在のユーザーのパスワードまたは生体認証を求められる場合があります。これはネットワーク設定の変更を許可するためです。許可後、プロキシは通常、現在使用中のWi-FiやEthernetなどのネットワークサービスへ設定されます。ネットワークサービスを切り替えた際、新しいサービス側にプロキシ設定がなければ、クライアント上では有効と表示されていてもアプリの通信が取り込まれないことがあります。その場合はシステムプロキシを一度無効にしてから再度有効にし、現在のネットワークへ書き直してください。「システム設定 → ネットワーク → 現在のネットワーク → 詳細 → プロキシ」で、Webプロキシと保護されたWebプロキシがローカルのループバックアドレスを指しているか確認することもできます。

ターミナルアプリとローカルネットワークへのアクセス

ターミナル内のcurl、パッケージマネージャー、開発ツールは、GUIのシステムプロキシに従うとは限りません。コマンド単位で一時的に変数を設定できます。実際のポートはクライアントの表示に合わせてください。

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
curl -I https://example.com
unset http_proxy https_proxy

変数をshellの設定ファイルへ書き込む前に、常時有効にする必要があるか確認してください。ノートパソコンを現在のネットワークから持ち出した後、ローカルのClashが起動していないと、恒久設定されたプロキシ変数によりターミナルのリクエストが存在しないポートへ送り続けられます。プロジェクト単位またはターミナルセッション単位で有効にするほうが安全です。LAN共有も慎重に設定してください。他の端末から接続する必要が明確な場合にのみAllow LANを有効にし、待受アドレス、ファイアウォール、信頼するネットワークの範囲を併せて検討します。普段はこのMacだけで使うなら、ループバックアドレスで待ち受けることで不要なLAN側の入口を減らせます。

TUN、ネットワーク拡張、スリープからの復帰

TUNを有効にすると、クライアントから補助サービスのインストールやVPN構成の追加を求められる場合があります。システム設定には対応するネットワーク拡張が表示され、メニューバーにもVPNの状態が現れることがあります。初回許可後にスイッチがすぐオフへ戻る場合は、「プライバシーとセキュリティ」に承認待ちの項目が残っていないか確認してから、クライアントを再起動してください。会社が管理するMacでは、構成プロファイルによってネットワーク拡張が制限され、一般ユーザーが解除できないことがあります。許可されている範囲を端末の管理担当者へ確認してください。

macOSでiCloudプライベートリレー、社内VPN、他のプロキシアプリ、ネットワークフィルター拡張を同時に有効にすると、通信経路が互いに上書きされることがあります。問題を調べる際は、通信を管理するツールを1つだけ残し、他のネットワーク拡張を無効にしてから、システムプロキシモードで確認を始めてください。スリープからの復帰後、IPアドレスには接続できるのにドメイン名を解決できない場合は、DNSとTUNインターフェースが再作成されているか重点的に確認します。すべての通信がログに入らない場合は、ネットワークサービスの切り替えとシステムプロキシの書き込みを確認してください。クライアントを終了する前にシステムプロキシとTUNを無効にしておくと、異常終了後もOSがローカルポートを参照し続ける事態を減らせます。

アプリに「接続済み」と表示されても、それはローカルコンポーネントが起動したことを示すだけで、対象への通信が想定したポリシーを通っているとは限りません。Connectionsまたはログでアクセス先ドメインを探し、一致したルールとポリシーグループを確認してください。ブラウザに独自のプロキシ拡張機能が入っている場合、その拡張機能がシステム設定を上書きすることがあります。基準状態をテストする間は無効にしてください。ルールとポリシーグループの仕組みは、ポリシーグループの種類を詳しく解説も併せて読むと理解しやすくなります。自動選択グループのヘルスチェック結果だけで、システム全体の通信状態を判断しないでください。

ANDROID / VPN SERVICE

Android：VPN権限、バックグラウンド動作、アプリ別ルーティング

AndroidクライアントはOSのVPNインターフェースを使って通信を取り込みます。安定性は、省電力設定、バックグラウンド制限、端末メーカー独自のネットワーク制御にも左右されます。

インストールと初回VPN許可

Androidへの新規導入ではClash Plusを優先してください。Clash Meta for Android、FlClash、Surfboardも利用できます。ダウンロード前に、システム情報でAndroidのバージョンとプロセッサのアーキテクチャを確認します。ダウンロードページにARM64、ARM、ユニバーサル版がある場合、近年の主要端末は一般にARM64ですが、必ず端末情報を基準に選んでください。ブラウザからパッケージをダウンロードしてインストールする際、使用中のブラウザまたはファイル管理アプリに「不明なアプリのインストール」の許可を求められる場合があります。インストール後はその許可を取り消し、一時的なインストール権限を開放したままにしないでください。

初めて接続を有効にすると、AndroidにVPN接続の確認が表示されます。これはローカルの仮想ネットワークインターフェースを作成する標準的な手順です。許可後、通常はステータスバーにVPNアイコンが表示されます。端末上で別のVPN、仕事用プロファイルのVPN、広告ブロックツール、プライベートDNSアプリが動いている場合、OSはそのうち1つにしかインターフェースの利用を許可しないことがあります。どのツールを主要な通信入口にするか先に決めてください。複数のVPNアプリで接続を何度も奪い合うと、スイッチが自動でオフになる、一時的に通信が切れる、DNS経路が一致しないといった問題が起きます。

サブスクの登録と設定の更新

設定管理画面を開き、URLまたはファイルからインポートします。クリップボードからサブスクURLを貼り付けた後、先頭部分、パス、クエリパラメータが欠けていないか確認してください。入力アプリが末尾に空白を加えたり、チャットアプリが長いURLを途中で省略したりすると、リクエストに失敗します。インポート後は新しい設定を明示的に選択し、現在のアクティブ項目にしてください。サブスクを一覧へ保存しただけで有効化していないことは、「設定は見えるのにノードがない」問題のよくある原因です。サブスクの更新は、できるだけ安定したネットワークでVPNを一時的に切った状態で行ってください。旧設定のルールによって、更新リクエストが利用不能なポリシーへ送られるのを防げます。

ノードとポリシーグループが表示されたら、まずルールモードと明示的なポリシーを1つ選び、VPNを開始します。Webページへアクセスしてからログを開き、ドメインがルールに一致しているか確認してください。AndroidアプリはQUIC、HTTP/3、独自DNSを使うことがあり、デスクトップブラウザと同じ挙動になるとは限りません。特定のアプリだけ失敗する場合は、まずシステムブラウザで基準となる動作を確認し、そのアプリがアプリ別設定で除外されていないか、IPv6のみを使っていないか、独自のセキュアDNSを有効にしていないか確認してください。

バックグラウンド動作とバッテリー設定

モバイルで最も多い問題は設定の解析ではなく、画面ロック後にOSがクライアントを制限することです。OSのバッテリー設定で現在のClashクライアントにバックグラウンド動作を許可し、必要に応じて自動起動やバックグラウンドアクティビティも許可してください。端末メーカーによってメニュー名は「電池の最適化」「バックグラウンドでの使用制限」「自動起動の管理」「アプリ起動管理」など異なります。最近使ったアプリのカードを固定するだけでは、OSレベルのバックグラウンド権限の代わりにはなりません。通常は手動で終了される可能性が下がるだけです。データセーバーによってクライアントのモバイルデータ利用が制限されていないことも確認してください。

画面ロックから数分後に接続が切れ、ロック解除すると復帰する場合は、省電力設定とバックグラウンド制限を優先して確認してください。Wi-Fiでは正常でモバイル回線だけ失敗する場合は、モバイルデータの権限、IPv6、通信事業者のネットワーク環境を確認します。すべてのネットワークで一定時間後に切れる場合は、サブスク内のノードの可用性とヘルスチェックを確認してください。モバイル端末でVPNを常時接続すると、ある程度のバックグラウンド処理が発生します。ルール数、DNSクエリ、頻繁なヘルスチェック、多数の接続はバッテリー消費に影響します。モバイル端末の異常なバッテリー消費を調べるも参考にし、不要な頻回テストを減らす、安定したポリシーを使う、バックグラウンドでの起動を確認するといった方法で、通常の消費と異常なループを見分けてください。

アプリ別プロキシ、除外、LANアクセス

Androidクライアントには一般にアプリ別プロキシがあり、「選択したアプリのみプロキシする」または「選択したアプリを除外する」を選べます。リストを作る前に目的を明確にしてください。少数のアプリだけをClashへ通す場合は対象を含めるモードを使います。大半のアプリにルールを適用し、銀行アプリやLAN用ツールだけをDIRECTにする場合は除外モードを使います。2つのモードは意味が逆なので、切り替え後にリストを再確認してください。アプリの更新や再インストールで内部識別子が変わることがあります。特定のアプリが突然迂回するようになった場合は、リストを開き直して確認してください。

プリンター、テレビ、ルーターの管理画面など、LAN内の機器へ接続できない場合は、まず設定上でLANアドレスがDIRECTになっているか確認し、クライアントにLANを除外する項目があるか確認してください。一般的なプライベートアドレスには10.0.0.0/8、172.16.0.0/12、192.168.0.0/16がありますが、実際のネットワークでIPv6のローカルアドレスを使っている場合もあります。1台のLAN機器へ接続するためにグローバルDIRECTへ切り替え、そのまま戻し忘れないようにしてください。ログで対象アドレスを特定し、明示的なルールを追加するか、LANの除外設定を調整するのが適切です。

「VPN接続済みなのに通信できない」場合は、まず接続を停止し、スマートフォン本来の通信が利用できるか確認してください。その後クライアントを起動し、システムブラウザだけでテストします。ログにリクエストがまったくない場合は、VPN権限とアプリ別の除外設定を確認します。リクエストがありDNSエラーが表示される場合は、DNS設定とプライベートDNSを確認します。プロキシに一致した後でタイムアウトする場合は、ポリシーとノードを確認してください。再インストールを繰り返すより、層ごとに状況を確認するほうが効果的です。再インストールしても、サブスク、バックグラウンド設定、競合するVPNアプリは自動では直りません。

IOS / NETWORK EXTENSION

iOS：Clash Plus、VPN構成、OSの制限

iOSはシステムのネットワーク拡張で接続を管理します。インストール先、VPNの許可、オンデマンド接続、システムのネットワークサービスが主な確認項目です。

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

iPhoneとiPadでは、本サイトのダウンロードページにあるClash PlusのApp Storeリンクを利用してください。クライアントの公式サイトはclashplus.ioです。ストアページを開き、通常の手順でインストールしてから、ホーム画面より起動します。iOSではプロセッサのアーキテクチャを選ぶ必要も、デスクトップ向け形式のファイルを手動でインストールする必要もありません。ストアページを開けない場合は、クライアントの問題と判断する前に、Apple ID、ネットワーク、App Storeのサービスが正常か確認してください。

初回接続時、OSからVPN構成の追加を求められ、端末のパスコード、生体認証、またはシステム上の確認が必要になります。許可すると、「設定 → 一般 → VPNとデバイス管理」、または使用中のiOSバージョンに対応するVPN画面に設定が表示されます。この許可は、Clash Plusによるネットワーク拡張の作成をOSが認めたことを示すだけで、サブスクが読み込まれたことやポリシーが利用可能であることまでは保証しません。許可を拒否してもクライアントは開き、設定一覧が表示される場合がありますが、実際の通信は取り込めません。接続スイッチへ戻り、システムの確認を再度表示してください。

サブスクを登録して設定状態を確認する

Clash Plusの設定管理を開き、URLからサブスクをインポートします。コピーする際はURL全体を維持し、公開される場所には貼り付けないでください。インポート後、設定が一覧に表示されていることを確認し、アクティブな設定として明示的に選択します。サブスクのダウンロードに失敗した場合は、現在のネットワークからサブスクのドメインへアクセスできるかSafariで確認できますが、サブスクの内容自体は公開しないでください。ダウンロードに成功してもポリシーグループが表示されない場合は、クライアントのエラー情報を確認し、YAML解析の失敗、リモートリソースの取得失敗、空の設定を区別してください。

ルールモードを選び、主要なポリシーグループでノードを1つ指定してから接続を開始します。初回テストではSafariで一般的なWebページへアクセスし、クライアントへ戻って接続履歴を確認してください。接続履歴にドメイン、ルール、ポリシーが表示される場合、ネットワーク拡張が通信を受信しています。履歴が空なら、VPNが実際に接続されているか、他のネットワーク拡張が通信を管理していないか、オンデマンド接続ルールによって現在のネットワークが除外されていないかを確認してください。一部のアプリは既存の接続を維持します。ポリシー変更後はアプリを完全に終了して再度開き、新しい経路で接続を確立する必要があります。

オンデマンド接続、モバイル通信、ローカルネットワーク

オンデマンド接続は、ネットワークの変化時やアプリからのリクエスト時にVPNを自動起動できるため、安定性を確認済みの設定に向いています。初回導入時はスイッチを手動で操作し、設定、ポリシー、DNSが正常であることを確認してから自動動作を有効にしてください。最初から有効にすると接続の自動再試行が本当のエラーを隠し、画面に接続中と繰り返し表示されるだけで、設定解析、ノードのタイムアウト、システム拡張の起動失敗のどれが原因か判断しにくくなります。オンデマンド接続を有効にした後は、Wi-Fiとモバイル通信の両方をテストしてください。両者ではIPv6、DNS、アクセス制御が異なる場合があります。

Wi-Fiでは使えてモバイル通信では使えない場合、Clash Plusにモバイルデータの使用が許可されているか確認し、低データモードがバックグラウンド動作を制限していないか確認してください。モバイル通信では使えるのに特定のWi-Fiで使えない場合、そのネットワークで認証ページが必要、VPNが制限されている、LANのDNSと設定が競合しているといった可能性があります。公衆Wi-Fiへ接続するときは、VPNを無効にした状態でWeb認証を完了してからClash Plusを起動してください。認証ページは通常ローカルネットワーク上にあります。最初からプロキシルールに取り込まれると、ページが正常に表示されないことがあります。

家庭内の機器へ接続する際、iOSから「ローカルネットワーク」の許可を求められる場合があります。プリンター、メディア機器、LANサービスを検出または利用する必要がある場合は許可し、プライベートアドレスをDIRECTへ送るルールになっていることを確認してください。LANアクセスが不要なら、インターネット接続のトラブル対処のためだけに権限を広げる必要はありません。権限の状態はOSのプライバシー設定で個別に確認できます。変更後に関連アプリを再起動すると、既存の接続が新しい権限状態で確立されやすくなります。

システムのネットワークサービス間の関係を整理する

iOSでは、iCloudプライベートリレー、「IPアドレスのトラッキングを制限」、企業向けコンテンツフィルター、他のVPN構成が同時に有効になっている場合があります。いずれもDNSと接続経路へ影響します。異常が起きたら、変数を1つに絞れる環境を作ってください。他のネットワーク拡張を一時的に無効にし、Clash Plusだけを残して、手動ポリシーを1つ選びテストします。基本接続が回復したら、他の機能を1つずつ有効にして、どの段階で変化するか確認してください。ステータスバーのVPNアイコンだけで、どのアプリが通信を管理しているか判断してはいけません。OSのVPN画面を開き、現在の接続名を確認してください。

機内モードからの復帰、Wi-Fiとモバイル通信の切り替え、長時間の画面ロック後には、古い接続を作り直す必要がある場合があります。まずClash Plus内で切断してから再接続してください。それでも通信できなければ、VPNを無効にして基本通信を確認し、クライアントを再起動します。ログでDNSのタイムアウトが表示されてもプロキシ接続が正常なら、設定内のDNSサーバーが現在のネットワークに適しているか確認してください。対象ポリシーのタイムアウトが表示されるなら、手動ノードへ切り替えて比較します。Safariは正常なのに特定のアプリだけ失敗する場合は、アプリが保持する接続、OSの地域サービス、アプリ別ルール、アプリ独自の通信方式を先に確認し、設定全体をすぐに削除しないでください。

LINUX / GUI OR CORE

Linux：GUIクライアントとMihomoのサービス運用

デスクトップLinuxではClash Verge RevまたはFlClashを利用できます。サーバーやルーター環境ではMihomoコアの直接実行が適しています。

デスクトップ環境に合うパッケージ形式を選ぶ

LinuxのGUIクライアントは、ダウンロードページの掲載順にClash Verge RevまたはFlClashを選択してください。インストール前にuname -mを実行してアーキテクチャを確認します。一般的な出力のx86_64はAMD64、aarch64はARM64に対応します。Debian、Ubuntuおよび派生ディストリビューションでは通常debパッケージを使い、FedoraやRHEL系ではrpmを使う場合があります。他のディストリビューションでは、ダウンロードページで提供される形式と各プロジェクトの説明に従って選んでください。サーバー向けのMihomo圧縮ファイルをGUI付きデスクトップクライアントと取り違えないでください。起動方法、設定ディレクトリ、システムプロキシの管理方法が異なります。

debパッケージはOSのソフトウェアセンターからインストールできるほか、ターミナルでローカルインストールすることもできます。ファイル名は実際にダウンロードしたものへ置き換えてください。

sudo apt install ./clash-client-amd64.deb
uname -m
systemctl --user status

パッケージマネージャーは依存関係も同時に解決できるため、下位の展開コマンドを直接使うより、一般的なインストールに適しています。初回起動時、デスクトップ環境からキーリング、バックグラウンド動作、ネットワーク権限に関する確認が表示される場合があります。まず設定のインポートとローカルプロキシのテストを済ませ、その後TUNを有効にしてください。GNOME、KDE、その他のデスクトップ環境ではシステムプロキシの対応状況が異なります。ターミナルアプリも通常、デスクトップのプロキシを自動では参照しないため、環境変数またはアプリ個別の設定で動作確認を行います。

デスクトッププロキシとターミナル環境

GUIクライアントでシステムプロキシを有効にしたら、デスクトップのネットワーク設定でHTTP、HTTPS、SOCKSのアドレスがローカルポートを指しているか確認してください。ブラウザでアクセスした後、接続ログを確認します。ターミナルでは変数を一時的に設定できます。

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

変数名の大文字・小文字への対応はツールによって異なります。小文字だけを参照するプログラムも、大文字だけを参照するプログラムもあります。アプリの挙動が不明な状態で、異なるポートを複数組設定しないでください。想定とは異なるプロトコルを経由する可能性があります。パッケージマネージャー、コンテナサービス、systemdサービスも、対話型shellの環境変数を必ず継承するとは限りません。該当するサービスやツールの設定に個別に記述し、不要になったら削除してください。

Mihomoコアを直接実行する

サーバー、サブ構成のルーター、デスクトップ環境のないホストではMihomoを実行できます。専用ユーザーと設定ディレクトリを用意し、実行ファイルを管理されたパスへ配置して、設定をYAMLで保存します。初回はフォアグラウンドで起動し、テスト用設定の解析結果を確認してください。最初からバックグラウンドへ隠さないでください。以下は一般的なコマンド形式です。パスはシステムのディレクトリ構成に合わせて調整できます。

mkdir -p "$HOME/.config/mihomo"
cp config.yaml "$HOME/.config/mihomo/config.yaml"
chmod 600 "$HOME/.config/mihomo/config.yaml"
mihomo -d "$HOME/.config/mihomo"

フォアグラウンドのログでは、設定解析、待受ポート、ルールプロバイダー、DNS初期化を確認できます。エラーがないことを確認してからsystemdサービスを作成してください。サービスには作業ディレクトリ、設定ディレクトリ、実行ユーザーを明示し、不要な高権限で常時動かさないようにします。TUNを使う場合、サービスアカウントにはネットワークインターフェースの作成とルート変更に必要な権限が必要です。すべてを単純にrootへ任せるのではなく、ディストリビューションのセキュリティモデルに沿って権限を設定してください。

[Unit]
Description=Mihomo Network Service
After=network-online.target
Wants=network-online.target

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

[Install]
WantedBy=multi-user.target

ファイアウォール、待受アドレス、DNS

このホストだけで使う場合は、mixed-port、コントロールポート、APIをループバックアドレスで待ち受けるようにします。LANへプロキシを提供する必要がある場合に限りAllow LANを有効にし、ファイアウォールで接続元の範囲を指定してください。アクセス制御なしでコントロール用インターフェースを全アドレスへ公開すると、管理機能が外部へ露出する範囲が広がります。サーバーでは、プロキシの受信ポート、DNS待受ポート、外部向けサービスのポートも区別してください。ss -lntupで実際の待受状態を確認し、ポートが競合していないことを確認します。

LinuxのDNSは、systemd-resolved、NetworkManager、デスクトップサービス、コンテナネットワークによって同時に管理される場合があります。TUNを有効にした後、IPアドレスへは接続できるのにドメイン名だけ失敗する場合は、resolvectl statusとクライアントログを確認し、クエリがどのDNSへ入っているか特定してください。/etc/resolv.confを何度も直接上書きしても、ネットワークマネージャーによって再生成されるため、一時的にしか反映されないことがよくあります。適切な方法は、DNSをどの層が担当するか明確にすることです。Mihomoでハイジャックして処理するのか、システムリゾルバーで処理した後にルールへ渡すのかを決め、2つのサービスが同じアドレスを同時に待ち受けないようにしてください。

コアの更新や設定の差し替えを行う前に、設定をテストし、現在起動できるファイルを残しておいてください。サービスを起動できない場合はjournalctl -u mihomoでログを確認し、YAML解析、権限、ディレクトリ、ポート、ネットワーク権限を重点的に調べます。ルーターへの導入では、転送、ポリシールーティング、LANのDNSも関係します。まずMihomoルーター導入の概要を読み、メインルーター、サブルーター、コアの直接実行のどこから通信を取り込むか確認してから、運用中のネットワークを変更してください。

CONFIG / RULE FLOW

共通設定：ポート、モード、DNS、ルールの確認

OSごとに画面は異なりますが、コアの処理手順は共通です。通信が待受入口へ入り、ドメイン名の解決とルール照合を経て、ポリシーグループ内の具体的な出口へ送られます。

最小設定の構造を理解する

動作する設定には、少なくともプロキシの入口、動作モード、プロキシノードまたはプロバイダー、ポリシーグループ、ルールが必要です。GUIクライアントは一部の設定をアプリ独自のデータベースへ保存する場合があります。そのため、画面上で指定したポート、TUN、DNSの上書きがすべてサブスクのYAMLへ記載されるとは限りません。問題を調べる際は、「現在有効な設定」がどこから生成されたかを先に確認してください。サブスクの原文、クライアントによる上書き、マージスクリプトで生成された最終設定のいずれかです。ローカルへダウンロードした元ファイルだけを見ても、実際の動作を説明できないことがあります。

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

proxies:
  - name: example-proxy
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-proxy
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

例に記載されたアドレスは説明用で、実際のサービスにはそのまま利用できません。mixed-portはHTTPとSOCKSの両方を受け付けるため、デスクトップアプリの設定に便利です。mode: ruleではルールによって出口を決定します。allow-lan: falseは、この端末だけで使用する設定です。ルールは上から順に照合され、最初に一致した時点で停止します。具体的なドメインやLAN向けのルールは、最後のMATCHより前に置いてください。変更後もクライアントが古い結果を使う場合は、設定を再読み込みし、新しい接続でテストしてください。既存の長時間接続は、必ずしもすぐ新しい経路へ移行しません。

ポリシーグループはノード一覧の別名ではない

selectグループはユーザーが手動で選択します。url-testはヘルスチェック結果から選択し、fallbackは先頭から順に最初の利用可能な項目を使い、load-balanceは接続ごとに複数の出口へ振り分けます。自動グループに表示される遅延は、指定されたテストリクエストをある時点で測定した結果にすぎず、Web閲覧、ダウンロード、動画再生の総合的な体感とは一致しません。テスト先へ到達できない、ノードがテストリクエストを制限する、端末のバックグラウンド動作が制限されると、ヘルスチェック結果は不正確になります。Clashの遅延テストの仕組みも参考に数値を判断し、重要な用途では実際のアクセス結果で確認してください。

ポリシーグループ同士が参照し合うこともあります。たとえば「アプリ用ポリシー」が「自動選択」を参照し、「自動選択」が複数のノードを含む構成です。ログに最終的なグループ名しか表示されない場合は、そのグループで現在選ばれている項目も確認してください。上位グループを切り替えても変化しない場合、下位グループが同じノードを維持している可能性があります。自動グループが頻繁に切り替わる場合は、チェック間隔が短すぎる、許容差が小さすぎる、ネットワークが不安定といった原因が考えられます。設定で目指すべきなのは、説明できる安定した経路です。すべての通信を必要以上に多段の自動選択へ通すことではありません。

DNSモードと名前解決の経路

DNSは、ドメイン名が最初にどのアドレスへ解決されるかを決め、ドメインベースのルールが正しく一致するかにも影響します。システムプロキシモードでは、一部のアプリはドメイン名をプロキシへ渡し、別のアプリは先にローカルで名前解決します。TUNモードではDNSハイジャックを有効にし、クエリを一括してコアへ送る場合もあります。一般的なfake-ipモードは、ドメインに予約アドレスを割り当ててコア内部に対応関係を保持するため、ドメインの復元とルール照合に便利です。redir-hostは、先に実アドレスを取得してから処理する方式に近いものです。LANサービス、ゲームプラットフォーム、機器検出、一部のセキュリティソフトはfake-ipの影響を受けることがあります。その場合はDNS機能全体を無効にするのではなく、フィルターリストで特定ドメインだけ実IPを使って名前解決してください。

DNS障害は症状から判断してください。ドメイン名では失敗し、IPアドレスへ直接接続すると正常なら、名前解決を重点的に調べます。ログにDNSリクエストがなければ、別のアプリやOSサービスがクエリを処理している可能性があります。正常なアドレスが返っていて接続がタイムアウトするなら、問題はすでにルーティングまたは出口の層へ移っています。暗号化DNSを有効にする場合は、そのDNSサーバーのドメイン名をどう解決するかも考慮し、「プロキシに必要なDNSの解決にプロキシが必要」という循環を避けてください。現在のネットワークと互換性のある基本的な名前解決経路を少なくとも1つ残し、実際のクエリ経路をログで確認することをおすすめします。

ログを使って再現可能な確認を行う

ルールを確認するときは対象ドメインを1つ選び、ログを消去するか現在位置を覚えてから、新しいアクセスを1回行います。送信元アプリ、対象ドメインまたはアドレス、一致したルール、ポリシーグループ、最終ノードを記録してください。ログがなければ通信はClashへ入っていません。システムプロキシ、VPN/TUN、アプリ独自の設定を確認します。想定ではプロキシなのにDIRECTへ一致した場合は、ルール順序、ドメインの形式、ルールプロバイダーの読み込み状態を確認してください。正しいポリシーに一致しても接続できない場合は、ノード、DNS、IPv6、対象サービスを確認します。

症状	最初に確認する項目	次の手順
対象リクエストがログにない	システムプロキシ、VPN、TUN、アプリ別設定	通信の入口を確認する
想定と異なるルールに一致する	ルール順序、ドメイン、providerの状態	より具体的なルールで再テスト
正しく一致するがタイムアウトする	ポリシーグループの現在項目、ノード、DNS	手動ノードへ切り替えて比較
一部のアプリだけ失敗する	アプリのプロキシ対応、QUIC、IPv6	システムブラウザと比較する

通常利用ではログレベルをinfoにしておけば十分です。短時間の問題を調べる際は詳細度を上げられますが、完了後は元に戻し、大量のログが長期間生成されないようにしてください。ログを共有する前に、サブスクURL、認証情報、ノードのアドレス、個人的なドメインを削除してください。設定変更には「DNSが失敗の原因か確認する」など明確な目的を持たせ、ノード、ルール、ネットワークモードを同時に変更しないでください。一度に1つの変数を変え、1つのテストリクエストを行うことが、このマニュアルで最も重要な検証方法です。

DIAGNOSE / RECOVERY

設定でよくある問題と層別のトラブル対処

問題を、基本ネットワーク、クライアントプロセス、設定読み込み、通信の入口、ルールとポリシー、対象への接続という6層に分けると、効果のない再インストールを減らせます。

クライアント起動後に通信できなくなった

最初にシステムプロキシとTUN、またはモバイル端末のVPNを無効にし、端末本来のネットワークが復旧するか確認してください。無効にしてもアクセスできない場合は、システムプロキシの設定が残っている、DNSが復元されていない、ネットワーク自体が切れている、別のVPNが動いている可能性があります。デスクトップでは、OSのプロキシ設定が127.0.0.1の古いポートを指していないか確認します。モバイルではステータスバーとOSのVPN画面、Linuxでは環境変数、ルート、リゾルバーを確認してください。基本ネットワークが復旧してからClashを再起動し、確認を続けます。

次に、システム通信を取り込まずクライアントだけを起動し、設定を正常に読み込めるか、プロキシポートが待ち受けているか確認します。3段階目でシステムプロキシまたはVPNを有効にし、システムブラウザから対象へアクセスしてログを確認してください。ログが空なら入口の問題です。記録はあるもののDNSエラーが出る場合は名前解決を確認します。ポリシーに一致した後でタイムアウトする場合は手動ノードへ切り替えます。この3段階により、「通信できない」という曖昧な結果を明確な層へ分けられます。質問と回答の形式で整理した対処方法は、よくある質問でも確認できます。

サブスクを更新できない、またはインポート後にノードがない

まずサブスクURLが完全にコピーされていることと、現在の基本ネットワークからサブスクサービスへアクセスできることを確認してください。クライアントが旧設定を使用中の場合、更新リクエストが古いルールによって利用不能なノードへ送られることがあります。一時的にプロキシを切ってから再試行してください。HTTPエラーは、リモートリクエストから想定した内容を取得できなかったことを示します。YAML解析エラーは内容をダウンロードできたものの、形式またはフィールドが設定要件を満たしていないことを示します。providerエラーは、リモートのノードグループやルールセットだけに影響する場合があります。3種類のエラーは対処方法が異なるため、すべてを「クライアントの故障」と判断しないでください。

インポート後にノードがない場合は、設定がアクティブ項目として選ばれているか、プロキシグループが空でないか確認してください。一部のサブスクは基本的な断片だけを返し、クライアント側に特定の処理機能が必要です。URLをブラウザで開くと、YAMLではなくログインページや案内文が返る場合もあります。Webページのエラー内容を設定ファイルとして保存し、何度もインポートしないでください。旧設定がまだ使える場合は復旧経路として残し、設定の提供元へサブスクの状態を確認します。すべての設定を何度も削除すると、正常な基準状態まで失われ、原因の特定が難しくなります。

システムプロキシは使えるがTUNを起動できない

システムプロキシが使えるなら、設定、ノード、基本ルールはおおむね正常です。問題の範囲を権限、サービス、仮想インターフェース、ルート、DNSに絞れます。Windowsではクライアントサービスがインストールされているか、仮想NICが作成されているか、セキュリティソフトがブロックしていないか確認します。macOSではネットワーク拡張とVPN構成の許可、Linuxでは実行ユーザーのネットワーク権限、カーネルモジュール、ファイアウォール、ポリシールーティングを確認してください。モバイル端末ではOSのVPN自体が主要な通信入口に相当するため、他のVPNに奪われていないか確認します。

TUNを有効にした直後に通信できなくなる場合は、まず無効にしてシステムプロキシの基準状態へ戻し、起動段階で最初に出たエラーを確認してください。よくある原因には、デフォルトルートが作成されていない、DNS待受ポートが競合している、厳格なルーティングがLANと互換性を持たない、IPv6経路に異常がある、別の仮想インターフェースの優先度が高いといったものがあります。TUNを必ず有効にすべき高速化スイッチと考えないでください。必要なアプリがすべてシステムプロキシに従うなら、システムプロキシモードだけでルールに基づくルーティングを行えます。プロキシ設定を参照しないアプリ、UDP、より広い通信を取り込む必要がある場合にのみ、TUNの権限と互換性を調整してください。

ノードの遅延は正常なのにWebページが遅い

遅延テストは通常、短いリクエストを使い、DNS、接続確立、テスト先までの経路の一部しか測りません。実際のWebページは、経路の混雑、パケットロス、TLS接続、対象サイトの所在地、並列リソース、転送速度にも影響されます。ノードを選ぶ際は1つの数値だけを比較せず、複数回のテストで安定性を確認し、実際の用途でも比較してください。自動ポリシーグループが頻繁に切り替わると長時間接続が切れる場合もあります。瞬間的な最小値を追うより、適切な許容差とチェック間隔を設定することが重要です。

特定のサイトだけ遅い場合は、そのサイトが一致したルールとポリシーを確認し、不適切なグループへ割り当てられていないか調べます。すべてのサイトが遅い場合は、DIRECTと手動ノードをそれぞれテストし、ローカル回線とプロキシ出口を切り分けてください。ブラウザは正常でも動画やダウンロードが遅い場合は、アプリによるUDP、QUIC、複数接続での転送も考慮します。ログに大量の再試行、DNSのタイムアウト、ポリシー切り替えがある場合は、クライアントの変更を検討する前に、これらの明確な兆候へ対処してください。

設定変更が反映されない

まず、編集対象が現在のアクティブ設定であり、サブスクのキャッシュ、コピー、未選択のファイルではないことを確認してください。サブスクを更新するとローカルでの直接編集が上書きされる場合があります。長期的なカスタマイズには、クライアントが対応する上書き、マージ、スクリプト機能を使ってください。YAMLを保存したら再読み込みし、構文エラーがログへ表示されていないか確認します。YAMLはインデントに依存し、リスト項目、コロン後の空白、文字列の型が解析に影響します。ルール内の名前はポリシーグループ名と完全に一致する必要があり、大文字・小文字や文字の違いがあると読み込みに失敗します。

次に新しい接続を作ります。ブラウザで開いたままのページ、メッセージアプリの長時間接続、ダウンロードタスクは、古い経路を使い続ける場合があります。モードを切り替えても、既存の接続すべてが自動的に再作成されるわけではありません。関連アプリを終了するか接続の終了を待ってから再テストしてください。DNSキャッシュにも古い結果が残る場合があります。まず未アクセスのドメインで確認し、その後OSのキャッシュを消去する必要があるか判断します。変更が反映された証拠は、スイッチの位置ではなく、ログに記録された新しいルールとポリシーから判断してください。

動作する最小構成へ戻す

変更が多すぎて判断できなくなった場合は、決まった順序で復旧してください。TUNとシステムプロキシを無効にし、他のネットワークツールを終了して基本通信を確認します。Clashを起動して、以前正常に使えた単純な設定を読み込みます。ポリシーを1つ手動で選び、システムプロキシまたはモバイル端末のVPNを有効にします。システムブラウザから新しいリクエストを送り、ログを確認してください。基準状態で成功した後、DNSのカスタマイズ、ルールプロバイダー、自動ポリシーグループ、アプリ別ルーティング、TUNの順に1つずつ追加します。各項目を追加するたびに確認結果を残してください。

それでも再インストールが必要な場合は、クライアント名、OSのアーキテクチャ、設定の入手元、エラー文、実施済みの手順を先に記録してください。アンインストール前にシステムプロキシ、TUN、バックグラウンドサービスを無効にし、削除済みのローカルポートをOSが参照し続けないようにします。再インストール後は古い設定をすべてすぐ取り込まず、最小設定で先に確認してください。初回導入時の詳しいチェックリストは、Clash初回インストール時の設定方法も参考になります。この復旧方法は複雑な機能を避けるためではありません。観察できる数まで変数を減らし、信頼できる環境を1項目ずつ再構築することが目的です。