始める前に
共通の準備：クライアント、サブスクリプション、プロキシモード
基本接続だけを一度設定したい場合は、より短いクイックスタートガイドからお読みください。このページでは、各プラットフォームのダウンロードとインストールから、サブスクリプション、システムプロキシ、TUN、権限、プラットフォーム固有の制限まで体系的に扱います。特定の問題を調べるときは、最初から読む必要はありません。上の目次から該当する章へ移動できます。クライアントはダウンロードセンターでプラットフォーム別に選び、デスクトップ・モバイルともにまずClash Plusを検討してください。その他の選択肢とメンテナンス状況は、ダウンロードページの最新一覧を確認してください。
クライアント、コア、設定ファイルを区別する
Clashの利用には、互いに独立した3つの要素があります。クライアントはウィンドウ、メニュー、スイッチ、サブスクリプション管理を提供します。mihomoなどのコアはポートの待受、DNS解決、ルール判定、接続確立を担当します。設定ファイルにはプロキシ情報、プロキシグループ、ルール、DNS、TUNのパラメーターが記録されます。画面クライアントを変更しても、サブスクリプションが変わるわけではありません。同じ互換設定を読み込めば、通常はルール判定の結果も変わりません。逆に、クライアント画面が正常に開いてもコアが起動していなければ、システムプロキシが設定済みでも有効な転送は行われません。
サブスクリプションURLは通常、サービス提供元が発行します。クライアントはURLを取得すると、YAML設定または変換済みの設定内容をダウンロードします。読み込みに成功したからといって、プロキシの接続先まで利用できるとは限りません。変数を減らすため、初回設定ではサブスクリプション本来のルールを残し、大量のカスタムルール追加、DNSの上書き、待受ポートの変更はすぐに行わないことをおすすめします。基本接続が安定してから、設定を一項目ずつ追加してください。毎回一箇所だけ変更すれば、トラブル時に戻しやすくなります。
サブスクリプション追加前の確認
URLをコピーするときは、前後の空白、改行、チャットアプリが付けた句読点が混入していないか確認します。URLは個人用の設定入口なので、公開ページやスクリーンショットに載せないでください。サービス提供元が「ワンクリック追加」と通常のサブスクリプションURLを用意している場合は、クライアントが明確に対応している方法を優先します。通常のURLは「サブスクリプション」「設定」または「Profiles」画面に貼り付けます。追加後は、設定名、プロキシグループ、ルールが表示されることを確認してから、現在の設定として有効化します。クライアントにURLを保存しただけで設定を有効化していない状態は、初回インストール後によくある見落としです。
システムプロキシとTUNの選び方
システムプロキシは、ブラウザー、デスクトップの通信アプリ、OSのプロキシ設定を参照するアプリに適しています。クライアントは通常、HTTPとSOCKSの待受アドレスを書き込みます。一般的なローカルアドレスは 127.0.0.1 で、ポートは設定内の mixed-port、port、socks-port によって決まります。権限要件が低く、オン・オフが分かりやすい一方、ゲーム、コマンドライン、ストアアプリ、独自ネットワークスタックを持つソフトはシステムプロキシを無視する場合があります。
TUNモードは仮想ネットワークインターフェースを通じて、より広範なシステム通信を取り込みます。システムプロキシを参照できないプログラムにも適しており、TCP、UDP、DNSリクエストをまとめて処理できます。その反面、高いシステム権限が必要で、他のVPN、仮想マシン、コンテナネットワーク、セキュリティソフト、企業ネットワーク部品と競合することがあります。初回はまずシステムプロキシを確認し、必要に応じてTUNを有効にしてください。複数の通信取り込みツールを同時に動かすのは避けましょう。モバイル端末のVPNスイッチは動作上TUNに近く、通常はこの種のネットワーク拡張を同時に一つしか有効にできません。
| 動作方式 | 適した用途 | 確認する点 |
|---|---|---|
| システムプロキシ | ブラウザー、一般的なデスクトップアプリ、日常的なルール設定 | アプリがシステムプロキシを参照するか、終了時に設定を復元するか |
| TUNまたはモバイル端末のVPN | ゲーム、コマンドライン、UDP、システムプロキシを無視するアプリ | 管理者権限、ルーティング競合、DNSの取り込み、他のVPN |
| アプリ内プロキシ | 特定のツールだけをローカルのSOCKSまたはHTTPポート経由にしたい場合 | プロキシプロトコル、待受アドレス、ポートをクライアントと一致させる |
再現可能な確認手順を作る
どのプラットフォームでも、同じ順序で確認できます。まずクライアントのコアが実行中か確認し、次に現在の設定が選択されているか確認します。その後、プロキシモードがルール、グローバル、ダイレクトのどれかを確認し、対象リクエストが接続ログでどのルールとプロキシグループに一致したかを調べます。最後に、プロキシの接続先自体が利用できるかを判断します。ウェブページが開くかどうかだけでは、DNS、ルール、接続先、システムへの取り込みのどの層に問題があるか分かりにくいものです。接続ログとログ出力の方が信頼できる根拠になります。関連するエラーフィールドはClashのログエラーを特定する方法も参照してください。
デスクトッププラットフォーム
Windows：インストール、サブスクリプション、システム通信の取り込み
Windowsでは、Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、アーカイブ用途のClash for Windowsを選択できます。新規設定では、現在も保守されmihomoに対応しているクライアントを優先してください。ダウンロード前に「設定 → システム → バージョン情報」で端末のアーキテクチャを確認します。一般的なPCの多くはx64です。ARMプロセッサーを搭載していることが明確な端末だけARM版を選びます。インストーラーとポータブル圧縮ファイルは使い方が異なります。インストーラーはプログラムフォルダーとショートカットを作成しますが、ポータブル版は固定フォルダーに完全に展開してから実行してください。圧縮ソフトのプレビュー画面から直接起動してはいけません。
インストールと初回起動
Windowsダウンロードエリアからインストールファイルを取得したら、まず古いClashクライアントを終了し、同じ待受ポートの競合を避けます。インストールウィザードを完了してクライアントを起動します。Windowsのファイアウォール確認が表示された場合は、LAN共有が本当に必要なときだけ該当するネットワークの種類を許可してください。単独利用なら、コアの待受アドレスはローカルループバックのままで問題ありません。「接続できるようにする」ために、すべてのネットワークインターフェースを開放する必要はありません。アプリは開くのにコアが起動しない場合は、古いクライアントがタスクトレイで動作していないか確認し、ポートの使用状況とコアのログを調べます。
ポータブル版は、一時ダウンロードフォルダー、同期ストレージの競合フォルダー、厳格な権限で保護された場所には置かないでください。クライアントは通常、自身のデータフォルダーに設定、キャッシュ、ログを書き込みます。書き込みできないパスでは、設定を追加しても消える、更新に失敗する、起動のたびに初期状態へ戻るといった症状が現れます。初回起動後、クライアント設定でデータフォルダーの場所を確認し、長期利用する設定は自分で管理できる場所にバックアップしてください。
サブスクリプションを追加してプロキシグループを選ぶ
「設定」または「サブスクリプション」画面でURLからの追加を選び、サブスクリプションURLを貼り付けて取得が完了するまで待ちます。新しい設定が表示されたら、有効化または現在の設定に指定します。続いて「プロキシ」画面を開き、モードを「ルール」にします。ルールモードでは設定内のルールを上から順に判定し、最初に一致した時点で終了します。一致後に実際の出口を決めるのがプロキシグループです。初回確認では、誤って「ダイレクト」にしたり、影響を理解しないまま「グローバル」を常用したりしないでください。ルールモードはLAN、普段使う中国本土のサービスをダイレクトにし、指定先だけをプロキシ経由にできるため、日常利用の標準設定として適しています。
プロキシグループが手動選択型の場合は、グループ内で利用可能な項目を明示的に選びます。自動テスト、フォールバック、負荷分散型の場合は、設定された検査と切り替えのロジックが処理します。クライアントに表示される検査結果は、指定されたテスト先への接続だけを示すもので、ダウンロード速度やすべてのサイトでの実際の体感速度を意味しません。この違いについてはノード遅延テストの仕組みを参照してください。
システムプロキシを有効にする
コアが動作していることを確認してから「システムプロキシ」を有効にします。これによりWindowsのプロキシ設定がクライアントのローカルポートを指すようになります。ブラウザーで対象サイトを開き、クライアントの接続画面で該当ドメイン、適用ルール、プロキシグループを確認します。ブラウザーは使えるのに特定のコマンドラインプログラムが使えない場合、サブスクリプションの問題ではなく、そのプログラムがWindowsのシステムプロキシを参照していない可能性があります。プログラムに HTTP_PROXY、HTTPS_PROXY、SOCKSアドレスを個別設定するか、必要に応じてTUNを使用します。
set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890
curl https://example.com上の例は現在のコマンドプロンプトウィンドウでのみ有効です。ポートはクライアントに表示される実際の混合ポートへ置き換えてください。PowerShell、Git、パッケージマネージャー、開発ツールにはそれぞれ独自のプロキシ設定がある場合があります。ブラウザーが使えるからといって、すべてのプログラムが自動的に追従すると考えてはいけません。トラブル対応では、まずツール自身の設定を確認し、その後で環境変数やTUNが必要か判断します。
TUNモードと権限
ゲーム、ストアアプリ、UDP、システムプロキシを参照しないソフトを取り込む場合は、他のVPNツールを終了し、管理者権限でクライアントを起動してからTUNを有効にします。初回は仮想NICやネットワークコンポーネントのインストールが求められることがあります。完了後、デフォルトルートとDNSがクライアントに取り込まれているか確認します。TUNを有効にした途端にシステム全体がオフラインになった場合は、まずTUNを無効にし、仮想マシンのブリッジ、コンテナネットワーク、アクセラレーター、セキュリティソフトのネットワークフィルターが同時に動作していないか確認します。異常な状態で複数の取り込みツールを何度も切り替えないでください。ルーティングテーブルとDNSの状態がさらに判断しにくくなります。
Windows特有の問題
休止状態から復帰した後に接続が切れた場合は、すぐにクライアントを再インストールせず、まずサブスクリプションの状態を更新してからコアを再起動します。システム時刻のずれはTLS接続に影響するため、自動時刻同期が正常か確認してください。LAN共有では、設定で「LAN接続を許可」を有効にし、待受アドレスをクライアントが許可するLAN向けの形式に変更します。ファイアウォールでは必要なポートだけを許可してください。他の端末からは、このPCのLANアドレスを指定し、127.0.0.1は指定しません。共有が終わったら入口を閉じ、信頼できないネットワークでプロキシポートを公開しないようにします。
デスクトッププラットフォーム
macOS：チップのアーキテクチャ、システムプロキシ、ネットワーク拡張
macOSではダウンロード前にチップのアーキテクチャを確認します。左上のAppleメニューから「このMacについて」を開き、Appleチップと表示される場合はApple SiliconまたはARM版、Intelプロセッサーと表示される場合はx64版を選びます。選択肢にはClash Plus、Clash Verge Rev、FlClash、アーカイブ状態のClashX Metaがあります。新規インストールでは保守中のクライアントを優先し、macOSダウンロードエリアからチップに合ったファイルを取得してください。アーキテクチャを間違えると、アプリが開かないか、追加の変換レイヤーが必要になる場合があります。
アプリのインストールと初回許可
一般的には、ディスクイメージを開いてアプリを「アプリケーション」フォルダーへドラッグし、そのフォルダーから起動します。ディスクイメージから直接実行し続けるのは避けてください。アプリの更新、補助コンポーネント、データフォルダーへの書き込みが想定どおり行われない場合があります。初回起動時にシステムの確認が表示されたら、アプリの入手元とダウンロード経路を確認し、システムが案内する安全な手順で進めます。システムプロキシ、ネットワーク拡張、TUNを利用する場合、macOSから管理者パスワードを求められることがあります。これはシステムネットワーク設定の変更に必要な許可です。
起動後は、システムプロキシとTUNを同時に有効にしないでください。設定画面からサブスクリプションURLで設定を追加し、プロキシグループとルールの読み込みが完了するまで待ちます。現在の設定に指定してから、ルールモードを選択します。追加後に設定項目は一つだけ表示され、プロキシグループが見えない場合は、ダウンロード内容の異常、サブスクリプション変換結果の非互換、または古い設定が選択されたままの可能性があります。設定の更新日時とクライアントログを確認し、更新ボタンを繰り返し押すだけにしないでください。
システムプロキシの適用範囲
macOSのシステムプロキシは、現在のネットワークサービスにあるHTTP、HTTPS、SOCKS設定へ書き込まれます。ブラウザーやシステムのネットワークフレームワークに従う多くのアプリはこれらの値を読み取りますが、ターミナルコマンド、開発ツールの一部、独自ネットワークスタックを持つアプリは追従しない場合があります。システムプロキシを有効にしたら、「システム設定 → ネットワーク → 現在のネットワーク → 詳細 → プロキシ」で各項目がローカルポートを指しているか確認できます。通常はここを手動で変更する必要はなく、クライアントがプロキシを無効にした際に復元します。
ターミナルツールで必要な場合は、現在のセッションだけに環境変数を設定できます。ポートはクライアントの実際の混合ポートに合わせてください。ターミナルを終了すると設定は自動的に無効になります：
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
curl https://example.comGit、Homebrew、その他のツールに個別のプロキシアドレスが保存されている場合は、内部設定も確認します。古いアドレスが現在の環境変数より優先され、「ブラウザーは正常だがターミナルだけ失敗する」状態になることがあります。トラブル対応では env | grep -i proxy で現在の環境を確認し、各ツールに追加パラメーターが保存されていないか調べます。
TUN、ネットワーク拡張、DNS
システムプロキシを参照しないアプリには、クライアントのTUNまたはネットワーク拡張モードを使用できます。初回有効化では通常、システムの許可が必要です。クライアントによっては、バックグラウンドでルートを調整する補助サービスをインストールします。許可後すぐにスイッチが戻る場合は、システム設定のネットワーク拡張許可、クライアントログ、補助サービスの状態を確認してください。企業管理端末では構成プロファイルに制限され、一般ユーザー権限で組織のポリシーを上書きできないことがあります。その場合は端末管理の要件に従い、繰り返しインストールしないでください。
macOSで複数のVPN、フィルター、コンテンツ検査ツール、仮想NICを同時に動かすと、ルートの優先順位が競合することがあります。接続は確立するのに通信できない、特定ドメインが誤ったアドレスへ解決される、LAN機器にアクセスできない、スリープ復帰後にオフラインになる、といった症状が現れます。まず他のネットワーク取り込みツールを終了し、Clashだけを残します。コアを再起動してDNSを確認し、単独で正常に動作することを確かめてから他のソフトを一つずつ戻します。これで競合している層を特定できます。
スリープ、ネットワーク切り替え、ローカルサービス
Macがスリープから復帰したり、Wi-Fi、有線、スマートフォンのテザリングを切り替えたりすると、ローカルIP、デフォルトルート、DNSが変わることがあります。接続が古い状態で止まった場合は、まずコアを一度停止して再起動し、必要ならシステムプロキシもオフ・オンします。ローカル開発サービスでは、localhost、127.0.0.1、LANセグメントは通常ダイレクトにします。カスタムルールがこれらを早い段階でプロキシへ送ると、ローカルページ、データベース、LAN機器に届かなくなります。LANのダイレクトルールを一般的なプロキシルールより前に置いてください。
メニューバーのアイコンを終了した後、すべてのウェブページが利用できなくなった場合は、システムプロキシが復元されていない可能性が高いです。クライアントを再起動してシステムプロキシを無効にするか、現在のネットワークサービスのプロキシ設定で該当項目を解除します。特定のブラウザーだけ異常なら、ブラウザー拡張機能またはブラウザー独自のプロキシ設定を確認します。システム層とアプリ層に異なるローカルポートを同時に保存しないでください。ポート変更後に古い値が残りやすくなります。
モバイルプラットフォーム
Android：アプリのインストール、VPN権限、バックグラウンド動作
AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardを選択できます。インストール前にAndroidダウンロードエリアからクライアントを選びます。インストールパッケージはARM64、ARM、汎用版に分かれる場合があります。近年のスマートフォンやタブレットの多くはARM64で、他のアーキテクチャが必要なのは古い端末に限られます。判断できない場合は、ダウンロードページの汎用ビルドを優先するか、システム情報アプリでABIを確認してください。アーキテクチャが合わない場合、通常はサブスクリプションやネットワークではなく、インストール時に対応していない旨が表示されます。
インストールとVPNの許可
ダウンロードが完了したら、Androidの手順に従ってファイルを開きます。現在のブラウザーやファイル管理アプリに一度だけインストール許可を求められる場合があります。完了後は安全上の判断に応じて許可を無効にしてください。初回起動して接続を開始すると、AndroidにVPN接続のリクエストが表示されます。許可すると、通常はステータスバーにVPNアイコンが表示されます。同時に実行できるVPNサービスは通常一つだけなので、他のVPN、企業トンネル、ファイアウォール、ローカルフィルターアプリが停止するか、逆にClashの接続を妨げることがあります。
モバイル端末にはデスクトップのシステムプロキシのような全体設定スイッチがなく、クライアントは通常Android VPN APIで仮想インターフェースを作成します。接続ボタンが接続済みを示していても、成功しているのはインターフェースの確立だけです。現在の設定、ルールモード、プロキシグループも確認してください。設定画面でURLからサブスクリプションを追加し、更新後にその設定を選択します。サブスクリプションの取得に既存のネットワーク経路が必要な場合は、利用可能なネットワーク環境で初回追加を完了してからプロキシを起動します。
アプリ別プロキシとバイパス設定
Androidクライアントにはアプリ別プロキシ機能が用意されていることが多く、「選択したアプリのみプロキシ」または「選択したアプリをバイパス」を選べます。2つのモードは意味が逆なので、切り替えたらリストを再確認してください。ブラウザーだけをプロキシに通す設定はテストに適していますが、ブラウザーから外部アプリを呼び出す際に経路が一致しないことがあります。銀行アプリ、LAN制御アプリ、VPNに敏感なアプリをバイパスする場合は、バイパス後に現在のネットワークへ直接接続することを理解しておきます。「VPNを常時オン」や「VPNなしの接続をブロック」が有効なら、バイパス動作はシステムポリシーの影響も受けます。
ルールモードとアプリ別プロキシは二段階で判定されます。まずアプリがVPNへ入るかを決め、入った後にClashのルールがDIRECT、PROXY、REJECTを決定します。アプリをバイパスリストに入れると、Clashのドメインルールを変更してもそのアプリには影響しません。「ルールがなぜ効かないのか」を調べるときは、まずそのアプリの通信がクライアントの接続ログに入っているか確認し、その後でルールの順序を確認します。
バックグラウンド制限とバッテリー設定
一部のAndroidシステムでは、画面ロック、タスクの消去、省電力モードによってVPNクライアントが制限されます。起動直後は使えるのに、しばらくロックすると接続が消え、アプリを開き直すと復帰するのが典型的な症状です。システムのバッテリー・バックグラウンド管理でクライアントの継続動作を許可し、自動消去の対象から外してください。メーカーによってメニュー名は異なりますが、目的は同じです。フォアグラウンドVPNサービス、バックグラウンド通信を許可し、画面消灯後にプロセスを強制終了しないようにします。
サブスクリプションの自動更新もバックグラウンド通信に依存します。アプリを開いたときだけ更新される場合は、更新間隔、バックグラウンドデータの許可、省電力制限を確認します。更新に失敗した場合は、削除して再追加するより、前回成功した設定を残す方が安全です。利用可能な設定を一つだけ削除すると、サブスクリプションを再取得するためのネットワーク経路を失うことがあります。
DNS、IPv6、テザリング共有
AndroidのプライベートDNS、クライアント内蔵DNS、通信事業者のDNSが同時に名前解決へ関与することがあります。一部のドメインだけ失敗する場合は、比較のため一時的にプライベートDNSを無効にし、設定内の enhanced-mode、上流リゾルバー、Fake-IP除外項目を確認します。IPv6、プライベートDNS、TUNスタック、ルールを同時に広範囲で変更しないでください。どれが影響したのか判断できなくなります。IPv6環境で「一部のアプリは正常だが一部はタイムアウトする」場合は、クライアントがIPv6を取り込んでいるか、設定に対応するルールがあるかを確認します。
スマートフォンでテザリングを有効にしても、接続した端末がスマートフォンのVPNを自動的に経由するとは限りません。共有できるかどうかは、Androidの実装、クライアントの機能、ルーティング権限に左右されます。スマートフォン自身が正常にアクセスできるだけでは、テザリング先もルール設定されるとは判断できません。安定した共有が必要なら、各端末に個別にクライアントをインストールするか、透過プロキシに明確に対応したゲートウェイ構成を利用してください。LANへのアクセスに失敗する場合は、プライベートアドレス帯がダイレクトになっているかも確認します。
モバイルプラットフォーム
iOS：App Storeからのインストール、サブスクリプション追加、オンデマンド接続
iPhoneとiPadでは、iOSダウンロードエリアからClash PlusのApp Storeページへ移動できます。クライアント公式サイトは clashplus.io です。インストール後、初回接続時にVPN設定の追加を求められます。システムで許可すると、クライアントがネットワーク拡張を作成できるようになります。iOSで同時に有効にできるVPNは通常一つだけです。既存の企業VPN、個人VPN、コンテンツフィルターと入れ替わることがあります。
サブスクリプションを追加して設定を有効にする
サブスクリプションURLをコピーし、クライアントの設定またはサブスクリプション画面でURLから追加を選びます。貼り付け時は、チャットアプリの省略記号、空白、改行が混入しないよう注意してください。保存後に更新を実行し、設定にプロキシグループとルールが表示されることを確認してから、現在の設定に指定します。Safariからクライアントを直接起動できるURLもありますが、手動貼り付けの方が完全なURLを確認しやすくなります。遷移後に新しい設定が追加されない場合は、アプリ内でURLから追加し、形式エラーやネットワークエラーが表示されていないか確認します。
接続を開始したら、まずルールモードを選択します。Safariでテストしながら、クライアントの接続ログを確認してください。ウェブページが想定したプロキシグループを通らない場合は、プロキシグループを何度も切り替える前に、ドメインがどのルールに一致したかを調べます。Clashのルールは設定順に上から下へ判定され、最初に一致した時点で終了します。後ろのルールが、すでに一致した結果を上書きすることはありません。DOMAIN、IP-CIDR、GEOSITE、MATCHの違いを理解したい場合は、Clashのカスタムルールと判定順序を参照してください。
オンデマンド接続とシステムネットワークの切り替え
オンデマンド接続に対応するクライアントは、モバイルデータ通信や指定したWi-Fiなど、ネットワーク状態に応じてVPNを自動起動できます。設定前に手動接続して安定性を確認し、その後条件を少しずつ追加してください。条件が広すぎると家庭内LANでも常に通信を取り込み、条件同士が競合すると接続と切断を頻繁に繰り返します。信頼できるWi-Fiでは自動接続したくない場合、毎回手動で切るのではなく、クライアントのネットワーク例外を使用します。
Wi-Fiからモバイルデータ通信へ切り替えると、iOSは基盤インターフェースを再構築するため、既存の接続が短時間停止するのはよくある現象です。長時間復帰しない場合は、VPN設定を削除せず、クライアントを停止して再起動します。機内モード、低データモード、システムレベルのネットワーク制限もバックグラウンド接続に影響します。問題を判断するときは、まず通常のネットワーク自体が使えることを確認してからクライアントを起動し、通信事業者やWi-Fiの障害をサブスクリプションの問題と取り違えないようにします。
DNSとLANアクセス
iOSではDNSリクエストをネットワーク拡張が処理できますが、具体的な動作はクライアントの実装と設定によって異なります。Fake-IPモードでは、まず予約済みアドレスを返し、接続時にマッピングを使ってドメイン名を復元するため、ルールマッチングに適しています。一部のLAN機器、プリンター、キャストサービス、特殊なアプリが実際のLAN名前解決を必要とする場合は、Fake-IPの除外リストに追加するか、LANドメインを直接解決するよう設定してください。変更前に元の設定を記録し、明確な異常が確認されたドメインだけに例外を追加します。
家庭用ルーター、ネットワークストレージ、キャスト機器へアクセスする場合は、プライベートアドレス帯とローカルドメインをダイレクトにします。代表的なプライベートネットワークは 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 です。設定内の早い段階にある一般ルールがこれらをプロキシへ送ると、ローカル機器がタイムアウトします。ルールを調整したら接続を再確立し、DNSマッピングと既存セッションをまとめて更新します。
バックグラウンド動作とシステム制限
iOSはバックグラウンドタスクを統合管理するため、クライアント画面を閉じても、確立済みのVPNネットワーク拡張が停止するとは限りません。動作中かどうかは、システムのステータスバー、コントロールセンター、クライアントの接続状態で確認します。逆に、アプリスイッチャーから画面を終了しても、システムがネットワーク拡張を保持する場合があります。停止したいときはクライアント内でオフにするか、システムのVPN設定から切断してください。「アプリを閉じたのに通信がまだプロキシ経由」という誤判断を防げます。
接続スイッチをオンにした直後に戻る場合、VPN許可が完了していない、別のネットワーク拡張が使用権を奪っている、設定からコアを起動できない、システムネットワークが一時的に利用できない、といった原因が考えられます。許可、他のVPN、現在の設定、ログの順に確認してください。最初からすべての設定を削除するのは避けましょう。起動エラーのログからDNS、ルール、設定形式の問題を直接特定できることがあります。iOSの詳しい操作手順はiPhoneでサブスクリプションを追加する手順も参照してください。
デスクトップとサーバー
Linux：GUIクライアント、mihomoコア、サービス管理
LinuxデスクトップではClash Verge RevまたはFlClashを選べます。サーバー、ルーター、GUIのない環境ではmihomoコアを直接実行する方が適しています。GUIクライアントはLinuxダウンロードエリアから、ディストリビューションに対応するパッケージを取得してください。選ぶ前にCPUアーキテクチャとパッケージ形式を確認します。Debian、Ubuntuおよび派生システムでは通常debを使いますが、他のディストリビューションでは異なるパッケージ管理方式を使用する場合があります。コアの圧縮ファイルもAMD64、ARM64、ARMv7、MIPSなどに分かれます。アーキテクチャを間違えると実行ファイルを起動できません。
デスクトップクライアントのインストール
debパッケージはシステムのソフトウェアセンターからインストールすることも、ターミナルでパッケージ管理コマンドを実行することもできます。ファイル名は実際にダウンロードした結果に合わせてください：
sudo apt install ./clash-client-amd64.debインストール後、アプリメニューから起動し、サブスクリプションを追加してルールモードを選択します。Linuxデスクトップのシステムプロキシの扱いは完全には統一されていません。GNOME、KDE、ブラウザー、ターミナルツール、サンドボックスアプリが異なる設定を参照する場合があります。クライアントに「システムプロキシ有効」と表示されたら、デスクトップのネットワーク設定に値が書き込まれたか確認し、ブラウザーとコマンドラインを個別に検証します。Flatpak、コンテナ、リモート開発環境には独立したネットワーク名前空間があり、ホストのプロキシを自動的に引き継がないことがあります。
mihomoを直接実行する
GUIのない環境では、まずmihomo用の独立したディレクトリを作成し、実行ファイルと config.yaml を置きます。実行権限を付与したら、-d で作業ディレクトリを指定します。以下は分かりやすいディレクトリ例にすぎないため、実際のシステムに合わせて変更できます：
sudo mkdir -p /etc/mihomo
sudo cp mihomo /usr/local/bin/mihomo
sudo chmod +x /usr/local/bin/mihomo
sudo cp config.yaml /etc/mihomo/config.yaml
mihomo -d /etc/mihomo初回確認にはフォアグラウンド起動が適しています。設定の解析エラーがターミナルへ直接出力されるためです。設定を読み込める、ポートが待受状態になる、ルールとDNSが正常に動作することを確認してから、サービスマネージャーへ移行します。最初からバックグラウンドで起動すると、失敗時にログから間接的に判断するしかありません。設定で参照するルールセット、Geoデータファイル、相対パスはすべて作業ディレクトリを基準にするため、実行ユーザーに読み取り権限があることを確認します。
systemdでサービスを管理する
長期運用する場合は、systemdサービスを作成できます。サービスアカウントには、設定の読み取りとキャッシュへの書き込みに必要な権限を与えます。TUNを有効にする場合は、対応するネットワーク権限も必要です。最小構成のサービス例は次のとおりです：
[Unit]
Description=mihomo service
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
[Install]
WantedBy=multi-user.targetシステムサービスファイルとして保存したら、設定を再読み込みして起動します。systemctl status で状態を確認し、journalctl でログを確認します。コアを更新するときは、まずサービスを停止してファイルを置き換えてから再起動し、実行中のプロセスとディスク上のファイルの不一致を避けます。サブスクリプション更新でも、完全な設定を生成して構文チェックを済ませてから現在のファイルを置き換えてください。誤ったHTMLページや不完全な内容を取得すると、サービスが終了することがあります。
プロキシ環境変数とサービスの適用範囲
デスクトップのシステムプロキシは、すべてのShell、SSHセッション、Dockerビルド、systemdサービスに自動適用されるわけではありません。一時的なコマンドでは環境変数を使用できます：
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export all_proxy="socks5h://127.0.0.1:7890"socks5h はドメイン解決をSOCKS側で行うことを示し、ローカルの名前解決とプロキシルールの不一致を減らせます。長期設定の前に適用範囲を明確にしてください。Shell設定に書けば該当ユーザーのセッションだけに適用され、systemdサービスの環境に書けばそのサービスだけに適用されます。Dockerデーモンに設定すれば、イメージの取得に影響します。トラブル対応では変数が古いポートを指していないか確認し、大文字・小文字の異なる変数が同時に存在しないかにも注意します。
TUN、権限、ファイアウォール
LinuxのTUNには、仮想インターフェース、ポリシールーティング、DNS、ファイアウォールが関係します。高い権限で直接実行するのは簡単ですが、長期運用では必要な機能だけを許可し、サービスアカウントを制限する方が適切です。TUNインターフェースの作成に失敗する場合は、カーネルがTUNデバイスを提供しているか、コンテナが対象デバイスを許可しているか、サービスにネットワーク管理権限があるか確認します。インターフェースは存在するのに通信できない場合は、ルーティングテーブル、ポリシールール、ファイアウォールの転送チェーンを確認します。
サーバーで他の端末向けに mixed-port を開放する場合、すべてのパブリックインターフェースで待受するよう初期設定しないでください。管理下にあるLANアドレスへ優先的にバインドし、ファイアウォールで送信元を制限します。コントロールインターフェースも保護が必要で、信頼できないネットワークへ直接公開してはいけません。デスクトップで単独利用する場合はループバック待受のままが最も簡単です。LAN共有が明確に必要な場合だけ allow-lan を有効にし、アクセス範囲を確認します。
問題の切り分け
よくある設定トラブル：ネットワーク入口からルール結果まで段階的に確認
Clashでインターネットに接続できないとき、クライアント、サブスクリプション、DNS、モードを一度に変更するのは効果的ではありません。データ経路に沿って一層ずつ確認してください。全体の経路は、端末の基本ネットワーク → クライアントのコア → 現在の設定 → システムプロキシまたはTUN → DNS → ルール → プロキシグループ → プロキシの接続先 → 対象サービス、と整理できます。一度に一層だけ検証すれば、結果を再現できます。短い質問はトラブルシューティングで分類別に確認できます。本章では、各プラットフォームに共通する体系的なトラブル対応手順を説明します。
手順1：Clashを停止した状態で基本ネットワークを確認する
まずシステムプロキシ、TUN、モバイル端末のVPNを無効にし、現在のWi-Fi、有線、モバイルデータ通信から一般的なウェブサイトへ直接アクセスします。直接接続自体が使えない場合は、ルーター、通信事業者のネットワーク、ログイン認証、システムネットワーク設定を先に直します。公衆Wi-Fiではウェブ認証が必要なことがあり、TUNが先に通信を取り込むと認証ページが表示されない場合があります。認証を完了してからクライアントを起動してください。
クライアントを停止しても接続できない場合は、システムプロキシが残っていないか確認します。デスクトップでは、クライアントが終了しているのにシステムプロキシが 127.0.0.1 のローカルポートを指したままになり、システムプロキシを参照するすべてのアプリが接続に失敗することがあります。クライアントを再起動してシステムプロキシを正しく無効にするか、OSのネットワーク設定でプロキシを解除します。モバイル端末ではシステムのVPN状態を確認し、別のネットワーク拡張が接続中でないことを確認します。
手順2：コアと設定が起動しているか確認する
クライアントのウィンドウが開いても、コアが動作しているとは限りません。ステータス画面で実行中と表示されているか、ログに設定の読み込み、待受ポート、起動エラーが出ていないか確認します。よくある失敗原因は、ポートの使用中、設定構文の誤り、ルールセットファイルの欠落、データフォルダーの権限不足、TUN権限不足です。アドレスが使用中と表示された場合は、他のプロキシクライアントを終了するか、同じポートを使っているプロセスを特定します。複数のポートを無計画に変更し、システムプロキシとの同期を忘れないようにしてください。
現在の設定が、追加した対象設定であり、クライアント内蔵のサンプルや古いファイルではないことを確認します。サブスクリプション項目が存在しても選択されていなければ、コアは以前の設定を読み込みます。更新後に起動できない場合は、前回成功した設定へ戻し、新しい内容が原因かどうかを判断します。YAMLはインデントに敏感です。手動編集ではスペースを使い、階層を統一してください。タブや誤ったコロン構造は避けます。
手順3：取り込みの失敗とプロキシ接続先の失敗を分ける
システムプロキシを有効にし、接続ログにブラウザーのリクエストが現れるか確認します。記録がまったくない場合は、通信がクライアントへ入っていません。システムプロキシが書き込まれているか、アプリがプロキシを参照するか、待受ポートが一致しているかを確認します。接続ログにリクエストがあるのにタイムアウトが続く場合は、一致したルール、プロキシグループ、接続先を確認します。TUNモードで記録がない場合は、まず仮想インターフェース、ルート、権限を確認します。モバイル端末ではVPNの許可とアプリ別プロキシリストを確認します。
同じ端末で2通りの比較ができます。まずTUNを無効にしてシステムプロキシだけを有効にし、ブラウザーをテストします。次にシステムプロキシを無効にしてTUNだけを有効にし、同じ対象をテストします。システムプロキシは使えるのにTUNが使えない場合、サブスクリプションと大半のルールに問題はない可能性が高く、TUNの権限、ルート、DNSに絞って確認します。逆にTUNは使えるのにシステムプロキシが無効なら、システム設定、アプリのプロキシ動作、ローカルポートを確認します。
手順4：DNSとルールの一致を確認する
ドメインへのアクセスだけ失敗し、既知のアドレスやクライアント内蔵の接続テストは成功する場合は、DNSを確認します。ログの名前解決タイムアウトは、上流へ到達できない、ブートストラップ解決に失敗する、ポートが競合する、DNSリクエストが取り込まれていない、といった原因で発生します。一時的に元のサブスクリプションのDNS設定へ戻し、カスタム設定が原因か確認します。複数のリゾルバー、Fake-IP、プライベートDNS、システムの暗号化DNSを同時に変更しないでください。
接続ログでリクエストがDIRECTへ送られ、PROXYを想定していた場合は、具体的に一致したルールを確認します。広すぎる DOMAIN-SUFFIX、GEOSITE、地域ルールが先に一致している可能性があります。REJECTと表示された場合は、広告ブロックのルールセットが対象ドメインを誤って拒否していないか確認します。MATCHに落ちる場合は、それより前に具体的なルールがありません。ルールを変更したら接続を再試行してください。既存の長時間接続は新しいプロキシグループへ自動的に切り替わりません。
手順5：サブスクリプションとプロキシ接続先の状態を判断する
設定は読み込めるのにすべてのプロキシ通信が失敗する場合は、まず一度サブスクリプションを更新し、返されたエラーを確認します。HTTPステータスの異常、空の内容、形式エラーは、サブスクリプション取得段階の問題を示します。更新に成功したら、異なるプロキシグループの項目を選んで比較します。ただし、クライアントの検査結果を実際の速度と同一視しないでください。テスト先だけが対象ネットワークに制限されていたり、普段のサイトとは異なる経路を通ったりすることがあります。
特定のサービスだけ失敗する場合は、ドメインルール、プロトコル対応、対象サービス自体の状態を確認します。すべての対象が接続確立段階でタイムアウトする場合に限り、プロキシ接続先や現在のネットワークによるブロックの可能性が高くなります。ログの timeout、connection refused、DNSエラーは意味が異なるため、すべてを「ノード障害」と一括りにしてはいけません。よくあるログフィールドの解説と照らし合わせて判断してください。
よくある症状の比較
| 症状 | 考えられる箇所 | 対応の順序 |
|---|---|---|
| クライアント終了後、ブラウザーがすべて使えない | システムプロキシが残っている | システムプロキシを復元し、クライアント終了時の設定を確認する |
| ブラウザーは使えるが、ゲームやターミナルが使えない | アプリがシステムプロキシを参照していない | アプリのプロキシを設定するか、競合がないことを確認してTUNを有効にする |
| TUN起動後にLAN機器が見えなくなる | プライベートネットワークのルートまたはDNS | LANのダイレクトルール、自動ルート、Fake-IPフィルターを確認する |
| 画面ロック後にAndroidの接続が切れる | バックグラウンドとバッテリーの制限 | バックグラウンド動作を許可し、クライアントの自動消去を無効にする |
| iOSのスイッチがすぐ元に戻る | VPNの許可、設定、拡張機能の競合 | システムの許可、他のVPN、起動ログを確認する |
| Linuxサービスが何度も再起動する | 設定の解析、権限、パス | フォアグラウンドで起動し、最初に表示された明確なエラーを修正する |
必要十分な情報を集める
サービス提供元やコミュニティへ問題を説明するときは、OS、クライアント名、通信の取り込み方式、プロキシモード、問題が始まった時刻、すべての対象が失敗するか、ログにある最初の関連エラーを伝えます。「使えない」とだけ書いたり、設定全体をそのまま貼り付けたりしないでください。サブスクリプションURL、認証情報、プロキシ情報は隠します。問題を安定して再現できる場合は、「TUNを無効にするとブラウザーは正常だが、有効にすると接続ログがすべて空になる」のように、最短の手順を書きます。無関係な大量のログより、はるかに特定しやすくなります。
ログレベルは通常 info で十分です。複雑なルールやDNSの流れを追跡する必要があるときだけ一時的に詳細度を上げ、完了後に戻してください。ログが急速に増えるのを防げます。問題が解決したことを確認してから、カスタムDNS、ルールの上書き、自動起動、その他のネットワークツールを一つずつ戻します。各項目を戻すたびに接続を確認し、説明可能で復旧できる設定に仕上げます。
リセットと再インストールの判断
設定が壊れた、クライアントのデータフォルダーへ書き込めない、アップグレード後に設定構造がおかしい、といった場合は、まず必要な設定をエクスポートしてからクライアントのリセット機能を使います。プログラムを再インストールしてもデータフォルダーが消えるとは限らないため、「再インストールしても問題が同じ」という結果は珍しくありません。逆に、データフォルダーを直接削除すると、サブスクリプション、上書き設定、プロキシグループの選択を失います。先に復元用の情報を保存してください。プログラムファイル、補助サービス、システムコンポーネントのインストール異常を確認できた場合に限り、再インストールが妥当な手順になります。
トラブル対応後は、「古いクライアントが混合ポートを使用していた」「Androidのバックグラウンド制限でVPNが終了した」「MATCHの前に広すぎるダイレクトルールがあった」のように、最終的な原因を記録しておくことをおすすめします。大量の一時設定を保存するより、こうした記録の方が役立ちます。別のプラットフォームへ移行するときは、このガイドの共通ロジックに沿って最小限の設定を作り、そこへプラットフォーム固有の機能を追加すると、同じ問題を繰り返し調べる手間を大幅に減らせます。