ドキュメント · プラットフォーム別ガイド

Clashの全プラットフォーム
インストール・設定ガイド

クライアントのインストール、サブスクリプションの追加、システムプロキシ、TUNの設定。
システム権限から接続確認まで、実際の通信経路に沿って順番にチェックできます。

初めて使う場合は、まずガイドに沿って接続を確認してください。このページでは、OSごとの違いや設定値の範囲、復旧手順をまとめています。インストール前の確認やトラブル時にご活用ください。メニュー名はクライアントによって異なるため、実際の画面と各プロジェクトのドキュメントを確認してください。

01 · 共通の準備

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

Clashクライアントは、設定の管理、モードの選択、接続ログの確認、システムとの連携を行います。コアはルールを解析して接続を確立し、サブスクリプションは設定プロバイダーから提供され、通常はノード、グループ、ルールを含みます。クライアントをインストールしても、利用可能なノードが自動で手に入るわけではありません。また、サブスクリプションを追加しただけでは、システムの通信がクライアント経由になるとは限りません。トラブル時はこの3つを分けて確認しましょう。まず設定を読み込めるか、次に選択した出站先へ接続できるか、最後にアプリの通信がクライアントへ渡っているかを確かめます。

当サイトでは、対応プラットフォームでClash Plusを第一候補として紹介しています。そのほかのクライアントは、OSや使い方に合わせて選んでください。mihomoはClashエコシステムで開発が続くコアの一つですが、すべてのクライアントが同じ設定項目に対応しているとは限りません。モバイル版の設定パーサー、デスクトップ版のコアのバージョンや画面機能には違いがあります。別の端末へ設定を移す前に、プロバイダーが提供する形式を確認し、移行先のクライアントが必要なプロトコル、ルール形式、DNS設定に対応しているかを調べてください。

OSのアーキテクチャと入手元を確認する

システムのデバイス情報やバージョン情報を開き、OS、プロセッサのアーキテクチャ、空き容量を確認します。デスクトップではx64やARM64が一般的です。MacではIntelとApple Siliconの違いにも注意してください。Linuxではパッケージ形式も確認が必要です。PCのメーカー名だけでインストーラーを選ばないでください。対応するOSの入口はクライアントのダウンロードページで確認できます。最低動作要件は選んだクライアントのリリース情報を参照し、別のクライアントの要件をそのまま当てはめないでください。

インストール前に、古いプロキシソフトを終了し、現在のシステムプロキシ、DNS、ほかのVPNの状態を控えておきます。会社や学校の端末では、管理ポリシーによって設定が固定されている場合があります。変更できる範囲を先に確認してください。既存の設定は、復元できるよう個人用のローカルフォルダーへエクスポートしておきましょう。サブスクリプションURLを含むスクリーンショットや設定ファイル、QRコードを公開の掲示板にアップロードしてはいけません。URLに含まれるアクセス用パラメーターは認証情報にあたることがあります。漏えいした場合はプロバイダーで再発行してください。

設定の入手元と通信の経路を確認する

リモートサブスクリプションは継続的な更新に向いており、ローカルYAMLは固定設定の保存に便利です。Base64でエンコードされたノード一覧が、完全なClash設定とは限りません。インポート時に項目不足のエラーが出たら、まず形式を確認し、エラー行をむやみに削除しないでください。変換ツールは、入手元の信頼性とデータの扱いを確認したうえで利用しましょう。3つの形式を比較する場合は、サブスクリプションURL・YAML・Base64の形式とインポート方法をご覧ください。

主な通信のプロキシ方式
方式対象最初に確認する項目
システムプロキシシステムプロキシ設定に従うアプリローカルの待ち受けポートとプロキシの有効状態
アプリ内プロキシアドレスを手動入力する個別アプリプロトコル・アドレス・ポートの一致
TUN / VPN仮想ネットワークインターフェース経由の通信権限・ルート・DNSの制御

システムプロキシはアプリにプロキシアドレスを通知するだけで、すべてのプロセスに利用を強制するものではありません。TUNは仮想インターフェースとルートを使って通信を処理するため、追加の権限が必要になることが多く、ほかのVPNとも競合しやすくなります。初回設定ではクライアントの推奨値を使い、接続を確認してから設定を広げてください。方式を切り替えるときは、一度に変更する項目を一つにし、ログの時刻も控えます。そうしないと、ノード、名前解決、ルートのどこが変わったのか判断しづらくなります。

再現できる確認手順を用意する

安定して直接接続できるサイトと、特定の出站先が必要なサイトを一つずつ用意し、それぞれ名前解決、ページ表示、ログ上のルール判定を記録します。初回はルールモードを使い、グループから利用可能な出站先を手動で選んでください。自動選択のままでは原因が見えにくくなることがあります。ブラウザーのキャッシュ、既存の長時間接続、アプリ独自のプロキシ設定も確認結果に影響します。設定を変えたら新しい接続を作って確かめましょう。ページを一度再読み込みできただけで、すべての通信が復旧したと判断しないでください。

クライアントを使っても、接続先サービスの利用ポリシーは変わりません。利用前に、居住地域の法律、組織のネットワーク規則、サービス利用規約を守ってください。準備が済んでいて、まず接続だけを確認したい場合はクイックスタートガイドへ進んでください。特定OSの権限、バックグラウンド動作、ルートの問題を調べている場合は、下の該当章を確認し、最後の章の手順で接続を検証しましょう。

02 · Windowsのインストールとプロキシ設定

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

まず設定画面のシステム情報でOSの種類を確認し、Windowsのダウンロードページへ進みます。まずはClash Plusをお試しください。異なる画面やワークフローが必要な場合は、Clash Verge Rev、FlClash、Clash Nyanpasuも検討できます。Clash for Windowsは開発が終了しているため、アーカイブ版としてのみ扱い、新しいOSとの互換性問題を解決する目的で古いクライアントへ何度も切り替えることはおすすめしません。インストーラーが現在のアーキテクチャに対応しているかは、ダウンロード項目の説明を確認してください。

インストール版はウィザードに従って保存先を選びます。ポータブル版は、現在のユーザーが書き込める固定フォルダーに展開し、圧縮ファイル内から直接起動しないでください。初回は通常ユーザー権限のまま起動し、アプリが開くことと設定フォルダーに書き込めることを確認します。入手元やセキュリティリスクについて警告が表示されたら、ダウンロード元と警告の詳細を確認してください。インストールのためにシステム全体の保護機能を無効にしてはいけません。組織管理のPCでは、導入の可否を管理者に確認してください。

サブスクリプションを追加して出站先を選ぶ

設定、サブスクリプション、Profilesなどの画面からリモート追加を開き、完全なURLを貼り付けて登録します。成功すると、入力欄にURLが残るだけでなく、選択可能な設定が表示されます。設定を選び、グループが表示されるか確認してください。空のリストしか表示されない場合は、設定の読み込みログを確認します。クライアントによっては、設定のダウンロードと有効化が別の操作です。更新に成功した後も、現在有効な項目を確かめ、古いファイルを使い続けないようにしてください。

出站モードをルールにし、プロキシを使うグループでノードを選択します。遅延テストが示すのは特定の測定先への応答時間であり、すべてのプロトコルやサイトに接続できることを保証するものではありません。初回の確認では、実際のアクセスと接続ログをあわせて見てください。サブスクリプションのダウンロードに失敗したら、直接接続できるネットワークから再試行し、サービスの有効期限やURLがログインページへ転送されていないかを確認します。WebページをYAMLとして保存して再インポートするのは避けてください。

混合ポートとシステムプロキシを確認する

設定画面で実際の待ち受けポートを確認します。混合ポートの例として7890がよく使われますが、PCによって異なる値の場合があります。混合ポートは通常HTTPとSOCKSの両方を受け付けます。システムプロキシへの反映方法は、クライアントの案内に従ってください。有効にしたら、Windowsの「ネットワークとインターネット」設定で、手動プロキシのアドレスがローカルホストを指しているか確認します。リモートノードのサーバーアドレスをシステムプロキシに入力しないでください。両者は異なる役割です。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

上記のPowerShellコマンドは、ポートの待ち受け状態を確認するものです。結果が表示されない場合は、コアが起動していないか、実際のポートが異なる可能性があります。別のプロセスが使用中と表示されたら、まずどのアプリかを特定します。古いクライアントを終了するか、ポートを変更してください。正体の分からないシステムプロセスを直接終了してはいけません。ポートを変更した場合は、アプリ内で手動設定したプロキシも合わせて変更します。設定ファイルを書き換えただけでクライアントを再読み込みしていない場合、実際の待ち受けポートは古いままのことがあります。

TUN・UWP・ファイアウォールの注意点

ブラウザーは正常でも一部アプリがプロキシを使わない場合は、まずそのアプリがシステム設定に従うか確認してください。TUNが必要なら、クライアントの案内に従ってサービスをインストールするか管理者権限を許可し、仮想インターフェースを有効にします。サービスのインストールと、毎回管理者として実行することは別です。サービスを導入済みのクライアントは、起動のたびに昇格が必要とは限りません。有効にした後はルートとログを確認します。ネットワークが切れた場合は、ほかのVPNや高速化ソフトを重ねる前にTUNを無効にして、通常の接続に戻してください。

一部のUWPアプリにはループバック通信の制限があり、ローカルプロキシが正常でも接続できないことがあります。クライアントにループバック管理機能がある場合は、それを使い、必要なアプリだけ例外に設定してください。すべてのアプリの制限をまとめて解除したり、ループバックの問題をルール設定の誤りと決めつけたりしないでください。操作の可否はシステムポリシーに左右されます。会社管理の端末で権限がない場合、何度も権限昇格を試すのではなく、通常のブラウザーで同じ接続先を確認してください。

ファイアウォールがネットワークアクセスの許可を求めた場合は、用途に応じたネットワーク範囲を選択します。PC内だけで使うなら、すべてのパブリックネットワークに受信接続を許可する必要はありません。LANで共有する場合は、待ち受けアドレス、認証、信頼できるネットワーク範囲も確認してください。スリープからの復帰後や異常終了後に、クライアントが終了しているのにシステムプロキシがローカルポートを指している場合は、システム設定で残ったプロキシを無効にしてからクライアントを再起動します。最後にルールログを確認しましょう。初回の確認項目については混合ポート・モード・システムプロキシのチェックリストもご覧ください。

03 · macOSのインストールと権限設定

プロセッサを確認してアプリを配置する

Appleメニューの「このMacについて」でチップ情報を確認します。Apple SiliconとIntelでビルドが異なる場合は、該当するインストーラーを選び、macOSのダウンロードページから入手してください。まずはClash Plusをおすすめします。用途に応じてClash Verge RevやFlClashも検討できます。ClashX Metaは開発が終了しています。アーカイブ版のOS対応や機能を、更新が続いているクライアントと同じように考えず、名前が似ているという理由だけでメンテナンス状況を見落とさないようにしてください。

ディスクイメージをダウンロードして開き、アプリを「アプリケーション」フォルダーへドラッグしてから、そのフォルダー内のアプリを起動します。ディスクイメージ内から起動し続けないでください。保存場所の変化によるアップデートや権限の問題を避けやすくなります。初回起動をシステムに止められた場合は、まず入手元を確認し、「プライバシーとセキュリティ」に表示された説明を確認します。すべてのアプリからセキュリティ属性を一括削除するコマンドを使ったり、個別アプリの警告を回避するためにシステム全体の保護を無効にしたりしないでください。

拡張機能・ヘルパーサービス・キーチェーンを確認する

macOSクライアントは、システムプロキシ、特権ヘルパーサービス、ネットワーク拡張などを使って通信を制御します。実装が異なれば、表示される許可画面も同じとは限りません。実際にクライアントが表示した要求だけに対応してください。VPN構成やネットワーク拡張の追加を求められたら、要求元のアプリ名を確認します。ヘルパーサービスのパスワードを求められた場合も、ダイアログの発行元を確認してください。特定の画面が表示されないからといってインストール不足とは限りません。存在しない設定を探して手順を補う必要はありません。

一部の権限はシステム設定で明示的に許可してから、クライアントで再試行する必要があります。システムの再起動を求められることもあります。その場合は作業内容を保存し、表示された手順を完了してから拡張機能の状態を確認してください。キーチェーンのダイアログは、認証情報の保存や読み取りに関するものが一般的です。入力するのは指定されたシステムキーチェーンのパスワードで、サブスクリプションサービスのパスワードではありません。拒否した後に機能しなくなった場合は、アプリの案内とキーチェーンアクセス権を確認し、キーチェーンの項目をすべて削除するのは避けてください。

サブスクリプションの追加とメニューバーの操作

クライアントの設定管理画面からリモートサブスクリプションを追加し、ダウンロード後の設定を有効にします。ローカルYAMLを使う場合は、ファイルのインポート機能か設定フォルダーを開く機能を利用してください。拡張子が二重になっていないかも確認しましょう。設定を読み込めたら、グループを確認し、メニューバーからルールモードと出站先を選択します。メニューバーにアイコンがあるのは、画面側が起動中というだけです。コアの状態、使用中の設定、システムプロキシが有効かも確認してください。

初回はシステムプロキシを使い、新しいブラウザーウィンドウでテスト先にアクセスしながら、接続ログに記録されたルールを確認します。一部のコマンドラインツールは、GUIのシステムプロキシ設定を参照しません。ターミナルからアクセスできなくても、すぐにクライアントの故障とは判断できません。1回限りのコマンドにプロキシを明示して、ローカルの接続先が応答するか確かめられます。以下のコマンドのポートは、クライアントの実際の値に置き換えてください。ターミナルの環境設定を恒久的に書き換えるものではありません。

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

TUNとネットワークの切り替え

アプリがシステムプロキシに従わない場合は、クライアントが対応するTUNやネットワーク拡張による制御を検討します。有効にする前に、ほかのVPNを終了し、必要な権限が許可されていることを確認してください。仮想インターフェースを作成した後も、DNSと出站ルートを確認します。接続中の表示だけでは、すべての通信が想定したルールを通っているとは限りません。社内ネットワーク、プリンター、ローカルの開発サーバーは個別にテストし、必要なら実際のネットワーク範囲に応じて直接接続を設定します。出所の分からない大規模なルート除外設定をそのままコピーしないでください。

Wi-Fiから有線LANへ切り替えたときや、テザリングに接続したとき、スリープから復帰したときは、システムプロキシの対象となるネットワークサービスが変わることがあります。ブラウザーが突然使えなくなったら、まず現在のネットワークで直接接続できるか確認し、その後クライアントの待ち受けとプロキシ設定を確認します。複数のプロキシツールを長期間同時に使っていると、後から起動したアプリが先行アプリの設定を上書きすることがあります。システムネットワークを制御するクライアントは一つに絞り、ほかのツールの制御機能を無効にしてから一つずつ検証してください。

終了前にシステムプロキシを無効にするかトンネルを切断し、異常終了後にローカルアドレスを指すプロキシが残らないようにします。アンインストールするときは、まずアプリ内の機能でインストール済みヘルパーサービスを削除し、システム設定で関連するVPNや拡張機能を確認してください。別のクライアントの手順を参考にして、ファイルを手動削除するのは避けましょう。同じ種類のソフトでも識別子は異なる場合があります。権限を拒否した後の復旧方法は、macOSのネットワーク拡張とキーチェーンの権限設定を参照し、実際に表示される画面に沿って確認してください。

04 · Androidのインストールとバックグラウンド動作

アーキテクチャとインストール権限を確認する

Androidのダウンロードページを開き、まずClash Plusを確認してください。Clash Meta for Android、FlClash、Surfboardも選択肢です。最近の端末の多くはARM64ですが、旧型端末や特殊なOSではプロセッサとアプリの対応状況を確認してください。汎用パッケージの有無はダウンロードページで確認できます。Surfboardは独自の設定形式を使うため、任意のClash YAMLをそのままインポートできるとは限りません。設定プロバイダーに、対象クライアント対応の形式を問い合わせてください。

APKをインストールするときは、現在使用しているブラウザーやファイル管理アプリに対し、「不明なアプリのインストール」を許可するよう求められることがあります。この権限は特定のアプリに対するものです。インストール後は必要に応じて無効にできます。解析エラーが出たら、まずダウンロードが完了しているか、OS要件とアーキテクチャが一致しているか確認します。更新時に署名の競合が表示される場合、入手元やビルドが異なる可能性があります。すぐにアンインストールせず、先に設定をエクスポートし、アカウント情報やローカル設定を復元できることを確認してから移行方法を決めてください。

設定を追加してVPN接続を許可する

サブスクリプション管理を開き、リモートURLを追加してダウンロード完了を待ち、設定を選択します。ローカルファイルを使う場合は、システムのファイル選択画面から読み取り権限を許可してください。ほかのアプリの専用フォルダーにあるファイルは直接開けないことがあります。自分で管理できるフォルダーに保存してから追加してください。サブスクリプション一覧に名前が表示されても、内容が有効とは限りません。ノードやグループが読み込まれているか確認し、エラーがあればダウンロード応答と設定の解析ログを確認します。

接続を開始すると、Androidは通常VPN接続の要求を表示します。要求元がインストールしたばかりのクライアントであることを確認してから許可してください。ここでいうVPNは、システムが提供するローカル通信の制御インターフェースです。端末がリモートVPNサーバーを自動的に取得するという意味ではありません。最終的な出站先は設定内のノードとルールによって決まります。接続後は通常、ステータスバーやVPN設定に状態が表示されますが、アイコンだけでは目的のサイトに接続できたか分かりません。

アプリごとの通信制御・ルールモード・DNS

モバイル版では、トンネルを通すアプリを指定できる場合があります。まず一覧が対象アプリを「含める」方式か「除外する」方式か確認してください。意味は逆で、前者は選択したアプリだけを制御し、後者は選択したアプリを迂回させます。設定を変更したら接続を作り直し、アプリによっては完全に終了してから再起動してください。接続ログにアプリが表示されない場合は、ノードを変更したりすべての分流ルールを無効にしたりする前に、アプリのフィルター設定を確認します。

アプリの通信がトンネルに入った後も、通常はドメイン、アドレス、ルールセットに基づいて出站先が選ばれます。アプリのフィルターとルールによる分流は異なる層の設定です。アプリを許可したからといって、そのすべての通信が直接接続されるとは限りません。ローカル機器の検出、画面共有、家庭内サービスでは、LANの迂回設定とDNSも確認してください。AndroidのプライベートDNSやアプリ独自のセキュアDNSは、名前解決の経路を変えることがあります。トラブル対処では、元の設定を記録して一時的に比較し、その結果を見てから変更してください。

バッテリー管理とネットワーク切り替え

画面消灯後に切断される場合は、まずバッテリー最適化、バックグラウンド動作、自動起動、通知の権限を確認します。設定名はメーカーごとに異なるため、すべてのアプリを一括で許可するのではなく、システムのアプリ情報から対象クライアントの設定を探してください。バックグラウンド動作を許可すると、バッテリー消費が増える場合があります。まずシステムによる停止が原因かを確認しましょう。モバイルデータ通信だけが切れる場合は、アプリのバックグラウンド通信制限や、契約プラン・ネットワーク側の制限も確認してください。

Wi-Fiとモバイルデータを切り替えると下位の接続が再確立され、既存の長時間接続が切れる場合があります。ネットワークが復旧したら、クライアントが自動で再接続するか確認し、必要に応じてVPNを切断して再起動します。複数のモードを連続して切り替えると、ログに手動切断と実際の障害が混在するため避けてください。システムの「常時接続VPN」や「VPN未接続時の接続をブロック」が有効な場合、クライアント停止中に端末が通信を拒否することがあります。システムのVPN画面で動作を確認してください。

通常、同じユーザー環境でシステムVPNインターフェースを使えるアプリは一つです。ローカルファイアウォール、広告ブロックツール、ほかのVPNがインターフェースを占有することがあります。起動前に競合するアプリを確認してください。学校や職場の端末では、ユーザーによるVPN追加が禁止されている場合もあるため、管理ポリシーに従います。LANで共有する場合も、スマートフォンが接続済みだからといって、テザリングの通信がトンネルに入るとは限りません。OSとクライアントの対応状況を確認してください。

設定後は、アプリを前面で使うとき、画面ロック後しばらく経ってから、ネットワークを切り替えた後の3つの状態で接続を確認し、ログの出站先も調べます。使用を終えるときはクライアントから切断し、システムのVPN表示が消えたことを確認してください。サブスクリプションの更新に成功したのにグループが変わらない場合は、現在有効な設定とローカルの上書き設定を確認します。よくある原因は、コアが新しいノードを読み込んでいないことではなく、別のサブスクリプションを更新したことです。

05 · iOSのインストールと接続設定

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

iPhoneとiPadではClash Plusをおすすめします。iOSのダウンロードページから、またはApp Storeのページを開いてインストールしてください。公式サイトはclashplus.ioです。インストール前に、ストアに掲載されている現在のOS互換要件とアプリ情報を確認してください。インストール可否はアカウントと端末の状態によって異なります。ほかのプラットフォーム向けのインストーラーやOS要件をiOSに当てはめないでください。

インストール後に初めて開いたら、まずサブスクリプション、グループ、接続画面の場所を確認してから設定を追加します。同じ名前の設定を複数追加すると、どれを使用中か分かりにくくなるため避けてください。ほかのプロキシアプリを利用中の場合は、設定とシステムVPNの状態を記録してから、古い接続を停止します。iOSはアプリのサンドボックスとバックグラウンドのネットワーク拡張を独自に管理します。デスクトップOSのように、常駐プロセスや待ち受けサービス、ドライバーのインストール画面を探す必要はありません。

サブスクリプションとローカル設定を追加する

設定またはサブスクリプション画面からリモートURLを追加し、完全なリンクを貼り付けて保存、更新します。QRコードを使う場合は、カメラの権限とコードの入手元に注意してください。読み取りは入力方法の一つであり、URLの安全性を保証するものではありません。ローカルファイルはシステムのファイル選択画面から実際のYAMLファイルを選びます。ファイルがクラウド上にあり、まだダウンロードされていない場合は、利用可能になってから再度インポートしてください。読み取りエラーを構文エラーと誤認しないようにしましょう。

インポート後、設定が正常で、グループと出站項目が表示されることを確認してから、現在の設定として選択します。ノードのサブスクリプションだけを提供するサービスでは、クライアント独自のルールテンプレートを適用する必要がある場合があります。完全な設定には、ルールとDNSが含まれていることがあります。両者を混同せず、クライアントのインポート案内を確認してください。未対応の項目がある場合は、対応形式の設定をプロバイダーから入手します。未知の項目を繰り返し削除して試すと、元の分流ロジックが変わるおそれがあります。

VPN設定を許可してルールを確認する

初回接続時に、システムからVPN設定の追加を求められ、端末のパスコードや生体認証で確認する場合があります。許可する前に要求元のアプリを確認してください。許可によってアプリがネットワークトンネルを作成できるようになりますが、サブスクリプションやノードの有効性が保証されるわけではありません。クライアントに戻って接続を開始し、ルールモードを選び、グループで出站先を指定します。新しい接続を試し、接続ログでルールの判定を確認してください。ステータスバーのVPN表示だけで結果を判断しないでください。

iOSでは通常、システムのネットワーク拡張を使って通信を制御します。デスクトップ版のように、各アプリへローカルのシステムプロキシを入力する必要はありません。専用のプロキシ入口、LAN設定、その他の通信制御機能があるかどうかは、実際のクライアントの機能を確認してください。初回はデフォルト設定を使うと、接続確認がしやすくなります。アプリの互換性やLANアクセスに問題がある場合に限り、迂回設定やDNSを確認し、一度に複数のネットワーク設定を変更しないようにしましょう。

バックグラウンド・オンデマンド接続・ネットワーク変更への対応

ホーム画面に戻った後も、アプリの画面とネットワーク拡張は別々に動作しています。画面に接続記録が一時的に表示されなくても、トンネルが停止したとは限りません。システムのVPN状態と実際の接続状況を合わせて確認してください。反対に、アプリを強制終了すると復旧に影響することがあり、日常的な切断方法には向いていません。プロキシを停止するときはアプリ内の接続スイッチを使い、システム設定でも接続状態が更新されたことを確認します。

オンデマンド接続を有効にしていると、条件を満たしたときにシステムがVPNを再起動し、手動で切断しても自動接続することがあります。アプリを繰り返し削除する前に、クライアントのオンデマンド設定とシステムのVPN設定を確認してください。会社管理の端末では個人VPNが制限されていたり、組織の設定がネットワーク動作を上書きしたりする場合があります。用途が分からない構成プロファイルを削除しないでください。まず目的を確認し、管理者の指示に従ってください。業務アカウントや証明書に影響するおそれがあります。

自宅のWi-Fiからモバイルデータに切り替えると、既存の接続を再確立する必要がある場合があります。まず、そのアプリにモバイルデータの使用が許可されているか確認し、現在の出站先に到達できるかを調べます。LAN内の特定サービスだけが使えない場合は、同じネットワーク上の機器のアドレスを試し、通信がルールによってプロキシへ送られていないか確認してください。ほかのプライバシー関連のネットワーク機能や、アプリ独自のセキュアDNSが確認結果を変えることもあります。設定項目を一つずつ記録して一時的に比較し、特定の機能を恒久的に無効にする必要があると決めつけないでください。

サブスクリプションの更新に失敗したら、まずサービスの状態と応答内容を確認し、直接接続できるネットワークでもう一度手動更新を試します。接続中にWebページを開けても、サブスクリプションの取得が同じ経路を使うとは限りません。バックグラウンド更新はクライアントの実装やシステムのスケジュールにも左右されるため、一定時刻に必ず実行されるとは考えないでください。端末を移行する前に、保護されたサブスクリプション情報と必要な設定を保存します。新しい端末で手動追加と接続確認を済ませてから、古い端末の設定を削除するか判断してください。

06 · Linuxクライアントとコアの実行

デスクトップクライアントとコマンドラインコアを区別する

Linuxのデスクトップユーザーは、LinuxのダウンロードページでClash Verge RevとFlClashを確認してください。おすすめは前者です。パッケージはディストリビューション、プロセッサのアーキテクチャ、パッケージ管理方式に合わせて選びます。Debian系ではdeb、ディストリビューションによってはrpmが使われますが、拡張子だけで依存関係の互換性を判断できません。サーバーやルーターではmihomoコアも選択肢になりますが、コマンドラインコアにはデスクトップ用のサブスクリプション管理画面やシステムプロキシ画面は付属しません。

ダウンロードしたパッケージは、ディストリビューションのソフトウェアインストーラーまたはパッケージ管理ツールでインストールし、依存関係の案内を確認してください。依存関係を満たすために異なるディストリビューションのソフトウェアリポジトリを混在させたり、正体の分からないスクリプトを高い権限で実行したりしないでください。デスクトップクライアントの起動後は、設定フォルダーに書き込めることと、コアが正常に起動することを確認します。トレイアイコンが表示されない場合はデスクトップ環境との連携が原因のこともあります。すぐに終了したと判断せず、ウィンドウやログを確認してください。

サブスクリプションを追加してデスクトップのプロキシを設定する

GUIクライアントでも、サブスクリプションの追加、設定のダウンロードと有効化、ルールモードと出站先の選択が基本の流れです。デスクトップ環境によってはHTTP、HTTPS、SOCKSのプロキシを個別に設定します。クライアントが案内するポートとプロトコルを指定してください。混合ポートが複数の接続方式に対応していても、プロトコル欄を任意に入れ替えてよいわけではありません。ブラウザー独自のプロキシ設定や、環境変数だけを参照するコマンドラインアプリもあるため、それぞれ個別に確認します。

curl -I --proxy http://127.0.0.1:7890 https://example.com
ss -lntp 'sport = :7890'

最初のコマンドで明示したHTTPプロキシへの接続をテストし、2つ目でローカルのTCP待ち受けを確認します。ポートは実際の設定に合わせてください。プロセス情報の表示には現在の権限が影響する場合があります。プロキシテストには成功し、デスクトップアプリだけ失敗する場合は、デスクトップ環境またはアプリ独自のプロキシ設定を確認します。ローカル接続そのものが拒否された場合は、まずコアの起動とポートを調べてください。待ち受けサービスがない状態でリモートノードを何度も変更しても、リクエストは出站の段階まで到達しません。

コマンドラインコアの確認と起動

mihomoを使う場合は、実行ファイルと個人用設定を場所が分かるフォルダーに置き、実際のファイル名で操作してください。実行ユーザーには、設定の読み取りとデータフォルダーへの書き込み権限が必要です。サブスクリプションやノード情報を含む設定は、ほかのユーザーに不要な読み取り権限を与えないでください。まず構文を検証し、次にフォアグラウンドで起動してエラー出力を確認します。以下のコマンドは、実行可能なmihomoと完全なconfig.yamlが現在のディレクトリにあることを前提としています。

./mihomo -t -d . -f ./config.yaml
./mihomo -d . -f ./config.yaml

構文チェックに通っても、ノードへの接続、ルール用リソース、ポートの競合が問題ないとは限りません。フォアグラウンドで正常に動作することを確認してからサービス化を検討してください。起動オプション、作業ディレクトリ、権限の問題がバックグラウンドに隠れるのを防げます。systemdを使う場合は、実行ファイル、設定、データディレクトリに実際の絶対パスを指定し、サービスユーザーが必要なファイルを読み書きできることを確認してください。サービスユニットを変更した場合は、管理設定の再読み込みも必要です。

TUNの権限・DNS・リモート環境からの復旧

TUNは仮想インターフェース、ルート、ネットワーク管理権限に関わるため、設定のスイッチを有効にするだけでは動きません。まずシステムにTUNデバイスがあることを確認し、選択したクライアントが推奨するサービスや権限の方法を使ってください。コンテナ内で実行する場合は、デバイスの割り当てとネットワーク名前空間も関係します。ホストで使えても、コンテナ内で使えるとは限りません。利便性のためにすべてのプログラムへ長期間ネットワーク管理権限を与えたり、用途を理解せずデスクトップ環境全体を最高権限で実行したりしないでください。

DNSはNetworkManager、systemd-resolved、デスクトップ環境の設定、クライアントの影響を同時に受けることがあります。まずどのサービスが名前解決を管理しているか確認し、制御する場所を決めてください。手動変更したファイルがシステムにすぐ上書きされる場合があります。Fake-IPを有効にした場合は、DNSリクエストが実際にコアを通っているかも確認します。強化モードだけを変更し、別経路の名前解決を残すと、ルールの判定と実際の通信が一致しないことがあります。イントラネットのドメインでは、適切なローカル名前解決経路を保ってください。

リモートサーバーで自動ルートを有効にする前に、管理用接続と別経路の復旧手段を必ず確保し、SSH、イントラネット、上流ノードの迂回範囲を明確にしてください。誤ったルート設定により、管理セッションやプロキシ自身の接続がトンネルへ送られることがあります。設定後は、ローカルプロキシ、出站先、リモート管理経路をそれぞれテストしてから自動起動を検討します。サービス停止後も通信できない場合は、残ったルート、デスクトッププロキシ、環境変数を確認し、実行ファイルを削除するだけでなく、導入前の状態に戻してください。

07 · 設定項目とよくあるトラブル

最小構成で設定項目を理解する

トラブル対処は、設定の読み込み、ローカル待ち受け、システムの通信制御、DNS、ルール、出站先の順に進めます。一度に変更する項目は一つにし、時刻と結果を記録してください。そうしないと、解決してもどの変更が効いたのか分かりません。以下のYAMLは項目とインデントの説明用で、直接接続のルールだけを含みます。プロキシノードはなく、サブスクリプションプロバイダーが提供する完全なルールも含まれていません。構成を理解するための独立したテスト設定として使用し、使用中のサブスクリプション設定を上書きしないでください。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAMLの階層にはスペースを使い、タブを混在させないでください。同じ階層のキーを揃え、リスト項目のハイフンも構文の一部として扱います。完全なプロキシ設定には参照可能な出站先またはグループが必要です。ルールで指定する名前も実在し、正確に一致していなければなりません。サブスクリプションを更新するとファイル全体が再生成されることがあり、ダウンロード済みファイルを直接編集すると変更が失われます。設定を継続的に変更する場合は、クライアントが明示的に対応する上書き、マージ、拡張の仕組みを使い、適用後の結果を確認してください。

基本項目の確認ポイント
項目役割よくある誤解
mixed-portローカルの混合プロキシポート待ち受けが成功してもシステムプロキシが有効とは限らない
allow-lanLANからのアクセス許可を制御する有効化後もバインドアドレスとファイアウォールを確認する
modeルール・グローバルなどの出站モードを選択するルールモードでも利用可能なグループの選択が必要
log-levelログの詳細レベルを設定するログレベルを上げても接続は修復されない

サブスクリプションの更新とリソース取得の失敗を分けて確認する

サブスクリプションの更新に失敗したら、URLが完全か、有効期限内か、サーバーから有効な設定が返されているか確認します。認証エラーはプロバイダー側で対処し、タイムアウトは取得経路とネットワークを調べてください。Webページが返る場合は、ログイン要求、リダイレクト、サーバーエラーが考えられます。GeoIP、GeoSite、ルールセットの更新は別種のリソース取得です。サブスクリプションを取得できても、これらのリソースがダウンロード済みとは限りません。ログから失敗したリソースを特定し、パス、権限、ネットワークを確認してください。すべてをノードの問題と決めつけないでください。

DNS・Fake-IP・ルールの優先順位

ドメインを解決できない場合は、システム、アプリ、コアのそれぞれがどの経路で名前解決しているかを切り分けます。Fake-IPはドメインとの対応付けに使う仮想アドレスを割り当てるため、この種のアドレスが表示されても実サーバーのアドレスが間違っているとは限りません。重要なのは、その後の接続がドメイン情報を復元できるコアを引き続き通ることです。トンネルを迂回するアプリが仮想アドレスを使うと、接続できない場合があります。通信制御の範囲とフィルターを確認し、仕組みの詳細はFake-IPとRedir-Hostの比較をご覧ください。

ルールは通常、上から順に照合され、最初に一致した結果が使われます。範囲の広いルールを早く配置しすぎると、後続の細かいルールが適用されません。末尾のMATCHは最終的な受け皿です。前のルールを理解しないまま変更しないでください。サイトが複数のドメインへ同時に接続することがあります。メインページだけ表示され、リソースの読み込みに失敗する場合は、個々の接続を確認しましょう。GeoIPはIPアドレス情報に依存し、一部のルールオプションは名前解決を行うかどうかにも影響します。ルールの記述だけで、すべての通信が地域に応じて正しく振り分けられると判断しないでください。

遅延・タイムアウト・復旧の手順

ノードの遅延テストに成功しても、実際の接続先を利用できるとは限りません。失敗しても、測定先に到達できないだけの場合があります。タイムアウト時は、ローカルポートへの接続失敗、リモートノードへの接続失敗、接続先への通信失敗を切り分けます。同じ時刻のログを確認し、別の利用可能な出站先でも比較してください。一時的にログの詳細度を上げて手掛かりを得たら、原因の特定後は通常のレベルに戻します。共有する前に、アドレス、アカウント、アクセス記録などの機密情報を削除してください。詳しくは実行ログのエラー解説をご覧ください。

すべてのアプリで失敗する場合は、待ち受けと通信制御から確認します。特定のアプリだけが失敗する場合は、独自プロキシ、ループバック、アプリのフィルター、キャッシュを調べてください。一つのサイトだけが失敗する場合は、ルールと出站先を確認します。復旧後は、実際のポート、現在の設定名、必要な権限を記録しておきましょう。サブスクリプションの認証情報は記録しないでください。その他の質問はよくある質問、用語は用語集をご覧ください。同じ名前の設定でも、OSによって動作が異なる場合があります。