インストールガイド · プラットフォーム別

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

インストールから通信の振り分けまで、設定・権限・ネットワークの状態を順に確認します。

初めて使う場合は、まずクイックスタートガイドに沿って接続を一度確立してください。このページでは各プラットフォームの手順をまとめています。準備を確認してから、お使いのデバイスの章へ進んでください。サブスクリプション、DNS、接続に問題がある場合は、最後の章で段階的に原因を切り分けます。クライアントによってメニュー名は異なるため、実際の画面とプロジェクトの説明を確認してください。

事前準備：プラットフォーム・設定・通信の振り分け方法を確認

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

クライアントは設定一覧、プロキシのオン・オフ、ログ表示などを提供します。コアは設定の解析、ルールの判定、接続の確立を担当します。サブスクリプションは、サービス提供元から設定やノード情報を受け取るためのものです。クライアントをインストールしただけでは、利用可能なノードは取得できません。使用前に、利用権限のあるサブスクリプションURLまたはローカル設定ファイルを用意し、選んだクライアントに対応しているか確認してください。アカウントのログインページや決済ページ、ブラウザーのアドレス欄に表示された管理画面のURLを、サブスクリプションリンクとして使わないでください。

mihomoはプロキシコアであり、特定のGUIクライアントを指すものではありません。mihomoを使うクライアントでも、設定のマージ方法、権限管理、更新方法はそれぞれ異なります。このページではWindows、macOS、Android、iOS向けにClash Plusを第一候補として紹介し、LinuxデスクトップではClash Verge Revをおすすめします。まずプラットフォームに合ったツールを選び、次に設定形式を確認してください。製品名が似ているという理由だけで、異なる形式を混在させないようにしましょう。

OSとプロセッサのアーキテクチャを確認

Windowsでは「設定 → システム → バージョン情報」でシステムの種類を確認します。Macでは「このMacについて」でチップまたはプロセッサを確認してください。Androidでは端末情報を確認し、ダウンロードページのアーキテクチャ表記に合ったパッケージを選びます。Linuxではuname -mを実行してアーキテクチャを確認します。一般にx86_64はAMD64、aarch64はARM64に対応します。アーキテクチャが合わないとアプリが起動しないことがあります。何度再インストールしても設定では解決できません。

インストールパッケージの最低システム要件、空き容量、アカウント権限も確認してください。GUIクライアント、補助サービス、コアにはそれぞれ対応環境が異なる場合があります。一般的な情報より、ダウンロードページやプロジェクトの説明を優先してください。組織管理下のデバイスでは、プロキシ設定の変更、サービスのインストール、仮想ネットワークアダプターの作成が許可されているか事前に確認しましょう。管理ポリシーを回避するためにシステムプロファイルを削除したり、出所不明のセキュリティ機能を無効にしたりしないでください。

サブスクリプションとローカルYAMLの違い

URLサブスクリプションは、クライアントが定期的にアクセスするURLです。YAMLはインデントで項目の階層を表す、一般的な構造化設定形式です。Base64はテキストのエンコード方式であり、それ自体が完全なClash設定を意味するわけではありません。URLによっては完全なYAMLを返し、別のURLではノード情報だけを返します。インポートに失敗したら、まず形式を確認してください。すぐにコアを変更する必要はありません。詳しくはサブスクリプションリンクとインポート形式の解説をご覧ください。

サブスクリプションURLにはアクセス用の認証情報が含まれることが多いため、パスワードと同様に管理してください。コピーする際はクエリパラメーターを含め、URL全体を保持します。引用符、空白、改行を追加しないでください。問い合わせる場合は、ドメイン以外の機密性の高いパスやパラメーターを伏せ、スクリーンショットにQRコード、ノードのパスワード、コントロール用インターフェースの情報が写っていないかも確認しましょう。見知らぬ変換サイトに実際のURLを貼り付けないでください。変換が必要な場合は、サーバー側にどの設定情報が渡るのかを先に確認してください。

まずシステムプロキシを試し、必要に応じてTUNを検討

システムプロキシを使うと、OSのプロキシ設定に従うアプリがローカルの待ち受けポートに通信を転送します。まずブラウザーで接続を確認するのに適しています。TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信をより広い範囲で取り込めます。ただし、バイパスルール、対象アプリ、ファイアウォールの影響を受けるため、すべての通信が自動的にプロキシされるわけではありません。追加の権限が必要になることが多く、ほかのVPNや仮想ネットワークアダプターとルーティングが競合しやすくなります。

方式	まず試す対象	確認ポイント
システムプロキシ	ブラウザーやOSの設定に従うアプリ	待ち受けアドレス、ポート、システム設定
TUN	ネットワーク層での通信制御が必要なアプリ	サービス権限、ルート、DNS
アプリごとの設定	ターミナルやプロキシ設定に対応したソフトウェア	プロキシプロトコルとアプリ側の設定

準備段階ではほかのプロキシツールを終了し、元のプロキシ設定とDNS設定を記録してから、最小限の接続を確立してください。ルール、ノード、DNS、通信の振り分け方法を一度に変更すると、問題の原因を特定しにくくなります。以下の例はローカルの待ち受け設定の範囲を示すものです。利用可能な既存設定に組み込んでください。リモートノードは含まれておらず、この例だけでプロキシ接続を利用することはできません。

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

Windows：クライアントのインストールとローカルプロキシの確認

ダウンロード後、初回起動する

Windowsのインストーラー一覧を開き、まずClash Plusを選んでください。ほかの候補はClash Verge Rev、FlClash、Clash Nyanpasu、そして開発が終了したClash for Windowsです。新しい環境で、アーカイブ済みのクライアントから使い始めることはおすすめしません。古い画面やコアの機能が、現在の設定項目と一致しない場合があります。移行する場合は、既存の設定をコピーしてから進め、現在動作している環境を先に削除しないでください。

システムの種類に合ったインストーラーを選び、ローカルディスクにインストールしてから、スタートメニューで起動します。セキュリティ警告が表示されたら、ダウンロード元、発行元情報、パッケージの入手先を確認してください。セキュリティ機能全体をそのまま無効にしないでください。初回起動は通常の権限で行います。補助サービスのインストールや仮想ネットワークアダプターの設定などで明確に必要な場合に限り、システムの認証画面から権限を昇格してください。会社支給のデバイスでブロックされた場合は、まず管理者に相談してください。

サブスクリプションを追加し、使用中の設定として選択

クライアントの「設定」または「サブスクリプション」画面を開き、URLからインポートを選んで、URL全体を貼り付けて保存します。インポート成功後、設定一覧に項目が追加されたことを確認し、現在の設定として選択してください。一覧にサブスクリプションがあるだけでは、コアがその設定を使っているとは限りません。複数の設定を保存できるクライアントでも、起動時に使われるのは選択中の設定だけです。続いてプロキシグループを開き、設定で定義されたグループ名が表示されていることを確認します。

ローカルのYAMLを読み込む場合は、ファイルインポート機能を使い、元のファイルをバックアップとして残してください。テキストエディターが付けた二重拡張子に変更したり、スペースの代わりにタブでインデントしたりしないでください。サブスクリプションを更新すると、手動で変更した内容が上書きされることがあります。長期間使うローカルルールは、クライアントがサポートするオーバーライドまたはマージ領域に保存してください。更新のたびにエラーログを確認し、旧設定に戻すか判断しましょう。

システムプロキシを有効にして段階的に確認

コアが起動していることを確認してから、クライアントのシステムプロキシを有効にします。Windowsの「設定 → ネットワークとインターネット → プロキシ」を開き、クライアントが設定したローカルアドレスとポートを確認してください。ポートはクライアントに現在表示されている値を使います。説明で7890が使われていても、そのまま流用しないでください。ポートがほかのプログラムに使用されている場合は、競合するプログラムを終了するか待ち受けポートを変更し、手動でプロキシを設定したアプリにも変更を反映します。

まず、普段直接アクセスできるサイトを開き、次にプロキシが必要なサイトを開いて、クライアントの接続ログを確認します。前者で基本的なネットワーク接続を、後者でルールとプロキシの出口を確認できます。ブラウザーに接続できても、PowerShell、Microsoft Store、その他のアプリが通信を振り分けられているとは限りません。ターミナルでは、次の単発リクエストでローカルHTTPプロキシをテストできます。ポートは現在の設定に合わせてください。このテストでは環境変数を変更しません。

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

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

システムプロキシに従わないアプリがある場合に、TUNを検討してください。クライアントの案内に従って補助サービスをインストールまたは起動し、システムの許可を得てから仮想ネットワークアダプターによる通信の取り込みを有効にします。テスト中はほかのVPNを終了し、ルートが重複して設定されていないか確認してください。リモートワーク用のトンネル、仮想マシンのネットワークアダプター、ゲーム用の通信最適化ツールもルーティングに影響します。有効にした後、ネットワーク全体に問題が出たら、DNS設定を重ねて変更するのではなく、まずTUNを無効にして、動作を確認済みのシステムプロキシに戻してください。

一部のUWPアプリでは、ループバック分離のためローカルプロキシに接続できないことがあります。特定のアプリだけで問題が起きるか確認し、クライアントにループバックの管理機能があれば、対象アプリに限って例外を許可してください。すべてのアプリの分離を一括で解除しないでください。ファイアウォールがネットワークアクセスを確認してきた場合は、ローカル接続とLANへの共有を区別します。自分のPCだけで使う場合、通常は同じWi-Fi上のデバイスにプロキシポートを公開する必要はありません。

スリープ復帰、終了、クライアント移行への対応

スリープからの復帰後やネットワーク切り替え後に接続できなくなったら、まずコアが動作しているか確認してから、システムプロキシをオフにして再度オンにします。管理ポリシーや別のソフトウェアがプロキシ設定を書き換え、スイッチはオンでもシステムのアドレスが変わっている場合があります。ログに待ち受けの失敗が記録されている場合はポート競合を確認してください。接続自体は確立しているのに接続先がタイムアウトする場合は、ノードとルールを確認します。どの問題もWindowsの権限が原因だと決めつけないでください。

通常終了する前に、システムプロキシとTUNを無効にします。アプリが異常終了してブラウザーがインターネットに接続できなくなった場合は、システムプロキシの設定画面でクライアントが残した手動プロキシの値を削除してから、直接接続をテストしてください。新しいクライアントに移行する場合は、古いクライアントの通信制御と自動起動を先に無効にし、必要な設定だけをインポートします。動作確認後に旧プログラムをアンインストールしてください。ログイン時に2つのクライアントが同じポートやシステムプロキシ設定を奪い合わないようにしましょう。

macOS：Applicationsに移動して通信の振り分けを設定

チップに合ったアプリを選んでインストール

「Appleメニュー → このMacについて」を開きます。Appleシリコンと表示される場合はApple SiliconまたはARM64版、Intelプロセッサと表示される場合はIntelまたはx64版を選んでください。macOSのダウンロード一覧から、まずClash Plusをインストールします。Clash Verge Rev、FlClashも選択できます。ClashX Metaは開発が終了しているため、アーカイブ用途として扱い、使用前に設定の互換性と対応OSを確認してください。

DMGディスクイメージを開き、アプリのアイコンをApplicationsフォルダにドラッグして、コピーが完了するまで待ちます。その後、「アプリケーション」フォルダから起動してください。ディスクイメージから直接起動し続けると、更新、権限の記録、アプリのパス認識に問題が起きることがあります。コピー後はディスクイメージを取り出してかまいません。既存のアプリを置き換える場合は、先に古いプロセスを終了して設定をバックアップし、システムの案内に従って置き換えてください。

初回起動時にセキュリティ警告が表示されたら、まずダウンロード元と警告内容を確認してください。アプリが信頼できると確認できた場合に限り、システム設定に表示される「このまま開く」などの許可項目を使います。隔離属性を削除したり、システム保護を無効にしたりするターミナルコマンドをそのまま実行しないでください。補助サービスの許可とアプリの初回起動は別の操作です。後からサービスをインストールする際に管理者認証が表示された場合は、その都度、許可する対象を確認してください。

サブスクリプションを追加してプロキシグループを選択

設定画面でURLまたはローカルファイルからインポートし、保存後にその項目を現在の設定として選択します。コアの読み込みが成功したら、プロキシグループを開いてノードを選んでください。ルールモードでは設定内の条件に従って、直接接続するかプロキシを使うかが決まります。グローバルモードは通常、バイパス対象以外の通信をグローバルポリシーグループに送りますが、システム側の通信制御を代替するものではありません。グローバルモードに切り替えても接続記録が表示されない場合は、まずアプリの通信がクライアントに届いているか確認してください。

ノードのテスト結果だけで判断しないでください。テスト先やプロトコルは実際のアプリの通信と異なる場合があり、単一のテストに成功してもすべてのサイトに接続できるとは限りません。利用できるノードを一つ固定し、同じ接続先で繰り返しテストしてから自動選択に戻します。サブスクリプションの更新に失敗しても古いノードが使える場合は、現在の設定を残してサブスクリプションの取得経路を個別に調べてください。すべてのノードやポリシーの選択をすぐに消去する必要はありません。

システムプロキシとネットワークサービスを確認

クライアントのシステムプロキシを有効にした後、「システム設定 → ネットワーク」で使用中のネットワークサービスを選び、詳細情報のプロキシ設定を確認します。macOSのバージョンによってメニュー名は多少異なるため、実際に接続しているWi-Fi、Ethernet、その他のサービスを確認してください。ネットワークインターフェースを切り替えた後にクライアントの設定が反映されない場合は、メニューバーのアイコンだけで判断せず、システムプロキシを一度切り替えてから現在のインターフェースの設定を確認します。

ブラウザーはシステムプロキシの確認に使えますが、ターミナルのツールではプロキシを個別に指定する必要がある場合があります。次のコマンドは今回のリクエストだけに適用され、待ち受けポートの動作確認に使えます。接続が拒否された場合はコアとポートを確認してください。ローカルプロキシには接続できてもリモート側がタイムアウトする場合は、プロキシグループ、ノード、接続先のルールを確認します。SOCKSを使う場合は、ドメイン名をローカルで解決するか、プロキシ側で解決するかも確認してください。

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

補助サービスをインストールしてTUNを有効化

TUNでは通常、仮想インターフェース、ルート、DNSの設定が必要であり、クライアント側にも対応機能が求められます。画面の案内に従って補助サービスをインストールし、システムの許可内容を確認してからTUNを有効にします。クライアントによっては通常のシステムプロキシにも補助コンポーネントが必要です。「サービスをインストールした」ことと「TUNを有効にした」ことは同じではありません。完了後は、許可画面を閉じただけで終わりにせず、現在の状態とログを確認して、サービスが利用可能で設定が読み込まれていることを確認してください。

有効化後にローカルデバイス、社内ネットワーク、リモート接続にアクセスできなくなった場合は、まずTUNを無効にして接続を復旧し、プライベートネットワークのバイパス設定とルーティングを確認します。システムのルートテーブルを直接削除したり、遠隔管理中に初めて全通信を取り込む設定を試したりしないでください。方式ごとの適用範囲については、macOSのシステムプロキシとTUNの仕組みを比較を参照し、長期的に有効にするか判断してください。

アップデート、移行、設定の残存に対処

アプリの更新後に権限の問題が起きた場合は、アプリを完全に終了してから起動し、クライアントの案内に従って補助サービスの更新が必要か確認してください。Appleシリコンのデバイスで旧アーキテクチャのプログラムが動作しても、そのインストーラーを使い続ける必要があるとは限りません。ネイティブ版を使えば互換レイヤーへの依存を減らせますが、利用できる機能はクライアントの実装によります。移行前にサブスクリプションの入手元、ローカルのオーバーライド、必要な設定を個別にバックアップしてください。用途が分からないキャッシュフォルダを丸ごとコピーしないでください。

アンインストールする前にシステムプロキシとTUNを無効にし、クライアントが提供するサービスの削除機能を使います。アプリをゴミ箱に移動するだけでは、システムプロキシの設定が戻らず、独立したサービスも削除されないことがあります。アンインストール後にインターネットへ接続できない場合は、現在のネットワークサービスのプロキシ設定に残っているアドレスを確認し、元の設定に戻してから直接接続をテストしてください。さらに原因を調べる場合は、エラーが起きた操作とログの時刻を記録し、よくある質問で該当する症状を確認してください。

Android：VPNを許可し、バックグラウンド動作を管理

インストーラーを選び、元の設定を残す

Androidのダウンロード一覧を開き、まずClash Plusを選んでください。ほかの候補はClash Meta for Android、FlClash、Surfboardです。クライアントによって対応する設定内容は異なります。特に、どれもプロキシに対応しているという理由だけで、完全なYAMLを相互に使えると判断しないでください。サブスクリプションの提供元が対応するクライアントと形式を確認し、端末のアーキテクチャに合ったインストーラーを選びます。判断できない場合は、端末メーカーが提供するシステム情報を参照してください。

APKをインストールする際、Androidからブラウザーやファイルマネージャーに不明なアプリのインストール許可を求められることがあります。今回使用する配布元に必要な権限だけを許可し、インストール後は必要に応じて無効にしてください。インストール時に競合が表示されたら、同じパッケージ名のアプリがすでにあるか、署名が異なるか確認します。すぐにアンインストールしないでください。アプリを削除すると、ローカル設定も一緒に消える場合があります。配布元を変えて移行する前に、復元できる情報をエクスポートし、サブスクリプションを再取得できることを確認してください。

インポート後、設定と起動状態を確認

クライアントの設定画面を開き、クリップボード、URL、ローカルファイルからインポートします。保存後に更新結果を確認し、その設定を現在の使用項目として選択してください。システムの共有メニューからインポートした場合は、クライアントに戻って新しい項目が実際に追加されたか確認します。「共有完了」と「コアの読み込み成功」は同じではありません。解析エラーが起きたら、ログに記録された項目名や行番号を確認してください。同じURLをブラウザーで開けても、設定本文ではなくログインページが返されることがあります。

初回接続前にプロキシグループの選択を一つに固定し、後で比較できるようルールモードを維持してください。アプリごとのプロキシ機能がある場合は、「選択したアプリのみをプロキシ」と「選択したアプリを除外」のどちらが選ばれているか確認します。両者の意味は逆です。有効にした後、一部のアプリだけがプロキシを通る場合は、通常、対象範囲の設定が関係しています。まず接続記録を確認し、すぐにノードの障害と判断しないでください。

システムのVPN許可について

多くのAndroid用プロキシクライアントは、システムのVPNサービスを使って端末内の通信を取り込みます。初回起動時に表示されるシステムの許可画面で、許可対象のアプリを確認して接続を許可し、ステータスバーまたはシステムのVPN画面で状態を確認してください。ここでいうVPNは、システムが提供する通信の取り込み経路を指します。リモートサービスが従来型のVPNプロトコルを使うとは限りません。実際の設定によって、クライアント内のプロキシプロトコル、DNS、ルールが決まります。

一般に、同じユーザー領域で通常のVPNアプリを2つ同時に使って通信を取り込むことはできません。広告ブロック、企業ネットワーク接続、ほかのネットワークツールが同じ経路を使用している場合もあります。起動直後に切断される場合は、ほかのVPNを停止してから現在のクライアントをテストしてください。複数のアプリを何度も切り替えて接続を奪い合わないようにしましょう。常時接続VPNや、VPN切断時に通信をブロックする設定がある場合は、対象アプリがどれに設定されているか確認してください。

バックグラウンド制限とネットワーク切り替えに対処

画面ロック後に切断される場合は、まずバッテリー最適化、バックグラウンド動作、メーカー独自の自動起動管理を確認します。端末の設定画面から、クライアントに必要なバックグラウンド動作を許可し、システムが必要とする常駐通知は残してください。設定名はメーカーによって異なります。省電力設定をすべて一度に無効にする必要はありません。まず数分間ロックした後の状態を確認し、次に長時間の待機をテストして、プロセスの終了、ネットワークのスリープ、リモート接続のタイムアウトを切り分けます。

Wi-Fiからモバイルネットワークに切り替えると、既存の接続を再確立する必要がある場合があります。ネットワークが利用可能になるまで待ち、コアのログに再接続が記録されるか確認してください。接続されない場合は、クライアントの接続を停止して再起動します。モバイルネットワークでは、アプリのデータ通信がシステムで制限されていないか、サブスクリプションの更新がWi-Fi接続時のみに設定されていないかも確認してください。通信量の計算はシステムまたはサービス提供元の管理対象です。クライアントの接続状態だけでは、契約データの残量は分かりません。

プライベートDNS、LAN、終了後のネットワーク復旧を確認

Androidでは、プライベートDNS、アプリ内の暗号化DNS、クライアントによるDNS制御がそれぞれ別の名前解決経路を使うことがあります。ローカルの待ち受けは正常なのにドメインへ接続できない場合は、まずプライベートDNSの元の設定を記録し、クライアントの説明に従って一つずつ切り替えてテストします。暗号化DNSを無効にすればすべて解決すると考えないでください。接続に失敗する対象、名前解決のエラー、適用されたルールを確認し、検証後は必要な設定を元に戻してください。

プリンター、画面ミラーリング、家庭内デバイスの検出には、LANへのアクセスが必要です。プロキシを有効にした後にデバイスが見つからない場合は、該当するプライベートアドレスがバイパス対象になっているか、クライアントが必要なローカル通信に対応しているか確認してください。ルートを変更する前に接続を切って比較し、通信制御が原因かどうかを確かめます。クライアントを停止してもインターネットに接続できない場合は、VPN切断時に通信をブロックする設定が有効か確認し、通常のネットワーク設定に戻してください。

普段の更新では、まずクライアントでサブスクリプションを更新し、アプリの更新が必要か判断します。ログをエクスポートする前に、サブスクリプションURL、パスワード、接続先サイトなどの個人情報を削除してください。特定のアプリが常に直接接続する場合は、アプリごとのプロキシ対象と既存の長時間接続を確認します。必要であれば、作業中のデータを保存してからアプリを再起動し、新しい接続記録を確認してください。

iOS：Clash Plusをインストールしてシステム接続を確立

ストアからインストールし、アプリ情報を確認

iPhoneとiPadではClash Plusをおすすめします。Clash PlusのApp Storeページを開き、ストアに表示される案内に従ってインストールしてください。製品の公式サイトはclashplus.ioです。当サイトのiOSダウンロード一覧からも同じストアページにアクセスできます。システム要件と現在利用できる機能は、ストアおよびアプリの説明を確認してください。他のプラットフォームの画面を見て、iPhone版のメニューを判断しないでください。

インストール前に、端末に十分な空き容量があり、App Storeに正常にアクセスできることを確認してください。組織管理下の端末では、VPN設定やアプリのインストールが制限される場合があります。制限が表示されたら、まず管理上の要件を確認してください。接続を強制するために、組織から提供された構成プロファイルを削除しないでください。インストール後は、まずアプリを開いて設定の取り込み方法と接続スイッチを確認します。初回の動作確認に複数の要因が混ざらないよう、ほかのネットワークツールは一時的に併用しないでください。

アプリが対応する形式でサブスクリプションを追加

アプリでサブスクリプションまたは設定のインポート画面を開き、サービス提供元から案内された対応URLを貼り付けて取得または更新します。QRコードから読み込む場合は、信頼できる入手元のコードであることを確認し、認証情報が含まれる画面を周囲から見える場所に表示しないでください。URLのクエリパラメーターを欠落させないようにしてください。チャットアプリが自動で追加した句点、空白、改行によってリクエストに失敗することもあります。

インポート後、設定に選択可能なポリシーやノードが表示されるか確認し、明確な解析エラーがないか確認してください。デスクトップで使えるすべてのYAML項目が、モバイルアプリでも同じ意味で使えるとは限りません。アプリ独自のインポートや変換処理が行われる場合があります。非対応の項目が見つかったら、DNS、ルール、ポリシーグループをむやみに削除するのではなく、対応設定を入手するかアプリのドキュメントを確認してください。見かけ上は読み込めても動作が変わる設定を残さないようにしましょう。

アプリに設定選択機能がある場合は、インポートした項目が現在有効になっているか確認してください。複数のサブスクリプションがある場合は、用途が分かる名前を付け、期限切れの設定を誤って選ばないようにします。更新に失敗しても元の項目を残し、失敗理由とサービスアカウントの状態を確認してください。既存ノードで接続できるのにサブスクリプションだけ更新できない場合は、設定の取得経路に問題があります。システムのVPN設定を何度も削除して対処しないでください。

アプリによるVPN構成の追加を許可

初回接続時、iOSからアプリによるVPN構成の追加と、システム認証による確認を求められる場合があります。アプリ名を確認して許可し、アプリに戻って状態を確認してください。システムにVPNアイコンが表示されるのは、ネットワーク拡張が動作中であることを示すだけです。リモートノードとの接続がすべて正常に確立したとは限りません。次に接続先へのアクセス、アプリの接続記録、エラー情報を確認してください。スイッチがオンになっただけで設定完了と判断しないでください。

iPhoneでは通常、システムのネットワーク拡張機能を使って通信を取り込むため、デスクトップ向けのローカルシステムプロキシ設定手順をそのまま使わないでください。「念のため」とWi-Fiの手動プロキシ設定を追加するのも避けましょう。モバイルネットワークではその設定が適用されない場合があり、二重プロキシになるおそれもあります。通信を取り込む経路は一つにして、まずWi-Fiで動作を確認し、その後モバイルネットワークでテストしてください。LAN向けに別途プロキシが必要な場合は、独立した用途として設定します。

Wi-Fi、モバイルネットワーク、ローカルアクセスを個別に確認

まず安定したWi-Fiに接続し、普段直接アクセスできるページを開いてから、プロキシが必要なサイトを開きます。前者は正常で後者だけ失敗する場合は、ポリシーグループ、ノード、適用ルールを確認してください。どちらも失敗する場合は、クライアントを切断して基本ネットワークを確認してから、設定と通信の取り込みを調べます。複数の項目を続けて変更して結果を再現できなくならないよう、テスト中は接続先とノードを固定してください。

続いてモバイルネットワークに切り替え、アプリのモバイルデータ通信が許可されていることと、接続が再確立されることを確認します。ネットワークの切り替えで既存のセッションが切断されることがあるため、開いたままのページを見るだけでなく、ページを再読み込みしてください。ホテルや学校など、Web認証が必要なWi-Fiでは、プロキシを一時停止してネットワークのログインを済ませてから接続を開始します。認証が完了していない場合、ノードやDNSのエラーは上位ネットワークが通信を許可していないだけの可能性があります。

プリンター、ルーターの管理画面、その他のローカルデバイスにアクセスするときは、クライアントにローカルネットワークの許可が必要か、ルールに直接接続する経路が残っているか確認します。システムのプライバシー関連機能、ほかのVPN、管理ポリシーもアクセスに影響することがあります。すべてのプライバシー設定を恒久的に無効にするのではなく、一つずつ一時停止してテストしてください。毎回元の設定値を記録し、原因が分かったら必要な項目だけを変更します。

自動接続と設定の復旧を管理

オンデマンド接続や自動復旧に対応している場合は、手動接続が安定してから有効にし、画面ロック、復帰、ネットワーク切り替えをそれぞれテストします。フォアグラウンドアプリがシステムによって終了されることと、ネットワーク拡張が停止することは別の問題です。判断する際は、システムのVPN画面と実際のアクセス結果を併せて確認してください。Androidのバックグラウンド許可リストの手順をそのまま使わないでください。iOSでは権限とライフサイクルの仕組みが異なり、アプリが提供する設定も異なります。

使用を停止する際は、まずアプリ内で接続を切断してください。VPN構成を削除する必要がある場合は、システム設定のVPN管理画面から削除します。システム構成を削除しても、サブスクリプションサービスが解約されるとは限らず、アプリ内のサブスクリプション情報も必ずしも連動して削除されません。それぞれ個別に確認してください。再インストール前に復元可能な設定の入手元をバックアップし、サービスアカウントに再度ログインできることを確認します。問い合わせ時は端末のOS、ネットワークの種類、失敗する手順を伝え、サブスクリプションのQRコード全体は公開しないでください。

Linux：デスクトップへのインストールとsystemdでのコア実行

GUIクライアントと単体コアから選ぶ

デスクトップ環境では、まずLinuxのダウンロード一覧を確認してください。Clash Verge Revをおすすめします。FlClashも選べます。ディストリビューションに合ったDEBまたはRPMを選び、パッケージとシステムのアーキテクチャが一致していることを確認してください。GUIのないサーバーにデスクトップクライアントをインストールしても、通知領域にウィンドウが表示されるとは限りません。サーバー、ルーター、スクリプトで管理する環境では、単体のmihomoコアを使えますが、設定、権限、サービスの稼働管理は自分で行う必要があります。

デスクトップ版をインストールする際は、依存関係の解決にディストリビューションのパッケージマネージャーを使ってください。実行ライブラリが不足している場合は、まずパッケージマネージャーの出力を確認し、出所不明の共有ライブラリをダウンロードしてシステムディレクトリに上書きしないでください。起動後、通知領域、設定の保存先、システムプロキシ機能が現在のデスクトップ環境に対応しているか確認します。GNOME、KDEなどではプロキシ設定の場所が異なり、コマンドラインアプリがデスクトップのプロキシ設定を使うとは限りません。GUIのスイッチだけで全プロセスを制御できているとは判断できません。

設定をインポートして待ち受けポートをテスト

GUIクライアントでは設定画面からサブスクリプションをインポートし、その項目を選択してからシステムプロキシを有効にします。単体コアを使う場合は、実際に利用可能なプロキシとルールを含む完全なYAMLを用意してください。次のコマンドは、アーキテクチャに合ったバイナリを/usr/local/bin/mihomoにインストールし、使用可能な設定ファイルを指定のパスに保存したことを前提としています。コマンドは設定を検査するだけで、ノードの取得やシステムサービスのインストールは行いません。

/usr/local/bin/mihomo -t -f /etc/mihomo/config.yaml

検査に成功したら、まずフォアグラウンドで実行し、設定、ルールファイル、必要なデータベースを読み込めるか確認します。次に別のターミナルからプロキシリクエストを送ってください。作業ディレクトリには必要な読み書き権限が必要です。相対パスを含む設定では、データディレクトリも確認します。本番サーバーで初回から全通信をルーティングする設定を有効にしないでください。特に、デフォルトルートを書き換える可能性のある設定は、唯一のSSH接続で試さないでください。

/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
# 別のターミナルで実行。ポートは実際の設定に合わせる
curl --proxy http://127.0.0.1:7890 --head https://example.com

一般ユーザーでsystemdサービスを作成

常時実行する場合は、まず専用のサービスアカウントとデータディレクトリを作成し、検証済みの設定を設定ディレクトリに配置します。次の例は一般的なHTTPとSOCKSの待ち受けを対象としており、TUNに必要なネットワーク管理権限は付与しません。systemdを採用した一般的なディストリビューションを想定しています。コマンドは管理者が実行してください。アカウントやディレクトリがすでに存在する場合は現在の状態を確認し、既存の設定や権限を重複して上書きしないでください。

sudo useradd --system --home-dir /var/lib/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -o mihomo -g mihomo -m 750 /var/lib/mihomo
sudo install -d -o root -g mihomo -m 750 /etc/mihomo
sudo chown root:mihomo /etc/mihomo/config.yaml
sudo chmod 640 /etc/mihomo/config.yaml

以下の内容を/etc/systemd/system/mihomo.serviceとして保存します。設定ファイルとバイナリは配置済みであることが前提です。設定で参照するほかのローカルファイルもサービスアカウントが読み込めるようにし、データディレクトリには書き込み権限を付与してください。コア全体を長期間管理者権限で実行するのではなく、まず一般ユーザーによるローカルプロキシサービスから始めると、ファイル権限とネットワーク権限の問題を切り分けやすくなります。

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

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

[Install]
WantedBy=multi-user.target

ログを確認してから自動起動を有効化

まずサービス定義を再読み込みして起動し、状態とログを確認します。待ち受け、プロキシリクエスト、設定の読み込みがすべて正常であることを確認してから、自動起動を有効にしてください。フォアグラウンドでテストしたプロセスは先に停止しないと、サービスとポートを奪い合うことがあります。サービスが終了する場合、再起動を知らせる最後のログよりも、最初に記録された明確なエラーのほうが役に立つことがあります。設定ファイルのパス、権限、ポート競合、不足ファイルを優先して確認してください。

sudo systemctl daemon-reload
sudo systemctl start mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -b -n 80 --no-pager
sudo systemctl enable mihomo

ネットワーク接続のオンライン判定は起動順序を定めるだけで、サブスクリプションのサイトやリモートノードがその時点で利用できることを保証しません。設定を更新する前に旧ファイルを保存し、設定の検査を実行してください。検査に成功してからサービスを再起動します。新しい設定が使えない場合は旧ファイルに戻して再起動し、設定を何度も変更しながらサービスを再起動し続けないでください。詳しい手順はLinuxデスクトップとsystemdの構築メモをご覧ください。

TUNの権限とサービスの公開範囲を確認

LinuxのTUNでは、デバイスノード、ネットワーク管理権限、ルーティング、DNSも関係します。上記の一般ユーザー向けサービスにはこれらの設定が含まれていません。tun.enableを有効に変更しただけで、構築が完了したと考えないでください。ディストリビューション、カーネル環境、mihomoのドキュメントを確認し、必要最小限の権限を設定してください。コンテナではホスト側で許可する権限も考慮する必要があります。リモート環境では、通信制御を試す前にコンソールなどの復旧手段を用意してください。

ローカルだけで使用する場合、プロキシとコントロール用インターフェースはループバックアドレスにバインドしてください。パネルを接続するために、待ち受けをすべてのネットワークインターフェースに公開しないでください。LAN内で共有する必要がある場合は、接続元のネットワークを制限し、認証とファイアウォールを設定します。コントロール用インターフェースは個別に保護してください。単体コアを停止しても、手動で追加したプロキシ環境変数やルートは自動的に削除されません。終了時に元の設定に戻し、直接接続のリクエストでネットワークの状態を確認してください。

設定とトラブルシューティング：問題の段階ごとに確認

まず問題が起きている範囲を切り分ける

まずプラットフォーム、クライアント名、通信の振り分け方法、エラーが起きた時刻を記録します。次に、基本ネットワーク、サブスクリプションの取得、設定の解析、コアの起動、通信の取り込み、ルール選択、リモート接続のどの段階に問題があるか判断してください。クライアントを終了した状態でも一般的なサイトを開けない場合は、ノードを変更するのではなく、ネットワークへのログイン、ゲートウェイ、システムプロキシを先に復旧します。サブスクリプションの更新だけが失敗し、旧設定が使える場合は、サブスクリプションURLとサービスアカウントの状態を優先して調べてください。

一度に変更するのは一つの項目だけにし、同じネットワーク、接続先、ノードで再テストしてください。直近で正常に動作した設定を残し、変更内容と結果をローカルのメモに記録します。ログの時刻とシステム時刻も合わせてください。時刻がずれていると、古いエラーを現在の原因だと誤認しやすくなります。調査のためにログの詳細度を一時的に上げた場合は、終了後に通常のレベルへ戻してください。アクセス先を含むログが長期間大量に記録されないようにしましょう。

サブスクリプションの取得失敗とYAML解析エラーを分けて対処

更新に失敗したら、URL全体が入力されているか、認証情報が有効か、サービス提供元が特定のサブスクリプション形式を指定しているか確認します。ログインページ、アクセス制限のページ、ノード情報の文字列が返されると、クライアントが解析エラーを報告する場合があります。ブラウザーに内容が表示されるだけで正しい形式だと判断しないでください。クライアントによっては、サブスクリプション更新だけに直接接続またはプロキシ経由を指定できます。現在使えるプロキシがあることを確認してからテストしてください。動作しない設定を使って自分自身の更新を試さないようにしましょう。

YAMLの行番号エラーが表示されたら、その行と前後の階層のインデント、コロン、引用符を確認してください。項目のエラーが次の行で初めて報告される場合があります。コード例の断片を完全な設定の末尾にそのまま追加し、トップレベルのキーを重複させないでください。次はルール構造の例です。PROXYは、完全な設定内に実際に定義されたプロキシまたはポリシーグループを指定する必要があります。名前だけをコピーして、接続先を定義しないままにしないでください。

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

ルールは通常、記述された順に照合され、最初に一致したポリシーが使われます。より具体的な条件は、最終的なフォールバックルールより前に記述してください。ローカルのオーバーライドで順序が変わっていないか、サブスクリプションの更新で手動の変更が上書きされていないか確認します。設定の解析に成功したということは、構造を読み取れたことを示すだけです。すべてのノードが利用できることや、ルールが想定どおりに動作することを保証するものではありません。

接続記録から次に確認する項目を判断

アプリからリクエストを送っても記録がまったく表示されない場合は、システムプロキシ、TUN、アプリ独自のプロキシ設定を確認してください。記録はあるのに出口が違う場合は、適用ルールとポリシーグループを確認します。正しいルールに一致しているのに接続できない場合は、ノード、プロトコルの対応状況、リモート側への到達性を調べてください。ルールモードとシステムプロキシを一つのスイッチと考えないでください。前者はコアに入った通信をどう振り分けるか、後者は一部のアプリの通信をコアにどう渡すかを決めます。

症状	まず確認	次に行うこと
ローカル接続が拒否される	コアの動作状況とポートの一致	待ち受けの失敗とポートの競合を確認
設定を解析できない	返された内容の形式、インデント、項目の対応状況	行番号を確認し、動作する設定に戻す
特定のアプリだけアクセスできない	通信の取り込み範囲とアプリのプロキシ設定	接続記録と適用ルールを確認
ネットワーク切り替え後に接続できない	現在のネットワーク、プロキシ、ルートの状態	接続を再確立し、DNSの経路を確認

「接続が拒否されました」は、接続先ポートにサービスがない、または接続が明示的に拒否された可能性を示します。「タイムアウト」は、制限時間内に処理が完了しなかったことを示すだけで、ノードがブロックされたとは限りません。エラーがローカルの待ち受け、リモートとのハンドシェイク、接続先からの応答のどの段階で起きたかを確認すると、エラー語句だけを見るより原因を特定しやすくなります。エラーを共有する場合は必要な前後関係を残しつつ、認証情報や個人的な接続先は削除してください。

DNS、IPv6、UDPを個別に確認

DNSはドメイン名をIPアドレスに変換します。ブラウザーの暗号化DNS、システムのリゾルバー、コアのDNS設定は異なる経路を使う場合があり、サーバーを一つ変更してもすべてのリクエストに反映されるとは限りません。Fake-IPはドメイン名を仮想アドレスに対応付け、後からコアが関連付けて処理する仕組みです。通信がコアを経由しないまま仮想アドレスを使うと、アクセスに問題が起きる場合があります。有効にする前に通信の取り込み経路が確立していることを確認し、アプリとの互換性に応じて例外を設定してください。

IPv6が使えるかどうかは、ローカルネットワーク、ノード、設定によって異なります。IPv6を無効にする方法は、記録を残して比較するためのテストとしてのみ使い、恒久的な解決策と決めつけないでください。UDPを利用するには、アプリ、通信の取り込み方法、ノード、プロトコルのすべてが対応している必要があります。ブラウザーでWebページを開けても、ゲームやリアルタイム通信が正常とは限りません。ドメイン名ではなくIPアドレスを指定したHTTPS接続で代用しないでください。証明書の検証や接続先サイトの選択にドメイン名が必要な場合があります。

更新、ロールバック、ネットワークの復旧

更新前に、サブスクリプションの入手元、ローカルのオーバーライド、現在の設定をそれぞれバックアップしてください。アプリ、コア、設定の更新はできるだけ別々に行い、一つずつ動作を確認してから次へ進みます。アーカイブ済みのクライアントは新しい項目に対応していない場合があります。移行する際は、現在もメンテナンスされているクライアントを選び、必要な設定を段階的に戻してください。古いキャッシュ、旧補助サービス、新しいクライアントをまとめてコピーし、後から異常の原因を推測するような移行は避けましょう。

ネットワークを元に戻すときは、逆の順序で操作します。TUNまたはシステムVPNを停止し、システムプロキシを無効にしてから、手動で変更したDNS、アプリのプロキシ設定、ターミナルの環境変数を元に戻し、直接接続を確認してください。アンインストールが必要な場合は、先にクライアントが提供するサービスの削除手順を実行します。解決しない場合は、個人情報を除いたログを添えてよくある質問で症状を確認してください。接続の手順を忘れただけなら、クイックスタートガイドに戻り、最小限の接続をもう一度確立してください。