プロトコルガイド · 必要な項目を参照

Clashのプロトコルとコアの基礎知識

プロトコル設計、コアの互換性、サブスクリプション形式、デバイスの選び方を解説します。

インストールや接続が初めての場合は、まずクイックスタートガイドをご覧ください。このページでは選択肢ごとの違いを解説し、クライアントでどのプロトコルを選べばよいか判断するための情報を紹介します。プロトコル名だけで回線品質は判断できません。サーバー設定、ローカルネットワーク、デバイスの条件を踏まえて検討してください。

6種類のプロキシプロトコル Clash / Meta / mihomo モバイルの電池消費 サブスクリプションの互換性

01 / 判断の順序

プロトコル選びを左右する4つの要素

クライアント、コア、プロトコル、回線

クライアントは設定のインポートや保存、システム権限の要求などを行う操作画面です。コアはルールの解析や接続の確立、データの転送を担います。プロトコルはクライアントとサーバー間の認証、データの構成、転送方法を定めます。回線にはローカルネットワークへの接続、経由するルート、サーバー側の出口が含まれます。この4つは連携しますが、互いに置き換えられるものではありません。画面を変えてもコアが変わるとは限らず、プロトコルを変えても出口は変わらない場合があります。すべてのアプリが速くなるとも限りません。

たとえば、同じサーバーがSSとTrojanの両方を提供していても、処理能力や出口帯域、上流の経路を共有している可能性があります。夜間に混雑すれば、どちらのプロトコルも速度が落ちることがあります。名称だけを見ていると、回線の混雑をプロトコルの欠点と誤解しかねません。反対に、同じプロトコルでもサーバーが違えば、証明書の設定、輻輳制御、ユーザーごとの速度制限、同時接続数の制限などが異なる場合があります。比較する際は、まず同じ回線を使っているか確認し、そのうえでプロトコルによる追加コストを検討しましょう。

接続の流れを分けて見る

ウェブページを開くと、通常は名前解決、接続の確立、安全な通信のためのハンドシェイク、リクエストの送信、コンテンツのダウンロードの順に処理されます。ノードテストで表示される時間は、その一部だけを測っている場合があり、ページ全体の読み込み時間を示すとは限りません。ブラウザーは画像、フォント、スクリプトを並行してリクエストし、確立済みの接続を再利用することもあります。テストは速いのにページ表示が遅い場合、接続先の応答、名前解決の場所、ルールの選択が異なる可能性があります。暗号化アルゴリズムの複雑さだけが原因とは限りません。

トランスポート層とプロキシプロトコルも分けて考える必要があります。TCPは信頼性と順序を保つバイトストリームを提供し、データが失われると再送します。UDPはデータグラムを提供しますが、順序どおりの配送を保証しません。QUICはUDP上で動作し、暗号化、信頼性のあるストリーム、輻輳制御を備えています。単に信頼性をなくした仕組みではありません。ノードがUDP転送に対応していても、そのノード自身がQUICを使っているとは限りません。アプリのデータ形式と、クライアントからサーバーまでの転送方式は別の要素です。

まず対応状況を確認し、その後に使い勝手を比較：クライアントの実装、コアの機能、サーバーの設定、ローカルネットワークを順に確認しましょう。メニューにプロトコルが表示されていても、画面から設定できるというだけで、現在のサーバーが対応しているとは限りません。

条件をそろえて比較する

比較する前に、デバイス、接続ネットワーク、プロキシモード、接続先のウェブサイト、テスト時刻を記録します。可能であれば同じ出口を使い、ほかのデバイスによる大容量通信を止めます。まず通常のウェブ閲覧で接続を確認し、その後、長時間のダウンロードと操作時の応答を測定しましょう。ルールやDNS設定を固定してプロトコルだけを切り替えるなど、一度に変更する項目は1つにします。最も速かった1回だけでなく、複数回の結果とばらつきを記録すると、普段の使い勝手を把握しやすくなり、一時的なキャッシュの効果も見分けられます。

セキュリティも層ごとに判断する必要があります。通信の暗号化が保護するのは該当する通信経路であり、サーバー運営者の権限を変えるものではありません。また、ウェブサイト自体のHTTPSに代わるものでもありません。サイト証明書はアプリ側で通常どおり検証してください。ノードのサーバー名、証明書名、実際の接続先アドレスは異なる場合がありますが、デプロイ構成に沿っている必要があります。証明書エラーが発生したら、名前、時刻、信頼チェーンを確認し、接続するために検証を無効化するのは避けてください。

実際の選択では、互換性、安定性、リソース消費、最大スループットの順に確認するとよいでしょう。まずデバイスが対応していない種類や、ネットワークで許可されていない種類を除外します。次に長時間使って安定するかを見て、最後に許容できる電池消費や通信量の範囲で速度を比較します。現在の設定でウェブ閲覧、会議、ファイル転送に問題がなければ、新しいプロトコルという理由だけで移行する必要はありません。以下の違いは候補を絞るための情報であり、プロトコルに固定の順位を付けるものではありません。

02 / 定番プロトコル

SSとVMess、それぞれの設計上の特徴

SS：シンプルなデータ転送方式

Shadowsocksは一般にSSと表記され、暗号化プロキシによる転送を中心に設計されています。プロトコルの構造は比較的シンプルです。複雑なルーティングをプロトコル自体で担うのではなく、クライアントとサーバー間のデータを保護し、宛先へ転送することを目的としています。ルールの照合、グループの選択、アプリの通信制御は、引き続きクライアントとコアが担当します。幅広く実装されているため、互換性や導入のしやすさを重視する環境でよく利用されます。ただし、対応する暗号方式は実装によって異なります。

SSの設定では、サーバー、ポート、暗号方式、パスワードを必ず確認してください。暗号方式はクライアント側で自由に変更できる最適化項目ではなく、サーバーと一致させる必要があります。古いストリーム暗号方式と、後から登場したAEAD方式は同じものではありません。SS 2022には独自の仕様と鍵の要件があります。サブスクリプションにSSと書かれているだけでは利用可能と判断できません。現在のコアが具体的な暗号方式に対応しているかも確認しましょう。

一般的なAEADの実装では、AES-GCMやChaCha20-Poly1305などを選択できます。ハードウェアアクセラレーションに対応したプロセッサーではAESの実装が有利な場合がありますが、省電力デバイスでは異なる結果になることもあります。アルゴリズム名だけでスマートフォンの電池持ちを判断することはできません。また、速度を試すためだけにサブスクリプションの暗号方式を変更するのも避けましょう。サーバーが複数の設定を提供している場合は、同じ回線と実際の負荷で比較し、CPU使用率が高止まりしていないか確認してください。

VMess：認証と転送方式を組み合わせる

VMessはV2Rayのエコシステムから生まれたプロトコルで、ユーザー認証とデータ保護の仕組みを備え、さまざまな転送方式と組み合わせて使われます。画面上でVMessと表示されるノードは、通常のTCPを使う場合もあれば、WebSocketなど実装が対応する別の転送方式を組み合わせる場合もあります。TLS層、リバースプロキシ、パスの設定も接続に影響します。そのため、どちらもVMessと表示されていても、ハンドシェイクの手順、サーバー構成、問題が発生する箇所は大きく異なる可能性があります。

VMessの設定では、通常ユーザーID、セキュリティ方式、転送パラメーターを指定します。古い資料にある互換用フィールドを、現在の実装にそのまま適用できるとは限りません。プロトコル認証では時刻の同期が必要です。デバイスの時計が大幅にずれていると、ネットワークに問題がなくても認証に失敗することがあります。失敗が続く場合は、まずシステムの自動時刻設定を有効にし、サーバー情報が有効か確認してから、コアのログを確認してください。認証エラーをDNSの問題と誤解して、名前解決サーバーを何度も切り替えるのは避けましょう。

比較項目SSVMess
主な設定項目暗号方式、パスワード、ポートユーザーID、セキュリティ方式、転送パラメーター
主な違いが生じる要因対応方式、プラグイン、実装の違い転送方式の組み合わせ、TLS、認証の互換性
トラブル対処の入口方式と認証情報を確認時刻、認証、トランスポート層を確認

ノード名だけでプラグインやカプセル化方式を判断しない

一部のSS設定では追加のプラグインが必要です。共有リンクのパラメーターに、プラグイン名とオプションが記載されている場合があります。クライアントが基本的なSS情報をインポートできても、該当するプラグインを実行できるとは限りません。互換性のある一部の実装だけに対応するものもあれば、プラグインを設定する項目自体がないものもあります。VMessでも同様です。サブスクリプションの解析に成功したのは、フィールドを読み取れたことを示すだけで、実際の転送方式をコアが実装している必要があります。SSやVMessに対応しているかだけでなく、どの組み合わせに対応しているのかを提供元に確認しましょう。

どちらのプロトコルも、名前だけでアプリのUDP通信が使えるとは限りません。クライアントのUDP設定、コアの対応状況、サーバーの転送設定、経由するネットワークが制約になる可能性があります。ウェブは見られるのに音声通話やゲームに問題がある場合は、まずアプリの通信が想定したルールに一致しているか確認し、その後UDP転送の条件を調べましょう。安易にグローバルモードに切り替えるとルールの問題が見えにくくなりますが、サーバー側にない機能が補われるわけではありません。

安定しているSS設定をすでに使っている場合は、現在の組み合わせを維持し、暗号方式とプラグインの互換性を重点的に確認しましょう。VMessを使っている場合は、転送フィールド、時刻、サブスクリプションの提供元に特に注意してください。新しい環境を作る際、特定のプロトコル名にこだわって複数の転送層を重ねる必要はありません。層を追加するたびに、一致させるパラメーターが増え、証明書、パス、リバースプロキシの設定に問題が起きた際の調査も複雑になります。

03 / TLSと認証

TrojanとVLESSの組み合わせと注意点

Trojan：TLSで通信を保護

Trojanの一般的な構成では、プロキシ認証とデータ転送をTLS接続の中で行い、実績のあるTLS実装で通信を保護します。利用できるかどうかは、パスワードやポートだけでなく、サーバー名、証明書チェーン、サーバー側のTLS設定にも左右されます。既存の証明書やサーバー管理のノウハウを活用できる設計ですが、ポートが開いていれば接続できるという意味ではありません。また、Trojanと表示されるすべての拡張実装が相互に置き換え可能なわけでもありません。

接続先アドレスはクライアントが実際に接続する宛先で、SNIはTLSハンドシェイク時に通知するサーバー名です。証明書の検証では、名前と信頼関係も確認します。これらの値が同じ場合もあれば、デプロイ方式によって異なる場合もあります。サブスクリプションにサーバー名が指定されている場合は、サーバーの要件に従って維持してください。接続先がIPアドレスだからといって削除してはいけません。証明書の期限切れ、デバイスの時刻のずれ、名前の不一致、証明書チェーンの欠落があると、プロキシ認証に進む前に接続が終了することがあります。

Trojanでは、一般的にTCPとTLSを組み合わせるため、初回接続時にそれぞれの確立処理が必要です。接続を再利用すれば確立のコストを減らせますが、実際の効果はクライアント、サーバー、アプリのリクエスト方式によって異なります。ブラウザーで複数のサイトを開く場合も、接続の構成によって体感が変わります。初回の接続待ちだけを見て、プロトコルが常に遅いと判断することはできません。1回のダウンロード速度だけで、ウェブページの初回表示も必ず速いと結論づけるのも適切ではありません。

VLESS：認証層だけでは安全性は完結しない

VLESSもV2Ray関連のエコシステムから生まれたプロトコルで、主に認証と転送を担います。VMessと同じデータ暗号化層はプロトコル自体に備わっていません。実際の構成では、通常TLSなど対応するセキュリティ方式と組み合わせます。設定の暗号化フィールドが空欄、または追加の暗号化を行わないことを示していても、直ちに通信が保護されていないとは限りません。外側のセキュリティ設定を確認してください。反対に、有効な保護が確立されていない場合は、VLESSという名前だけで通信が安全だと判断できません。

VLESSの互換性は、転送方式、TLS設定、サーバーが要求するflowなど、複数のパラメーターの組み合わせで決まることがよくあります。REALITYを使う構成もありますが、これは通常のTLSフィールドに別の名前を付けたものではなく、個別に確認が必要なセキュリティハンドシェイク方式です。公開鍵、短いID、サーバー名、クライアントの対応状況を一致させる必要があります。別々の設定例を誤って組み合わせると、インポート時の構文解析には成功しても、接続には失敗し続ける場合があります。

同じ転送方式でも詳細を確認する

WebSocketを組み合わせる場合は、パス、リクエストヘッダー、リバースプロキシの転送設定を確認します。gRPCではサービス名やHTTP/2の設定が関係することがあります。パスの文字列は区別される場合があり、末尾のスラッシュが変わるだけでもサーバー側のルーティングに影響する可能性があります。接続後すぐに切断されても、認証情報の誤りとは限りません。リクエストが誤ったバックエンドに届いている可能性もあります。まずTLSが完了したか、次に転送層が確立したかを確認し、最後にプロトコル認証を調べましょう。

一部のパラメーターは、特定のサーバーハンドシェイクにクライアントを対応させるためのもので、汎用的な速度向上設定ではありません。多重化を使う場合も、プロトコルの組み合わせが対応しているか、接続がどう分離されるか、サーバーにどのような制限があるかを確認してください。複数のリクエストを少数の接続にまとめればハンドシェイクを減らせる一方、接続に問題が起きた際に多くのリクエストへ影響する可能性があります。デフォルト設定で動作しているなら、まずはそのまま使い、再現できる問題がある場合にだけ変更前後を比較しましょう。

実際の選択では、適切な証明書と明確な構成手順があるTrojanは、層ごとに問題を調べやすい傾向があります。VLESSは組み合わせ全体をまとめて確認しましょう。初心者が複数の記事からパラメーターを手作業で組み合わせるのは避けてください。提供元が現在のコア向けに生成した設定を優先し、元のファイルも比較用に保存します。クライアントに不明なフィールドが表示された場合は、削除してインポートできたことを解決とみなすのではなく、まずコアの対応状況を確認してください。

どちらのプロトコルも、ウェブ閲覧や長時間接続が必要な用途に適する場合がありますが、常にどちらかが省電力とは限りません。外側の転送方式、ハンドシェイクの頻度、接続維持、無線信号の状態は、認証層の違いより大きく影響することがあります。モバイルで比較する際は、接続先、アプリ、バックグラウンド権限をそろえ、待機時と使用時の両方を観察してください。信号の変化やシステムによるバックグラウンド制限を、プロトコル固有の特徴と誤認しないようにしましょう。

04 / UDPを使った転送

Hysteria2とTUICに必要なネットワーク条件

共通の基盤はQUICであり、任意のUDP通信ではない

Hysteria2とTUICはいずれもQUICベースの設計で、特定のネットワーク環境におけるプロキシ通信の改善を目的の1つとしています。QUICはユーザー空間のプロトコル実装で、信頼性のあるストリーム、暗号化、輻輳制御を提供し、下位層ではUDPデータグラムを使います。従来のTCP構成とは異なる制御が可能ですが、ローカル接続、中間経路、サーバーがUDP通信を許可していることが前提です。UDPが制限されていれば、プロトコル名が適切でも性能を発揮できません。

QUICでは、異なるストリーム間で、同一TCPバイトストリームのように順序どおりの配送を待つ必要がないため、ストリームをまたいだ待ち時間を減らせる場合があります。ただし、各ストリームは利用可能な帯域や輻輳状態を共有します。パケットロスからの回復も必要で、物理回線の容量が増えるわけではありません。ネットワークの混雑、無線の再送、サーバーの処理能力不足も使い勝手に影響します。QUICはパケットロスや遅延の影響を受けないと考えると、設定調整に対する期待を誤ることになります。

Hysteria2：帯域情報と輻輳制御

Hysteria2は初期のHysteriaとは異なる世代のプロトコルです。古い設定をタイプ名だけ変えて流用することはできません。高遅延やパケットロスのあるネットワークでのスループット向上を重視し、複数の輻輳制御方式を提供します。帯域に関する設定を使う構成もありますが、数値は想定する条件を示すものであり、測定結果ではありません。クライアントとサーバーが対応する方式、サーバー側の制限、帯域情報の提供状況によって実際の動作が決まります。

帯域を手動で設定する場合は、現在の接続ネットワークで継続的に得られる性能を基準にしてください。回線契約の公称速度ではなく、数値を大きくすれば速くなるわけでもありません。過大な設定はキューやパケットロス、帯域の競合を招き、同じネットワーク上の会議やウェブ閲覧の応答を悪化させる可能性があります。逆に、過小な設定ではスループットが制限されます。モバイル回線とWi-Fiを頻繁に切り替えるデバイスでは環境の変化が大きいため、まず提供元の推奨値や実装のデフォルト設定を使い、条件をそろえて比較しましょう。

TUIC：接続管理と実装の互換性

TUICもQUICベースで、認証、接続の多重化、データ転送の仕組みを備えています。実際に使う際は、プロトコルの世代と実装パラメーターが一致しているか確認してください。サブスクリプションにTUICと表示されているだけで、互換性の違いを無視できるわけではありません。ユーザーID、パスワード、輻輳制御、UDP転送に関する設定はサーバーの説明に従います。対応する任意フィールドはコアによって異なる場合があり、画面に保存できても、下位の実装に反映されているとは限りません。

TUICの実装によっては、初期データに関する仕組みなど、ハンドシェイクの待ち時間を減らす機能が用意されています。こうした機能はセッション再開やサーバーのポリシー、安全上の制約を受けるため、起動のたびにすぐ効果が出るわけではありません。初期データを使う場合は、リプレイ攻撃のリスクやリクエストの性質も考慮してください。接続待ちを少し減らすためだけに、一般ユーザーが関連設定をすべて有効にする必要はありません。サーバーが明確に対応し、検証済みの組み合わせを優先しましょう。

ウェブが見られても、UDP経路が使えるとは限りません：一般的なHTTPS通信はTCPで動作することがあります。QUIC系ノードを調べる際は、ノードが使うUDPポート、サーバーの待ち受け設定、ファイアウォールの条件を確認してください。同じアドレスのTCPポートだけをテストしても判断できません。

MTUとネットワーク切り替えを前提条件として考える

トンネルのカプセル化ではデータのオーバーヘッドが発生し、利用できるパスMTUは接続方式によって変わります。小さなリクエストは通るのに、大きなデータ転送が繰り返し止まる場合は、ログでデータグラムのサイズ、パスの検出、フラグメントに関する問題を確認します。ただし、MTUはすべてのタイムアウトに使える万能の解決策ではありません。証明書や認証の誤りは、MTUを下げても直りません。ハンドシェイクの成功とサーバーへの到達を確認してから、転送サイズと経路の互換性を調べましょう。

ネットワーク切り替え後の挙動は、実装によっても異なります。QUICには接続移行の仕組みがありますが、プロキシクライアント、サーバー、OSが常に接続を維持できるとは限りません。モバイル回線への切り替え、スリープからの復帰、アドレスの変更後には、再接続が必要な場合もあります。初回起動だけでなく、画面ロックからの復帰、アクセスポイントの切り替え、長時間のダウンロードをそれぞれテストしてください。モバイルでは、1回のテストでの最高速度より安定して再接続できることが重要です。

ネットワークがUDPを許可し、デバイスの処理能力にも余裕があり、既存のTCP構成がパケットロスのある経路で不調なら、Hysteria2やTUICを候補に加えられます。利用環境でUDPが頻繁に制限される場合は、検証済みのTCP系設定も用意しておきましょう。これらは特定の条件に対処するための選択肢であり、すべてのプロトコルを置き換えるものではありません。比較する際は出口をできるだけそろえ、サーバー回線の優位性をQUIC全般の特長と取り違えないようにしてください。

05 / 使い勝手の測定

接続速度、リソース、モバイルの電池消費

初回応答と継続的なスループットを分けて測る

接続速度には、クリックしてから最初の有効な応答が返るまでの時間と、接続確立後に継続してデータを転送する能力の少なくとも2つの観点があります。前者には名前解決、ハンドシェイク、接続先の応答が影響し、後者には帯域、輻輳制御、サーバー負荷が大きく影響します。プロトコルによって、片方が有利でも、もう片方は同程度の場合があります。短時間のウェブ閲覧、動画のバッファリング、大容量ファイルのダウンロードでは必要な性能が異なります。1つの測定用ファイルの結果ですべてのアプリを評価することはできません。

コールド接続とウォーム接続も分けて考えましょう。コールド接続では、名前解決をやり直してTLSやQUICのハンドシェイクを行う場合があります。ウォーム接続では、既存のセッションを再利用できることがあります。テスト前にクライアントを再起動したか、ブラウザーにキャッシュが残っているか、接続プールが有効かどうかも結果に影響します。初回接続を調べるときは、条件をそろえて接続を作り直します。普段のブラウジングを評価する場合は自然な接続再利用を維持し、状態を意図的に消去した際のコストを過大評価しないようにしてください。

リソース使用量に決まったプロトコル順位はない

CPU負荷は、暗号化、データのコピー、プロトコルスタックの処理、ルール照合、ログ記録など、さまざまな処理で発生します。ハードウェアアクセラレーション、OSのネットワークインターフェース、コアの実装によって結果は変わります。メモリー使用量は接続数、バッファー、ルールの規模、キャッシュに左右されます。クライアントがアイドル時に低負荷でも、同時接続が多い通信中も低いとは限りません。プロトコルの追加処理が少なくても、複雑なルールを含む構成全体が軽くなるとは限りません。

使用状況を見る際は、画面のプロセスとコアのプロセスを区別してください。デスクトップクライアントの画面は異なる技術で実装されている場合があり、ウィンドウを開いたときと閉じたときで負荷も変わります。タスクマネージャーで1つのプロセスだけを見ると、実際の転送を担うプロセスを見落とすことがあります。スマートフォンでは、OSのバッテリー統計、画面の使用時間、バックグラウンドでの動作時間をあわせて確認しましょう。短いテスト中に本体が熱くなっただけでプロトコルを評価するのは避けてください。特に、アップデートのダウンロードやメディア処理を同時に行っている場合は注意が必要です。

確認項目確認するポイント固定する条件
ウェブの応答最初の有効な応答、全体の読み込み時間、失敗回数接続先のページ、名前解決方式、接続状態
継続的なデータ転送安定した速度、速度の変動、同時利用時の応答出口、ファイルの提供元、テスト時間帯
モバイルの電池消費待機中と使用中の電池消費、バックグラウンド動作時間電波状況、画面の明るさ、アプリの負荷、権限

無線通信の起動とバックグラウンド接続の維持

モバイルの電池消費は暗号化処理だけで決まるわけではありません。無線モジュールは少量のデータ送信後もアクティブ状態を維持することがあり、頻繁なハートビート、ヘルスチェック、自動更新によって起動回数が増えます。電波が弱いと再送や送信出力の変化で消費電力が増えることもあります。待機中も電池が大きく減る場合は、まず定期タスクや接続維持の頻度を確認しましょう。認証方式を変えるだけでは、バックグラウンドのポーリングによる継続的な動作を解消できないことがほとんどです。

自動テストの設定は実際の使い方に合わせましょう。テスト間隔が短すぎる、候補ノードが多すぎる、切り替えが頻繁すぎると、余分なリクエストが発生し、既存の接続が中断されることもあります。自動選択が必要な場合は、使わない候補を減らし、デフォルトの間隔で足りるか確認してください。自動プロキシグループの選択方法については、url-test・fallback・load-balanceの比較もご覧ください。これらは同じ自動速度テスト機能ではありません。

TUNモードはより多くのアプリ通信を取り込める場合があります。一方、システムプロキシはアプリがプロキシ設定を参照する必要があるため、処理する通信量が異なることがあります。電池消費を比較する際は、通信の取り込み方式を固定してください。そうしないと、対象となる通信範囲が異なる設定同士の比較になります。AndroidのVPNサービスやバックグラウンド制限、iOSのネットワーク拡張機能の管理も、接続のライフサイクルに影響します。必要なバックグラウンド動作を許可すると安定性が向上しますが、1つのクライアントのためにすべての省電力機能を無効にする必要はありません。

普段の使用時と画面ロック中の待機時について、近い時間の記録を複数回取りましょう。システム更新、テザリング、電波状況の変化を除外してから、特定の設定で電池消費が継続的に増えるか判断してください。最適化する場合は、まず不要なテスト、詳細すぎるログ、重複するサービスを減らし、その後にプロトコルを評価します。速度の問題はノード、回線、ローカル設定を分けて調べる方法を参考にし、電池の問題はデバイス本体の統計情報も確認してください。

06 / 実装と機能

Clash、Meta、mihomoの関係

設定形式が似ていても、機能は同じとは限らない

Clashは幅広く利用されるプロキシ設定とルールのエコシステムを築き、多くのクライアントがYAML形式やコントロールインターフェースを引き継いでいます。Clash Metaはこのエコシステムをもとに、プロトコルやネットワーク機能を拡張しました。mihomoはMetaコアのメンテナンスを引き継いでいます。資料ではMeta、Clash Meta、mihomoなど複数の呼び方が使われています。チュートリアルを読む際は、コア、クライアント、サブスクリプション形式のどれを指しているのか確認し、過去の名称を独立した完全互換の製品と誤解しないようにしましょう。

オリジナルのオープンソース版Clash、かつて追加機能を提供していたPremium版の系統、Meta/mihomoは、機能範囲が同一の実装ではありません。あるコアで動作した古いチュートリアルが、別のコアでも同じDNS、TUN、ルールプロバイダーのフィールドに対応するとは限りません。古いクライアントには特定のコアが固定で同梱されている場合もあります。画面が開けても、新しいサブスクリプションに適した機能を備えているとは限りません。実際に動作中のコア情報と最新のドキュメントを確認してください。

まずコアを調べ、その後クライアントの機能を確認

デスクトップクライアントでは、通常「バージョン情報」「設定」「ログ」などにコアの名前や起動情報が表示されます。確認時は、クライアントのタイトルやインストーラーのファイル名だけを見て判断しないでください。コアの切り替えや更新ができるクライアントでは、切り替え後に実行中の情報を再確認しましょう。クライアントが実行用の設定を自動生成する場合は、画面の設定がインポートしたファイルのDNS、ポート、TUNの項目を上書きするかどうかも確認してください。サブスクリプションを編集しても、実際の動作設定が変わるとは限りません。

プロトコルへの対応は、機能の一部にすぎません。ルールの種類、ルールセットの形式、ドメイン名の解決方式、仮想ネットワークインターフェースの実装、外部コントロールインターフェースの挙動も使い勝手に影響します。2つのコアが同じノードを認識できても、デフォルトのDNS、ルーティングの優先順位、接続処理が異なれば動作も変わる可能性があります。移行時は最小限の設定を残し、まず基本的な転送を確認します。その後、元のルールを段階的に追加してください。起動に成功しただけで、すべての機能を移行できたと判断してはいけません。

クライアント選びはこちら：初めて選ぶ場合は、まずダウンロードセンターでClash Plusを確認し、その後プラットフォームに応じてClash Verge RevやFlClashなどを比較してください。各クライアントのプロトコル対応状況は、それぞれの実装に基づいて確認する必要があります。特定のサブスクリプションをインポートできても、同じコアを使用しているとは限りません。

各プラットフォームの対応状況と提供終了クライアント

当サイトでは、Windows向けにClash Nyanpasuと、開発が終了したClash for Windowsも掲載しています。macOS向けには開発が終了したClashX Meta、Android向けにはClash Meta for AndroidとSurfboard、Linux向けにはClash Verge RevとFlClashがあります。これらは同じ画面を別のデザインにしただけのアプリではありません。特にSurfboardは、独自に対応する設定形式を使う必要があります。Androidのダウンロード欄にあるという理由で、完全なClash YAMLをそのまま読み込めると考えないでください。

iOS向けにはClash PlusのApp Storeページを掲載しています。公式サイトはclashplus.ioです。モバイルOSでは、ネットワーク拡張機能、バックグラウンド動作、通信の取り込み方法に独自の制約があるため、デスクトップ用チュートリアルのシステムプロキシ設定やサービスのインストール手順をそのまま適用できません。別のプラットフォームへ移行する際は、まずクライアントが対応するサブスクリプション形式とプロトコルの組み合わせを確認し、その後システム権限を確認してください。同じ認証情報を使っていても、すべてのプラットフォームでまったく同じ実行設定を使えるとは限りません。

設定全体を置き換えず、層ごとに戻す

古いコアから移行する前に、元のサブスクリプションとローカルの上書き設定を保存し、モード、DNS、通信の取り込み方法を記録してください。まず少数のノードで認証と転送を確認し、次にプロキシグループ、ルールプロバイダーの順に追加します。最後にTUNなどシステムレベルの機能を有効にします。各段階でウェブ閲覧、名前解決、必要なアプリの接続をテストしてください。問題が起きても前の段階へ戻せるため、完全な設定の中から複数の非互換フィールドを同時に探す必要がありません。

コアをサーバーやルーターに導入する場合は、起動管理、待ち受け範囲、権限管理も必要です。外部コントロールインターフェースを公開サービスとして使わず、信頼できるローカル環境や必要な管理環境に限定し、デプロイ要件に応じてアクセスを保護してください。一般のユーザーには、システムプロキシや権限を管理しやすいGUIクライアントがおすすめです。自動実行、サービス管理、ルーターでの通信制御が明確に必要な場合に限り、コアを直接使い、関連するシステム設定を管理しましょう。

07 / 設定の共有

サブスクリプション形式と設定の互換性

共有リンク、ノード一覧、完全な設定ファイル

サブスクリプションは設定を受け渡す方法であり、プロキシプロトコルではありません。サブスクリプションURLから完全なClash YAMLが返ることもあれば、エンコードされた共有リンクの一覧や、特定のクライアント専用の形式が返ることもあります。共有リンクには通常1つのノード情報が含まれますが、完全な設定ファイルにはプロキシグループ、ルール、DNS、待ち受けポートなどが含まれる場合があります。両者は情報量が異なるため、ファイルをダウンロードできたからといって、インポート後に想定どおりの振り分けができるとは限りません。

完全なYAMLでは、ノードは通常proxies、プロキシグループはproxy-groups、ルールはrulesに記述します。プロバイダーを使う場合は、proxy-providersやrule-providersを参照することもあります。クライアントによって、インポートした内容を設定ファイルとして保存する場合と、ノード情報だけを抽出して設定を再生成する場合があります。まず、インポート先がどの形式を必要としているか確認してください。ノード一覧を完全な設定ファイルの入力欄に貼り付けると、必須フィールドの不足エラーが出たり、想定したルールのない状態で動作したりすることがあります。

変換しても機能が追加されるわけではない

サブスクリプション変換では、フィールドの表現や出力形式を変更できますが、コアが未対応のプロトコルを突然使えるようにはなりません。共有形式によっては転送の詳細を完全に表せず、変換時にプラグイン、パス、UDP、特殊なハンドシェイクの設定が失われる場合があります。変換結果の構文チェックに通っても、実際の接続に失敗することがあります。まず、対象クライアントで直接使えるサブスクリプションを提供元に依頼してください。変換が必要な場合は、元のデータを保存し、複雑なノードの設定を項目ごとに確認しましょう。

サブスクリプションURLにはアクセス情報が含まれていることが多く、URLを入手した人が設定を読み取れる可能性があります。URL全体を公開スクリーンショット、質問投稿、不明なオンライン変換サービスに載せないでください。問い合わせる際は、認証情報を削除したエラーメッセージ、プロトコルの種類、関連するフィールド名だけを共有しましょう。ローカルで変換する場合も、ツールがデータをどのように扱うか確認してください。URLを短縮しても、元のURLが持つアクセス権限は変わりません。

ルール参照を短い例で確認

以下は、上から順に照合するルールと、組み込みのDIRECTポリシーの記述方法を示す設定例です。プロキシノードを含まず、サブスクリプション全体でもありません。例示ドメインは構文の説明にのみ使用しています。実際の振り分けはアプリの使い方に合わせて調整し、この短い例だけで既存のルールをすべて置き換えないでください。すでに確立された接続は、ルールを変更してもすぐに経路が変わらない場合があります。確認する際は、新しい接続を作成してください。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,DIRECT

ルールで指定するポリシー名は、実在するプロキシグループまたは組み込みポリシーと一致している必要があります。1文字でも違うと解析に失敗することがあります。サブスクリプションの更新でノード名が変わると、名前を基準にしたプロキシグループが空になる場合もあります。プロバイダーを利用する場合は、リソースのダウンロードに成功したか、正しい形式が返されたかも確認してください。メインのサブスクリプション更新が成功しても、外部のルールセットやノードプロバイダーがすべて正常に読み込まれたとは限りません。ログでそれぞれの結果を確認しましょう。

上書き、更新、解析エラー

多くのクライアントには、サブスクリプションの更新でローカルルールが上書きされないようにする上書き、マージ、拡張設定の機能があります。マージの順序はクライアントによって異なり、設定全体を置き換えるもの、リストに追加するもの、スクリプトで結果を生成するものがあります。使う前に、最終的な実行設定をどこで確認できるか把握し、変更後に実際の結果を確認してください。サブスクリプション元と上書き設定の両方に矛盾するDNS設定を記述すると、次回の更新時にどちらが有効か判断しにくくなります。

YAMLのエラーは、インデント、タブ、リストの階層、特殊文字を含む値が原因となることがよくあります。サブスクリプションURLからログインページやエラーページが返ると、それを設定ファイルの解析エラーと誤認することもあります。まず期待した設定ファイルが実際に返されているか確認し、その後ログで行やフィールドを特定しましょう。ファイル全体を公開の検証サービスに貼り付けるのは避けてください。更新に失敗した場合は、直近の正常な設定を残し、ネットワークからの取得失敗と、取得後の解析失敗を区別します。この2種類では対処方法が異なります。

GeoIPやGeoSiteなどのデータはルールの実行に必要なものであり、ノードのサブスクリプションとは別です。設定を更新してもデータベースを読み込めなければ、一部のルールが正常に動作しない場合があります。詳しくはGeoIP・GeoSiteデータベースの更新ガイドをご覧ください。サブスクリプション管理では、内容の提供元、ローカルの変更箇所、失敗時の復旧方法を追跡できる状態を目指しましょう。偶然接続できるまでインポート方法を変え続けるのは避けてください。

08 / 用途別の選択

用途に合わせた選び方と段階的なトラブル対処

デスクトップでの日常利用とモバイルデバイス

デスクトップでの日常的なブラウジングでは、完全なサブスクリプションとの互換性、接続の安定性、メンテナンスのしやすさを優先しましょう。Clash Plusから試し、OSや操作方法に合わせてほかのクライアントと比較したうえで、サーバー側で検証済みのプロトコル構成を使います。SS、Trojan、VLESSの設定がすでに安定しているなら、名称が新しいという理由だけで変更する必要はありません。会議、開発ツール、ブラウザーを併用する場合は、それぞれの通信に適切なルールが適用されているか確認し、業務に必要な接続が別のポリシーへ誤って振り分けられないようにしましょう。

モバイルデバイスでは、接続環境の変化とバックグラウンドからの復帰を優先して確認します。通勤中の電波の変動、モバイル回線とWi-Fiの切り替え、画面ロック後のシステム制限は、最高速度よりも使い勝手に大きく影響します。候補のプロトコルについて、起動、待機、復帰、ネットワーク切り替えの4つの状態をテストしてください。現在のネットワークでQUIC系の設定が安定しているなら、次に電池消費を比較します。UDPに頻繁に接続できない場合は、検証済みのTCP系設定を普段使いの候補として優先しましょう。

大容量ファイル、リアルタイム通信、制限のあるネットワーク

大容量ファイルの転送では、継続的なスループットと、ほかの通信への影響を確認します。まず接続先と出口に速度制限がないことを確認してからプロトコルを比較してください。複数のダウンロードを同時に実行してネットワークを使い切った状態で、ウェブの応答を評価するのは避けましょう。Hysteria2の帯域設定やほかの輻輳制御方式は、実際の回線に合っている必要があります。家庭内ネットワークで会議をしている場合、1回だけ速度を最大まで出すより、混雑時の通信が安定することのほうが重要です。プロトコルだけでルーターの適切な帯域管理を代替することはできません。

音声通話、ゲームなどのリアルタイムアプリでは、アプリ自体がUDPを使うか、その通信がクライアントに取り込まれ、サーバーで転送されるか確認してください。ノードテストの時間が短くても、テスト先とゲームサーバーが異なれば、ゲーム内の遅延も短いとは限りません。まず接続ログに記録された宛先と適用されたポリシーを確認し、その後で回線を変更する必要があるか判断しましょう。UDPの制限が厳しいネットワークでは、別のQUIC系プロトコルに切り替えれば基本的な接続性が解決すると考えないでください。

ノードを次々に切り替えず、失敗した段階を特定する

まったく接続できない場合は、まずローカルネットワーク、サーバーアドレスの名前解決、ポートの状態を確認します。次に証明書やプロトコルのハンドシェイクを調べ、最後に認証を確認してください。ハンドシェイクは成功するのにウェブサイトが開かない場合は、ルールの適用、出口への接続、DNSを確認します。一部のアプリだけが失敗する場合は、まず通信の取り込み範囲とUDPの条件を調べましょう。エラー全文と発生時刻を記録し、同じ調査中にモード、DNS、TUN、プロトコルをすべて同時に変更するのは避けてください。

ドメイン名では開けないのにIPアドレスを使ったテストは成功する場合、名前解決の経路に問題がある可能性があります。ただし、IPアドレスへの直接アクセスは、HTTPSで正しいホスト名が必要なため、有効なウェブサイトのテストとは限りません。証明書の検証を無効にせず、クライアントのログでドメイン名の問い合わせと実際の接続先を確認してください。Fake-IPモードでアプリに合成アドレスが表示されても、サーバーアドレスに問題があるとは限りません。仕組みやよくある対処法はよくある質問をご覧ください。設定を変える前に、まず動作を理解しましょう。

結論には適用条件を明記する

比較の記録には、使用したデバイス、ネットワーク、時間帯、対象のアプリやサービス、安定していた条件を明記しましょう。特定のプロトコルが速いとだけ書くのでは不十分です。比較対象が同じ回線を使っていない場合は、結論をその2つのノードの使い勝手に限定し、プロトコル全体の評価に広げないでください。失敗が続く場合も、到達性、認証、名前解決、出口の問題を区別します。そうすることで、サブスクリプション全体を公開せずに、再現可能な情報をサービス提供元へ伝えられます。

毎日すべてのパラメーターを調整し直す必要はありません。サブスクリプションの更新、OSのアップグレード、ネットワークの切り替え後に、ウェブの名前解決、よく使うアプリの接続、必要なUDP通信、画面ロックからの復帰を簡単に確認しましょう。モードの切り替えが与える影響はルール・グローバル・DIRECTモードの違いをご覧ください。インストール手順を最初から確認する場合は、チュートリアルの手順に沿って進めてください。

最終的な選択では、4つの条件を満たす必要があります。現在のクライアントがプロトコルの組み合わせ全体に対応していること、サーバーの設定が明確で有効であること、利用するネットワークが必要な転送方式を許可していること、デバイスのリソースと電池消費が許容範囲内であることです。これらを満たしたうえで、性能の詳細を比較しましょう。サーバーやルーターでは、権限、待ち受け範囲、再起動後の復旧確認も必要です。こうして得られるのは、一度のテストやプロトコル名だけで決めた一時的な設定ではなく、継続して管理できる構成です。