INSTALLATION / CONFIGURATION

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

プラットフォーム別にインストール、サブスクリプションの追加、通信の取り込み方法を確認できます。まず接続できる状態にしてから、ルールとDNSを調整しましょう。

初めて使う場合は、まず利用ガイドのクイックスタートに沿って接続を完了してください。このページでは、アーキテクチャの選び方、権限の範囲、設定例、元に戻す方法をまとめて確認できます。特定のプラットフォームで問題が起きた場合は、目次から該当する章に進んでください。

  • クライアントとコア
  • サブスクリプションとローカル設定
  • システムプロキシ / TUN

01 / BEFORE INSTALLATION

共通の準備：クライアント、サブスクリプション、通信の取り込み方法

まずクライアントとコアの役割を確認

Clashのエコシステムには、GUIクライアントと、実際の通信を中継するコアがあります。クライアントはサブスクリプション、トレイ、権限、設定画面を管理し、コアは設定を読み込んで接続を処理します。画面が似ていても、対応する設定項目が同じとは限りません。特に、旧Clashの設定とmihomo独自の設定には違いがあります。クライアントを選ぶ際は、まず対応プラットフォームを確認し、次にサブスクリプションで使うプロトコルとコアの対応範囲を照合してください。本ガイドでは、対応プラットフォーム向けにClash Plusを優先して紹介します。別の画面やデスクトップ管理機能が必要な場合は、ダウンロードページからClash Verge Rev、FlClashなどを選べます。

操作を始める前に、OS、プロセッサアーキテクチャ、インストール権限を確認してください。デスクトップでは通常x64とARM64を区別します。Apple Silicon用とIntel用のインストーラーは、ファイル名にmacOSとあるだけでは判断できません。AndroidでもARM64と旧世代のARMアーキテクチャが分かれる場合があります。インストールできても、バックグラウンドサービスや仮想ネットワークアダプターに別途許可が必要なことがあります。会社支給端末でドライバー、ネットワーク拡張、管理者権限が制限されている場合は、端末管理のルールに従ってください。組織のポリシーを回避するためにシステム保護を無効化しないでください。

サブスクリプションを準備し、元に戻せる設定を残す

クライアント自体に、すぐ使えるリモートプロキシの接続先は含まれていません。利用権限のあるサブスクリプションURL、個別の接続情報、またはローカル設定ファイルを用意し、選択したクライアントに対応する形式か確認してください。サブスクリプションURLには認証情報が含まれる場合があるため、公開スクリーンショットやログ、オンライン変換サイトに貼り付けないでください。インポート前に、従来のクライアントで使っていたモード、ポリシーグループ、自作ルールを控えておくと移行しやすくなります。ただし、互換性のないデータベースやパスを引き継がないよう、新しいクライアントのデータディレクトリを丸ごと上書きしないでください。

リモートサブスクリプションと、最終的に有効になる設定は別のものです。サブスクリプションを更新すると内容が再取得されるため、本文に直接加えたポートやルールの変更は上書きされることがあります。継続して使う変更は、クライアントのオーバーライド、マージ、拡張設定の機能に保存してください。リストのマージ方法はクライアントごとに異なるため、特にルールの順序やポリシーグループが丸ごと置き換わっていないか確認が必要です。初回インポートでは元の設定を保ち、動作を確認してからローカルコピーを保存しましょう。その後は一度に一種類の設定だけを変更してください。

ルールモードと通信の入口を区別する

ルール、グローバル、ダイレクトは、通信がコアに入った後の処理モードです。システムプロキシとTUNは、通信をコアに取り込む方法です。ルールモードを有効にしても、すべてのアプリが自動的にプロキシを使うわけではありません。TUNを有効にしても、すべての通信がリモートへ送られるわけではありません。システムプロキシは、OSのプロキシ設定に従うブラウザーやデスクトップアプリに適しています。TUNは仮想ネットワークインターフェースを通じてより多くの通信を取り込み、ルーティング、DNS、権限にも関係します。最初のトラブルシューティングでは、まず簡単な入口を使い、複数のクライアントや通信取り込み機能を同時に有効にしないようにしてください。

入口対象確認ポイント
システムプロキシOSの設定に従うアプリプロキシのアドレスとポート、アプリ独自の設定
明示的なHTTP / SOCKSプロキシプロキシを手動指定できるツールプロトコルの種類と待ち受けアドレス
TUN / プラットフォームVPNインターフェース仮想インターフェースで取り込む通信権限、ルーティング、DNS、除外範囲

以下はmihomoの基本項目の例です。リモートプロキシは含まれていないため、完全なサブスクリプションの代わりにはなりません。混合ポートはHTTPとSOCKSの両方を受け付けます。ループバックアドレスへのバインドは、同じ端末からのアクセスに限定されます。クライアントが待ち受けポートやDNSを管理する場合は、最終的に生成された設定を確認してください。同じ名前の項目を複数のオーバーライドに分散させないでください。YAMLのインデントにはスペースを使い、同じ階層に同じキーを重複させないようにします。編集後はクライアントの設定チェックを実行してから、コアを再読み込みしてください。

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

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

動作確認は段階的に行います。コアが起動していること、設定が読み込まれていること、ポリシーグループに選択肢があることを確認し、目的のサイトにアクセスして接続ログの適用ルールを調べます。疎通テストでわかるのは、特定のテスト先への結果だけです。すべてのサイト、UDP、ログイン機能が使えることを示すものではありません。テスト時のネットワーク環境とエラー発生時刻を記録しておくと、設定変更、リモート側の障害、ローカルネットワークの変化を切り分けやすくなります。まず接続だけ済ませたい場合は、利用ガイドに戻り、手順に沿って進めてください。

02 / WINDOWS

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

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

システム設定の「システム情報」でシステムの種類を確認し、Windowsインストーラーから対応するアーキテクチャのファイルを選んでください。まずはClash Plusを検討し、使い方に応じてClash Verge Rev、FlClash、Clash Nyanpasuを選ぶこともできます。Clash for Windowsは開発が終了しています。アーカイブ版は主に旧環境との互換性や移行向けで、新規インストールの標準選択肢には適しません。クライアントのダウンロードとコアのプロトコル互換性は別の問題です。旧設定を読み込めない場合は、画面を何度も再インストールするのではなく、まずコアの対応状況を確認してください。

インストーラーを実行する際は、ファイルの入手元とシステムの警告を確認してください。インストール先とユーザーデータの保存先は別の場合があり、アンインストーラーでサブスクリプション、ログ、サービスまで削除されるとは限りません。初回起動時に画面が表示されない場合は、まずトレイにすでに起動中のインスタンスがないか確認し、次にタスクマネージャーとクライアントのログを調べます。起動ボタンを連続して押したり、データディレクトリをそのまま削除したりしないでください。別のクライアントを使っていた場合は、システムプロキシ、自動起動、バックグラウンドサービスを停止してから終了し、インストール後に複数の自動通信取り込み設定が残らないようにします。

サブスクリプションを追加し、実際に読み込まれたか確認する

サブスクリプションまたは設定の管理画面からURLでのインポートを選び、完全なアドレスを貼り付けて保存し、更新を実行します。続いて、その設定を現在使用する項目に指定し、ログで読み込みが完了したか確認してください。リストにサブスクリプション名が表示されても、コアが設定を採用したとは限りません。プロキシ画面でポリシーグループとそのメンバーも確認しましょう。インポートに失敗した場合は、ダウンロードの失敗と解析の失敗を切り分けます。前者ではURL、ネットワーク、サーバーの応答を確認し、後者では取得した内容が対応する設定形式か確認してください。ログインページやエラーページを読み込んでいる可能性もあります。

ルールモードに切り替えたら、主要な選択グループで利用可能なメンバーを指定します。初回接続時は、自作ルール、スクリプト、DNSのオーバーライドを同時に追加しないでください。まず目的のページを開き、接続ログで対象ドメイン、適用ルール、最終的な出力先を確認します。特定のアプリだけ失敗する場合は、独自のプロキシ設定、組み込みのセキュアDNS、既存の接続がないか調べてください。設定の保存やポリシーグループの切り替え後も、既存の長時間接続が以前の出口を使い続けることがあります。該当する接続を閉じるか、アプリを再起動してから確認してください。

まずシステムプロキシを確認し、その後TUNを使うか判断する

システムプロキシを有効にしたら、Windowsのプロキシ設定でローカルアドレスと待ち受けポートを確認します。クライアントに表示されるポートが例と異なる場合は、テストコマンドも同じ値に変更してください。ブラウザーは使えるのにターミナルツールが失敗する場合、ツールがシステムプロキシを参照していないことがよくあります。まずHTTPプロキシを明示的に指定して確認してください。以下のコマンドは例示サイトへのアクセスを試し、ローカルポートがリクエストを受け付けるか確認するものです。実際に使う接続先でも試してください。一度の応答だけですべての通信が使えると判断しないでください。

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

TUNはシステムプロキシ設定に従わないアプリに適していますが、クライアント側の対応サービスと権限が必要です。まずクライアントの画面からサービスをインストールまたは起動してから、TUNを有効にしてください。具体的な項目名はクライアントによって異なります。画面を毎回管理者として起動する方法を、サービスの恒久的な代替手段として使わないでください。有効にしたら仮想ネットワークアダプター、コアのログ、接続記録を確認し、通信が実際にコアを通っているか確かめます。設定ミスでコアが停止し、ルートだけが残った場合は、まずTUNを無効にしてクライアントを正常終了し、ネットワークが復旧するか確認してください。

ポートの使用状況はPowerShellで確認できます。結果に待ち受け中のポートが表示された場合は、まずプロセスを確認してください。旧クライアントがバックグラウンドで動いているケースがよくあります。使用中だからといって、正体のわからないシステムプロセスを強制終了しないでください。ローカルポートを変更する場合は、システムプロキシとアプリの手動プロキシ設定もあわせて更新します。変更後はコアを再読み込みしてください。そうしないと、画面に保存された値と実際の待ち受けポートが一時的に異なることがあります。

Get-NetTCPConnection -LocalPort 7890 -State Listen -ErrorAction SilentlyContinue
netsh winhttp show proxy

2つ目のコマンドで確認するのはWinHTTPプロキシです。デスクトップユーザーのプロキシ設定とは別の仕組みです。一部のサービスや更新コンポーネントはWinHTTPを使うため、ブラウザーが正常でも、こうしたコンポーネントの設定が正しいとは限りません。特定のアプリのためにWinHTTP設定を一括で取り込んだりリセットしたりせず、まずそのアプリがどのプロキシ設定を参照するか確認してください。ネットワークが組織によって管理されている場合は、既存の企業プロキシや証明書の設定を残し、ほかのサービスに影響が出ないようにします。

スリープ、自動起動、終了後に残る設定への対処

自動起動で開始されるのはクライアントであり、サブスクリプションの読み込み、サービスの準備、TUNによる通信の取り込みまで完了するとは限りません。有効にしたら一度再起動し、スタートアップ項目があることだけでなく、トレイ、モード、ログも確認してください。スリープからの復帰後やネットワークの切り替え後に接続できなくなった場合は、まず既存の接続を閉じてからコアを再読み込みします。改善しない場合は、システムプロキシ、TUN、DNSの順に確認してください。クライアント終了後もブラウザーがプロキシに接続できないと表示する場合は、システムプロキシが停止中のローカルポートを指したままになっていないか確認します。起動直後にクラッシュする場合は、クライアントのクラッシュ対処手順も参照してください。

03 / MACOS

macOS：アーキテクチャの選択とネットワーク権限

チップに合ったクライアントを選び、アプリケーションにインストールする

「このMacについて」を開き、AppleシリコンかIntelプロセッサかを確認してから、macOSインストーラーで対応するファイルを選んでください。まずClash Plusを検討し、画面の好みに応じてClash Verge RevやFlClashを選ぶこともできます。ClashX Metaは開発が終了しており、既存環境との互換性を保つ場合に主に利用します。旧クライアントの設定ディレクトリを新しいクライアントのディレクトリへ丸ごとコピーしないでください。サブスクリプション、ルール、設定は分けて移行し、特に旧設定の絶対パスや使えなくなったスクリプトに注意しましょう。

ディスクイメージ形式のインストーラーは、アプリを「アプリケーション」フォルダにドラッグしてから、そのフォルダから起動してください。マウントしたイメージから長期間直接起動するのは避けます。初回起動時にシステムのセキュリティ警告が表示された場合は、入手元を確認し、システムが用意する正規の許可手順に従ってください。出所不明の一括隔離解除コマンドを使ったり、クライアントを動かすためにシステムの保護機能全体を無効にしたりしないでください。アプリを起動してもメインウィンドウが表示されない場合は、メニューバーのアイコンを確認します。メニューバー常駐アプリは、ウィンドウの表示と起動状態が一致しないことがあります。

サブスクリプションを追加し、設定とポリシーグループを確認する

設定管理画面でサブスクリプションURLまたはローカルのYAMLをインポートし、更新後に現在使用する設定として選択してください。続いてプロキシ画面で、選択グループと自動選択グループが生成されているか確認します。インポートした内容が接続情報のみで、完全なClash設定ではない場合は、クライアントに合ったインポート方法を使ってください。形式が異なるファイルをYAMLに名前変更しても解決しません。ポリシーグループ名はルール内の参照と一致させます。自作ルールをコピーした場合は、新しいサブスクリプションに存在しないグループ名が残っていないか特に確認してください。

初回の動作確認ではルールモードを使い、利用可能とわかっているメンバーを選んでから、アクセス時の接続記録を確認します。画面上の速度テストが成功してもサイトを開けない場合は、DNS解決、接続確立、TLSのどの段階で失敗しているかを調べてください。段階によって原因は異なるため、すべてを「回線が遅い」と決めつけるのは適切ではありません。自動選択グループのチェック間隔や許容値は切り替え頻度に影響しますが、無効なサブスクリプションやローカルのプロキシ設定ミスは解決しません。パラメーターの選び方は、ポリシーグループの種類と使い分けを参照してください。

システムプロキシはネットワークサービスごとに適用される

システムプロキシを有効にしたら、現在のネットワークサービスで使われているプロキシ設定を確認してください。macOSではWi-Fi、有線LANなどのネットワークサービスごとにプロキシ設定を保存できるため、接続インターフェースを切り替えると結果が異なる場合があります。以下では、まずサービス名を一覧表示し、次にWi-FiのHTTPプロキシとSOCKSプロキシを確認します。システム上のサービス名が異なる場合は、一覧に表示された実際の名前を使ってください。これらのコマンドは状態を読み取るだけで、ネットワーク設定は変更しません。

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

HTTP、HTTPS、SOCKSの各プロキシ設定は、クライアントが提供する入口に合わせてください。クライアントに混合ポートがあれば、複数のプロキシプロトコルで同じポートを使えますが、実際の設定を確認する必要があります。ターミナルツールはシステムのネットワークプロキシを参照しない場合があります。その場合は、ツール独自のプロキシオプションを使うか、現在のターミナルセッションでプロキシ環境変数を設定してください。一時的なテスト設定をすべてのシェルの起動ファイルに書き込まないでください。クライアント終了後も、新しいターミナルが停止したローカルポートへ接続し続けることになります。

TUN、バックグラウンド補助サービス、ほかのネットワークツール

デスクトップクライアントでTUNを有効にする際は、クライアントの実装に応じて特権補助サービスのインストール、ネットワーク拡張の許可、バックグラウンドコンポーネントの起動が必要になることがあります。許可の要求内容が、実行中の操作と合っているか確認してください。許可後にコアを再読み込みし、ログで仮想インターフェースとルートの状態を確認します。画面上でTUNスイッチがオンになっただけでは、通信の取り込みに成功したとは限りません。システムプロキシに従わないアプリをひとつ使い、その接続がログに記録されるか確認してください。

端末で企業VPN、コンテンツフィルター、ほかの仮想ネットワークツールを同時に使うと、デフォルトルートやDNSの割り当てが互いに影響することがあります。調査では、停止できるコンポーネントを一度にひとつだけ無効にし、結果を記録してください。組織で利用が義務付けられているソフトを勝手にアンインストールしてはいけません。TUNを有効にした後、LANプリンター、共有フォルダ、開発用サービスにアクセスできなくなった場合は、まずアドレス範囲とルートを確認し、必要に応じて対象を絞ったダイレクトルールを追加します。社内ドメインをすべてプロキシ経由にしたり、DNS機能をすべて無効にして原因を覆い隠したりしないでください。

スリープからの復帰後やWi-Fiの切り替え後は、古いTCP接続やDNSキャッシュに以前のネットワーク情報が残ることがあります。まず対象アプリの接続を閉じてから、クライアントの設定を再読み込みしてください。システムプロキシが有効なままコアが起動していない場合は、クライアントを通常どおり起動するか、該当するプロキシを無効にしてから接続を確認します。アンインストール前にシステムプロキシとTUNを無効にし、補助サービスはクライアントが提供する手順で処理してください。アプリをゴミ箱に移すだけでは、バックグラウンドコンポーネントや現在のネットワーク設定が残ることがあります。

04 / ANDROID

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

アーキテクチャを選び、旧設定を残す

Androidインストーラーでは、まずClash Plusを検討してください。設定の互換性や操作感に応じて、Clash Meta for Android、FlClash、Surfboardも選べます。比較的新しい端末の多くはARM64ですが、機種の新旧だけでアーキテクチャを推測せず、システム情報や端末の仕様を確認してください。Surfboardの設定方式はClash YAMLとは異なります。同じ提供元のサービスを読み込めても、設定全体をそのまま流用できるとは限りません。インストール前に、サブスクリプションの形式とクライアント側のインポート方法を確認しましょう。

APKをインストールする場合は、実際にAPKを開くファイルマネージャーまたはブラウザーに限って、必要なインストール権限を許可してください。インストール後、必要に応じて権限を取り消せます。署名の競合が表示される場合、インストール済みアプリと新しいファイルの署名が異なる可能性があります。すぐに旧アプリをアンインストールせず、まずサブスクリプション、設定、自作ルールをエクスポートして復元できることを確認してください。上書きインストールならデータが残ることが多い一方、アンインストールすると内部ストレージの設定も削除される場合があります。外部ファイルが残っていても、アプリの設定まで自動で復元されるとは限りません。

サブスクリプションを追加し、プラットフォームVPNを起動する

サブスクリプションまたは設定の画面でURLからインポートし、更新後にその設定を現在使用する項目にします。主要なポリシーグループが存在することを確認し、利用可能なメンバーを選んでから接続を開始してください。Androidクライアントは通常、プラットフォームのVPNインターフェースを使ってローカルの仮想ネットワークを構築します。初回起動時にはシステムの許可画面が表示されます。この許可は、対象となる通信をアプリが取り込むことを認めるものであり、リモートプロキシが使えることを示すものではありません。許可後もコアの状態、ポリシーグループ、実際のアクセス結果を確認してください。

AndroidのVPNインターフェースは、デスクトップの「システムプロキシ」スイッチと同じ仕組みではありません。画面に起動ボタンしかなく、TUNという独立した項目がない場合もあります。デスクトップと同じ名前の設定を探す必要はありません。通常、同じユーザーまたはプロファイル内では、同時に有効にできるVPNはひとつです。そのため、別のVPN、一部のファイアウォール、ローカルVPNを使うフィルタリングツールが競合することがあります。接続前に現在有効なサービスを確認し、複数のツールを繰り返し起動して、接続が成立してもすぐ置き換わる状態にならないようにしてください。

アプリごとの対象範囲とDNSの動作を確認する

ブラウザーだけが接続できる場合は、アプリごとのプロキシ設定を確認してください。許可リストは通常、選択したアプリだけを通信の取り込み対象にします。除外リストは、選択したアプリをプロキシ経由にしない設定です。両者の意味は逆になります。対象範囲を変更した後は、VPNを再接続しないと反映されない場合があります。仕事用プロファイルのアプリは別の環境にあるため、個人用の領域と同じ範囲で取り込まれるとは限りません。まず対象範囲をシンプルな状態に戻し、ひとつのアプリで確認してから除外項目を追加してください。リストの意味がわからないまま、すべてのアプリをまとめて選択しないでください。

以下はmihomo設定におけるドメインのダイレクト接続ルールの例です。このコアを使い、ルールのオーバーライドに対応するクライアントで利用できます。このルールが決めるのは、通信がコアに入った後の出力先です。Androidがアプリの通信をクライアントに渡すかどうかは決めません。既存のルール一覧に統合し、先に一致するフォールバックルールより前に配置してください。この部分だけでサブスクリプション全体を置き換えないでください。また、Surfboardの設定画面にClash YAMLを直接貼り付けないでください。

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

AndroidのプライベートDNS、ブラウザーのセキュアDNS、クライアントのDNSが同時に名前解決の経路へ影響することがあります。Webページに問題がある場合は、まずプライベートDNSの元の設定を記録し、一時的に条件を変えて比較してから調整してください。Fake-IPを有効にすれば、すべてのアプリが同じリゾルバーを使うとは限りません。アプリ独自の名前解決や接続方式が使われている場合は、接続ログも確認します。LAN内のドメインを開けない場合は、リモート側のポリシーグループだけを変更するのではなく、現在のWi-Fiが提供するローカルDNSでその名前を解決できるかも確認してください。

バックグラウンド制限、ネットワーク切り替え、テザリング

画面ロック後に接続が止まる場合は、まずバッテリー最適化、バックグラウンド動作、メーカー独自の起動管理を確認してください。バックグラウンドでの動作を許可するために、すべての権限を与える必要はありません。ネットワークサービスの維持に必要な項目だけを有効にしてください。システムの「常時接続VPN」を有効にする場合は、「VPN未接続時に通信をブロック」の影響も理解しておきましょう。クライアントが起動していない、またはコアの読み込みに失敗した場合、ネットワーク全体が使えなくなる可能性があります。初期設定ではブロック機能を有効にせず、再起動、画面ロック、ネットワーク切り替えが正常に動くことを確認してから判断してください。

Wi-Fiからモバイルデータ通信に切り替えると、既存の接続を再確立する必要がある場合があります。まず設定を再読み込みするか、いったん切断してから再接続し、アクセス記録を比較してください。一度の切り替え中断をサブスクリプションの無効化と誤解しないようにしましょう。モバイルデータ通信だけ失敗する場合は、アプリのモバイルデータ使用がシステムで制限されていないか、現在のネットワークがリモート接続に影響していないか確認します。テザリングで接続する他の端末が、スマートフォンのVPNインターフェースを経由するとは限りません。スマートフォン本体で正常でも、共有先の通信が取り込まれている証明にはなりません。これはシステムの転送経路とクライアントの機能によるため、個別に確認してください。「LANを許可」を有効にするだけで共有が完了したと判断しないでください。

端末を移行する際は、サブスクリプションと必要なオーバーライド設定をエクスポートしてください。アプリのディレクトリ全体を端末間で使えるバックアップと見なさないでください。インポート後は、アプリのインストール状況、仕事用プロファイル、システム権限が変わる場合があるため、アプリごとのリストを再確認します。トラブルシューティング用のログを他人に渡す場合は、サブスクリプションURL、接続情報、不要なドメイン名を削除してください。クライアントが起動直後に終了する場合は、再インストールを検討する前に、クラッシュ対処記事の手順に沿って設定とデータを確認してください。

05 / IOS

iOS：Clash Plusのインポートと接続確認

ストアからインストールし、インポート方法を確認する

iOSではClash Plusを使います。App StoreのClash Plusページからインストールできます。製品情報は公式サイトのclashplus.ioで確認してください。サイト内のiOSダウンロードにも同じリンクを掲載しています。インストール後、アプリが正常に起動することを確認してからサブスクリプションを準備します。画面の項目名はクライアントの更新で変わることがあるため、設定、サブスクリプション、接続などの機能を目印にしてください。デスクトップとまったく同じメニュー名を探す必要はありません。

インポート前に、手元の情報が何かを確認してください。Web管理画面のURL、サブスクリプションURL、個別の接続情報、完全な設定ファイルはそれぞれ別のものです。リンクをコピーする際は、すべてのパラメーターを含め、チャットアプリによる途中切れや末尾の句読点の付加を避けてください。システムの共有メニューや別アプリからインポートする場合も、保存前に内容と名前を確認します。クリップボードのサブスクリプションには認証情報が含まれる場合があります。作業後に公開メモへ貼り付けたり、トラブル調査のためにURL全体を送ったりしないでください。

設定を有効にしてVPN接続を確立する

クライアントにサブスクリプションまたは設定を追加し、内容を取得してから現在使う項目として選び、利用可能なポリシーを確認します。インポートの成功は、通常、内容が保存されたことを示すだけです。設定を有効にし、接続を開始する必要があります。初回の通信取り込み時には、iOSからVPN構成の追加許可を求められるため、システムの案内に従って端末認証を完了してください。その後クライアントに戻って接続状態を確認し、対象アプリを開いてログを確認します。システムにVPN接続中と表示されても、トンネルセッションがあることを示すだけです。リモートの回線、特定のドメイン、個別のサービスが使えるとは限りません。

起動直後に停止する場合は、接続ボタンを何度も押すのではなく、まずクライアントのエラー情報とシステムのVPN状態を確認してください。設定の解析エラー、リモート側のパラメーター非互換、現在のネットワークで接続を確立できない、別のVPN設定が通信を取り込んでいるなど、原因はいくつか考えられます。現在の設定をコピーしてから、最小限の変更で確認してください。システムのVPN構成を削除すれば、次回クライアントが許可を再申請する場合がありますが、サブスクリプション内の無効な項目は修正されません。構成の削除を万能な解決方法として繰り返さないでください。

モバイルOSの通信取り込みとルールの範囲を理解する

iOSの通信取り込みは、プラットフォームが提供するネットワーク拡張機能に依存します。デスクトップ設定のHTTPシステムプロキシスイッチと同じものではありません。クライアントにルート、ルール、モードの選択肢がある場合は、実際に対応する方法で設定してください。ルールモードは対象ごとに出力先を分け、グローバルモードは処理対象の通信を選択したポリシーに送ります。グローバルモードでも、システムまたはクライアントが定める除外範囲が残る場合があります。すべてのシステムサービスが同じ経路を通るとは限りません。

初回の確認では、特定のポリシーメンバーを選択し、実際のアクセス先を使ってリクエストを試してから、ドメイン、ルール、最終的な出口を確認します。Webページは開けてもアプリにログインできない場合は、ログインAPI、認証コード、リソースのドメイン、UDPなどの接続要件をそれぞれ検討してください。サービスによってはアカウント状態やサーバー側の地域制限にも左右されます。ネットワークに接続できても、これらの条件が自動で変わるわけではありません。ブラウザーの結果だけを根拠にルール全体を何度も変えず、失敗したリクエストがクライアントに届いているか、期待したポリシーが適用されたかを確認してください。

確認結果優先して確認する項目次の手順
設定にポリシーが表示されないサブスクリプション形式とインポート結果内容を確認して再取得する
接続がすぐに停止する設定エラーとシステムの許可エラーを確認し、該当箇所だけ修正する
特定のアプリだけ失敗する適用ルールと実際のリクエスト既存の接続を閉じてから再確認する

サブスクリプションの更新、DNS、ネットワーク切り替え

サブスクリプションを更新すると、利用できるメンバーやポリシーの参照先が変わります。更新前にローカルの変更が上書きされるか確認してください。クライアントに独立したルールまたはオーバーライド機能がある場合は、継続して使う変更をその機能で管理します。インポートした内容を直接編集する方式しかない場合は、まずコピーを保存し、次回の更新後に差分を再確認してください。ポリシーグループが削除済みのメンバーを参照していると、画面に名前が残っていても接続できないことがあります。更新後は、現在の選択と実際のアクセス結果を最低一度確認し、更新日時だけで判断しないでください。

Wi-Fi、モバイル回線、公共のホットスポットでは、DNSやネットワーク接続の条件が異なります。ネットワークを切り替えた後は、既存の接続が使えなくなり、再接続が必要な場合があります。ホテルや空港などでWeb認証が必要な場合は、クライアントに接続する前にネットワークの案内に従ってログインしてください。認証を済ませないと、サブスクリプションの取得やリモート接続がキャプティブポータルに遮られることがあります。特定のネットワークで失敗が続く場合は、クライアントを切断した状態で基本的なWebページにアクセスできるか比較し、失敗した段階を記録します。ネットワークの認証問題をクライアントの設定破損と誤解しないようにしてください。

DNS設定はClash Plusが実際に対応する形式に合わせてください。他の章にあるmihomoの例は項目の意味を説明するためのもので、すべてのモバイルクライアントにそのまま貼り付けられるとは限りません。カスタムリゾルバー、システムのネットワーク設定、ブラウザーの機能が結果に影響することがあります。トラブルシューティングでは一度にひとつだけ変更してください。Fake-IPのマッピングや検出範囲を詳しく知りたい場合は、DNSの検査と漏えい防止設定を確認し、クライアントの機能に合わせて設定してください。

長期間使う場合は、設定を頻繁にすべて消去するのではなく、サブスクリプションの有効性と現在のポリシーを定期的に確認してください。別の端末に移行した場合は、システムのネットワーク権限を改めて許可する必要があります。サブスクリプションを復元しても、旧端末の接続状態までは復元されません。クライアントを削除する前に接続を切断し、システムのネットワークが正常に戻ったことを確認してください。トラブルシューティング用の情報は、必要な日時、エラーの種類、機密情報を除いた設定だけにとどめ、スクリーンショットにサブスクリプションURLや認証情報が映らないようにします。

06 / LINUX

Linux：デスクトップクライアントとコアの導入

デスクトップ環境ではディストリビューションに合ったパッケージを選ぶ

デスクトップでは、LinuxインストーラーからClash Verge RevまたはFlClashを選べます。ここではClash Verge Revをおすすめの選択肢として紹介します。まずシステム情報でディストリビューションとアーキテクチャを確認してください。Debian系やUbuntu系では通常DEB、RPM系のディストリビューションではパッケージ管理システムが対応する形式を使います。クライアントを入れるために、別のディストリビューションのパッケージ管理ツールを混在させないでください。GUIアプリにはデスクトップコンポーネントやシステムライブラリが必要な場合もあり、パッケージを展開できても、すべてのディストリビューションで実行できるとは限りません。

実際にダウンロードしたディレクトリでインストールを実行し、コマンド内のファイル名をダウンロード済みの正確な名前に置き換えてください。システムのパッケージ管理ツールでローカルパッケージをインストールすると、依存関係の処理や後からのアンインストールが容易になります。インストールに失敗した場合は、エラー全文を残し、アーキテクチャの不一致、依存関係の不足、権限の問題を切り分けてください。ディレクトリ全体に再帰的な書き込み権限を与えないでください。初回起動時は通常ユーザーとしてGUIを実行し、仮想ネットワークに必要な権限は、クライアントが対応するサービスの仕組みで処理してください。デスクトップアプリ全体をrootで実行するのを標準にしないでください。

サブスクリプションを追加し、デスクトップとターミナルのプロキシを区別する

クライアントにサブスクリプションをインポートして現在の設定として選択し、ポリシーグループと実行ログを確認してください。Linuxデスクトップ環境のシステムプロキシ設定は統一されていません。GNOME、KDE、個々のアプリで参照方法が異なることがあります。ブラウザーは使えるのにコマンドラインが失敗する場合は、まずツールにプロキシを明示して、待ち受けポートが使えるか確認してください。以下の例では、クライアントと同じポートを指定します。コマンドは現在のテストだけに使い、確認前にグローバルな環境設定ファイルやサービス設定へ書き込まないでください。

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

socks5hは、接続先ドメインの名前解決をSOCKSプロキシ側で行う指定です。ローカルでの名前解決と比較する際に役立ちます。これだけでシステム全体のDNSが変更されたわけではありません。プロキシ環境変数も、それを参照するプロセスにだけ適用されます。すでに起動しているデスクトップアプリやsystemdサービスには、新しいターミナルの設定は自動で引き継がれません。特定のアプリで長期的に使う場合は、まずそのアプリ独自のプロキシ設定を確認し、元に戻す方法も記録してください。クライアント停止後も、システム更新やバックグラウンド処理が停止したローカルポートへ接続し続ける事態を防げます。

TUN、ルーティング、ローカルDNSサービス

TUNによる通信の取り込みには、必要な権限とシステムのネットワーク機能が必要です。有効にする前に、通常のプロキシ経路が動作することを確認してください。以下はmihomoのTUN設定例です。有効なプロキシとルールを含む完全な設定に統合して使用します。クライアントがこれらの項目を独自に管理している場合もあり、重複して上書きすると動作を判断しにくくなります。自動ルーティングを有効にしても、既存のVPN、コンテナネットワーク、ポリシールーティングを無視できるわけではありません。有効にした後は実際のルーティングテーブルを確認し、LANと外部への接続をそれぞれテストしてください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

DNSの横取りを使うには、完全な設定でコアのDNSを有効にする必要があります。すべての暗号化DNSやアプリ独自の名前解決まで自動的に対象になるわけではありません。systemd-resolvedを使うディストリビューションでは、ローカルのスタブを通じて名前解決する場合があります。システムの管理方式を理解せずに/etc/resolv.confを直接上書きしないでください。以下のコマンドでアドレス、ルート、名前解決の状態を確認できます。最後のコマンドは、対応するツールがあるシステムでのみ実行できます。ネットワーク切り替え後に問題が起きた場合は、TUN有効化の前後でデフォルトルートとDNSサーバーを比較し、具体的な差分に対処してください。

ip address show
ip route show
resolvectl status

サーバーやルーターではコアを独立したサービスとして管理する

デスクトップ環境のないサーバーやルーターでは、ダウンロードページのコア一覧からプロセッサと実行環境に合ったmihomoを選べます。この方法はサービス、権限、ネットワークルールを管理できるユーザー向けです。一般的なデスクトップ利用では、GUIを使わずに導入する必要はありません。設定用と書き込み可能なデータ用のディレクトリを分け、バイナリを管理されたパスに配置してから、まず設定をテストしてください。以下では、バイナリを指定の場所に置き、完全な設定を保存済みとします。テスト成功は、基本的な構文と参照先が正しいことを示すだけです。実際の接続も別途確認してください。

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

テストに成功したら、サービスマネージャーで実行し、作業ディレクトリ、起動引数、実行ユーザー、再起動ポリシーを明確に指定してください。一般的なHTTPやSOCKSの待ち受けにroot権限は通常不要です。TUNやルーティングの操作には追加の権限が必要になるため、導入方法に応じて最小限の権限を付与します。管理APIは標準でローカル端末に限定し、リモート管理には制御された経路を使ってください。制御ポートや認証のないプロキシポートをインターネットに直接公開しないでください。LANからの接続を許可する場合も、待ち受けアドレス、ファイアウォールの範囲、必要な認証をあわせて設定してください。

SSH経由でTUN、デフォルトルート、ファイアウォールを変更する前に、2つ目のセッションを確保し、帯域外またはローカルで復旧できる手段を用意してください。まず基本的なプロキシを起動し、その後ルーティングとDNSの取り込みを段階的に追加します。一度の変更でリモート接続を失わないようにしてください。コンテナ環境ではネットワーク名前空間、デバイス、権限の割り当ても関係するため、ホスト向けの設定をそのまま適用しないでください。アップグレード前に旧バイナリと設定のコピーを残し、新しいコアとの互換性をテストします。項目の移行については、mihomoとオリジナルClashの違いを参照してください。

07 / DIAGNOSTICS

設定に関するよくある質問：接続の段階ごとに切り分ける

サブスクリプションの更新失敗と設定の解析エラー

サブスクリプションの更新に失敗した場合は、まず取得の段階を確認してください。URLが完全か、システム時刻が正しいか、サービスが有効か、現在のネットワークからサブスクリプションの接続先へアクセスできるかを調べます。URLからログインページ、アクセス制限の案内、エラーテキストが返っている場合、後に表示される解析エラーはその結果にすぎません。YAMLのインデントを変更しても解決しません。更新にプロキシを使うかどうかはクライアントの実装によります。先に接続が必要な場合もあれば、古いプロキシの失効が更新を妨げる場合もあります。クライアントの更新時のネットワーク設定を確認し、条件を変えて比較してください。

内容をダウンロードできてもコアが読み込みを拒否する場合は、構文、項目、参照先を確認します。YAMLのインデントにはスペースを使い、リスト項目の位置をそろえてください。同じマッピング内のキーを重複させ、後の値で上書きする方法には頼らないでください。ルールが参照するポリシーグループと、ポリシーグループが参照するプロキシやプロキシセットは、すべて存在している必要があります。コアごとに対応するプロトコルや項目は異なります。拡張子をYAMLに変えても形式は変換されません。まず直近のオーバーライドを元に戻し、その後少しずつ再追加すると、設定をすべて削除するより原因を特定しやすくなります。

ポート、待ち受けアドレス、通信がコアに届いているか

アプリに接続拒否と表示された場合は、まずコアが起動しているか、ローカルポートが待ち受けているか、アプリのプロキシアドレスが一致しているか確認してください。127.0.0.1で待ち受けるサービスはローカル端末専用です。別の端末から、自分自身のループバックアドレスをこのコンピューターのアドレスとして使うことはできません。端末間で使うには、サーバー側のLANアドレス、許可する待ち受け範囲、ファイアウォールのルールを明示する必要があります。トラブル調査のためにすべてのインターフェースをそのまま公開しないでください。まずローカルでプロキシを明示してテストし、成功してから管理されたLANの範囲へ段階的に広げます。

目的のサイトにアクセスしても接続ログに変化がない場合は、出力先のポリシーを変更する前に入口を確認してください。アプリがシステムプロキシを無視している、独自の設定を使っている、モバイル端末で通信の取り込み対象外になっている可能性があります。ログに記録されていてもダイレクト接続になっている場合は、適用ルールと順序を確認します。想定したプロキシを経由しているのに失敗する場合は、リモートへの接続状況、認証、接続先サービスを調べてください。段階的に確認すれば、すべての問題を接続先の停止と決めつけずに済み、サブスクリプションの無用な再インポートも避けられます。

DNS、Fake-IP、ルールの順序

Fake-IPはドメインに予約アドレスを割り当て、その後の接続でもドメインを関連付けてルール判定できるようにします。この形式のアドレスが表示されても、DNSが壊れているとは限りません。ただし、実際の名前解決結果に依存するプログラムには、個別の例外設定が必要なことがあります。例外はできるだけ具体的なドメインに限定し、広い範囲を除外してドメインルールが想定どおり動かなくなるのを避けてください。イントラネットのドメインには、その名前を解決できるローカルDNSも必要です。通常、パブリックDNSは企業や家庭内ネットワークのプライベートな名前を解決できません。

ルールは上から順に評価されます。特定のサービス向けのルールは通常、範囲の広いルールより前に置き、フォールバック用のMATCHは最後に配置します。以下は完全な設定に追加する例で、組み込みのダイレクトポリシーを使うため、自作のグループ名に依存しません。示しているのは順序と構文だけで、実運用のルール一式ではありません。サブスクリプションに含まれるリモートプロキシと選択グループは残してください。変更後は再読み込みし、ファイルが保存されたかだけでなく、接続ログで実際に適用されたルールを確認します。

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
  - MATCH,DIRECT

DNS検査で表示されるリゾルバーの場所だけでは、通信が想定どおりの出口を通っているか判断できません。名前解決の経路、接続先、ルールのログをあわせて確認してください。ブラウザーのセキュアDNS、アプリ内蔵の名前解決、キャッシュも比較結果に影響します。詳しい設定はDNS漏えいの検査と防止策を参照してください。DNSの項目を増やせば信頼性が自動的に高まるわけではありません。各項目の役割を理解してから、一つずつテストしてください。

ポリシーの選択、接続の再利用、更新からの復元

自動選択グループは、テスト先と独自のロジックに基づいて経路を選びます。種類によって、遅延、可用性、負荷分散など重視する点が異なります。テストに成功しても特定のサービスが使えるとは限らず、失敗してもテスト先に到達できないだけの場合があります。まずメンバーを手動で選び、実際の接続先で確認してからテスト用のパラメーターを調整してください。ポリシーを切り替えた後も、既存の長時間接続が以前の出口を使い続ける場合があります。該当する接続を閉じるかアプリを再起動してから比較してください。そうしないと、切り替えが反映されていないと誤解することがあります。

クライアントやコアのアップグレード後に問題が起きた場合は、まずログと現在の設定を保存し、バックアップと比較してください。独自の拡張項目、旧パス、ルールセットのキャッシュ、権限の変更が起動に影響することがあります。バックアップがない状態で、アップグレード、データ消去、設定の書き換えを同時に行わないでください。どの操作が影響したか判断しにくくなります。旧クライアントからの移行は、Clash for Windowsのサポート終了後の代替と移行方法を参照してください。まずサブスクリプションとルールを移し、実行データ全体を直接コピーしないでください。

必要最小限のトラブル情報を記録し、復旧手順を残す

詳しい調査が必要な場合は、OSとアーキテクチャ、クライアント名、通信の取り込み方法、接続できない対象の種類、エラーの発生時刻を記録し、機密情報を除いた関連ログを添えてください。ログレベルを一時的に上げるのは再現時だけにし、完了後は通常のレベルに戻してアクセス記録が蓄積し続けないようにします。接続情報、サブスクリプションのパラメーター、管理インターフェースの認証情報を公開資料に含めないでください。復旧は有効化と逆の順序で行います。まず追加したルートやTUNを無効にし、次にプロキシとDNSを元に戻し、最後にクライアントが正常に終了したか確認します。各プラットフォームの手順はこのページの該当章を、基本操作はクイックスタートガイドを参照してください。