インストール・設定ガイド

Clashの全プラットフォーム設定

このページではOSごとに、ダウンロードからインストール、サブスクリプションの追加、通信の振り分けまでをまとめています。端末の移行、TUNの設定、OSごとの違いを確認したい場合にご利用ください。初めて使う場合は、まず使い方ガイドで基本操作を済ませてから、該当する章で権限、サービスの起動、DNSを確認してください。クライアントによって画面上の項目名は異なるため、メニュー名ではなく設定の役割を基準に説明します。

おすすめの読み進め方：まず共通の準備を確認し、次に使用する端末の章を参照してください。問題が起きた場合はログを保存し、最後の章にある手順に沿って原因を絞り込みます。

共通の準備と設定時の注意点

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

ClashのGUIクライアントは設定の表示や起動管理、システムプロキシの設定を担当します。コアはポートの待ち受け、ルールの処理、接続の確立を担い、サブスクリプションにはサーバー情報やプロキシグループなどの設定が含まれます。この3つは別のものです。クライアントをインストールしただけでは、利用可能なサブスクリプションは用意されません。リンクを追加しても、コアが正常に設定を読み込んだとは限りません。トラブル時は、アプリが起動するか、設定を解析できるか、通信がコアに届いているか、接続先が利用可能かをそれぞれ確認してください。

インストーラーを選ぶ前に、OS、プロセッサのアーキテクチャ、現在のユーザー権限をシステム情報で確認してください。当サイトでは対応プラットフォーム向けにClash Plusを優先して掲載しています。詳細はクライアントのインストーラーをご覧ください。クライアントによって対応するコアの設定項目、システムサービス、インポート方法が異なります。拡張子が同じという理由だけで、設定が完全に互換性を持つとは判断できません。開発が終了したアーカイブ版は旧環境の再現には使えますが、新しい端末での利用にはおすすめしません。

設定の入手元を記録し、認証情報の拡散を防ぐ

サブスクリプションURLにはアカウントを識別する情報が含まれることが多いため、認証情報として扱ってください。コピー時は改行やチャットアプリの付加文、末尾の句読点が混入していないか確認します。URL全体が写ったスクリーンショットを公開したり、問い合わせ窓口や公開ログに貼り付けたりしないでください。ブラウザーでリンクを開けても、クライアントと同じネットワーク経路、リクエストヘッダー、証明書環境でアクセスできるとは限りません。形式に対応していない場合は、提供元にClashまたは対象コア向けの設定形式を確認してください。

初回インポート前に元の設定を複製し、現在選択している設定名も記録しておきます。リモートサブスクリプションの更新で、ダウンロードした内容が上書きされることがあります。継続して使う独自ルールは、クライアントが対応するオーバーライド、マージ、拡張設定に保存してください。マージの順序は製品によって異なるため、保存後に最終的な設定内容を確認します。別の端末へ移す際は必要な項目だけをコピーし、パス、ネットワークインターフェース名、ローカルの待ち受けアドレスは新しい端末で確認し直してください。

まずは最小構成で接続する

最初はルールモードを使い、利用可能なプロキシグループを選んでから、通信を振り分ける方法を1つだけ有効にしましょう。デスクトップではまずシステムプロキシを試し、モバイルでは通常、クライアントがシステムVPNトンネルを作成します。TUNを使うとより多くのアプリの通信を取り込めますが、仮想インターフェース、ルーティング、DNSという新たな確認項目が増えます。初回設定で複数のクライアント、グローバルモード、TUNを同時に有効にすると、ログから原因を特定しにくくなり、重複したルートが残ることもあります。

項目	役割	最初に確認すること
システムプロキシ	システム設定に従うアプリにプロキシアドレスを通知する	ローカルの待ち受けポートとシステム設定が一致していること
TUN／システムトンネル	仮想インターフェースまたはシステムのネットワーク拡張で通信を取り込む	権限、ルート、DNSの設定
ルールモード	設定ルールに基づいて接続先を選ぶ	ルールの適用順とプロキシグループ名
サブスクリプションの更新	リモートの設定を再取得する	更新対象が現在の設定と同じか

以下はローカルの待ち受け設定を理解するための例です。サーバー情報は含まれておらず、これだけではプロキシ接続を確立できません。ポート番号に決まった値はなく、他のアプリで使用されていないことと、接続元の設定と一致していることが重要です。既存の設定に同じ項目がある場合は値を変更し、同名のキーを重複して追加しないでください。

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

混合ポートはHTTPとSOCKSの両方のリクエストを受け付けます。「LANからの接続を許可」は他の端末からのアクセスを許可するかどうかを設定し、ローカルのバインドアドレスで待ち受け範囲をさらに制限できます。認証を設定していない場合は、接続元を自分の端末だけにして、ポートがネットワークに公開されないようにしてください。システム時刻も同期しておきましょう。時刻のずれにより、暗号化ハンドシェイクや証明書の検証に失敗することがあります。準備ができたら設定を一度に1つだけ変更し、その都度テストして新しいログを確認してください。複数箇所をまとめて変更するより、原因を特定しやすくなります。

Windowsへのインストールと通信の振り分け

インストーラーを選んで初回起動する

「設定」の「システム」からプロセッサのアーキテクチャを確認し、Windows用インストーラーから対応するクライアントを選びます。まずはClash Plusがおすすめです。用途に応じてClash Verge Rev、FlClash、Clash Nyanpasuも選べます。Clash for Windowsは開発が終了したアーカイブ版です。別のアーキテクチャ向けのファイルを名前だけ変更しても、互換性は得られません。解凍したフォルダーの内容をすべて保持し、メインプログラムだけを別の場所に移動しないでください。

インストーラーを実行する前に、システムに表示されたファイルの入手元と発行元を確認してください。安全性はファイル名だけでは判断できません。不審な点があればインストールを中止し、ダウンロード元を確認してください。システムの保護機能をそのまま無効にしないでください。インストール後はまず通常のユーザーとして起動し、タスクトレイのアイコン、設定画面、ログが開けることを確認します。サービスのインストール、仮想ネットワークアダプターの有効化、保護された設定の変更が必要な場合に限り、クライアントの案内に従って権限を昇格してください。常に管理者として実行するのは避けましょう。

サブスクリプションを追加し、使用中の設定を確認する

設定管理画面を開き、URLからインポートを選んでサブスクリプションURLをすべて貼り付け、保存します。ダウンロード後はその設定を選択し、解析エラーがないことを確認してから、プロキシまたはプロキシグループの画面で接続先を選びます。クライアントによっては「設定をダウンロード」と「設定を有効化」が別の操作です。リストにファイルが表示されていても、コアがその設定を使用中とは限りません。提供元からローカルファイルを受け取った場合は、ファイルのインポート機能を使ってください。ファイルのパスをサブスクリプションURL欄に貼り付けないでください。

インポートに失敗したら、接続エラー、レスポンス形式の異常、未対応項目のどれに該当するかを確認します。Webページにログイン画面が表示される場合、クライアントが設定ではなくHTMLを取得している可能性があります。未認識の項目が表示されたら、サブスクリプションが現在のコアに対応しているか確認してください。エラーを消すために、意味が分からない項目をすべて削除するのは避け、元のファイルを保存しておきます。読み込みに成功したら設定名とプロキシグループの選択を記録し、その後で更新を試します。更新によって別の設定に切り替わっていないことも確認してください。

システムプロキシ、UWPのループバック、TUN

クライアントでシステムプロキシを有効にしたら、Windowsのプロキシ設定が、クライアントの実際のローカルアドレスと待ち受けポートを参照しているか確認します。ブラウザーに独自のプロキシ拡張機能があると、システム設定よりそちらが優先される場合があります。テスト中は経路を1つに統一してください。コマンドラインのプログラムがシステムプロキシに従うとは限りません。明示的にプロキシを指定したリクエストでテストすれば、「アプリの通信が取り込まれていない」のか「接続先への通信に失敗している」のかを切り分けられます。以下のポートは設定画面に表示された実際の値に置き換えてください。テスト先のアドレスも、調査中のサイトに変更できます。

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

ブラウザーにはアクセスできるのに、一部のストアアプリに接続できない場合は、UWPアプリによるローカルのループバックアドレスへのアクセス制限が関係している可能性があります。ループバックの許可が本当に必要なアプリだけを確認し、まずはクライアントが提供する管理機能を使ってください。すべてのアプリに一括で許可するのは避けましょう。現在の用途に合えばTUNも検討できますが、サブスクリプションの有効性やルールの適用状況を確認する代わりにはなりません。組織の管理下にある端末では、デバイス管理のルールに従ってください。

TUNを初めて有効にすると、サービスのインストールや仮想ネットワークアダプターの作成が必要になることがあります。システムプロキシのテストが成功してからTUNを有効にし、インターフェースの作成、ルートの設定、権限に関するエラーがログに出ていないか確認します。ファイアウォールの確認画面では、実際のネットワーク範囲に応じて許可してください。自分の端末だけで使う場合、パブリックネットワークからの着信を許可する必要はありません。別のVPNやセキュリティソフトのネットワークフィルター、古い仮想ネットワークアダプターがルーティングを変更していることもあります。トラブル時は、クライアントを何度も再インストールするのではなく、重複して通信を取り込む機能を一時的に無効にしてください。

自動起動と終了後の設定復元

「自動起動」は通常、ユーザーのログイン後に画面を起動する設定です。「サービスモード」では画面とは別にコアが動作する場合があり、両者は同じではありません。利用できるサブスクリプションを設定してから自動起動を有効にし、再起動後に正しい設定が選ばれているか確認してください。起動直後に一時的にネットワークへ接続できない場合は、ネットワークの準備が整うタイミング、サービスの権限、サブスクリプションのオンライン取得が必要かを確認します。タスクスケジューラとクライアントの両方に同じ起動タスクを登録しないでください。

インストール手順の詳細はWindowsのファイアウォール、UWPループバック、TUNでよくある注意点をご覧ください。問題が発生したときのネットワークの種類、権限、通信の振り分け方法を記録すると、「接続できない」とだけ伝えるより原因を特定しやすくなります。

macOSへのインストールとネットワーク権限

チップとアプリの入手元を確認する

Appleメニューの「このMacについて」でチップの種類を確認し、macOS用インストーラーからApple SiliconまたはIntel向けのファイルを選びます。まずはClash Plusがおすすめです。Clash Verge Rev、FlClashも利用できます。ClashX Metaは開発が終了したアーカイブ版です。互換機能を使えば異なるアーキテクチャのアプリを実行できる場合もありますが、起動や権限に関する問題を減らすため、端末に合ったインストーラーを優先してください。

ディスクイメージを開き、アプリを「アプリケーション」フォルダーに移動してから、その場所から起動してください。マウント中のインストールイメージから常用するのは避けましょう。初回起動時のセキュリティ警告は、ダウンロード元とシステムに表示された情報を確認して判断します。ファイルが破損している、または入手元に問題があると表示された場合は、対応するインストーラーを再入手し、システムの互換性要件を確認してください。出所が不明な解除コマンドをネット上からコピーして実行しないでください。補助サービスのインストールを求められた場合は、現在の操作に関係する確認画面であることを確認してください。

設定を追加し、ネットワークサービスを確認する

設定画面にサブスクリプションURLを貼り付け、ダウンロード後に設定を選択してログの解析結果を確認します。ブラウザーからアプリへ引き継いでインポートする場合は、リンクを受け取るアプリが正しいことを確認してください。複数のクライアントがインストールされていると、リンクが古いアプリに関連付けられている場合があります。起動できない場合はクライアントに手動でURLを貼り付けてください。認証情報を含むURLを第三者の変換サイトに送るのは避けましょう。インポート後はルールモードと利用可能なプロキシグループを選び、まずブラウザーで簡単な接続テストを行います。

macOSのシステムプロキシは、現在のネットワークサービスに関連付けられます。Wi-Fi、有線アダプター、その他のネットワークサービスで設定が別々になっている場合があります。ネットワークを切り替えた後に接続できない場合は、現在有効なサービスがクライアントのローカル待ち受けポートを使用しているか確認してください。自動プロキシ設定と手動のWebプロキシでは通信経路が異なるため、どちらが有効か把握しておきましょう。以下のコマンドは状態の確認だけに使い、システム設定は変更しません。サービス名は必ずしもWi-Fiとは限らないため、最初に端末上の実際の名前を一覧表示してください。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"

出力された有効状態、サーバーアドレス、ポート番号がクライアントの設定と一致しているか確認します。クライアント終了後もローカルポートが指定されたままだと、システムのリクエストは待ち受けを停止したサービスに送られます。復元するには、システム設定のネットワークから該当するプロキシ項目をオフにし、自動プロキシ設定も有効になっていないか確認してください。現在の状態が分からないままネットワークサービスを変更するコマンドを続けて実行すると、Wi-Fiだけ直して有線の設定を見落とすおそれがあります。

TUN、補助サービス、DNS

TUNの実装はクライアントとコアによって異なります。特権を持つ補助サービスでルートを調整するものもあれば、システムのネットワーク拡張を許可するものもあります。使用中のクライアントの案内に従って許可してください。メニューのスイッチがオンになっていても、ログでインターフェースとルートが実際に作成されたことを確認します。OSのアップグレード後やアプリの保存場所を移動した後は、古いサービスの修復や再認証が必要な場合があります。クライアントのサービス管理機能を使い、用途が分からないシステムファイルを手動で削除しないでください。

TUNを有効にした後、社内ドメインだけ使えなくなった場合は、ノード全体の障害ではなく、DNSの振り分けや企業VPNのルートが原因かもしれません。利用できないドメイン、接続中のネットワークサービス、適用されたルールを記録し、クライアントが既存の名前解決経路を上書きしていないか確認してください。社内DNSが必要な環境では、該当ドメインが正しいDNSサーバーで解決されるよう設定を維持します。すべてのDNSリクエストを同じパブリックDNSに送るだけでは解決しない場合があります。設定後は社内ネットワークとインターネットの両方をテストしてください。

システムプロキシの影響を受けるのは、通常、システム設定に従うプログラムです。ターミナルのツールではプロキシの明示的な指定や環境変数の設定が必要な場合があります。環境変数が有効なのはそれを引き継いだプロセスだけで、システム全体の通信が振り分けられるわけではありません。ターミナルから接続できるのにブラウザーでは失敗する場合は、ブラウザー拡張機能、キャッシュ、システムのネットワークサービスを確認してください。両方で失敗する場合は、クライアントのログと選択中のプロキシグループを確認します。プロキシアイコンの表示だけでなく、実際のリクエストで動作を検証してください。

ログイン時の起動、スリープ、ネットワーク切り替え

ログイン後に起動する場合は、クライアントの自動起動設定を使い、システムのログイン項目で無効になっていないか確認します。補助サービスの稼働とメニューバーの画面表示は別のものです。ウィンドウを閉じてもコアが停止するとは限りません。スリープからの復帰、テザリングへの切り替え、有線アダプターの再接続後は、インターフェース名やデフォルトルートが変わることがあります。まず通信の振り分けを停止してから再度有効にし、ルートが再構築されるか確認してください。すぐにサブスクリプションを上書きしないでください。

別のMacへ移行する際は設定をエクスポートできますが、サービスの権限を再設定し、ローカルのファイルパスを確認して、プロキシグループを選び直してください。プライベート証明書、組織のネットワーク設定、システムキーチェーンの情報は、通常のサブスクリプションファイルで共有しないでください。安定して動作することを確認してから、自動更新、自動起動、その他の拡張設定を1つずつ元に戻します。正常に接続できたときのログを保存しておくと、障害時との比較に役立ちます。

Androidへのインストールとバックグラウンド接続

端末のアーキテクチャに合ったアプリを選び、権限を設定する

Android用インストーラーでは、まずClash Plusをおすすめします。ほかにClash Meta for Android、FlClash、Surfboardも選べます。アプリごとに対応する設定形式やプロトコルが異なるため、あるアプリでインポートに失敗しても、すぐにスマートフォン側の問題とは限りません。先にサブスクリプションの提供元が対応している形式を確認してから、クライアントを選びましょう。インストーラーは端末のアーキテクチャに合ったものを使います。古い端末や特殊な端末ではシステム情報を確認し、メーカー名だけで選ばないでください。

ブラウザーやファイル管理アプリからインストーラーを開くと、その入手元からのアプリインストールを許可するよう求められる場合があります。必要な入手元だけを許可し、インストール後は端末の方針に応じて許可を取り消してください。既存アプリと署名が一致しないと表示された場合、通常はそのまま上書きできません。必要な設定をエクスポートし、新旧アプリの入手元とパッケージ名を確認してから、アンインストールするか判断します。アンインストールで設定、ログ、権限が消える場合があるため、最初のトラブルシューティングとして安易に行わないでください。

サブスクリプションを追加してシステムトンネルを作成する

クライアントの設定またはサブスクリプション管理画面を開き、リモートURLを追加して保存後に更新します。その設定を現在の設定として選択してください。設定名には見分けやすい任意の名前を使い、認証情報を含むURL全体は書かないでください。ローカルファイルを追加する場合は、システムのファイル選択画面からアクセスを許可します。ダウンロードフォルダーにファイルがあっても、クライアントが自動で読み取れるとは限りません。追加後、プロキシグループが表示されるか、未対応項目のエラーがないか確認します。

起動ボタンを押すと、通常AndroidからVPN接続の許可を求められます。このVPN権限はクライアントが端末内の通信を受け取るためのもので、システムがリモート接続先を自動で提供するという意味ではありません。いま起動したアプリからの要求であることを確認してから許可してください。一般的な環境では、同時に使えるシステムVPN接続は通常1つです。ほかのVPN、ファイアウォール、同じ仕組みを利用するフィルターアプリが接続を置き換える場合があります。切り替える前に、どのアプリを停止するか確認しましょう。

モバイル端末のシステムトンネルは、デスクトップの「システムプロキシを設定」とは異なります。Wi-Fiの詳細設定で同じローカルプロキシをもう一度入力する必要はありません。Wi-Fiの手動HTTPプロキシは一部のアプリと現在のネットワークにしか適用されないことがあり、重ねて設定すると誤ったポートへ通信が送られる場合があります。まず通信を振り分ける経路を1つだけ使い、ブラウザーと対象アプリの接続ログが記録されることを確認してから、アプリごとの振り分けやLANサービスを検討してください。

アプリごとの振り分けとバックグラウンド制限

クライアントにアプリごとの設定がある場合、「選択したアプリのみプロキシを使用」と「選択したアプリをプロキシから除外」のどちらが有効か確認してください。同じアプリを選んでも、モードによって意味は逆になります。アプリ一覧では通信をトンネルに通すかを決め、ドメインやアドレスのルールではトンネルに入った通信の接続先を決めます。2段階に分けて確認してください。対象アプリのリクエストがログにまったくない場合は、ドメインルールを増やす前にアプリ一覧を確認します。

画面ロック後の切断は、システムのバッテリー管理が原因であることがあります。まずクライアントにフォアグラウンドサービスの通知が表示されているか確認し、端末のバッテリー設定でアプリのバックグラウンド実行が制限されていないか確認してください。メーカーによって自動起動、バックグラウンド動作、省電力の設定名は異なります。端末全体の省電力機能を無効にせず、対象アプリに関する項目だけを調整しましょう。テストでは画面点灯中、ロック中、長時間の待機後それぞれの接続を確認し、起動直後だけで判断しないでください。

「VPNを常時接続」と「VPNを使用しない接続をブロック」はシステム全体に適用される設定です。後者はクライアントの起動前や設定が無効になったときに、ほかのネットワーク通信まで遮断する可能性があります。動作を理解し、再起動後のテストが済んでから有効にしてください。クライアントの自動再接続とシステムによる通信遮断は、作用するタイミングが異なります。強制設定を解除する場合は、アプリ内のスイッチを切るだけでなく、システム設定が元に戻ったことも確認してください。

DNS、プライベートDNS、テザリングの注意点

AndroidのプライベートDNS、クライアントのDNS、アプリ独自の暗号化DNSが同時に動作している場合があります。ドメインへのアクセスに問題がある場合は、まず各設定の現在の状態を記録し、1つずつテストして比較してください。同時に複数の設定を変えないでください。アプリによってはDNSキャッシュや既存の接続を再利用するため、設定変更後に新しいリクエストを行う必要があります。IPアドレスにアクセスできるというだけで、すべてのDNS機能を恒久的に無効にする必要があるとは判断できません。

スマートフォンのVPNは、通常、テザリングで接続した他の端末の通信を自動的には取り込みません。パソコンからスマートフォンのプロキシを使うには、クライアントがLANでの待ち受けに対応していることを確認し、到達可能なアドレス、認証、ファイアウォールを設定する必要があります。これはテザリングを有効にすることとは別の設定です。一般的なモバイル利用では、LANからのアクセスを無効にしておくことをおすすめします。モバイル通信ではサブスクリプションを更新できず、Wi-Fiでは成功する場合は、通信権限、ネットワーク制限、提供元への接続可否を確認し、ネットワークの違いを設定の破損と誤認しないようにしてください。

iOSへのインストールとトンネル設定

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

iPhoneとiPadではClash Plusを利用できます。インストール方法はiOSクライアントをご覧ください。App StoreのClash Plusを直接開くこともできます。製品の公式サイトはclashplus.ioです。インストール前にストアのページでOSの対応状況を確認し、端末に表示される情報を基準にしてください。他プラットフォーム向けのインストーラーをモバイルOSに取り込むことはできません。サブスクリプションを使うために、出所不明の構成プロファイルをインストールする必要もありません。

初回起動後は、設定画面、プロキシモード、接続スイッチを確認します。通知権限とネットワークトンネルの権限は用途が異なります。通知は状態表示やアラートに使い、トンネルの作成にはシステムによるVPN構成の確認が必要です。学校や組織が管理する端末では、ネットワーク機能が制限されていることがあります。利用できる範囲を事前に確認してください。アプリをインストールしただけでは利用可能な設定は用意されません。続けてサブスクリプションを追加し、適切な接続先を選びます。

リンクを追加し、設定の入手元を確認する

提供元から受け取ったサブスクリプションURLをすべてコピーし、クライアントでリンクから設定を追加します。任意の設定名を入力して保存してください。クリップボードへのアクセス確認が表示されたら、貼り付けを行っていることを確認して許可します。ブラウザーからのクイックインポートでは、アプリの関連付けを通じてクライアントが起動します。切り替わらない場合はクライアントに手動で追加してください。同じリンクを何度も開いて、見分けにくい設定を増やす必要はありません。アカウント情報を含むサブスクリプションURLを、公開メモや共有スクリーンショットに保存しないでください。

更新が完了したら設定を選択して、プロキシグループを確認します。インポート後にリストが空の場合は、ダウンロードが成功したか、取得した内容が設定ファイルか、クライアントがその形式に対応しているかを確認してください。ノード情報とルールが同じファイルに含まれる場合もあれば、クライアントが対応する別の構造で整理されている場合もあります。ファイルサイズだけで内容が完全かどうかは判断できません。手動で編集する前にコピーを保存し、形式の修正で元のインデントやグループ名を壊さないようにしてください。

VPN構成を許可し、ルールの動作を確認する

初回接続時にシステムからVPN構成の追加を求められます。端末のパスコードなどで確認が必要な場合があります。許可したらアプリに戻って接続状態を確認し、ブラウザーで新しいリクエストを送信してください。ステータスバーにVPNアイコンが表示されても、それだけでリモートサーバーが正常に動作していることや、すべての通信が同じ接続先を経由することは保証されません。ルールモードでは一部のドメインが直接接続される場合があります。動作確認では、適用されたルールとプロキシグループの両方を確認してください。

iOSのクライアントは通常、システムのネットワーク拡張を利用して通信を受け取ります。デスクトップのHTTPプロキシ設定とは異なる仕組みです。Wi-Fiの詳細にある手動プロキシ設定は別の経路であり、クライアントを起動するために追加で設定する必要は通常ありません。端末に他のVPN構成がある場合は、どの接続が現在有効か確認してください。複数のアプリを何度も切り替えると、システムが使用する構成が変わることがあります。トラブルシューティング中はクライアントを1つに絞り、設定の関連付けによる影響を減らしましょう。

ルールの適用状況は、今回の接続ログを基準に確認してください。アプリが既存の接続を再利用する場合、ルールを変更しても同じページを再表示するだけでは新しい判定が行われないことがあります。対象ページを閉じてから再アクセスし、必要に応じて対象アプリを再起動してください。1つのドメインを確認するために端末全体のネットワーク設定を何度もリセットする必要はありません。ルールが参照するプロキシグループが存在しない場合は、グループ名かサブスクリプションとの互換性を修正します。エラーを隠すために、すべての通信を恒久的にグローバルモードへ切り替えないでください。

バックグラウンド動作とオンデマンド接続

システムトンネルとアプリの画面は別々に動作するため、他のアプリに切り替えても接続が停止するとは限りません。逆に、画面を強制終了してもトンネルが停止したとは判断できません。停止するときはクライアントの接続スイッチを使い、システムのVPN状態も確認してください。オンデマンド接続に対応している場合は、まず起動条件を確認し、Wi-Fiとモバイル通信の両方でテストします。自動起動、ネットワーク切り替え時の再接続、特定のネットワークの例外が設定されているか確認してください。

画面ロックから復帰した後にアプリが一時的に読み込めない場合は、新しいリクエストを送ってログを確認し、既存の接続が切れたのか、トンネルが継続して使えないのかを切り分けます。低電力モード、ネットワーク切り替え、接続先サービスのセッション制限も影響するため、一度再接続しただけで原因を特定することはできません。ネットワークが変わると、サブスクリプションに記載されたサーバーへの到達性も異なる場合があります。別のネットワークでの結果をそのまま当てはめず、現在のネットワークでテストしてください。

端末の移行と設定の更新

端末を変更したら、システムVPNの権限、現在の設定、プロキシグループの選択を確認し直してください。端末のバックアップで接続権限まで完全に復元されるとは限りません。設定をエクスポートする前に、サブスクリプションの認証情報やサーバーのパスワードが含まれていないか確認し、信頼できる方法でのみ転送してください。デスクトップ用コアのファイルには、待ち受けポート、ネットワークインターフェース、ローカルパスなどが含まれる場合があります。これらの項目をモバイルクライアントがどう扱うかは実装によって異なるため、1つずつそのままコピーせず、互換性のある設定を使ってください。

サブスクリプションを定期的に更新すると、提供元の変更を反映できます。ただし、ネットワーク障害中に更新を何度も繰り返すのは避けてください。まず現在の設定がまだ使えるかを確認し、更新リクエストが成功したか、リモートの内容が変わったか、同じ設定が選択されているかを順番に調べます。更新時の一般的なトラブルについてはサブスクリプション更新の問題をご覧ください。正常に読み込める設定のバックアップを残しておくと、「取得に失敗した」のか「新しい設定が使えない」のかを切り分けやすくなります。

Linuxデスクトップとコアの導入

GUIクライアントと独立したコアから選ぶ

LinuxデスクトップではLinux用インストーラーからClash Verge RevまたはFlClashを選べます。まずディストリビューション、プロセッサのアーキテクチャ、パッケージ形式を確認し、ディストリビューションが対応する方法でインストールしてください。ダウンロードページのパッケージがすべてのディストリビューションやアーキテクチャに対応しているわけではありません。他のOS向けのパッケージは、拡張子を変更しても使えません。インストール時はパッケージ管理ツールが表示する依存関係を確認してください。依存関係の競合が起きた場合は原因を特定し、チェックを強制的に無視しないでください。

GUIクライアントは、サブスクリプションの追加やプロキシグループの切り替えを簡単に行えます。単独のMihomoコアは、サーバー、ルーター、自分でサービスを管理するユーザーに適しています。ダウンロード先はコアのダウンロードをご覧ください。コアにはGUIがなく、ファイルを解凍した後に実行権限、設定ディレクトリ、起動方法を用意する必要があります。一般的なデスクトップ利用では、プロキシを使うためにバックグラウンドサービスを構築する必要はありません。まずGUIクライアントで通信経路を確認すると、導入時の確認項目を減らせます。

GUIでサブスクリプションとプロキシを設定する

インストール後に設定画面からリモートサブスクリプションを追加し、ダウンロード後に設定を選んでログを確認します。GUIが正常に表示されていても、コアのプロセスが起動しているとは限りません。実際の待ち受けアドレスとポートを確認してください。デスクトップ環境によってシステムプロキシの対応状況は異なります。デスクトップの設定を参照するアプリ、環境変数だけを参照するアプリ、独自のネットワーク設定を使うアプリがあります。そのため、「ブラウザーでは成功するがターミナルでは失敗する」場合でも、ノードが原因とは限りません。

ログイン用のスクリプトをすぐに変更せず、ターミナルのテスト中だけプロキシを指定できます。以下の環境変数が影響するのは、現在のシェルとそこから起動する子プロセスだけです。すでに起動しているデスクトップアプリには自動的に適用されません。テストが終わったら変数を解除し、クライアント終了後もターミナルからローカルポートへリクエストが送られないようにしてください。アドレスとポートにはクライアントが実際に待ち受けている値を指定します。認証情報を使う場合は、公開状態のスクリプトにパスワードを書かないでください。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl --head https://example.com
unset http_proxy https_proxy

ここではHTTPSの接続先へHTTPプロキシを通してトンネルを作成するため、プロキシアドレスにHTTPを使っても矛盾しません。大文字の環境変数、システム全体の環境設定ファイル、ツール独自の設定がテスト結果に影響していないかも確認してください。コンテナ、リモートセッション、サンドボックスのアプリには、それぞれ異なるネットワークや環境の制約があります。コンテナ内のローカルアドレスは通常ホスト側を指しません。デスクトップと同じポートを設定しただけで、サービスが使えないと判断しないでください。

独立コアの配置場所と実行ユーザー

手動で導入する場合は、解凍した実行ファイルを管理された場所に置き、実行権限を付与します。設定ファイルと実行データ用のディレクトリも分けて用意してください。まずフォアグラウンドで起動し、設定の解析とポートの待ち受けが成功することを確認してから、サービスとして登録します。以下の例では実行ファイル名をmihomoとし、設定ファイルをユーザーディレクトリに保存しているものとします。このコマンドだけで有効なサブスクリプションが作成されたり、リモートサーバーの情報が補われたりするわけではありません。

mkdir -p "$HOME/.config/mihomo"
chmod u+x ./mihomo
./mihomo -t -d "$HOME/.config/mihomo"
./mihomo -d "$HOME/.config/mihomo"

テストに成功しても、確認できるのは設定を解析できたことだけです。リモートサービスへの接続までは保証されません。サービスとして登録する際は、実行ユーザー、作業ディレクトリ、起動コマンド、設定ファイルのパスを明確にしてください。サービス用アカウントが別の初期設定を読み込んでいる場合があります。ログや更新データの保存先にも適切な書き込み権限が必要です。権限設定を簡単にするために、すべてのファイルを全ユーザーから書き込み可能にしないでください。設定にアカウント情報やコントロールインターフェースの認証情報が含まれる場合があります。

TUN、ルーティング、DNSに必要な権限

TUNの利用には、通常、仮想ネットワークデバイスへのアクセスやルートの変更に必要な権限が求められます。GUIクライアントは補助サービスを通じて処理する場合があり、独立したコアでは実行権限を自分で設定する必要があります。ネットワーク管理権限を任意のファイルに付与するコマンドを安易にコピーしないでください。まずバイナリの場所、更新方法、権限を与える範囲を確認します。バイナリを置き換えるとファイル単位の権限が変わることがあるため、更新後に改めて動作を確認してください。

有効にした後は、ルーティングや名前解決の状態を確認するツールで、ルート、待ち受けポート、システムのDNSサービスの変化を確認します。ディストリビューションによってDNS管理の仕組みは異なります。同じDNS設定ファイルを複数のコンポーネントで繰り返し上書きしないでください。リモートサーバーを管理中の場合は、別の管理セッションを残し、明確な復旧手段を用意してから操作します。デフォルトルートを誤ると現在の接続が切れることがあるため、GUIのスイッチだけで復旧できるとは限りません。

自動起動と停止後に残る設定の確認

デスクトップの自動起動項目はユーザーのログイン後に動作し、システムサービスはログイン前に起動する場合があります。バックグラウンドで常時動作させる必要があるかに応じて選び、同じポートを使うコアを両方から起動しないでください。再起動後は、サービス名が正常と表示されているかだけでなく、実際のプロセス、設定ディレクトリ、待ち受けポートを確認します。停止する際はプロキシとルートを元に戻してからプロセスを終了してください。ポートが競合する場合は、使用中のプロセスがどのサービスに属するか確認してから対処し、別のネットワークアプリを誤って停止しないようにしましょう。

よくある設定の問題とトラブルシューティング

症状から障害の発生箇所を特定する

トラブルシューティングを始める前に、OS、クライアント名、使用中の設定、プロキシモード、通信の振り分け方法を記録し、問題発生前の最後の変更も控えてください。ほかのプロキシやVPNを一時停止し、新しいリクエストを1回送信します。クライアントに接続がまったく届かない場合は、システムプロキシ、アプリ一覧、TUNのルートを確認してください。リクエストは届いているのに接続先へ接続できない場合は、プロキシグループとサーバーを調べます。接続が確立しているのにページが正常に表示されない場合は、DNS、ルール、アプリ固有の動作を確認してください。

「接続済み」という表示は、ローカルのコアが起動している、またはシステムトンネルが作成されたことだけを示す場合があります。アクセス経路全体が正常とは限りません。端末から通信を取り込めているかと、リモート接続先に到達できるかを分けてテストすると、間違った箇所を繰り返し変更せずに済みます。詳しい手順は接続済みなのにWebページが開けない場合の確認リストをご覧ください。ログにリモート接続のタイムアウトが記録されている場合は、ノードのタイムアウト・接続失敗時の確認手順も参照してください。

ルールの順序、グループ名、設定の更新

ルールは通常、上から順に評価され、最初に一致したルールで処理が決まります。広範囲に一致するルールを前に置くと、より具体的なルールが適用されないことがあります。フォールバック用のルールは通常末尾に置きます。以下の断片は構文の例であり、設定にPROXYという名前のプロキシグループが存在することが前提です。実際のグループ名が異なる場合は、既存の名前に置き換えてください。例に合わせるためだけに空のグループを作ったり、設定ファイルのトップレベルに同名のルール項目を重複して追加したりしないでください。

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

地域ベースのアドレスルールは、対応するデータが利用可能であることに加え、ドメインの名前解決結果にも左右されます。グローバルモードは一時的な比較には使えますが、ルール設定が正しいことの証明にはなりません。特定のサイトで問題が起きた場合は、選択中のプロキシグループだけでなく、その接続に適用されたルールと最終的な接続先を確認してください。リモート更新でグループ名が変わると、オーバーライド設定が古い名前を参照し、読み込みに失敗することがあります。更新前後のエラーを比較し、必要に応じて動作確認済みのバックアップに戻してから、1項目ずつ移行してください。

DNSとTUNの相互作用

DNSはドメイン名を接続可能なアドレスに変換します。プロキシ接続が成功しても、名前解決の経路が正しいとは限りません。仮想IPモードを有効にすると、一部のドメインにマッピング用のアドレスが割り当てられます。これはリモートサービスの実際のアドレスではありません。そのアドレスを他の端末にコピーしたり、クライアントを通さずに利用したりしても、接続できない場合があります。特殊なアプリとの互換性が必要な場合は、コアのドキュメントに従ってドメインの例外を設定し、ルールがドメイン情報を正しく取得できることを確認してください。

社内ドメイン、プリンター、ローカル端末にアクセスできない場合は、通信が誤ってトンネルに送られていないか、名前解決が元のネットワークを使っているかを確認します。すべてのDNSを一律にパブリックDNSへ置き換えても解決できるとは限りません。TUNを無効にして比較する場合も、システムプロキシやほかのDNS設定が引き続き有効になっていないか確認してください。元の通信経路に戻っていなければ、正しい比較になりません。IPv6にも独立したアドレス、名前解決、ルーティングがあります。一部のサイトだけで失敗する場合は、IPv4とIPv6の違いを調べ、すぐにIPv6を恒久的に無効にしないでください。

症状	優先して確認する項目	切り分け方法
すべてのアプリで接続できない	ネットワークの基本接続、残ったプロキシ設定、通信を強制するトンネル設定	通信の振り分けを順番に停止し、システム設定を元に戻す
一部のアプリだけ接続できない	アプリ内のプロキシ設定、振り分け対象の一覧、ループバック制限	該当する接続ログが記録されているか確認する
更新後に設定が使えなくなった	解析エラー、グループ名の変更、コアの項目との互換性	ローカルのバックアップと比較し、読み込みをテストする
ネットワーク切り替え後に接続できない	ルート、名前解決の参照先、サーバーへの到達性	通信の振り分けを再構築し、新しいリクエストを送信する

サブスクリプションの更新と速度テスト

更新に失敗したら、まずレスポンスの種類を確認します。接続タイムアウトはリクエストが完了していないことを示し、認証エラーの場合は認証情報とアカウントの状態を確認します。形式エラーの場合は、取得した内容を対象の形式として解析できないことを意味します。更新リクエストがプロキシを通るかどうかは、クライアントの実装や設定によって異なり、常に直接接続またはプロキシ経由とは限りません。古い設定で接続できる場合は、その設定を保存し、削除と再作成を繰り返さないでください。詳しくはヘルプセンターのサブスクリプション更新ガイドをご覧ください。

レイテンシテストの結果は、指定したリクエストがその時点でどう動作したかを示すものです。継続的なダウンロード速度とは異なり、すべてのWebサイトに接続できることも保証しません。テスト先、ハンドシェイクの段階、同時接続の状態によって結果は変わるため、条件を揃えて比較してください。接続先を選んだ後は、実際に使うアプリで必要な動作を確認します。関連する仕組みはレイテンシテストと実際の通信速度の違いをご覧ください。1回のテスト結果だけで判断せず、接続ログと実際の使用状況も確認してください。

問題の記録を残してから安定した状態に戻す

ログを共有する前に、サブスクリプションURL、アカウント情報、サーバーのパスワード、不要なネットワーク情報を削除してください。エラーの種類、発生時刻、原因の特定に必要な前後の情報だけを残します。詳細ログは問題の再現中だけ有効にし、完了後は通常のログレベルに戻してください。過剰なログが長期間生成されるのを防げます。設定を変更するたびに結果を記録し、改善しなければ元の値に戻します。症状を説明できる具体的な違いが見つかるまで、これを繰り返してください。安定したら自動更新と自動起動を再び有効にします。最初から手順を確認する場合は使い方ガイドに戻り、一時的なトラブルシューティング用の設定を通常の設定として使い続けないでください。