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

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

プラットフォーム、アーキテクチャ、クライアント種別を確認する

Clashは単一のインストーラーではなく、プロキシコア、GUIクライアント、設定ファイル、ルーティングデータで構成されるツールチェーンです。一般的なデスクトップやモバイル端末ではGUIクライアントを使い、サーバー、ソフトウェアルーター、コンテナ環境ではMihomoコアを直接実行します。GUIクライアントはサブスクリプション管理、ポリシー切り替え、ログ確認、システム権限の操作を担当し、コアは設定の解析、ローカルポートの待ち受け、ルール照合、接続転送を担当します。ダウンロード前にこの2種類を区別すれば、コマンドライン専用のコアをデスクトップアプリとしてインストールする誤りを防げます。

プラットフォームの判断では、Windows、macOS、LinuxといったOS名だけでなく、CPUアーキテクチャも確認します。一般的なWindows PCはx64ですが、QualcommなどのARMプロセッサー搭載機ではARM64が必要です。Apple Silicon MacにはmacOS ARM64版、Intel Macにはx64版を選びます。Androidのインストーラーにはarm64、arm、universalがあり、近年の端末では通常arm64を優先します。不明な場合はuniversalを選べます。Linuxではパッケージ形式も確認し、Debian、Ubuntuとその派生環境は通常deb、FedoraやopenSUSEなどは通常rpmを使います。

サブスクリプションURLと基本的なネットワークを準備する

クライアント自体に利用可能なプロキシノードは含まれていません。初回設定の前に、サービス提供元が発行したClashまたはMihomo対応のサブスクリプションURL、あるいは完全なYAML設定ファイルを用意してください。サブスクリプションURLには通常、アクセス認証情報が含まれます。パスワードと同じように管理し、スクリーンショット、公開ログ、コマンド履歴、公開コードリポジトリに載せないでください。提供元が複数形式を用意している場合は、Clash、Mihomo、Metaと明記された形式を優先します。一般的な共有リンクを追加できるかは、クライアントの形式変換機能に左右されます。

追加前に、現在のネットワークからサブスクリプションURLへアクセスできることを確認します。ブラウザーで開けなければ、通常クライアントも更新できません。認証が必要なサブスクリプションでYAMLテキストが返るのは正常です。ログイン画面、HTMLエラーページ、空の内容が返る場合は、URL、権限、ネットワーク環境に問題があります。企業、学校、公共のネットワークでは特定の接続が制限されることがあるため、初回インストールは安定した家庭回線やモバイルホットスポットで行い、その後対象ネットワークで確認してください。

設定、サブスクリプション、オーバーライドを区別する

サブスクリプションはリモート設定の取得元、設定ファイルはクライアントが実際に読み込む内容、オーバーライドはリモートのサブスクリプションを変更せずにローカル項目を調整する仕組みです。多くのGUIクライアントはサブスクリプションをキャッシュするため、追加に成功しても起動のたびにリモートへ再取得するとは限りません。通常は更新ボタンで再取得します。サブスクリプションのキャッシュ内にあるYAMLを変更しても、次回更新時に上書きされる可能性があります。ポート、DNS、ルールの変更を長期的に保持する場合は、クライアントのオーバーライド、設定のマージ、スクリプト機能を使い、変更前に元の設定をエクスポートしてください。

最小構成には、少なくとも待ち受けポート、プロキシノードまたはプロキシプロバイダー、ポリシーグループ、ルールが必要です。各項目には参照関係があります。ルールがポリシーグループを参照し、ポリシーグループが具体的なノードを選択します。名前が1か所でも一致しないと読み込みに失敗します。YAMLを手作業で管理する場合は、まず Clash設定ファイルの構造解説 を読み、階層を理解してから変更してください。YAMLのインデントにはスペースを使い、タブを混在させないでください。同じリスト内の項目はインデントを統一します。

元に戻せる初期状態を記録する

インストール前に、システムに設定されているプロキシ、DNS、VPNアプリの状態を記録します。Windowsでは「設定 → ネットワークとインターネット → プロキシ」、macOSでは現在のネットワークサービスの「詳細 → プロキシ」を確認します。モバイル端末では、別のVPN構成がないか確認してください。Clashと他のVPN、ネットワークフィルター、パケットキャプチャー、ペアレンタルコントロール、企業向けセキュリティソフトを同時に動かすと、ルーティングテーブル、仮想NIC、システムプロキシを奪い合うことがあります。初回の切り分けではネットワークを制御するツールを1つだけ残し、接続が安定してから他のソフトを1つずつ戻します。

ダウンロード先は クライアントページ にまとめています。Clash PlusはWindows、macOS、Android、iOS向けの推奨GUIクライアントです。LinuxデスクトップではClash Verge RevまたはFlClashを選べます。サーバーやルーター環境ではMihomoコアを検討してください。サポートが終了したClash for WindowsとClashX Metaは、既存環境の移行や旧設定との互換性が必要な場合に限って使用し、新規の長期運用にはおすすめしません。

Windowsのダウンロード、インストール、システム接続

インストーラーをダウンロードして初回起動を完了する

Windowsの一般ユーザーにはClash Plusを推奨します。操作感に応じてClash Verge Rev、FlClash、Clash Nyanpasuも選べます。Windowsダウンロード欄でデバイスのアーキテクチャを確認してから、完全なインストーラーをダウンロードしてください。IntelまたはAMD搭載PCの大半はx64です。システム情報にARM64と明記された端末だけARM版を選びます。インストール先は既定の場所を推奨します。頻繁に同期するクラウドドライブ、一時フォルダー、権限の制限が厳しいフォルダーは避けてください。

インストール中にユーザーアカウント制御が表示されたら、操作元を確認してインストールを許可します。初回起動時には、Windowsファイアウォールがクライアントの通信を許可するか尋ねることがあります。信頼できるネットワークでの利用に限り、必要に応じて許可してください。拒否しても、通常はループバックアドレス経由で本機からプロキシポートへ接続できますが、LAN共有、外部制御、一部のTUN機能が制限される場合があります。インストール後はまずメイン画面を開き、設定と接続方式が正常に動作することを確認してから、自動起動を有効にします。

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

設定またはサブスクリプション画面でURLからの追加を選び、URLを貼り付けて保存します。取得が完了すると、設定名、ポリシーグループ、ノード一覧が表示されます。空の設定しか表示されない、または追加ボタンを押しても反応しない場合は、ログでHTTPステータス、タイムアウト、証明書エラー、YAML解析情報を確認します。ローカルファイルを追加するときは、ブラウザーで保存したHTMLページではなく、完全なYAMLファイルを選びます。設定の読み込みに成功したら現在の設定に指定し、プロキシグループ画面でポリシーを選択します。

初回テストでは、主要なポリシーグループに自動選択や負荷分散ではなく、明確なノードを1つ指定することをおすすめします。接続問題が起きたときに、ヘルスチェックやポリシー切り替えの影響を除外できます。クライアントの遅延テストはテスト先への接続だけを示すもので、すべてのサイトで利用できることを意味しません。テスト後はログを開き、一般的なWebページへアクセスした際にルールのヒットと接続記録が出ることを確認します。

システムプロキシの有効化とポートの関係

Windowsのシステムプロキシは、ブラウザー、チャットアプリ、WinINETまたはシステムプロキシ設定に従う多くのデスクトップアプリに適しています。クライアントの「システムプロキシ」を有効にすると、通常はHTTPとHTTPSプロキシがローカルの待ち受けアドレスを指します。一般的な待ち受けアドレスは 127.0.0.1 で、ポートは設定の mixed-port、port、またはクライアント設定から取得されます。システムプロキシはローカルポートを指定する設定にすぎず、実際のルール照合はClashコアが行います。

ブラウザーはアクセスできるのにコマンドラインツールが失敗する場合、ノードではなく、プログラムがWindowsのシステムプロキシを読み取っていないことが多いです。PowerShell、Git、パッケージマネージャー、開発ツールでは、プロキシ環境変数やアプリ内プロキシを個別に設定する必要があります。逆に、ブラウザー拡張機能が独自のプロキシを設定していると、システム設定を迂回する場合があります。切り分けではまずブラウザーのプロキシ拡張を無効にし、システムプロキシのアドレスがクライアントの実際の待ち受けポートと一致するか確認します。

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

Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY

上記のPowerShell設定は現在のターミナルセッションだけに適用され、ポートはクライアントに表示される実際の混合プロキシポートへ置き換える必要があります。短期テストではセッション単位の変数が安全です。ウィンドウを閉じれば他のプログラムへの影響は残りません。Gitだけに設定する場合はGit独自の設定項目を使い、不要になったら削除してください。クライアント終了後もコマンドが無効なローカルポートを参照するのを防げます。

TUNモード、サービスモード、権限

システムプロキシを読み取らないアプリ、ストアアプリの一部、UDPを処理するプログラムではTUNモードを利用できます。TUNは仮想ネットワークインターフェースを作成してルーティングを変更するため、通常は管理者権限またはサービスコンポーネントが必要です。クライアントによっては「サービスモード」を用意し、起動のたびに管理者権限を求める代わりにバックグラウンドサービスを使います。サービスをインストールしたらクライアントを再起動し、サービスが正常であることを確認してからTUNを有効にします。仮想NICの作成に失敗する場合は、他のVPN、仮想マシンのネットワークコンポーネント、古いネットワークフィルタードライバーが同時に動作していないか確認します。

TUNを有効にしても、すべての接続がプロキシを通るわけではありません。ルールモードでは、ドメイン、IP、プロセス、ルールセットに応じて、直接接続、プロキシ、ブロックを決定します。LANプリンター、NAS、リモートデスクトップに接続できない場合は、すぐにグローバルモードへ切り替えるのではなく、プライベートアドレスのルールとルーティング除外を確認します。一般的なプライベートネットワークは直接接続にし、企業環境で独自の内部ネットワークを使っている場合は、追加の直接接続ルールを設定します。

自動起動、スリープ復帰、終了の順序

サブスクリプション更新、システムプロキシ、TUNが正常に動くことを確認してから、自動起動を有効にします。「サイレント起動」「起動後にシステムプロキシを有効化」「起動後にTUNを有効化」などの独立した設定がある場合は、段階的に有効にしてください。まずクライアントだけを起動し、接続を自動制御しない状態で再起動を1回確認し、その後自動プロキシを有効にします。サービスの準備前にシステムが通信をローカルポートへ向け、ログイン直後に一時的な通信断が起きるのを防げます。

Windowsではスリープ復帰やネットワーク切り替え後に、古い接続やDNSキャッシュが残ることがあります。復帰後にアクセスできない場合は、まずシステムプロキシまたはTUNを停止し、クライアントがネットワーク状態を再取得するのを待ってから再度有効にします。クライアントを終了する前に画面の終了コマンドを使い、システムプロキシを元に戻してください。タスクマネージャーで直接プロセスを終了すると、プロキシアドレスが残る場合があります。「クライアント終了後にすべてのWebページが開けない」場合は、システムプロキシ設定で手動プロキシを無効にしてからクライアントを再起動します。

macOSのインストール、権限、ネットワーク拡張

Apple Silicon版とIntel版を選ぶ

macOSでは最初にCPUアーキテクチャを確認します。画面左上のAppleメニューから「このMacについて」を開き、チップにApple Mシリーズと表示される場合はApple SiliconまたはARM64版を、プロセッサーにIntelと表示される場合はx64版を選びます。Clash Plusを推奨しますが、Clash Verge RevやFlClashも利用できます。ダウンロード先は macOSクライアント欄 です。アーキテクチャを間違えると起動できない、または互換レイヤー経由で動作して互換性の問題が増えることがあります。

一般的なインストール方法は、ディスクイメージを開き、アプリを「アプリケーション」フォルダーへドラッグして、そこから起動する手順です。ディスクイメージから長期間直接実行しないでください。マウントパスが変わるため、ログイン項目、更新、権限の記録が不安定になる場合があります。初回起動でブロックされたら、「システム設定 → プライバシーとセキュリティ」でアプリ名を確認して開くことを許可します。アプリの場所を何度も移動しないでください。macOSでは異なるパスが別の許可対象として扱われます。

サブスクリプションを追加して必要な権限を許可する

クライアントの設定画面でリモートサブスクリプションを追加し、更新後にアクティブな設定として指定します。続いてポリシーグループでノードを選び、ログまたはWebアクセスで接続を確認します。プロキシ、TUN、ネットワーク拡張を初めて有効にすると、管理者パスワードの入力やVPN構成の追加許可を求められる場合があります。許可画面はOSが表示するものです。完了後はクライアントに戻り、スイッチの状態を確認してください。システムのポップアップが消えたかだけで判断しないようにします。

クライアントにメニューバーアイコンがある場合、メニューバーからシステムプロキシやモードをすばやく切り替えられます。ただし複雑な設定はメイン画面で行ってください。メニューバーアイコンが消えても、プロセスが終了したとは限りません。システムによって折りたたまれているか、アプリがバックグラウンドのみで動作している可能性があります。「アクティビティモニタ」でプロセスを確認する方が、複数のインスタンスを繰り返し起動するより確実です。同じポートを複数のインスタンスが使うと、後から起動したコアがポート使用中のエラーを出します。

システムプロキシとネットワークサービスの違い

macOSはネットワークサービスごとにプロキシ設定を保存します。Wi-Fi、Ethernet、インターネット共有にはそれぞれ別の設定がある場合があります。クライアントがシステムプロキシを有効にすると、通常は現在アクティブなサービスを変更しますが、ネットワーク切り替え後に別のプロキシ状態へ戻ることがあります。Wi-Fiでは正常で有線接続では失敗する場合は、「システム設定 → ネットワーク」で現在のサービスを確認し、クライアントだけを再起動しないでください。企業の構成プロファイルでプロキシが固定されている場合、一般アプリでは上書きできないため、端末管理ポリシーに従います。

システムプロキシは、主にCFNetworkまたはシステムネットワーク設定に従うアプリへ影響します。ターミナルの curl、SSH、Homebrew、一部の開発ツールは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
unset HTTPS_PROXY

ポートはクライアントの現在の混合ポートと一致させます。ターミナルのテストは成功するのにGUIアプリが失敗する場合は、アプリが独自のネットワーク拡張を使っていないか、古いDNSをキャッシュしていないか、システムプロキシを明示的に無効化していないか確認します。GUIアプリは正常でターミナルだけ失敗する場合は、環境変数、Shellの起動ファイル、アプリ独自のプロキシ設定を優先して確認します。

TUN、DNS、他のネットワーク拡張との競合

TUNは、より多くのアプリやUDP通信を制御したい場合に適しています。有効にすると、クライアントはネットワーク拡張をインストールまたは呼び出し、システムルートを変更します。macOSではファイアウォール、コンテンツフィルター、企業VPN、仮想マシンブリッジ、他のプロキシアプリも同時に動作する可能性があり、処理順序が接続に影響します。初めてTUNを有効にする前に、他のネットワーク制御ツールを一時終了し、「システム設定 → ネットワーク → VPNとフィルタ」で重複した設定が有効になっていないか確認します。

TUNを有効にした後、IPアドレスにはアクセスできるのにドメインを解決できない場合は、クライアントログのDNSリクエストを確認し、設定したDNSサーバーへ現在のネットワークから到達できるか確認します。LANドメインがルーターや社内DNSに依存している場合、すべての問い合わせをパブリックDNSへ送ると内部名が解決できなくなります。内部ドメインには個別のnameserver-policyを設定するか、対応するドメインとプライベートアドレスをローカル解決へ回します。

ログイン項目、終了、システムアップデート後の確認

自動起動が必要な場合は、クライアント本体のログイン時起動を使い、「システム設定 → 一般 → ログイン項目」で状態を確認します。複数のツールで同じ起動項目を追加しないでください。2つのインスタンスが起動する可能性があります。システムアップデート後にネットワーク拡張が動かなくなった場合は、アプリの権限とバックグラウンド項目が許可されたままか確認してから、サービスコンポーネントを再インストールします。アプリを削除するだけではシステムプロキシが残る場合があります。削除前にシステムプロキシとTUNを停止し、クライアントを通常の手順で終了してください。

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

インストーラーを選んでインストールを完了する

AndroidではClash Plusを優先して選べます。Clash Meta for Android、FlClash、Surfboardも利用できます。Androidダウンロード欄で、端末のアーキテクチャに合ったインストーラーを選んでください。近年のスマートフォンやタブレットの大半はarm64です。古い端末ではarmを使う場合があります。不明な場合はuniversalを選べますが、ファイルサイズは通常大きくなります。アーキテクチャが合わないと、インストール時にエラーが出るか、インストール後に起動できません。

ブラウザーからアプリのインストーラーをダウンロードすると、Androidは現在使用しているブラウザーまたはファイルマネージャーに「不明なアプリのインストールを許可」を求める場合があります。この権限は指定したアプリがインストールを開始することだけを許可し、すべての提供元を永久に許可するものではありません。インストール後は必要に応じて、その提供元の許可を無効にできます。既存アプリとの競合が表示される場合は、署名が異なるか、同じパッケージ名を旧アプリが使っていることが多いです。まず旧クライアントの設定をエクスポートし、サブスクリプションやオーバーライドルールを失わないようにしてからアンインストールを判断します。

サブスクリプションを追加してVPN接続を作成する

クライアントを開き、設定画面でURLからサブスクリプションを追加し、更新後にその設定を選択します。プロキシまたはポリシー画面で、主要なポリシーグループにノードを指定します。ホーム画面で起動をタップすると、AndroidがVPN接続リクエストを表示します。許可すると、通常ステータスバーにVPNアイコンが表示されます。この権限はローカルの仮想ネットワークインターフェースを作成してアプリの通信をClashコアへ渡すためのもので、利用可能なノードが選択済みであることを意味しません。アクセスできるかどうかは、設定、ポリシー、DNSに左右されます。

起動をタップしてすぐ停止する場合は、まずクライアントログを確認します。よくある原因は、設定解析エラー、ローカルポートの競合、別アプリによるVPN権限の使用、バックグラウンド起動の制限です。Androidでは通常、一般的なVPN接続を同時に1つしか使えません。他のVPN、広告ブロッカー、企業向けセキュリティクライアント、一部のファイアウォールがClashと入れ替わることがあります。テスト時は他のVPNを停止してから、もう一度許可してください。

アプリ別プロキシ、バイパス、ローカルネットワーク

Androidクライアントは通常、アプリ別プロキシに対応しています。指定したアプリだけをプロキシするか、指定したアプリをVPNから除外できます。対象を限定する方式は、どのアプリを制御するか明確な場合に適しています。バイパス方式は、ほとんどのアプリを制御しつつ銀行、LANツール、企業アプリだけを除外したい場合に向いています。システムコンポーネントには呼び出し関係があり、アプリがシステムダウンローダー、WebView、外部ブラウザー経由でリクエストすることもあります。アプリ別リストが狭すぎると、メイン画面は正常なのにログインやダウンロードだけ失敗することがあります。

ルーター、キャスト機器、プリンター、NASへアクセスするには、LAN接続を許可し、プライベートアドレスを直接接続にします。一部のAndroidには「VPNを使用しない接続をブロック」という設定があり、有効にするとVPNに入らない通信がすべて破棄されるため、アプリ別バイパスやLANアクセスと競合する場合があります。このシステム設定を有効にしたときだけ問題が起きる場合は、まず無効にして確認し、その後Clashのルーティングとバイパスルールを調整します。

省電力設定とバックグラウンド維持

モバイルOSは、画面オフ、バッテリー残量低下、長時間のバックグラウンド動作中にアプリを制限します。起動直後は正常でも、しばらく画面をロックすると接続が切れ、クライアントを開くと復旧することがあります。システムのバッテリー設定でクライアントを「制限なし」にし、バックグラウンド動作を許可してください。端末メーカーの自動起動管理でも起動を許可します。設定名はメーカーごとに異なりますが、確認すべき点は同じです。画面オフ後もクライアントのプロセスとVPNサービスが終了されないことです。

TUNまたはVPNを継続利用すると、一定の電力を消費します。消費量はネットワーク品質、DNSリクエスト、ヘルスチェックの頻度、アクティブな接続数に左右されます。維持のために、重複した定期更新や高頻度の速度測定を複数有効にしないでください。サブスクリプションの更新間隔は実際の用途に合わせ、ポリシーグループのヘルスチェックも大量のノードを頻繁に探査する必要はありません。異常な電池消費がある場合は、Androidのバッテリー使用量とクライアントログを確認し、継続的な通信なのかVPNの再起動を繰り返しているのかを切り分けます。

モバイル通信、Wi-Fi、プライベートDNS

Wi-Fiからモバイル通信へ切り替えると、既存のTCPおよびUDP接続が切断され、クライアントは通信経路を再確立します。しばらく待っても復旧しない場合は、サブスクリプションを何度も追加し直すのではなく、VPNを停止して再起動します。Androidの「プライベートDNS」は暗号化DNSを使うため、ClashのDNS制御と処理順が異なる場合があります。一部のドメインだけ解決できない場合は、まずプライベートDNSを自動にして比較し、その後の設定に応じてシステムまたはClashのどちらか一方にDNS処理を任せます。

iOSのインストール、VPN構成、オンデマンド接続

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

iPhoneとiPadではClash Plusを使用します。ダウンロードページにはApp Storeへのリンクがあり、公式サイト clashplus.io も掲載しているため、アプリ情報の確認に利用できます。インストール後はまずアプリを開き、システム権限の説明を確認してから設定画面へ進みます。iOSのネットワーク制御はシステムのNetwork Extensionに依存します。アプリが初めてプロキシを起動すると、VPN構成の追加を求められ、端末のパスコード、Face ID、Touch IDでの認証が必要になります。

システム設定のVPN状態は、ネットワーク拡張が確立しているかを示すもので、設定内のノードが利用可能とは限りません。インストール後は、サブスクリプション追加、設定の選択、ポリシーグループの指定、接続テストを順番に行います。VPNだけを許可して有効な設定を読み込んでいない場合、接続直後に切断されたり、接続中のまま転送可能なポリシーがなかったりします。

サブスクリプションの追加と設定更新

設定画面でURLからの追加を選び、ClashまたはMihomo対応のサブスクリプションURLを貼り付けます。更新に成功したら、設定内にプロキシグループとルールがあることを確認して現在の設定に指定します。iOSではサブスクリプションURLを貼り付ける際、クリップボードへのアクセスに関するプライバシー通知が表示されることがあります。追加後はURLをクリップボードに長期間残さないでください。Safariでサブスクリプションリンクをタップしてアプリへ移動する場合は、実際に開いたアプリと設定名を確認し、同じサブスクリプションを重複追加しないようにします。

サブスクリプションの更新に失敗したら、まずSafariで同じURLへアクセスします。ブラウザーでも開けない場合は、ネットワーク、URLの有効性、サービス状態を確認します。ブラウザーでは開けるのにアプリが失敗する場合は、URLにエスケープされた文字が含まれていないか、追加のリクエストヘッダーが必要でないか、クライアントログのステータスコードを確認します。既存設定を更新する前に重要なオーバーライドをエクスポートしてください。リモート更新で、サブスクリプションが生成したノードやポリシーグループが置き換わることがあります。

ポリシーモード、LAN、モバイル通信

初回接続ではルールモードを使い、主要なポリシーグループに明確なノードを指定することをおすすめします。グローバルモードでは、本来直接接続すべき多くのシステムサービスやローカル接続まで単一のポリシーへ渡すため、長期的なトラブル解決には適しません。ルールモードではドメインとアドレスを順番に照合し、ヒットしなかった接続は最終ルールで処理します。家庭内機器へアクセスする場合は、プライベートアドレス、LANドメイン、Bonjour関連の通信が誤ってプロキシされないようにします。

Wi-Fiからモバイル通信へ切り替えると、システムは下位の接続を再構築します。ネットワーク拡張は通常自動復旧しますが、長時間接続はアプリが再接続を開始する必要があります。ステータスバーにVPNが表示されたまま通信できない場合は、まずClash Plus内で接続を停止し、VPN表示が消えるのを待ってから再起動します。機内モードを何度も切り替えるだけでは設定問題が隠れてしまい、ネットワーク切り替え、DNS、ノードのどれが原因か判断しにくくなります。

オンデマンド接続とバックグラウンド制限

オンデマンド接続はネットワークの変化に応じてVPNを自動接続でき、設定が安定した端末に適しています。初回インストール直後は、誤った設定がネットワーク切り替えのたびに自動復旧して調査を難しくするため、すぐに有効にしないでください。まず手動接続でWi-Fi、モバイル通信、画面ロック、復帰をテストし、必要に応じてオンデマンドルールを有効にします。家庭、職場のWi-Fi、モバイル通信で処理を変える場合は、広すぎる1つのルールに頼らず、ネットワーク条件を明確に設定します。

iOSのバックグラウンド動作はシステムが一元管理するため、アプリ画面を開き続けてもすべての切断を防げるわけではありません。安定性はネットワーク拡張の状態、システムリソース、設定の複雑さ、ネットワーク切り替えに左右されます。高頻度のヘルスチェックはバックグラウンド活動を増やし、複雑なスクリプトや大きすぎるルールセットは設定の読み込みを遅くします。接続がシステムに停止された場合は、まず不要な探査を減らし、ログにメモリ、設定解析、ネットワーク変化の記録がないか確認します。

他のVPN構成との関係

端末には複数のVPN構成を保存できますが、通常は同時に1つの主要トンネルしか有効にできません。企業の端末管理、コンテンツフィルター、DNSアプリ、他のプロキシツールがネットワーク拡張の機能を占有する場合があります。Clash Plusを起動できない場合は、「設定 → 一般 → VPNとデバイス管理」で現在の構成を確認します。ただし企業管理項目を不用意に削除しないでください。個人端末では他のVPNを停止して比較できますが、管理対象端末では組織のポリシーに従います。

Linuxデスクトップ、コマンドライン、サービス運用

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

LinuxデスクトップではClash Verge RevまたはFlClashを選べます。Debian、Ubuntu、Linux Mintとその派生環境は通常debパッケージ、Fedora、Rocky Linux、openSUSEなどはディストリビューションに対応したrpmを使います。クライアントによっては単体実行形式も提供されます。Linuxダウンロード欄へ進む前に、uname -mを実行してアーキテクチャを確認します。x86_64は通常AMD64、aarch64はARM64に対応します。

uname -m
cat /etc/os-release

sudo apt install ./clash-client-amd64.deb
# rpm系ディストリビューションでは、対応するパッケージマネージャーでrpmファイルをインストールします

例にあるファイル名は、実際にダウンロードしたファイルへ置き換えてください。ローカルパッケージは直接解凍してコピーするより、パッケージマネージャーでインストールした方がデスクトップエントリーや依存関係を扱いやすくなります。インストール後にメニューアイコンが表示されない場合は、ターミナルから一度起動してエラー出力を確認します。WaylandとX11では、トレイアイコン、権限通知、自動起動の動作が異なることがあります。トレイに表示されなくてもコアが停止したとは限らないため、プロセス、ポート、ログを併せて確認します。

設定の追加とデスクトップのシステムプロキシ

GUIクライアントでのサブスクリプション追加手順は、他のデスクトップ環境とほぼ同じです。リモートURLを追加し、設定を更新して現在の設定に指定し、ポリシーを選んでからシステムプロキシを有効にします。Linuxのシステムプロキシには全システム共通の単一インターフェースがなく、GNOME、KDE、ブラウザー、ターミナル、バックグラウンドサービスがそれぞれ異なる設定を読む場合があります。デスクトップのスイッチはデスクトップ環境のプロキシ設定に従うアプリへ主に影響し、コマンドラインプログラムやsystemdサービスは通常自動で読み取りません。

ターミナルのテストでは環境変数を一時的に設定できます。より多くのツールに対応するため、大文字と小文字の変数名を併記することもできますが、恒久設定の前にプログラムの動作を確認してください。プロキシ変数を全ユーザーのグローバル環境へ直接書き込まないでください。クライアントが動作していないと、多くのコマンドが失敗します。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export HTTP_PROXY=$http_proxy
export HTTPS_PROXY=$https_proxy

curl -I https://example.com

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY

HTTPプロキシ変数を設定しただけでは、SSHは自動的にClashを経由しません。GitのHTTPSリモートは環境変数を読み取る場合がありますが、SSHリモートでは個別のProxyCommandまたはTUNルーティングが必要です。パッケージマネージャーにも独自のプロキシ設定ファイルがある場合があります。切り分けではアプリごとに確認し、「ブラウザーが正常だからLinuxの全プロセスが制御されている」と判断しないでください。

TUNの権限、ルーティング、DNS

LinuxのTUNでは /dev/net/tun へのアクセスと、ルート、ポリシールーティング、ファイアウォールルールの変更が必要です。GUIクライアントは認証ヘルパーでこれらを処理する場合があります。コマンドラインのコアでは適切なcapabilityが必要になるか、管理されたサービスから起動します。デスクトップクライアント全体をrootで長期間実行するのは望ましくありません。クライアントのサービスモードを優先するか、コアに必要最小限の権限を付与してください。

コンテナ、仮想マシン、Dockerブリッジ、ローカルKubernetesは追加のネットワークセグメントを作成します。自動ルーティングを有効にした際にこれらのセグメントが正しく除外されていないと、コンテナからホストへのアクセス、イメージ取得、クラスター内部通信に問題が起きることがあります。TUNを有効にする前に ip route を記録し、問題発生後にルーティングテーブルを比較します。LAN、コンテナのネットワーク、VPN専用セグメントは、実際の環境に合わせて直接接続または除外を設定します。

ip route
ip rule
ss -lntup | grep -E '7890|9090'
resolvectl status

ディストリビューションによって、systemd-resolved、NetworkManager、従来のresolv.confなど、DNSの管理方式が異なります。ClashのDNS制御は現在の名前解決経路と連携させる必要があります。システムの /etc/resolv.conf がローカルstubを指し、Clashも同じアドレスへ問い合わせを戻すと、ループが発生する可能性があります。ログにDNSタイムアウト、CPU使用率の上昇、大量の重複リクエストが続く場合は、上流nameserverが最終的に到達可能な実DNSを指しているか確認します。

Mihomoコアをサービスとして動かす

デスクトップ環境のないサーバーやルーターでは、Mihomoコアを直接実行できます。設定ディレクトリにはメイン設定と必要なルーティングデータを置き、実行ユーザーに読み取り権限を与えます。起動前にコアの設定検証機能でYAMLを解析できることを確認し、その後systemdで管理します。サービスには明確な作業ディレクトリ、設定パス、再起動ポリシー、ログ出力を設定し、一時ディレクトリから起動しないようにします。

mihomo -t -d /etc/mihomo
mihomo -d /etc/mihomo

サービス運用では、制御ポートとプロキシポートをすべてのNICへ無条件に公開しないでください。本機だけで使う場合はループバックアドレスで待ち受けます。LAN端末へ提供する必要がある場合に限り、allow-lan、待ち受けアドレス、ファイアウォール、制御インターフェースの認証を設定します。リモート制御インターフェースを公開する場合は接続元を制限し、アクセスキーを設定してください。設定を変更したら、まず検証してからサービスをリロードし、すぐに戻せる起動可能な設定を1つ残します。

自動起動とGUIセッションの違い

デスクトップクライアントの自動起動は通常、ユーザーのGUIセッションに依存します。一方、systemdのシステムサービスはOS起動時に動作します。同じコアのインスタンスを両方で起動すると、ポートと設定ディレクトリを奪い合うため併用しないでください。デスクトップのプロキシだけが必要なら、クライアントのログイン時起動を使います。ホスト全体またはLANへ安定したサービスを提供する場合は、独立したコアサービスを使い、GUIは制御画面にとどめます。アップデート前にサービスを停止して設定をバックアップし、アップデート後はまず前景で設定の互換性を確認してから自動起動へ戻します。

システムプロキシ、ルールモード、グローバルモード、TUN

4つの概念の役割

システムプロキシ、TUN、ルールモード、グローバルモードは同じ層の機能ではありません。システムプロキシとTUNは「どの通信をClashへ入れるか」を決め、ルールモードとグローバルモードは「入った後にどう処理するか」を決めます。システムプロキシはOSのプロキシ設定を使い、プロキシ対応アプリをローカルの待ち受けポートへ向けます。TUNは仮想ネットワークインターフェースとルーティングで、より多くの接続を制御します。通信がコアに入った後、ルールモードはルール一覧に従って直接接続、プロキシ、ブロックを選び、グローバルモードは大半の接続を指定した1つのポリシーへ渡します。

この2層を理解すると、よくある誤判断を避けられます。ブラウザーの通信ログがない場合は、接続がClashへ入っていない可能性があるため、システムプロキシまたはTUNを確認します。ログに接続があるのに結果が想定と違う場合は、ルール、ポリシーグループ、ノードを確認します。グローバルモードへ切り替えても、すでにコアへ入った通信の処理が変わるだけです。システムプロキシをまったく読み取らないプログラムを突然制御することはできません。

ルールが順番に照合される理由

Clashのルールは通常、上から順に確認し、最初にヒットした時点で照合を止めます。そのため、具体的なルールを広範なルールより前に置き、最後にMATCHをフォールバックとして使います。ドメインルール、ルールセット、IP範囲、プロセスルールは同時に存在できますが、DNSを解決するか、IP照合をスキップするかによって性能と結果が変わります。特定のサイトが誤ったポリシーへ進む場合は、ログからドメイン、宛先アドレス、ヒットしたルールを確認して設定へ戻り、無闇に重複ルールを追加しないでください。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-KEYWORD,example,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

例では、より具体的なドメインサフィックスのルールをキーワードルールより前に置き、プライベートアドレスを明示的に直接接続し、最後にMATCHでPROXYポリシーグループへ渡しています。実際の設定では、ポリシーグループ名を proxy-groups の定義と完全に一致させます。no-resolve は、そのIPルールを照合するときにドメインの追加解決を発生させない指定であり、DNSモジュール全体を無効にするものではありません。

ポリシーグループはノード一覧と同じものではない

ノードは具体的な接続パラメーターを定義し、ポリシーグループは複数のノードまたは他のポリシーから選択します。selectグループは手動選択、url-testグループはテスト結果による選択、fallbackグループは利用可能な候補へ切り替え、load-balanceグループはアルゴリズムで接続を分配します。日常のトラブル解決では、まずselectでノードを固定してください。自動ポリシーはヘルスチェックにより結果が変わるためです。固定ノードが安定してから、自動グループのテスト先、間隔、許容差が適切か確認します。

ポリシーグループは他のポリシーグループを参照できます。よくある構成では、業務ルールが「海外サイト」「ストリーミング」「ダウンロード」などの業務グループを指し、業務グループが地域グループを参照し、地域グループが最終的にノードを選びます。階層が深いと、画面で選んだものが最終ノードとは限りません。参照チェーンを1層ずつ展開し、各グループに利用可能な出口があるか確認します。プロジェクトとコアの関係は、Clashオープンソースエコシステムの関係 を参照してください。

DNS制御、Fake IP、実アドレス

DNSモジュールはドメインをアドレスへ変換するだけでなく、ルール判定や通信のマッピングにも関わります。Fake IPモードでは予約アドレスを先に返し、コアがマッピングから元のドメインを復元するため、ルール照合に適し、アプリが独自に迂回するのを抑えられます。LAN探索、固定DNS、特殊な検証、返されたアドレスの直接記録に依存する一部のアプリはFake IPに対応できない場合があります。その場合は除外リストへ追加するか、比較のためredir-hostへ切り替えます。

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

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

この断片はフィールド構造を示すもので、ノード、ポリシーグループ、ルールを含まないため、単独で接続できる完全な設定ではありません。待ち受けアドレスを本機に限定しており、1台の端末で項目を理解する用途に適しています。実際の利用では、ネットワークの到達性、プライバシー要件、内部DNSの必要性に応じて上流DNSを選び、機械的にコピーしないでください。IPv6に対応していないネットワークで設定がIPv6アドレスを優先すると、ドメインは解決できても接続がタイムアウトすることがあります。システムネットワーク、DNSの応答、ClashのIPv6設定を併せて確認します。

日常の動作方式を選ぶ

デスクトップ環境では、まずルールモードとシステムプロキシを使うと、制御範囲が明確で終了時の復元も簡単です。コマンドライン、UDP、プロキシに従わないアプリを扱う場合は、ルールモードとTUNへ切り替えます。モバイル端末は通常、システムVPNインターフェースで通信を制御するため、本質的にはTUNに近い仕組みです。ただし出口はルールで決まります。グローバルモードは「現在のノードで接続を確立できるか」を判断するのに適していますが、すべての問題に対する最終解決策ではありません。

設定の保守とよくあるトラブル解決

まず障害が発生している層を判断する

効果的なトラブル解決では、層ごとに範囲を絞ります。第1層はクライアントが動作し、コアが起動し、ポートが待ち受けているか。第2層は通信がClashへ入っているか。第3層はルールが想定したポリシーにヒットしているか。第4層は選択したノードへ接続できるか。第5層は対象サイト、DNS、アプリのプロトコルに追加の制限がないかです。Webページが開けないからといって、クライアント、サブスクリプション、DNS、モードを同時に変えないでください。復旧しても本当の原因が分からなくなります。

まずクライアントのホーム画面でアクティブな設定が表示されているか確認し、次にログを見ます。アクセス記録がまったくない場合は、システムプロキシ、TUN、VPN権限、アプリ独自のプロキシを確認します。接続記録はあるがルールが誤っている場合は、ルールの順序とポリシーグループを確認します。接続記録があり、正しいノードにヒットしているのにタイムアウトする場合は、別のノードと別のネットワークで試します。特定のドメインだけ失敗する場合に、DNS、ドメインルール、対象サービスの状態を確認します。

サブスクリプション更新失敗と設定読み込み失敗

サブスクリプションの更新失敗は、通常、ネットワークエラー、HTTPエラー、内容の解析エラーに分かれます。タイムアウトや接続拒否はURLへ到達できないことを示します。認証失敗や権限エラーではサブスクリプションの状態を確認します。YAMLではなくHTMLが返る場合は、ログイン画面、ゲートウェイによる遮断、誤ったリダイレクトがよくある原因です。ブラウザーで開けても、クライアントとリクエスト条件が完全に同じとは限りませんが、URLの誤りと基本ネットワークの問題を先に除外できます。URLをコピーするときは、前後の空白、改行、チャットアプリが追加したエスケープ文字に注意してください。

設定解析エラーは通常、ログに行番号またはフィールド名として表示されます。YAMLでよくある問題は、インデント階層の誤り、コロン後のスペース不足、同じキーの重複定義、リスト記号の位置ミス、存在しないポリシーグループの参照です。エラーが出たら、報告された行から上方向へ所属する構造を確認します。本当のインデントミスが数行前にある場合があるためです。直近の利用可能な設定へ戻してから、変更を小さな単位に分けて少しずつ追加してください。

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

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,PROXY

この構造では、rulesが参照するPROXYとポリシーグループ名が一致しています。名前を別の文字列へ変更する場合は、ルールも同時に変更する必要があります。YAMLで特殊文字を含む名前は引用符で囲めますが、同じ参照名は完全に一致させます。フィールドの体系的な説明は 設定ファイルの構造解説 を参照してください。

ポート使用中とコアの起動失敗

コアは起動後、混合プロキシ、HTTP、SOCKS、DNS、制御ポートを待ち受けます。別のClashインスタンス、古いプロセス、他のプロキシソフトが同じポートを使っていると、新しいインスタンスは起動に失敗します。Windowsではリソースモニターまたはコマンドライン、macOSとLinuxでは lsof または ss で待ち受けポートを確認できます。使用中のプロセスを見つけたら、まず身元を確認してください。正体の分からないシステムサービスを直接終了しないでください。古いクライアントを閉じるか、現在の設定に未使用のポートを指定します。

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

# Linux
ss -lntp | grep 7890

ポートが使用されていないのにコアが起動しない場合は、設定ファイルの権限、作業ディレクトリ、ルールデータベースの存在、クライアントが呼び出すコアのパスを確認します。セキュリティソフトによるコアファイルの隔離、システムアップデート後のサービス権限の変化、アプリの移動でも同じ症状が出ます。GUIに「起動に失敗しました」としか表示されない場合は、詳細ログを開くか、ターミナルからクライアントを起動して完全なエラーを取得します。

ブラウザーは正常だがターミナルやアプリが失敗する

ブラウザーが正常なら、ノードと少なくとも1つのプロキシ入口が利用可能であることは分かりますが、ターミナルが制御されているとは限りません。ターミナルプログラムはシステムプロキシを読まず、環境変数やアプリ単位の設定が必要な場合があります。ゲームや一部のストアアプリはUDPまたは直接ソケットを使うためTUNが必要です。ブラウザーに独自のプロキシ拡張が入っている場合、Clashのシステムプロキシを使っていない可能性もあります。テストした各リクエストがログに出ているか比較してください。

ターミナルの起動ファイルに古いプロキシ変数が残っていないか確認します。変数が終了済みクライアントのポートを指していると、コマンドは失敗し続けます。WindowsではPowerShellの環境変数、macOSとLinuxではShell設定ファイルと現在のセッションを確認します。Git、npm、パッケージマネージャーなどが独自のプロキシ設定を保存していることもあります。詳しい分岐は システムプロキシが効かない場合の確認方法 を参照してください。

IPにはアクセスできるがドメインで失敗する

この症状は通常DNSを示します。まずClashのDNSが有効か、待ち受けポートが使用中でないか、上流サーバーへ到達できるか確認します。TUNモードではDNSハイジャックが有効か、システムの問い合わせがループしていないかも確認します。内部ドメインだけ失敗する場合、パブリックDNSが企業や家庭内のレコードを知らないことが原因です。対象ドメインをローカル解決に残してください。一部のアプリだけ失敗する場合は、Fake IPとの互換性と除外ルールを確認します。

システムのDNSキャッシュを消去しても古いレコードを処理できるだけで、誤った上流DNSやルールは修正できません。キャッシュの更新を繰り返すだけに頼らないでください。比較テストではClashのDNSを一時的に無効にして、システムの名前解決へ戻せます。すぐに正常化した場合は、enhanced-mode、nameserver、fallback、nameserver-policy、IPv6を順番に確認します。無効にしても失敗する場合は、システムネットワークまたはルーターのDNSを調べます。

TUNを有効にするとLANまたはネットワーク全体が切断される

まずTUNを無効にし、システムプロキシモードが正常か確認します。無効にして復旧するなら、ノードと基本設定はおそらく正常で、問題はルーティング、仮想NIC、DNS、権限に絞られます。他のVPN、仮想マシン、コンテナネットワーク、企業フィルターがないか確認します。プライベートアドレスは直接接続にし、特殊な内部ネットワークは除外へ追加します。Windowsではサービスモードと仮想アダプター、macOSではVPNとフィルタ、Linuxではルーティングテーブル、ポリシールーティング、ファイアウォールを重点的に確認します。

TUNの失敗後もシステムがネットワークへ接続できない場合は、まずクライアントを通常の手順で終了し、残ったルート、システムプロキシ、DNSを確認します。モバイル端末ではVPNを停止し、システムのVPN表示が消えてからネットワークへ再接続します。デスクトップでは最初から仮想NICを削除しないでください。クライアントのサービスが再作成する可能性があり、他のソフトのアダプターまで削除すると問題が広がります。まずクライアントで機能を無効にし、その後に対応するサービスコンポーネントを削除します。

サブスクリプション更新後に以前の選択が失われる

サブスクリプション提供元がノード名、ポリシーグループ、ルール構造を変更することがあります。クライアントが保存した選択は通常名前で関連付けられるため、名前が変わると既定項目へ戻ります。ローカルオーバーライドを使っている場合も、古いグループ名の参照が無効になる可能性があります。更新後はまずポリシーグループが残っているか確認し、次にオーバーライドのログを確認します。サブスクリプションキャッシュを長期的に直接編集しないでください。次回更新で上書きされます。

クライアントを移行する際は、サブスクリプションURL、ローカル設定、オーバーライドスクリプト、ユーザーの選択を分けてバックアップします。クライアントごとに設定ディレクトリ、スクリプト機能、ポリシーの保持方法が異なるため、古いプログラムのフォルダー全体をコピーするだけでは不十分です。旧クライアントの移行手順は、旧クライアント終了後の設定保持と代替ソフトの選び方 を参照してください。

保守しやすい設定更新フローを作る

安定した設定には、直近で利用できたバックアップを1つ残し、ローカル変更を説明可能な範囲に抑えます。サブスクリプション更新前に、現在のポリシーと重要なオーバーライドを記録します。更新後は設定の読み込み、DNS、直接接続サイト、プロキシサイト、LANを順番に確認します。ルーティングデータの更新とクライアントの更新は分けて行うと、問題の発生源を判断しやすくなります。GeoIPとGeoSiteの用途、参照、読み込み問題は GeoIPとGeoSiteの使い方 を参照してください。

トラブル解決中は、接続とルールの情報が見えるレベルまでログを上げ、問題が解決したら通常レベルへ戻します。大量のファイルが長期間生成されるのを防ぐためです。ログを共有する際は、サブスクリプションURL、制御キー、ノードの認証情報、個人に関するドメイン記録を削除してください。分類が分からず調査を続ける場合は、よくある質問で基礎知識、インストールと設定、使い方、トラブル解決の順に検索できます。

すべてのプラットフォームで、基本的な判断手順は同じです。まずソフトウェアと設定が動作しているか確認し、次に通信が入っているかを確認します。その後、ルール、ポリシー、ノードを確認し、最後にDNSとプラットフォームの権限を調べます。この順序で証拠を残し、変数を減らす方が、何度も再インストールするより安定した結果を得やすくなります。クライアントやインストーラーを選び直す場合は、Clashクライアントのダウンロードページへ戻り、対象プラットフォームの章に沿って権限と接続設定をやり直してください。