使い方ガイド · OS別に見る

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

ダウンロード、サブスクリプションの追加、通信のプロキシ化を行い、ログで設定を確認します。

初めて使う場合は、まずスタートガイドに沿って接続まで進めてください。このページはリファレンスとして、デバイス別のインストール手順や、サブスクリプション、権限、ルーティングの問題を調べるためのものです。設定のトラブルはページ末尾の項目を確認してください。インストーラーはダウンロードから入手できます。すべての章を最初から読む必要はありません。

デスクトップ・モバイル対応 GUIクライアント・コマンドライン 実用的なルールと設定例

共通の準備：クライアント、サブスクリプション、通信の振り分け

画面・コア・設定ファイルの違いを理解する

Clashは一般に、ルールベースのプロキシツールを指します。実際に使うには、具体的なクライアントを選ぶ必要があります。クライアントは画面の表示、設定の管理、システム権限の取得を担い、コアは通信の受け付け、ドメイン名の解決、ルールに基づく振り分けを行います。mihomoは、このエコシステムで使われるコアの一つです。画面が正常に開いても、コアが起動しているとは限りません。ノード一覧が表示されても、システムの通信がプロキシに渡されているとは限りません。

一般的な用途なら、まずClash Plusをお試しください。別の画面や機能が必要な場合は、ダウンロードページのOS別一覧を確認してください。複数のクライアントで同時に通信を振り分ける設定は避けましょう。ローカルポート、システムプロキシ、仮想インターフェースが競合する可能性があります。移行時は、旧クライアントのポートと通信の振り分け方法を控えてから終了し、新しいクライアントを有効にしてください。変更の原因を特定しやすくなります。

設定ファイルには通常YAML形式が使われ、ノード、プロキシグループ、ルール、DNSなどが記述されています。クライアントによって対応するインポート形式は異なるため、拡張子だけで互換性を判断できません。読み込みに失敗したら、まずログで構文エラー、未対応フィールド、ダウンロードエラーのどれかを確認し、ファイルを修正するかサブスクリプション形式を変更するか判断してください。

サブスクリプションを用意し、認証情報を保護する

クライアントをインストールしただけでは、プロキシサービスは利用できません。開始前に、利用権限のあるサブスクリプションURLまたはローカル設定を用意し、有効期限内であることを確認してください。URLは提供元のコピー機能を使い、説明文や改行、末尾の空白が混ざらないようにします。ノードの共有リンクしかない場合は、クライアントがその形式に対応しているか確認してください。任意のWebページのURLをサブスクリプションとして追加することはできません。

サブスクリプションURLには認証情報が含まれる場合があるため、パスワードと同様に扱ってください。問題を調べるときはエラーの種類だけを伝え、公開コメント欄にURL全体を貼り付けたり、実際のノードパスワードを含む設定をアップロードしたりしないでください。相談する場合は、サブスクリプションのパラメーター、サーバーアドレス、認証情報を削除し、フィールド名、インデント、エラー行付近の構造を残してください。サブスクリプション変換を行う前に、サブスクリプション変換の説明をお読みください。

追加に成功したら、まず現在の設定として選択されていることを確認し、プロキシグループに選択可能なノードがあるか調べてください。クライアントによっては、設定のダウンロードと適用が別の操作になっています。更新ボタンが成功しても、ファイルを取得できたことしか示しません。新しい設定の読み込みに失敗した場合、以前の設定が引き続き使われていることもあります。現在の設定名とログを確認し、成功の表示だけで判断しないでください。

システムプロキシかTUNを選び、二重の通信振り分けを避ける

システムプロキシは、システムのプロキシ設定に従うアプリの通信をローカルの待受ポートへ転送します。まずブラウザーで動作を確認するのに適しています。TUNは仮想ネットワークインターフェースで、より多くの種類の通信を受け付ける方式です。ルーティングやDNSの設定も関係します。単純な上位・下位の関係ではありません。システムプロキシで足りるなら、まず通信の振り分け範囲を狭く保ちましょう。システムプロキシに従わないアプリがある場合は、TUNを検討してください。

通信の振り分け方法主な対象最初に確認する項目
システムプロキシシステムプロキシ設定に従うアプリローカルポート、アプリ独自のプロキシ設定
TUN仮想インターフェースとルート経由の通信システム権限、ルートの除外設定、DNS
アプリごとの設定指定したブラウザー、ターミナル、その他のプログラムプロキシプロトコル、アドレス、ポート

インストール前に、ほかのVPNやプロキシソフトを一時終了してください。特にデフォルトルートを変更するツールには注意が必要です。会社のデバイスでは組織のポリシーによる制限がある場合があるため、管理上の要件を回避しないでください。ネットワークへの接続にWeb認証が必要な場合は、プロキシを有効にする前に認証を済ませましょう。そうしないと、サブスクリプションの取得時に設定ファイルではなく認証ページが返されることがあります。

この順序で初回接続を確認する

まずコアを起動し、設定を追加して適用します。次にルールモードを選び、ノードを一つ指定してから、通信の振り分け方法を一つだけ有効にしてください。クライアントの接続画面を開き、確認用のサイトにアクセスして、対応する通信とルールの記録が表示されるか確認します。検証では一度に変更する設定を一つにし、元の値も控えておきましょう。ノード、DNS、モードを同時に変更すると、成功しても失敗しても原因を特定しにくくなります。

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

アーキテクチャに合ったパッケージを選び、初回起動する

WindowsのダウンロードからClash Plusをお選びください。必要に応じてClash Verge Rev、FlClash、Clash Nyanpasuも利用できます。Clash for Windowsは開発終了しているため、アーカイブ版は旧環境からの移行向けです。新しいデバイスでの標準的な選択肢には適しません。名前が似ていても、クライアントごとに設定フォルダーは異なります。切り替える前に必要な設定をエクスポートしてください。

Windowsの設定で「システム」から「バージョン情報」を開き、プロセッサーのアーキテクチャとOSのビット数を確認してください。ダウンロードページにデバイスに適したビルドがない場合、ファイル名を変更してインストールしないでください。インストーラーを実行し、画面の案内に従って保存先を選びます。初回起動は通常のユーザー権限で行い、システムサービスやドライバーのインストールなど、管理者権限が明示的に必要な場合にのみ許可してください。

ファイアウォールの確認画面が表示されたら、実際の利用範囲に応じて許可するか判断してください。このPCだけで使うプロキシなら、ほかのデバイスからアクセスできるLAN向けの待受を開く必要はありません。家庭内のデバイスで共有する場合は、ネットワークの種類、待受アドレス、ファイアウォールの範囲を確認してください。プログラムを起動するためだけにファイアウォール全体を無効化すると、問題と無関係なネットワークアクセスまで許可することになります。

サブスクリプションを追加し、設定が有効か確認する

設定またはサブスクリプションの画面を開き、URLから追加する項目に完全なサブスクリプションURLを貼り付け、識別しやすい名前を付けます。ダウンロードが終わったら、その設定を選択し、プロキシグループにノードが表示されることを確認してください。まずルールモードを使い、手動でノードを一つ選びましょう。初回のトラブル調査で、自動的なポリシー切り替えの影響を避けられます。サブスクリプションの準備方法はサブスクリプション追加ガイドをご覧ください。

クライアントで解析エラーが表示されたら、ログでエラー箇所を確認してください。YAMLのインデントにはスペースを使い、リスト項目の前のハイフンも構造上の意味を持ちます。別のクライアント向けの設定全体を、そのまま上書きしないでください。拡張フィールドの中には特定のコアだけが対応しているものがあります。新しい設定を読み込めない場合は、以前の正常な設定に戻してから新しいファイルを個別に確認し、端末全体がネットワークに接続できなくなる事態を避けましょう。

まずシステムプロキシを確認し、必要に応じてTUNを有効にする

クライアントでシステムプロキシを有効にしたら、Windowsのプロキシ設定でローカルアドレスとポートを確認してください。画面にはHTTPポートが表示される場合も、混合ポートが表示される場合もあります。現在のクライアント設定を基準にしてください。ブラウザーではアクセスできるのに特定のアプリでできない場合、そのアプリ独自のプロキシ設定がないか、システムプロキシを無視していないか確認しましょう。すぐにノードの故障と判断しないでください。

TUNを使う場合は、クライアントの案内に従ってサービスモードや関連するネットワークコンポーネントをインストールしてから、TUNを有効にしてください。サービスのインストール完了と、サービスの実行中は別の状態です。スイッチがすぐにオフに戻る場合は、ログで権限、デバイスの作成、ルート設定のエラーを確認してください。有効になった後は、システムトレイのアイコンだけでなく、接続画面に対象アプリの通信が記録されているか調べましょう。

一部のセキュリティソフトは、仮想ネットワークアダプター、サービスプロセス、ネットワークフィルターの操作を制限します。ログに明確な理由がある場合は、該当する権限を確認してください。クライアントのフォルダー全体を広範な除外対象にする必要はありません。別のVPNが動作中なら、終了してから再度試してください。社内ネットワーク、リモートデスクトップ、プリンターに接続する場合は、TUNを有効にする前に、プライベートネットワークのルートが誤って振り分けられないことを確認してください。

終了後にインターネットへ接続できない・ポートが使用中

クライアントを終了した後も、Windowsのシステムプロキシが停止済みのローカルプロキシを参照していると、その設定に従うアプリは接続できません。まずクライアントを再起動してシステムプロキシをオフにし、設定が元に戻ったか確認してください。今後使わない場合は、残っている手動プロキシ設定を削除します。組織から配布された自動構成スクリプトや既存のネットワークポリシーは、安易に削除しないでください。

ログに待ち受けの失敗が記録されている場合は、旧クライアントがポートを使用していないか確認してください。以下のコマンドは例示したポートの待ち受け状態を調べるものです。実際のポートが異なる場合は、設定画面に表示された値に変更してください。プロセス番号から該当プログラムを確認し、競合するプログラムは強制終了ではなく、通常の手順で終了させてください。

netstat -ano | findstr :7890

ブラウザー独自のプロキシ拡張機能が有効な場合、システム設定が正しくても古いポートに接続し続けることがあります。テスト時は拡張機能を一時停止し、標準のネットワーク設定で結果を比較してください。PCの再起動で一部の一時的な状態はリセットできますが、プロキシアドレス、サービスの状態、設定エラーの確認に代わるものではありません。接続が戻ったら原因を記録し、次回の起動時に再発しないようにしましょう。

自動起動を設定する際は、状態を確認できるようにする

まず通常の起動、接続、終了を一通り確認してから、自動起動を設定してください。GUIの起動、バックグラウンドサービスの起動、プロキシの自動有効化は、それぞれ別の設定の場合があります。画面が起動しただけで通信が振り分けられていると判断しないでください。ログイン後に現在の設定と接続記録を確認し、ユーザーセッションより早くサービスが起動する場合は、ユーザーフォルダー内の設定を読み込めるか確認しましょう。共通の確認方法は自動起動のトラブル対処、OS別の詳しい手順はWindowsのインストールとファイアウォール設定ガイドをご覧ください。

macOS：インストールの許可、ヘルパーサービス、ネットワーク拡張

チップのアーキテクチャとクライアントのサポート状況を確認する

Appleメニューの「このMacについて」でAppleシリコン搭載機かIntelプロセッサ搭載機かを確認し、macOSのダウンロードから対応するインストーラーを選んでください。Clash Plusを推奨します。Clash Verge RevやFlClashも利用できます。ClashX Metaは開発終了しており、主に旧設定との互換性確保や移行に使われます。クライアント名にMetaとあることだけで、現在も開発が続いていると判断しないでください。

ディスクイメージを開き、アプリを「アプリケーション」フォルダーにコピーしてから起動してください。ダウンロードフォルダーやディスクイメージから直接実行すると、ヘルパーサービスのパス、自動起動項目、アップデートの動作が不安定になる場合があります。既存ファイルとの競合が表示されたら、まず実行中のクライアントを終了して設定をバックアップし、通常の手順で置き換えてください。自動起動するコピーを複数残さないようにしましょう。

初回起動時のセキュリティ警告は、入手元を踏まえて判断してください。信頼できる配布元から再度ダウンロードし、ファイルのダウンロードが完了していることと、システムに対応していることを確認しましょう。ネット上で共有されている、システム保護を一括で無効にするコマンドを安易に実行しないでください。「破損している」などの警告や起動できない問題が続く場合は、macOSのインストールと許可に関するガイドに沿って項目ごとに対処してください。すべての警告を同じ原因と決めつけないようにしましょう。

サブスクリプションを追加し、アプリの権限と設定の問題を切り分ける

起動後に設定管理を開き、サブスクリプションURLを追加します。取得が完了したら現在の設定に指定してください。ノードが表示されたら、ルールモードと手動ノードを選びます。追加に成功しても一覧が空の場合は、サブスクリプションからログインページやエラー説明が返されていないか、クライアントがその形式に対応しているかを確認してください。システムにネットワーク権限を許可しても、サブスクリプションの構文エラーは解決しません。問題を分けて確認しましょう。

システムプロキシの設定や、高い権限が必要なネットワーク操作のために、クライアントからヘルパーツールのインストールを求められる場合があります。実行中の操作に合った許可だけを承認し、アプリ名も確認してください。システムアカウントのパスワード入力は、通常、システム変更の許可を求めるものです。サブスクリプションにそのパスワードが保存されるわけではありません。許可の要求が繰り返される場合は、ヘルパーサービスのインストール状況とアプリの保存場所が変わっていないか確認してください。

キーチェーンの警告は個別に判断してください。アプリによる機密設定の保存や読み込みに関係する場合があり、プロキシを使っているという理由だけですべての要求を許可すべきではありません。アカウントのパスワード変更やシステム移行が、キーチェーンの読み込みに影響することもあります。要求元が使用中のアプリであることを確認し、システムの案内に従ってください。関係のないキーチェーンの問題をノードの認証エラーと誤認しないようにしましょう。

現在のネットワークサービスのシステムプロキシを確認する

システムプロキシを有効にしたら、システム設定のネットワーク詳細で現在使用中のネットワークサービスを確認してください。Wi-Fi、有線ネットワーク、その他の接続には、それぞれ別のプロキシ設定が保存されていることがあります。一つのネットワークで有効でも、別のネットワークに切り替えた後も同じとは限りません。自動プロキシ設定スクリプトを使う職場環境では、クライアントが組織指定のプロキシを上書きしないよう、元の設定を確認してください。

テストには、まずシステムプロキシ設定に従うブラウザーを使い、クライアントの接続画面で対象のドメインを探してください。ターミナルのツールがGUIのシステムプロキシ設定を自動的に読み込むとは限りません。ターミナルから接続できないだけで、システムプロキシが無効とは判断できません。アプリ独自のプロキシ設定がある場合は、経路を一つに絞りましょう。システムプロキシがクライアントを参照し、そのクライアントがさらに別のプロキシツールに転送するようなループを避けてください。

クライアントを終了する前にシステムプロキシをオフにし、直接接続が戻るか確認してください。異常終了でローカルプロキシの設定が残った場合は、クライアントを再度開いて状態を復元し、通常の手順で終了できます。手動で削除する際は、クライアントに属することが確実な項目だけを変更してください。必要な自動検出、自動構成、その他のネットワークサービスの設定を残し、一つの問題を直すためにネットワーク全体の設定を壊さないようにしましょう。

TUN、ネットワーク拡張、社内ネットワークへのルート

macOSクライアントによって、通信の振り分けにはヘルパーサービス、仮想インターフェース、ネットワーク拡張など異なる方式が使われます。すべてのソフトで同じ許可画面が表示されるとは限らないため、使用中のクライアントの説明に従ってください。ネットワーク拡張の許可が求められた場合は、システム設定のプライバシーやセキュリティ、拡張機能の管理画面で許可し、クライアントに戻って状態を確認します。

TUNを有効にできない場合は、まずシステム権限とヘルパーサービス、次にルートとDNSを確認してください。有効にすると一部のサイトにしかアクセスできない場合は、別のVPN、フィルタリングソフト、企業ネットワーク用コンポーネントが経路を変更していないか確認しましょう。不要なツールを一つずつ停止して比較し、ネットワークサービスをまとめて削除しないでください。LAN内のデバイスに接続できない場合は、プライベートネットワークへの直接接続とルート除外を確認します。

スリープから復帰した後に一時的なネットワーク変化が起きた場合も、個別に記録してください。デバイスのIPアドレス、デフォルトゲートウェイ、DNSが変わり、バックグラウンド接続に古い状態が残ることがあります。ネットワーク接続が完了するまで待ち、コアのログを確認して、必要な場合に限り通信の振り分け機能を再起動します。復旧のたびにシステム全体の再起動が必要なら、前後のログを保存してください。サブスクリプションを何度も変更するより、原因の特定に役立ちます。

Android：アプリのインストール、VPNの許可、バックグラウンド動作

アーキテクチャに合ったアプリを選び、既存の設定を保存する

Androidのダウンロードからインストーラーを選んでください。Clash Plusを推奨します。ほかにClash Meta for Android、FlClash、Surfboardも選べます。新しめのデバイスの多くはARM64ですが、端末のアーキテクチャとクライアントの対応状況を確認してください。汎用パッケージは、アーキテクチャを特定できず、ダウンロードページに対応ビルドが明記されている場合に利用できます。すべてのスマートフォンが同じプロセッサー環境だと考えないでください。

ブラウザーやファイル管理アプリからインストールする場合、Androidでその提供元からのアプリのインストールを許可する必要があります。今回使う提供元に限って必要な権限を許可し、インストール後は元の設定に戻してください。アップデート時に署名の不一致が表示されても、すぐに旧アプリをアンインストールしないでください。サブスクリプション名、アプリごとの設定、ローカル上書きをバックアップし、インストーラーの配布元と同じクライアントのものかを確認しましょう。

システムのバージョンやメーカー独自のカスタマイズ、アプリ権限の管理方法によってメニューの場所は異なりますが、確認する順序は同じです。まずインストールと起動ができることを確認し、その後で通信の振り分けを設定します。起動直後にアプリが終了する場合は、システムとの互換性やインストーラーのアーキテクチャを確認してください。DNSを変更しても解決しません。不明な配布元のドライバー修正ツールをインストールしないでください。Androidクライアントは通常、システムのVPNインターフェースを使用します。

サブスクリプションを追加し、初回のVPN確認画面を理解する

設定管理を開き、リモートサブスクリプションを追加するか、ローカルファイルをインポートしてください。設定に名前を付けて更新し、現在の設定に切り替えた後、プロキシグループにノードがあるか確認します。クライアントによっては、更新後にメイン画面へ戻って接続を開始する必要があります。ファイルをインポートした場合、リモートサブスクリプションの更新ではローカルコピーは自動更新されません。古いノードを使い続けないよう、更新元を把握しておきましょう。

初めて接続するとき、システムからVPN接続の作成を求められます。ここでいうVPNはAndroidが提供する通信の振り分け用インターフェースであり、別会社の従来型VPNサービスに自動接続するという意味ではありません。許可すると、クライアントはシステムから渡される通信を受け取れるようになります。許可しない場合、ノード一覧とルールが読み込まれていても、アプリの通信は振り分けられません。

Androidでは通常、一般的なVPNインターフェースを同時に使用できるアプリは一つです。別のVPN、ローカルVPNを使うフィルタリングツール、一部のファイアウォールアプリを起動すると、現在の接続が置き換わる場合があります。スイッチがすぐオフになる、または状態が変わり続ける場合は、サブスクリプションやノードを調べる前に、ほかのアプリがインターフェースを使用していないか確認してください。同じURLを何度も追加し直す必要はありません。

アプリごとのプロキシ設定とLANアクセス

Androidクライアントは通常、デスクトップのシステムプロキシスイッチを使わず、VPNで振り分ける範囲内の通信を処理します。アプリごとの設定には「選択したアプリのみをプロキシ」のほか、「選択したアプリを除外」の場合もあり、意味が正反対です。変更する前に現在のモードの説明を読み、一つのアプリで接続記録を確認してから、対象を追加してください。

特定のアプリが接続画面に表示されない場合は、除外されていないか、仕事用プロファイルにあるか、別ユーザーで実行されているか確認してください。個人用と仕事用のプロファイルでは、システムが提供するネットワーク範囲が異なる場合があります。アプリごとの設定を変更した後、VPNの再接続や対象アプリの再起動が必要なことがあります。既存の接続は新しい振り分け経路に自動で切り替わりません。

画面のキャスト、プリンター、ルーターの管理画面などはLANアクセスを必要とします。プロキシを有効にした後、こうした機能が使えなくなった場合は、プライベートアドレスへの直接接続ルールと、クライアントのLAN除外設定を確認してください。LANからスマートフォンのプロキシに接続できるようにすることと、スマートフォン自身がLAN通信を迂回することは別の機能です。前者は待受と共有、後者はルーティングの範囲に関係します。一つのスイッチで両方を制御できるとは限りません。

実際の切断原因に応じてバックグラウンド動作を調整する

画面が点灯している間は正常で、ロック後に切断される場合は、まずバッテリー最適化、バックグラウンド実行、メーカー独自のアプリ終了機能を確認してください。クライアントに必要な範囲でバックグラウンド動作を許可し、画面をロックして再度テストします。システムのVPNアイコンと、アプリを開き直した後のログを確認してください。すべてのアプリにバックグラウンド権限を与える必要も、電池消費の警告だけでコアの故障と判断する必要もありません。実際に通信が切断されたかを確認しましょう。

「常時接続VPN」と「VPN未接続時に接続をブロック」はシステムレベルの機能です。有効にする前に、解除方法を確認してください。後者を有効にすると、VPNが接続されていない間はネットワークが制限されます。サブスクリプションやクライアントに問題が起きた場合、端末全体がオフラインになることもあります。設定が安定していることと、システムのVPN設定を開く方法を確認してから有効にするか判断してください。接続エラーを直すためのスイッチではありません。

Wi-Fiからモバイルネットワークに切り替えた後は、古い接続の再確立が必要な場合があります。モバイルネットワークでは、IPv6、UDPの対応状況、ノードまでの経路も異なることがあります。まず同じノードを両方のネットワークで試し、その後にノードやプロトコルを変更してください。一つのアプリだけが失敗する場合はアプリごとの対象範囲を、すべてのアプリが失敗する場合はVPNの状態とデフォルトネットワークを確認します。影響範囲に応じて原因を絞り込みましょう。

iOS：App Storeからのインストール、設定の追加、オンデマンド接続

Clash Plusをインストールし、機能の場所を確認する

iPhoneとiPadには、App StoreからClash Plusをインストールできます。製品情報は公式サイトのclashplus.ioをご覧ください。先にiOSのダウンロード案内を確認することもできます。インストール後はアプリを開き、設定、ポリシー、接続状態の場所を確認してから、既存のサブスクリプションを追加しましょう。システムのVPN設定画面をサブスクリプション管理画面と混同しないようにしてください。

モバイルOSの通信振り分け方法はデスクトップとは異なります。Windowsのサービスインストール手順をそのまま使ったり、同じ名前の仮想ネットワークアダプター用ドライバーを探したりする必要はありません。クライアントは通常、システムのネットワーク拡張機能を使ってVPN設定を作成します。システム設定で管理するのは許可と接続状態です。ノード、プロキシグループ、ルールは引き続きクライアントで管理するため、両方の画面の情報は用途が異なります。

初回起動時に通知、ネットワーク、その他の権限を求められる場合があります。用途を確認して一つずつ判断してください。初回接続で求められるVPN設定の許可と、通常の通知権限は別のものです。通信の振り分けを許可しなかった場合は、アプリに戻って接続を再度開始し、システムの案内に従ってください。通知を許可しただけではプロキシは有効にならず、サブスクリプションの不足も解決しません。

サブスクリプション追加後は、接続を繰り返す前にポリシーを確認する

アプリの設定管理でサブスクリプションを追加し、完全なURLを貼り付けて更新してください。共有メニューからファイルを追加する場合は、Webページを保存したものではなく、対応する設定が実際に含まれていることを確認します。追加後は現在の設定に指定し、プロキシグループで選べる項目を確認してください。設定名は端末内で識別するためのものなので、用途に合わせて付けられます。アカウントのパスワードや完全なアクセスURLは名前に含めないでください。

ノードが表示されてもアクセスできない場合は、まずノードを一つ指定し、現在のモードを確認してください。ルールモードではルールに基づいてポリシーが選択されます。グローバルモードでは対象となる通信がグローバルポリシーに渡されますが、ノードの故障は解決しません。初回の検証では変数を一時的に減らしてかまいませんが、日常利用ではアクセス要件や社内ネットワークの要件に合わせてモードを選びましょう。誤ったルールを隠すためにグローバルモードを常用する必要はありません。

サブスクリプションの更新と、すでに確立した接続は別の処理です。更新に成功したら、現在の設定に適用されていることを確認してください。既存の長時間接続は、古い経路を使い続けることがあります。新しい設定を試すときは、対象アプリを開き直し、必要ならVPNを再接続してから、クライアントで新しい接続記録を確認しましょう。同じキャッシュ済みページを更新するだけで、新しいルールが適用されたか判断しないでください。

VPNの状態、オンデマンド接続、ほかのネットワークツール

接続を開始してシステムのVPN設定を許可したら、システム設定で接続状態を確認し、テスト用のサイトにアクセスしてください。VPNが接続済みと表示されていれば、システムの通信経路は確立していますが、上流のノードが使えるとは限りません。ログに接続が記録されているのにリクエストが失敗し続ける場合は、ノード認証、サーバーへの到達性、ルールの対象を確認してください。システムのVPN設定を何度も削除する必要はありません。

オンデマンド接続は、条件を満たしたときにシステムが接続を開始する機能です。アプリを常に前面に表示する機能ではありません。条件にはネットワークの種類やクライアントのポリシーが関係することがあります。詳細は現在の画面で確認してください。初めは手動接続で正常に動作するか確かめてから、オンデマンドルールを有効にしましょう。自動再接続が問題の調査中に接続を復旧させると、スイッチを切れないように見える場合があります。

別のVPNや、同じくネットワーク拡張を使うツールが現在の通信経路に影響することがあります。調査時は不要なツールを一時停止し、システムのVPN設定に古い項目が残っていないか確認してください。古い設定が不要と確認できた場合にのみ、対応するアプリの接続を停止してから削除します。管理対象デバイスのネットワークポリシーは変更できない場合があるため、デバイス管理の要件に従い、回避しようとしないでください。

ネットワーク、DNS、LANの範囲を切り分ける

ホテルや空港などのネットワークでは、認証ページを開く必要がある場合があります。認証前にプロキシへ自動接続すると、サブスクリプションの更新やノードへの接続が失敗することがあります。一時的にオンデマンド接続をオフにしてネットワーク認証を済ませてから、手動で接続してください。認証ページの転送先をサブスクリプションとして保存したり、公共Wi-Fiで失敗したからといって、元の有効な設定を上書きしたりしないでください。

Wi-Fiとモバイルネットワークでは通信経路が異なります。切り替え後に短時間再接続が起きた場合は、ネットワークの変化として状況を確認してください。特定のWi-Fiだけで失敗する場合は、そのネットワークの認証状態、DNS、ファイアウォール制限を比較します。すべてのネットワークで失敗する場合は、ノードとサブスクリプションを調べてください。テスト時にクライアントの接続画面へリクエストが記録されるか確認すると、通信の振り分け範囲の問題と上流接続の問題を切り分けられます。

LANの権限は、近くのデバイスを検出する一部のアプリに影響しますが、正しいプロキシルールの代わりにはなりません。家庭内のストレージ、キャスト機器、ルーターの管理画面に接続できない場合は、まず接続先がローカルアドレスか確認してから、クライアントの直接接続やバイパス設定を調べてください。開けないドメインをすべて直接接続に設定しないでください。プロキシが必要な宛先なら、問題をルール段階から直接接続段階に移すだけです。

iOSで確認できるログやバックグラウンド動作は、システムの仕組みによって制限されます。バックグラウンド画面からアプリを消しても、システムVPNが停止するとは限りません。Appスイッチャーにアプリが残っていても、接続が正常とは限りません。システムの接続状態、クライアントの記録、実際のアクセス結果を照らし合わせて判断してください。停止する場合は、オンデマンド接続を無効にしてVPNを切断し、ネットワークが想定した経路に戻ったことを確認しましょう。

Linux：デスクトップクライアントとmihomoバックグラウンドサービス

デスクトップへのインストールはディストリビューションに合ったパッケージを選ぶ

デスクトップ環境では、Linuxのダウンロードから推奨のClash Verge Revを選ぶか、FlClashを利用できます。ディストリビューションに合わせてDEBまたはRPMを選び、プロセッサーのアーキテクチャと実行環境の要件を確認してください。拡張子だけを見て別のディストリビューション向けパッケージをインストールしたり、依存関係を解決するためにシステムの重要なライブラリを置き換えたりしないでください。GUIが起動しない場合は、ターミナルから実行して依存関係のエラーを確認しましょう。

インストール後にサブスクリプションを追加し、設定を適用してノードを選ぶ手順は、ほかのデスクトップOSとほぼ同じです。ただし、システムプロキシの設定がすべてのデスクトップ環境やアプリに反映されるとは限りません。ブラウザー、ターミナル、パッケージ管理ツールでは、参照するプロキシ設定が異なることがあります。まずコアがローカルポートで待ち受けていることを確認し、必要なプログラムごとにプロキシを設定してください。デスクトップの設定が成功しただけで、すべてのプロセスの通信が振り分けられているとは限りません。

デスクトップ環境がない場合は、設定と実行ディレクトリを用意する

サーバーやルーターでは、mihomoコアを直接実行できます。システムのアーキテクチャに合ったバイナリを選び、展開して管理下の実行可能ディレクトリに配置してください。以下ではプログラムを/usr/local/bin/mihomo、設定を/etc/mihomo/config.yamlに置く例を示します。この節の例示パスであり、ほかのソフトウェアが使用しているディレクトリを上書きする必要はありません。

専用のサービスアカウントと作業ディレクトリを作成してから、既存の設定を配置し、設定ファイルの読み取り権限を制限してください。以下のコマンドは、該当ツールが利用できる一般的なLinux環境向けです。実行前にアカウントが存在しないことを確認してください。設定で参照するルールセット、データベース、相対パスの権限も作業ディレクトリを基準に確認します。メインの設定ファイルだけを読み取り可能にし、依存ファイルを見落とさないでください。

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -o mihomo -g mihomo -m 0750 /etc/mihomo
sudo install -o mihomo -g mihomo -m 0640 ./config.yaml /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo

テストコマンドが成功しても、確認できるのは設定を解析・検査できたことだけです。ノードが利用可能であるとは限りません。初回起動時に、設定から参照されるリソースを取得する必要がある場合もあります。ネットワーク制限やディレクトリへの書き込み権限が取得を妨げることがあります。構文解析の成功をデプロイ完了とみなさず、プロセス、待受ポート、実際のリクエストを確認してください。特に、データベースのリソースエラーとノードのエラーを区別しましょう。

systemdで通常のプロキシサービスを管理する

以下のサービスユニットは、TUNを有効にせず、ネットワーク管理権限も追加しない、本機向けの通常のプロキシ待受を想定しています。内容を/etc/systemd/system/mihomo.serviceに保存し、実行パスが実際の配置場所と一致していることを確認してください。systemdを使わないディストリビューションでは、無理にコマンドを流用せず、そのシステム標準のサービス管理方式を使いましょう。

[Unit]
Description=mihomo local proxy
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
UMask=0077

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
sudo journalctl -u mihomo -b --no-pager -n 80

「ネットワークの準備完了」という状態でも、外部のサブスクリプションURLへアクセスできるとは限りません。サービス起動時にリソースの取得に失敗した場合は、ログを確認し、リソースの管理方法に沿って対処してください。無制限に再起動するだけでは解決しません。設定を変更する前に、使用可能なコピーを保存してからテストし、サービスを再起動しましょう。再起動ループが起きた場合はいったん停止し、設定を修正してから起動してください。上流への失敗リクエストを送り続ける事態を避けられます。

ターミナルのプロキシ、リモート接続、TUNの権限

一時的なターミナル作業では、現在のシェルにプロキシ環境変数を設定できます。以下の例では混合ポートを7890としています。これらの変数を読み取るプログラムだけに適用され、システムのルートは自動で変更されません。ローカルサービスはプロキシ対象外に指定し、ループバックアドレスへのアクセスがプロキシ経由にならないようにしてください。SOCKSやリモートDNSに対応しているかは、各ツールのドキュメントを確認してください。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1
curl -I https://example.com

# 現在のターミナルで一時設定を解除する
unset http_proxy https_proxy no_proxy

SSHでサーバーを管理する場合は、ルートを変更する前に、管理用の接続をもう一つ確保してください。TUNには仮想ネットワークデバイスへのアクセスと必要なネットワーク管理権限が必要です。上記の低権限サービスユニットでは、これらの操作を直接行えません。システムとクライアントの実装に合わせて権限を個別に設計し、すべてのサービスをrootで実行するだけの方法は避けてください。リモートマシンでは、SSHの戻り経路と管理用ネットワークの除外を事前に計画しましょう。

本機だけで使う場合は、待受アドレスをループバックの範囲に保ち、外部向けの制御インターフェースを公開しないでください。LANにプロキシを提供するには、待受アドレス、認証、ファイアウォールをあわせて検討する必要があります。「LANを許可」をオンにするだけでは不十分です。より詳しい構成はLinuxのヘッドレス環境とsystemdの設定ガイドをご覧ください。通常のプロキシが安定してから、TUNやリモート管理の要件を一つずつ追加してください。

設定のよくある質問：サブスクリプション、ルール、TUN、DNS

サブスクリプションの更新に失敗したら、リクエストと解析を切り分ける

更新に失敗したら、まず設定を取得できたか確認してください。タイムアウトは、現在のネットワーク、アクセス経路、サーバーの応答に原因があることが多くあります。認証エラーの場合は、サブスクリプションの有効期限とURLを確認します。Webページが返される場合は、ログイン画面、認証ページ、エラーページの可能性があります。すぐにURLを変換サービスへ送らないでください。変換では期限切れのサービスを修復できず、非公開のサブスクリプションを別の処理事業者に開示するおそれもあります。

ダウンロードは成功したのに解析に失敗する場合は、内容の形式、インデント、コアが対応するフィールドを確認してください。クライアントに前回成功した設定がキャッシュされていると、「まだ接続できる」ことは今回の更新が適用された証拠になりません。エラー行付近を機密情報が分からない形で保存し、クライアントの対応範囲と照らし合わせてください。プロキシ経由でサブスクリプションを更新する場合は、現在使える設定で接続できることを先に確認します。更新しないとネットワークに接続できないという循環を避けましょう。

ルールと上書き：上から順に照合し、変更元ごとに管理する

ルールは通常、上から順に確認され、最初に一致したルールでポリシーが決まります。末尾のMATCHは、ほかのルールに一致しなかった通信に適用されます。以下はルール構造の例です。設定にPROXYという名前のポリシーがすでに存在することを前提としています。ドメインルールと接続先IPルールでは判定条件が異なります。ドメインへの接続がIPルールで処理された場合は、ドメインの識別や名前解決の過程を確認してください。

mode: rule
mixed-port: 7890
allow-lan: false

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

手動ルールをフォールバックルールの後ろに書かないでください。サブスクリプションの更新で直接編集した内容が上書きされることがあります。長期的な変更には、クライアントが対応する上書き、マージ、ルール拡張の機能を使い、結合後の設定も確認してください。ポリシー名は空白や大文字・小文字も含めて完全に一致させる必要があります。別の設定からグループ名をコピーしても、対応するプロキシグループがなければ読み込みに失敗します。

TUNモード：権限、ルート、ループを確認する

TUNを有効にした直後に失敗する場合は、権限、サービス、仮想デバイスを確認してください。有効化後に端末全体がネットワークへ接続できなくなった場合は、デフォルトルート、DNS、ノードの出口を調べます。自動ルーティングでは、プロキシコア自身の出口が再びTUNに戻されないようにしてください。循環が発生する可能性があります。デスクトップクライアントが関連設定を管理している場合があるため、低レベルの設定を手動変更する前に、画面から生成されたルート設定と競合しないことを確認しましょう。

以下はmihomoのTUNフィールドの例で、すべてのクライアントにそのまま貼り付けられるものではありません。有効にする前に、プラットフォーム側で必要な権限を設定してください。DNSのリダイレクト範囲はシステム、ルーティング、実装によって異なります。社内ネットワーク、別のVPN、リモート管理を使う場合は、除外ルートを事前に計画しましょう。自動ルーティングがすべてのネットワークに適した既定設定だと考えないでください。

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

DNS：名前解決とプロキシ経路を分けて確認する

DNSはドメイン名をIPアドレスに変換し、ルールは接続に使用するポリシーを決めます。両者は関係しますが、同じ仕組みではありません。名前解決に失敗しているなら、ノードを変更しても解決しない場合があります。名前解決が正常でも接続に失敗するなら、DNSを変更する必要があるとは限りません。まずログでIPアドレスを取得できているか確認し、次に接続に適用されたルールとポリシーを調べてください。ブラウザーの暗号化DNSを有効にしている場合は、クライアントが使う予定の名前解決経路を迂回していないかも確認しましょう。

nameserverは通常の名前解決に使う上流を指定します。fallbackはフィルター条件と組み合わせて候補結果の使い方を決め、fake-ipは合成アドレスを使ってドメイン名との対応を保持します。IPアドレス形式の上流を使うと、上流のドメイン名を解決するための導入的な名前解決を避けられますが、すべてのネットワークに適しているとは限りません。以下は構造の例です。実際の到達性とプライバシー要件を踏まえて判断してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - '*.lan'
    - localhost

名前解決モードを変更した後も、システムやアプリに古いキャッシュが残り、既存の接続が古いアドレスを使い続ける場合があります。テスト中のアプリの古い接続を終了してから、プラットフォームに応じてキャッシュを消去するか、通信の振り分けを再確立してください。複数のフィールドを続けて変更しないでください。DNSリダイレクトは、すべての暗号化DNSを遮断する機能と同じではありません。フィールドの関係について詳しくはClashのDNS設定ガイドをご覧ください。

自動起動と復旧：3つの状態を切り分ける

自動起動では、画面の起動、コアの実行、プロキシによる通信の振り分けをそれぞれ確認してください。バックグラウンドサービスは実行中でも画面が開いていないことがあり、画面が起動していても設定が適用されていない場合があります。再起動後はログの時刻、現在の設定、待受ポートを確認し、システムプロキシやVPNの状態も検証してください。ネットワーク認証が未完了、ユーザーフォルダーがロック中、旧クライアントがポートを使用中などの理由で、起動時だけ失敗することがあります。

変更のたびに、変更したフィールド、元の値、テストしたネットワーク、結果を簡潔に記録してください。ネットワークに接続できなくなった場合は、新たに有効にした通信の振り分けをオフにし、前の設定に戻してから層ごとに調べましょう。公開の場で質問する場合は、機密情報を除いたログと、再現に必要な最小限の手順だけを共有してください。ノードの選び方に迷ったら、ノードの地域・プロトコル・速度測定の選び方を参考にしてください。一度の測定結果だけで設定全体を削除しないでください。

ルールモードとグローバルモードで結果が違う場合、ノードの故障ですか？

必ずしもそうではありません。モードによって別のポリシーが選ばれている可能性があります。まず接続記録のルール、プロキシグループ、実際に使われたノードを比較し、次にDNSを確認してください。同じ経路を使っていると確認できてから、ノード自体を比較しましょう。

クライアントは接続しているのに、特定のアプリが接続記録に表示されない場合は？

まず、そのアプリがシステムプロキシに従うか、アプリごとの一覧で除外されていないか、古い接続を使い続けていないか確認してください。通信の振り分け範囲を把握してから、TUNが必要か判断しましょう。最初にすべてのノードやDNSを変更しないでください。