Clashのプロトコルとコアの選び方

選び方の基本：5つの層を順に確認

Clashの設定にあるSS、VMess、Trojanなどは、プロキシの接続先同士でデータを認証・カプセル化・転送する方式を示します。アプリの通信がクライアントに入る方法を示すものではありません。ブラウザーでシステムプロキシを使う場合、アプリからローカルのSOCKSポートに接続する場合、TUNでシステムのルーティングを引き受ける場合では、通信の入口が異なります。入口によって対象となる通信範囲は変わりますが、サーバー側のプロトコルが別の方式に変わるわけではありません。まずローカルの入口とリモートのプロトコルを切り分け、通信の取り込み方の問題をプロトコル性能の問題と混同しないようにしましょう。

クライアントの画面とコアの機能は分けて考える

クライアントは設定の管理、プロキシグループの操作画面、システムプロキシの切り替え、権限の要求などを担当します。コアは設定の解析、ルールの照合、名前解決、外部への接続を担当します。画面にプロトコル名が表示されていても、実行中のコアがすべての拡張機能に対応しているとは限りません。逆に、コアが特定の項目を読み取れても、クライアントの編集画面にその入力欄がない場合があります。対応状況を調べる際は、クライアント名、実際に動作しているコア名、ノードの通信方式の組み合わせを確認してください。

プロトコル名には、トランスポート層やセキュリティ層が組み合わさることもあります。たとえばVLESSは複数の通信方式を利用でき、TLSやREALITYと組み合わせる場合もあります。VMessでも、プロトコルによる認証と外側の通信方式を分けて考える必要があります。ノードのプロトコル名だけを比べると、通信経路の重要な要素を見落とします。サーバーの場所、回線距離、通信事業者間の接続、出口の混雑、サーバー側の制限は、プロトコル自体の処理負荷より大きく影響することがあります。

接続成功・初回応答・継続的な転送速度は別の指標

接続の確立時間には、名前解決、トランスポートのハンドシェイク、認証、場合によってはセキュリティ層のハンドシェイクが含まれます。Webページの初回応答は、アクセス先の応答やルール処理にも左右されます。大容量ファイルの転送速度は、輻輳制御、帯域幅、サーバーのリソースにより大きく影響されます。初回接続が遅くても、接続を再利用すると安定するプロトコルもあれば、短いリクエストは速くても長時間のダウンロードではサーバーの速度制限を受けるものもあります。テストではクライアントに表示される単一の遅延値だけを見るのではなく、用途を明確にしましょう。

UDPへの対応も段階ごとに確認が必要です。ノードのプロトコルがUDP転送に対応していても、アプリの通信がUDPの入口からプロキシに入っているとは限りません。ノード設定でUDPが有効でも、サーバーがその転送を受け付けるとは限りません。ゲーム、音声通話、一部のリアルタイム通信アプリでは特に確認が必要です。QUICベースのプロトコルでは、クライアントからサーバーへの接続自体にUDPの到達性が必要です。これはプロキシ内で転送されるアプリの通信がUDPかどうかとは別の問題です。

あとから確認できる選定基準を作る

実際の確認は4段階で進めます。まずサービス側が指定する完全なパラメーターを確認し、次にクライアントのコアが対応しているか調べます。その後、通信の入口とルールが正しく適用されているか検証し、最後に同じ用途で使い勝手を比較します。偶然の最低遅延ではなく、接続成功率、初回表示、継続的な通信、ネットワーク切り替え後の復旧を記録してください。異なるサーバーや経路のノードを比べても、その結果から分かるのは個々のサービスの差であり、プロトコル全体の優劣ではありません。こうした条件をテスト記録に残しておけば、クライアントを変更した後も判断基準を活用できます。

ShadowsocksとVMess：軽量な転送とプロトコル認証

Shadowsocksは一般にSSと略され、比較的シンプルな方法で暗号化プロキシ通信を行う設計です。一般的なクライアントではTCP接続とUDPデータグラムをそれぞれ処理し、Web向けの通信層を必須としません。そのため、設定項目は比較的少なくなります。シンプルなのはプロトコルの役割が明確だからであり、あらゆるネットワークの問題を自動で解決するわけではありません。実際の安全性や使いやすさは、暗号方式、鍵の管理、クライアントの実装、サーバー設定によって異なります。SSという総称だけで判断しないでください。

従来のAEAD方式とShadowsocks 2022を区別する

一般的なAEAD方式は暗号化とメッセージ認証を組み合わせ、受信側で暗号文の改ざんを検出できます。Shadowsocks 2022は、明示的な対応が必要な別のプロトコル方式であり、従来方式の別名ではありません。鍵の形式などに異なる要件があり、サービスによっては複数ユーザー向けの仕様も関係します。ノードの暗号方式名だけを別の方式に書き換えても、移行にはなりません。サーバーとクライアントで、実装と認証情報を一致させる必要があります。

SSノードの問題を調べるときは、まず cipher が対応しているか確認し、次にパスワードまたは鍵の形式、サーバーのポート、UDPの設定を確認してください。ノードによってはプラグインが必要です。プラグインによる通信のカプセル化は、SSのコアプロトコルとは別の機能です。設定変換でプラグインのパラメーターが欠落すると、ノード名やアドレスは正しく表示されても接続できないことがあります。その場合はローカルの待ち受けポートを何度も変更するのではなく、元のノード情報を確認しましょう。

VMessの設計と認証の仕組み

VMessはV2Rayエコシステムで生まれたプロトコルで、ユーザー認証とプロキシ要求のカプセル化を設計に取り入れ、複数の基盤通信方式を組み合わせられます。SSとの違いは、パスワードをUUIDに置き換えただけではありません。VMessには独自のリクエスト形式、認証方式、データ保護の仕組みがあります。接続にはTLSやWebSocketなどの層を重ねることもあります。ユーザーID、プロトコル設定、外側の通信方式をすべて一致させる必要があり、どれか一つでも異なるとハンドシェイクに失敗することがあります。

古い設定を読むと、alterIdやalter-idという項目が見つかることがあります。これらは旧式の互換方式に関係します。現在一般的なVMess AEAD設定では通常ゼロを使いますが、そのことを理由にサービス提供元が指定した別のパラメーターを変更してはいけません。ソフトウェアによって項目名の表記も異なります。古いガイドの記述は、対象となるコアの仕様に照らして解釈してください。別形式の設定をそのままClash YAMLに貼り付けないようにしましょう。

VMessの認証はシステム時刻の影響を受けます。端末の時刻が大きくずれていると、アドレスとUUIDが正しくても認証に失敗することがあります。トラブル時は証明書検証を緩めるのではなく、自動時刻設定が正常に動作しているか確認してください。システム時刻はTLS証明書の有効期間にも関係しますが、認証とは別の失敗要因です。ログに時刻や認証の問題が示されている場合は、まず端末の時刻を修正してから再接続してください。

リソース負荷と用途を比較する方法

ネットワークが安定し、接続先の実装が成熟していて、追加のカプセル化がない条件では、SSの通信経路は比較的シンプルです。幅広い互換性が必要な日常の通信に向いています。VMessの負荷は、通信方式との組み合わせも含めて評価する必要があります。直接接続と、WebSocketやTLSを介した接続では、ハンドシェイクの回数やカプセル化の経路が異なります。多層カプセル化されたVMessと直接接続のSSのテスト結果を比べて、プロトコル固有の固定的な速度差だと結論付けることはできません。

モバイル端末では、接続数やバックグラウンドでの動作にも注目しましょう。連続ダウンロード中は暗号処理がリソース消費の一部になりますが、短いメッセージをやり取りする用途では、無線モジュールの起動、DNS問い合わせ、接続の維持のほうが重要な場合があります。SSとVMessのどちらを選ぶ場合も、サービス側が明示的に対応し、利用中のクライアントが設定を正しく読み取れる組み合わせを優先してください。古いノードが保守されていないクライアントにしか対応しない場合は、古いソフトを使い続けるのではなく、サーバー側の移行方法を検討しましょう。

TrojanとVLESS：認証と通信の保護を分けて考える

TrojanとVLESSはいずれもTLSと組み合わせて使われることがありますが、同じプロトコルの別名ではありません。一般的なTrojanの構成では、TLS接続でプロキシ要求を運び、パスワードを使った認証情報でユーザーを識別します。VLESSはプロキシプロトコル自体をシンプルにし、通信の保護を外部のセキュリティ層に委ねる設計です。比較する際は、認証、通信内容の盗み見防止、サーバーの本人確認という目的を区別しましょう。これらを単一の設定項目でまとめて実現するわけではありません。

Trojan：TLS接続の後にプロキシ認証を確認

標準的なTrojan接続では、TLS設定が正しいことが前提です。クライアントが接続するサーバーアドレスにはドメイン名またはIPアドレスを指定できますが、TLS検証では証明書が示すサーバーの識別情報が関係します。sniは通常、サーバー名を送信し、接続処理に利用されます。適当なドメイン名を指定すれば自動的に一致するわけではありません。サーバー証明書、期待する名前、ポート、パスワードをすべて正しく設定する必要があります。前段サービスを介して接続する構成では、追加の要件も提供元の案内に従ってください。

TrojanはUDP転送を扱えますが、一般的な実装ではアプリのデータグラムもTLSを使う信頼性の高いバイトストリームを通じて送られます。そのため、ローカルではUDPを使うアプリに見えても、リモートへの通信経路ではTCPのヘッドオブラインブロッキングの影響を受ける場合があります。リアルタイム通信に適するかどうかは、ノードのUDP表示だけで判断せず、実際のパケットロスや操作感を測定してください。拡張実装によって別の通信方式が追加されることもありますが、その挙動をすべてのTrojanサービスに当てはめることはできません。

VLESS：プロトコルがシンプルでも通信が自動で暗号化されるわけではない

VLESSの認証には通常UUIDを使いますが、UUIDは認証用の識別子であり、TLSの代わりになる暗号化設定ではありません。従来のVLESS設定でよく見られる encryption: none は、プロトコル層が該当するデータ暗号化を提供しないことを示します。通信全体が必ず保護されないという意味ではありません。安全性はTLS、REALITYなど、実際に利用する外側の方式によって決まります。逆に、セキュリティ層のない設定をVLESSだから暗号化済みとみなすこともできません。

VLESSは通信方式の組み合わせが多いため、必要な機能ごとにクライアントの対応状況を確認してください。flowは自由に設定できる最適化用のラベルではなく、特定のデータフロー処理方式と接続先の実装に合わせるパラメーターです。たとえばVision関連の方式を使う場合、サーバー、コア、通信方式、セキュリティ層がすべて要件を満たすか確認する必要があります。別のノードから flow をコピーすると、接続できていた設定が失敗することがあります。

REALITYは通常のTLS設定を別の名前で呼んだものではありません。利用する場合は、公開鍵、short ID、サーバー名、関連するハンドシェイクパラメーターをサーバー設定と一致させる必要があります。ソフトウェアによって項目名が異なるため、使用中のコアのドキュメントを確認してください。ブラウザーフィンガープリント関連の項目は特定のハンドシェイク動作に影響しますが、誤ったポートや無効なユーザーID、公開鍵の不一致を修正するものではありません。汎用的な高速化設定としても扱わないでください。

通信方式の選択に与える影響

WebSocketやgRPCなどの通信方式は、既存のサーバー構成に合わせるために使われることがあります。それぞれ固有のパス、サービス名、リクエストヘッダー、中間層の要件が加わります。カプセル化が一段増えると必ず遅くなるわけではありません。実際のボトルネックが処理装置ではなく回線にある場合もあります。ただし設定項目が増え、トラブル時に確認すべき条件も多くなります。特別な構成上の制約がなければ、提供元の説明が明確で、クライアントが標準で対応し、パラメーターが少ない組み合わせを優先してください。

TrojanもVLESSも、証明書検証を無効にして設定ミスを補うべきではありません。証明書の期限切れ、サーバー名の不一致、システム時刻のずれは、それぞれ別に対処してください。検証を省略すると安全性が損なわれるうえ、本当の問題を見えにくくすることがあります。ノードの読み込み後に機密情報の入力が必要な場合は、ローカルのクライアントで設定し、完全な設定や認証情報を公開画像に含めないでください。トラブルの情報を共有する際は、プロトコルの種類、エラーの分類、項目名を残せば十分です。

Hysteria2とTUIC：QUICを使った異なる設計

Hysteria2とTUICはどちらもQUICを利用しますが、互いの設定をそのまま読み込んだり、認証パラメーターを共用したりはできません。QUICはUDP上で暗号化通信、信頼性のあるストリーム、接続管理を実現し、TCPとは異なる基盤を提供します。Hysteria2は複雑な回線環境での通信と帯域の活用を重視します。TUICはQUIC上にプロキシ要求とデータ転送を構築し、独自の認証とUDP処理方式を備えています。設定項目とサーバー側の実装はそれぞれ一致させる必要があります。

QUICでできること、できないこと

QUICは1つの接続で複数のストリームを扱えます。あるストリームでパケットロスが起きても、単一のTCPバイトストリームのように、欠落データをすべてのストリームが待つ必要はありません。ただし、接続内の輻輳制御や利用可能な帯域、一部のリソースは共有されるため、各リクエストが完全に独立するわけではありません。物理的な距離、深刻な混雑、サーバーの性能制限も解消できません。ネットワークがUDPを破棄する場合、QUIC接続そのものを確立できないこともあります。

接続の移行はQUICの機能の一つですが、Wi-Fiとモバイル回線を切り替えた後も使い続けられるかは、プロキシの実装、サーバーのポリシー、クライアントのライフサイクルにも左右されます。モバイルOSがプロセスを一時停止したりリソースを回収したりする場合があり、クライアントがトンネルを再作成することもあります。回線切り替え後の復旧を試す際は、アプリのリクエストが再び成功するか、安定して復旧するかを確認してください。プロトコルに接続識別子があるだけで、あらゆる切り替え後も通信が継続すると判断してはいけません。

Hysteria2：帯域パラメーターは実際の回線に合わせる

Hysteria2と旧Hysteriaは、設定形式を自由に入れ替えて使えるものではありません。種類に hysteria2 を指定した場合は、対応する認証、TLS、その他のオプションを使用してください。難読化の設定もサーバー側と一致させる必要があり、接続を試すために適当に有効化してはいけません。標準的な接続でも、サーバーの本人確認と証明書検証を正しく行う必要があります。QUICを使うからといって、これらの要件がなくなるわけではありません。

Hysteria2の帯域ネゴシエーションや輻輳制御の挙動は、両端の設定に左右されます。クライアントでは上り・下りの帯域情報を up、down などの項目で指定できますが、手動設定が必要な構成ばかりではありません。数値を大きくしても利用可能な帯域が自動で増えるわけではなく、キューの増大、パケットロス、同じネットワークを使う端末への影響につながることがあります。まずサーバー側の要件を確認し、明示的な設定が必要な場合は、Wi-Fiの公称速度ではなく、実際に継続できる帯域を基準に控えめに調整してください。

TUIC：認証・輻輳制御・データグラムの処理方式

一般的なTUIC設定にはUUID、パスワード、TLS関連のパラメーターが含まれ、輻輳制御やUDP転送方式を指定できる場合もあります。具体的な項目はTUICの世代やクライアントの実装によって異なるため、「TUIC対応」という情報だけでは不十分です。Hysteria2の認証文字列をTUICのパスワード欄に入れても、同じQUICを利用しているという理由で接続できるわけではありません。

輻輳制御アルゴリズムは送信のペースや回線からのフィードバックへの応答に影響しますが、あらゆるネットワークで使える速度設定ではありません。UDPデータグラムをどの方式で転送するかによっても、信頼性、遅延、追加の負荷が変わります。信頼性のある転送ではアプリのデータグラムが失われるのを防げる場合がありますが、待ち時間が増えることがあります。信頼性を重視しない転送はデータグラム本来の動作に近い一方、アプリ側でパケットロスに対処する必要があります。選択前に用途を明確にし、すべての設定を強気な値にすればよいと考えないでください。

ネットワーク環境を確認してから使い勝手を比べる

公衆Wi-Fi、企業ネットワーク、モバイル回線ではUDPの扱いが異なる場合があります。TCP系のノードは使えるのにQUIC系のノードが2つとも失敗する場合は、認証より先にUDPの到達性、ポート制限、経路の問題を確認してください。長時間使った後に切断されるなら、NATのマッピング、アイドルタイムアウト、モバイル端末のバックグラウンド制限が関係している可能性があります。まず固定回線で基準となる動作を確認し、その後、実際の利用環境で試すと、複数の条件が同時に変わることによる誤判断を減らせます。

Hysteria2やTUICは、遅延が大きくパケットロスがある一方でUDPに到達できる環境なら、候補に加えて試す価値があります。ただし、常に優先すべきという意味ではありません。積極的な送信制御によってスループットが向上する場合もあれば、処理負荷や無線通信の時間が増える場合もあります。ダウンロード速度だけでなく、端末の発熱、同じネットワークを使う端末への影響、通信の安定性も記録してください。

通信速度・リソース使用量・モバイルの電池消費

プロトコルの性能を比べるには、できるだけ条件をそろえる必要があります。同じクライアント、同じ端末、同じ通信の入口、近い時間帯を使うことが最低限の条件です。サーバーの場所、出口の帯域幅、接続先のWebサイトが異なる場合、結果が示すのはサービス経路全体の違いだけです。プロトコル自体の処理にも差はありますが、一般的なWeb閲覧では名前解決や接続先からの応答に時間がかかる場合があります。待ち時間をすべて暗号化やハンドシェイクのせいにしないでください。

短時間の接続・再利用・継続的な通信を分けて測る

最初のリクエストには、DNS問い合わせ、TCPまたはQUICの接続確立、TLS、プロトコル認証が含まれることがあります。後続のリクエストでは、すでに確立した通信接続が再利用される場合があります。測定では、コールドスタートか接続を事前に温めた状態かを明記してください。遅延テストを連続して行うと、キャッシュや接続の再利用によって数値が次第に低くなることがありますが、実際のアプリがアイドル状態の後にも同じ条件を利用できるとは限りません。短いリクエストを比べる場合は、初回と再読み込み時の安定性を分けて記録しましょう。

大容量ファイルの転送では、開始直後の急な速度だけを記録しないよう、十分な時間をかけて観察してください。単一接続と複数接続のダウンロードも区別しましょう。後者はネットワークと処理リソースをより多く使う場合があり、プロトコルの単一接続あたりの効率が高いことを直接示すものではありません。再送、輻輳への応答、サーバー側の速度制限も速度の推移に影響します。速度測定は通信量を消費し、その時点の負荷も変えるため、ノードを切り替えるたびに大容量のテストを自動実行するのは避けましょう。

プロセッサーとメモリに機器を問わない順位はない

暗号アルゴリズムがハードウェアアクセラレーションを使うか、コアがバッファーをどう管理するか、同時接続数はいくつかによって、プロセッサーの使用率は変わります。あるプロセッサーで効率的なアルゴリズムが、古いモバイルチップや小型ルーターでも有利とは限りません。QUICの実装ではユーザー空間で多くの通信処理を行うことがありますが、どの処理でも必ずリソースを多く使うとは言えません。実際のスループットとシステムのスケジューリングを合わせて確認してください。

メモリ使用量には、ルールセット、DNSキャッシュ、接続追跡、ログのレベル、画面部分のフレームワークも影響します。大規模なルールセットを含むクライアントと、簡素な設定のクライアントを比較しても、プロトコルのメモリ使用量は判断できません。ルーターのメモリが不足する場合は、プロトコルを変える前に接続数、ルールの読み込み、ログを確認してください。デスクトップクライアントで表示されるプロセス全体の使用量には画面部分も含まれることがあり、プロキシコア単体の使用量とは異なります。

モバイルの電池消費は無線通信とバックグラウンド動作に左右される

スマートフォンの通信モジュールが頻繁に起動すること、接続維持の間隔が短すぎること、電波が弱い状態で再送が続くこと、アプリがバックグラウンドで通信することは、いずれも電池消費を増やす可能性があります。アイドル接続の維持と動画の連続再生では、電力の使われ方が異なります。そのため、信頼できる汎用的なプロトコル別の電池消費ランキングはありません。画面を点けた状態での閲覧、画面オフの待機、継続的なデータ転送を分けて記録し、画面の明るさ、電波状況、ネットワークの種類、アプリの負荷をできるだけそろえてください。

Androidのバッテリー最適化によってクライアントが一時停止し、画面ロック後に接続が切れることがあります。関連する制限を解除すると長時間動作しやすくなりますが、バックグラウンドでの動作も増えます。iOSのネットワーク拡張機能はシステムのライフサイクル管理を受けるため、デスクトップと同じバックグラウンド設定は使えません。切断時はシステム設定とクライアントのログを確認し、すぐに接続維持の頻度を上げないでください。頻繁な確認で接続を維持できても、不要なオンライン状態のために電池を余分に消費する場合があります。

プロキシは接続済みなのにWebページが開けない場合は、性能を比較する前にシステムプロキシからDNSまでの確認リストに沿って通信経路を確認し、通信の取り込みが有効か確かめてください。一度だけ高いスループットを記録するより、用途の要件を安定して満たす組み合わせを選ぶことが大切です。

Clash・Meta・mihomo：コアの系譜と画面の役割

オリジナルのClashでは、YAML設定、プロキシグループ、ルールによる振り分けを中心とした使い方が確立されました。その後のエコシステムでは複数のコアの派生版や拡張実装が登場し、Metaは一般にClash.Metaの開発系統を指します。mihomoはその系譜で使われているプロジェクト名です。これらは自由に組み合わせられる3つの機能プラグインではありません。設定が動作するかどうかは、実際に使用するコアがノードの種類、ルール構文、関連モジュールに対応しているかで決まり、ファイル名にClashが含まれるかどうかでは判断できません。

基本構文が似ていても、機能が同じとは限らない

proxies、proxy-groups、rulesなど、よく使われる項目は複数の実装で似た構造を保っており、基本的な設定は移行しやすい場合があります。一方、プロトコル拡張、DNSの挙動、TUNのパラメーター、ルール機能が同じとは限りません。オリジナルの設定で使える基本的なノードが、新しい拡張ノードにも対応するとは限りません。未対応のプロキシタイプが表示されたら、まず対応範囲を調べましょう。YAMLのインデントを変えてエラーを隠そうとしてはいけません。

資料を読むときは、歴史上のオープンソース版、Premium関連機能、Meta系統の実装を区別してください。古い記事に「Clash対応」と書かれていても、実際には当時の特定のコアだけを対象としている場合があります。そうした記述を寄せ集めて、すべてのクライアントに共通する機能一覧とみなすことはできません。特にTUN、ルールプロバイダー、スクリプト、特定のルール形式については、現在使用中のコアのドキュメントで個別に確認してください。

クライアント名とコア名は別

一般ユーザーは、まずダウンロードページでおすすめしているClash Plusから始め、OSに合ったクライアントを選び、実際のプロトコル対応状況と設定の読み込み機能を確認できます。Clash Verge RevやFlClashなども画面を備えたクライアントです。設定の対応状況は、実際に組み込まれているコアを基準に判断してください。Clash Meta for Androidという名称はエコシステムとの関係を示していますが、インストール中のアプリがどのように実装されているかは確認が必要です。ブランド名が似ているだけで、設定の拡張機能もすべて同じだと推測しないでください。

デスクトップ版で画面のプログラムを更新しても、実行中のコアが切り替わったとは限りません。コアを個別に管理できるクライアントもあれば、インストールパッケージにまとめて含まれているものもあります。トラブル時は、バージョン情報画面、実行ログ、コア管理画面で実際に動作している情報を確認してください。設定フォルダーが複数ある場合は、クライアントがどのファイルを読み込んでいるかも調べましょう。バックアップファイルを編集していたのに動作が変わらないことを、コアの不具合と誤認するおそれがあります。

Clash for WindowsとClashX Metaは、本サイトのダウンロード一覧でサポート終了済みのアーカイブ版として掲載しています。アーカイブは旧環境の確認や移行に役立ちますが、新しいプロトコル機能を利用するための標準的な選択肢ではありません。サポートが終了しても既存の接続がすぐにすべて使えなくなるわけではありませんが、今後のOS変更、プロトコル拡張、修正が継続されるとは限りません。移行前に元の設定を保存し、複製した設定で新しいクライアントを試してください。

コアを移行するときは機能ごとに進める

移行時はまず、ノードを最小限にして手動選択用のプロキシグループを1つ用意し、認証と通信が確立できるか確認します。その後、ルール、DNS、プロバイダー、TUNを順に戻しましょう。こうすると、問題がどのモジュールにあるか絞り込めます。複雑な設定を一度に読み込んで通信できなくなると、ノードの誤り、DNSのループ、ルーティングの競合、ルール参照の誤りが混在し、ログを解釈しにくくなります。まず基本接続を確認してから機能を追加するほうが、設定全体を一度に試すより効率的です。

サービスモードと管理者権限はシステム連携の条件であり、リモートプロトコルの属性ではありません。コアがTUNに対応していても、一般権限のプロセスで仮想ネットワークインターフェースを作成したり、ルートを変更したりできるとは限りません。より多くのアプリの通信を取り込む場合は、TUNモードと仮想ネットワークインターフェースの解説も確認してください。サーバーやルーターで使う場合は、GUIクライアントとコア単体での導入を区別し、OpenWrtとバイパスルーターの導入概要を参考にリソースとネットワーク構成を検討しましょう。

設定形式の互換性：URL・ノード・完全な設定

サブスクリプションは設定を配布する方法であり、独立したプロキシプロトコルではありません。サブスクリプションURLの応答は、完全なClash YAML、複数の共有リンク、エンコードされたノード一覧、ほかのソフトウェア向けの設定形式など、さまざまです。クライアントがURLからデータを取得できても、現在のコアでその内容を直接設定として使えるとは限りません。「形式エラー」が出て何度も更新を試す前に、まず内容の種類を確認しましょう。

単一ノードの共有リンクと完全なYAMLでは含まれる情報が異なる

ss://、vmess://、trojan://などの共有形式は、通常1つの出先ノードを表します。具体的な項目のエンコード方法には、各エコシステム独自の仕様が使われる場合もあります。共有リンクにはプロキシグループ、振り分けルール、DNS、ローカルポートが含まれないことがあります。完全なClash設定は通常、これらのモジュールで動作環境を構成します。ノードリンクの文字列を .yaml ファイルとして保存しても、自動的にYAML設定になるわけではありません。拡張子を変えてもファイル形式は変わりません。

同様に、別のコア向けのJSON設定も、括弧やインデントを変えるだけではClash設定になりません。モジュールの構成、ルーティングの表現、DNSの意味が根本的に異なる場合があります。変換ツールは理解できる項目だけを対応付けるため、元の動作をすべて保てるとは限りません。REALITY、特定のフロー制御、プラグイン、新しいプロトコルのパラメーターを含む場合は、変換後に各項目を慎重に確認してください。ノード数が一致していても、接続に必要な情報がそろっているとは限りません。

プロキシプロバイダーは、別のトップレベル設定ではない

proxy-providersを使うと、外部ソースからノード一覧を読み込み、プロキシグループから参照できます。プロバイダーファイルは通常、ノード一覧を提供する役割に限られます。別の完全なサブスクリプションに含まれるポート、DNS、ルールまで一緒に取り込まれると考えてはいけません。ソースが実際には完全な設定を返す場合、ノードを抽出できるかどうかは、クライアントやコアの処理方法によります。プロバイダーが要求する構造に合わせてデータを用意し、「メイン設定の読み込みが成功した」という経験をそのまま当てはめないでください。

以下は、単独で解析できるローカルの振り分け用設定例です。リモートノードは含まれていません。ポート、プロキシグループ、ルールの構成を確認するためのもので、プロキシ性能の測定には使えません。実際のノードを読み込んだ後、該当するプロキシグループにノード名を追加してください。完全なサブスクリプションを直接使う場合は、ローカル設定のマージ方法をクライアントで確認し、ローカルルールが上書きされないようにしましょう。

mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
  - name: 手動選択
    type: select
    proxies: [DIRECT]
rules:
  - MATCH,手動選択

設定の解析後は参照関係も確認する

YAMLではインデント、リストの階層、文字列の表記に決まりがあります。特殊文字を含む値には適切な引用符を使ってください。プロトコル項目の型も重要です。真偽値と文字列を自由に入れ替えることはできません。ただし、構文が正しいだけでは不十分です。プロキシグループが参照するノード名、ルールが参照するグループ名、ルールプロバイダー名が実際に存在する必要があります。サブスクリプション更新後にノード名が変わり、手書きのグループで古い名前を使い続けると、参照エラーが発生することがあります。

クライアントでは、ローカル設定を維持するために上書き、マージ、スクリプトを使うことがあります。それぞれ実行タイミングや適用範囲が異なるため、実際に有効になる設定ファイルはダウンロードした元ファイルと異なる場合があります。トラブル時は実行中の設定を調べ、ノードとルールが最終的にどのように組み合わされているか確認してください。サブスクリプションの編集画面で項目を検索しただけで、コアが読み込んだと判断しないでください。必要であれば、ローカルの上書きを一時的に無効にし、コピーした元のサブスクリプションで検証してから項目ごとに戻します。

更新エラーと形式の非互換は分けて対処する

HTTPエラー、ログインページへのリダイレクト、空の応答、YAMLの解析エラーは、それぞれ別の問題です。サブスクリプションURLにアクセス用の認証情報が含まれる場合があるため、信頼できないオンライン変換サービスに渡さないでください。変換サービスから完全なノード情報にアクセスされるおそれがあります。まずクライアントに備わった読み込み機能や、自分で管理できる方法を使いましょう。更新手順の詳細は、サブスクリプションの更新失敗と自動更新の設定を確認してください。

更新前に動作する設定のコピーを保存し、更新後はまずノードの種類とプロキシグループを確認してから、ルールとDNSを検証してください。サーバー側で現在のコアが未対応の種類が追加された場合は、互換性のあるサブスクリプション形式を選ぶか、対応クライアントを更新しましょう。エラー項目を単純に削除してはいけません。項目を消せば解析に成功することがあっても、認証や通信方式の意味が変わり、かえって原因を特定しにくい接続エラーを招く場合があります。

用途に合ったプロトコル選び：基準を保って比較する

実際に使うプロトコルは、特定の名前を先に決めてパラメーターを探すのではなく、利用できるサービスの条件から選びましょう。プロトコルにはサーバーとクライアントの両方が対応する必要があります。ローカル設定の type を変えても、リモート側が自動で対応するわけではありません。サービス提供元が検証済みの組み合わせを一つだけ提示している場合は、まず用途の要件を満たせるか確認してください。UDPに到達できない、回線切り替え後に安定して復旧しない、端末のリソースが不足するといった具体的な制約が見つかった場合に、目的を定めて別の組み合わせを比較しましょう。

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

デスクトップのWeb閲覧やオフィスアプリでは、まず通信の安定性、名前解決、ルールの適用を確認しましょう。SS、VMess、Trojan、VLESSのいずれも、成熟した互換性のある構成なら候補になります。安定して動いている接続を、新しい名前のプロトコルに変える必要はありません。クライアントはClash Plusを優先して選ぶか、ダウンロードページのプラットフォーム一覧から選択してください。アーキテクチャとシステム要件を確認したうえで、対象ノードが必要な通信方式に完全対応しているか調べましょう。インストール後の基本操作は、使い方ガイドを参照してください。

モバイル端末では、画面ロック、ネットワーク切り替え、バックグラウンドからの復帰も追加でテストしてください。まずWi-Fiで条件を固定して試し、その後モバイル回線に切り替えます。切り替え後だけ問題が起きる場合は、認証パラメーターをすぐに変更せず、クライアントが接続を再確立しているか確認してください。TUNで通信を取り込む場合は、OSのVPN権限やほかのネットワーク拡張機能との競合も調べましょう。クライアントがOSによって一時停止される問題と、プロキシサーバーが認証を拒否する問題では、対処方法がまったく異なります。

高遅延の回線とリアルタイム通信

遅延が大きくパケットロスもある回線では、UDPに到達できることを確認したうえで、Hysteria2、TUIC、既存のTCP系方式を比較できます。比較ではダウンロードのピーク速度だけでなく、操作時の待ち時間、継続的な通信、ほかのアプリへの影響を確認してください。公衆ネットワークでQUIC系の接続が頻繁に切れる場合は、検証済みのTCP系の候補を一つ残しておくほうが実用的です。予備の経路はあらかじめテストし、メインの経路が使えなくなってから初めて読み込むことのないようにしましょう。

音声通話やゲームなどのリアルタイム通信では、データグラムの転送が経路全体を通るか、長い待ち時間や断続的な切断が発生しないか確認してください。信頼性のある転送ではパケットロスの現れ方が変わりますが、必ずリアルタイム通信が改善するとは限りません。アプリによっては、再送を待つより古いデータを破棄するほうが適しています。実際の用途で確認すると同時に、接続先サービスがIPアドレスの変化に敏感かどうかも調べましょう。サービス側のセッション切れをプロキシプロトコルの問題と誤認しないでください。

ルーターと低リソース端末

ルーターでは、まずプロセッサーのアーキテクチャ、使用可能なメモリ、同時接続数、ルールセットのサイズを確認してください。リソースが限られる場合は、ルールを減らす、不要なログを抑える、ヘルスチェックの重複を避けるといった対策が、プロトコルの変更より直接的なことがあります。暗号化方式の実装やQUICの処理負荷は、実際に使うハードウェアで試してください。デスクトップPCの結果から小型ルーターの動作を推測したり、物理ポートの速度がプロキシ使用時にも得られると考えたりしないでください。

バイパスルーターの構成では、ゲートウェイ、DNS、戻り経路も確認してください。端末の通信がプロキシ機器を経由していなければ、プロトコルを選んでも効果はありません。DNSの設定先が誤っている場合やルーティングがループしている場合は、すべてのノードで接続に失敗することもあります。まず最小限のネットワーク構成で1台の端末を検証し、その後、全ネットワークに広げてください。安定稼働中の端末では、コアの変更とプロトコルの変更を一度に行わず、分けて試すと、どの層の変更が影響したか判断しやすくなります。

比較結果を記録する手順

1. 端末、OS、クライアント、実際に動作しているコアを記録し、複数の通信制御ソフトが同時に動作していないことを確認します。
2. 元の設定を保存し、ネットワークと用途を固定したうえで、ノードの認証、通信方式、証明書のパラメーターを確認します。
3. 初回リクエスト、継続利用、アイドル状態からの復帰、ネットワーク切り替えをそれぞれ確認し、異なるテストの結果を混同しないようにします。
4. 一度に変更する条件は一つにし、失敗した場合はエラーの分類を記録します。その後、正常な基準設定に戻してネットワークが引き続き使えることを確認します。
5. 要件を安定して満たせる組み合わせを採用し、検証済みの代替候補も残しておきます。重要な更新後は再テストしてください。

最終的な判断基準は3つです。設定がサーバーの要件を正確に表しているか、端末が許容できるリソース消費で動作を続けられるか、実際のネットワークが通信方式を安定して運べるかを確認します。すべて満たした後で使い勝手の差を比べましょう。プロトコル名は調べるための手がかりであり、品質を保証するものではありません。特定の端末と用途で繰り返し確認できた結果こそが、ノードとクライアントの組み合わせを使い続ける判断材料になります。