全プラットフォームガイド · インストールと設定

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

初めてインストールする場合は、クイックスタートガイドに沿ってダウンロード、設定の追加、接続まで進めてください。このページではOSごとの詳しい確認手順をまとめています。権限の確認、クライアントの乗り換え、自動起動の設定のほか、「サブスクリプションを追加したのにネットにつながらない」といった問題の切り分けにも役立ちます。

クライアントによってメニュー名は多少異なります。ここでは設定、プロキシ、ログなどの機能名を使って手順を説明します。画面が異なる場合は、使用中のクライアントに表示される項目を確認してください。例にあるポート番号は固定値ではありません。

Clashをダウンロードクイックスタートガイド

共通の準備

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

Clashのクライアントは、画面や設定の管理、OSのネットワーク機能との連携を担います。コアは設定の読み込み、ルールの判定、接続の確立を担当します。クライアントをダウンロードしただけでは、プロキシサービスを利用できるわけではありません。接続には有効なノード設定またはサブスクリプションURLと、そのサービスを利用できるネットワーク環境が必要です。まずクライアントのダウンロードページから使用するOSに対応したアプリを選び、サービス提供元のサブスクリプションを用意しましょう。Windows、macOS、Android、iOSではClash Plusを、LinuxではClash Verge Revをまず確認してください。名前が似ていても、同じコアを使っているとは限りません。設定の互換性は、対応するプロトコルや項目を確認してください。

サブスクリプションは、ClashのYAML設定一式の場合もあれば、ノード情報だけの場合や、サービス提供元が指定する形式の読み込みが必要な場合もあります。追加する前にURLの用途を確認し、アカウント管理ページ、決済ページ、Web共有リンクをサブスクリプションURLと取り違えないようにしてください。URLにはアカウントを識別する情報が含まれることがあるため、パスワードと同様に管理しましょう。トラブルを報告するときは、応答ステータスやエラー文だけを伝え、URL全体を公開の掲示板に貼らないでください。設定画面のスクリーンショットでは、ノードのパスワード、トークン、管理APIキーも隠してください。URLを公開してしまった場合は、サービス提供元の管理画面で先に再発行し、クライアントに保存した古い情報を更新しましょう。

システムのアーキテクチャとインストール範囲

ダウンロード前に、システムのアーキテクチャとインストーラーの形式を確認してください。Windowsではx64とARM64、MacではApple SiliconとIntel、AndroidではARM64、ARM、汎用パッケージの違いに注意が必要です。Linuxではディストリビューションに合ったパッケージ形式も確認しましょう。CPUのアーキテクチャやOSのビット数は、端末の見た目だけでは判断できません。システム情報の「バージョン情報」を確認するか、システムコマンドを使ってください。ダウンロードページに掲載されているパッケージが、このサイトで配布している範囲です。使用中のクライアントに対応するアーキテクチャがない場合は、その端末に対応した別のクライアントを選びましょう。他OS向けファイルの名前を変えてインストールすることはできません。

プラットフォーム	インストール前に確認	接続に必要な権限
Windows	OSの種類、インストール先	システムプロキシ、サービス、仮想ネットワークアダプターの権限
macOS	チップの種類、セキュリティ警告の表示元	補助サービス、ネットワーク設定の権限
Android	パッケージのアーキテクチャ、入手元	VPNの許可、バックグラウンド動作
iOS	ストアの互換性、既存のVPN設定	システムVPN設定の許可
Linux	ディストリビューション、アーキテクチャ、実行方法	ポートの待ち受け、TUN、サービスの権限

サブスクリプションの追加と初回確認

クライアントの設定またはサブスクリプション画面で項目を追加し、URLから読み込む方法を選んでリンクを貼り付け、ダウンロードします。完了したら設定名、更新日時、プロキシグループが表示されることを確認し、その設定を現在使用するものに指定してください。クライアントによっては「項目の追加」と「設定の有効化」が別の操作です。ダウンロードしただけでは、実行中の設定は切り替わりません。ローカルファイルを読み込む場合は、元のファイルをバックアップとして保管してください。クライアントが生成した実行用設定を直接編集すると、次回更新時に上書きされることがあります。継続的に変更する場合は、クライアントが対応するオーバーライド、マージ、スクリプト機能を使いましょう。

追加に失敗したら、まず端末の時刻、基本ネットワーク、URLが完全かどうかを確認してください。サブスクリプションサーバーがWebページを返すと、クライアントでは解析エラーになることがあります。これはノードに接続できるかどうかとは別の問題です。失敗をすべて形式の問題と決めつけたり、アカウントの期限切れを見落としたままコアを何度も変更したりしないでください。先にサブスクリプションが有効か確認し、クライアントログのネットワークエラーや項目に関するメッセージを調べましょう。サブスクリプションの更新にプロキシが必要な環境では、利用可能な設定で先に接続してください。初回インストールで接続手段がない場合は、サービス提供元が許可する方法で設定ファイルをダウンロードし、ローカルから読み込めます。

プロキシグループ、モード、確認の手順

初回接続ではルールモードを選び、設定にある選択グループから利用可能なノードを手動で選ぶ方法がおすすめです。グローバルモードは短時間の比較には使えますが、通常は直接接続するリクエストの経路も変更します。ダイレクトモードではプロキシノードを使いません。遅延テストで分かるのはテスト先への接続状況だけで、すべてのサイトにアクセスできるかや実際のダウンロード速度は判断できません。まず普段使うサイトを開き、接続ログで適用ルールと出口を確認してください。リクエストが目的のプロキシグループを通っていると確認できてから、地域、プロトコル、テスト先を変更しましょう。ノード選びの詳しい比較は遅延・倍率・地域・プロトコルの比較をご覧ください。

Windowsのインストール・設定

ダウンロード、インストール、移行

Windowsのダウンロードを開き、まずClash Plusを確認してから、必要に応じてClash Verge Rev、FlClash、Clash Nyanpasuを比較してください。ダウンロード前に「設定 → システム → バージョン情報」でシステムの種類を確認し、ダウンロードページに実際に掲載されているインストーラーを選びます。インストール時は保存先と権限に関する表示を確認し、完了後にスタートメニューから起動してください。ポータブル版は安定したローカルフォルダーに展開しましょう。圧縮ファイルのプレビューから直接実行したり、自動削除される一時フォルダーに置いたりしないでください。セキュリティソフトの警告が表示された場合は、ファイルの入手元と警告の内容を確認してください。保護機能全体を無効にすることはおすすめしません。

Clash for Windowsは開発が終了しています。アーカイブ版は旧環境の確認には使えますが、新しい端末での標準的な選択肢には適しません。サポート中のクライアントへ移行する前に、サブスクリプションURL、ルールの変更、プロキシグループの選択をバックアップし、旧アプリを終了してシステムプロキシを無効にしてください。クライアント間でデータベースや画面設定を引き継げるとは限らないため、通常はプログラムフォルダー全体をコピーするのではなく、サブスクリプションを再登録するのが確実です。旧設定で特定のスクリプトや項目を使っている場合は、新しいコアの対応状況を一つずつ確認してください。テーマ、ショートカット、起動設定などは再設定が必要になることがあります。

サブスクリプションの追加とシステムプロキシ

設定画面でサブスクリプションを追加して更新し、有効化したら、プロキシ画面でルールモードと使用可能なノードを選びます。その後、設定画面またはホーム画面でシステムプロキシを有効にし、クライアントに表示される待ち受けポートを確認してください。Windowsのシステムプロキシが影響するのは、主にシステムプロキシ設定に従うアプリです。すべての通信が自動的に切り替わるわけではありません。ブラウザーに独自のプロキシ拡張機能が入っていると、システム設定よりそちらが優先されることがあります。問題を切り分けるときはブラウザーをシステムプロキシに合わせ、複数の設定が同時に有効にならないようにしましょう。別のVPN、通信高速化ツール、古いクライアントもプロキシ設定を書き換えることがあるため、いったん終了してから確認してください。

Windowsの「ネットワークとインターネット」設定で、手動プロキシのアドレスがローカル端末を指しているか、ポートがクライアントの表示と一致しているかを確認できます。アドレスがローカル端末でも、アプリが終了していれば接続先のサービスは存在しないため、ブラウザーからはネットワーク全体が切断されたように見えることがあります。その場合はまずシステムプロキシを無効にして基本ネットワークを復旧し、クライアントを再起動してください。ブラウザーでページが開けても設定が正しいとは限りません。直接接続されている場合やキャッシュが表示されている可能性もあります。クライアントの接続一覧で新しいリクエストに適用されたルールとポリシーを確認すると、実際の通信経路を判断しやすくなります。

TUN、サービスモード、権限

システムプロキシに従わないアプリも通信させたい場合は、クライアントが対応していればTUNを有効にできます。TUNは仮想ネットワークアダプターとルーティングを使って通信を取り込むため、通常のシステムプロキシより高い権限が必要です。クライアントによっては補助サービスのインストールや管理者の許可が必要になります。実際の画面に表示される案内を確認してください。有効にした後は、ログにネットワークアダプターの作成、ルートの追加、DNS設定の失敗が記録されていないか確認します。画面全体を常に管理者として実行するのが最善とは限りません。サービスモードが用意されている場合は、説明に従って設定し、サービスが正常に起動しているか確認しましょう。

TUNと別のVPNを同時に使うと、デフォルトルートを取り合うことがあります。企業向けセキュリティソフトによって仮想ネットワークアダプターが制限される場合もあります。テスト前に既存のVPNとネットワーク設定を記録し、通信を制御するツールを一つだけ有効にしてください。TUNを有効にしてネットにつながらなくなったら、まずTUNを無効にし、システムプロキシが使えるか確認します。そのうえで権限、ルート、DNSを個別に調べましょう。システムプロキシは使えてTUNだけ失敗する場合、サブスクリプションを買い直したりクライアントを何度も再インストールしたりする必要は通常ありません。ノードへの接続は正常で、問題は端末側の通信制御にある可能性が高いと分かります。

UWPのループバックとコマンドラインのプロキシ

Windowsのアプリコンテナーで動作する一部のアプリは、ローカルのプロキシポートに直接アクセスできず、ブラウザーでは使えてもストアアプリでは失敗することがあります。まず対象アプリが制限のあるアプリコンテナーに属するか確認し、必要に応じてクライアント付属のループバック許可ツールを使ってください。すべてのアプリに一括でアクセスを許可せず、必要性が明確なアプリだけ設定しましょう。別の方法としてTUNもありますが、クライアントとシステム環境の対応状況に加えてルートの確認が必要です。一般的なデスクトップアプリ、ブラウザー拡張機能の競合、アプリコンテナーの制限はそれぞれ別の問題です。「ストアから入手したアプリ」というだけでループバック許可が必要だと決めつけないでください。

コマンドラインツールも、Windowsのシステムプロキシを読み取るとは限りません。まず明示的な引数でローカルのHTTPプロキシを試せます。ポート番号はクライアントに表示される実際の値に置き換えてください。curl.exeを使うと、一部のPowerShell環境で同名のエイリアスと混同せずに済みます。プロキシを明示すると成功するのに通常のコマンドでは失敗する場合は、サブスクリプションではなく、そのツールが対応する環境変数や設定を確認しましょう。

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

自動起動と終了後の復元

手動で接続できることを確認してから、自動起動を有効にしてください。「クライアントの起動」「コアの起動」「システムプロキシの復元」がそれぞれ何をするのかも確認しましょう。ログイン時にアプリが起動しても、システムサービスまで起動するとは限りません。補助サービスが設定を自動選択するとも限りません。再起動後は通知領域のアイコン、現在の設定、プロキシの状態を確認し、実際にリクエストを送ってテストします。終了前、特に移行やアンインストールの前には、システムプロキシとTUNを無効にしてください。アンインストール後もネットにつながらない場合は、ネットワーク設定をすぐにすべてリセットするのではなく、残ったシステムプロキシやVPNルートを先に確認しましょう。

macOSのインストール・設定

チップの確認と初回起動

「このMacについて」でチップまたはプロセッサの情報を確認し、macOSのダウンロードからインストーラーを選んでください。まずClash Plusを確認し、ほかの候補としてClash Verge RevやFlClashも検討できます。ClashX Metaは開発が終了しているため、アーカイブ版を使う場合は互換性に注意してください。Apple Silicon用とIntel用のインストーラーは、ファイルサイズだけでは判別できません。互換レイヤーで別アーキテクチャのアプリを実行できるかは、アプリの要件を確認してください。ネイティブ版がある場合は、対応するアーキテクチャのものを優先しましょう。インストール前に旧クライアントを終了し、メニューバーアプリが複数同時にポートを待ち受けたり、プロキシ設定を変更したりしないようにしてください。

一般的なインストール方法は、ディスクイメージを開いてアプリを「アプリケーション」フォルダーにドラッグし、そこから起動することです。イメージ内から直接起動したまま使い続けると、イメージの取り出し、再起動、更新の際にアプリを見つけられなくなることがあります。初回起動時にセキュリティ警告が表示された場合は、ダウンロード元を確認し、「プライバシーとセキュリティ」に表示される手順に従ってください。一つのアプリのためにシステム全体のセキュリティ機能を無効にしないでください。「アプリが破損している」と表示された場合も、まず再ダウンロードし、システムとの互換性を確認しましょう。対象外のファイルまで影響する可能性があるため、ネットで見つけた制限解除コマンドをすぐに実行するのは避けてください。

設定の有効化とネットワークサービスのプロキシ

設定画面でサブスクリプションを読み込んだら、使用する設定を選び、プロキシ画面でルールモードとノードを指定します。システムプロキシを有効にした後は、現在使用中のネットワークサービスも確認してください。Wi-Fi、有線LAN、ドッキングステーションの接続、ほかのネットワーク環境には、それぞれ別のプロキシ設定がある場合があります。クライアントが現在のサービスを自動設定しても、ネットワークを切り替えた後は設定が維持されているか確認しましょう。ブラウザーでは使えるのにターミナルでは失敗する場合、それぞれがシステムプロキシを参照しているかを個別に調べてください。二つのアプリが同じ通信経路を通るとは限りません。

システム設定のネットワーク詳細で、Webプロキシ、セキュアWebプロキシ、SOCKSプロキシがクライアントの待ち受け方式と一致するか確認してください。混合ポートを使うとHTTPとSOCKS5の両方を受け付けられますが、システム設定では対応する欄に入力する必要があります。接続先は通常、ローカルのループバックアドレスです。サブスクリプションサーバーのアドレスを入力しないでください。サブスクリプションURLは設定の取得先であり、ローカルプロキシの待ち受け先ではありません。クライアントを切り替えたときは、以前のソフトの既定ポートをそのまま使わず、現在のポートを確認してください。

補助サービスとTUNによる通信制御

TUNや拡張通信制御には、追加のネットワーク権限が必要になることがあり、クライアントが補助サービスをインストールする場合もあります。許可する前に、どのアプリが権限を求めているかを確認し、インストールしたクライアントのものだと確かめてください。許可後にスイッチがすぐオフに戻る場合は、ログでサービスへの接続、ネットワークアダプターの作成、ルート情報を確認します。メニューバーにアプリが表示されていても、補助サービスが使えるとは限りません。アプリの更新、保存場所の変更、バックアップからの復元後に、サービスと本体の状態が食い違うこともあります。まずクライアントに用意されたサービスの確認・修復機能を使ってください。

会社管理の端末では、管理ポリシーによってプロキシ、ネットワーク拡張、補助サービスが制限されていることがあります。スイッチを何度も操作しても解決しません。端末管理の許可範囲内でクライアントを使用してください。別のVPN、仮想マシン、コンテナーのネットワークもルートを追加することがあります。TUNを有効にした後、一部のネットワークだけで問題が起きる場合は、影響を受ける接続先と既存のルートを確認しましょう。システムのルートをすべて削除するのではなく、ほかの通信制御ソフトを終了して比較してください。問題の記録を残しながら、元の作業環境にも戻しやすくなります。

ターミナル、DNS、ネットワーク切り替え

ターミナルのツールでは、プロキシを明示的に指定する必要があることがよくあります。以下のコマンドはローカルの待ち受けとリクエスト経路の確認用です。ポート番号はクライアントに表示される値に合わせてください。2つ目のコマンドは現在のシステムプロキシ情報を取得するだけで、設定は変更しません。リクエストが成功したら、次に使用するツールが対応する方法でプロキシを設定します。環境変数をシェル設定ファイルに書き込むと、以後のターミナルセッションにも影響します。まず現在のウィンドウだけで一時的に試し、クライアント終了後にどう解除するか確認してください。ローカルの待ち受けを停止した後も、開発ツールが接続を試み続ける事態を防げます。

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

Wi-Fiの切り替え、スマートフォンのテザリング、スリープからの復帰後は、クライアントが接続し直す必要がある場合があります。まず端末の基本ネットワークを確認し、その後でコアとプロキシの状態を見てください。ドメイン名だけにアクセスできない場合は、DNSログと現在のネットワークでの名前解決設定を調べます。ホテルや公衆Wi-Fiでは、先にWeb認証が必要な場合があります。そのときは一時的にプロキシを無効にして認証ページを開き、完了後に再び有効にしてください。特定のネットワークで認証ページが開けないからといって、すべてのネットワークのDNSを恒久的に変更すると、局所的な問題がほかの環境にも広がります。

ログイン時の起動、移行、アンインストール

ログイン時に起動する必要がある場合は、クライアントとOSのログイン項目で実際の状態を確認してください。ウィンドウを閉じても画面が隠れるだけのことがあり、完全に終了するにはメニューバーから操作する必要があります。デスクトップにウィンドウがあるかどうかではなく、コアと待ち受けの状態でプロキシが動作中か判断しましょう。別のクライアントへ移行する前に、サブスクリプションとローカルルールをバックアップし、旧アプリのシステムプロキシを無効にしてください。アンインストール時はクライアントの手順に従って補助サービスを削除し、その後、現在のネットワークサービスにローカルプロキシ設定が残っていないか確認します。具体的な残存項目がある場合だけ処理すればよく、ソフトの移行だけでネットワーク環境全体を作り直す必要はありません。

Androidのインストール・設定

インストーラーのアーキテクチャとクライアント選び

Androidのダウンロードでは、まずClash Plusを確認し、設定の要件に応じてClash Meta for Android、FlClash、Surfboardを選んでください。ARM64は対応する64ビット環境向け、ARMパッケージは対応環境向けです。クライアントが用意している場合、アーキテクチャが分からない端末には汎用パッケージを選べます。端末のハードウェアが64ビットに対応していても、OSがすべてのARM64アプリのインストールを許可するとは限りません。古い端末や特殊なOSでは、実際の実行環境も確認してください。「インストールできません」と表示されたら、OSとの互換性、空き容量、署名の競合を調べましょう。同じパッケージの名前を何度も変更してインストールしないでください。

インストールファイルからアプリを更新する場合、パッケージ名と署名が既存アプリと一致している必要があります。別の配布元や異なる署名のパッケージでは、上書きインストールできないことがあります。アンインストールするとアプリのデータも削除される場合があるため、先にサブスクリプションとローカル設定をバックアップしてください。OSからインストール元の許可を求められた場合は、実際にファイルを開くファイル管理アプリまたはブラウザーだけに許可します。インストール後はその権限を取り消してもかまいません。Androidのメーカーによってメニューの場所は異なりますが、確認するのはインストール元の権限、アプリの互換性、既存のインストール状況です。セキュリティ警告をすべて無効にする必要はありません。

サブスクリプション、現在の設定、ルール

設定画面でリモートサブスクリプションの追加機能を使ってリンクを登録し、ダウンロード後に実行する設定を明示的に選びます。ダウンロードが完了したら、まずプロキシ画面で必要なプロキシグループとノードが表示されるか確認してから接続を開始してください。Clash Meta for AndroidとFlClashでは項目名が異なる場合がありますが、設定を取得し、有効な項目として選び、ポリシーを指定して、OSの許可を受けるという流れは共通です。Surfboardの設定形式はClash YAMLと同じではありません。使用する場合は、サービス提供元が明示的に対応している形式を入手してください。互換性のないファイルを読み込んだ後、モードを切り替えて直そうとしないでください。

リモート更新では、サブスクリプションの内容が置き換わるのが一般的です。ローカルで変更した名前、追加したルール、選択状態が残るかどうかはクライアントの実装によります。長期的に維持するルールは、クライアントが対応する独立したオーバーライドやローカル設定に保存し、更新後に実際の反映状態を確認してください。サービス提供元がプロキシグループ名を変更すると、以前の選択が無効になることがあります。ノードが一覧に残っていても想定した出口を通らない場合は、現在のグループ間の参照関係を確認しましょう。ノードのテストボタンだけで判断せず、最終的なルールがそのグループを参照していることも確かめてください。

VpnServiceの許可と通信の制御範囲

Androidでは通常、システムのVpnServiceを使って通信をクライアントに渡します。初回接続時にVPN接続の要求が表示されるので、確認すると、ステータスバーに鍵またはVPNのアイコンが出ることがあります。これはOSが端末内の通信制御用トンネルを許可したことを示すもので、プロキシノードへの接続成功を意味するわけではありません。許可を拒否した場合は、もう一度接続を開始してシステムの案内を確認してください。仕事用プロファイル、管理対象モード、常時接続VPNのポリシーがある端末では、新しい接続が許可されるかどうかはシステムのポリシーによって決まります。ポリシーによる制限を、サブスクリプション形式のエラーと取り違えないでください。

通常、同じユーザー環境で有効にできるVpnServiceは一つです。広告ブロッカー、ファイアウォール、別のVPNアプリが同じ機能を使っている場合があります。テスト時は関連するほかのアプリを終了してから、現在のクライアントを起動してください。アプリ別のプロキシ機能がある場合は、「選択したアプリだけをプロキシする」と「選択したアプリを除外する」の違いに注意しましょう。二つのリストは意味が逆のため、プロキシを使いたいアプリを除外してしまうことがあります。リストを変更した後、再接続しないと反映されないクライアントもあります。対象アプリを開き直し、新しい接続ログで確認してください。

バックグラウンド動作と画面消灯後の切断

インストール後、画面点灯中は使えるのに、画面を消してしばらくすると接続できなくなる場合は、まずバッテリー最適化とバックグラウンド制限を確認してください。OSのアプリ情報でバックグラウンド動作を許可し、メーカー独自の設定に従ってバッテリー最適化の対象外、自動起動、バックグラウンドでのロックなどを設定します。これらの項目は端末によって存在しない場合があり、設定しても常に動作し続けるとは限りません。実際の動作で確認してください。通知に表示されるフォアグラウンドサービスの通知は、継続動作に関係することがあります。表示を隠すために必要な通知をむやみに無効にしないでください。バックグラウンド制限と通知の権限は別々に記録して切り分けましょう。

再現性のあるテストを行うには、接続後に時刻を記録し、画面を消してしばらく待ってから同じアプリを開き、接続が戻るか確認します。その後、クライアントログに再起動やネットワーク切り替えの記録がないか調べてください。プロセスが動作中なのにモバイルデータ通信だけ失敗する場合は、通信権限、データセーバー、ネットワーク環境を確認します。プロセスが終了している場合は、OSによる終了の可能性が高いでしょう。詳しくはVpnServiceの許可とバッテリー最適化の対象外設定も参照してください。メニューの場所は使用中の端末で確認しましょう。

テザリング共有、DNS、切断後の復旧

スマートフォンでVPNが有効でも、テザリングで接続したほかの端末も同じプロキシを使うとは限りません。テザリングで転送される通信が、アプリのVpnServiceによる制御範囲に入らないことがあります。スマートフォン自身でアクセスできるだけでは、共有に成功したと判断できません。タブレットをPCのプロキシに接続する場合は、LAN共有の手順に沿ってタブレットのプロキシアドレスとポートを設定し、PCからの接続が許可されていることを確認してください。AndroidのプライベートDNS、ブラウザーのセキュアDNS、クライアントのDNS設定で、名前解決の経路が分かれることもあります。明確なドメインエラーがある場合に一項目ずつ比較し、すべてのDNS機能を一度に無効にしないでください。

終了、アンインストール、移行の前に、現在の接続を停止し、システムのVPN設定に残っている項目がないか確認してください。バックアップには必要なサブスクリプションとローカルルールだけを保存します。アカウント情報を含むエクスポートファイルを共有ストレージや自動公開されるフォルダーに置かないでください。移行後はアプリごとのプロキシ対象範囲とバックグラウンド権限を改めて確認しましょう。旧クライアントに付与したシステム権限が、新しいクライアントに引き継がれることは通常ありません。

iOSのインストール・設定

App Storeからのインストールと端末の互換性

iPhoneとiPadでは、iOSのダウンロードからClash PlusのApp Storeページを開くか、Clash PlusのApp Storeページを直接確認できます。公式サイトはclashplus.ioです。製品の案内を確認する場合は、このドメインを参照してください。インストール前に、App Storeに表示される端末とOSの互換性を確認しましょう。必要なOSのバージョンは、現在のストア情報に従ってください。他のプラットフォーム向けインストーラーの要件を当てはめないようにしましょう。インストール後はアプリを一度開き、サブスクリプションを追加する準備をします。すでにVPN設定がある場合は、用途と接続状態を記録してください。

このページでは端末上のクライアントとOSの接続設定を扱います。プロキシサービスの利用には、有効な設定が別途必要です。ストアからアプリをインストールできたこと、アプリを起動できること、ノードに接続できることは、それぞれ別の確認項目です。アプリが起動しない場合は、端末の空き容量、OSの互換性、インストール状況を確認します。アプリは起動するのにサブスクリプションをダウンロードできない場合は、URLとネットワークを確認してください。ノードが表示されているのに接続できない場合は、システムの許可とノードへの接続経路を調べましょう。この順に確認すると、一つのインストール問題をきっかけにアカウントやネットワーク全体を再設定する必要がなくなります。

サブスクリプションの追加、更新、選択

Clash Plusの設定またはサブスクリプション画面を開き、現在の画面に表示される方法でリモートURLを追加します。貼り付ける前に、説明文ではなくサブスクリプションURL全体をコピーしたことを確認してください。ダウンロード後は設定が有効になっているか、プロキシグループが表示されているかを確認します。ファイルからの読み込みに対応している場合は、サービス提供元から入手した互換性のある設定ファイルを使用できます。URLが返す形式は、現在のクライアントが対応する形式と一致していなければなりません。名前にClashとあるだけで、どのサブスクリプションでも使えるとは限りません。特に新しいプロトコルやコア専用の項目を使う設定では注意してください。

サブスクリプションを更新する前に、選択中のプロキシグループと必要なローカル設定を記録してください。更新によってノード名、グループ構成、ルールが変わることがあるため、更新後は想定していた出口が選択されているか確認します。複数の選択グループがある場合は、ホーム画面で遅延が低そうなノードを一つ選ぶだけでなく、最終的にリクエストがどのグループに振り分けられるかを確認してください。自動選択グループではテスト先に応じて出口が変わることもあります。地域や接続先を固定したい場合は、設定にある手動選択グループを使い、ルールから実際に参照されていることを確認しましょう。

VPNの許可と接続状態

初回接続時に、アプリからVPN設定の追加を求められ、OSが許可または端末認証を要求することがあります。許可した後はアプリに戻って接続を続け、システム設定でVPNの状態を確認してください。このOSの設定は通信を制御するための権限であり、プロキシサービス提供元にアカウント情報を送信する手順ではありません。許可画面が表示されない、または接続直後に切断される場合は、ほかに有効なVPNがないか、管理ポリシーや確認待ちの設定がないかを調べてから、アプリ内のエラーを確認しましょう。同じサブスクリプションを何度読み込んでも、システム権限の問題は解決しません。

iOSの接続経路はデスクトップのシステムプロキシとは異なり、通常はOSが許可するネットワーク拡張機能を利用します。デスクトップ向けのTUNスイッチ、サービスのインストール、コマンドラインの環境変数を、そのままスマートフォンに当てはめないでください。アプリにオンデマンド接続、ルール、その他のネットワーク設定がある場合は、現在の機能説明に沿って設定します。有効にする前に、Wi-Fi、モバイル通信、端末のロック中にどのように動作するか確認してください。会社のVPNや管理対象の設定がある端末では、管理者の要件に従いましょう。二つの通信制御ツールを同時に使うために、仕事で必要な設定を削除しないでください。

Wi-Fi、モバイル通信、ドメインのトラブルシューティング

初回の確認では、安定したWi-Fiに接続し、ルールモードと使用可能なノードを選んでから、対象サイトを開き、接続ログを確認します。その後、モバイル通信に切り替えて同じテストを行ってください。一方のネットワークだけで失敗する場合は、そのネットワークの基本的な接続状況とアプリのモバイルデータ通信権限を確認します。両方で失敗し、別の端末では同じノードが使える場合は、対象端末の設定と権限を調べましょう。ネットワーク切り替え時は接続が途切れることがあります。切り替え直後の一時的な失敗と、継続してつながらない状態を分けて記録してください。一瞬の切断だけでサブスクリプション切れと判断しないでください。

公衆Wi-Fiでは認証ポータルが表示されることが多いため、まずネットワークの認証を完了し、その後にプロキシを有効にしてください。プロキシを有効にして認証ページが開かなくなった場合は、接続を一時停止して認証し、完了後に再接続します。ドメインの名前解決に問題がある場合は、クライアントのDNSエラーと、プライバシーやネットワーク関連の機能が通信経路に影響していないか確認してください。「特定のサイトが開けない」だけで、OSのDNS障害だと決めつけないでください。直接接続のルールが適用された場合や、現在の出口が接続を拒否している場合もあります。ルールモードと短時間のグローバルモードを比較し、接続ログを確認するほうが、システム設定を何度も変えるより多くの手がかりを得られます。

バックグラウンド接続と家庭内端末の共有

アプリの画面を閉じても、確立済みのネットワーク拡張機能は停止しない場合があります。切断する際は接続スイッチを使うか、システムのVPN設定で状態を確認してください。アプリを強制終了した後に接続が残るかどうかは、現在の実装とOSの状態によります。アプリがバックグラウンドに表示されているかだけで通信全体の状態を判断しないでください。長時間使わなかった後に再開する場合は、まずVPNの状態を確認し、サブスクリプションが有効か調べます。アプリやOSの更新後に接続できなくなった場合は、いったん切断して再接続し、具体的なエラー文を記録してください。設定または許可の問題が明確な場合に限り、該当する項目を修正しましょう。

iPhoneやiPadをPCのプロキシに接続するには、信頼できるLANのWi-Fi詳細で手動HTTPプロキシを設定し、PCのLAN内アドレスと実際の待ち受けポートを入力します。この方法が影響するのは、そのWi-Fiのプロキシ設定に従うリクエストだけです。モバイルアプリのように通信全体を制御するものではなく、通常はモバイル通信には適用されません。ネットワークを離れる前にプロキシ設定を戻し、次回接続時に電源が切れたPCを探し続けないようにしてください。共有の範囲とファイアウォールについては、混合ポートとLAN共有ガイドをご覧ください。

Linuxのインストール・設定

デスクトップクライアントとコマンドラインの選び方

Linuxでは使用環境に合わせて方法を選びます。デスクトップ環境ではLinuxのダウンロードからClash Verge Revを確認し、次にFlClashも検討してください。サーバー、ルーター、スクリプトで管理する環境では、コアのダウンロードからmihomoを選べます。GUIクライアントは設定管理と操作を担いますが、コマンドラインのコアではファイル、プロセス、システム側の通信制御を自分で管理する必要があります。コアをインストールしただけでデスクトップのプロキシが自動設定されるわけではありません。作業を始める前にuname -mを実行してアーキテクチャを確認し、ディストリビューションが対応するパッケージ形式を調べてください。DEBとRPMは共通のインストーラーではありません。

デスクトップ版はディストリビューションのパッケージ管理ツールでインストールすると、依存関係や削除記録を管理できます。ダウンロードページに実際に掲載されているファイルを使用し、OSのソフトウェアインストーラーで開くか、ダウンロードフォルダーからパッケージ管理ツールでインストールしてください。出所不明のスクリプトに管理者権限を与えないでください。インストール後にアプリを起動できない場合は、ターミナルから起動して、不足しているライブラリやグラフィカル環境のエラーを確認します。サーバーにグラフィカル環境がないためデスクトップアプリを表示できない場合、Linux向けコアが非対応ということではありません。無関係なデスクトップコンポーネントを追加するのではなく、コマンドライン方式を選びましょう。

デスクトップでのサブスクリプションとアプリのプロキシ設定

GUIクライアントでも、ほかのデスクトップOSと同様に、リンクを追加してダウンロードし、使用する設定として有効化した後、ルールモードとノードを選びます。システムプロキシを有効にしたら、現在のデスクトップ環境のネットワークプロキシ設定を確認してください。GNOME、KDE、個別のアプリでシステムプロキシを読み取る方法は完全には同じではありません。ターミナル、コンテナー、システムサービスがデスクトップの設定を自動的に引き継ぐとも限りません。まずブラウザーで確認し、次にコマンドラインツールを明示的なプロキシ指定でテストすると、ノードの問題とアプリがプロキシを使っていない問題を切り分けられます。

GUIクライアントがTUNに対応している場合は、スイッチがオンかどうかだけでなく、補助サービス、コアの権限、ルートも確認してください。LinuxでTUNデバイスを作成するには、通常/dev/net/tunとネットワーク管理権限が関係します。コンテナーでは、ホスト側で明示的な許可が必要です。一般アプリ全体を常に権限昇格して実行する方法が、すべての環境に適しているとは限りません。クライアントが提供するサービス機能を使うか、権限の範囲を理解したうえで設定してください。SSHでのリモート操作では、復旧手段を必ず確保しましょう。唯一の接続経路からデフォルトルートを直接変更しないでください。

mihomoのファイル配置と設定の検証

コマンドラインで導入する場合は、対応するアーキテクチャのコアを展開し、決めた場所に配置します。以下では/usr/local/bin/mihomoを実行ファイル、/etc/mihomo/config.yamlを設定ファイルの例として使います。管理方法に応じてパスを変更できますが、コマンドとサービスファイルで同じパスを指定してください。ディレクトリを用意したら、入手した互換性のある設定を指定ファイルに保存し、構文をテストします。テストに成功しても、設定を読み込めることが分かるだけで、ノードのアカウントや接続先ネットワークが使えるとは限りません。起動後もログと実際のリクエストを確認してください。

sudo install -d -m 700 /etc/mihomo
sudo chmod 755 /usr/local/bin/mihomo
sudo /usr/local/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

コアが起動するかだけを確認する場合は、以下の最小限の直接接続設定を使えます。プロキシノードは含まれていないため、プロキシ経由の出口は提供されません。待ち受け、ログ、基本的な設定形式を確認するためのものです。実際に使う場合は有効なサブスクリプション設定に置き換えるか、項目の関係を理解したうえでノードとプロキシグループを追加してください。まず安全に試せるよう、待ち受けはローカル端末だけに限定し、LANからのアクセスを無効にしています。管理APIを利便性のためにインターネットへ公開しないでください。

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

systemdによる常駐起動とログ

systemdを使うディストリビューションでは、コアをサービスとして実行できます。以下の例は、HTTPまたはSOCKSのローカル待ち受けを使い、TUNを有効にしない初期設定向けです。特権のない動的ユーザーで実行します。設定ディレクトリはサービスユーザーから読み取り可能にし、設定内のファイルパスにもアクセスできるようにしてください。実行状態の保存にはステータス用ディレクトリを使い、設定ファイルと書き込み可能なデータを分離しています。ローカルルールファイルの読み込みが必要な場合は、読み取り権限を別途設定してください。認証情報を含むディレクトリ全体を書き込み可能にしないでください。

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

[Service]
Type=simple
DynamicUser=yes
StateDirectory=mihomo
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target

ファイルを/etc/systemd/system/mihomo.serviceとして保存します。前述のディレクトリは管理者以外が読めない設定です。この動的ユーザーの例を有効にする前に、サービスが設定を読み込めるようにしてください。systemdの資格情報機能を使う方法、または専用の固定ユーザーを作成して必要な読み取り権限だけを付与する方法があります。権限の違いを確認せずに、そのまま有効化しないでください。専用ユーザーを使う場合は、サービスのユーザー設定とディレクトリの所有者も合わせて変更します。TUNを使うには追加のネットワーク権限とルーティング設計が必要ですが、この例では扱いません。権限を確認したら再読み込み、有効化、ログの確認を行い、失敗した場合は具体的なエラーを確認してください。

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo
sudo journalctl -u mihomo -b --no-pager

リモート利用の安全対策と更新時の復旧

サービス起動後は、プロキシを明示したリクエストで待ち受けを確認し、サーバーの全出力ルートをすぐに変更しないでください。共有する場合は、待ち受けるネットワークインターフェース、接続元のネットワーク、ファイアウォールルールを限定します。管理APIとプロキシポートは用途が異なるため、それぞれ個別にアクセスを制限してください。コアを更新する前に設定とサービスファイルをバックアップし、サービスを停止してから実行ファイルを置き換えます。設定をテストして起動し、問題が起きたら元のファイルに戻せるようにしてください。再起動だけで互換性の問題を隠さないようにしましょう。デスクトップ版とコマンドライン版の詳しい比較はLinuxのGUIクライアントとsystemdによる導入ガイドをご覧ください。

設定トラブルの確認手順

ポート、ルール、オーバーライド

設定の問題は、まずどの層で起きているかを切り分けます。ファイルを解析できるか、ノードに接続できるか、ルールが想定した出口を選んでいるか、アプリがローカルプロキシを使っているかを確認してください。混合ポートはHTTPとSOCKS5のリクエストを受け付けます。システムプロキシは一部のアプリに接続先を通知し、TUNはより低い層で通信を制御します。相互に関係はありますが、互いの代わりにはなりません。ログに待ち受けの失敗がある場合はポートの使用状況を、ポリシーが見つからない場合はプロキシグループの参照を確認します。リクエストが接続一覧に表示されるのに出口が異なる場合は、ルールの順序を調べてください。障害の層を特定してから変更すれば、修正の目的が明確になります。

設定項目	役割	主な確認箇所
`mixed-port`	HTTPとSOCKS5の混合ポート待ち受け	ポートの使用状況、アプリに設定した値との一致
`allow-lan`	LAN内の端末からの接続を許可	バインドするアドレスとファイアウォールの範囲
`mode`	ルール、グローバル、ダイレクトの各モード	クライアントが設定値を上書きしていないか
`rules`	ルールの順に出口ポリシーを適用	参照先のノードまたはプロキシグループが存在するか
`dns`	コアのDNS設定	有効になっているか、上流へ接続できるか
`tun`	仮想ネットワークアダプターによる通信制御	コアの対応状況、OSの権限、ルート

ルールは通常、上から順に照合されます。最後のMATCHは、優先して適用するルールの後に配置してください。ルールの出口名は、既存のノードまたはプロキシグループと完全に一致させる必要があります。大文字・小文字、空白、名前の変更も参照に影響することがあります。以下の例にあるPROXYは、現在の設定ですでに定義されているポリシーでなければなりません。コアが自動で作成する共通の出口ではありません。リモートサブスクリプションを変更した場合は、クライアントのオーバーライドが適用される順序も確認してください。実行中の設定がサブスクリプションの元データと異なっていても、マージの結果として正常なことがあります。最終的に有効な設定を確認して判断しましょう。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

よくある問題の確認

サブスクリプションをダウンロードできても、プロキシグループが表示されないのはなぜ？

まず、ダウンロードした設定が有効になっていることを確認し、内容が設定一式かどうかを調べます。サブスクリプションによってはノード情報しか含まず、プロキシグループやルールをクライアント側または外部の設定で補う必要があります。Webのエラーページがファイルとして保存されている場合もあります。ダウンロード完了の表示だけで判断せず、ログにある具体的な解析エラーを確認してください。以前の設定で接続できる場合は一時的に戻してから、新しいサブスクリプションの形式とコアとの互換性を調べましょう。

ノードテストに成功したのに、ブラウザーでアクセスできないのはなぜ？

ノードテストは通常コアから実行されますが、ブラウザーのリクエストがコアに届いていないことがあります。システムプロキシのアドレスとポート、ブラウザー独自のプロキシ設定、接続一覧を確認してください。新しいリクエストが見えない場合は、まずプロキシへの接続設定を調べます。リクエストが見える場合は、適用されたルール、プロキシグループ、エラーを確認しましょう。別の接続先でも試し、特定サイトだけの制限か、接続全体の失敗かを切り分けてください。テスト先への接続に成功しても、目的のサイト、UDP、すべてのプロトコルが使えるとは限りません。

TUNを有効にした後、ネットにつながらなくなるのはなぜ？

まずTUNを無効にして基本ネットワークを確認し、続いてシステムプロキシからノードに接続できるか試します。システムプロキシが正常なら、仮想ネットワークアダプターの権限、補助サービス、デフォルトルート、DNSを重点的に確認してください。別のVPNの同時利用、古いルートの残存、上流DNSへの接続不可などが、通信制御後のリクエストを妨げることがあります。一度に変更するのは一項目だけにし、有効化する前後のログを残しましょう。プラットフォーム、コア、ネットワーク環境は端末ごとに異なるため、ほかの端末のTUN設定をまとめてコピーしないでください。

ノードの障害ではなく、DNSの問題だと判断するには？

ログに名前解決のタイムアウトがあるか確認し、複数のドメインやアプリで結果を比較して、クライアントがどの名前解決経路を使っているかを調べます。ブラウザーのセキュアDNS、システムのプライベートDNS、コアのDNSが同時に使われている場合があります。システム設定を変更しても、ブラウザーに反映されないことがあります。fake-ipモードで合成アドレスが返るのは仕様です。実際のIPアドレスではないからといって、異常と判断しないでください。一部のアプリで問題が起きる場合は、設定の仕組みを理解したうえで例外を追加しましょう。DNS設定全体を削除する必要はありません。

PCでは使えるのに、スマートフォンからPCのプロキシを使えないのはなぜ？

スマートフォンには、127.0.0.1ではなくPCの現在のLAN内アドレスを設定してください。2台が相互に通信できるネットワークに接続していること、PCでLAN接続が許可されていること、外部からの接続を受け付けるアドレスで待ち受けていること、信頼できる接続元だけをファイアウォールで許可していることを確認します。ゲストWi-Fiやクライアント間通信の分離によって、端末同士が通信できない場合があります。allow-lanを有効にしても、ファイアウォールやネットワーク構成が自動的に整うわけではありません。トラブル対応のためにファイアウォール全体を無効にしないでください。

サブスクリプション更新後に、カスタムルールが消えるのはなぜ？

リモート設定は新しい内容に置き換わるのが一般的です。ダウンロード済みファイルを直接編集しても、変更が維持されるとは限りません。使用中のクライアントに対応したオーバーライド、マージ、独立ルールの機能を使い、適用順序も確認してください。更新後は最終的な実行設定を確認し、ルールがフォールバック用ルールより前に追加されているか、参照先のプロキシグループ名が変わっていないかを調べます。変更前のバックアップは復元に役立ちますが、旧設定の全項目を新しいコアに無理に上書きしないでください。

ログ、以前の状態への復元、関連情報

問題を記録するときは、OS、クライアント名、コアの情報、通信制御の方式、対象アプリ、最短の再現手順を残してください。ログは通常の実行レベルから始め、必要な場合だけ一時的に詳細度を上げます。共有前にアカウント情報を削除しましょう。接続一覧にリクエストがない場合、誤ったルールが適用されている場合、ノードのハンドシェイクに失敗する場合は、それぞれ原因の切り分け方が異なります。何度も再インストールするより、状況に合わせて確認してください。コアの項目の違いはオリジナル版・Meta・mihomoの互換性ガイドを、用語は用語集をご覧ください。

すぐに原因を特定できない場合は、最後に使えた状態へ戻しましょう。新たに有効にした通信制御機能をオフにし、バックアップした設定を復元して、システムプロキシが終了済みのアプリを指していないことを確認してください。ネットワークが復旧したら、問題を一つずつ再現します。別のクライアントを選ぶ場合はクライアントの比較・選び方を、操作を最初から確認する場合はクイックスタートガイドをご覧ください。ダウンロード、設定、OSの権限を分けて確認すると、次回の移行や更新時にも比較の基準を保てます。