インストール・設定・通信のプロキシ経由化

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

このページでは、OSごとの導入手順とトラブルの切り分け方を確認できます。初めて接続する場合は、まずクイックスタートガイドに沿って基本操作を完了し、その後、該当する章で権限、DNS、ルーティングの問題を確認してください。

クライアントによって画面上の項目名は異なります。実際の設定項目と実行ログを確認し、設定パラメーターは使用するコアの対応範囲に合わせてください。

共通の準備：クライアント、設定、通信の経由方法

クライアント画面とプロキシコアを区別する

Clashエコシステムのクライアントは通常、サブスクリプション管理、プロキシグループの選択、ログ表示、システムネットワーク設定を担い、コアは設定の読み込み、接続の確立、ルールの適用を担います。mihomoは単体で動作するプロキシコアであり、特定のGUIクライアントと同じものではありません。同種のコアを使うクライアントでも、設定の統合方法、権限サービス、更新方式は異なる場合があります。トラブルシューティングでは、クライアント名、コアの情報、OSのアーキテクチャ、通信の経由方式を記録してください。「Clashのエラー」と一括りにするだけでは、原因を特定できません。

デスクトップとモバイルでは、まずインストーラー一覧から環境に合うクライアントを選びましょう。Windows、macOS、Android、iOSではClash Plus、LinuxではClash Verge Revを第一候補として紹介しています。古い環境との互換性が必要な場合は、システム要件を確認して別のクライアントを選んでください。Clash for WindowsとClashX Metaは開発が終了したアーカイブ版のため、新しいシステムに継続導入する際の標準候補には適しません。名称の近さだけで判断せず、GUI、設定の互換性、システム権限への対応をあわせて確認してください。

サブスクリプションを用意し、設定形式を確認する

サブスクリプションURLは設定を取得するための入口であり、プロキシノードそのものではありません。追加前に、提供元が対象クライアントに対応しているか、またはClash／mihomoで読み込めるYAMLを出力できるか確認してください。ノードのリンクだけを含むテキストと、プロキシグループ、ルール、DNSを含む完全な設定ファイルは別物です。初回の追加後は、選択できる設定とプロキシグループが表示されることを確認しましょう。追加完了と表示されてもノードがない場合は、レスポンスの内容、サブスクリプションの状態、形式を確認してください。システムプロキシを何度も切り替えても解決しません。サブスクリプションの取得に失敗した場合、取得先に一時的にアクセスできない可能性もあります。

サブスクリプションURLにはアクセス認証情報が含まれることが多いため、公開の変換サイト、問い合わせ用スクリーンショット、公開リポジトリに掲載しないでください。変換が必要な場合は、データの処理環境を自分で管理できる方法を優先し、変換後もルールやプロキシグループが保持されるか確認してください。設定のバックアップも機密情報として扱い、安全な場所に保管しましょう。変更前に、現在使える設定をエクスポートし、元のプロキシポート、DNS設定、プロキシグループの選択を記録してください。復旧時には、接続成功のスクリーンショットよりこうした情報が役立ちます。

まずはシステムプロキシを使い、必要に応じてTUNを検討する

システムプロキシは、その設定に従うアプリの通信をローカルのプロキシポートへ送ります。通常、すべてのアプリの通信を経由するわけではなく、デバイス全体のトンネルと同じものでもありません。TUNは仮想ネットワークインターフェースとルーティングを使って通信を経由させますが、対象範囲はルートの除外設定、アプリの動作、権限にも左右されます。初めて導入する場合は、まず通常のプロキシ接続を確認してからTUNを有効にしてください。サブスクリプションが使えない状態で仮想アダプターやDNSも同時に変更すると、確認すべき要素が増え、原因を特定しにくくなります。

ルールモード、グローバルモード、DIRECTモードは、コアがどの出口を使うかを決めます。システムプロキシとTUNは、アプリの通信をどのようにコアへ送るかを決めるもので、異なる層の設定です。ルールモードでは設定内のルールを順に照合します。グローバルモードは、出口が使えるかを短時間比較する場合に便利です。DIRECTモードでも仮想インターフェースが必ず無効になるわけではありません。変更前後のモードを記録し、一度に一つだけ変更してテストしてください。会社のVPN、別のプロキシクライアント、ネットワークフィルターを使っている場合は、無効にしてよいか確認し、ルートやローカルの待ち受けポートが競合しないようにしましょう。

通信をプロキシ経由にする方式の違い
方式	適用される場所	確認するポイント
システムプロキシ	アプリが参照するシステムのプロキシ設定	アプリがプロキシ設定に従うか、ポートが一致しているか
明示的なプロキシ設定	個別のアプリやコマンドに指定するプロキシ設定	プロキシプロトコル、待ち受けアドレス、認証
TUN	仮想インターフェースとシステムルート	管理者権限、ルーティング、DNSの経路

再現可能なテスト環境を整える

開始前に、システム時刻、通常の直接接続、空きディスク容量を確認し、設定を保存してアプリを起動できる状態にしてください。アクセス可能なHTTPSページと、実際にプロキシが必要なサービスを一つずつ用意し、有効化前後の状態を記録します。ブラウザーでページを開けても、ターミナル、ゲーム、更新サービスの通信まで経由しているとは限りません。遅延テストに結果が出ても、アカウントへのログインや大容量ファイルの転送が正常とは限りません。テストでは、リクエストが接続一覧に表示されるか、どのルールに一致したか、どの出口を使ったかを確認し、必要に応じてログのエラーも調べてください。

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

インストーラーを選び、単一クライアントの環境を整える

まずシステム設定の「システム情報」でプロセッサーとシステムの種類を確認し、Windowsインストーラーから適切なものを選びます。第一候補はClash Plusです。必要に応じてClash Verge Rev、FlClash、Clash Nyanpasuも検討できます。Clash for Windowsはアーカイブ版としてのみ案内しています。インストーラーのビット数とブラウザーのビット数を混同しないでください。ARMデバイスでは、クライアントだけでなく、コアやサービスコンポーネントが現在の環境に対応しているか確認が必要です。アプリがエミュレーションで起動しても、仮想ネットワークアダプターが正常に動作するとは限りません。

インストール前に他のプロキシクライアントを終了してください。まずシステムプロキシを無効にし、次にタスクトレイのメニューから終了して、古いプロセスがポートを占有しないようにします。インストーラーの案内に従って保存先を選び、初回起動時はセキュリティソフトやシステムの許可要求を確認してください。インストールがブロックされた場合は、具体的なブロック理由とファイルの入手元を確認し、保護機能を一括で無効にしないでください。組織管理下のデバイスでは、ネットワークサービスや仮想アダプターのインストールが制限される場合があります。セキュリティポリシーを変更して回避せず、まず組織のルールを確認してください。

サブスクリプションを追加し、ローカルポートを確認する

設定管理画面でURLからのインポートを選び、サブスクリプションURLを入力して更新した後、その設定を明示的に選択します。クライアントによっては「サブスクリプションの追加」と「現在の設定にする」が別の操作になっています。追加だけでは、実行中のコアが新しいファイルを使うとは限りません。プロキシグループを開き、選択可能な出口が少なくとも一つあることと、設定読み込みログを確認してください。未対応の項目が表示された場合は、サブスクリプションが対象のコア形式か確認しましょう。構文エラーをファイアウォールによる接続ブロックと誤認しないでください。

システムプロキシを有効にする前に、クライアントが実際に待ち受けているHTTPポートまたは混合ポートを確認してください。以下の例では混合ポート 7890 を使います。クライアントがこのポートで待ち受けている場合に限り、そのまま実行してください。異なる場合は実際の値に置き換えます。PowerShellでは curl.exe を明示的に呼び出すことで、同名のコマンドエイリアスとの混同を防げます。明示的なプロキシテストで確認できるのは、そのコマンドのリクエスト経路だけです。他のプログラムのネットワーク設定は自動で変わりません。

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

明示的なプロキシ接続を確認してからシステムプロキシを有効にし、ブラウザーでテストページを開いて、接続一覧でプロセス、ルール、出口を確認します。Windowsのユーザープロキシ設定、WinHTTP設定、アプリ独自のプロキシ設定は、常に同期するとは限りません。ターミナルサービスやバックグラウンドタスクは、現在のユーザー設定を参照しない場合もあります。一つのプログラムをプロキシ経由にするためだけに、デバイス全体のサービスプロキシを変更しないでください。まず、そのプログラムに個別のプロキシ設定があるか、TUNによる通信の経由が本当に必要かを確認しましょう。

必要に応じてサービスモードとTUNを有効にする

TUNでは通常、クライアントが提供する権限サービスのインストールまたは起動が必要です。許可を求めるクライアントが、実際に使用しているものか確認してください。許可後にサービスの状態を確認してからTUNを有効にし、仮想インターフェースとルートが作成されたか確認します。正しいサービス設定の代わりに、GUI全体を常に管理者として実行する必要はありません。起動に失敗した場合は、ログの「権限不足」「インターフェース作成失敗」「ルート追加失敗」をそれぞれ切り分けてください。他のトンネルツールを無効にしてから、クライアントの修復機能でサービスを再インストールします。

Windowsファイアウォールで許可するネットワークプロファイルは、デバイスとLANの接続に影響します。ローカルでのみ使う場合は「ローカルネットワークへの接続を許可」を有効にする必要はなく、すべてのネットワークに対して受信範囲全体を開放するのも避けてください。他のデバイスから使う場合は、待ち受けアドレス、認証、ファイアウォールの接続元を個別に制限します。UWPアプリでローカルプロキシを使う際にループバック制限が関係する場合があります。対象アプリにこの制限があると確認できた場合のみ、クライアントのループバック解除機能を使い、すべてのアプリに権限を広げないようにしてください。

スリープ、終了、移行後に確認する

スリープからの復帰後やWi-Fi切り替え後は、クライアントのコアプロセスが動いているか、サブスクリプションが読み込まれているかを確認してから、通信の経由機能を再起動してください。クライアント終了後にインターネットへ接続できない場合は、システム設定の手動プロキシが、停止したローカルポートを指していないか確認します。残ったプロキシ設定を無効にしてから直接接続をテストしてください。これはサブスクリプションの無効化とは別の問題です。新しいクライアントへ移行する前に、古いクライアントのシステムプロキシとTUNを無効にして終了し、バックアップをインポートします。新しいクライアントだけで動作することを確認してから、古い設定を削除してください。Windowsのファイアウォール、ポート競合、権限に関する詳しい対処は、Windowsのインストールとトラブルシューティングをご覧ください。

macOS：アーキテクチャ、ネットワークサービス、補助コンポーネント

Apple SiliconとIntelを見分ける

「このMacについて」でチップ情報を確認し、対応するインストーラーを選びます。Apple Siliconは通常ARM64、Intelはx64に対応します。ユニバーサル版がある場合は、リリースノートに記載された対応範囲を確認してください。macOSダウンロードではClash Plusを第一候補として案内し、Clash Verge RevとFlClashも掲載しています。ClashX Metaは開発終了済みのアーカイブ版です。古いクライアントが起動するからといって、新しいOSのネットワーク拡張、セキュリティ機能、権限の手順に対応しているとは限りません。継続利用には、現在もメンテナンスされているものを優先してください。

ディスクイメージを開き、案内に従ってアプリを「アプリケーション」フォルダへ移動してから起動してください。マウントしたイメージから長期間直接実行するのは避けましょう。初回起動がシステムにブロックされた場合は、配布元とシステムの警告を確認し、システム設定から通常の手順で許可してください。セキュリティチェックを一括で解除したり、システム保護を無効にしたりするコマンドは実行しないでください。ネットワーク拡張、バックグラウンド補助コンポーネント、システム権限が求められた場合は、申請元の名前と用途を確認します。通常のサブスクリプション追加に、ネットワークと無関係な広範な権限は必要ありません。

設定を読み込み、使用中のネットワークサービスを確認する

クライアントの設定画面からサブスクリプションを追加し、更新後に現在の設定として選択して、プロキシグループから出口を選びます。まず明示的なプロキシリクエストを実行し、その後システムプロキシを有効にしてください。macOSのプロキシ設定はネットワークサービスごとに保存されます。Wi-Fi、有線アダプター、USBアダプターで、それぞれ異なる設定が残っている場合があります。ドッキングステーションの接続やネットワークの切り替え後は、直近で変更したWi-Fiの設定画面だけでなく、現在使用中のネットワークサービスを確認してください。サービス名は変更できるため、コマンド例にある名前が必ず存在するとは限りません。

次のコマンドでネットワークサービスの一覧を確認し、一般的なWi-FiサービスのHTTPプロキシとHTTPSプロキシを調べられます。一覧に Wi-Fi がない場合は、実際のサービス名に置き換えてください。表示されるのはシステムに記録されたプロキシ設定であり、ポートが待ち受け中か、対象アプリが設定に従うかを示すものではありません。プロキシアドレスはクライアントの表示と一致させてください。ローカルで使う場合は通常ループバックアドレスを指定します。サブスクリプションサーバーやノードサーバーのアドレスを誤って入力しないようにしましょう。

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

TUNの権限と複数のトンネル

クライアントのTUN機能は、補助サービス、仮想インターフェース、ネットワーク拡張に依存する場合があり、許可の手順も一律ではありません。使用中のクライアントの案内に従ってコンポーネントをインストールし、システム設定で必要な許可を行ってください。有効化後は、ログでインターフェースの準備完了とルートの作成を確認しましょう。メニューバーのアイコンだけでは判断できません。起動のたびに許可を求められる場合は、コンポーネントが想定した場所にインストールされているか、管理ポリシーでブロックされていないか、アプリを一時フォルダから実行していないかを確認してください。

会社のVPN、他のネットワークフィルター、既存のトンネルは、TUNと同時にデフォルトルートやDNSを変更する場合があります。一部のドメインにアクセスできないときは、許可される範囲で他のトンネルを一時停止し、クライアントを一つだけ使う環境でテストしてください。用途不明の仮想インターフェースやシステムのネットワーク設定ファイルを削除しないでください。組織管理ソフトが使用している可能性があります。複数のトンネルを併用する場合は、どの宛先ネットワークをどのトンネルが処理するか決め、社内ドメインの名前解決に必要なDNSへ引き続きアクセスできることを確認しましょう。プロキシ経由にした結果、社内サービスへ接続できなくなるのを防げます。

ターミナルのプロキシ、証明書、スリープ復帰

メニューバーでシステムプロキシが有効と表示されていても、ターミナルのプログラムが自動でその設定を使うとは限りません。コマンド固有のプロキシオプションを使うか、現在のターミナルセッションにプロキシ環境変数を設定してください。テスト後は速やかに解除し、クライアントを終了した後もコマンドが停止中のローカルポートへ接続し続ける状態を避けます。HTTP、HTTPS、SOCKSでは指定する値の意味が異なり、DNSをローカルとリモートのどちらで解決するかも異なる場合があります。切り分けではプロキシプロトコルを一つだけ明示し、環境変数、アプリ設定、TUNを同時に重ねて経路が分かりにくくならないようにしましょう。

HTTPS証明書のエラーを、証明書検証を無効にして解決しようとしないでください。まずシステム時刻、対象サイト、ネットワーク上の証明書差し替えポリシーを確認し、クライアント設定で意図せず通信の復号機能が有効になっていないか調べます。通常のプロキシ接続では、すべてのサイトにルート証明書をインストールする必要はありません。スリープ復帰後に一部のアドレスへ接続できない場合は、ネットワークを再接続し、プロキシ経由の機能を再起動してからDNSとルートを確認してください。クライアント終了後も問題が続く場合は、使用中のネットワークサービスにプロキシ設定が残っていないか確認します。更新前にサブスクリプションと上書き設定を保存し、古い補助コンポーネントを新しいインストール先へ手動でコピーしないでください。

Android：VPNの許可、バックグラウンド動作、アプリ別設定

デバイスのアーキテクチャに合うクライアントをインストールする

Androidダウンロードからクライアントを選びます。第一候補はClash Plusです。設定の互換性に応じて、Clash Meta for Android、FlClash、Surfboardも検討できます。比較的新しいデバイスの多くはARM64ですが、実際に対応するアプリのアーキテクチャを確認してください。チップが64ビットであることだけで、すべてのソフトウェア環境を判断できるわけではありません。インストール時に既存アプリとの競合が表示された場合は、パッケージ名、署名元、インストール経路を確認し、復元できるよう設定を保存してからアンインストールするか判断します。異なる署名のインストーラーをそのまま上書きできるとは限りません。

ブラウザーやファイルマネージャーからインストールする場合、Androidでその提供元からのアプリインストールを許可する必要があることがあります。使用する提供元に限って必要な許可を行い、完了後は制限を元に戻せます。インストールに失敗した場合は、OSのバージョン要件、アーキテクチャの不一致、ストレージ不足、署名の競合を切り分けてください。同じファイルを何度ダウンロードしても、これらの条件は変わりません。初回起動時は、設定一覧、プロキシグループ、ログ、接続スイッチの場所を確認します。自動起動、VPNの常時接続、アプリ別リストなど、すべての項目をすぐに有効にしないでください。

サブスクリプションを追加し、VPN接続を許可する

設定画面でサブスクリプションURLを追加し、更新後にその設定を選択して、有効なノードとプロキシグループがあることを確認します。Androidでのクリップボード、ファイル選択、QRコードからのインポート方法はクライアントごとに異なり、項目名も異なる場合があります。URLを読み込んでも設定名しか表示されない場合は、内容が実際にダウンロードされたか、構文エラーがないか確認してください。モバイル回線では取得に失敗し、Wi-Fiでは成功する場合、まずリクエスト経路と提供元の制限を確認します。先にアプリの振り分けリストを変更する必要はありません。

接続を開始すると、通常はシステムからVPN接続の許可を求められます。許可するとクライアントはAndroidのVPNサービスを使ってデバイスの通信を受け取りますが、デスクトップ版TUNのすべての設定項目と同じというわけではありません。システムにVPNアイコンが表示されることから分かるのは、サービスが確立したことだけです。実際の出口はクライアントのルールと接続履歴で確認してください。通常、同じユーザー環境で同時に有効にできるVPNサービスは一つです。別のツールもVPNインターフェースを使う場合、後から起動した方が先に起動した方を置き換えることがあるため、どちらを使うか先に決めてください。

アプリ別設定とバックグラウンド動作

アプリ別設定には通常、「選択したアプリのみプロキシを使う」と「選択したアプリを除外する」の二通りの意味があります。変更前に現在のモードを確認してください。ブラウザーをリストに追加しても、プロキシを回避するとは限りません。ブラウザーだけが通信の経由対象になる場合もあります。まずテスト用アプリを一つだけリストに追加し、保存後、クライアントの案内に従って再接続してから接続履歴を確認します。システムコンポーネント、仕事用プロファイル、複数ユーザー環境は同じアプリ一覧に表示されない場合があります。パッケージ名が似ているだけで、通信の経由範囲を判断しないでください。

画面ロック後に接続が切れる場合は、バッテリー最適化、バックグラウンド動作の制限、クライアントの通知権限を確認してください。端末によっては自動起動の管理が通常のバッテリー設定とは別になっています。実際の画面に合わせて設定しましょう。使用中のクライアントに必要なバックグラウンド権限だけを許可し、関連するすべてのアプリの制限を無条件に解除する必要はありません。通知が表示され続けていても、コアが動作しているとは限りません。ロック解除後に接続時間、ログ、リクエストがコアに届いているかを確認し、プロセスの終了とネットワーク切り替えによる再接続を区別してください。

プライベートDNS、テザリング、ネットワーク切り替え

AndroidのプライベートDNS、ブラウザーのセキュアDNS、クライアントのDNSが同時に動作していても、同じ経路で名前解決されるとは限りません。「接続済みなのにドメインを開けない」場合は、まず現在のプライベートDNS設定を記録します。システムの自動設定に一時的に切り替えて比較し、クライアントのDNSログも確認してください。特定の設定を無効にするだけで恒久的な解決とせず、どの名前解決経路にアクセスできないか、どのルールと一致しないかを特定しましょう。会社や学校が管理するDNSポリシーがある場合は、デバイス管理の指示に従ってください。

スマートフォンのテザリングに接続した他のデバイスが、そのままスマートフォンのVPNを経由するとは限りません。テザリング通信を転送できるかは、OSとクライアントの機能によります。スマートフォン自身がプロキシ経由で通信できるだけでは判断できません。Wi-Fiからモバイル回線に切り替えると、既存の接続が切れ、新しいDNSやルートに変わる場合があります。古いページを更新するだけでなく、新しいリクエストで確認してください。「常時接続VPN」やVPN以外の通信をブロックする設定が有効な場合、クライアントが起動できないとデバイス全体の通信がOSに遮断されることがあります。無効化やアンインストールの前にシステム設定を確認し、復旧手段を確保しましょう。

iOS：App Storeからのインストール、設定の追加、トンネルの確認

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

iPhoneとiPadにはClash Plusを第一候補として案内しています。App StoreのClash Plusページからインストールできます。製品の公式サイトは clashplus.io です。このサイトのiOSインストール案内からストアへ移動することもできます。インストール前に、ストアのシステム要件とデバイスの対応状況を確認してください。機能名や設定項目は実際のアプリ画面に従ってください。デスクトップ版クライアントのメニュー画面をiOSの手順として使わないでください。プラットフォームによって権限やネットワークインターフェースが異なります。

初回起動後は、設定管理、接続状態、プロキシポリシー、ログの入口を確認してください。ローカルネットワークへのアクセスや通知を許可するか尋ねられた場合は、実際の用途に応じて判断します。これらの許可とVPN構成の追加は別のものです。サブスクリプションを追加しても、自動的に通信が経由されるとは限りません。VPN構成を許可しても、サブスクリプションが利用可能になるわけではありません。「アプリのインストール、設定の読み込み、接続の許可、リクエストの確認」の順に進めることで、画面、設定、システム権限の問題を切り分けやすくなります。

クライアントに対応したサブスクリプション形式を使う

サブスクリプションURLをコピーし、アプリの設定追加またはインポート画面に貼り付けて更新した後、現在の設定として選択します。提供元が現在のクライアントのインポート形式に対応しているか確認してください。「Clash」と名の付くサブスクリプションがすべて同じ機能を含むとは限りません。ファイルから読み込む場合は、システムのファイル選択画面から読み取れるファイルを開き、Webページやエラーレスポンスではなく実際の設定テキストをインポートしたことを確認します。共有メニューにアプリ名が表示されても、受け取り機能があることを示すだけで、内容の互換性までは保証されません。

インポート後は、プロキシグループに選択可能な出口があるか、設定が有効かを確認してから初回接続を行います。サブスクリプションの更新時に認証エラーが出た場合は、URLが完全か、アカウントが有効か、提供元がリクエストを制限していないか確認してください。最初からすべてのローカル設定を削除して再インストールする必要はありません。手動で変更したルールは更新時に上書きされる場合があります。クライアントが提供する永続的な拡張方法を優先してください。アプリがmihomoの特定の項目に対応していない場合は、設定の出力方法を変更するか、対応する機能を備えたクライアントを選びます。デスクトップ用YAMLを無理にコピーしないでください。

VPN構成を許可し、実際の出口を確認する

接続を開始すると、iOSからVPN構成の追加を求められ、デバイス認証が必要になる場合があります。許可したらアプリに戻って接続状態を確認し、必要に応じてシステム設定でも現在のVPNを確認してください。このトンネルは、アプリがシステムのネットワーク拡張機能と連携して確立するものです。デスクトップの「システムプロキシ」スイッチをスマートフォンに移したものではありません。画面に「接続済み」と表示されるのはトンネルの状態を示すだけです。ルールが想定どおり適用されているか、対象サービスが現在の出口を受け入れるかは、実際のアクセスとクライアントの接続履歴で確認してください。

テストでは、まずアクセス可能なHTTPSページを開き、次に対象アプリを確認して、どちらもクライアントの接続一覧に表示されるか記録します。ページは開けても特定のアプリだけ異常がある場合は、アプリ内のキャッシュ、アカウント制限、UDPの必要性、独自の名前解決動作を切り分けてください。VPNアイコンだけを見て、すべての接続が選択したノードを経由すると判断しないでください。LAN、特定のドメイン、その他の宛先はルールにより直接接続される場合があります。プロキシポリシーを切り替えた後は、新しい接続でテストしてください。既存の長時間接続は、以前の経路を使い続ける場合があります。

必要に応じた接続、LAN、システムサービスの範囲

オンデマンド接続機能がある場合は、まず手動接続の安定性を確認してからトリガー条件を追加してください。複数のVPNアプリを頻繁に切り替えると、現在有効な構成が変わることがあります。トラブルシューティング中は、接続元を一つに絞りましょう。Wi-Fi設定画面の手動HTTPプロキシは、そのネットワークと設定に従う通信だけに適用され、アプリのトンネルとは別の層です。両方を有効にすると二重プロキシになったり、使用できなくなったLANアドレスを参照したりする場合があります。それぞれの設定を記録して個別にテストし、混同しないようにしてください。

プリンター、家庭内ストレージ、その他のLAN機器に接続できない場合は、クライアントにLAN通信の除外設定があるか、システムのローカルネットワーク権限で対象アプリが許可されているか確認します。iCloudプライベートリレーなどのシステム機能が、一部のリクエスト経路を変える場合もあります。条件が合えば一時的に無効にして比較できますが、元の設定を記録して後で戻してください。会社の管理デバイスやアプリ単位のVPNでは、管理者にポリシーの適用範囲を確認します。通常のプロキシ接続を復元するために、管理対象の構成プロファイルを直接削除しないでください。

ネットワークの切り替え、OSの更新、デバイスの再起動後は、アプリを手動で接続し直す必要があるか、サブスクリプションを更新できるか、オンデマンド接続の条件が現在のネットワークに合うかを再確認します。アンインストール前に接続を切断し、関連するオンデマンド設定を整理して、サブスクリプションの配布元と必要なルールをバックアップしてください。アプリのサンドボックス内のファイルは、削除時に失われる場合があります。VPNを無効にしてもネットワークに問題が残る場合は、新しいVPN構成を何度も作り直さず、Wi-Fiの手動プロキシ、DNS、デバイス管理ポリシーを確認してください。証明書エラーは時刻、サイト、ネットワークの証明書チェーンから調べ、検証を無効にして隠さないでください。

Linux：GUIクライアント、コアの実行、権限の範囲

ディストリビューションとアーキテクチャに合わせて導入方法を選ぶ

LinuxのGUIデスクトップにはClash Verge Revを第一候補として案内しています。FlClashも利用できます。パッケージ形式はLinuxダウンロードで確認してください。まず uname -m でアーキテクチャを調べ、次にディストリビューションのパッケージ管理方式を確認します。AMD64とARM64は互換ではなく、DEBとRPMもそのまま相互に使えるファイルではありません。デスクトップ用パッケージが現在のシステムで動作するかは、グラフィカルセッションやランタイムライブラリにも左右されます。インストーラーで依存関係の不足が報告された場合は、ディストリビューションの信頼できるソフトウェアソースから依存関係を解決してください。提供元が不明な共有ライブラリを個別にダウンロードして補わないでください。

インストール後は、通常のデスクトップユーザーで起動します。サブスクリプションを追加して現在の設定に選び、プロキシグループとコアのログを確認してください。GUIアプリをインストールする権限と、コアの実行に必要なネットワーク権限は別です。デスクトップアプリ全体をrootで常時実行しないでください。デスクトップ環境のシステムプロキシは、通常、該当する設定を参照するアプリにのみ適用されます。ターミナル、コンテナ、パッケージ管理ツール、システムサービスには別の設定が必要な場合があります。明示的なプロキシテストは成功してもソフトウェア更新サービスが接続できない場合は、そのサービスのプロキシ設定を確認してください。すぐにコアの故障と判断しないでください。

mihomoを単独実行するための基本チェック

サーバーやルーターで使う場合は、コアのダウンロードから対応するビルドを選びます。展開後、実際のファイル名に合わせて名前を変更し、実行権限を付けてから、ヘルプコマンドで実行ファイルとプラットフォームの互換性を確認してください。設定を専用ディレクトリに置き、テスト用パラメーターで読み込みを確認します。テスト中はルールセットなどのリソースを取得する場合があります。ネットワークエラーと構文エラーは分けて確認してください。以下の例では、バイナリを現在のディレクトリの mihomo、設定を config.yaml として保存済みとします。このコマンドはシステムサービスを自動でインストールしません。

uname -m
chmod u+x ./mihomo
./mihomo -h
./mihomo -t -f ./config.yaml
./mihomo -f ./config.yaml

以下はローカルで直接接続するプロキシだけを提供する最小構成です。待ち受けポートとアプリのプロキシ設定を確認できますが、リモートプロキシの出口を検証する用途には使えません。まずこの設定でローカルの入口を把握し、その後、信頼できるサブスクリプションを読み込みます。正常に動作しているサブスクリプションの末尾に、同じトップレベルキーをそのまま貼り付けないでください。同じキーを重複して定義すると、パーサーに拒否されたり値が上書きされたりして、記述した順序と実際の結果が一致しない場合があります。

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

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

LinuxでTUNを使うには、システムが対応デバイスと必要なネットワーク権限を提供している必要があります。制限のあるコンテナ、共有ホスト、最小構成のシステムでは /dev/net/tun が使えない場合があり、YAMLを変更するだけではホスト環境の不足を補えません。ログに権限不足が表示された場合は、まず実行ユーザー、サービスの制限、デバイスが見えるかを確認します。すべてのプログラムに権限を広げないでください。必要なコアプロセスだけに許可を与え、アップグレード後にバイナリの置き換えで既存の権限設定に影響がないか確認しましょう。

自動ルーティングを有効にする前に、デフォルトルート、リモート管理の接続先、既存のファイアウォールルールを記録してください。リモートサーバーでルートの経由を誤るとSSH接続が切れる可能性があるため、操作前にコンソールなど別の復旧経路を用意します。DNSはNetworkManager、systemd-resolvedなどのサービスが管理している場合があります。クライアントのDNSがどのポートで待ち受け、システムのリクエストがどのように届くのか明確にしてください。コアにDNSを設定しただけでシステムの名前解決経路が変わらなければ、すべてのアプリがそのDNSを使うわけではありません。管理対象の名前解決ファイルを上書きしても、設定が長期間維持されるとは限りません。

サービス化、コンテナ、LANとの境界

フォアグラウンド実行での確認後、ディストリビューションの仕組みに合わせてバックグラウンドサービスを設定します。実行ファイルの絶対パス、設定ファイルのパス、作業ディレクトリ、実行ユーザーを明確にしてください。サービスの作業ディレクトリは対話型ターミナルと異なることが多く、ルールセットやキャッシュファイルにも適切な書き込み権限が必要です。起動に失敗した場合は、システム全体を何度も再起動せず、サービスログを確認します。サービス停止後は、自動追加されたルートやDNS設定が元に戻ったか確認してください。特に、このマシン自身の名前解決とリモート管理が引き続き可能かを検証しましょう。

コンテナ内のループバックアドレスはコンテナ自身を指し、ホストではありません。ホストのプロキシに 127.0.0.1 を設定しても、ブリッジ接続のコンテナからアクセスできないのが一般的です。プロキシを共有する場合は、ネットワークの入口、バインドするアドレス、ファイアウォールの範囲を明確に設計し、認証も考慮してください。すべてのインターフェースで待ち受けるように変更して、インターネットに公開しないでください。ルーターへの導入には、ゲートウェイ、DNSの配布、透過プロキシの経路も関係するため、デスクトップ設定をそのまま流用できません。ネットワーク構成と適用範囲についてはOpenWrtサイドルーター導入ガイドをご覧ください。通常のデスクトップ利用でプロキシを使うために、サイドルーターを導入する必要はありません。

設定のよくある問題：ルール、DNS、段階別トラブルシューティング

原因を層ごとに切り分けてから変更する

トラブルシューティングは「設定の読み込み、コアの待ち受け、通信の経由、ルールの照合、出口への接続、接続先の応答」の順に進めます。設定の解析に失敗している場合、システムプロキシやTUNを切り替えてもYAMLは修復できません。コアが待ち受けていなければ、ブラウザーのプロキシ設定が正しくても接続できません。リクエストがコアに届いていない場合、ノードを切り替えても効果はありません。最初に失敗した層を見つけ、ログの具体的なエラー、発生時刻、操作手順を記録してから、変更する要素を一つに絞ります。他の人に相談する際は、サブスクリプションの認証情報、ノードの認証情報、アクセス履歴から機密情報を隠してください。

追加完了と表示されても使えない場合は、どの設定が有効になっているか、起動時にクライアントが上書き設定を統合しているかを確認します。YAMLのインデントにはスペースを使い、タブは使わないでください。リストの階層、コロンの後のスペース、文字列の引用符は解析結果に影響します。ルールが参照するプロキシグループ名が存在し、完全に一致することも確認してください。サブスクリプション提供元がグループ名を変更した場合、以前のカスタムルールが削除済みのグループを参照していることがあります。この問題はルールの参照先を修正するもので、システムDNSを変更するものではありません。

ルールは記述順に照合し、最後にフォールバックを置く

mihomoの通常のルールは上から順に確認され、最初に一致したものが適用されます。ドメインルールはサービスごとの振り分けに、IPネットワークルールは明確なネットワーク範囲の指定に適しています。MATCH は、それまでのルールに一致しなかった接続を処理します。以下の例は組み込みのDIRECTとREJECTだけを使い、ルールの順序を説明するもので、完全なサブスクリプションではありません。no-resolve は、このIPルールのためにドメインの名前解決を自発的に行わない設定であり、すべてのDNSを無効にする意味ではありません。既存のサブスクリプションでは、クライアントの拡張機能からルールを追加し、サブスクリプションのフォールバックルールより前に配置されたことを確認してください。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - DOMAIN-SUFFIX,invalid,REJECT
  - MATCH,DIRECT

変更後は新しい接続でテストし、ルールファイルに対象ドメインがあるかだけでなく、実際にどのルールが適用されたか確認します。アプリは複数のドメインに接続したり、キャッシュされたアドレスを使ったり、既存の接続を再利用したりするため、ページを一度開いただけでも異なるポリシーの記録が複数表示される場合があります。プロキシを使う場合は、ルールの参照先を設定内に実在するプロキシグループ名にしてください。任意のグループ名を貼り付けるだけでは動作しません。ルールの種類、優先順位、上書き関係についてはカスタムルールの構文と優先順位をご覧ください。

DNSはリクエストの経路とあわせて確認する

DNSはドメイン名をIPアドレスに変換し、ルールとルーティングはその後の接続経路を決めます。Fake-IPモードは合成アドレスでドメインとの対応を保持し、Redir-Hostは通常、実際の名前解決結果をアプリに返します。両者を単純に速度で比較することはできません。Fake-IPを有効にして一部のLANサービスやデバイスで問題が発生した場合は、例外ドメインと実際の通信経路を確認してから対処してください。例外の範囲をむやみに広げないでください。DNSリークの判定では、実際のリクエストがどこへ送られるかを確認します。検査ページに表示されたDNSサービス名だけで結論を出さないでください。

ブラウザー内蔵の暗号化DNS、AndroidのプライベートDNS、システムのリゾルバー、コアのリゾルバーが並行して動作する場合があります。トラブルシューティングでは、まず経路を一つに絞ってテストし、その後ほかの設定を一つずつ戻してください。暗号化DNSの接続先自体にも、到達可能な接続経路が必要です。誤ったプロキシ依存関係があると、ノードの接続に必要なドメイン名を解決するDNSリクエストが、まだ確立していないノードに送られる循環が起きる場合があります。ルールがGeoIPやGeoSiteに依存する場合は、データベースのダウンロードに成功したか、項目が現在のコアに対応しているかも確認してください。詳しくはGeoIP・GeoSiteの更新方法をご覧ください。

よくある症状と優先して確認する項目
症状	最初に確認	次に検証する項目
設定を読み込めず起動しない	解析ログ、インデント、グループ名、対応する項目	最小構成を読み込めるか
明示的なプロキシは使えるが、アプリが接続できない	アプリのプロキシ設定、通信の経由範囲	対象リクエストが接続履歴に表示されるか
TUNを有効にするとドメインに接続できない	DNSの経路、トンネルの競合、ルーティング	TUNを無効にした場合との比較
終了後もインターネットに接続できない	残ったシステムプロキシ、VPNの通信ブロック設定	直接接続とシステムDNSが復旧するか

遅延、帯域幅、接続の安定性を分けて確認する

ノードの遅延テストで分かるのは、特定の条件下で指定したテスト先にリクエストしたときの所要時間であり、実際のダウンロード帯域ではありません。遅延が低いノードでも、混雑、出口の制限、接続先サービスのポリシーによって性能が低下する場合があります。テスト先、時間帯、ネットワークの種類、出口を記録し、同じ条件で比較してください。複数の設定を続けて切り替えた後、結論だけを残すのは避けましょう。ハンドシェイクとURL Testについては遅延テストと実際の通信速度の違いをご覧ください。個別の問題はよくある質問もご確認ください。

復旧は導入時と逆の順序で行います。まずTUNまたはアプリのトンネルを無効にし、次にシステムプロキシをオフにして、最後にコアを終了します。システムDNSとデフォルトルートが想定どおりに戻ったことを確認してください。最後に正常動作した設定と変更内容を保存しておけば、次に問題が起きたときの基準になります。特定のサービスだけに問題があり、ほかのプロキシ通信と直接接続が正常な場合は、クライアントを再インストールするのではなく、対象サービスのアカウント、証明書、地域、プロトコル要件を確認してください。初回導入の手順はクイックスタートガイドに戻って順に確認できます。