2026-08-02 レビュー 読了時間目安 11 分

Clash Plusは、iPhoneやiPadで手軽に使える無料のプロキシクライアントです。App Storeから入手でき、広告もありません。サブスクリプションを登録するだけで、初めての人でもスムーズに始められます。この記事では、iOS版を導入する前に知っておきたい仕組み、サブスクリプションの登録手順、プロファイルとプロキシの選び方、通信できない場合の確認ポイントまでを順番に解説します。

Clash Plus iOS版を無料で導入｜App Storeで使えるおすすめアプリ

Clash Plus iOS版でできること

Clash Plusは、iPhoneやiPad上でサブスクリプション形式のプロキシ設定を読み込み、登録されたルールに応じて通信先を振り分けるアプリです。すべての通信を同じ経路へ送る単純なVPNアプリとは異なり、ドメイン名やIPアドレスなどの条件に応じて、プロキシ経由と直接接続を分けられる点が特徴です。

たとえば、通常のウェブ閲覧はプロキシグループへ送り、家庭内の機器や国内サービスは DIRECT にする、といった構成を作れます。どの通信をどの経路へ送るかは、アプリ内で読み込んだClash互換設定の rules とプロキシグループによって決まります。そのため、アプリをインストールしただけで接続先が自動的に用意されるわけではなく、別途有効なサブスクリプションが必要です。

  • iPhoneとiPadで利用可能:App Storeから通常のiOSアプリとしてインストールできます。
  • 無料で始めやすい:アプリ本体の導入後、利用中のサービスからサブスクリプションを取得して登録します。
  • ルールベースの分岐に対応:プロキシ経由、直接接続、特定グループへの転送を条件ごとに設定できます。
  • 広告表示を抑えた操作環境:設定確認や接続切り替えに集中しやすく、初心者でも画面を追いやすい構成です。

なお、App Storeでの配信状況や表示名、対応OSの条件は地域やアプリの更新によって変わる場合があります。検索結果に同名のアプリが複数表示されたときは、開発元、アプリの説明、更新日、対応端末を確認してから導入してください。

導入前に準備するもの

Clash Plusの初期設定を始める前に、次の3つを用意しておくと作業が止まりにくくなります。特に重要なのは、アプリと接続サービスを別々に考えることです。Clash Plusは設定を読み込んで通信を制御するクライアントであり、プロキシサーバーそのものを提供するサービスではありません。

  1. Clash Plus本体:App Storeから公式の配信ページを開き、端末のOS条件を満たしていることを確認してインストールします。
  2. 有効なサブスクリプションURL:利用するサービスの管理ページから発行された、https:// で始まるリンクを用意します。
  3. 安定した初回通信:最初の設定を取得する段階では、App Storeやサブスクリプション配布元へアクセスできる通信環境が必要です。
注意

サブスクリプションURLにはアカウント識別情報が含まれることがあります。SNS、掲示板、サポート依頼のスクリーンショットへそのまま貼り付けたり、出所不明の変換サイトへ入力したりしないでください。漏えいした場合は、サービス側でURLを再発行できるか確認し、古いリンクを無効化するのが安全です。

サブスクリプションの形式も確認してください。Clash互換のYAMLを返すリンクであれば、そのまま読み込める可能性が高くなります。一方、特定の別クライアント向けに生成されたリンクや、単一ノードの共有リンクだけを返すURLは、Clash Plus側で直接利用できないことがあります。サービス提供者が「Clash」「mihomo」「iOS」などの対応先を案内しているかを先に確認しましょう。

App Storeからインストールする手順

iPhoneまたはiPadでApp Storeを開き、アプリ名を検索します。検索結果だけで判断せず、アプリの正式名称と開発元が案内ページの情報と一致しているかを確かめてください。非公式なコピーアプリや、似た名前の別アプリを選ぶと、設定項目やサブスクリプションの読み込み方法が異なることがあります。

  1. App Storeで Clash Plus を検索します。
  2. アプリの説明、開発元、対応OS、直近の更新情報を確認します。
  3. 「入手」をタップし、Face ID、Touch ID、またはApple Accountの認証を完了します。
  4. インストール後にアプリを起動し、通知やVPN構成に関する案内が表示されたら内容を確認します。

iOSでは、アプリが独自に端末全体の通信を自由に取得することはできません。システムが表示するVPN構成の追加許可をユーザーが承認し、アプリが用意したネットワーク拡張を有効にすることで、指定された通信の処理が始まります。これはAndroidのVpnServiceとは異なるiOS側の仕組みです。初回接続時に「VPN構成の追加」やパスコード入力を求められた場合、アプリが不審な動作をしているとは限らず、OSの保護機構による通常の確認である可能性があります。

確認ポイント

インストール直後に接続できなくても、アプリの不具合とは限りません。まだサブスクリプションが登録されていない、VPN構成の追加を承認していない、またはプロキシグループに接続先が選択されていない、という初期状態を順番に確認してください。

サブスクリプションを登録する方法

画面の名称はバージョンによって少し異なる場合がありますが、基本的な流れは「リンクをコピーする」「Clash Plusへ追加する」「設定を取得する」「有効化する」の4段階です。リンクを手入力すると文字の欠落や改行混入が起きやすいため、管理ページからコピーして貼り付ける方法をおすすめします。

  1. 利用中のプロキシサービスの管理ページを開き、ClashまたはiOS向けのサブスクリプションURLをコピーします。
  2. Clash Plusを起動し、設定、Profiles、サブスクリプションなどの管理画面を開きます。
  3. 追加ボタン、インポート、またはURL入力欄を選択し、コピーしたURLを貼り付けます。
  4. プロファイル名を必要に応じて入力し、保存または確認を実行します。
  5. 取得が完了したら、追加されたプロファイルを現在の設定として選択します。
  6. プロキシグループ画面で使用するノードまたは自動選択グループを指定します。

取得後にプロファイル名だけが表示され、ノードやプロキシグループが空になる場合は、URLの形式が対応していない可能性があります。サーバーが返す内容がHTMLのログイン画面になっていないか、認証期限が切れていないか、通信量の上限を超えていないかも確認してください。

複数のサブスクリプションを登録する場合は、名前にサービス名や用途を付けると管理しやすくなります。ただし、同じサービスの古いURLと新しいURLを同時に有効化すると、どの設定が使われているか分かりにくくなります。不要になったプロファイルは削除するか、無効なものとして整理しておきましょう。

初回接続とルールの選び方

サブスクリプションを追加しただけでは、必ずしも通信が始まるとは限りません。まずプロファイルを有効にし、次にプロキシグループで接続先を選び、その後にメイン画面の接続スイッチをオンにします。iOSの確認ダイアログが表示されたら、VPN構成の追加を承認してください。接続中はiOSのステータス領域にVPN接続を示す表示が出ることがあります。

プロキシグループには、手動選択型、URLテスト型、負荷分散型などが設定されていることがあります。初めて使う場合は、次のように選ぶと確認しやすくなります。

  • 手動選択:候補を一つずつ切り替えたいときに向いています。接続先ごとの違いを確認しやすい反面、毎回の選択が必要です。
  • URLテスト:指定されたテストURLへの応答時間をもとに候補を選びます。測定値が低くても、実際のサービスとの相性や混雑状況まで保証するものではありません。
  • 自動選択:設定提供者が用意したルールに従って経路を選びます。初心者には扱いやすい一方、問題が起きたときにどのノードを使っているか確認しにくいことがあります。

最初のテストでは、ブラウザで通常のページを開くだけでなく、直接接続にするサービスとプロキシ経由にするサービスの両方を確認します。すべての通信をプロキシへ送る設定が必要とは限りません。銀行、社内システム、家庭内機器などは、サービスの案内に従って直接接続へ分けた方が安定する場合があります。

自動更新とiOSでの運用設定

サブスクリプションは、登録した時点の設定を永久に固定するものではありません。サーバーのアドレス、ポート、暗号化方式、利用期限、プロキシグループの構成などが変更されると、クライアント側の情報も更新する必要があります。プロファイルの編集画面に更新間隔や手動更新の項目がある場合は、サービス提供者の案内に合わせて設定してください。

  • 通常利用では、短時間に何度も手動更新せず、案内された更新間隔を守ります。
  • 更新後にノード数が急に減ったときは、通信量上限、アカウント期限、配布サーバーの障害を確認します。
  • iOSの設定アプリでVPN構成を削除すると、Clash Plus側で再度許可が必要になることがあります。
  • 低電力モードやアプリの強制終了は、バックグラウンドでの更新や接続維持に影響する場合があります。
  • 長時間使わないときは接続をオフにし、必要な場面でオンにすることで不要な電池消費を抑えられます。

iOSはバックグラウンド動作を厳しく管理するため、アプリを完全に終了させた状態で常に更新や再接続が行われるとは限りません。接続が必要な時間帯にはアプリを一度開いて状態を確認し、プロファイルの最終更新日時と選択中のグループを確認すると、原因を切り分けやすくなります。

接続できないときの確認手順

接続できない場合は、いきなりプロファイルを削除するのではなく、問題の位置を分けて調べます。次の順番で確認すると、URLの問題、ノードの問題、iOSの許可問題を区別できます。

  1. 接続スイッチを確認する:Clash Plus内で接続がオンになっているか、iOSの設定アプリでVPN構成が有効になっているかを見ます。
  2. プロファイルの更新状態を見る:最終更新時刻、取得エラー、ノード数、プロキシグループの有無を確認します。
  3. 別のノードへ切り替える:一つのノードだけが停止している可能性があります。手動選択グループで別の候補を試します。
  4. ルールを確認する:テストしたドメインが意図せず REJECT や利用できないグループへ送られていないか確認します。
  5. 元のネットワークで試す:Wi-Fiとモバイルデータ通信を切り替え、特定ネットワークだけのDNSやファイアウォール問題かを切り分けます。

サブスクリプション取得そのものに失敗する場合は、アプリ内の接続設定を変更する前にURLの有効性を確認します。リンクの末尾が欠けている、URLに空白が入っている、サービス側の認証が期限切れになっている、配布サーバーが一時停止している、といった原因が多くあります。取得は成功するものの特定サイトだけ開けない場合は、ノードではなくルール、DNS、対象サービス側の制限を調べる方が適切です。

切り分けの要点

VPN表示が出ていても、すべての通信が正常とは限りません。VPN構成が有効であることは「通信を処理する経路が起動した」ことを示すだけで、選択中のノードが応答していることや、ルールが期待どおりに評価されていることまで保証するものではありません。

安全に使うための確認事項

無料で導入できることと、すべての通信が無条件に安全であることは同じではありません。Clash Plusは通信経路を選択するクライアントであり、利用するプロキシサービスの運用方針、ログ管理、接続先の信頼性を自動的に保証するものではありません。アカウント情報や決済情報を入力するサービスでは、提供元の説明と利用規約を確認し、重要な通信にどの経路を使うかを把握しておきましょう。

また、サブスクリプションURLを第三者へ渡さないこと、不要な構成プロファイルを削除すること、App Store以外から配布された不明な構成ファイルを安易に読み込まないことも重要です。通信が遅いときに、設定を無制限に追加するより、使用中のプロファイル、グループ、ルール、DNSの状態を一つずつ確認する方が安全で再現性のある対応になります。

Clash Plus iOS版は、App Storeから導入でき、サブスクリプションを登録すれば比較的短い手順で使い始められるクライアントです。まずは公式配信ページからアプリを入手し、対応形式のURLを一つだけ登録して、VPN許可、プロファイル、プロキシグループ、ルールの順に確認してください。初期設定を整理しておけば、iPhoneとiPadの用途に合わせて、必要な通信だけをプロキシ経由にする運用を組み立てやすくなります。

クライアントをダウンロード

まずは2つの横取り方式の仕組みを理解する

Clashを使い始める前に、ネットワーク通信がどのようにしてプロキシへ「横取り」されるのかを理解しておくことは、個々のスイッチ名を覚えるよりもはるかに重要です。Clashおよびその派生コアであるClash Meta(mihomo)は、まったく異なる2つのアプローチを用意しています。1つは「システムプロキシ」、もう1つは「TUNモード」です。両者が解決しようとしている課題は同じ——デバイスから送信される通信をClashのルールエンジンに通してから転送する——ですが、介入する階層が根本的に異なり、それが適用範囲・互換性・設定コストの差につながっています。

システムプロキシはOSレベルで提供される設定インターフェースで、本質的には「対応するアプリへ、まずこのアドレスとポートにHTTP/HTTPSリクエストを送るように」指示する仕組みです。WindowsやmacOSには標準でシステムプロキシの設定項目があり、ブラウザや一部のダウンロードツール、IDEのネットワークコンポーネントがこの設定を読み取って動作します。一方、TUNモードは発想がまったく異なります。システム内部に仮想ネットワークインターフェース(Virtual Network Interface)を作成し、OSはこの仮想アダプタを実際のネットワーク出口として扱います。ルーティングテーブルの判定によりこの出口を経由すべきと判断されたIPパケットは、送信元のプロセスや使用プロトコルを問わず、まずこの仮想アダプタに流れ込み、その後Clashコアが解析・ルール照合を行い、対応するノードへ転送します。

システムプロキシ:軽量だが構造上どうしても穴がある

システムプロキシの利点は設定が簡単で、リソース消費が少なく、オン/オフの切り替えも柔軟なことです。Clashに初めて触れるユーザーの多くはまずこの方式から使い始めます。ただしその仕組みは、アプリケーション側が積極的に「協力」することを前提としています。アプリ内部がシステムや環境変数からプロキシアドレスを読み取り、自らそのアドレスに接続してリクエストを転送する必要があるのです。つまり、この約束事に従うアプリだけが正しく横取りされる仕組みです。

問題はまさにここにあります。すべてのネットワーク通信を行うアプリがシステムプロキシ設定を読み取るわけではなく、代表的な迂回パターンとしては以下が挙げられます。

  • 一部のコマンドラインツールやバックグラウンドサービスはシステムプロキシの環境変数を読み取らず、HTTP_PROXY/HTTPS_PROXYを別途手動で設定する必要があります。
  • 一部のアプリはハードコードされた直接接続ロジックや非標準ポートでの通信を採用しており、システムプロキシの設定が一切効きません。
  • UDPプロトコルの通信(一部のリアルタイム通信やゲーム加速のシーンなど)は、システムプロキシの対象範囲外になることが多く、システムプロキシは主にTCPベースのHTTP/HTTPSリクエストを想定した設計です。
  • モバイル向けアプリの実装はより分散しており、多くのアプリがOSの下位ネットワークライブラリを直接呼び出して接続するため、アプリ層のプロキシ設定を素通りしてしまいます。

つまり、システムプロキシは一種の「紳士協定」のようなものです。協力的なアプリは素直にプロキシ経由で通信しますが、協力しないアプリはそのまま直接通信を続けます。Clashを起動しているのに、あるクライアントで「プロキシに接続されていません」と表示されたり、想定と異なる結果になったりするのは、多くの場合ルール設定が間違っているのではなく、そのアプリがそもそもシステムプロキシの経路を通っていないことが原因です。

TUNモード:ネットワーク層で一括横取り

TUNモードの発想はより徹底しています。アプリが「協力する意思」を持っているかどうかに依存せず、OSのネットワークプロトコルスタック層に仮想ネットワークアダプタを差し込み、ルーティングテーブルの規則と組み合わせて、デバイス上のほぼすべての対象IPパケットをこの仮想インターフェースへ誘導します。パケットが仮想アダプタに入った後、Clash Meta(mihomo)コアがユーザー空間でプロトコル解析(一般的にはgVisorまたはOS標準スタックのいずれかの実装方式)、ドメイン照合、ルール判定を行い、どのノード経由にするか、あるいは直接接続にするかを決定します。

横取りがアプリ層ではなくネットワーク層で行われるため、TUNモードはアプリの種類をほとんど選びません。ブラウザ、コマンドラインツール、ゲームクライアント、OS自体のバックグラウンドサービスであっても、ルーティング条件に合致する通信であればすべて一括で管理対象となり、システムプロキシでは扱えなかったUDP通信も含まれます。ゲームや音声通信、クロスプラットフォームクライアントを細かく振り分けたいユーザーが最終的にTUNモードへ移行するのはこのためです。

注意

TUNモードは仮想ネットワークアダプタの作成が必要なため、通常は管理者権限が求められます(Windowsでは管理者として実行、macOS/LinuxではNetwork ExtensionまたはRoot権限が関係します)。初回有効化時にシステムから権限許可のプロンプトが表示されるのは正常な動作です。

互換性と安定性の実際の差

適用範囲が広いことは、TUNモードにコストがないことを意味しません。通信がネットワーク層で捕捉され、ユーザー空間のプロトコルスタックで処理されてから転送されるため、パケットが経由する封装・解析の層が増え、理論上はわずかな性能オーバーヘッドが発生します。低性能なデバイスや遅延に極めて敏感な用途では差を感じる場合があります。また、仮想アダプタは端末のルーティングテーブル、ファイアウォール設定、VPNクライアントと相互に影響し合う可能性があります。

  • 同じ端末で他のVPNソフトや仮想ネットワークツールを併用している場合、ルーティングテーブルが競合し、一部通信が想定外の経路をたどることがあります。複数の仮想アダプタ系ツールを同時に有効化しないことを推奨します。
  • 企業内ネットワークや一部のセキュリティソフトは、新たに追加された仮想ネットワークインターフェースを検知してブロックや警告を出すことがあります。TUNモードを初めて有効にする前に、利用しているネットワーク環境のポリシーを確認しておくとよいでしょう。
  • OSごとにTUNデバイスの実装は異なり、WindowsはWintunドライバ、macOSはNetwork Extensionフレームワークを利用します。設定画面や権限申請の方法には多少の差がありますが、エンドユーザーが操作するオン/オフの体験自体はほぼ同じです。

対照的に、システムプロキシにはこうした低レベルのリスクがなく、設定すれば即時に反映され、無効化すれば即時に元に戻ります。不具合が起きた際の調査も分かりやすく、多くの場合「どのアプリがプロキシ設定を読み取っていないか」に行き着きます。これが、軽量な用途では今もシステムプロキシが標準的な選択肢である理由です。

適用範囲の比較一覧

比較項目システムプロキシTUNモード
動作する階層アプリ層。アプリ側がプロキシ設定を読み取ることに依存ネットワーク層。仮想アダプタとルーティングテーブルで一括処理
対応プロトコル主にHTTP/HTTPSを対象。UDP対応は限定的TCP・UDPともに対応し、プロトコル種別をほぼ問わない
追加権限の要否通常は管理者権限不要仮想アダプタ作成に管理者/Root権限が必要
互換性のリスク低い。ただし「プロキシを迂回する」アプリが存在する他の仮想ネットワークツールと競合する可能性がある
代表的な適用シーン日常的なブラウジング、軽い作業、一時的な利用ゲームの振り分け、コマンドラインツール、プロセス単位での細かい制御

システムプロキシを迂回しやすいアプリの例

あるアプリの通信がいつもプロキシルールに従わない場合、おおむね以下のいずれかに該当します。

  1. コマンドラインツールや開発ツール:パッケージマネージャーやビルドツールなど、標準ではシステムプロキシを読み取らないものが多く、環境変数やツール独自のプロキシ設定を個別に行う必要があります。
  2. 独自のネットワークスタックを持つクライアント:チャットアプリやクラウドストレージ同期系のソフトの一部は、接続速度を優先して独自にネットワーク処理を実装しており、システムプロキシのインターフェースを経由しません。
  3. ゲームや音声通信:多くのゲームはリアルタイム通信にUDPを使用しますが、システムプロキシのUDP対応は総じて弱いか対応していません。この種の通信は基本的にTUNモードでしか横取りできません。
  4. OSのバックグラウンドサービスや更新機能:OS自体の更新チェックやテレメトリ送信といったバックグラウンド処理は、通常ユーザーが設定したプロキシを経由しません。

このような問題に遭遇したときは、アプリごとにプロキシ設定の入り口を探すよりも、TUNモードへ切り替えてネットワーク層で一括対応してしまう方が「横取り漏れ」を効率的に解決できます。

TUNモードへ切り替えるべき場面

以上の比較を踏まえると、次のような判断基準が導けます。

  • 日常的なWebブラウジングや、少数のアプリのプロキシ利用だけで十分な場合は、システムプロキシで足ります。設定の手間も少なく済みます。
  • システムプロキシの約束事に従わないアプリ(コマンドラインツール、ゲーム、一部のチャットアプリなど)を多く使っている場合や、UDP通信をルールで振り分けたい場合は、TUNモードのほうが根本的な解決策になります。
  • プロセス単位で細かく振り分けたい場合(特定のアプリだけ直接接続にし、それ以外はプロキシ経由にするなど)、TUNモードとClash Meta(mihomo)のプロセスルール(process-name)を組み合わせることで、アプリ層では実現できない粒度の制御が可能になります。
  • 企業ネットワークやセキュリティソフトの制約が厳しい環境では、仮想アダプタがブロックされないかを事前に確認したうえでTUNモードの有効化を判断し、業務用ネットワークへの影響を避けることを推奨します。
おすすめの進め方

多くのクライアントはシステムプロキシとTUNモードの併用や素早い切り替えに対応しています。まずシステムプロキシでノードとルールが正常に動作するか確認し、問題がなければTUNモードを有効にして適用範囲を広げると、トラブル調査の際の見通しが立てやすくなります。

設定ファイル上の実際の違い

設定ファイルの観点で見ると、システムプロキシはClashの設定に特別な記述を追加する必要がなく、クライアント画面上のスイッチひとつでOSのAPIを直接呼び出して完了します。一方TUNモードは、通常設定ファイル内で有効状態・スタックの種類・DNSを横取りするかどうかなどの項目を明示的に指定する必要があります。Clash Meta(mihomo)の一般的な記述例は次の通りです。

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

auto-routeは通信を仮想アダプタへ誘導するルーティングテーブルを自動設定するかどうかを決め、dns-hijackはDNSクエリを横取りして、一部のドメイン名解決がルール照合を迂回してしまうのを防ぎます。これらの項目はほとんどのGUIクライアントで画面上の簡単なスイッチとして実装されており、通常のユーザーが設定ファイルを直接編集する必要はありませんが、意味を理解しておくと稀に発生する接続不具合の調査に役立ちます。

よくある質問

TUNモードを有効にしたら、システムプロキシも必要ですか?基本的に同時に有効にする必要はありません。TUNモードはシステムプロキシが処理できる範囲をすでに包含しており、両方同時に有効にするとルーティング判定が混乱しやすいため、どちらか一方を選ぶことを推奨します。

TUNモードにすると全体の速度が遅くなりますか?封装・解析の分だけオーバーヘッドは確かに存在しますが、現行の多くの端末ではその差はほとんど感じられません。速度差の多くは接続方式そのものよりも、利用しているプロキシノードの回線品質に起因します。

スマートフォンにもTUNモードはありますか?Androidでは通常VpnServiceインターフェースを通じて同様の効果を実現しており、考え方はデスクトップの仮想アダプタと同じで、アプリ層で処理できない通信も横取りできます。iOSではNetwork Extensionフレームワークによって同種の機能が実現されています。

クライアントをダウンロード