システム別リファレンス

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

Windows、macOS、Android、iOS、Linuxでのダウンロード、インストール、サブスクリプションの読み込み、システムプロキシ、TUNモード、プラットフォームごとのトラブル対応を網羅しています。章ごとに詳しく確認したい場合に利用してください。まず接続だけを早く完了したい場合は、クイックスタートガイドで基本操作を済ませてから、このページでプラットフォームごとの違いや設定上の注意点を確認できます。

クライアントをダウンロード クイックガイドを見る

1. インストール前に行う共通の準備

クライアント、コア、設定ファイルの違いを理解する

Clashを実際に使うには、3つの要素が関わります。GUIクライアントは設定の表示、ポリシーの切り替え、システムプロキシの制御、更新管理を担当します。コアはルールの解析、接続の確立、DNSやTUNトラフィックの処理を行います。設定ファイルには、プロキシの接続先、プロキシグループ、ルール、ポート、DNSパラメータが保存されます。デスクトップ版・モバイル版の多くは対応コアを内蔵しているため、一般ユーザーがMihomoを別途ダウンロードする必要はありません。サーバー、ルーター、コンテナ環境で運用したり、サービスプロセスを自分で管理したりする場合に限り、コアを直接導入します。

サブスクリプションURLも、クライアントが自動生成するものではありません。通常はネットワークサービスの提供元から発行され、クライアントはURLを読み込んでローカル設定へ変換します。公開コードリポジトリ、クライアント公式サイト、このサイトのダウンロードページでは、そのまま使えるプロキシサブスクリプションを提供していません。サブスクリプションURLを受け取ったら機密情報として扱い、スクリーンショット、公開チケット、共有されたコマンド履歴、一般公開のコードリポジトリに載せないでください。YAMLファイルだけを受け取った場合は、ローカル設定として読み込めるため、先にサブスクリプションURLへ変換する必要はありません。

デバイスに合ったクライアントを選ぶ

初回インストールでは、まずGUIクライアントを選ぶのがおすすめです。Windows、macOS、Android、iOSでは、最初にClash Plusを確認できます。WindowsとmacOSでは、画面の好みに応じてClash Verge Rev、FlClash、Clash Nyanpasuも選択できます。AndroidではClash Meta for Android、FlClash、Surfboard、LinuxデスクトップではClash Verge Rev、FlClashが利用できます。Clash for WindowsとClashX Metaはメンテナンスが終了しているため、過去の環境を扱う場合に限って使用し、新規導入の出発点にはしないでください。利用可能な入手先はすべてクライアントダウンロードにまとめています。古いガイドのファイル名だけで、現在のパッケージが適切か判断しないでください。

ダウンロード前に、プロセッサのアーキテクチャを確認します。Windowsの一般的なデバイスはx64ですが、Windows on ARMでは対応ビルドの有無を確認してください。Apple Silicon搭載Macはarm64、旧型のIntel Macはx64です。Androidのインストールパッケージにはarm64、arm、汎用ビルドがあり、近年の主流スマートフォンは通常arm64ですが、メーカー名だけで判断してはいけません。LinuxではCPUアーキテクチャに加えてパッケージ形式も確認します。DebianやUbuntuではdeb、Fedora系ではrpmが一般的です。圧縮ファイルを使う場合は、実行権限やサービス管理を自分で設定する必要があります。

プラットフォーム 優先する選択肢 インストール前の確認事項 トラフィックの取り込み方法
Windows Clash Plus x64アーキテクチャ、管理者権限の要否 システムプロキシまたはTUN
macOS Clash Plus Apple SiliconまたはIntel システムプロキシまたはTUN
Android Clash Plus CPUアーキテクチャ、システムVPN権限 ローカルVPNサービス
iOS Clash Plus App Storeアカウントとシステム権限 Network Extension
Linux Clash Verge Rev ディストリビューション、デスクトップ環境、アーキテクチャ デスクトッププロキシ、TUN、サービスプロセス

インストールに必要な情報を整理する

開始前に、サブスクリプションURLまたはYAMLファイル、デバイスの管理者権限、正常に接続できる基本ネットワーク、結果確認用のブラウザーを準備します。会社や学校のデバイスでは、管理ポリシーによってプロキシ、VPN、ネットワーク拡張、証明書設定が固定されていることがあります。その場合、クライアントのインストールに成功しても、システムのネットワーク状態を変更できない場合があります。同種のクライアントを複数同時に起動しないでください。2つのプログラムが同じポートを待ち受けたり、システムプロキシを書き換えたり、TUNインターフェースを作成したりすると、起動失敗、ネットワークループ、終了後に接続を復元できない問題が起きやすくなります。

初期設定では、HTTPとSOCKSの共通入口としてmixed-portがよく使われます。ポート番号は設定によって異なり、7890が例としてよく使われますが、最終的にはクライアント画面に表示された値を確認してください。ブラウザーやターミナルにプロキシを手動入力する場合、ホストは通常ローカルループバックアドレス 127.0.0.1、ポートは実行中の設定と一致させます。サブスクリプションサービスのリモートポートをシステムプロキシに入力したり、他のデバイスからの接続が必要でないのにLANアドレスを待ち受けアドレスにしたりしないでください。

ルール、グローバル、ダイレクトモードを理解する

ルールモードは、設定内の rules を上から順に照合し、ドメイン、IP、プロセス、ルールセットに応じて指定されたプロキシグループへ接続を渡します。日常利用では標準的な選択肢です。グローバルモードは分流ルールを無視し、プロキシ可能なトラフィックを一律にグローバルポリシーへ渡します。ルールの誤判定を短時間確認する用途には向きますが、常用には適しません。ダイレクトモードはプロキシを迂回し、基本ネットワークの復旧や、障害がクライアントに起因するかの確認に使います。モードを切り替えても、無効なサブスクリプションが修復されたり、プロキシグループ内の利用不能な選択肢が自動交換されたりすることはありません。

読み込み後は、まずプロキシグループを確認します。よくあるグループ名にはProxy、Auto、Streaming、Final、REJECTがあります。手動選択グループでは、利用可能なポリシーを明示的に選択します。自動テストグループは、設定されたテスト方法に基づいて選択を更新します。Finalは通常、前のルールに一致しなかった接続を受け持ち、REJECTは一致したトラフィックを拒否します。サブスクリプションによって名称は異なるため、固定の日本語ボタンを探すのではなく、グループの種類と用途を基準に操作してください。

2. Windowsでのダウンロード、インストール、システムプロキシ設定

GUIクライアントをダウンロードしてインストールする

Windowsに新規インストールする場合は、WindowsクライアントからClash Plusを選択できます。Clash Verge Rev、FlClash、Clash Nyanpasuも利用できます。Clash for Windowsはメンテナンスが終了しているため、古い設定との互換性が必要な場合や過去のデータを移行する場合に限って使用してください。ダウンロード後にインストーラーを実行します。ユーザーアカウント制御が表示されたら、ファイルの入手元と実行内容を確認してから許可するか判断します。インストール先は通常のローカルディスク上のパスを選び、テンポラリフォルダー、同期ドライブ、企業ポリシーの制限対象フォルダーは避けてください。

一部のクライアントでは、現在のユーザー向けインストールと全ユーザー向けインストールを選べます。前者は継続的な管理者権限を必要としないことが多く、後者は複数アカウントでプログラムファイルを共有しやすい一方、設定データはユーザーディレクトリごとに保存される場合があります。TUNの有効化、サービスのインストール、自動起動の設定では、初回操作時に管理者権限を求められることがあります。従来のシステムプロキシを有効にするだけなら、通常は常に管理者として実行する必要はありません。常時管理者権限で実行すると、ドラッグ＆ドロップ、ブラウザー連携、一般ユーザーのフォルダーアクセスに余計な制限が生じるため、万能な解決策と考えないでください。

サブスクリプションを読み込み、設定を有効にする

Profilesまたは設定ファイルのページを開き、「URLから読み込む」を選択します。完全なサブスクリプションURLを入力欄に貼り付け、ダウンロードを実行してください。読み込みに成功しても、設定が有効になったとは限りません。設定一覧で読み込んだ項目を選択し、現在の設定にする必要があります。ローカルYAMLを使う場合は、ローカルファイルの読み込みを選ぶか、クライアントが許可する設定ディレクトリにファイルを置きます。クライアント内部のキャッシュファイルを直接編集すると、サブスクリプション更新時に上書きされる可能性があります。長期的に保持するカスタムルールは、クライアントが提供するオーバーライド、マージ、スクリプト機能を使用してください。

設定を有効にしたら、プロキシモード、プロキシグループ、ポートの順に確認します。日常利用にはルールモードが適しています。Proxyなどの手動プロキシグループを開き、サブスクリプションに実際に存在するポリシーを選択します。Autoやurl-testグループが含まれている場合は、最初に一度更新を実行してもよいでしょう。画面に緑色の状態が表示されるかだけで判断せず、後で実際の接続を確認してください。設定をダウンロードした後に一覧が空になる場合、サブスクリプションの返却形式、認証状態、ネットワークアクセスに問題があることが多く、システムプロキシのスイッチが原因とは限りません。

システムプロキシとTUNの適用範囲

Windowsのシステムプロキシは、ローカルプロキシのアドレスをシステム設定へ書き込みます。WinINETまたはシステムプロキシ設定に従うブラウザーやデスクトップアプリは自動的に利用しますが、一部のゲーム、コマンドラインツール、ストアアプリ、独自のネットワークスタックを使うソフトは設定を無視することがあります。有効化後は、Windowsのプロキシ設定でローカルアドレスとポートを確認できます。通常、クライアントを終了すると設定は復元されますが、強制終了や異常シャットダウンでは、停止したポートを指すプロキシ項目が残り、すべてのWebページが開けなくなることがあります。

TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のIPトラフィックを取り込みます。システムプロキシを読み取らないアプリに適しています。初回有効化では、ドライバーやシステムサービスのインストール、管理者権限の許可が必要になる場合があります。有効化後は、ルーティングテーブル、DNS、ファイアウォールが正常か確認し、TUNやグローバルVPNインターフェースを作成する別ソフトを同時に実行しないでください。システムプロキシとTUNを同時に使えるかはクライアントの実装によります。初回の切り分けでは、取り込み方式を1つだけにし、安定してから併用を検討してください。

コマンドライン、ターミナル、開発ツール

PowerShell、コマンドプロンプト、Git、パッケージマネージャー、開発言語のランタイムは、常にWindowsのシステムプロキシを読み取るとは限りません。必要に応じて、現在のターミナルセッションに環境変数を設定し、ポートはクライアントの現在のmixed-portへ置き換えます。一時変数はそのターミナルと子プロセスだけに影響し、ウィンドウを閉じると無効になるため、テストに適しています。ユーザー環境変数へ永続的に書き込む前に、オフライン開発、LANサービス、コンテナツールまで誤った経路を通らないか確認してください。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

クライアントを停止する場合は、永続化されたGitのプロキシ設定も削除してください。削除しないと、Gitは停止済みのローカルポートへ接続し続けます。git config --global --unset http.proxyと、対応するHTTPSコマンドで削除できます。ターミナルは接続できるのにブラウザーが接続できない場合は、システムプロキシ、ブラウザー拡張、セキュリティソフトを優先して確認します。ブラウザーは接続できるのにターミナルが接続できない場合は、環境変数、Git設定、ツール独自のプロキシ項目を重点的に確認してください。

Windows特有のトラブルの境界

ポートの競合は、Windowsで起動に失敗する一般的な原因です。クライアントログにアドレスが使用中と表示されたら、別のClashインスタンスや残ったプロセスがないか確認し、プロセスを終了するかmixed-portを変更するか判断します。詳しい特定方法はポート競合の確認手順を参照してください。ポートを変更したら、システムプロキシ、ブラウザーの手動プロキシ、ターミナルの環境変数、LAN内のデバイスもすべて同じ値に変更します。

終了後にネットワークが切れた場合は、まずWindowsの手動プロキシを無効にし、仮想ネットワークアダプター、プロキシ環境変数、他のVPNが残っていないか確認します。すぐにすべてのネットワークコンポーネントをリセットしないでください。仮想スイッチ、静的DNS、開発環境の設定まで同時に消える可能性があります。まずクライアントプロセスが終了したことを確認し、システムプロキシ、DNS、デフォルトルート、TUNサービスの順に復元します。スリープ復帰後だけ失敗する場合は、クライアントのコアを再起動してからTUNを再作成します。ルーティング競合やセキュリティポリシーが原因なら、頻繁な再インストールでは解決できません。

3. macOSのインストール、ネットワーク拡張、プロキシ切り替え

プロセッサのアーキテクチャに合うパッケージを選ぶ

macOSでは、ダウンロード前に「このMacについて」を開いてチップの種類を確認します。Apple Siliconはarm64、Intelプロセッサはx64ビルドに対応します。新規インストールではmacOSクライアントからClash Plusを選べます。Clash Verge RevやFlClashも利用できます。ClashX Metaはメンテナンスが終了しているため、主に過去の環境の移行用です。アーキテクチャを間違えると、起動できない、変換レイヤー経由で動作する、補助サービスのインストールに失敗するといった問題が起こります。ファイル名にmacOSと書かれているかだけで互換性を判断しないでください。

一般的なインストールでは、ディスクイメージを開き、アプリを「アプリケーション」フォルダーへドラッグして、そこから初回起動します。ダウンロードフォルダーやマウント中のディスクイメージから長期間直接実行しないでください。自動更新、ログイン時の起動、補助サービスのパスが不安定になることがあります。システムに起動を阻止された場合は、まず入手元を確認し、「プライバシーとセキュリティ」で該当する警告を確認します。個別アプリの許可問題を解決するために、システム全体のセキュリティ設定を下げないでください。

設定の読み込みとメニューバー操作

Profilesまたは設定ページを開き、URLからサブスクリプションを読み込むか、ローカルYAMLを読み込みます。ダウンロード後は設定を明示的に選択し、プロキシページでProxy、Auto、または設定に定義されたグループを選びます。macOSクライアントはメニューバーに常駐することが多く、メインウィンドウを閉じてもコアが停止したとは限りません。ポート競合やプロキシの残留を確認するときは、メニューバーから終了するか、アクティビティモニタで関連プロセスが動作中か確認してください。

サブスクリプション更新では、リモートの内容を再取得します。クライアントが自動更新間隔に対応している場合は、サービス提供元の更新方式に合わせ、頻繁すぎるポーリングは避けてください。リモート設定とローカル変更が同時に存在すると、次回更新で直接編集した内容が上書きされることがあります。分流ルール、DNS、スクリプトを追加する場合は、オーバーライド設定を優先してください。プロキシ情報を含む設定ファイルをエクスポートする前に、保存先とアクセス権限を確認します。

システムプロキシの仕組み

システムプロキシを有効にすると、クライアントは現在のネットワークサービスのWebプロキシとセキュアWebプロキシ設定を変更します。Safariやシステム設定に従うアプリは通常そのまま反映されますが、一部のコマンドラインツール、サンドボックスアプリ、接続を独自管理するソフトはこれらの設定を読み取りません。Wi-Fi、Ethernet、テザリングへ切り替えたり、新しいネットワークサービスを追加したりした後は、プロキシの状態を再確認してください。macOSのプロキシ設定は、個々のネットワークサービスに紐づいています。

scutil --proxyで、システムが現在読み取っているプロキシ情報を確認できます。このコマンドで分かるのは設定が書き込まれているかどうかであり、ローカルポートが接続を受け付けることや、プロキシグループに利用可能な選択肢があることを示すものではありません。クライアント終了後もプロキシアドレスが残っている場合は、クライアントから再度有効にして正常に終了し、復元処理を実行させます。システムのネットワーク設定から該当するプロキシ項目を手動で無効にする方法もあります。ブラウザー拡張、自動プロキシ設定ファイル、クライアントのシステムプロキシを同時に動かして互いに上書きさせないでください。

scutil --proxy
networksetup -listallnetworkservices
lsof -nP -iTCP:7890 -sTCP:LISTEN

TUN、システム拡張、権限

macOSのTUNモードでは通常、補助サービスのインストール、仮想インターフェースの作成、ネットワーク拡張の権限が必要です。初回有効化では、管理者の認証情報を入力し、「プライバシーとセキュリティ」で確認を求められることがあります。許可した後も、クライアントに戻ってコアが実際に起動しているか確認してください。ボタンが一時的に有効になってすぐ無効になる場合は、権限、ルート、DNS、インターフェース作成に関するログを確認し、何度もクリックし続けないでください。

TUNはシステムプロキシに従わないアプリも取り込めますが、他のVPN、企業向けセキュリティクライアント、仮想マシン、コンテナネットワークとのルーティング競合も起こりやすくなります。切り分けでは、デフォルトルートやDNSプロキシを作成する他のプログラムを終了し、トラフィックを取り込むツールを1つだけ残します。LANプリンター、NAS、開発サーバーへアクセスできない場合は、全トラフィックをダイレクトに変更するのではなく、設定内のプライベートアドレス向けダイレクトルールと除外ルートを確認してください。

ターミナルプロキシと証明書の境界

Terminal、Homebrew、Git、curl、言語パッケージマネージャーでは、個別にプロキシを設定する必要がある場合があります。現在のシェルでHTTP、HTTPS、ALL_PROXYをエクスポートできます。zshを使い、設定ファイルへ変数を書き込む場合は、同時に解除方法も用意してください。プロキシ変数を長期間残すと、クライアント未起動時にターミナルが接続拒否になるほか、ローカル開発サーバーへのアクセスにも影響することがあります。

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

通常のClashプロキシで基本接続を行うために、カスタムルート証明書をインストールする必要はありません。HTTPS復号、スクリプトデバッグ、特定のツールチェーンを明示的に使う場合に限り、証明書の信頼設定が関係します。TLSエラーが発生したら、まずシステム時刻、名前解決、プロキシポリシー、アプリ独自の証明書ストアを確認し、証明書検証の無効化を恒久的な対策にしないでください。会社管理のデバイスでは、証明書やネットワーク拡張が管理設定により制御されている場合があるため、管理者に対応を依頼します。

4. Androidのインストール、VPN権限、バックグラウンド動作

インストールパッケージを選び、インストールを完了する

AndroidではAndroidクライアントからClash Plusを選べます。Clash Meta for Android、FlClash、Surfboardも利用できます。インストールパッケージにはarm64、arm、汎用アーキテクチャ向けのものがあります。近年の主流デバイスは通常arm64ですが、旧型デバイス、TVボックス、エミュレーターでは異なる場合があります。判断できない場合は、クライアントが提供する汎用ビルドを使ってください。パッケージを解析できないと表示されたら、アーキテクチャ、Androidのバージョン、ファイルのダウンロード完了状況、提供元アプリのインストール許可を確認します。

ブラウザーやファイルマネージャーからインストールすると、Androidは現在の提供元にインストール権限を与えるよう求めます。インストール後は、その提供元の権限を取り消してもクライアントの動作には影響しません。同じパッケージ名で署名が異なるバージョンがすでに入っている場合、上書きインストールを拒否されることがあります。その場合は、保存したい設定を先にエクスポートし、旧アプリをアンインストールしてから再インストールします。特にローカルオーバーライド、スクリプト、手動で読み込んだYAMLは、アンインストール前のアプリデータが必ず復元されるとは限りません。

サブスクリプションを読み込み、ローカルVPNを作成する

クライアントを開き、設定ページでサブスクリプションURLを追加します。識別しやすい名前を入力して更新を実行してください。更新後は、その設定を現在の設定として選び、プロキシグループでポリシーを選択します。初回接続時、AndroidはVPN接続リクエストを表示します。これはアプリがローカルVPNインターフェースを作成するためのシステム権限です。許可すると、通常はステータスバーにVPNアイコンが表示されます。ただし、アイコンはインターフェースの作成を示すだけなので、ブラウザーやクライアントログでトラフィックが正常に転送されているか確認してください。

Androidでは通常、一般的なVPNサービスを同時に1つしかアクティブにできません。別のVPN、会社の仕事用プロファイル、広告ブロックツールがすでに接続中の場合、新しい接続が以前の接続を置き換えたり、システムに拒否されたりします。プライベートDNSとClash内部のDNSが異なる名前解決経路を作ることもあります。ドメインは開けないのにIPアドレスへはアクセスできる場合、プライベートDNS設定を一時的に確認し、設定内のnameserver、fallback、fake-ipの動作を確認してください。

アプリ別の分流とバイパス設定

モバイルクライアントには、アプリごとにプロキシ、バイパス、または指定アプリだけをプロキシする機能が用意されていることがあります。銀行アプリ、LAN制御、画面ミラーリング、VPNに敏感なアプリをダイレクトにしたり、ブラウザーや通信ツールだけを取り込んだりする場合に便利です。アプリ一覧を変更した後は、VPNインターフェースを再作成してルールを確実に反映させます。システムアプリは複数のパッケージで構成されることがあるため、ホーム画面のアイコン名だけでは関連プロセスをすべて対象にできません。

ルールモードは設定されたルールに基づいて接続先を決め、アプリ分流はその前段で、アプリをClashに入れるかどうかを決めます。両者を混同しないでください。アプリをバイパスに設定すると、そのトラフィックはドメインルールに入らないため、ルールにプロキシが明記されていても適用されません。特定アプリを切り分ける場合は、まずアプリ分流リスト、次にルールの一致とプロキシグループ、最後にQUIC、自前DNS、証明書ピンニングの使用状況を確認します。

バックグラウンド制限と接続の回収

Androidメーカーは、バックグラウンド動作、バッテリー使用、自動起動に追加の制限を設けることがあります。画面ロック後に接続が切れる、最近のタスクを消すとVPNが消える、モバイルネットワークへ切り替えると復旧できない、といった症状が現れます。システム設定でクライアントのバックグラウンド実行を許可し、端末が提供する項目で過度なバッテリー最適化を無効にし、必要な自動起動を許可してください。メーカーによってメニュー名は異なりますが、目的はシステムがクライアントプロセスを停止したり、VPNサービスを制限したりするのを防ぐことです。

常時接続VPNは、ネットワークの変化後にAndroidが復旧を試みるよう設定できます。ただし、設定が安定する前に「VPN未接続時の接続をブロック」を同時に有効にしないでください。サブスクリプションの期限切れ、クライアントのクラッシュ、コアの起動失敗が発生すると、デバイスが完全にオフラインになる可能性があります。Wi-Fi、モバイルネットワーク、スリープ復帰、再起動後の動作を確認してから、厳格なモードを有効にします。一時的にネットワークを復旧する場合は、クライアント画面を閉じるだけでなく、システムのVPNページから切断してください。

テザリング、LAN、IPv6

スマートフォンでテザリングを有効にしたとき、接続したデバイスがClashを経由するかどうかは、システムバージョン、クライアントの機能、転送方式によって異なります。一般的なAndroid VPNで保証されるのは通常、本体アプリのトラフィックだけです。テザリング先のデバイスまで自動的に取り込まれるとは考えないでください。共有が必要な場合は、クライアントがテザリング転送やLAN接続を明示的に提供しているか確認し、接続先デバイスにスマートフォンのLANアドレスとプロキシポートを手動設定します。アプリによるLAN待ち受けを許可し、公共ネットワークでのアクセスリスクにも注意してください。

一部のモバイルネットワークはIPv6を優先します。設定がIPv4 DNSしか提供していない、またはルールがIPv4しか対象にしていない場合、アプリによって結果が異なることがあります。長期的な対処としてシステムのIPv6を無効にしないでください。まずコアのIPv6設定、DNSの応答、ルールの一致、プロキシ入口が対象の接続に対応しているか確認します。ログに到達不能なIPv6アドレスへの接続試行が残る場合は、切り分けのため一時的に設定を調整し、ネットワーク環境に応じてデュアルスタックを有効にするか判断してください。

Android側のログは、障害の層を判断する重要な手がかりです。設定解析エラーは通常コア起動前に発生します。DNSエラーには名前解決失敗やタイムアウトが表示されます。ポリシーの問題では、ルール一致後の接続失敗が表示されます。アプリが除外されている場合、該当するリクエスト自体が記録されないことがあります。この4層に分けて調べるほうが、クライアントを何度も交換するより原因を特定しやすくなります。

5. iOSのインストール、設定の読み込み、オンデマンド接続

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

iPhoneとiPadでは、iOSダウンロードからClash PlusのApp Storeページを開けます。クライアント公式サイトは clashplus.ioです。インストール後の初回起動時、システムからVPN構成の追加を求められることがあります。この許可はNetwork Extensionの作成に使われるもので、すべての接続が正常にプロキシされることを意味しません。許可後も、設定を読み込み、ポリシーを選択して接続を開始する必要があります。

iOSのネットワーク取り込みはシステム拡張が管理し、デスクトップOSのシステムプロキシスイッチは使いません。ステータスバーやコントロールセンターにVPNアイコンが表示されれば、拡張が接続状態にあります。アプリのメイン画面を閉じても、拡張が動作を続けることがあります。システム設定から切断した場合は、アプリ内の状態も更新されるはずです。切り分けでは、アプリの画面と「設定」のVPN状態を両方確認し、どちらか一方だけで判断しないでください。

サブスクリプションとローカル設定を読み込む

設定ページでサブスクリプションURLを追加し、更新後にその設定を選択します。他のアプリからサブスクリプションURLをコピーする場合、前後に空白や改行が入っていないか、チャットアプリで途中が切れていないか確認してください。ファイルアプリからYAMLを読み込む場合は、システムの共有メニューからClash Plusへ送信し、設定一覧で読み込み結果を確認します。設定ファイルが外部ルールセットを参照している場合、初回読み込み時に関連リソースのダウンロードも必要です。メインYAMLの読み込みに成功しても、すべてのルールリソースが準備できたとは限りません。

プロキシグループの選択方法は他のプラットフォームと同じです。ルールモードはルールに従って分流し、手動グループでは実際のポリシーを選び、自動グループは設定されたテスト方法で選択を更新します。モバイルネットワークは環境が頻繁に変わるため、Wi-Fiで使えるポリシーがセルラーネットワークでも接続できるとは限りません。特定のネットワークだけで失敗する場合は、設定を変えずにWi-Fiとセルラーネットワークのログを比較し、DNS、モード、ポリシーを同時に変更して原因を分からなくしないでください。

オンデマンド接続とシステムネットワークの切り替え

オンデマンド接続は、システムのネットワーク状態に応じて拡張を自動起動できます。安定性を確認済みの設定に適しています。有効にする前に、手動で完全な接続を1回行い、Wi-Fi、セルラーネットワーク、画面ロックからの復帰をそれぞれテストしてください。オンデマンドルールを誤ると、信頼できるLANでも自動的に取り込み、プリンター、画面ミラーリング、家庭内デバイスへのアクセスに影響することがあります。LANを明確に利用する場合は、プライベートアドレス向けのダイレクトルールを残し、ローカルネットワーク権限が許可されているか確認します。

iOSはネットワーク切り替え、低バッテリー、システムリソース不足の際にネットワーク拡張を再作成することがあります。一時的に切断されたら、まず拡張が再ネゴシエーションするまで待ち、その後アプリログを確認してください。接続中のまま何度も止まる場合は、システム設定からVPNを切断し、クライアントへ戻って再起動します。オンデマンドが有効なVPN設定を複数残すと、システムの選択動作が分かりにくくなるため、同時に保持しないでください。

DNS、QUIC、アプリごとの違い

Safari、ネイティブアプリ、サードパーティ製ブラウザーは、異なる接続方式を使うことがあります。一部のアプリはHTTP/3や独自の名前解決を優先するため、ブラウザーは使えるのに特定アプリだけタイムアウトする場合があります。設定内のDNSモード、ルール、UDP対応が結果に影響します。UDPを無効にするとアプリが復旧する場合、UDP転送やQUIC経路に問題がある可能性があります。ただしこれは切り分けの手がかりであり、すべてのUDPを無効にしたままにする代わりに根本原因を修正してください。

fake-ipモードでは、ドメインに予約アドレスを返し、コアがドメインを復元してルールに照合します。分流の一貫性を高めやすい一方、LAN探索、一部のデバイス制御アプリ、特殊なドメインでは除外リストが必要になることがあります。redir-hostは実際のDNS応答に近く、互換性の考え方が異なります。どちらがすべてのネットワークに適するという決まった答えはないため、設定ルール、LANの要件、ログを基準に選んでください。DNS漏れとnameserverの詳しい確認はDNS検査と設定ガイドを参照してください。

消費電力、バックグラウンド、設定のメンテナンス

ネットワーク拡張が接続を継続的に処理すると、一定の電力を消費します。ルール数、DNSクエリ、ログレベル、ネットワーク品質も実際の消費量に影響します。日常利用でdebugログを常時有効にしないでください。詳細ログは短時間の再現調査に使い、終了後は通常レベルに戻します。消費電力が急に増えた場合は、VPNアイコンの表示時間だけでなく、接続の再試行、DNSループ、自動テストグループの高頻度実行を先に確認してください。

サブスクリプションを更新する前に、現在のプロキシグループの選択を記録しておくと安心です。設定の更新によってプロキシグループが再構築され、名称の変更で以前の選択がデフォルトへ戻ることがあります。更新後に急にアクセスできなくなった場合は、設定が有効か、プロキシグループに選択肢があるか、ルールリソースのダウンロードが完了したか、拡張が再作成されたかを順に確認します。アプリの削除と再インストールは、ローカルオーバーライドや過去のログも消すため、設定のバックアップと基本的な切り分けの後に行ってください。

iOSではデスクトップOSのように完全なルーティングテーブルや待ち受けプロセスを直接確認できないため、クライアントログと比較テストへの依存度が高くなります。一度に1つの条件だけを変更してください。まずポリシーを変え、次にモードを変え、その後DNSを確認します。同じ手順で設定を再構築し、ネットワークも切り替えると、復旧しても本当の原因を特定できません。

6. Linuxデスクトップクライアントとコアサービスの導入

デスクトップ環境に合わせたインストール方法

LinuxデスクトップではLinuxダウンロードからClash Verge RevまたはFlClashを選べます。インストール前に、ディストリビューション、CPUアーキテクチャ、パッケージ形式を確認してください。Debian、Ubuntuとその派生システムでは通常deb、FedoraやRHEL系ではrpmが一般的です。パッケージマネージャーでローカルパッケージをインストールすると、依存関係も同時に確認できます。実行ファイルを直接展開する場合は、デスクトップエントリ、権限、自動起動、更新を自分で設定する必要があります。

デスクトップ環境によって、システムプロキシの対応は異なります。GNOME、KDE、軽量デスクトップではプロキシ設定を書き込む場所が異なり、環境変数を読むアプリ、デスクトップ設定を読むアプリ、どちらも無視するアプリがあります。そのためGUIクライアントに「システムプロキシが有効」と表示されても、ブラウザー、ターミナル、対象アプリを個別に確認してください。WaylandやX11がプロキシ機能を直接決めるわけではありませんが、トレイアイコン、認証ダイアログ、デスクトップ連携の表示には影響します。

設定を読み込み、待ち受けポートを確認する

GUIクライアントのサブスクリプション読み込み手順は、他のデスクトッププラットフォームと同じです。URLを追加し、更新し、設定を選択し、プロキシグループを選んでからシステムプロキシまたはTUNを有効にします。コアを使う場合は、設定を権限管理されたディレクトリに保存し、コマンドラインでパスを指定して起動します。起動前に設定テストを実行し、サービスが何度も再起動するのを防いでください。Mihomoのビルドによってパラメータが異なるため、現在のプログラムのヘルプを優先します。一般的な起動形式は次のとおりです。

mihomo -t -f /etc/mihomo/config.yaml
mihomo -d /etc/mihomo

ss -lntp | grep 7890
journalctl -u mihomo --no-pager -n 100

-tは設定を解析できるか確認し、-fは単一の設定ファイルを指定し、-dは作業ディレクトリを指定します。作業ディレクトリにはキャッシュ、ルールセット、データベースが含まれることがあるため、実行ユーザーには必要な読み書き権限を与えます。権限エラーを解消するために、ディレクトリ全体を全ユーザー書き込み可能にしないでください。サービスプロセスは専用の低権限アカウントで実行し、TUN作成、ルート変更、制限リソースのバインドに必要な場合だけ能力を付与します。

systemdサービスと自動起動

サーバーや長時間稼働するデスクトップホストでは、systemdでコアを管理できます。サービスは基本ネットワークが利用可能になってから起動し、異常終了時は適切な間隔で再試行するようにします。設定更新前に構文チェックを実行し、その後サービスを再読み込みまたは再起動します。以下の例では、バイナリと設定ディレクトリが指定されたパスに準備済みであることを前提としています。実際のユーザー名とパスは環境に合わせて変更してください。

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

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

[Install]
WantedBy=multi-user.target

サービスユニットとして保存したら、まず systemctl daemon-reload を実行し、起動してログを確認します。自動起動は、手動実行が安定してから有効にしてください。起動直後から失敗を繰り返す場合は、まず自動再試行を止め、設定テストを直接実行します。再起動ループはログを急速に埋めるだけでなく、ルートを何度も変更する可能性があります。サービスを更新するときは、互換性問題に備えて旧バイナリと設定のバックアップを残してください。

環境変数、デスクトッププロキシ、TUN

ターミナルツールでは http_proxy、https_proxy、all_proxy を使えます。同じ変数に大文字・小文字の形式が存在する場合、ツールによって読み取り方が異なります。サーバー上のsystemdサービスは、ユーザーのシェル設定を自動的に継承しません。サービスユニットまたは専用の環境ファイルで明示的に設定してください。1つのコマンドだけプロキシを通す場合は、コマンドの前に変数を置き、システム全体へ影響させない方法がおすすめです。

http_proxy=http://127.0.0.1:7890 \
https_proxy=http://127.0.0.1:7890 \
curl -I https://example.com

all_proxy=socks5://127.0.0.1:7890 git fetch

LinuxでのTUN導入には、仮想インターフェース、ポリシールーティング、DNS、ファイアウォールルールが関係します。コアには /dev/net/tun へのアクセスと、インターフェース作成・ネットワーク設定変更に必要な権限が必要です。コンテナ内で実行する場合は、TUNデバイスとネットワーク権限も明示的に渡します。現在のnftables、iptables、ポリシールーティングを理解しないまま、ルールを全消去するコマンド一式をコピーしないでください。リモート接続が切れる可能性があります。ルーターや旁路ルーターでの利用はOpenWrt導入概要を参照してください。

権限、DNS、コンテナの境界

長期間rootで直接実行すると、一部の権限問題は回避できますが、設定スクリプト、外部ルール、管理インターフェースによるリスクが広がります。専用アカウントを使い、capabilitiesやサービス管理で最小限の権限を与えるほうが適切です。管理用ポートを本機だけで使う場合はループバックアドレスにバインドします。LANからのアクセスが必要な場合は、アクセス制御とホストファイアウォールを同時に設定し、インターネットへ直接公開しないでください。

systemd-resolved、NetworkManager、dnsmasq、Clash DNSは、ローカルDNSポートを競合させたり、互いに転送したりすることがあります。まず、アプリがどこへリクエストを送り、システムのstubがどこへ転送し、Clashがどのアドレスで待ち受け、上流のnameserverがどこにあるかを整理してください。ポート競合時に、システムの名前解決サービスを考えずに停止しないでください。待ち受けアドレスや転送関係を調整します。コンテナ内部の 127.0.0.1 はコンテナ自身を指し、ホストを指しません。コンテナアプリがホストのプロキシを使うには、ゲートウェイアドレスと待ち受け範囲を明示する必要があります。

7. 共通設定ファイル、DNS、ルール、TUNパラメータ

設定ファイルの基本構造

Clashの設定はYAMLを使います。インデントは階層を表すため、タブとスペースを自由に混在させないでください。キー名の後のコロンには正しい空白を残し、リスト項目にはハイフンを使います。設定には通常、待ち受けポート、動作モード、ログレベル、プロキシ定義、プロキシグループ、ルールプロバイダー、DNS、最終ルールが含まれます。サブスクリプションが生成する完全な設定は長くなることがありますが、切り分けではまずトップレベルの構造が正しいか確認し、その後に個別のプロキシ入口を確認します。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

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

上の例は構文を説明するためのもので、利用可能なプロキシ定義は含みません。mixed-portはHTTPとSOCKSの接続を同時に受け付けます。allow-lanは他のデバイスからの接続を許可するか決めます。bind-addressは待ち受けアドレスを制限します。modeはルール、グローバル、ダイレクトの動作を決め、log-levelはログの詳細度を制御します。ポートは未使用であればよく、例の値に固定する必要はありません。待ち受けポートを変更したら、すべての外部プロキシ設定も同時に変更します。

allow-lanと待ち受けアドレス

本機だけで使う場合は、allow-lan: falseを維持し、ループバックアドレスにバインドすると分かりやすくなります。同じLAN内の他のデバイスからプロキシを使う場合は、LANアクセスを有効にし、クライアントが実際にLANインターフェースで待ち受けていることを確認します。その後、他のデバイスにClashを実行している端末のLAN IPとmixed-portを入力します。ホストファイアウォールでは該当ポートを許可する必要がありますが、すべてのネットワークプロファイルに無条件で開放しないでください。

LAN接続を許可しても、他のデバイスへ自動的にトラフィックが共有されたり、ゲートウェイが設定されたりするわけではありません。下流デバイスでHTTP/SOCKSプロキシを手動設定するか、ゲートウェイで透過転送を行う必要があります。モバイルデバイスが現在のWi-Fiから離れると、元のLANアドレスには到達できなくなるため、手動プロキシを解除してください。公共Wi-Fiでは待ち受けを開放しないことをおすすめします。必要な場合でも、少なくとも送信元ネットワークを制限し、管理インターフェースまで公開しないようにしてください。

ルールの照合順序とプロキシグループ

ルールは上から順に照合され、通常は最初に一致した時点で処理が止まります。そのため、より具体的なドメイン、プロセス、プライベートネットワークのルールを、広範囲のルールより前に置きます。MATCHは通常末尾に配置します。DOMAINは完全なドメインに一致し、DOMAIN-SUFFIXはドメインサフィックスに、DOMAIN-KEYWORDはキーワードに、IP-CIDRはアドレス範囲に一致します。IPルールによってDNS解決が発生することがあり、解決を省略できるかは構文とコアの対応状況によります。

プロキシグループはプロキシ入口そのものではなく、複数のポリシーを選択、テスト、フォールバックする論理層です。selectグループはユーザーが手動で選択します。url-testはテストアドレスと間隔に基づいて選択を更新します。fallbackは通常、利用可能性の順に切り替えます。load-balanceは設定された方式で接続を分配します。テスト結果はテスト対象とその時点のネットワークだけを反映し、すべてのWebサイトへアクセスできることを意味しません。テスト間隔を短くしすぎると接続数と消費電力が増えるため、画面を頻繁に更新する目的で常時探測しないでください。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - provider-a
      - provider-b
    url: https://www.gstatic.com/generate_204
    interval: 600

DNSモードと名前解決経路

DNS設定の目的は、ドメインを解決することだけではありません。解決結果をルール照合やプロキシ接続と一致させることも重要です。fake-ipモードは予約アドレスを返し、コアがドメインとの対応を記録して接続時にドメインを復元します。安定したドメイン分流が必要な環境に適しています。redir-hostは実際の解決結果を返すため、一部のLANや特殊アプリでは分かりやすい一方、分流経路が異なります。選択前に、クライアントがシステムDNSを取り込むか、Clashに入らないアプリがどこへ問い合わせるかを確認してください。

nameserverは通常の上流DNS、fallbackは別の名前解決経路、default-nameserverはDoHやDoTの上流自体のドメイン解決に使われることが多い項目です。上流にドメイン名を指定し、その基礎解決も同じ上流に依存すると、起動時の依存ループが生じる可能性があります。ブラウザーのセキュアDNSがシステム経路を迂回する場合もあります。DNS漏れを検査するときは、ブラウザー設定、システムリゾルバー、Clashログを同時に確認し、1つのWebページの結果だけで判断しないでください。

TUNパラメータと厳格ルーティング

TUNモードでよく使われるパラメータには、有効・無効、スタック実装、自動ルート、自動インターフェース検出、厳格ルートがあります。対応範囲はプラットフォームやコアのバージョンによって異なり、クライアント画面がこれらの項目を代わりに生成する場合もあります。自動ルートを有効にすると、コアが必要なルートを追加します。自動インターフェース検出は、Wi-Fi、Ethernet、モバイルネットワークの変化時に出口を識別します。厳格ルートはトラフィックの迂回を減らせますが、仮想マシン、コンテナ、LANルートとの競合が表面化しやすくなります。

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

初回有効化では保守的な設定から始め、必要な項目だけを有効にします。ブラウザー、ターミナル、LAN、スリープ復帰が正常であることを確認してから、厳格ルートやDNSハイジャックを調整してください。企業VPN、仮想スイッチ、コンテナブリッジ、複数のデフォルトルートがある場合は、有効化前後のルート差分を記録します。TUNはシステムプロキシが効かないときの万能な代替ではありません。解決するのはトラフィックの取り込み範囲であり、無効なサブスクリプション、誤ったポリシー、リモート接続失敗を修復するものではありません。

8. 設定更新、接続異常、復旧手順

層ごとに切り分け、複数の変数を同時に変更しない

トラブルシューティングでは、基本ネットワーク、クライアントプロセス、設定の読み込み、待ち受けポート、トラフィックの取り込み、ルール一致、ポリシー接続、DNSを順に確認します。まずダイレクトへ切り替えるかクライアントを完全に終了し、デバイス自体がインターネットへ接続できることを確認します。次にクライアントを起動しますが、まだシステムトラフィックは取り込まず、コアが正常に動作しているか確認します。その後、ローカルプロキシポートを使って明確なテストを1回行い、最後にシステムプロキシまたはTUNを有効にします。これにより、問題がコアより前にあるのか、システムの取り込み後にあるのかを区別できます。

一度に1つの条件だけを変更してください。サブスクリプション更新、クライアント切り替え、DNS変更、TUN有効化、ポリシー変更を同時に行わないでください。複数の操作を同時に実施すると、復旧しても原因を特定できません。クライアントログはまずinfoレベルで確認し、より詳しい情報が必要なときだけ短時間debugへ切り替えます。ログを共有する前に、サブスクリプションURL、認証情報、プロキシアドレス、デバイス情報を削除してください。

サブスクリプションの更新に失敗する

サブスクリプションの更新に失敗したら、まずURLが完全か、期限切れでないか、コピー時に空白が入っていないか、基本ネットワークから対象アドレスへアクセスできるか確認します。HTTPステータスエラーは、認証、レート制限、サービス側の状態が原因であることが多く、接続タイムアウトはDNS、現在のプロキシ経路、ネットワーク遮断が考えられます。ダウンロードは成功したのに解析に失敗する場合は、返却内容が想定したYAMLでない、または変換形式が違う可能性があります。システムプロキシを何度も切り替えるだけで対処しないでください。

古い設定は使えるのに新しい設定だけ更新できない場合は、まず古い設定を残し、ブラウザーやcurlでサブスクリプションURLへ個別にリクエストして、レスポンスの種類を確認します。更新が現在のプロキシ経由かダイレクトかは、クライアントの実装によって異なります。必要に応じて取り込み方式を一時的に変えて比較してください。設定にリモートルールセットが含まれる場合、メインサブスクリプションが成功しても、ルールリソースのダウンロード段階で失敗することがあります。ログで具体的なURLとリソースの種類を区別してください。

起動失敗とポート競合

ログにaddress already in useと表示された場合、待ち受けアドレスまたはポートが使用中です。よくある原因は、同じクライアントの二重起動、終了していない古いコア、同じポートを使う別のプロキシソフト、システムサービスによる別インスタンスの自動起動です。Windowsではnetstatとタスクマネージャー、macOSとLinuxではlsofまたはssで特定できます。プロセスの用途を確認してから終了し、ポート番号だけを見て未知のシステムプロセスを停止しないでください。

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

mixed-portを変更する場合は、クライアント画面、システムプロキシ、環境変数、ブラウザーの手動プロキシ、LAN内のデバイスをすべて新しい値に変更します。YAMLだけを変更しても、クライアントが実際にはオーバーライド設定を使っていれば、起動後にポートが再び置き換えられることがあります。詳しい分岐はポート7890の使用中エラーを特定する方法を参照してください。

接続済みなのにWebページを開けない

まず、プロキシグループで実際のポリシーが選択されているか確認します。空のグループや利用できない上位グループになっていないことも確認してください。次にリクエストログを見ます。ログがまったくない場合は、トラフィックがクライアントに入っていません。ルール一致後に接続が失敗している場合は、ポリシーまたはリモート側の問題です。ドメイン解決だけが失敗している場合は、DNSを優先して確認します。ブラウザーに証明書またはプロトコルエラーが出る場合は、システム時刻、QUIC、証明書ストア、中間ネットワークを確認してください。グローバルモードへの切り替えはルールの影響を判断する手段にすぎず、常用に適するとは限りません。

一部のWebサイトだけに問題がある場合は、そのドメインがどのルールに一致し、最終的にどのポリシーへ渡されたか確認します。ルールは上から順に実行されるため、前の広範なルールが後の正確なルールを先に取り込むことがあります。特定のアプリだけが異常な場合は、システムプロキシを無視していないか、アプリ分流で除外されていないか、UDPや独自DNSを使っていないか確認します。この場合、TUNは取り込み範囲の確認に使えますが、リクエストが実際に入ったかはログで確認してください。

DNS異常と漏れの確認

ドメインには失敗するのにIPへはアクセスできる場合、DNS経路に問題があることが多いです。システムDNSの向き先、Clash DNSの待ち受けポート、nameserverの到達性、ブラウザーのセキュアDNS、TUNのDNSハイジャック設定を確認します。fake-ipで予約アドレスが表示されても、それだけで異常とは限りません。重要なのは、接続がコアに取り込まれ、元のドメインへ復元されているかです。アプリがClashを迂回してfake-ipアドレスへ直接アクセスすると失敗するため、取り込み範囲または除外ルールを調整してください。

DNS漏れの検査を1回のWebテストだけに頼らないでください。有効化前後のDNSサーバーを比較し、クライアントログに対象の問い合わせが記録されているか確認し、コマンドラインツールでシステムのデフォルトリゾルバーを指定してテストします。企業ネットワーク、モバイルネットワーク、ブラウザー独自の暗号化DNSが追加経路を作ることもあります。詳しい手順はDNS漏れの検査とfake-ip設定の実践ガイドを参照してください。

TUN有効化後にLANや仮想マシンが使えない

TUNはルートの優先順位を変え、厳格ルートやDNSハイジャックによって影響範囲がさらに広がります。LANが使えなくなったら、まずプライベートアドレス向けのダイレクトルールを確認し、次にルーティングテーブルで対象ネットワークをどのインターフェースが処理しているか確認します。仮想マシン、Docker、WSL、コンテナプラットフォームは独自のプライベートネットワークを作ることが多く、物理LANやプロキシの予約アドレスと重なると競合します。長期的な応急処置として個別のデバイスIPを追加するのではなく、完全なネットワーク範囲と実際の出口を特定してください。

strict-routeを無効にしたりDNSハイジャックを一時停止したりすることは、切り分けの手段になります。ただし、どの変更で接続が復旧したか記録してください。スリープ、ネットワーク切り替え、VPN再接続の後だけ発生する場合は、自動インターフェース検出が更新されていない可能性があります。コアを再起動するかTUNを再作成するほうが、デバイス全体を再起動するより的確な場合があります。Linuxサーバーではnftables、ポリシールーティング、逆引きパスフィルタリングも確認し、WindowsとmacOSでは他のVPNやセキュリティクライアントを確認してください。

元に戻せるメンテナンス習慣を作る

クライアントを更新したり設定を大きく変更したりする前に、現在使える設定、オーバーライドファイル、重要な設定値を保存します。機密性のあるサブスクリプションを含むファイルを公開場所へバックアップしないでください。変更後は、設定解析、コア起動、単一ポートのプロキシ、システムプロキシまたはTUN、DNS、LAN、スリープ復帰を個別に確認します。どこかで失敗したら、変更を重ねるのではなく、直近の明確に動作していた状態へ戻してください。

初回設定を早く完了したい場合はClashクイックスタートガイドへ戻ってください。クライアントを選び直す場合はクライアント比較レビューを確認できます。プロキシグループ、設定ファイル、fake-ip、mixed-portなどの用語は用語集で個別に確認できます。「入手元を明確にする、設定を層別に保存する、一度に1項目だけ変更する、ログを層ごとに判断する」という流れを身につけるほうが、特定クライアントの画面上の固定位置を覚えるより確実です。