ドキュメント一覧 · インストール / 設定 / トラブル対処

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

OS別にダウンロード、インストール、サブスクリプションの追加、通信の振り分け方法を確認できます。このページはリファレンスとしてご利用ください。初めて使う場合は、まずClashの使い方ガイドに沿って接続し、その後、プラットフォームごとの違いや設定上の注意点を確認してください。

共通の準備：クライアント、サブスクリプション、設定の注意点

クライアント、コア、接続サービスの違い

Clashのエコシステムには、GUIクライアント、プロキシコア、設定形式があります。GUIクライアントはサブスクリプションの追加、プロキシの選択、システム権限の要求を担い、コアは設定の解析、ルール判定、接続を担います。mihomoは広く使われるコアですが、すべてのクライアントが同じ設定項目に対応しているとは限りません。サブスクリプションのプロトコル、クライアントに同梱されたコアの機能、設定の変換方法が互いに適合しているか確認しましょう。特に新しい通信パラメーターやDNS項目には注意が必要です。

クライアントをインストールしただけでは、接続できる状態にはなりません。事前に、信頼できるサービス提供元のサブスクリプションURL、またはプロキシの接続先を含むローカルのYAMLファイルを用意し、利用範囲、有効期限、デバイス数の制限を確認してください。まずはクライアントのダウンロードページからOSに合ったClash Plusを選びましょう。別の画面や導入方法が必要な場合は、プラットフォームに応じてClash Verge RevやFlClashなども比較してください。複数のプロキシコアを同時に起動するのは避けましょう。

アーキテクチャを確認し、現在のネットワーク設定を控える

ダウンロード前に、OS、CPUアーキテクチャ、インストール権限を確認します。デスクトップではx64とARM64、macOSではIntelとApple Siliconを区別し、Androidでは端末が対応する命令セットに合ったインストールパッケージを選びましょう。アーキテクチャが合わないと、起動やインストールに失敗することがありますが、サブスクリプションの問題ではありません。インストール前に、既存のVPN、手動プロキシ、社内ネットワーク用ソフト、カスタムDNSの設定も控えておくと、新しい設定で上書きした場合に元へ戻せます。

現在使える設定とクライアントの上書きルールをバックアップしておきましょう。サブスクリプションURLにはアカウント情報が含まれる場合があるため、スクリーンショット、問い合わせ、公開リポジトリではURL全体を隠してください。ローカルにエクスポートしたYAMLにもパスワードが含まれることがあります。複数のデバイスで同期する場合は、サービス提供元が管理するサブスクリプションと、自分で管理する上書き設定を分けましょう。リモートのサブスクリプションから生成されたファイルを直接編集すると、次回の更新で変更が失われることがあります。管理方法は複数デバイス間の設定同期方法を参考にしてください。

システムプロキシとTUNの通信範囲を理解する

システムプロキシは、OSのプロキシ設定に従うアプリにローカルのHTTPまたはSOCKS接続先を提供します。すべてのゲーム、コマンドラインツール、UDP通信がこの接続先を使うとは限りません。一方、TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、通常はサービスコンポーネントやシステム権限が必要です。用途は異なるため、まずシステムプロキシで動作を確認できる状態を作り、必要なアプリに応じてTUNを有効にしましょう。すべての設定を同時に有効にするより、問題を特定しやすくなります。

以下の共通項目は、一般的なmihomo設定で利用できます。mixed-portはHTTPとSOCKSの両方を受け付けます。ループバックアドレスで待ち受ける場合、接続できるのは同じ端末からのみです。この例にはプロキシの接続先が含まれないため、通信経路のテストには使えません。クライアントの画面でポートや待ち受けアドレスを設定する場合は、サブスクリプションのファイルだけでなく、実行中の設定に反映された値も確認してください。

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

サブスクリプション追加後の確認手順

URLを追加したら、まずサブスクリプションを更新し、新しい設定を現在の設定として選択します。想定したプロキシグループが表示されることを確認し、グループを開いて実際に使えるプロキシを選びましょう。「自動選択」グループにも有効なメンバーが必要です。サブスクリプションの取得に成功しても、プロキシに接続できるとは限りません。取得に失敗した場合は、端末の時刻、URLの欠落、サービス提供元が指定する形式を確認してください。まずはクライアントのインポート機能を使い、安易に第三者の変換サービスを利用しないでください。

次にルールモードで、プロキシ経由になるはずのリクエストをテストし、接続ログで適用ルールと最終的な接続先を確認します。直通になるはずのリクエストも試して、振り分けが想定どおりか確かめましょう。変更する項目は一度に一つに絞り、変更前後の結果を記録してください。ブラウザーでページを開けても、すべてのアプリが通信を取り込めているとは限りません。接続元のIPアドレスが変わっただけでは、DNSの経路が正しいとも断定できません。リクエスト、ルール、名前解決の3点を確認しましょう。

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

インストールパッケージを選び、初回起動する

Windowsの「設定」からシステム情報を開き、システムの種類を確認して、ダウンロードページに記載されたアーキテクチャとシステム要件に合うパッケージを選びましょう。まずはClash Plusがおすすめです。使い方に応じてClash Verge Rev、FlClash、Clash Nyanpasuも選べます。Clash for Windowsは開発終了しているため、古い設定の確認や移行には使えますが、古い解説記事にあるメニューの場所が現在のクライアントにも当てはまるとは限りません。新しいクライアントを入れる前に、古いクライアントを終了してシステムプロキシを無効にしてください。

インストーラーが管理者権限を要求した場合は、ファイルの入手元と要求された操作を確認してください。通常のGUIと管理者権限が必要なバックグラウンドサービスは別のコンポーネントです。GUIを起動するたびに管理者として実行する必要はありません。初回起動後、コアが正常に起動しているか確認しましょう。画面は表示されるのに、設定やログの画面で接続エラーが続く場合は、ローカルのコアプロセスと制御用接続を先に調べてください。すぐにOS全体を再インストールしたり、サブスクリプションを何度も変更したりする必要はありません。

設定を追加し、システムプロキシで接続を確認する

サブスクリプションまたは設定の画面を開き、完全なURLを貼り付けてダウンロードします。見分けやすい名前を付け、更新後にその設定を選択して現在の設定にします。次にプロキシ画面で選択グループを開き、実際に使うプロキシを指定してから、設定でシステムプロキシを有効にします。ブラウザー側で固定プロキシを設定していたり、プロキシ切り替え拡張機能を使っていたりする場合は、一時的にシステム設定を使うように変更してください。そうしないと、クライアントのシステムプロキシ設定がブラウザーに反映されない場合があります。

テストでは、まずルールモードを使います。トレイアイコンだけで判断せず、接続ログで対象ドメイン、適用ルール、接続先を確認してください。ローカルHTTP接続先をテストする場合は、PowerShellから次のコマンドを明示的に実行できます。curl.exeを使うことで、PowerShell環境によって短いコマンドの解釈が異なる問題を避けられます。リクエストが成功しても、指定した接続先が使えることを示すだけで、ほかのアプリがシステムプロキシに従うとは限りません。

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

必要に応じてTUNサービスをインストールする

対象アプリがシステムプロキシを無視する場合や、より多くの通信を取り込みたい場合にTUN設定を開きます。クライアントによっては、TUNを有効にする前にサービスコンポーネントのインストールが必要です。サービスのインストール、サービスの起動、TUNの有効化はそれぞれ別の状態です。権限を許可したら、仮想ネットワークアダプター、ルート、初期化に関するログを確認してください。有効化に失敗した場合は、まずシステムプロキシで確認できる状態に戻して、エラーの内容を調べます。権限、ドライバー、サービスの状態を確認し、インストールボタンを何度も押さないでください。

TUNは、ほかのVPN、仮想マシンやコンテナーのネットワーク、企業向けセキュリティソフトとルートが競合する場合があります。トラブル対処では、通信を取り込むツールを一つだけ有効にして、無効にしたソフトを記録しましょう。リモートデスクトップや会社の管理下にある端末では、管理用接続が切れるおそれがあるため、デフォルトルートを安易に変更しないでください。会社のポリシーでサービスのインストールが制限されている場合は、端末の管理ルールに従いましょう。セキュリティソフトの保護機能をすべて無効にする方法は、一般的な解決策ではありません。

ポート、プロキシ設定の残存、権限の問題を調べる

ログにポートの競合が表示された場合は、上記の待ち受け確認コマンドでプロセスIDを調べ、そのプロセスがどのプログラムのものか確認します。正体の分からないシステムプロセスを終了しないでください。重複起動しているクライアントを終了するか、クライアントの設定で空いているポートに変更できます。ポートを変更したら、ブラウザー、ターミナル、エディターに手動で設定したプロキシも合わせて変更してください。設定ファイルと画面上の上書き設定が異なる場合は、コアが実際に待ち受けている値を確認しましょう。

クライアント終了後にブラウザーでネットに接続できなくなった場合、Windowsにローカルポートを指す手動プロキシ設定が残り、コアだけが停止していることがよくあります。Windowsのネットワーク設定からプロキシを開き、手動プロキシが有効なままになっていないか確認して、元のネットワーク環境に合わせて復元してください。特定のアプリだけで問題が起きる場合は、そのアプリ独自のプロキシ設定、バックグラウンドプロセス、キャッシュされた接続を確認します。一つのアプリの失敗だけで、TUNやサブスクリプション全体が使えないと判断しないでください。

アップグレード前に、サブスクリプション一覧、上書きファイル、必要な設定をバックアップし、更新後にサービスの状態と起動時の動作を再確認します。スリープから復帰した後やWi-Fiを切り替えた後に接続が切れた場合は、まずクライアントを再接続し、ルートの変化を確認してからサービスの再起動を検討してください。インストール手順やよくあるエラーの詳細はWindowsでClash Verge Revをインストールする手順をご覧ください。記事内の画面名をほかのクライアントにそのまま当てはめないようにしましょう。

macOS：チップのアーキテクチャ、ネットワーク権限、プロキシ設定の復元

チップに合ったクライアントを選んでインストールする

「このMacについて」でチップまたはプロセッサの情報を確認し、macOSのダウンロードページから対応するインストールパッケージを選びます。まずはClash Plusがおすすめです。Clash Verge RevやFlClashも選べます。ClashX Metaは開発終了しているため、古い設定を移行する場合はコアの設定項目を別途確認してください。インストールパッケージのアイコンやファイルサイズだけでアーキテクチャを判断しないでください。変換機能を使って起動できても、その端末に最適な形式とは限りません。

インストールパッケージの説明に従ってアプリを「アプリケーション」フォルダへ移し、ディスクイメージや一時的なダウンロードフォルダからではなく、決まった場所から起動しましょう。入手元や権限に関する警告が出た場合は、ダウンロード元とアプリの情報を確認し、システムが案内する通常の手順で許可してください。システムのセキュリティ機能をすべて解除することは、インストール手順ではありません。初回起動後、メニューバー、設定画面、ログ画面が正常に開くことを確認してから、サブスクリプションを追加します。

サブスクリプションを追加し、使用中のネットワークサービスを確認する

クライアントの設定管理画面からリモートサブスクリプションを追加し、更新後に現在の設定として選択します。プロキシグループで接続先を選びましょう。同じクライアントに複数の設定を保存する場合は、サービスの提供元や用途が分かる名前を付けてください。追加後はTUNを有効にせず、システムプロキシをオンにしてブラウザーで確認します。設定のダウンロードエラーが出た場合は、URL、端末の時刻、現在のネットワーク接続を確認してください。ブラウザーでサブスクリプションURLのテキストを表示できても、クライアントとの形式の互換性に問題がないとは限りません。

macOSのプロキシ設定は、ネットワークサービスごとに管理されます。Wi-Fi、有線LAN、その他のネットワークインターフェースで設定が別々の場合があるため、接続先を切り替えたら設定を再確認してください。クライアントにシステムプロキシが有効と表示されているのに接続ログにリクエストが出ない場合は、現在使っているネットワークサービスと、アプリがシステムプロキシを使うかどうかを確認します。ブラウザー拡張機能、開発ツール、コマンドライン環境が個別のプロキシ設定を持つ場合もあります。メニューバーの表示だけで、すべてのリクエストの経路を判断しないでください。

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

上記のコマンドは、現在のプロキシ情報の確認、ローカルHTTP接続先への明示的なリクエスト、待ち受けプロセスの確認にそれぞれ使います。ターミナルは通常、GUIのシステムプロキシ設定を自動で引き継ぎません。そのため、ブラウザーでは成功し、ターミナルでは失敗することもあります。特定のコマンドでプロキシを使う場合は、まずそのプログラムのプロキシオプションを使いましょう。環境変数を使う場合、その設定は現在のターミナルと子プロセスだけに適用され、システム全体の設定ではないことを理解してください。

TUNの権限とバックグラウンドコンポーネント

システムプロキシに従わないアプリの通信を取り込む場合は、クライアントのTUN機能を使います。実装方法はクライアントによって異なり、特権ヘルパー、バックグラウンドサービス、システムのネットワーク機能を利用します。権限の確認画面も同じとは限らないため、内容と申請元を一つずつ確認してください。許可後、クライアントが初期化の成功を明示しているか確認します。バックグラウンドコンポーネントが許可されていない場合、接続先を何度切り替えても解決しないことがあります。まずサービスやネットワーク権限の状態を確認しましょう。

既存のVPN、コンテンツフィルター、仮想ネットワーク、企業の管理設定があると、TUNのルーティングと競合することがあります。まず現在の状態を記録し、不要な通信取り込み機能を一つずつ無効にして比較しましょう。リモートワーク用ネットワークに接続する場合は、社内ドメインやプライベートIPアドレスへのアクセスが必要か特に確認してください。すべての通信をプロキシに向けると、社内リソースにアクセスできなくなることがあります。必要なルートやDNSの方針は、起動順に頼らず、明確なルールで管理してください。

スリープからの復帰、キーチェーン、アンインストール時の注意

スリープからの復帰、Wi-Fiの切り替え、ドッキングステーションへの接続によって、ネットワークインターフェースの状態が変わることがあります。復帰後に通信できなくなった場合は、現在の設定が有効か、プロキシが待ち受けているかを確認してから再接続してください。IPアドレスへ直接接続できるのにドメイン名で失敗する場合は、名前解決の経路を重点的に確認します。DNS設定をすぐに複数変更しないでください。サブスクリプションの認証情報やシステム権限の保存先はクライアントによって異なります。端末を移行する前に、クライアントのエクスポート機能を使い、ファイルを安全に保管してください。

アンインストールする前にシステムプロキシとTUNを無効にし、クライアントを終了してください。クライアントにバックグラウンドサービスを削除する機能がある場合は、説明に従って処理します。アプリをゴミ箱に移動するだけでは、設定済みのネットワークプロキシやバックグラウンドコンポーネントが解除されないことがあります。削除後にネットワークの問題が起きた場合は、現在のネットワークサービスのプロキシ設定でローカルアドレスを確認し、インストール前に記録した状態へ戻してください。診断ログを共有する際は、サブスクリプションURLとプロキシの認証情報を削除してください。設定フォルダ全体を公開しないでください。

Android：インストール元、VPNによる通信の取り込み、バックグラウンド動作

アーキテクチャを選び、インストールを許可する

Androidのダウンロードページからクライアントを選びます。まずはClash Plusがおすすめです。Clash Meta for Android、FlClash、Surfboardも選択肢です。設定への対応範囲はクライアントごとに異なり、特定のコア向けの完全なYAML設定がそのまま使えるとは限りません。インストールする前に、サービス提供元が対応しているクライアントとサブスクリプション形式を確認してください。プロトコルやルール形式を解析できないと、インストール後に分かる事態を避けられます。

インストールパッケージは端末のアーキテクチャに合わせてください。新しいスマートフォンはARM64が一般的ですが、実際の対応状況は端末で確認しましょう。古い端末には別のビルドが必要な場合があります。ファイル管理アプリやブラウザーからのインストールを許可する必要がある場合は、実際に使うアプリに必要な権限だけを付与し、インストール後に取り消すこともできます。「アプリをインストールできません」と表示された場合は、システム要件、空き容量、アーキテクチャ、既存アプリの署名を確認してください。すべてのインストールエラーがネットワークの問題とは限りません。

サブスクリプションを追加し、正しい設定を選択する

サブスクリプションまたは設定画面を開き、リモート設定を追加してURLを貼り付けます。ダウンロード後、リストに表示されているだけでなく、その設定が選択中になっていることを確認してください。プロキシグループから接続先を選び、ホーム画面に戻って接続を開始します。クライアントによっては、サブスクリプションの更新と現在の設定への切り替えが別の操作です。別の設定を更新しても、実行中の設定は自動で切り替わりません。トラブル対処では設定名と最後に更新した結果の両方を確認してください。

追加後にリストが空だったり、項目エラーが表示されたりする場合は、サービス提供元が指定する形式、サブスクリプションの有効期限、クライアントが対応するプロトコルを確認してください。保存できるようにするために、意味の分からない項目を安易に削除しないでください。通信方式や認証方法を決める項目かもしれません。Surfboardなどのクライアントでは、対応する形式を使う必要があります。サービス提供元が複数のURLを用意している場合は、設定を何度も読み込み直すより、正しい形式のURLを選びましょう。

AndroidのVPN接続の仕組みを理解する

Androidのクライアントは通常、システムのVPN機能を使ってアプリの通信を取り込みます。初回接続時には、システムの確認画面が表示されます。これはローカルVPNインターフェースの作成を許可するもので、すべての通信がプロキシ経由になることを意味しません。実際の経路はルールによって決まります。ステータスバーのVPNアイコンはインターフェースの状態を示すだけです。選択したプロキシ経由で通信しているかは、クライアントの接続ログ、対象ドメイン、接続元IPアドレスを合わせて確認してください。

通常、Androidでは複数のVPNアプリが同じユーザーの通信を同時に取り込むことはできません。広告ブロック、セキュリティアプリ、会社のVPN、ほかのプロキシクライアントが機能を使用中の場合があります。起動に失敗したら、まずシステムのVPN画面を確認し、競合する接続のうち不要なものを終了してください。デスクトップ向けの「システムプロキシを有効にする」手順をそのままスマートフォンに適用しないでください。Androidのアプリごとの振り分け、VPNによる通信の取り込み、Wi-Fiの手動プロキシは、それぞれ別の設定です。

アプリごとの振り分け、プライベートDNS、バッテリー管理

アプリの許可リストを使う場合、リストにないアプリの通信はクライアントに取り込まれないことがあります。除外リストを使う場合は、選んだアプリが直接接続することがあります。まずリストの動作モードを確認し、対象アプリが正しい側にあるか調べましょう。ブラウザーでは成功するのに別のアプリで失敗する場合、ルールの問題だけでなく、そのアプリが通信を取り込まれていない可能性もあります。アプリの振り分け設定を変更した後は、クライアントの案内に従って接続し直し、古いインターフェースの状態が残らないようにしてください。

AndroidのプライベートDNS、ブラウザーのセキュアDNS、クライアントのDNSによって、名前解決の経路が複数に分かれることがあります。特定のドメインに接続できない場合は現在の設定を記録し、一つずつ比較してください。プライベートDNSを変更しながらプロキシも切り替えて、結果を記録しないまま調べるのは避けましょう。VPNでDNSをまとめて処理できるクライアントもありますが、対応状況は実装によって異なります。fake-ipやDNSの経路を確認する方法は、DNSリークの確認と対策をご覧ください。

画面ロック後に接続が切れる場合は、システムがクライアントのバックグラウンド動作、バッテリー使用、自動起動を制限していないか確認してください。メニュー名は端末によって異なるため、そのアプリの電池管理画面で確認し、必要な権限だけを変更しましょう。「常時接続VPN」や「VPNなしの接続をブロック」を有効にする前に、動作を理解してください。クライアントが正常に起動しないと、後者の設定によって端末が一時的にネットワークへ接続できなくなることがあります。まずVPNインターフェースが安定して作成されることを確認してください。

アップグレード前にサブスクリプションURLとローカルの上書き設定を保存し、アプリ固有の設定をエクスポートする必要があるか確認してください。別のクライアントへ移行しても、アプリの振り分け設定やバッテリー権限は完全に引き継がれないことがあり、再確認が必要です。アンインストール前に接続を停止し、システムのVPN設定を確認してください。トラブルのスクリーンショットを共有する際は、サブスクリプション、接続先、アカウント情報を隠し、接続ログは必要な時間帯だけに絞りましょう。

iOS：Clash Plus、サブスクリプションの追加、ネットワーク拡張

App Storeからインストールし、設定の入手元を確認する

iOSではClash Plusがおすすめです。App StoreのClash Plusページからインストールできます。製品情報は公式サイトのclashplus.ioで確認してください。インストール前に、App Storeに記載された対応デバイスとアプリの説明を確認し、使用する端末に合っているか確かめましょう。デスクトップ向けの実行ファイルやAndroid用パッケージは、iOSのインストールには使えません。クライアントをインストールした後も、有効なサブスクリプションは別途用意する必要があります。

サブスクリプションは接続サービスの提供元が管理するもので、App Storeからのインストールと利用権限は別です。URLが有効であること、アカウントで現在の端末を利用できること、提供元が指定する設定形式を確認してください。サブスクリプションURLにはアクセス情報が含まれることがあるため、共有メモ、公開スクリーンショット、掲示板に載せないでください。インポートエラーを提供元へ問い合わせる場合は、機密情報を隠したエラー内容とクライアント名を伝え、URL全体は公開しないようにしましょう。

サブスクリプションを追加・更新し、現在の設定にする

クライアントの設定またはサブスクリプション管理画面を開き、リモートURLを追加してダウンロードが完了するまで待ちます。提供元のQRコードを使う場合は、クライアントが対応するサブスクリプションURLが含まれていることを確認してください。アカウントのログイン画面や通常のWebページではないか注意しましょう。追加後は設定内容とプロキシグループが表示されることを確認し、現在使う設定にして、実際の接続先を選びます。サブスクリプション名が表示されただけでは、有効化されたこともプロキシグループのメンバーが使えることも分かりません。

サブスクリプションの更新に失敗した場合は、まず端末の時刻、ネットワーク、URLが完全かどうかを確認します。URLのコピー時にクエリパラメーターが欠けたり、空白や改行が混じったりすることがあります。信頼できる入手元からコピーし直しましょう。古い設定がまだ使えるなら、トラブル対処中は残しておき、バックアップなしにすべて削除しないでください。クライアントのローカルルールや上書き設定を使う場合は、サブスクリプション更新後も維持されるか確認しましょう。更新前と振り分けの動作が変わることがあります。

VPN設定を許可し、実際の接続先を確認する

初めて接続するとき、システムからVPN設定の追加を求められることがあります。申請元が使用中のクライアントであることを確認し、システムの手順に沿って許可してからアプリに戻り、接続状態を確認してください。iOSはネットワーク拡張を使って通信を処理するため、Windowsのようなローカルのシステムプロキシスイッチを探す必要はありません。ステータスバーやコントロールセンターのVPN表示は、システム接続の状態を示すだけです。通信の経路を確認するには、クライアントの設定、プロキシグループ、接続ログを確認してください。

まずルールモードで、プロキシ経由になるはずのリクエストをテストし、次に直接接続になるはずのリクエストを試します。アプリの内容が更新されても、キャッシュが表示されているだけだったり、古い接続が残っていたりする場合があります。テストではリクエストを新たに発行してください。プロキシグループを切り替えても、既存の接続がすぐに別の接続先へ切り替わるとは限りません。必要に応じてクライアントの接続管理機能を使うか、対象アプリを再起動しましょう。古い画面の表示だけを見て、設定が反映されていないと判断しないでください。

Wi-Fi、モバイル通信、その他のネットワーク機能

Wi-Fiとモバイル通信でそれぞれ接続を確認すると、ローカルネットワークの制限と設定の問題を切り分けやすくなります。特定のWi-Fiだけで失敗する場合は、まず認証画面を完了し、プロキシ接続をオフにして端末が正常にインターネットへ接続できるか確認してください。公衆Wi-Fiでは外部サービスを使う前にログインが必要なことがあります。認証が済んでいないと、サブスクリプションの更新やプロキシ接続も失敗します。その場合、複数のルールを切り替えても解決にはなりません。

会社のVPN、オンデマンド接続設定、ほかのネットワーク拡張がある場合は、それぞれの管理方法を確認し、複数のツールが接続を繰り返し切り替えないようにしてください。組織の管理下にある端末では、一部のネットワーク設定がポリシーで制御されている場合があります。管理ルールに従ってください。システムのプライバシー機能やブラウザーの設定も確認結果に影響することがあります。各設定の状態を記録し、一度に一つずつ変更してテストした後、必要なプライバシー設定や業務用設定を元に戻しましょう。

バックグラウンド制限、アップデート、ネットワークの復旧

iOSのバックグラウンド動作を、デスクトップのプロセスと同じように考えないでください。アプリ画面がバックグラウンドに移った後も、画面が動作するかどうかと、ネットワーク拡張の接続が維持されるかどうかは別の問題です。接続が繰り返し停止する場合は、システムのVPN状態、クライアントのエラーログ、端末の空き容量、設定の規模を確認します。ルールを大量に重複して追加した状態で、画面の動作が遅いだけなのに接続先の障害と判断しないでください。モバイル通信の切り替えによる一時的な再接続と、トンネルを確立できない状態も区別しましょう。

アプリやOSをアップデートする前に、サブスクリプションの入手元と重要なローカルルールを保存し、クライアントが対応するバックアップ方法を確認してください。ネットワークを復旧する場合は、まずクライアントで接続を停止し、システム設定でVPNの状態を確認します。最初から端末のネットワーク設定をすべてリセットする必要はありません。Wi-Fiなどの既存情報にも影響します。クライアント関連の接続が終了していることを確認しても通信できない場合に、ネットワークの認証、端末の管理ポリシー、通信事業者のネットワークを調べてください。

Linux：ディストリビューション、デスクトッププロキシ、サービスの導入

デスクトップクライアントとコアの導入方法を分けて考える

Linuxデスクトップでは、ダウンロードページからClash Verge Revを選ぶのがおすすめです。FlClashも利用できます。サーバーやルーターでは、mihomoコアを単独で実行できます。GUIクライアントとコアのサービス運用は別の導入方法です。同じポートで同時に起動しないでください。トレイアイコン、デスクトップのシステムプロキシ、対話式のサブスクリプション管理が必要かを整理してから、GUIクライアントを使うか、設定ディレクトリ、サービス権限、ログを自分で管理するか決めましょう。

インストール前にシステム情報でディストリビューション、CPUアーキテクチャ、パッケージ形式を確認します。Debian系では通常、対応するDEBパッケージを使います。RPM系のパッケージ管理を採用するディストリビューションでは、対応するパッケージを選びます。依存関係やデスクトップ環境の対応は、クライアントの説明を確認してください。拡張子が同じでも、すべてのディストリビューションで使えるとは限りません。インストール時に依存関係のエラーが出た場合は、ディストリビューションのパッケージ管理ツールで原因を調べます。ほかのシステムのライブラリをシステムディレクトリへ安易にコピーしないでください。

uname -m
cat /etc/os-release
ss -lntp 'sport = :7890'

デスクトップクライアントのサブスクリプションとシステムプロキシ

インストール後、デスクトップからクライアントを起動し、サブスクリプションを追加して現在の設定にします。プロキシグループで接続先を選んでから、システムプロキシを有効にし、デスクトップ環境のネットワークプロキシ設定を確認しましょう。システムプロキシの読み取り方は、デスクトップ環境、サンドボックスアプリ、ブラウザーによって異なります。ターミナルのプログラムも通常、デスクトップのプロキシ設定を自動では使いません。まず明示的なプロキシ指定でコアをテストし、対象プログラムごとに接続方法を確認してください。一つのプログラムの失敗だけで、コアが起動していないと判断しないでください。

以下のコマンドは、環境変数を使って実行中のコマンドにHTTPプロキシを指定します。影響するのは、そのコマンドと関連する実行環境だけです。継続して使う場合は、プログラムの説明に従って設定し、除外するアドレスも検討してください。すべてのユーザーに適用される環境設定ファイルへ安易にプロキシを記述すると、コアを停止した後もパッケージ管理ツールやバックグラウンドタスクが存在しないローカル接続先へアクセスし続けることがあります。

HTTPS_PROXY=http://127.0.0.1:7890 curl --head https://example.com

TUN、ルート、最小限の権限

LinuxでTUNを使って通信を取り込むには、通常、仮想ネットワークインターフェースやルーティングの権限が必要です。GUIクライアントにサービスのインストール機能がある場合は、その手順を優先し、アプリ全体に過剰な権限を与えないようにしましょう。まずサービスの起動を確認してからTUNを有効にし、ログでインターフェースの作成とルート設定の結果を確認します。補助コンポーネントの権限問題を解決するために、通常のデスクトップユーザーがGUI全体をrootで常時実行するのは避けてください。

リモートサーバーでは、自動ルーティングに特に注意してください。有効にする前に、独立した管理経路を確保し、SSH、プライベートネットワーク、ローカルゲートウェイへの接続方法を確認します。デフォルトルートが変更されると、現在の管理接続が切断されるおそれがあります。TUNの自動ルート、自動インターフェース認識、DNSの横取りは、実際のネットワーク構成に合わせて設定してください。コンテナー、ブリッジ、複数のネットワークカードを使う環境に、単一NICのノートPC向け設定をそのまま適用しないでください。ルーターへの導入については、OpenWrtのサイドルーターでmihomoコアを動かす方法もご覧ください。

コアの設定確認とサービスのディレクトリ

コアを直接実行する場合は、プロキシの接続先、プロキシグループ、ルールを含む完全な設定を用意し、構文を確認してから実行します。以下のコマンドは、mihomoがシステムのコマンドパスにインストールされ、設定ファイルが現在のユーザーの設定ディレクトリにあることを前提としています。実際のパスが異なる場合は、導入先に合わせて変更してください。構文チェックに通っても、すべてのプロキシに接続できるとは限らず、ルールプロバイダーが更新済みとも限りません。

mihomo -t -f "$HOME/.config/mihomo/config.yaml"
mihomo -d "$HOME/.config/mihomo"

設定ディレクトリにはメイン設定のほか、ルールプロバイダーのファイル、キャッシュ、データベースが保存されることがあります。手動実行とサービス実行でユーザーが異なると、読み書き権限も変わり、手動起動は成功するのにサービスは失敗する場合があります。サービスの実行ユーザー、作業ディレクトリ、設定ファイルのパスを明確にして、ディレクトリの権限を確認してください。ログは導入方法に対応した手段で確認します。エラー出力を確認できないまま、サービスを繰り返し再起動しないでください。

ファイアウォール、LAN、アップデート管理

端末上のプロキシは使えるのにLAN内のデバイスから接続できない場合は、待ち受けアドレス、allow-lan、ファイアウォールをそれぞれ確認してください。ほかの端末へポート番号を伝えるだけでは不十分です。LANからのアクセスを許可すると、接続口が外部に公開される範囲が広がります。信頼できるネットワークに制限し、必要に応じて認証を設定しましょう。コントロールインターフェースとプロキシの接続口は用途が異なります。コントロールインターフェースを信頼できないネットワークに公開したり、リモート管理のためにファイアウォールをすべて無効にしたりしないでください。

クライアントやコアを更新する前に、設定とサービス定義を保存し、古いプロセスが停止したことを確認してから新しいプロセスを起動してください。デスクトップセッションの終了時にクライアントが停止するかどうかと、システムサービスが動作し続けるかどうかは別です。導入目的に応じて設定しましょう。アンインストールする場合は、まずデスクトッププロキシを元に戻し、サービスを停止して追加のルートを解除してから、プログラムを削除します。環境変数や自動起動タスクが残っていると、プログラムの削除後も次回ログイン時に接続エラーが起きることがあります。

設定に関するよくある質問：ポート、DNS、ルールのトラブル対処

テスト条件を固定してから設定を変更する

トラブル対処は「アプリが通信に接続しているか」「ルールがどの接続先を選んだか」「プロキシに接続できるか」「名前解決が正しいか」の順に進めます。対象アプリ、ドメイン、プロキシを一つずつ決め、システムプロキシまたはTUNの状態を記録してから接続ログを確認しましょう。プロキシ、DNS、ポートを同時に変更したり、クライアントを再インストールしたりしないでください。通信が復旧しても原因が分からず、次回のトラブル対処に活かせません。

以下は、よく使われる設定項目の役割と適用範囲です。クライアントがサブスクリプションの値を画面上で上書きする場合があるため、問題を調べる際は実行中の設定を確認してください。DNSの待ち受けポートとmixed-portは用途が異なります。数字が近くても相互に置き換えられません。ローカルの接続口を公開する場合は、待ち受けアドレスを任意の値に変更する前に、利用者とネットワークの範囲を明確にしましょう。

項目	用途と注意点
`mixed-port`	HTTPとSOCKSで共用する接続口。アプリには実際の待ち受けポートを指定する必要があります。
`allow-lan`	LANからの接続を許可するかどうか。待ち受けアドレスとファイアウォールも確認してください。
`mode`	rule、global、directを選択します。システムサービスを自動でインストールする機能ではありません。
`dns.enhanced-mode`	DNSの動作方式を選択します。実際の名前解決経路の確認には別途対応が必要です。
`tun.auto-route`	コアが関連するルートを設定します。権限が必要で、既存のネットワークに影響する場合があります。

症状に応じて確認する

サブスクリプションの更新に成功したのに接続できないのはなぜですか？

更新した設定が現在有効な設定か確認し、次に選択中のグループが実際の接続先を指しているか調べます。空のグループやdirectになっていないかも確認してください。その後、コアが正常に待ち受けているか、アプリが接続ログに表示されるかを確認します。ログがまったくない場合は、システムプロキシ、アプリごとの振り分け、TUNによる通信の取り込みを優先して確認してください。ログに接続記録があり、プロキシへの接続が失敗する場合は、アカウントの状態、プロトコルの対応状況、接続先への到達性を調べます。サブスクリプションの取得とプロキシへの接続は別の通信です。前者の成功だけで後者を確認したことにはなりません。

ルールモードでは失敗し、グローバルモードでは成功します。原因はどう調べればよいですか？

同じ接続先を維持したまま、両方のモードで失敗したリクエストの経路を比較します。ルールモードではdirect、REJECT、別のプロキシグループに振り分けられている可能性があります。ドメインの識別が想定と異なり、フォールバックルールが適用されている場合もあります。ルールの順番とルールプロバイダーの更新状況を確認し、ルールの誤りをグローバルモードで隠したままにしないでください。モードの基本的な違いはガイドのプロキシモード解説を、具体的な構文は用語集をご覧ください。

ドメインに接続できないのに、ネットワークとプロキシは正常に見える場合は？

まず失敗するドメインが名前解決できるか確認し、ブラウザーのセキュアDNS、システムDNS、クライアントのDNSで異なる経路が使われていないか調べます。fake-ipは内部マッピング用のアドレスを返します。これをリモートサーバーのアドレスとして直接テストしないでください。LAN内のデバイス検出や特殊なドメインとの互換性に問題がある場合は、対象のドメインに応じてフィルタリングや名前解決の方針を検討し、すべてのドメインを例外に追加するのは避けましょう。使用する設定項目が現在のコアに対応していることも確認してください。

TUNを有効にした後、LANや社内リソースにアクセスできない場合は？

まずTUNを無効にし、元のネットワークが正常か確認してから、プライベートネットワークのルート、社内DNS、会社のVPNとの優先順位を調べます。directルールを一つ追加するだけでは、誤ったシステムルートや名前解決経路が直らないことがあります。ドメインによってプロキシ経由の名前解決と直接の名前解決を使い分ける必要がある場合は、明確なDNSポリシーを定めてください。管理対象端末のネットワーク要件は管理者に確認し、制限を回避するために組織の設定やセキュリティ機能を削除しないでください。

設定のプロキシグループ名とルールの接続先は、どう対応させればよいですか？

ルールの接続先名は、定義済みのプロキシ、プロキシグループ、または組み込みの接続先と一致している必要があります。大文字・小文字や文字列を正確に合わせてください。例にあるPROXYが自動で用意されるわけではありません。以下の例では「サブスクリプションの接続先」という有効なプロキシがすでにあることを前提に、選択グループとルールの関係だけを示します。設定に追加する前に、実在する接続先の名前に置き換え、対象ドメインに先に適用されるルールがないか確認してください。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - サブスクリプションの接続先
      - DIRECT

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

通信速度が遅い場合、すぐにTUNのスタックやDNSを変更するべきですか？

同じ時間帯、同じ接続先でプロキシを比較し、次にローカルWi-Fi、帯域の使用状況、リモート側の回線を確認します。DNSが影響するのは主に名前解決の段階です。ダウンロードが遅いというだけでは、DNSの変更で説明できません。ログや比較テストから端末側の通信取り込みが原因と分かった場合に限り、TUN関連の項目を一つずつ調整しましょう。段階的な確認方法はClashの通信速度が遅い場合の3段階チェックをご覧ください。変更のたびに、元に戻せるよう記録を残してください。

元に戻せる方法で設定を管理する

原因を確認したら、必要な変更はクライアントが対応する上書き設定やマージ設定に追加し、ダウンロードしたサブスクリプションのファイルを直接編集し続けるのは避けましょう。最小構成で動作する設定を基準として保存し、ルールを追加するたびに構文を確認してから、プロキシ接続と直接接続の両方をテストしてください。サポートを依頼する際は、問題に関係する機密情報を隠した設定の一部、エラーの行番号、再現手順だけを共有します。設定全体、アカウント情報を含むURL、ローカル管理用のキーを公開の添付ファイルにしないでください。