Clashのインストール・設定ガイド｜サブスクリプション・システムプロキシ・TUN

共通の準備：設定の入手元と通信の取り込み方法

クライアント・コア・サブスクリプションの違い

クライアントは設定の保存、コアの起動、プロキシ設定、接続状況の表示を行う操作画面です。コアはプロトコルの解析、ルール判定、通信の転送を担います。サブスクリプションは設定の取得元で、ノード、グループ、ルール、DNS設定などが含まれる場合があります。クライアントをインストールしただけでは、利用可能な出口が用意されたことにはなりません。開始前に、サービス提供元の有効なサブスクリプションURL、または使用するコアに対応したYAMLファイルを準備してください。

このガイドでは、まずClash Plusを選択肢として紹介します。ほかのクライアントではボタン名が異なる場合がありますが、設定、プロキシ、接続、設定画面などの項目で構成されるのが一般的です。あるクライアントで読み込めたからといって、別のクライアントもすべての項目に対応するとは限りません。特にプロトコル拡張、ルールプロバイダー、スクリプト関連の設定は、使用するコアの対応状況を確認してください。解析エラーが出た場合は、まずエラーに示された項目名と行番号を確認しましょう。

サブスクリプションとシステム情報を確認する

サブスクリプションURLにはアクセス用の認証情報が含まれる場合があります。アカウントのパスワードと同様に慎重に管理し、URL全体を公開フォーラムやスクリーンショット、見知らぬオンライン変換サイトに貼り付けないでください。問い合わせる場合は、エラーの種類、クライアント名、OS、ネットワーク環境だけを共有しましょう。URLが漏えいした場合は、提供元に再発行を依頼してください。ローカルの記録を削除しても、すでに他者が得たアクセス権は取り消せません。

インストール前に、OSのバージョン、プロセッサーのアーキテクチャ、空き容量を確認してください。デスクトップではx64とARM64、MacではIntelとApple Silicon、Android端末ではARM64版APKに対応しているかを確認します。クライアントを切り替える前に、既存の設定やカスタムルールをバックアップしてください。テスト中はほかのプロキシやVPNソフトを終了し、システムプロキシ、仮想ネットワークアダプター、DNS設定を複数のソフトが同時に変更しないようにします。

通信の取り込み方法を選ぶ

方式	対象	注意点
システムプロキシ	システムプロキシ設定に従うブラウザーやアプリ	一部のゲーム、コマンドラインツール、独自のネットワークスタックを使うアプリは利用しません
TUN	仮想ネットワークアダプター経由でコアに入る通信	通常は追加の権限が必要で、ルーティングやDNS設定の影響を受けます
モバイル端末のVPNインターフェース	クライアントのネットワーク拡張機能が通信を取り込みます	システムの許可を確認し、アプリの除外範囲もチェックしてください
アプリごとの手動プロキシ設定	プロキシアドレスを個別に指定したアプリ	アドレス、ポート、プロトコルをクライアントの待ち受け設定に合わせます

システムプロキシとTUNは通信の取り込み方法、ルール・グローバル・DIRECTはルーティングの判断モードであり、別の階層にあります。TUNを有効にしてもルールモードは利用できます。また、ルールでDIRECTに振り分けられた通信も、いったんコアを経由してから直接送信される場合があります。トラブル時は「アプリの通信がクライアントに入っているか」と「入った後にどの出口へ進むか」を分けて確認し、スイッチ名だけでプロキシ接続済みと判断しないでください。

最小構成で接続を確認する

初回接続では、サブスクリプションの追加、設定の選択、利用可能なノードの選択、サービスの起動の4つだけを行います。デスクトップではまずシステムプロキシを試し、モバイルではVPNの許可を確認してください。最初はサブスクリプションに含まれるDNSとルールをそのまま使い、上書き、アプリ除外、LAN共有を同時に追加しないようにします。接続できたら、使用したネットワーク、ノード、取り込み方法を記録します。その後は設定を一つずつ変更し、どの変更が影響したか分かるようにしましょう。

確認時は、通常は直接接続するサイトと、ルール上プロキシ経由になるサイトを一つずつ開き、接続ログで適用されたポリシーを確認してください。ページが開いたことは、そのリクエストが成功したことを示すだけで、すべてのアプリ、ドメイン、UDP通信が利用できる証明にはなりません。記録には必要な情報だけを残してください。ログにはドメイン名、サブスクリプションURL、ローカルパスが含まれる場合があるため、共有前に機密情報を隠しましょう。

Windows：インストールとシステムプロキシ

インストーラーを選び、初回起動する

Windowsのダウンロードから、まずClash Plusをご確認ください。使い方に合わせてClash Verge Rev、FlClash、Clash Nyanpasuを選ぶこともできます。Clash for Windowsは開発が終了しています。過去の設定を移行する際の参考にはなりますが、新規インストールの標準候補には適しません。古いクライアントのフォルダーを別のアプリにそのまま上書きしないでください。設定ファイルや画面のデータベースに互換性がない場合があります。

「設定」から「システム」→「バージョン情報」を開き、システムの種類を確認して、ダウンロードページにある対応パッケージを選びます。インストール前に起動中のプロキシを終了し、インストーラーの案内に従って保存先を選択してください。初回起動時にネットワークアクセスの許可を求められた場合は、アプリの入手元とファイルの場所を確認したうえで、必要な範囲で許可します。ウィンドウを閉じても通知領域で動作し続ける場合があります。ポートの競合を調べる際は、タスクトレイのメニューから完全に終了してください。

サブスクリプションを追加して設定を選ぶ

設定またはサブスクリプションの画面を開き、新しいリモート設定を追加して、サービス提供元のURLを貼り付けます。ダウンロードと解析が終わり、設定名が表示されたら、有効化するか選択してください。画面によっては「追加済み」と表示されても、リストに保存されただけで、現在のコアに読み込まれていないことがあります。プロキシ画面に戻ってグループが表示されるか確認しましょう。空の場合は、設定が選択されているか、サブスクリプションがClash形式で返されているかを確認してください。

プロキシグループを開き、テスト用に実際のノードを一つ選択します。自動選択グループは疎通テストに依存する場合があり、追加直後は結果が揃っていないことがあります。すぐにすべてのノードが使えないと判断しないでください。サブスクリプションを更新する前に、カスタムルールを保存しましょう。リモート設定ファイルは更新時に置き換えられる場合があります。長期間残したいローカル設定は、キャッシュファイルを直接編集せず、クライアントの上書きや拡張機能を利用してください。

システムプロキシを有効にして待ち受けポートを確認する

コアを起動してから「システムプロキシ」を有効にします。通常はWindowsのプロキシアドレスがループバックアドレスとクライアントのポートに設定されます。ブラウザーで接続し直してからテストしてください。開いたままのタブは以前の接続を再利用している場合があります。ブラウザー拡張機能にも独自のプロキシ設定がある場合は、別経路へ通信が流れないよう、まず拡張機能側のプロキシ制御を無効にします。アプリ独自のプロキシ設定は、システムのスイッチに連動しないことがあります。

以下の混合ポートの例は、HTTPとSOCKSの両方のプロキシ接続を受け付けます。これはローカルの待ち受け方法を示すもので、ノードは含まれず、単独で完全なサブスクリプションとしては使えません。実際のポートはクライアントの現在の設定に合わせてください。画面に別の値が表示されている場合、例に合わせるためだけにサブスクリプションを変更する必要はありません。ループバックアドレスでの待ち受けは同じ端末からの接続に限られ、基本的な接続確認に適しています。

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

ポートを確認したら、PowerShellで次のコマンドを実行し、HTTPプロキシへの接続を個別にテストできます。プロキシを明示的に指定するため、システムプロキシのスイッチには依存しません。成功してブラウザーだけ失敗する場合は、ブラウザーやシステム設定を優先して確認してください。ローカルポートに接続できない場合は、ノードを変更する前にコアの状態と待ち受けアドレスを確認します。リクエストが成功しても、実際の出口は接続ログで確認してください。

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com

TUN、サービス権限、終了後の復旧

システムプロキシに従わないアプリの通信も取り込みたい場合は、TUNを検討してください。クライアントによっては、サービスコンポーネントのインストールや管理者権限での初期化が必要です。該当クライアントの案内に従って操作してください。有効化後は、仮想ネットワークアダプターと接続ログを確認します。システム全体でドメインを解決できなくなった場合は、まずTUNを無効にして基準設定に戻し、DNS、ルートの競合、セキュリティソフトのブロックを確認しましょう。複数のネットワーク設定を同時に変更しないでください。

普段の利用でWindowsファイアウォール全体を無効にする必要はありません。セキュリティソフトが通信をブロックする場合は、入手元を確認できたアプリに対して、必要なネットワーク範囲だけ許可してください。スリープからの復帰、Wi-Fiの切り替え、社内VPNへの接続後にルートが無効になることがあります。その場合は、まずコアを停止してから再起動します。自動起動を設定する場合も、手動起動で安定していることを確認してから、システム起動時の実行とプロキシの自動有効化を設定しましょう。起動直後から問題が発生する状態を避けられます。

クライアントを終了する前にシステムプロキシを無効にしてください。アプリが異常終了した場合は、Windowsの「設定」から「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシ設定が残っていないか確認します。アプリが停止したのにシステムがローカルポートを参照していると、プロキシを利用するアプリは接続できません。LAN共有には待ち受けアドレスと受信ルールの設定も必要です。詳しくは混合ポートとLAN共有の解説をご覧ください。「LANからの接続を許可」をオンにするだけで設定を終えないようにしましょう。

macOS：チップのアーキテクチャとネットワーク権限

チップに合ったクライアントを選ぶ

Appleメニューから「このMacについて」を開き、「チップ」または「プロセッサ」に表示される内容を確認してから、macOSのダウンロードで対応するインストーラーを選びます。まずClash Plusを検討してください。Clash Verge RevやFlClashも選択できます。ClashX Metaは開発が終了しています。移行する場合はサブスクリプションとルールを先にバックアップしてください。古いアプリが起動することと、新しい設定形式に対応できることは別です。

ディスクイメージをダウンロードして開き、アプリを「アプリケーション」フォルダーへドラッグしてから、そのフォルダー内のアプリを起動します。ディスクイメージ内のアプリを使い続けると、アップデート、権限、ログイン時の起動設定が別々の場所を参照することがあります。macOSが起動をブロックした場合は、まずダウンロード元を確認し、「システム設定」→「プライバシーとセキュリティ」で具体的なメッセージを確認してください。出所不明のコマンドを使って、セキュリティ機能を一括で無効にしないでください。

リモート設定を追加して読み込みを確認する

設定画面を開き、リモートサブスクリプションを追加して、名前とURLを入力します。保存後、解析が終わったら現在の設定として選択してください。ファイルから読み込む場合は、ファイル選択画面でYAMLを開きます。クライアントがファイルをコピーするのか、元のパスを参照し続けるのか確認しましょう。一時的なダウンロードフォルダーに置いたまま削除すると、次回の再読み込みに失敗することがあります。長期間参照するファイルは、安定した場所に保存してください。

プロキシグループが表示されていることを確認し、テスト用ノードを手動で選択します。設定の更新成功は、サブスクリプションの取得と解析が完了したことを示すだけで、ノードへの接続が成功した証明にはなりません。まずノードが利用可能か確認してから、通信の取り込みを有効にしてください。ブラウザーではサブスクリプションにアクセスできるのにクライアントでは失敗する場合、異なるプロキシ経路を使っていないか、システム時刻が正しいかを確認します。公開ページにURL全体を載せないでください。

現在のネットワークサービスに適用されるシステムプロキシ

クライアントのシステムプロキシを有効にすると、macOSでは通常、使用中のネットワークサービスにHTTP、HTTPS、またはSOCKSプロキシの設定が反映されます。Wi-Fiと有線ネットワークでサービスが別の場合があるため、ネットワークを切り替えた後は設定を確認してください。環境変数だけを参照するターミナルツールもあれば、独自のプロキシ設定を持つアプリもあります。ブラウザーは動くのにターミナルでは失敗する状況もあり得ます。対象アプリがどの接続方法を使うか確認しましょう。

次の読み取り専用コマンドで、現在のシステムプロキシの状態を確認できます。有効かどうか、アドレスとポートがクライアントに合っているかを確認してください。表示されるのはシステム設定であり、すべてのアプリがその設定に従うとは限りません。終了済みのクライアントのアドレスが残っていたら、現在のクライアントでシステムプロキシをいったん無効にしてから再度有効にします。それでも直らない場合は、該当するネットワークサービスのプロキシ設定を一つずつ確認してください。

scutil --proxy

シェル全体の設定を変更するより、ターミナルの特定のリクエストに一時的にプロキシを指定するほうが、トラブルの切り分けが簡単です。以下のコマンドは実行した1回だけに適用されるため、使用前にポートが実際の設定と一致しているか確認してください。シェルの起動ファイルにプロキシ環境変数を設定している場合は、残っていないかも確認します。GUIクライアントを終了しても環境変数は自動で削除されず、停止したローカルポートへの接続を試みることがあります。

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

TUNの権限とネットワーク切り替えへの対処

TUNの利用時、クライアントから補助サービスのインストール、ネットワークインターフェースの作成許可、システム拡張機能の承認を求められる場合があります。現在使用しているアプリの案内に従い、別のクライアントのサービスコンポーネントを代わりに何度もインストールしないでください。許可後も通信がない場合は、ログに権限、インターフェース、ルートの作成エラーがないか確認します。これらはノード接続前の問題であり、サブスクリプションを変えても通常は解決しません。

企業VPN、ほかのネットワークフィルター、仮想マシンのネットワークを同時に使うと、ルートの優先順位やDNSが競合する場合があります。まず通信を取り込むツールを一つだけ有効にして確認し、その後ほかのコンポーネントを一つずつ戻して、問題が起きる段階を特定してください。会社が管理するデバイスでは、既存のネットワークポリシーに従ってください。管理対象の設定を削除してTUNを強制的に有効にするのは避けましょう。プロキシ設定ですべてのセキュリティ制限やアクセス制限が自動的に解除されるわけではありません。

Macがスリープから復帰したときや、有線からWi-Fiに切り替えたときは、クライアントを停止してから再起動し、接続を復旧させます。その後、現在のネットワークサービスに適用されているプロキシを確認してください。アンインストール前にシステムプロキシとTUNを無効にし、補助サービスはクライアントの手順に従って削除します。アプリをゴミ箱に入れるだけでは、ローカルポートを参照する設定が残る場合があります。削除後にブラウザーが接続できなくなった場合は、ネットワーク設定をすべてリセットする前に、システムプロキシが残っていないか確認しましょう。

Android：VPNの許可とアプリごとの振り分け

インストール、アップデート、設定の移行

Androidのダウンロードから、まずClash Plusをご確認ください。Clash Meta for Android、FlClash、Surfboardも選択できます。Surfboardの設定方式はClash YAMLと完全には同じではなく、同じYAMLをすべてのクライアントで共通して使えるわけではありません。サービス提供元がClashサブスクリプションのみを提供している場合は、その形式に明確に対応したクライアントを選び、インストール後に設定が合わないと判明するのを避けましょう。

APKをインストールする際は、現在使っているブラウザーやファイル管理アプリからのインストール許可を求められる場合があります。ファイルの入手元を確認したうえで、実際に使うインストール元だけに許可してください。インストール済みアプリとの競合が表示された場合は、パッケージ名、署名、入手元を確認し、設定をバックアップしてから移行するか判断します。現在動作しているアプリをすぐに削除しないでください。署名の異なるAPKは通常そのまま上書きできず、データを消去しても署名の不一致は解消されません。

URLから設定を読み込み、VPNを起動する

Clash for Android風の画面では、「設定」→「新しい設定」→「URLからインポート」を開き、見分けやすい名前とサブスクリプションURLを入力します。保存後、更新の完了を待ってから設定一覧に戻り、該当項目を選択してください。ファイルから読み込む場合は、システムのファイル選択画面でYAMLを選びます。スマートフォンにファイルをダウンロードしただけではクライアントに読み込まれないため、インポートして選択する必要があります。

ホーム画面に戻り、起動ボタンをタップします。初回はAndroidのVPN接続リクエストが表示されるので、アプリ名を確認して許可してください。ステータスバーにVPNアイコンが表示されればVPNインターフェースは確立されていますが、リモートノードに接続できたとは限りません。プロキシ画面でルールモードになっていることを確認し、テスト用ノードを選択してからブラウザーを開きます。接続ログも確認し、入口から出口までの通信を検証しましょう。

Androidでは通常、一人のユーザー環境でVPNサービスを使用できる一般アプリは一つです。起動時に別のVPNが切断されても、システム上の制約であり、クライアントの不具合とは限りません。端末上のVPNを使うフィルターアプリも競合する場合があります。仕事用プロファイルと個人用プロファイルは別々のネットワークポリシーで管理されることがあり、一方のプロファイルのクライアントが他方のアプリを制御できるとは限りません。端末の管理範囲を確認してください。

アプリのアクセス制御でプロキシ対象を決める

設定のアクセス制御またはアプリ振り分けを開き、「選択したアプリのみプロキシ」と「選択したアプリを除外」のどちらが有効か確認します。同じアプリを選んでも、設定によって結果は逆になります。初回のトラブルシューティングでは、いったんすべてのアプリがVPNに入る基準状態に戻し、一つずつ除外してください。ブラウザーは正常でも特定のアプリが接続ログにまったく出ない場合は、ノードの問題と決めつけず、アプリ一覧とプロファイルの所属を確認します。

「プライベートネットワークをバイパス」は通常、LANアドレスへのルーティングに影響し、ルーター、プリンター、ローカル端末へのアクセスに役立ちます。ただし、設定ルールも併せて確認してください。この設定は、ほかのデバイスがスマートフォンのプロキシを使えるようにするものではありません。「アプリによるバイパスを許可」はVPNのシステム層における別の動作で、具体的な効果はクライアントの実装によって異なります。変更前に説明を確認し、異なる階層のバイパス設定を混同しないようにしましょう。

DNSハイジャックとバックグラウンド動作

DNSハイジャックは、VPNに入ったDNSリクエストをコアに処理させるために使われます。ただし、アプリが独自に確立した暗号化DNS接続まで取り込めるとは限りません。ブラウザーのセキュアDNSやシステムのプライベートDNSが有効だと、想定と異なる経路で名前解決される場合があります。トラブルシューティングでは、まず現在の設定を記録し、一時的にシステムの既定値に戻して比較してください。ノード、DNSモード、ルールを同時に変更すると、どの変更が有効だったか分からなくなります。

画面を消した後に通信が切れる場合は、まずバッテリー設定でクライアントのバックグラウンド動作が制限されていないか確認します。次に、メーカー独自の自動起動やバックグラウンド維持の設定を確認してください。設定名はOSによって異なるため、このクライアントだけを調整し、端末全体の省電力機能を無効にする必要はありません。画面消灯後だけ発生するのか、アプリを開き直すと復旧するのか、ログにプロセスの再起動があるのかを確認すると、バックグラウンドで終了されたのかネットワーク切り替えによる切断なのかを判断しやすくなります。

常時接続VPNと「VPNを使用しない接続をブロック」は、基本接続が安定してから有効にしてください。後者を有効にすると、クライアントが停止中または再接続中に通信が遮断され、端末全体がオフラインになったように見えることがあります。有効化後にLANへ接続できない場合は、システムのブロック設定とアプリ除外の競合も確認してください。元に戻す場合は、まずAndroidのVPN設定を変更し、その後クライアント内のルールを調整します。

スマートフォンでVPNを有効にしても、テザリング中の端末が必ず同じプロキシを共有するわけではありません。テザリング時の転送経路、システム権限、プロキシの待ち受け設定は別の問題です。共有する場合は、LANプロキシの方法に従って接続先のアドレスとポートを設定し、アクセス可能な範囲を制限してください。利用後は不要な待ち受けを無効にし、信頼できないネットワークにローカルプロキシポートを長時間公開しないようにしましょう。

iOS：インストール、設定の読み込み、ネットワーク拡張

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

iPhoneとiPadでは、まずClash Plusをご利用ください。Clash PlusのApp Storeページからインストールできます。製品情報は公式サイト clashplus.ioでも確認できます。システム要件はApp Storeの最新表示をご確認ください。インストールボタンが利用できるかどうかは、端末の互換性とアカウントからアクセスできるストアの内容によって異なります。端末のモデルだけで判断しないでください。

まず当サイトのiOSダウンロードで入手先を確認することもできます。初回起動時は、設定や接続に関する画面を確認し、アプリ名を確かめてください。クライアントは設定を読み込んで通信を転送するアプリであり、サブスクリプションは別途用意する必要があります。App Storeからインストールしただけで利用可能なノードまで用意されたわけではありません。ネットワーク権限のリクエストとサブスクリプションの購入やアカウント認証も混同しないようにしましょう。

サブスクリプションの読み込みと形式の違い

クライアントの設定またはサブスクリプション画面からリモート設定を追加し、サービス提供元のURLを貼り付けます。ダウンロードと解析が完了するまで待ってください。画面の更新でボタン名が変わることはありますが、リモートサブスクリプションを追加する操作が目印です。読み込み後、グループとノードが表示されるか確認して、現在の設定として選択します。空の項目しか表示されない場合は、システムVPNの許可を何度も試す前に、ダウンロードが成功したかを確認してください。

スマートフォンでURLをコピーすると、前後の空白、説明文、改行まで一緒に含まれることがあります。第三者のツールにアップロードして試すのではなく、内容が正確か端末上で確認してください。URLを開いた際にログインページ、アカウント案内、通常のWebページが表示される場合、クライアントはYAMLとして読み込めません。サービス提供元が複数形式を用意している場合は、現在のクライアントまたはコアに対応すると明記された形式を選びます。URLの末尾だけで互換性を判断しないでください。

ファイルから読み込む場合は、システムのファイル選択画面で実際の設定ファイルを選び、クラウド上の仮ファイルではなく、端末にダウンロード済みであることを確認します。外部ファイルへの参照が保持されるかはクライアントの仕様によります。リモートルールやノードプロバイダーが追加のリソースを取得する場合もあります。メイン設定の読み込み後もグループが不完全なら、関連リソースの取得状況とネットワークへの到達性を確認してください。

VPN設定とルールモードを確認する

初回接続時に、システムからVPN設定の追加を求められます。要求元のアプリを確認し、システムの案内に従って許可してください。必要に応じて端末の認証を行います。クライアントに戻って接続を開始し、システム設定でもVPNの状態を確認してください。iOSではネットワーク拡張機能が通信を取り込むため、Windowsの管理者サービスのインストール手順を流用する必要はありません。デスクトップ版と同じ名前のTUNスイッチを探す必要もありません。

初回はルールモードを選び、プロキシグループでノードを一つ明示的に選択してください。グローバルモードは問題を一時的に比較するには便利ですが、ルールのトラブルシューティングの代わりにはなりません。特定のサイトがグローバルモードでだけ使える場合、ルールの振り分け、直接接続の経路、グループの選択が異なる可能性があります。グローバルモードを常用するより、該当リクエストに適用されたルールを確認するほうが、意図した振り分けに戻しやすくなります。

アプリの対象範囲、DNS、オンデマンド接続

iOSクライアントがAndroidと同じようにアプリを個別選択できるとは限りません。一般的な端末で利用できるアプリ単位の制御はシステムインターフェースに制限され、実際の機能はクライアントの画面や端末の管理状態によって異なります。特定の種類のサイトを直接接続したい場合は、通常、ドメインルールとプロキシグループで設定します。アプリ名だけで判断すると、そのアプリが利用する複数のドメインやシステムサービスを見落とすことがあります。

DNSは設定ファイル、クライアントの上書き、システムのネットワーク設定、ほかのネットワーク拡張機能の影響を受ける場合があります。プライバシーリレーやフィルター機能によって、確認できる通信経路が変わることもあります。トラブルシューティングでは、まず現在有効なコンポーネントを確認し、すべてのシステム設定をすぐに削除しないでください。現在のプロキシクライアントだけを一時的に残してテストし、その後ほかの機能を一つずつ戻せば、どの階層で競合しているかを特定しやすく、元の設定に戻す根拠も残せます。

オンデマンド接続は、クライアントで設定した条件を満たすとネットワーク拡張機能を自動的に起動します。手動接続とサブスクリプションの更新が安定してから有効にし、どのネットワークで接続するかを明確にしてください。アプリの画面を閉じた後もVPNが接続状態を保つのは、拡張機能が動作を続けている場合の正常な挙動です。画面が反応しなくなったとは限りません。完全に停止するには、クライアントの接続スイッチを使うか、システムのVPN設定で切断を確認してください。

ネットワーク切り替えと設定のバックアップ

Wi-Fiからモバイル通信に切り替えると、以前の接続が無効になる場合があります。再接続を待ってから、新しいリクエストで確認してください。ホテルや空港など、Web認証が必要なWi-Fiでは、先にネットワークへログインします。プロキシで接続認証を代替することはできません。特定のWi-Fiでだけ失敗する場合は、モバイル通信の結果と比較し、ローカルDNS、ネットワーク制限、ノードへの到達性を確認します。すぐにすべてのサブスクリプションを削除しないでください。

端末を変更する前に、サブスクリプションの入手元、プロキシグループの選択、必要な上書き設定を記録してください。システムのバックアップですべての設定が完全に移行するとは限りません。エクスポートファイルにはノードの認証情報が含まれる場合があるため、安全な場所に保管します。サブスクリプション更新後に問題が起きたら、新しいグループに切り替わっていないか、リモートルールの読み込みが完了しているかを確認してから、以前の設定に戻すか判断してください。古いファイルが使えるかどうかは、サービス提供元が該当ノードを維持しているかにもよります。

Linux：デスクトップクライアントとコアの実行

デスクトップとサーバーの用途を分けて考える

LinuxデスクトップではLinuxのダウンロードから、まずおすすめのClash Verge Revをご確認ください。FlClashも選択できます。サーバー、ルーター、コマンドラインだけで動かす環境では、ダウンロードページのコア欄からMihomoをご確認ください。GUIクライアントは通常、コア、設定、サービス権限を管理します。コアを直接実行する場合は、保存先、起動方法、ログ、通信の取り込みを自分で設定する必要があり、運用上の責任も異なります。

インストール前に、ディストリビューション、プロセッサーのアーキテクチャ、パッケージ形式を確認してください。Debian系では通常debパッケージ、RPM系ではダウンロードページに用意されたrpmパッケージを使います。拡張子だけを書き換えてインストールすることはできません。デスクトップ用GUIアプリは、ディスプレイサービスやシステムライブラリに依存する場合があり、GUIのないサーバーでの実行には適しません。共有ライブラリが不足している場合は、システムディレクトリのファイルを無作為に上書きせず、ディストリビューションの互換性を確認してください。

インストール後に通常のプロキシ接続を確認する

システムのパッケージインストーラーでインストールし、アプリメニューから起動します。コマンドラインでパッケージをインストールする場合は、パッケージマネージャーが示す依存関係と変更内容を先に確認してください。設定画面でリモートサブスクリプションを追加し、更新後に現在の設定として選択してから、プロキシグループでノードを選びます。初回テストではGUIを一般ユーザーとして起動し、サービスのインストールやネットワークインターフェースの作成など、明確に権限が必要な操作だけシステムの許可を行ってください。

GNOME、KDEなどのデスクトップ環境では、プロキシ設定の場所が異なります。また、デスクトップの設定を参照するかどうかもアプリごとに異なります。ブラウザーはデスクトップのシステムプロキシを使っていても、ターミナルツールは明示的な引数や環境変数を必要とする場合があります。システムプロキシが有効だからといって、パッケージマネージャー、コンテナー、バックグラウンドサービスも利用しているとは限りません。まずプロキシを明示したリクエストでローカルポートに接続できることを確認し、その後アプリごとに設定します。

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

現在のターミナルセッションで複数のツールにHTTPプロキシを使わせる場合は、以下の環境変数を一時的に設定できます。すべてのツールがこの変数に従うわけではなく、個別設定が必要なツールもあります。動作を確認する前に、全ユーザーの起動ファイルへ書き込まないでください。使用後に変数を解除しておけば、クライアントの終了後も停止した待ち受けポートへ接続しようとする状態を防げます。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# このセッションのプロキシ設定を解除
unset http_proxy https_proxy

Mihomoを直接実行する際のディレクトリ

コアを単独で使う場合は、まずアーキテクチャに合った実行ファイルを用意し、実行パスにインストールします。以下の起動コマンドは、システムからmihomoというプログラムを実行でき、ユーザーの設定ディレクトリに完全なconfig.yamlが置かれていることを前提としています。設定をテストコマンドで確認した後、フォアグラウンドで起動してログを確認してください。構文の検証に通っても、ノード、DNS、リモートルールのリソースにアクセスできるとは限りません。

mkdir -p "$HOME/.config/mihomo"
mihomo -t -d "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

ディレクトリの指定は、設定ファイルや一部の実行データを探す場所に影響します。ターミナルから起動できるのにシステムサービスでは失敗する場合、実行ユーザー、作業ディレクトリ、ファイル権限、環境変数の違いが原因として考えられます。サービス環境は、対話型シェルのプロキシ環境変数を自動では引き継ぎません。まずサービスが実際に参照する設定ファイルのパスを確認し、サブスクリプション、ルールファイル、ログディレクトリにアクセスできるかを調べましょう。異なる設定を何度もコピーして上書きしながら試すのは避けてください。

TUN、DNS、コンテナネットワーク

TUNでは仮想インターフェースの作成やルートの変更に権限が必要です。GUIクライアントでは通常、サービスモードや補助コンポーネントが用意されているため、クライアントのインストール手順に従ってください。コアを単独で使う場合の権限設定は、ディストリビューションのサービス管理方式に合わせ、デスクトップアプリ全体を不必要に高い権限で常時実行しないようにします。TUNデバイスを開けないというエラーは、システムの対応状況や実行権限を確認してください。リモートノードの有効性とは無関係です。

LinuxのDNSは、NetworkManager、systemd-resolved、その他のコンポーネントが管理している場合があります。設定ファイルにDNSの待ち受けポートを指定しても、すべてのプログラムが自動的にそこへ問い合わせるわけではありません。システムの名前解決経路やTUNによる取り込みも正しく設定する必要があります。DNS設定を変更する前に現在の管理元を確認し、ネットワークサービスによって再生成されるファイルを手動で書き換えないようにしてください。クライアントがサポートする連携方法を優先し、元の設定に戻せるよう記録を残しましょう。

コンテナー内のループバックアドレスはコンテナー自身を指し、ホストを指すものではありません。ホストでプロキシを動かしていても、コンテナー内で127.0.0.1を指定すると接続できないことがよくあります。異なるネットワーク名前空間から接続する必要がある場合は、到達可能なアドレス、待ち受け範囲、アクセス制限を設計してください。簡単だからといって、プロキシとコントロールインターフェースをすべてのネットワークインターフェースに公開しないでください。バックグラウンドサービスにも個別の環境設定があるため、サービスごとに検証し、デスクトップでのテスト結果をそのまま適用しないようにします。

フォアグラウンドでの動作確認が済んでから自動起動を設定し、再起動後のサービス状態とログを確認してください。サービスを停止する際は、システムプロキシ、ルート、DNSも元に戻し、通常の直接接続が動作することを確認します。リモート端末でサーバーを管理している場合、デフォルトルートを変更する前に現在のセッションと復旧手段を確保してください。管理用の接続まで切断されるおそれがあります。一般的なデスクトップ利用では、コアのサービス全体を手動管理する必要はなく、GUIクライアントのほうが継続利用に適しています。

設定に関するよくある問題：通信経路ごとに切り分ける

サブスクリプションの失敗は取得と解析に分けて確認する

「更新に失敗しました」というエラーは、URLへのリクエスト、接続、データ受信、YAMLの解析など、異なる段階で発生する場合があります。まずタイムアウト、証明書エラー、権限拒否、項目や構文のエラーのどれかを確認してください。ネットワークエラーなら現在の接続、システム時刻、リクエスト経路を確認します。解析エラーなら、取得した内容と形式の互換性を調べてください。DNSを変更してもインデントの不足は直らず、YAMLを書き換えても期限切れのURLは有効になりません。

ブラウザーとクライアントで同じURLの結果が異なる場合、ブラウザーが既存のプロキシ、保存済みのログイン状態、異なるリクエスト情報を利用している可能性があります。ブラウザーで開けるという理由だけで、クライアント側の不具合と決めつけないでください。更新に現在のプロキシが必要なのに、現在の設定が利用できない場合、復旧できない循環に陥ることがあります。クライアントが対応するダウンロード経路を使って設定してください。詳しくはサブスクリプションの期限切れ・解析失敗の確認方法をご覧ください。

ルールの順序と上書きの範囲

ルールは通常、上から順に照合され、最初に一致したルールのポリシーが適用されます。最後のMATCHは、それまでのルールに一致しなかった接続を受け持ちます。以下は設定の一部であり、単独で動作するサブスクリプションではありません。PROXYは設定内に実在するプロキシグループ名に置き換えてください。グループ名が一致しないと、設定の読み込みに失敗する場合があります。ドメインルールにはドメイン情報が必要で、IPアドレスへの直接接続はドメインのルールに一致しないことがあります。

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

クライアントの上書き設定は、該当箇所全体を置き換える場合も、項目をマージする場合もあります。YAMLの階層だけからマージ方法を判断しないでください。リモートルール、カスタムルール、画面上の設定を重ねた場合は、最終的な実行設定や接続時の実際の判定結果を確認します。サブスクリプションの更新後にカスタム設定が消えた場合、リモート更新の管理対象ファイルを編集していた可能性があります。長期間使うルールは、クライアントが明示的にサポートするローカル拡張機能に追加し、元の内容をバックアップしてください。

DNS、Fake-IP、ポートを分けて調べる

Fake-IPは、一部のドメインに対応付け用の仮想アドレスを割り当て、後続の接続時にコアがドメインと関連付ける仕組みです。ノードの実アドレスではありません。アプリとの互換性に問題がある場合は、まずDNSリクエストがコアに届いているか確認し、アプリに古い結果がキャッシュされていないか調べてください。キャッシュにある仮想アドレスを長期利用するIPルールに直接登録しないでください。DNSモードを切り替えた後は接続し直し、必要ならアプリのDNSキャッシュを消して比較しましょう。

nameserver、fallback、フィルター条件の効果は、DNS設定全体によって異なります。複数のパブリックDNSアドレスを無計画に追加しても、最適化にはなりません。特に、まだ解決できていないプロキシサーバーのドメイン名に上流DNSへの接続が依存すると、名前解決のループが発生するおそれがあります。各項目を詳しく確認するにはDNS項目とハイジャック経路の解説をお読みください。試す前に、動作する設定を保存しておきましょう。

症状	まず確認すること	次に試すこと
ローカルプロキシポートに接続できない	コアが動作しているか、ポートが待ち受けているか	アドレス、ポート、使用中のプロセスを確認する
接続ログに対象アプリが表示されない	通信の取り込み方法とアプリの除外範囲	プロキシを明示する方法か、単一の取り込み方法で比較する
接続はあるが出口が違う	モード、適用ルール、プロキシグループの選択	実際に動作中のルールの順序を確認する
ドメイン名を使うリクエストだけ失敗する	DNSリクエストの経路と名前解決ログ	システムとコアのDNS設定を比較する
ネットワーク切り替え後、一時的に通信が切れる	古い接続、ルート、VPNの状態	接続を確立し直してから新しいリクエストを試す

LAN共有とコントロールインターフェース

混合ポートはアプリのプロキシ通信を受け付け、コントロールインターフェースはコアを管理するためのもので、用途が異なります。別の端末とプロキシを共有するには、到達可能なアドレスで待ち受け、LANからのアクセスを有効にし、ファイアウォールの範囲を設定する必要があります。そのためにコントロールインターフェースを公開する必要はありません。接続する側の端末には、クライアントを動かしている端末のLANアドレスを指定します。共有後はネットワークが信頼できるか確認し、使わなくなった接続口は速やかに閉じてください。

必要最小限の情報で、再現可能な切り分けを行う

テスト時はOS、クライアント、通信の取り込み方法、失敗するアプリ、発生時刻を記録し、条件を一つずつ変更してください。ノードの接続テストに成功しても、すべてのプロトコル、サイト、UDP通信が使えるとは限りません。Webサイトを開けても、バックグラウンドアプリが正常とは限りません。通信が取り込まれたか、ルールが正しいか、出口に接続できたかを順番に確認してから変更する箇所を決めることで、関係のない設定を切り替え続けずに済みます。

クライアントを変えれば、すべての設定問題を解決できますか？

いいえ。URLの失効、ノードへの接続不可、ネットワーク制限は、複数のクライアントで同じように発生することがあります。まず元の設定を残し、失敗した段階を特定してください。コアの互換性やプラットフォーム連携の違いが原因だと確認できた場合に限り、クライアント比較ガイドを参考に代替クライアントを選びましょう。

ログを共有する際に残すべき情報は？

エラーの種類、発生時刻、必要な状況説明だけを残してください。サブスクリプションURL全体、ノードの認証情報、コントロールインターフェースの認証情報、個人のファイルパスは削除します。基準設定に戻した後の結果も記録してください。接続手順を最初から確認するだけなら、クイックスタートガイドに戻り、設定の選択とシステムの許可を順に確認できます。