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

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

インストーラーのアーキテクチャ選びから通信の制御まで、プラットフォーム別の設定手順とトラブルシューティングを確認できます。

本ページは、導入前の確認やクライアントの移行、特定プラットフォームの問題解決に役立つリファレンスです。初めて利用し、接続まで順番に進めたい場合は、まずクイックスタートガイドをご覧ください。サブスクリプションを追加済みの場合は、該当するプラットフォームまたはページ末尾の設定ガイドへ進んでください。クライアントによってメニュー名は多少異なるため、以下では機能名を使って操作箇所を説明します。特定のクライアントの画面構成を共通仕様として扱うことはありません。

事前準備

共通の事前準備：クライアント、アーキテクチャ、設定の入手先

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

Clashのエコシステムは、GUIクライアント、ネットワーク処理を担うコア、プロキシやルールを記述する設定ファイルで構成されています。クライアントは設定のインポートや切り替え、ログ確認、権限管理を行い、コアは接続、ドメイン名の解決、ルールの照合を実行します。インストールできても、利用可能なプロキシ接続先があるとは限りません。サブスクリプションは通常、サービス提供元が発行するもので、クライアントのダウンロード先で提供されるわけではありません。始める前に、設定の入手先、有効期限、対応形式、複数端末での利用可否を確認してください。

GUIが必要な場合は、Windows、macOS、Android、iOSではClash Plusから検討するのがおすすめです。LinuxではClash Verge RevまたはFlClashを選べます。各製品のインストーラーはダウンロードセンターでプラットフォーム別に確認できます。製品名が似ていても、設定機能が完全に同じとは限りません。特に新しいプロトコル、ルール項目、スクリプト機能には注意が必要です。クライアントを切り替える際は、まず元の設定を保存し、移行先のコアがどの項目に対応しているか確認してください。拡張子だけで互換性を判断しないようにしましょう。

OSとCPUアーキテクチャを確認する

デスクトップでは、まずOSのバージョンとCPUの種類を確認します。Windowsでは「設定 → システム → バージョン情報」でシステムの種類を確認します。macOSではAppleメニューの「このMacについて」でチップを確認できます。Linuxでは下記のコマンドでアーキテクチャを調べられます。AndroidのインストーラーにはARM64、ARM、汎用版などがあり、インストールに失敗しても、ただちにファイル破損とは限りません。アーキテクチャが一致していても、クライアントの最低システム要件を確認してください。古いOSに必要な実行環境がなければ、同じアーキテクチャのインストーラーに替えても解決しません。

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

現在のネットワーク環境も記録しておきましょう。学校や職場のネットワークに接続しているか、先にWebページで認証が必要か、ほかのプロキシやVPNを使用しているかを確認します。ネットワーク認証が済んでいない場合は、通信の制御をいったん無効にして認証を完了してください。複数のクライアントでシステムプロキシや仮想NICを同時に有効にすると、接続先やルーティングが競合することがあります。初回設定では起動するクライアントを1つに絞り、その後も一度に変更する項目を1つにすると、結果が変わった原因を特定しやすくなります。

元に戻せる設定バックアップを作成する

リンクを追加する前に、信頼できる入手先のものか確認し、機密情報として扱ってください。リンクにはアカウント情報やアクセス用の認証情報が含まれる場合があります。公開スクリーンショットや共有ログ、オンライン変換サービスに載せないでください。ファイルからインポートする場合は、元のYAMLを別途保存します。クライアントで設定をエクスポートできる場合は、クライアント設定のバックアップも作成してください。サブスクリプションとクライアントのローカル設定は別々に保存されることが多いため、移行時にYAMLだけをコピーしても、自動起動、サービスモード、画面設定などは引き継がれない場合があります。

設定には判別しやすいローカル名を付け、追加方法、最後に更新が成功した日時、使用中のコアを記録しておきましょう。その後、混合ポート、通信モード、通信の制御方法を確認します。まずはシステムプロキシに従うブラウザーでアクセスできることを確かめてから、TUN、LAN共有、複雑なDNS設定を検討してください。基本の接続が確立する前にすべての機能を有効にすると、設定、権限、ネットワークの問題が混在して原因を特定しにくくなります。

確認項目	確認する内容
設定の入手先	リンクにアクセスでき、対象クライアントが対応する設定が返される
通信モード	まずはルールモードを使い、実際に適用されたプロキシグループを確認する
通信の制御方法	デスクトップではシステムプロキシを検証し、モバイル端末ではVPN権限を確認する
復旧手順	元のファイルを保管し、プロキシの無効化とクライアントの終了方法を把握する

インストール前に、システム時刻が正しいこと、ディスクに空き容量があること、ログの確認場所を把握していることも確認してください。証明書関連のエラーは時刻のずれが原因の場合があります。ポートの起動に失敗した場合は、ポートの競合を確認しましょう。初回インストール時の権限やよくあるエラーについては、プラットフォーム共通の初期設定チェックリストも参照してください。再インストールを繰り返す前に、エラーの内容と発生した段階を記録しておきましょう。

Windows

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

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

Windowsのダウンロードから、まずClash Plusを選んでください。画面や設定管理方法を比較したい場合は、Clash Verge Rev、FlClash、Clash Nyanpasuも確認できます。Clash for Windowsはすでにメンテナンスが終了したアーカイブ版のため、新しい端末での利用はおすすめしません。ダウンロード前にシステムの種類とインストーラーの要件を確認してください。すべてのWindows端末が同じCPUを搭載しているわけではありません。

インストールウィザードで保存先を選びます。初回起動後、メイン画面が開くこととコアが正常に動作することを確認してください。セキュリティソフトにブロックされた場合は、対象ファイル、入手先、ブロック理由を確認し、組織や端末のセキュリティポリシーに沿って対処しましょう。保護機能をすべて無効にするのは避けてください。ポータブル版とインストール版ではデータの保存先が異なる場合があります。移行前に、クライアントの「設定フォルダーを開く」などの機能で場所を確認し、別製品の保存先を参考にファイルを削除しないようにしてください。

サブスクリプションを追加し、設定を適用する

「設定」「サブスクリプション」などのページでリモート設定を追加し、ローカル名とサブスクリプションURLを入力して保存した後、更新を実行します。更新後は、その設定を選択して適用してください。リストに表示されただけでは、コアに読み込まれたとは限りません。プロキシまたはプロキシグループの画面で、想定した内容があることを確認しましょう。接続先がDIRECTしかない場合は、システムプロキシを何度も切り替えるのではなく、サブスクリプションの応答内容と解析ログを確認してください。

ローカルファイルは、インポート画面からYAMLを選択できます。読み込みに失敗したら、まずエラー行付近のインデント、項目名、プロキシグループ名を確認し、次にコアの対応状況を調べます。リモート設定にローカルの変更を加える場合は、クライアントの上書き・マージ機能を利用してください。キャッシュファイルを直接編集すると、次回の更新で上書きされることがあります。テスト前に現在の混合ポートを記録しておきましょう。よくある例は7890ですが、実際の接続ではクライアントが現在待ち受けているポートを使ってください。

まずシステムプロキシを確認し、その後TUNを有効にする

クライアントで「システムプロキシ」を有効にし、Windowsの「設定 → ネットワークとインターネット → プロキシ」でアドレスとポートを確認します。通常、ローカルのアドレスは127.0.0.1で、ポートはクライアントの設定と一致している必要があります。ブラウザーにプロキシ拡張機能を入れている場合は、どの設定が通信を制御するのか明確にし、拡張機能がシステム設定を上書きしないようにしてください。ルールモードでは、接続先にアクセスしてから接続ログで適用されたルールと出力先を確認します。スイッチがオンかどうかだけでは判断できません。

コマンドラインツールがシステムプロキシを使うとは限りません。下記の変数をPowerShellのセッション内で一時的に設定し、対象のツールをテストできます。これらの環境変数を利用するプログラムだけが設定を反映し、ツール独自のプロキシ指定が優先される場合もあります。ウィンドウを閉じると、このセッションでの設定は終了します。ユーザー環境またはシステム環境にも変数を設定した場合は、それぞれの設定画面で削除してください。一時セッションの結果だけで、端末全体の設定が元に戻ったと判断しないようにしましょう。

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# テスト後、このセッションの設定を解除する
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue

TUNは、システムプロキシに従わないプログラムの通信を制御する機能で、クライアントに適切な権限が必要です。「サービスモード」や「サービスをインストール」などの項目がある場合は、案内に従って設定してからTUNを有効にし、ログを確認してください。サービスのインストール、コアの起動、仮想NICの作成はそれぞれ別の段階です。サービスが正常でもTUNが失敗する場合は、ドライバー、権限、ルーティングを確認しましょう。サブスクリプションを再インポートしても解決しません。企業管理端末では仮想NICが制限される場合があるため、端末の管理ポリシーに従ってください。

スリープ復帰、ポート競合、終了後の設定

PCのスリープ復帰後やWi-Fiの切り替え後に接続がおかしくなったら、まず通信の制御を一時停止し、基本ネットワークが使えることを確認してから再度有効にします。ポートの競合は、Get-NetTCPConnection -LocalPort 7890で待ち受け状況を確認し、プロセス情報と照らし合わせて原因を特定できます。正体の分からないプロセスを強制終了しないでください。古いクライアントを終了するか、新しいクライアントのポートを変更し、そのポートを参照する箇所もすべて更新してください。

スタートアップ時の起動と自動接続は別の設定です。まず手動で接続を検証してから有効にしてください。ブラウザーは使えるのにターミナルから接続できない場合は、ブラウザーとターミナルを分けてトラブルシューティングを参照してください。特定のアプリだけ失敗する場合は、独自のプロキシ設定、特殊な通信プロトコル、アプリ側のネットワーク制限を確認しましょう。

macOS

macOS：チップのアーキテクチャ、ヘルパーサービス、ネットワーク設定

チップに合ったクライアントを選ぶ

「このMacについて」でAppleシリコンかIntelプロセッサかを確認し、macOSのダウンロードから対応するインストーラーを選んでください。まずはClash Plusがおすすめです。Clash Verge RevやFlClashも利用できます。ClashX Metaはメンテナンスが終了したアーカイブ版です。旧設定を移行する場合は、新しいコアとの項目の違いに特に注意してください。互換レイヤーを使ってもシステム要件の確認は必要です。通常、ネイティブアーキテクチャ向けのパッケージのほうが管理しやすくなります。

ディスクイメージ形式の場合は、開いた後にアプリを「アプリケーション」へ移動し、その場所から起動してください。イメージ内から直接起動し続けないようにしましょう。システムに開けないと表示された場合は、ダウンロード元と警告の内容を確認し、「プライバシーとセキュリティ」の案内に従って対処します。セキュリティ制限をすべて解除する方法を、一般的なインストール手順として扱わないでください。組織管理下のMacでは、バックグラウンド項目、ネットワーク拡張、管理者権限が制限されていることもあります。まず端末のポリシーを確認してください。

設定をインポートし、クライアントの設定を保管する

設定管理画面でリンクからリモートサブスクリプションを追加し、更新後に現在の設定として適用します。ログで読み込みの成功を確認してから、プロキシグループで出力先を選んでください。ファイルをインポートしても、メニューバーの動作、システムプロキシの制御、ヘルパーサービスの状態までは含まれない場合があります。旧クライアントから移行する場合は、元のファイルとローカル上書きをエクスポートしてから、新しいクライアントの設定を一つずつ行います。複数製品のバックグラウンドサービスを同時に復元しないようにしましょう。

リモートサブスクリプションの更新後にカスタムルールが消えた場合は、ルールがサブスクリプションのキャッシュ内にあるのか、別の上書き設定として保存されているのかを確認してください。更新時の扱いが異なります。編集前にクライアントのメニューから現在の設定フォルダーを開き、実際に有効なファイルを確認しましょう。「ダウンロード」フォルダーの元ファイルが、クライアントと常に同期しているとは限りません。設定を解析できても想定したプロキシグループがない場合は、アプリを再インストールするのではなく、サブスクリプションの種類と選択中の設定を確認してください。

現在のネットワークサービスのプロキシ設定を確認する

システムプロキシを有効にしたら、「システム設定 → ネットワーク」で使用中のWi-FiまたはEthernetサービスを選び、「詳細 → プロキシ」でアドレスを確認します。ネットワークサービスごとに設定が異なるため、Wi-Fiから有線接続に切り替えた場合は、改めて確認してください。クライアントがWebプロキシ、セキュアWebプロキシ、SOCKSプロキシを同時に設定することがあります。製品ごとに動作は異なりますが、重要なのはアドレスとポートが現在起動中のクライアントを指していることです。

下記のコマンドでシステムプロキシの状態を確認できますが、設定を読み取るだけであり、すべてのコマンドラインプログラムが自動的に利用するわけではありません。特定のHTTPリクエストを調べる場合は、ローカルプロキシを明示的に指定できます。例では予約済みのサンプルドメインを使っており、リクエスト経路の確認だけを目的としています。リクエストが成功しても、すべてのサイトやプロトコルが正常とは限りません。接続ログを確認し、リクエストが実際にコアへ届いていることを確かめてください。

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

「Webページは開くのに、コマンドラインでは失敗する」場合は、ツール独自のプロキシ設定、環境変数、ドメイン名の解決方法を確認します。SOCKSに対応し、プロキシ経由で名前解決する必要があるツールでは、ドキュメントに従って適切なモードを選んでください。HTTPプロキシのアドレスをすべてのプロトコル設定に入力してはいけません。証明書エラーも別に切り分け、システム時刻、証明書チェーン、ネットワークによる通信の遮断を確認しましょう。証明書の検証を無効にしたまま使うのは避けてください。

TUNの権限とネットワークの復旧

TUNを有効にする前に、クライアントの案内に従ってヘルパーサービスをインストールまたは許可してください。ヘルパーサービスは、追加権限が必要なシステム操作を実行するためのもので、GUIがすべてのネットワーク機能を自動的に使えるという意味ではありません。インストール成功と表示されたのにスイッチがすぐ戻る場合は、サービスログ、コアのログ、システムの権限状態を確認します。クライアントを切り替える際は、古いクライアントのTUNを先に停止してください。残ったルートと新しい通信制御が重なるのを防げます。

スリープからの復帰、ネットワークサービスの切り替え、ほかのVPNの起動・停止によってルーティングが変わることがあります。トラブルシューティングでは、まずTUNとシステムプロキシを無効にして直接接続を確認し、その後は通信制御の方法を1つだけ再度有効にしてください。直接接続できるのに有効化するとすべてのドメインで失敗する場合は、DNSとルーティングを確認します。特定の接続先だけ失敗する場合は、ルールと出力先を確認してください。最初からシステムネットワーク全体をリセットすると、業務ネットワークで必要な固定アドレスや認証設定まで失うおそれがあります。

ログイン時の自動起動は最後に設定し、バックグラウンド項目の実行が許可されていることを確認してください。OSのアップデート後に権限が変わった場合は、同じサブスクリプションを何度も追加するのではなく、権限の設定画面を再確認します。プラットフォーム側の設定に問題がなく解析エラーが続く場合は、設定とトラブルシューティングへ進み、ファイル、コア、ルールの順に原因を調べてください。

Android

Android：インストーラー、VPN権限、バックグラウンド動作

アーキテクチャを確認し、インストール制限に対処する

Androidのダウンロードからクライアントを選びます。まずはClash Plusがおすすめです。ほかにClash Meta for Android、FlClash、Surfboardがあります。製品によって対応するサブスクリプション形式やルール機能は異なります。あるクライアントの完全なYAMLを確認せずに別の製品へ読み込ませないでください。先に対応形式を確認し、端末のアーキテクチャに合ったパッケージを選びます。判断が難しい場合は、製品が汎用版を提供しているか確認してください。

外部からアプリをインストールする際、ブラウザーやファイル管理アプリにインストール権限を求められる場合があります。今回利用する入手元だけに権限を許可し、インストール後はシステム設定から取り消しても構いません。解析エラーが表示された場合は、システム要件、アーキテクチャ、ファイルのダウンロード状態、空き容量を順に確認してください。署名の競合は、既存アプリとの署名や配布元の違いが原因であることが多いです。アンインストールする前に設定とローカルデータをエクスポートしてください。

サブスクリプションを追加し、現在の設定に切り替える

「設定」または「サブスクリプション」画面でリンクを追加するか、ファイル選択画面からローカルのYAMLをインポートします。Androidのファイル選択画面では、選択したファイルの読み取り権限だけがクライアントに付与される場合があります。そのため、インポート後に元ファイルを変更しても、設定に反映されるとは限りません。保存したら一度手動で更新し、内容とプロキシグループを確認してから現在の設定として適用します。「インポート成功」は操作が完了したという意味にすぎないため、コアが読み込めているかも確認してください。

リモートリンクがWebページ、ログイン画面、または未対応形式を返すと、空の設定や解析エラーが発生することがあります。まずサブスクリプションの有効期限、クライアントに対応したURLの選択、システム時刻を確認してください。完全なリンクをチャットグループで公開しないでください。クライアントからログを共有する場合は、サブスクリプションURL、アカウント情報、ノードの認証情報を削除し、エラーの種類、関連項目、必要な前後関係だけを残します。

VPNインターフェースとアプリごとの通信制御を理解する

接続を開始すると、AndroidにVPN接続の要求が表示されます。クライアント名を確認して許可し、システムのステータスバーとアプリ内の状態を確認してください。ここでいうVPNインターフェースは、システムが提供する通信制御の経路です。すべての通信がリモートプロキシを経由するという意味ではありません。最終的な経路はルール、プロキシグループ、アプリごとの設定で決まります。通常、Wi-Fiの手動プロキシを変更する必要はありません。モバイルネットワークとWi-Fiで設定が分かれ、混乱するのを避けましょう。

通常、同じユーザー環境でVPNインターフェースを同時に使用できるVPNアプリは1つだけです。企業VPN、ファイアウォール、ローカルフィルターアプリを使っている場合は、どのアプリに通信制御を任せるか決めてください。「常時接続VPN」や「VPN未接続時に通信をブロック」を有効にする前に、クライアントの起動と再接続をテストしましょう。後者を有効にするとクライアント停止中に通信が遮断され、Wi-Fiの不具合と誤認することがあります。

アプリごとの通信制御には、選択したアプリだけを制御する方式と、選択したアプリ以外を制御する方式があります。保存前にリストの意味を確認し、チェックの有無だけで判断しないでください。テスト時は、制御対象に含めたアプリでリクエストを発生させ、ログと適用ルールを確認します。仕事用プロファイル、クローンアプリ、別ユーザー環境にはそれぞれ制限がある場合があります。メイン環境での設定が、別の環境にも適用されるとは限りません。

バックグラウンド制限、ネットワーク切り替え、バッテリー消費の確認

画面ロック後に切断される場合は、まずバッテリー最適化、バックグラウンド動作、自動起動の設定を確認してください。メーカーによってメニュー名が異なるため、アプリ情報に表示される実際の項目を確認しましょう。フォアグラウンドサービスの通知は、動作の維持や接続状態の表示に使われます。通知が常時表示されるだけで異常とは限りません。設定後は、画面を点灯した状態、ロック中、Wi-Fiからモバイルネットワークへ切り替えた状態の3通りでテストし、どの段階で最初に失敗するか記録してください。

モバイルネットワークだけで失敗する場合は、そのアプリのモバイルデータ利用が制限されていないか、データセーバーが有効か、サブスクリプションの接続先が現在のネットワークから接続できるかを確認します。接続自体は確立していて一部のアプリだけ使えない場合は、アプリごとの通信制御とDNSを確認してください。LAN上の機器にアクセスできない場合は、プライベートアドレスが想定どおり直接接続されるかを調べます。通信をすべて1つの出力先へ強制して振り分けの誤りを隠すと、ローカルサービスへの接続経路まで変わってしまいます。

ネットワークを共有する場合、スマートフォン側のVPNによる通信制御が、テザリング先の端末にも適用されるとは限りません。OSや実装によって異なります。スマートフォン経由でPCをインターネットに接続するだけでは、PCにもプロキシが引き継がれたとは判断できません。まずPC側でリクエストの経路を個別に確認してください。ルールモード、グローバルモード、DIRECTモードの違いは、Clash初心者向け10の質問も参照してください。

iOS

iOS：App Storeで入手、設定のインポート、ネットワーク拡張

App StoreからClash Plusを入手する

iPhoneとiPadでは、まずClash Plusを利用してください。iOSのダウンロードで入手先を確認するか、Clash PlusのApp Storeページを直接開いてください。製品の公式サイトはclashplus.ioです。入手前に、App Storeに記載されたOSの互換性と対応端末を確認します。インストール後は、まずアプリが正常に起動することを確認してから設定をインポートしてください。アプリのダウンロードとサブスクリプションの入手は別の手順です。

iOSでの設定互換性は、項目ごとに確認する必要があります。特定のルール構文に対応していても、別クライアントの画面設定、スクリプト、拡張項目すべてに対応するとは限りません。サービス提供元が複数のサブスクリプションURLを用意している場合は、現在のクライアントに対応した形式を選んでください。旧端末から移行する際は、プロキシグループの選択とカスタムルールを記録しておきます。新端末でアプリのデータが復元されたかも実際に確認してください。アプリのアイコンが表示されたことだけでは判断できません。

リンク、ファイル、QRコードからインポートする際の注意点

リンクからインポートする場合は、通常、設定管理画面でリモート設定を追加し、URLを貼り付けて名前を付けて保存した後、更新して適用します。クリップボードから読み込める画面では、OSから貼り付けの許可を求められた際に、操作内容に応じて許可してください。貼り付けたURLに空白、改行、チャットアプリが追加した文字が含まれていないか確認します。更新後はサブスクリプション一覧で終わらせず、プロキシやプロキシグループの内容を確認してください。

ファイルからインポートする場合は、OSの「ファイル」アプリで保存済みの設定を選択します。クラウドストレージ上のファイルが端末にダウンロードされていない場合は、開けることを確認してからクライアントに読み込ませてください。ファイルのインポートは通常、内容を一度コピーするだけです。元ファイルを変更しても、アプリ内の設定が自動で更新されるとは限りません。継続的に更新する設定では、リモートリンクとして管理する方法がおすすめです。ローカルで管理する場合は、変更後に再インポートして適用する手順を決めておきましょう。

QRコードの読み取りは、クライアントが対応する形式の内容に利用できます。QRコードには、サブスクリプションURL、単一のプロキシ、製品独自のインポートURLなどが含まれることがあり、読み取りに成功しても完全なルール設定とは限りません。読み取り後に認識結果とインポートの種類を確認し、出所不明の内容を取り込まないようにしてください。カメラ権限が必要なのは読み取り機能を使う場合だけです。QRコードを使わないなら、リンクやファイルから設定できるため、ほかのシステム権限を変更する必要はありません。

VPN権限を許可し、通信が制御されているか確認する

初回接続時、OSからVPN構成の追加を求められ、端末のロック解除による確認が必要になる場合があります。許可したらクライアントに戻って接続を開始し、システム設定でVPNの状態を確認してください。この仕組みはネットワーク拡張によって通信を制御するもので、デスクトップOSのHTTPプロキシ設定とは異なります。設定の読み込み、システムトンネルの起動、リモート接続先の利用可否は別々の段階です。どこかで失敗すると、Webページを開けないことがあります。

まずルールモードで利用可能なプロキシグループを選び、接続先にアクセスしてクライアントログを確認します。直接接続するサイトは使えるのに、プロキシが必要な接続先だけ失敗する場合は、プロキシグループの選択とリモート接続を重点的に調べます。すべてのドメインで失敗する場合は、DNS、ネットワーク拡張の状態、基本ネットワークを確認してください。接続中と表示されても、すべてのルールが正しいとは限りません。ステータスバーの表示だけに頼らず、実際のリクエストで検証しましょう。プラットフォーム上でアプリ内ログを確認できる場合は、エラー発生時刻とネットワークの種類も記録してください。

オンデマンド接続、バックグラウンド動作、ネットワークの競合

オンデマンド接続に対応している場合は、手動接続が安定してから有効にしてください。接続を開始する条件やWi-Fiの例外を一つずつ確認し、Web認証が必要なネットワークでリクエストを先に制御してしまわないようにします。ホテル、学校、公共施設のWi-Fiに接続した際は、まず認証ページを完了できるか確認してください。必要に応じて一時的にクライアントを切断して認証し、その後再接続します。認証ゲートウェイの問題をサブスクリプションの無効と誤認しないようにしましょう。

iOSでは、前面で動作するアプリとネットワーク拡張で実行される機能のライフサイクルが異なります。アプリを前面から閉じてもネットワーク拡張が必ず停止するわけではありません。逆に、アプリが最近使用した項目に残っていても、トンネルが正常に動作しているとは限りません。バックグラウンドの問題は、OSのVPN状態と実際のリクエストを確認して判断してください。アプリを何度も前面に切り替えるだけでは解決しません。別のVPNやネットワークフィルターを有効にする前に、既存の設定を置き換えないか確認し、トラブルシューティング中は通信制御を1つに絞ってください。

Wi-Fiでは使えるのにモバイル通信で失敗する場合は、アプリのモバイルデータ利用権限とネットワーク制限を確認します。特定のアプリだけに問題がある場合は、アプリ独自のネットワーク機能と適用ルールを調べてください。詳しいインポート手順はiPhoneでのクライアント入手と設定のインポートを参照してください。端末を替える、またはクライアントの利用をやめる前に、自動接続関連の設定を無効にし、不要になったVPN構成がシステム設定に残っていないか確認しましょう。

Linux

Linux：ディストリビューション別のインストール、デスクトッププロキシ、コアの起動

GUIクライアントとパッケージ形式

Linuxのデスクトップでは、Clash Verge RevとFlClashを確認し、ディストリビューションに合ったパッケージを選んでください。Debian系やUbuntu系では通常deb、Fedoraなどではrpmが使われますが、インストールできるかどうかはアーキテクチャ、システムライブラリ、デスクトップ環境にも左右されます。拡張子だけで互換性を判断しないでください。インストール前にディストリビューション情報とuname -mの出力を確認し、パッケージの要件が現在のシステムに合っているか確かめましょう。

システムのパッケージマネージャーを使うと、個別に展開するより依存関係を処理しやすくなります。下記のコマンドはパッケージがあるディレクトリへ移動し、ユーザーが選んだローカルのdebファイルをAPTでインストールします。実行前に、指定したファイルが信頼できる入手先のものか確認してください。依存関係のエラーが出た場合は出力を読み、ソフトウェアリポジトリの問題、ライブラリのバージョン不足、アーキテクチャの不一致を切り分けます。依存関係を強制的に無視して、管理しにくい状態でプログラムを動かすのは避けてください。

cd ~/Downloads
read -r -p "現在のディレクトリにあるdebファイル名を入力してください：" package_file
if [ -f "$package_file" ]; then
  sudo apt install "./$package_file"
else
  printf '指定されたファイルが見つかりません\n'
fi

サブスクリプションの追加とデスクトッププロキシ

インストール後、デスクトップからクライアントを起動し、リモートサブスクリプションまたはローカル設定をインポートして適用し、コアのログを確認してください。デスクトップ環境では、セッションバスを介してシステムプロキシを管理する場合があります。GNOME、KDE、軽量ウィンドウマネージャーでは動作が異なります。クライアントのシステムプロキシを有効にしても反映されない場合は、デスクトップのネットワーク設定で実際の値を確認します。スイッチがオンというだけで、すべてのプログラムが設定を読み込んだとは限りません。

ブラウザーはデスクトップのプロキシ設定に従う場合がありますが、ターミナル、コンテナ、サービスプロセスでは通常読み込まれません。単一のリクエストを調べるには、curl --proxy http://127.0.0.1:7890 --head https://example.comのように明示的に指定できます。明示したプロキシ経由では成功し、通常の実行では失敗する場合は、対象プログラムのプロキシ設定を優先して確認してください。コンテナ内の127.0.0.1はコンテナ自身を指し、ホスト側ではありません。デスクトップのアドレスをそのまま使わないでください。

TUNの権限と複数のネットワーク管理機能

TUNは通常、/dev/net/tunへのアクセスとルートの変更を必要とします。GUIクライアントでは、ヘルパーサービスを通じて権限を付与する場合があります。まず製品が提供する権限管理方法を使い、GUI全体を管理者権限で実行する必要があると決めつけないでください。下記のコマンドでデバイスとルートの有無を確認できますが、出力は状態の確認に使います。役割を理解せずにルートを削除したり、ファイアウォールを初期化したり、システムの名前解決サービスを停止したりしないでください。

ls -l /dev/net/tun
ip route
resolvectl status
ss -lntp 'sport = :7890'

resolvectlは、対応する名前解決サービスを使うシステムでのみ利用できます。コマンドが見つからなくても、DNSが壊れているとは限りません。NetworkManager、systemd-resolved、他のVPN、クライアント内蔵のDNS機能が、名前解決に同時に影響する場合があります。TUNを有効にしてドメインに接続できなくなったら、リクエストがコアに届いているか、名前解決をどのサービスが処理しているかを確認してから、変更する箇所を判断してください。すべての名前解決サービスを同時に停止すると、原因を特定する手がかりが失われます。

サーバーやルーターで使うMihomo

デスクトップ環境のないサーバーやルーターでは、ダウンロードセンターからMihomoコアを確認できますが、GUIクライアントのインストールとは別の方法です。プロセス、設定ディレクトリ、ログ、権限を自分で管理する必要があります。アーキテクチャに加えて、実行環境の要件も確認してください。特にルーターでは、製品説明に記載されたCPUシリーズだけを頼りにせず、アーキテクチャ名と浮動小数点演算への対応を調べてからファイルを選びましょう。ルールによる振り分けを使うだけなら、デスクトップユーザーがサービスの構築から始める必要はありません。

設定の検証にはmihomo -t -f config.yamlを使用できます。ただし、実行ファイルがコマンド検索パスにあり、設定ファイル名が実際に一致している必要があります。検証に成功したら、まずフォアグラウンドで実行してログを確認し、待ち受けポートと出力先が正常であることを確かめてから、サービスマネージャーに登録してください。設定が外部ルールセットを参照している場合は、作業ディレクトリ、ファイル権限、ダウンロード先も確認します。サービス環境と対話型ターミナルでは条件が異なることがあります。

自動起動の問題は、デスクトップへのログイン時に起動する場合と、システムサービスとして起動する場合を分けて考えます。前者はユーザーセッションに依存し、後者はネットワークの準備が整う前に実行されることがあります。手動実行では正常なのにサービスで失敗する場合は、実行ユーザー、作業ディレクトリ、ログを確認し、検証済みのサブスクリプションは変更しないでください。利用をやめる際は、環境変数、デスクトッププロキシ、サービスの自動起動設定も解除し、バックグラウンドプロセスが新しいクライアントとポートを奪い合わないようにします。

設定とトラブルシューティング

設定のよくある問題：項目、ルール、DNS、接続の確認

設定の入手元と実際に適用される内容を確認する

クライアントに表示されるサブスクリプションの原文が、コアによって最終的に読み込まれるファイルとは限りません。リモート設定、ローカル上書き、画面上の設定、自動生成項目がマージされてから適用される場合があります。「ファイルを変更したのに動作が変わらない」ときは、クライアントの実行中設定またはコアのログを確認し、現在の設定名、読み込み結果、最終的な項目を特定してください。元のサブスクリプション、キャッシュ、画面上のスイッチを同時に変更すると、どの値が上書きしたのか判断しにくくなります。

YAMLはインデントと値の型に注意が必要です。タブではなくスペースを使い、同じ階層の項目はインデントをそろえてください。リスト項目がどの項目に属するかは、親の構造から判断します。エラー行は解析が停止した場所にすぎず、実際の原因が直前の行の引用符、コロン、インデントにある場合もあります。まず最後に正常だったファイルへ戻し、変更を少しずつ加え直してみましょう。応答や形式の問題については、サブスクリプションの更新失敗と設定の解析エラーも参照してください。

項目	用途と確認ポイント
`mixed-port`	HTTPとSOCKSの共通入口。ポートを変更したら、利用する側の設定も更新
`mode`	ルール、グローバル、DIRECTの各モードを切り替える。通信を制御するかどうかとは別の設定
`allow-lan`	別の端末からのアクセスに関係する。待ち受けアドレスとファイアウォールも確認
`external-controller`	制御インターフェース。プロキシの接続先とは用途が異なる
`tun`	仮想NICに関する設定。権限、ルーティング、コアの対応が必要
`rules`	上から順に照合され、先に一致したルールが後続の結果に影響する

ルールの順序と通信モード

ルールは通常、上から順に照合され、一致した時点で対応するプロキシグループが使われます。特定ドメイン向けのルールは、範囲の広いルールより前に置き、最後にデフォルトのルールを配置してください。ルールが参照するプロキシグループが存在し、名前が一致している必要があります。以下は構造の説明だけを目的とした、DIRECT接続の診断用設定です。リモートプロキシは含まれず、読み込み後も一致するリクエストはすべて直接接続されます。実際に使う場合は、サービス提供元のプロキシとプロキシグループを残し、コアのドキュメントに従ってルールをマージしてください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

グローバルモードは一時的な比較には便利ですが、正しいルールの代わりにはなりません。ルールモードでは失敗し、グローバルモードでは成功する場合は、適用されたルール、プロキシグループ、ルールセットを確認してください。すぐにクライアントの動作が不安定だと決めつけないようにしましょう。DIRECTモードでもシステムプロキシが無効になるとは限りません。アプリがまずローカルのプロキシに接続し、その後コアが直接接続する場合があります。元のネットワークで確認する際は、通信の制御を明示的に無効にしてください。モードをDIRECTに変えるだけでは不十分です。

DNSとTUNの確認範囲

DNSはドメイン名をIPアドレスに変換し、プロキシはその後の接続を処理します。2つの処理が異なる場所で行われる場合もあります。TUNを有効にすると、ルーティングと名前解決の経路が変わることがあります。設定ファイルのDNS項目、システムの名前解決サービス、クライアントの上書き設定を合わせて確認してください。別の端末のfake-ipアドレス範囲、除外リスト、上流DNSサーバーをそのままコピーしないでください。既存のネットワーク、コアの機能、実際の用途に合わせる必要があります。組み合わせを誤ると、一部のドメインで問題が発生します。

まず基本ネットワークを確認し、次にコアの待ち受け、リクエストの到達、名前解決、ルールの適用、リモート接続の順に調べます。既知のIPアドレスには接続できるのにドメイン名で失敗する場合は、名前解決の経路を確認します。ただし、これだけで証明書や、ドメイン名を使うサーバー側のルーティングを無視してはいけません。ブラウザーの暗号化DNSが想定した経路を迂回している場合もあります。診断時にはその状態を記録し、一度に変更する設定を1つにして結果を比較してください。

遅延、速度測定、接続できないときの判断

ノードの遅延テストで分かるのは、特定の接続先、プロトコル、時刻における結果です。タイムアウトしてもすべての通信が利用できないとは限らず、数値が低くても大容量ファイルの転送速度が速いとは限りません。まずテスト先と方法を確認し、実際に利用する接続先へのリクエストでも検証してください。プロキシグループに自動選択機能がある場合は、実際に使われている出力先を確認します。一覧中のテスト結果だけで、実際の通信経路を判断しないようにしましょう。

速度測定の結果は、ローカル回線の帯域、Wi-Fiの電波状況、リモート側の速度制限、同時実行中のタスク、測定サイトなどに左右されます。比較する際は、ネットワーク、時間帯、測定先をできるだけそろえ、ほかの大容量通信を止めて使用した出力先を記録してください。1回の測定中にクライアント、DNS、ルールモードを同時に切り替えないでください。特定のアプリだけ遅くなる場合は、すべてのノードを何度も更新するのではなく、そのアプリの接続ログとプロトコルを確認しましょう。

Clashでインターネットに接続できない場合は、まず通信の制御を無効にして直接接続できることを確認し、現在の設定が読み込まれているか、入口のポートが待ち受けているか、プロキシグループに利用可能な選択肢があるかを調べます。次に、エラーが名前解決の失敗、接続タイムアウト、認証失敗、接続拒否のどれに当たるか確認してください。問い合わせる際は、プラットフォーム、クライアント名、通信の制御方法、エラーの原文、確認済みの項目を伝え、機密情報は削除します。症状から調べるにはFAQを、最小限の手順で検証し直すにはクイックスタートガイドを参照してください。