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

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

システム構成から通信の制御まで、プラットフォーム別に導入し、症状に応じて問題を切り分けます。

5つのプラットフォーム別ガイド サブスクリプション · 権限 · DNS · TUN

このページは、インストール前の確認や、権限・プロキシ・名前解決の問題が起きたときに参照できる総合ガイドです。初めて使う方や、まず接続を確立したい方は、Clashの使い方ガイドに沿って基本操作を試してください。プラットフォームごとの違いや設定上の注意点を確認する際は、このページに戻ってください。インストーラーはクライアントのダウンロードページから選べます。利用できる機能は、実際の画面とコアの対応状況によって異なります。

おすすめの読み方：まず共通の準備を確認し、使用するデバイスの章へ進んでください。最後の章では「設定を読み込めるか → 通信が取り込まれているか → ルールが適用されているか → 接続先に到達できるか」の順に確認します。

共通の準備：アーキテクチャ、サブスクリプション、通信の制御方式

デバイスを確認してからクライアントを選ぶ

インストール前に、OS名、システムアーキテクチャ、管理者権限の有無を確認しましょう。アーキテクチャによってインストーラーが動作するかどうかが決まり、権限によってサービスの導入や仮想ネットワークインターフェースの作成が可能かどうかが決まります。「64ビットOSだからx64」とは限りません。ARMプロセッサ搭載のPCでも、64ビットOSを実行している場合があります。Windowsでは「システム情報」、macOSでは「このMacについて」を確認し、Linuxでは下記のコマンドを使います。スマートフォンでは、ダウンロードページに記載された対応パッケージを選び、古い端末ではプロセッサの対応状況も確認してください。

GUIを使えるデバイスでは、グラフィカルなクライアントがおすすめです。当サイトでは、対応プラットフォーム向けにClash Plusを第一候補として紹介しています。クライアントは設定管理、プロキシの切り替え、システム連携を担い、コアは設定の解析、ルールの適用、接続の確立を担います。両者は別のものです。クライアントを入れ替えても、システム権限やバックグラウンドサービス、ローカルの上書き設定は自動で引き継がれません。同じサブスクリプションを使っても、コアの機能や設定のマージ方法によって動作が異なることがあります。選び方の詳細はクライアント比較を、コアとの関係はmihomoとGUIクライアントの関係をご覧ください。

uname -m
# x86_64 は通常 x64 / AMD64 に対応
# aarch64 または arm64 は通常 ARM64 に対応

インポートするサブスクリプションまたは設定ファイルを用意する

クライアントはプロキシツールであり、利用可能な接続先を自動で作成するものではありません。始める前に、利用権限のあるサブスクリプションURLまたはローカルのYAMLファイルを用意し、サービスの有効期限も確認してください。一般的な設定には、ノード、プロキシグループ、ルールが含まれます。ノード一覧しかない場合、動作する設定にするためテンプレートが必要なことがあります。形式エラーが表示されても、すべてのノードが無効とは限りません。まずURLから実際に返される内容が設定ファイル、ノード情報、ログインページ、エラーメッセージのどれかを確認してください。詳しくはサブスクリプションの形式と変換方法をご覧ください。

サブスクリプションURLには個人用の認証情報が含まれることがあるため、パスワードと同様に扱ってください。公開スクリーンショットやオンライン変換サイト、公開リポジトリには載せないでください。設定を共有する場合は、ノードのパスワード、コントロールインターフェースのキー、ローカルパスも確認しましょう。リモートサブスクリプションを更新すると、直接編集した内容が上書きされることがあります。個別の変更は、クライアントが対応する上書き・マージ機能を使うのがおすすめです。編集前に現在動作している設定を書き出し、選択中のプロキシグループも記録しておくと、問題発生時に復元できます。同じ項目を複数の場所で繰り返し変更するのは避けましょう。

システムプロキシとTUNの違い

システムプロキシは、OSのプロキシ設定に従うアプリにプロキシ接続を提供します。通常はブラウザーで使えますが、コマンドラインツールやゲーム、一部のアプリは設定を無視することがあります。TUNは仮想ネットワークインターフェースを使い、ルーティング対象の通信を取り込みます。別途権限が必要で、ルートやDNSの設定も関係します。「どんな問題も解決する強化ボタン」ではありません。まずシステムプロキシでサブスクリプションと接続先を確認し、必要なアプリに応じてTUNを有効にしてください。モバイル端末では通常、システムのVPNインターフェースを経由します。画面上の名称は異なる場合がありますが、システムの許可が完了していることを確認してください。

項目・設定役割と注意点
混合ポート同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。実際のポート番号は現在の設定で確認してください。
LANからの接続を許可他のデバイスから接続できるようにする設定で、この端末のインターネット接続に必須ではありません。
ルールモードルールを上から順に照合します。最終的な接続先は、プロキシグループで選択中の項目にも左右されます。
外部コントロールパネルやクライアントからコアを制御するための機能です。ブラウザーに設定するプロキシポートではありません。

以下は設定項目を説明する抜粋です。ノード情報は含まれていないため、完全なサブスクリプションとして単独では使えません。ループバックアドレスへの接続は、この端末内に限られます。LANに公開する場合は、ファイアウォールと認証もあわせて設定してください。外部コントロールのインターフェースは、特に公共ネットワークへ直接公開しないでください。リモート管理には、アクセスを制限できる別の方法を利用しましょう。

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

最後に、システム時刻が正しいこと、端末がローカルネットワークに正常に接続できることを確認し、プロキシやルートを変更する他のソフトウェアは一時停止してください。元のプロキシ設定とDNSの参照先、特に職場の端末で使われている自動設定URLを記録しておきましょう。クライアントを終了した後もインターネットに接続できない場合、元に戻す手掛かりになります。組織管理下の端末では、管理者のネットワークポリシーに従ってください。

Windows：サービスの導入とシステムプロキシ

ダウンロード、インストール、初回起動

Windowsのダウンロード欄を開き、まずClash Plusを検討してください。必要に応じてClash Verge Rev、FlClash、Clash Nyanpasuも選べます。Clash for Windowsは開発が終了しています。互換性を確認したうえで古い環境を調べる場合には参照できますが、新しい端末での第一候補にはおすすめしません。「設定 → システム → バージョン情報」でシステムの種類を確認し、ダウンロードページの説明に従ってアーキテクチャを選んでください。対応するネイティブ版がない場合、ファイル名が似ているという理由だけでインストールせず、OSとクライアントがその実行方式に対応しているか確認しましょう。

インストール時はOSの案内を読み、一般的なアプリケーション用フォルダーにインストールしてください。初回起動時にバックグラウンドサービスやネットワークコンポーネントの導入を求められることがあります。許可する対象が、インストール中のクライアントと一致していることを確認しましょう。サービスの設定を代替するために、アプリ全体を常に管理者として起動するのは避けてください。GUIが開くことと、コアのサービスに必要な権限があることは別です。セキュリティ警告が表示された場合は、ファイルの入手元、対応OS、署名情報を確認してください。インストールのためにシステムの保護機能を一括で無効にするのは避けましょう。職場のPCでサービスをインストールできない場合は、許可されている通常のプロキシ機能を使ってください。

サブスクリプションを追加し、最初の接続を確認する

「設定」または「サブスクリプション」を開き、URLから追加してダウンロードします。設定名が表示されただけでは完了ではありません。現在の設定として有効にし、「プロキシ」画面でプロキシグループが表示されるか確認してください。リストが空の場合は、インポート時の通知に戻り、ダウンロード状況と解析エラーを確認します。最初からTUNを有効にしないでください。複数のサブスクリプションがある場合は、提供元や用途が分かる名前を付けましょう。今使いたい設定が選択されていることを確認してください。別のファイルを編集していて、実際には他の設定を使っていたという事態を防げます。

最初の確認ではルールモードを選び、プロキシが必要なグループで接続先を1つ選択してから、システムプロキシを有効にします。Windowsの「設定 → ネットワークとインターネット → プロキシ」で、手動プロキシのアドレスとポートがクライアントの待ち受け設定と一致しているか確認してください。よく使われるローカルアドレスは 127.0.0.1、ポートは 7890 ですが、実際の値はクライアントの表示に従ってください。ブラウザーに独自のプロキシ拡張機能がある場合は、一時的に無効にするか、システム設定を上書きしていないか確認しましょう。そうしないと、システムプロキシが有効かどうかを正しくテストできません。

ブラウザー独自の設定を使わずに比較するには、PowerShellでプロキシを明示してリクエストできます。以下のコマンドで確認できるのは、ローカルのHTTPプロキシへの接続だけです。接続先サイトからHTTPレスポンスが返れば、少なくともリクエストと応答が一度往復したことが分かります。ステータスコードが成功を示すとは限りません。このコマンドだけで、すべてのアプリやUDP通信が正常だと判断しないでください。

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

TUNの権限、ネットワークアダプター、ルート

システムプロキシが使えるようになった後、プロキシ設定に従わないアプリがある場合は、クライアントのTUNを有効にしてください。初回の有効化にはサービスコンポーネントと昇格した権限が必要なことがあります。画面の案内に沿ってインストールし、サービスが実際に動作しているか確認しましょう。TUNを有効にしたら、スイッチの色だけでなく、接続画面に対象アプリのリクエストが表示されるかも確認してください。仮想ネットワークアダプターが存在しても、ルートが正しいとは限りません。コアが動作していても、DNSが制御されているとは限りません。それぞれの状態を分けて確認しましょう。

TUNを有効にした後、LAN機器、プリンター、職場のネットワークリソースに接続できなくなったら、まずTUNを無効にして比較してください。無効にすると復旧する場合は、クライアントのLAN除外、ルート除外、組織VPNのアドレス範囲を確認します。プライベートネットワークのルートを自動管理するクライアントもありますが、ネットワーク環境によっては既存のゲートウェイと競合します。固定の除外ルールを大量にそのままコピーするのは避けましょう。特に、リモートアクセスに必要なプライベートアドレスまで一括で直接接続にしないでください。除外範囲は実際のネットワーク用途に合わせて設定します。

ポートの競合と終了後の設定復旧

「アドレスは既に使用されています」と表示された場合は、別のクライアント、古いコアプロセス、開発用プロキシが同じポートを使っていないか確認します。下記のコマンドで待ち受け状態を調べ、タスクマネージャーでプロセスIDから該当するアプリを確認してください。プロセスIDが表示されたからといって、システムプロセスをすぐに終了しないでください。ポートを変更した場合は、ブラウザーの拡張機能、ターミナルの環境変数、他のデバイスの設定も更新が必要です。クライアント内のポートを変更しても、外部の設定は自動で変わりません。

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

自動起動の設定も、GUIの起動、コアサービスの起動、設定の自動有効化、システムプロキシの自動復元を分けて確認してください。設定後に一度再起動し、ログイン後も設定が有効で、ポートが待ち受けているか確認しましょう。スリープ復帰後にのみ問題が起きる場合は、サブスクリプションを繰り返しダウンロードする前に、ネットワークの切り替えとサービスの状態を確認してください。バックグラウンド復帰の問題を見落とすおそれがあります。

macOS：チップのアーキテクチャ、ネットワークサービス、権限

Apple SiliconとIntelのインストーラーを見分ける

Appleメニューの「このMacについて」でチップまたはプロセッサを確認します。Apple Siliconは通常ARM64、Intelはx64に対応します。macOSのダウンロード欄を開き、まずClash Plusを検討してください。画面の使い勝手に応じてClash Verge RevやFlClashも選べます。ClashX Metaは開発が終了しているため、アーカイブ版を使う場合はmacOSとの互換性を確認してください。できるだけネイティブアーキテクチャのインストーラーを選びましょう。互換モードで動作しても、バックグラウンドサービスやネットワークコンポーネント、アップデート手順が現在の端末に適しているとは限りません。

ディスクイメージ形式のインストーラーの場合は、開いたウインドウからアプリを「アプリケーション」フォルダーにドラッグし、そのフォルダーから起動してください。マウントしたディスクイメージから常時実行すると、パスやログイン時の起動項目、アップデートに問題が起きることがあります。アプリを開けないという警告が表示されたら、入手元、システム要件、エラーの詳細を確認し、システムが案内する方法で対処してください。ネット上で見つけた属性削除コマンドをまとめて実行したり、アプリ全体の権限を大まかに変更したりするのは避けましょう。

設定を追加して、現在使っているネットワークサービスを確認する

クライアントの設定画面でURLまたはローカルファイルを追加し、ダウンロード後に有効化します。プロキシ画面でプロキシグループとルールが表示されることを確認し、接続先を手動で選択してください。次にシステムプロキシを有効にし、「システム設定 → ネットワーク」で現在使っているWi-Fiまたは有線接続を開き、詳細情報のプロキシ設定を確認します。macOSのプロキシ設定は通常、ネットワークサービスごとに保存されます。Wi-Fiで設定できても、有線接続に切り替えたとき同じ設定が引き継がれるとは限りません。

有線と無線の両方に接続している場合は、現在のデフォルトルートとネットワークサービスの優先順位を確認しましょう。テスト時にネットワーク経路を1つに絞ると、原因を特定しやすくなります。ブラウザーは接続できるのにターミナルから接続できない場合は、システムDNSをすぐ変更せず、プロキシを明示したコマンドで確認してください。ターミナルのツールがシステムプロキシを参照するかどうかは、ツールの実装によります。ツール独自の引数や環境変数が必要な場合もあります。これだけでシステムプロキシが無効だとは判断できません。

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

scutil --proxy は現在のプロキシ設定を確認するコマンドです。有効かどうか、アドレス、ポートを確認できますが、出力だけではリモートの接続先が利用可能かどうかは分かりません。ブラウザーで自動プロキシ設定や拡張機能、仕事用プロファイルを使っている場合は、実際の通信経路が上書きされていることもあります。通常のブラウザーウインドウとプロキシを明示したリクエストを組み合わせて試すと、ブラウザーの設定とクライアントの接続先を切り分けられます。同じ画面で何度も設定を切り替える無駄も減らせます。

補助サービス、TUN、他のVPN

TUNを使うには、クライアントによる補助サービスやネットワーク関連コンポーネントのインストールが必要なことがあります。権限の確認画面が表示されたらアプリ名を確認し、クライアントの手順に従って設定してから有効化を確認してください。現在の機能に必要な権限だけを許可します。「フルディスクアクセス」を一般的な解決策として使わないでください。OSのアップデート後に一部の権限やバックグラウンド項目を再確認する必要がある場合は、再インストールする前に「ログイン項目と機能拡張」などのシステム設定を確認しましょう。

TUNを有効にする前に、別のVPNや同種のプロキシクライアントを終了してください。メニューバー上ではオフに見えても、ネットワーク機能拡張が残っているアプリには特に注意が必要です。複数のツールが同時にデフォルトルートやDNSを変更すると、リクエストの迂回やループ、一部ドメインだけが失敗する問題につながります。組織のVPNと併用する必要がある場合は、管理要件に従ってルート範囲を分けてください。個人用クライアントでグローバルモードにしても、組織のネットワークとのアドレス競合は自動で解決しません。

以下はmihomoのTUN設定項目を説明する抜粋です。macOSのすべてのクライアントにそのまま貼り付けられる設定例ではありません。GUIクライアントはシステムに応じて設定を再生成する場合があるため、まずクライアントの設定画面を使ってください。自動ルートとインターフェースの検出は、通信をコアに取り込む経路を設定する機能です。リモートに接続するには、引き続き利用可能な設定と正しいプロキシグループが必要です。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

スリープ、ネットワーク切り替え、アンインストール後の復旧

Macを閉じて再び開いた後、クライアント上では接続中なのにWebページを開けない場合は、まずWi-FiにIPアドレスが割り当てられているか、追加のログインが必要でないかを確認し、コアが復帰しているかを見ます。ホットスポットの切り替え後に問題が起きた場合は、通信の制御を無効にして通常のネットワーク接続を確認してから、もう一度有効にしてください。これにより、基本ネットワークとプロキシの問題を切り分けられます。復帰に失敗しただけで設定をすべて削除する必要はありません。通常、スリープしただけでサブスクリプションの内容は変わりません。

ログイン時に自動起動する設定にしたら、バックグラウンド実行が許可されているか確認し、再起動後に設定が自動で有効になるかも確かめてください。ターミナルで一時的に設定したプロキシ環境変数は通常、現在のセッションにのみ適用されます。シェルの設定ファイルに記述した場合、GUIクライアントを終了しても変数が残ることがあります。トラブル時はシステムプロキシとターミナルの環境変数を両方確認し、片方だけを元に戻すことのないようにしましょう。

Android：VPNの許可とバックグラウンド動作

インストーラーを選び、初回の権限を許可する

Androidのダウンロード欄では、まずClash Plusを検討してください。機能に応じてClash Meta for Android、FlClash、Surfboardも選べます。インストール前にOS要件とアーキテクチャを確認しましょう。比較的新しい端末では通常ARM64、古い端末ではARM版や汎用パッケージが必要な場合があります。ダウンロードしたファイルはシステムのインストーラーで開きます。ファイルマネージャーやブラウザーにアプリのインストールを許可するのは、必要な場合だけにしてください。インストール後はこの提供元の権限を取り消せます。すべてのアプリに常時インストールを許可する必要はありません。

起動したら、まずサブスクリプションを追加してから接続を開始します。AndroidではVpnServiceを通じてシステムのVPN許可画面が表示され、許可するとクライアントがローカルの仮想ネットワークインターフェースを作成できます。ステータスバーにVPNアイコンが表示されても、システムトンネルが確立したことを示すだけで、サブスクリプションやルールの正しさまでは分かりません。許可画面が何度も表示される、確認ボタンを押せないといった場合は、画面オーバーレイ、ユーザー補助機能の通知、端末管理の制限を確認し、システムの案内に従ってください。許可を回避するために異なるパッケージを何度もインストールしないでください。

サブスクリプションの追加、プロキシグループの選択、アプリの通信制御

設定画面でリモート設定を新規作成し、サブスクリプションURLを入力してダウンロードした後、現在の設定に切り替えます。貼り付ける際は、先頭・末尾の空白や改行に注意してください。チャットアプリによってはURLが複数行に分割されることがあります。インポートに失敗したら、まず詳細なメッセージを確認し、ネットワーク接続、認証の期限切れ、形式の非互換を切り分けます。完全なYAML設定とノード情報では扱いが異なることがあります。ブラウザーで開けるURLがすべて直接インポートできるサブスクリプションとは限りません。

設定を有効にしたらプロキシ画面でルールモードとプロキシグループの接続先を選び、VPNを開始します。モバイル端末のVPNによる通信制御は、デスクトップOSのシステムプロキシと同じものではありません。通常、Wi-Fiのプロキシにローカルアドレスを追加設定する必要もありません。以前にWi-Fiのプロキシを手動設定した場合は、テスト前に設定を記録し、引き続き必要か確認してください。そうしないと、システムが停止済みの古いポートへリクエストを転送することがあります。まずはクライアントの標準的な接続方式で動作を確認し、その後に高度なネットワークスタックの設定を調整しましょう。

アプリごとのプロキシ設定には、「選択したアプリのみをプロキシ経由にする」と「選択したアプリをプロキシから除外する」という逆の動作があります。選ぶ前に画面の説明をよく読んでください。対象アプリを変更した後、反映するためにVPNの再接続が必要なクライアントもあります。システムのダウンロード機能、ブラウザー、アプリ内ブラウザー、メインアプリは、それぞれ別のプロセスやパッケージの場合があります。メインアプリだけを選択しても、ログインやダウンロードの通信すべてを対象にできるとは限りません。ページを表示できるのに添付ファイルを取得できない場合は、すぐに接続先を変更せず、リクエストを送っているコンポーネントを確認しましょう。

バッテリー最適化と画面ロック後の切断

画面を表示している間は使えても、ロックしてしばらくすると接続が切れる場合は、まずバックグラウンドの制限を確認します。アプリ情報で必要なバックグラウンド動作を許可し、システムの設定に従ってバッテリー最適化を調整してください。クライアントのフォアグラウンドサービス通知は表示したままにします。メーカー独自のシステムでは、自動起動、連携起動、タスクの終了を別々に管理している場合があります。設定名はOSによって異なるため、1つの項目を変更しただけでバックグラウンド実行が完全に許可されたと判断しないでください。詳しくはAndroidのVPN許可とバッテリー最適化除外設定をご覧ください。

バックグラウンド実行を許可するために、端末全体の省電力機能を無効にする必要はありません。まずクライアントに必要最小限の変更を行い、画面をロックした状態で通知、Webページの再読み込み、接続状態を確認してください。それでも消費電力が大きい場合は、ログが詳細レベルのままになっていないか、サブスクリプションの更新頻度が高すぎないか、アプリが失敗したリクエストを繰り返していないかを確認しましょう。詳しくはモバイル端末のバッテリー消費とバックグラウンド動作をご覧ください。バッテリーの減り方は電波状況、画面、使用状況によって変わるため、一度の観察だけでクライアントを評価しないでください。

常時接続VPN、テザリング、ネットワーク切り替え

Androidの「常時接続VPN」と「VPNを使わない接続をブロック」は、システム全体に適用される設定です。後者を有効にすると、クライアントの停止や起動失敗時に端末がインターネットに接続できなくなり、Wi-Fiの不具合のように見えることがあります。設定する前に、この制限が必要か確認し、元に戻す方法も覚えておきましょう。多くの一般的な環境では、同じユーザープロファイルでVPNインターフェースを使うアプリを2つ同時には動かせません。別のファイアウォールやフィルタリングアプリが同じ接続枠を使っている場合もあります。

Wi-Fiからモバイルネットワークに切り替えた後に接続できなくなったら、モバイルデータの許可、システム時刻、通信事業者のネットワークが正常かを確認し、VPNを再接続してください。公共Wi-Fiでログインが必要な場合は、システムの制限を守りながら一時的に通信の制御を無効にし、認証を済ませてから再び有効にします。設定の読み込みは成功しているのに、どのアプリにも接続履歴がない場合は、VPNの許可とアプリごとの対象リストを確認してください。履歴があるのにすべてタイムアウトする場合は、接続先、名前解決、基本ネットワークを確認しましょう。

Surfboardとmihomo系クライアントでは、設定形式や機能へのアクセス方法が完全には一致しません。YAMLをそのままどのクライアントにも読み込ませられるとは限りません。アプリを切り替える前に、サブスクリプションが対応する形式を確認し、通信制御の権限とアプリごとの対象リストを設定し直してください。同期できる設定とシステムの権限は分けて扱います。システムの権限は、各端末で改めて確認が必要です。

iOS：App Storeからのインストールとトンネルの設定

Clash Plusをインストールして設定の入手元を確認する

iPhoneとiPadではClash Plusがおすすめです。App StoreのClash Plusページからインストールできます。製品情報は公式サイトのclashplus.ioをご覧ください。当サイトのiOSのダウンロード欄にも共通の案内を掲載しています。インストール前にApp Storeに表示されるシステム要件を読み、インストール後は自分のサブスクリプションURLまたは設定ファイルを用意してください。アプリをインストールできただけでは、接続先の準備は完了していません。

初回起動時は、設定一覧、プロキシグループ、接続スイッチ、ログの表示場所を確認してください。リリースによって画面上の文言が変わることがあるため、この章では機能を基準に説明します。ボタン名がすべて一致する必要はありません。他のアプリから共有してファイルを読み込む場合は、拡張子と内容を確認し、Webページの保存データやサブスクリプションの説明ページを誤って読み込まないようにしましょう。設定のアカウント情報は個人用の認証情報です。スクリーンショットを撮る際は、サブスクリプションURL全体やノードの認証情報が見えないようにしてください。

サブスクリプションを追加してVPN設定を行う

設定管理でリンクから追加する項目を選び、サブスクリプションを貼り付けてダウンロードし、その設定を有効にします。名前が表示されたら、プロキシグループがあり、接続先を選択できることも確認してください。返された内容が非対応の場合は、サービス提供元が指定する形式を使うか、信頼できる環境で設定を変換してください。ファイルの拡張子をYAMLに変えるだけでは形式の変換になりません。定期更新が必要なリモート設定は元の入手先を残しておきましょう。一度だけ読み込んだ静的なコピーを、ノードが自動同期される設定だと誤解するのを防げます。

初回接続時に、システムからVPN設定の追加や端末パスコード、生体認証による確認を求められる場合があります。許可した後、クライアントに戻ってトンネルを開始し、システムのVPN画面で現在の接続状態を確認してください。追加できない場合は、スクリーンタイム、デバイス管理、組織のポリシーによる制限がないか確認しましょう。管理対象の端末では、管理者に利用可能な方法を確認してください。個人用プロキシを使うために管理プロファイルを削除するのは避けましょう。

iOSのネットワーク接続はシステムのネットワーク機能拡張が担います。すべてのアプリに同じデスクトップ用HTTPプロキシアドレスを設定する方式ではありません。クライアントにTUN、ネットワークスタックなどの項目があっても、実装に応じた意味を確認してください。Windowsのサービスインストールや仮想ネットワークアダプターの手順をそのまま当てはめないでください。最初の確認ではネットワーク設定を初期状態のままにし、ルールモードと明確な接続先を選択してから、ブラウザーで再現性のあるHTTPSページを開きます。

ルール、DNS、アプリ内の接続

ブラウザーは使えるのに特定のアプリで失敗する場合は、まずそのアプリの接続履歴があるか確認します。履歴がない場合は、特殊なネットワーク経路、別のVPN、アプリ独自の制限を調べてください。履歴がある場合は、適用されたルール、プロキシグループ、エラーの種類を確認します。アプリによってはUDP、独自の名前解決、内部キャッシュを使うため、Webページが開けても正常とは限りません。ルールを変更したら対象アプリを終了して再起動してください。必要に応じてトンネルを再接続し、新しい設定でリクエストを送ります。

DNS設定はドメイン名の名前解決方法に影響し、プロキシグループは接続先を決めます。両方の設定を確認してください。DNSサーバーだけを変更しても、すべての通信が自動的にプロキシ経由になるわけではありません。反対に、プロキシ接続先を選んでも、到達できないDNSサーバーの問題は解決しません。特定のドメインに接続できない場合は、ドメイン名、名前解決の結果、適用されたルールを記録し、変更は最小限にとどめて確認します。fake-ipの仕組みと注意点についてはDNSテストとfake-ipの設定をご覧ください。診断ページの1つの結果だけで結論を出さないでください。

ネットワーク切り替え、自動接続、設定の移行

自宅のWi-Fiからモバイル通信に切り替えると、既存の接続が一時的に切れたり、ネットワークアドレスの変化によって新しい接続が影響を受けたりすることがあります。まずシステムのネットワークが安定するのを待ち、トンネルが復帰するか確認してください。長く復旧しない場合は一度停止して再接続し、クライアントと対象アプリにモバイルデータの利用が許可されているか確認します。公共Wi-Fiに認証ページがある場合は、まずWi-Fiのログインを完了してからプロキシを試してください。ネットワーク認証が終わっていない状態で接続先やルールを変更すると、問題の切り分けが難しくなります。

オンデマンド接続などの自動復帰機能を有効にしていると、手動で停止してもシステムのルールによって再接続される場合があります。一時的に無効にする際は、メインスイッチを繰り返し操作するのではなく、クライアントの自動接続設定とシステムのVPN状態を両方確認してください。自動接続は実際のネットワーク利用状況に合わせて設定しましょう。見知らぬネットワークへの接続、職場のリソースへのアクセス、ローカル機器のトラブル対応では、常に接続中と表示されることより、トンネルがいつ起動するか把握できることが重要です。

デバイスを交換する際、サブスクリプションや必要なルールは移行できますが、システムの許可、自動接続の動作、ローカルネットワークの権限は改めて確認が必要です。クラウド同期を行う前に、同期対象を確認してください。ログ、キー、ローカル設定がすべて移行されるとは限りません。古い端末を使わなくなったら、不要なサブスクリプションのコピーを削除しましょう。URLが漏えいした疑いがある場合は、クライアントの記録を消すだけでなく、サブスクリプションの提供元で認証情報を更新してください。

画面ロック後にだけ問題が起きる場合は、ロック解除後の新しいリクエストと、ロック中のプッシュ通知を分けてテストしてください。使われるシステムの仕組みが異なることがあります。ネットワークの種類、電波の切り替わり、復旧に再接続が必要かどうかを記録すると、OSの動作、ネットワークの切り替え、アプリ固有の挙動を見分けやすくなります。バックグラウンドで起きる問題を、すべて接続先の不具合と決めつけないでください。

Linux：GUIクライアントとコアの実行

ディストリビューションに合ったパッケージを選ぶ

デスクトップ環境ではLinuxのダウンロード欄からClash Verge RevまたはFlClashを選択できます。Clash Verge Revをこのプラットフォームのおすすめとして案内しています。ディストリビューション情報とアーキテクチャを確認し、パッケージ形式を選びましょう。DebianやUbuntu系では通常deb、Fedoraなどでは通常rpmを使いますが、実際にはダウンロードページにあるパッケージに従ってください。AMD64向けのパッケージをARM64の端末にインストールしたり、コアの圧縮ファイルをメニュー、サブスクリプション編集機能、システムトレイを備えたデスクトップアプリと取り違えたりしないでください。

cat /etc/os-release
uname -m

システムのソフトウェアインストーラーまたはディストリビューションのパッケージマネージャーでローカルパッケージをインストールし、依存関係の処理内容を確認してください。GUIが開かない場合は、ターミナルからインストール済みのクライアントを起動してエラーを確認します。グラフィックライブラリの不足、ディスプレイセッションの問題、コア設定のエラーを切り分けましょう。Wayland、X11、デスクトップ環境によってシステムトレイの対応状況は異なります。トレイにアイコンが表示されないからといって、プログラムが動作していないとは限りません。まずウインドウとプロセスを確認し、必要に応じてデスクトップ環境を調整してください。

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

GUIクライアントにサブスクリプションを追加して設定を有効にし、プロキシグループの接続先を選択します。基本的な流れは他のデスクトップOSと同様です。デスクトップ環境やアプリを問わず共通のシステムプロキシ設定はありません。GNOMEとKDEでは設定方法が異なり、ターミナルのプログラムがデスクトップのプロキシを参照するとも限りません。まずプロキシを明示したコマンドでコアのポートを確認し、成功したら現在のデスクトップ環境を設定してください。デスクトップのプロキシ、シェル環境変数、パッケージマネージャーの設定を同時に変え、Webページの表示だけでどれが有効か判断するのは避けましょう。

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

# 現在のシェルと、そこから起動する子プロセスにのみ適用
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

ここで使うHTTPS用のプロキシ変数にもHTTPプロキシの入口を指定します。ツールがその入口を経由してトンネルを作るという意味であり、ローカルポートでHTTPSサービスを動かすという意味ではありません。ツールによって変数名の大文字・小文字や設定の優先順位が異なる場合があるため、各ツールのドキュメントを確認してください。テスト後は unset http_proxy https_proxy no_proxy で今回の設定を解除できます。シェルの起動ファイルに書き込む前に、この端末でローカルプロキシを常時使う必要があるか確認しましょう。クライアントを停止した後、ターミナルからも接続できなくなることがあります。

TUN、権限、名前解決サービス

LinuxのTUNは通常、/dev/net/tunとネットワーク管理権限を必要とします。GUIクライアントを使う場合は、クライアントに用意されたサービスのインストール手順を優先し、手軽だからという理由でユーザーセッション全体を昇格させないでください。コンテナや制限付きのホストには、必要なデバイスや機能がない場合があります。管理者として起動してもインターフェースを作成できるとは限りません。まず実行環境が通信制御に対応しているか確認し、その後で設定項目を調べましょう。コンテナで問題が起きた場合は、ホスト、コンテナネットワーク、アプリそれぞれのルートを分けて確認してください。

自動ルートを有効にしたら、既存のVPN、仮想マシンのネットワーク、コンテナブリッジとの競合がないか確認します。DNSをNetworkManagerやsystemd-resolvedが管理している場合もあります。名前解決の設定ファイルを直接上書きすると、システムによって元に戻されたり、現在のネットワークを損なったりすることがあります。システムが実際に使っている名前解決の経路を調べ、クライアントに制御させるリクエストを決めてください。TUNのDNSハイジャックが処理できるのは、該当する経路を通る通信だけです。アプリ独自の暗号化DNSは別途確認が必要です。

ip route
ip rule
resolvectl status
ss -lntp

ディストリビューションによってはresolvectlがインストールされていません。コマンドが見つからなくても、DNSの障害とは限りません。そのディストリビューションで実際に使われているネットワーク管理ツールを利用してください。ルートの出力ではデフォルトの出口、ポリシールーティング、重複した仮想インターフェースを確認します。待ち受け状態の出力ではループバックアドレスと全インターフェースを区別してください。内部ネットワークやインターフェースのアドレス、組織のネットワーク情報が含まれる場合があるため、出力全体をそのまま公開しないでください。

サーバーでmihomoを使う際の注意点

サーバー、ルーター、GUIを必要としない環境では、ダウンロードページのmihomoコア欄から選べます。インストール前にOS、プロセッサアーキテクチャ、バイナリの対応範囲を確認してください。完全な設定を用意し、構文をテストした後、フォアグラウンドで起動してログを確認します。以下のコマンドは、コアがコマンド検索パスにインストール済みで、指定したパスに有効な設定ファイルがあることを前提としています。ノードやプロキシグループを作成するコマンドではありません。

mihomo -t -f "$HOME/.config/mihomo/config.yaml"
mihomo -f "$HOME/.config/mihomo/config.yaml"

サービスを常時稼働させる場合は、設定ファイルの読み取り権限を必要な範囲に限定し、一般ユーザーがサブスクリプションの認証情報を閲覧できないようにしてください。ログは必要な量だけ保存し、トラブル対応後は通常のレベルに戻します。LANにプロキシを公開する場合は、必要な待ち受けアドレスとファイアウォールの接続元だけを許可してください。プロキシポートやコントロールインターフェースをインターネットに直接公開しないでください。アンインストールや停止の際は、対応するサービス、プロキシ環境変数、残留ルートを整理し、通常のネットワーク接続が復旧したことを確認しましょう。

よくある設定の問題：リクエストの経路に沿って確認する

設定を読み込めない：まずダウンロードと解析を確認する

エラーが出たら、まず全文と発生時刻を記録し、サブスクリプションの取得失敗と設定の解析失敗を区別します。前者はURLの期限切れ、サーバーへの接続不可、未認証のネットワークなどが原因です。後者はインデント、フィールドの型、プロトコルの対応状況、参照先の名前などが関係します。YAMLではインデントにスペースを使い、リストの階層と文字列の型を正しく記述してください。エラー箇所が特定の行に表示されても、前の行にコロンや引用符の不足がないか確認します。指摘された行だけを削除するのは避けましょう。

インポート後にノードが表示されない場合は、取得した内容がプロキシ一覧だけではないか、サブスクリプションの取得先がログインページにリダイレクトされていないか確認してください。ノードはあるのにプロキシグループでエラーが出る場合は、グループが参照する名前が正しいか、サブスクリプションプロバイダーからのダウンロードが成功したかを確認します。ルールセットによっては、別途リソースの取得が必要です。メイン設定が読み込めても、すべての外部ファイルが利用可能とは限りません。更新後に問題が起きた場合は、まずバックアップに戻して変更箇所を比較します。利用できる設定の唯一のコピーを上書きし続けないでください。

接続履歴がない：通信の入口を確認する

対象アプリから新しいリクエストを送っているのにクライアントに記録がまったくない場合は、接続先ではなく通信制御を確認してください。システムプロキシではアドレスとポート、TUNではサービスの権限とルート、モバイル端末ではVPNの許可とアプリごとの対象リストを確認します。アプリが既存の接続を再利用していることもあるため、設定変更後は対象アプリを再起動するか、新しいリクエストを送ってから観察してください。接続画面の表示フィルターも確認しましょう。特定の接続だけが表示されているのに、すべての通信が取り込まれていないと判断しないでください。

端末のブラウザーでは接続できるのにターミナルではできない場合は、プロキシを明示してテストしてください。他の端末から共有プロキシへ接続できない場合は、LANからの接続許可、待ち受けアドレス、ファイアウォールを確認します。ループバックアドレスが使えるのは同じ端末内だけです。他の端末からは、プロキシを動かしている端末のLANアドレスに接続してください。自身の127.0.0.1を指定しても接続できません。外部コントロールポートは混合ポートの代わりになりません。認証を設定した場合は、接続するツールにも対応する認証情報を入力してください。

接続履歴はあるが結果がおかしい：モードとルールを確認する

ルールは上から順に適用されます。先にある範囲の広いルールが、後の詳細なルールに優先することがあります。プロキシグループに一致した後は、グループで現在選択している接続先も確認してください。プロキシらしい名前のグループでも、直接接続が選択されている場合があります。グローバルモードは通常の振り分けを迂回するため、短時間の比較には使えますが、ルールの修正代わりに常用しないでください。基本ネットワークの確認には直接接続モードが役立ちます。モードを変更した後に作成した新しい接続で動作を確認してください。既存の接続は変更前の経路を使い続ける場合があります。

以下はルールの順序を示す抜粋です。PROXYは既存のプロキシグループ名に置き換えてください。完全な設定ではないため、サブスクリプション全体をそのまま置き換える用途には使えません。ドメインルールが適用されるかどうかは、コアが接続先のドメイン名を把握できるかにも左右されます。アプリがIPアドレスに直接接続している場合、ドメイン末尾のルールに必ず一致するとは限りません。

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

タイムアウト、名前解決の失敗、プロトコルの違い

タイムアウトは、名前解決、リモートへの接続、プロトコルのハンドシェイク、接続先からの応答のいずれでも発生します。同じ接続先、同じネットワーク、同じプロキシグループで再現できるテストを行い、一度に変更する条件は1つにしてください。特定の接続先だけ失敗し、他は正常な場合は、まずその接続先を確認します。特定のネットワークですべての接続先が失敗する場合は、ネットワークの制限と名前解決の経路を調べましょう。速度テストの結果は接続先を選ぶ参考にすぎず、すべてのプロトコル、Webサイト、時間帯での動作を保証するものではありません。

確認された症状まず確認する項目次に行う比較
プロキシの接続先が接続を拒否するコアの動作、ポートの待ち受け、アドレスが正しいかプロキシを明示したリクエストと待ち受け一覧
ドメイン名を使うリクエストだけ失敗する名前解決サービス、DNSの経路、ドメインルールログに名前解決エラーがないか確認
Webページは開けるが音声通話が失敗するUDPの対応、アプリの通信制御、接続先の機能対象アプリの新しい接続履歴
更新後、直接接続に戻る現在の設定、上書きのマージ、プロキシグループの選択バックアップ設定と項目ごとに比較する

Webページでは主にTCPが使われますが、音声通話や一部のゲームではUDPが必要になることがあります。ノードのプロトコル、サーバー、クライアント設定が必要な通信方式に対応しているか確認してください。HTTPSのページが開けても、UDPが使えるとは限りません。システム時刻が大きくずれていると、暗号化接続の検証に失敗することがあります。まず信頼できる時刻同期を有効にしてください。DNSを変更しても古いキャッシュがテストに影響する場合があります。まず新しい接続を作成し、必要な場合はOSの方法でキャッシュを更新してください。ネットワーク設定を一括で消去するのは避けましょう。

更新、上書き、復元用の記録

サブスクリプションの自動更新はリモート設定を最新に保つのに便利ですが、提供元の推奨に合わせて頻度を設定してください。頻繁に更新する必要はありません。更新のたびに個別ルールが消える場合は、クライアントが対応する上書き機能に移し、マージ順序を確認します。設定を末尾に追加するものもあれば、一覧全体を置き換えるものもあります。保存した元ファイルが、必ずしもコアの実行設定と同じとは限りません。クライアントの実行設定表示またはログで、最終的な内容を確認してください。

トラブル対応が終わったら、ログを通常のレベルに戻し、一時的なグローバルモードと不要になったLANの待ち受けを無効にして、現在の設定をバックアップしてください。操作手順を最初から確認したい場合は使い方ガイドへ戻ってください。用語の意味だけを知りたい場合は用語集が便利です。インストールの問題は該当するプラットフォームの章で、接続の問題はリクエストの経路を順に確認します。毎回、最初からアンインストールして再インストールする必要はありません。