Clashのプロトコルとコアの技術ガイド

接続の仕組み：プロトコル・通信方式・システム連携

アクセスはどのような経路を通るのか

アプリからアクセスすると、接続はシステムプロキシ、アプリ内のプロキシ設定、またはTUN仮想インターフェースを経由してローカルのクライアントに入ります。コアが宛先を判別し、ルールに基づいて直接接続するか、プロキシのポリシーを選んでからリモートサーバーへ接続します。リモートサーバーは最終的な宛先に接続し、応答を同じ経路で返します。経路は少なくとも、アプリからローカル、クライアントからリモート、リモートから宛先までの3区間に分かれます。名前解決、ハンドシェイク、転送、出口の混雑のいずれかに問題があると、ページがなかなか開かないなどの症状が現れます。

ノードのプロトコル種別は、クライアントとリモート側の間で認証・カプセル化・通信を行う方法を示します。システムプロキシとTUNはアプリの接続をローカルで受け取る方法、ルールは接続先を決める設定です。それぞれ異なる階層に属します。TUNを有効にしてもSSノードがHysteria2に変わるわけではなく、ルールモードを選んでもサーバーのプロトコルは変わりません。この3つを分けて記録すれば、システム連携の問題でノードを何度も切り替えたり、設定形式の非互換を回線速度の問題と誤認したりするのを防げます。

プロトコル名だけでは分からない接続パラメーター

プロトコルは通常、下位の通信方式やセキュリティ層にも依存します。たとえばVLESSはTCPやWebSocketなど、対応する通信方式と組み合わせられます。セキュリティ層にはTLSやREALITYを使う場合があります。サブスクリプションに含まれるポート、サーバー名、パス、通信方式によって、ハンドシェイクが成立するかどうかが決まります。どちらもVLESSと表示されていても、設定をそのまま入れ替えられるとは限りません。同じサーバーでも、ポートによって異なるサービスが稼働している場合があります。クライアントの種類選択は設定の入口にすぎず、すべてのパラメーターが接続条件を構成します。

TCPは、パケットを再送して損失を補う、順序保証付きの信頼性のあるバイトストリームを提供します。UDPはデータグラムを送信しますが、確認応答や再送は自ら行いません。QUICはUDPを基盤とし、プロトコル内で暗号化、信頼性のあるストリーム、輻輳制御を実現します。そのため「UDPベース」だからといって、データの損失を放置するわけではありません。また、外側の接続と内側の通信を区別する必要があります。プロキシは、Webで使われるTCPをUDPで運ぶことも、条件が合えばアプリのUDP通信を転送することもできます。UDPと書かれているだけで、ゲームや動画に適しているとは判断できません。

用途を明確にしてからノードを比較する

選定前に、Web閲覧、大容量ファイルの転送、リアルタイム通信、スマートフォンでのバックグラウンド接続維持のどれが目的かを確認しましょう。Web閲覧では初回接続や短いリクエストへの応答、大容量ファイルでは持続的なスループット、リアルタイム通信では遅延の揺らぎやパケット損失が重要です。スマートフォンではアイドル時の通信維持も考慮します。テストでは端末、接続ネットワーク、アクセス先、時間帯を固定し、クライアントのログで選んだノードを実際に経由しているか確認してください。プロトコルだけでなくサーバーの地域も同時に変えると、結果をプロトコルの違いに結び付けられません。

SSとVMess：暗号化と設定の違い

軽量な転送を重視するShadowsocks

Shadowsocksは一般にSSと略され、比較的シンプルなプロキシ転送方式を採用しています。クライアントは宛先アドレスと通信データを仕様に沿って暗号化し、サーバーは復号して宛先に接続します。設計上は、複雑な通信方式を多数組み合わせるよりも、カプセル化をシンプルに保つことが重視されています。よく使われるAEAD暗号方式は、機密性と完全性の検証を同時に行い、改ざんされたデータを受信側で検出できます。実際の接続には、サーバーアドレス、ポート、パスワード、暗号方式が一致している必要があります。どれか1つでも異なると、認証または復号に失敗することがあります。

暗号方式は、名称だけを見て「最強」や「最速」と決められるものではありません。AESのハードウェアアクセラレーションを備えた端末と、主にソフトウェアで処理する端末では、アルゴリズムごとの負荷が異なる場合があります。SS 2022は互換性を個別に確認する必要がある別のプロトコル系列で、鍵の形式や実装要件が従来のSS設定と異なります。サブスクリプションにSS対応と記載されていても、すべてのSS 2022方式に対応するとは限りません。サーバーから提供された鍵を一般的な短いパスワードに置き換えると、双方で同じ方法による認証ができなくなります。

SSノードには、追加の通信方式やカプセル化を提供するプラグインが設定されている場合があります。このときの互換性は、type: ssを解析できるかだけではなく、コアがプラグインとそのオプションを実装しているかによって決まります。モバイル向けのGUIクライアントでは一部のプラグイン設定が表示されないこともあります。インポート後も実際の接続ログを確認してください。SSのUDP転送にもクライアントとサーバー双方の対応が必要です。Webページは表示できるのにリアルタイム通信が失敗する場合は、すぐに暗号方式を変更せず、UDP対応、ポート設定、アプリの接続方法を個別に確認しましょう。

VMessのセッション認証と通信方式

VMessはV2Rayエコシステムに由来し、セッション認証とデータ保護を提供します。TCPやWebSocketなどと組み合わせて使われることが一般的です。認証情報には通常、SSのような共有パスワードではなくUUIDを使います。現在の設定ではサーバーの要件に従ってAEAD方式を使うのが基本です。過去のサブスクリプションにあるalterIdを、自由に調整できる最適化項目と考えてはいけません。旧式の認証方式は新しい実装での対応状況が異なる場合があります。古い設定を使う際は、提供元の実際の構成を確認してください。数値を変えながら「共通の正解」を探す方法は適切ではありません。

VMessの認証方式の一部は時刻に依存するため、端末の時計がずれているとハンドシェイクに失敗することがあります。同じサブスクリプションが別の端末では動作する場合、まずシステム時刻が自動同期されているかを確認し、次にUUID、TLS、通信方式の設定を確認してください。WebSocketではパスとHostの一致が必要で、TLSではサーバー名と証明書の整合性が重要です。ハンドシェイクやカプセル化が加わると初回アクセスに影響する場合がありますが、その程度は接続の再利用、回線の往復時間、実装方法によって異なります。すべてのVMessノードが同じ速度になるわけではありません。

この2種類のノードを優先して検討するケース

端末の性能が限られていて、一般的なWeb閲覧や安定した転送が主な用途なら、設定がシンプルで適切に保守されているSSノードから試すとよいでしょう。VMessの設定一式と対応するサーバーがすでにある場合は、現在の通信方式が正確に設定されていることを優先します。実際には、両者の差よりサーバー負荷、出口、距離による差の方が大きいことがよくあります。クライアントに未知の暗号方式や非対応の通信方式が表示されたら、まずコアの互換性を解決してください。接続が確立しているのに速度が安定しない場合に回線を比較し、設定形式の問題と性能の問題を混同しないようにしましょう。

TrojanとVLESS：TLS、セキュリティ層、通信設定

TrojanはTLSにセキュアな通信を任せる

Trojanは一般に、TLSチャネル内で認証とプロキシ転送を行い、成熟したTLS実装によって接続を保護します。クライアントはまずセキュアな接続を確立し、その後プロトコルに従って認証情報と宛先情報を送ります。そのため、証明書の検証、サーバー名、サーバーの待ち受け設定が重要です。ノードのパスワードが正しくても、TLS接続が必ず成功するとは限りません。誤ったアドレスへの接続、サーバー名の不一致、期限切れの証明書、端末時刻のずれなどにより、認証前のハンドシェイクで接続が切れることがあります。

サーバーアドレスはリモートホストを見つけるために使い、SNIは通常TLSハンドシェイクでサーバー名を通知するために使います。両者は異なる場合がありますが、サーバーの構成と一致している必要があります。IPアドレスで接続しながらドメイン名で証明書を検証するのは一般的な構成です。SNIを自動的にIPアドレスに置き換えてはいけません。証明書チェーンの検証は、システムまたはコアが使用する信頼ストアにも依存します。PCでは接続できてスマートフォンでは失敗する場合、パスワードが無効だと決めつけず、スマートフォンの時刻、信頼ストア、クライアントのTLS実装を確認しましょう。

VLESSのシンプルな認証と外部セキュリティ層

VLESSもV2Ray関連のエコシステムに由来し、プロトコル自体の認証やカプセル化をシンプルにしていますが、汎用的な通信暗号化を単独では提供しません。一般的なセキュリティ構成では、サーバーとクライアントの対応状況に応じてTLSやREALITYなどを利用します。UUIDが正しいからといって、セキュリティ層の設定を省略できるわけではありません。また、名称にある「軽量」を、どの用途でもリソース消費が少ないという意味に捉えるのも適切ではありません。外側のTLS、選択した通信方式、フロー制御も接続確立やデータ処理に関わります。

REALITYは一般的なTLS証明書の代わりに入力する単純な項目ではなく、両端をその仕組みに沿って設定するセキュリティ層です。クライアントには通常、公開鍵、Short ID、サーバー名などが必要です。これらの値はサービス提供元から入手してください。Visionは特定のフロー制御設定で、サーバーや使用する通信方式との互換性が必要です。任意のVLESSノードで有効にすべき高速化機能ではありません。公開鍵の不足、Short IDの誤り、フロー制御の不一致は、通常設定の修正が必要です。システムプロキシやTUNを切り替えても、これらの項目は補われません。

通信レイヤーの重なりが短いリクエストに与える影響

TCP、TLS、WebSocketなどの各レイヤーにはそれぞれ役割がありますが、ハンドシェイクやカプセル化の処理が増えることもあります。Webページに多数のリソースが含まれる場合、接続の再利用によって一部のコストを分散できます。ただし、再利用されるかどうかはクライアント、プロトコル、アプリの動作によって異なります。HTTP/2系の通信方式などでは接続の構成も異なるため、「多重化」という言葉だけで速さを判断できません。接続上のリソース競合、サーバー側の制限、中間ネットワークのポリシーは、複数の通信が同時に動くときの使用感に影響します。

TrojanとVLESSを比較する際は、サーバー、TLS条件、通信方式をそろえたうえで、初回接続、連続閲覧、大容量ファイル転送の3段階を確認します。確立済みの長時間接続だけを測ると初回ハンドシェイクの差を見落とし、初回アクセスだけでは長時間のダウンロードへの影響を過大評価することがあります。同じ回線上での性能差は、設定の複雑さを受け入れるほど大きくない場合もあります。設定が正確で、クライアントが必要な機能に対応し、サーバーが適切に保守されているノードの方が、任意の機能を重ねたノードより安定して使いやすいでしょう。

インポート後に画面上でプロトコル名しか確認できない場合は、設定プレビューで通信方式とセキュリティ設定を確認できます。ただし、認証情報を含む設定全体を公開の掲示板に貼り付けないでください。各項目の意味は用語解説、GUIクライアントの比較はクライアント比較を参照してください。当サイトではClash Plusを第一候補として紹介しています。対応プロトコルは、そのプラットフォームに実際に組み込まれているコアの機能で判断してください。クライアント名だけでは互換性を確認できません。

Hysteria2とTUIC：QUIC、パケット損失、回線条件

QUICを使ったプロキシ接続

Hysteria2とTUICはいずれもQUICベースの通信方式を採用し、最新の暗号化通信やストリーム管理をプロキシに活用します。QUICはUDP上で信頼性のあるストリームを実現します。あるストリームでデータが失われても、独立した別のストリームが同じバイト列の補完を待つ必要は通常ありません。ただし、帯域や輻輳制御のリソースは共有されます。ストリーム間のヘッドオブラインブロッキングを軽減できても、パケット損失、無線の電波状況、出口の混雑がなくなるわけではありません。すべての用途で自動的に遅延が短くなるわけでもありません。

QUICはTLS関連のセキュリティ機構を使い、実装によって接続確立とデータ暗号化を処理します。また、接続を移行できるプロトコル上の仕組みを備えていますが、プロキシクライアントがその機能を完全に有効にしているかは、実装と動作環境によります。スマートフォンがWi-Fiからモバイル回線に切り替わると、アドレスの変化、NATの状態、OSのバックグラウンド制限などによって接続を再確立することがあります。QUICノードだからアプリのセッションが常に維持されるとは限りません。特に長時間バックグラウンドにした後でアプリを開く場合は注意してください。

Hysteria2の帯域設定は速度測定の結果ではない

Hysteria2は高遅延やパケット損失のある回線でのスループットを考慮して設計されており、輻輳制御や帯域関連の設定は実際の構成に応じて理解する必要があります。設定によっては上り・下りの帯域を推定し、送信方法に影響します。実際の動作はサーバーの制限やネゴシエーションの結果にも左右されます。利用可能な回線の能力を大幅に超える値を設定しても帯域は増えません。むしろキューの蓄積やパケット損失を招き、他のアプリの応答が遅くなることがあります。家庭内の共有回線では、同時に利用する人の通信も考慮してください。

HysteriaとHysteria2は名称が似ていても、設定をそのまま置き換えられません。プロトコルや設定項目が異なるため、クライアントがhysteria2として認識できる必要があります。サーバーアドレス、ポート、認証、TLSに加え、サーバーで追加の難読化が有効なら、クライアント側の設定も一致させます。Web閲覧もダウンロードも接続できない場合は、まずUDP経路、プロトコル種別、認証情報を確認してください。帯域推定値を上げ続けて、接続障害をスループット不足と誤認しないようにしましょう。

TUICの認証と輻輳制御の注意点

TUICの設定には通常、認証情報、TLS、輻輳制御に関する項目が含まれます。プロトコルの世代や実装によって互換性が異なる場合があるため、サブスクリプションに含まれるUUID、パスワードなどの認証情報はサーバーの要件に従ってください。輻輳制御アルゴリズムは、回線容量の変化やパケット損失に応じた送信方法を決めるもので、回線の状態と無関係な速度設定ではありません。固定回線で良好なアルゴリズムが、遅延の揺らぎが大きい無線回線でも同様に適するとは限りません。まず既定値で再現可能な基準を作りましょう。

切り替え可能な接続手段を残す

制限付きのゲストネットワーク、一部のモバイル回線、特定のルーター設定ではUDPが不安定になることがあります。そのような環境でTCP系ノードは動作する一方、QUICノードが2つとも失敗する場合は、サブスクリプションの再インポートを繰り返すより、接続ネットワークを優先して確認しましょう。スマートフォンのテザリングや別の回線で比較できますが、一度に変更する条件は1つにします。日常利用では動作確認済みのTCP系ノードを予備として残すと、異なるネットワークでも使いやすくなります。QUICを選ぶかどうかは、プロトコルの新しさではなく、同じ回線での実際の用途に対する結果で判断してください。

通信速度、リソース使用量、モバイル端末のバッテリー

速度を3つの段階に分けて確認する

「速い」とは、ページをすぐに開けることか、ダウンロードが速いことかもしれません。初回アクセスではDNS、接続確立、認証、宛先からの応答が関わります。継続的な転送では、出口の帯域、輻輳制御、サーバー負荷、接続ネットワークの帯域がより重要です。安定性は、接続失敗、再接続、遅延の揺らぎに現れます。プロトコルが影響するのは、その一部にすぎません。比較する際は、クリック後に画面が長時間表示されない、リソースの読み込みが途中で止まる、ダウンロード速度が徐々に落ちるなど、具体的な症状を記録しましょう。単独の速度測定値よりも、症状を明確にする方が診断に役立ちます。

テストは、初回アクセス、同じサイトのページを連続して開く、継続的なダウンロード、ネットワーク切り替えの順に固定できます。初回アクセスのテスト前には関連する接続を終了し、連続アクセスでは通常どおり接続を再利用します。毎回同じ宛先とネットワークを使い、数回繰り返して変動を確認してください。最も良かった1回だけを結果にしないようにしましょう。クライアントのテスト用アドレスは短いリクエストしか測定せず、ファイルのダウンロードとは経路が異なることがあります。同じ地域のノードでも出口が共通とは限りません。詳しくはノードの速度測定と倍率の見方を参照してください。

リソース負荷は接続処理全体から生じる

CPU負荷には暗号化、カプセル化、プロトコル状態の管理、ルール照合、データコピーが含まれます。メモリ使用量は接続数、キャッシュ、コアの実装に左右されます。TLS、QUIC、多層の通信方式にはそれぞれ処理負荷がありますが、ハードウェアアクセラレーションや接続の再利用によって相対的なコストは変わります。そのため、6種類のプロトコルに対して常に有効なメモリやCPUの順位を付けることはできません。負荷の小さいデスクトップで得た差が、エントリークラスのスマートフォン、ルーター、多数の接続を処理するサーバーでも同じとは限りません。

TUNでは仮想インターフェースとシステムのネットワークスタック間のデータ処理が増えます。DNSの引き継ぎ、スニッフィング、頻繁なテストもリソースを消費します。ルールセットが大きくても必ず動作が重くなるわけではありませんが、重複インポート、デバッグログの継続記録、高頻度の更新は不要な処理を増やす可能性があります。コアの負荷を評価する際は、これらの設定も記録してください。TUNを有効にしたQUIC構成と、システムプロキシだけを使うSS構成を直接比較して、その差をすべてプロトコルによるものと判断するのは適切ではありません。

スマートフォンのバッテリー消費とバックグラウンド通信

モバイル端末の消費電力はCPUだけでなく、無線通信の状態にも左右されます。頻繁なキープアライブ、バックグラウンドでの速度測定、サブスクリプション更新、再接続によって、端末が通信状態を繰り返し維持する場合があります。電波が弱いと、転送や再試行のコストも上がります。ダウンロード中の消費電力と、夜間のアイドル状態での消費電力は別々に測定してください。ファイルを早く転送できるプロトコルが、バックグラウンドでも省電力とは限りません。アイドル時に通信が少ない接続が、高スループット時にも最も省電力とは限りません。

バッテリー消費を調べる際は、まずOSのバッテリー画面で前面・バックグラウンドの動作時間を確認し、次にクライアントのテスト間隔、自動更新、接続ログを確認します。不要な高頻度チェックを停止し、同じサブスクリプションと画面状態で比較して、切断と再認証が繰り返されていないかを見ましょう。OSがプロキシサービスをネットワーク使用量に含める場合、表示の集計方法も影響します。アプリ一覧に表示される割合だけでプロトコルの問題と判断せず、実際の総消費量と使用時間を合わせて確認してください。

選定では、まず頻繁に失敗するノードを除外し、次に実際の用途で応答を比べ、最後に消費電力や設定を調整します。安定したTCPノードが特定のモバイル回線に適している場合もあれば、パケット損失の多い環境でQUICが継続的な転送を大きく改善する場合もあります。キープアライブや輻輳制御はクライアントの既定値から始め、問題を確認してからサーバーのドキュメントに従って調整してください。一度に複数の設定を変えると比較の基準を失い、一時的な回線の改善を設定変更の効果と誤認しやすくなります。

オリジナルのClash、Meta、mihomoの互換性

GUIクライアントとプロキシコアを分けて確認する

GUIクライアントはサブスクリプション管理、設定画面、システム連携、プロセス制御を担当し、プロキシコアは設定の解析、ルール照合、接続の転送を担当します。クライアントに特定のコアが組み込まれている場合も、コアを切り替えられる場合もあります。プラットフォームによって組み込み方も異なります。プロトコルへの対応状況は、アプリ名やインストーラー名ではなく、実際に動作しているコアの情報で確認してください。画面上に設定項目があっても、古いコアが対応する設定項目を理解できるとは限りません。

オリジナルのClashは広く使われているYAML設定形式とルールモードを確立しました。過去のオープンソースコアとPremium版には機能の違いがあるため、「オリジナルが対応」とだけ書かれていても、どの実装なのかを確認する必要があります。Clash.MetaはClashのエコシステムでプロトコルと機能を拡張し、その後プロジェクトはmihomoという名称で発展を続けています。古いガイドのMetaは通常、この技術系譜を指します。ただし、クライアントに含まれる古いMetaバイナリーが、名称変更だけで現在の実装の全機能に対応するわけではありません。

共通する設定構造があっても、すべての項目が共通とは限らない

これらのコアは、プロキシノード、ポリシーグループ、ルール、ローカルの待ち受けポートなど、多くの設定概念を共有しています。一方、新しいプロトコル、ルール種別、DNSオプション、TUNの動作が当然に後方互換となるわけではありません。新しいmihomo向けの設定を古いコアで起動すると、未知のプロキシ種別やルール、項目の解釈違いが生じることがあります。逆に、基本的な設定を新しいコアが読み込めても、既定の動作が古い環境と完全に同じとは限りません。移行時は「読み込み成功」の表示だけではなく、ログと実際の接続を確認してください。

移行後に生成された有効な設定を確認する

クライアントはサブスクリプション、全体設定、ローカルの上書き設定を統合し、コアに渡す設定を生成することがあります。サブスクリプションのポートがクライアント設定で上書きされたり、DNSやTUNが画面から一括管理されたりする場合もあります。そのためトラブル時は、元のサブスクリプションだけでなく、有効な設定とコアのログを確認してください。ファイルを直接編集しても、クライアントが次回更新時に設定を再生成すると手書きの項目は失われます。変更を維持するには、クライアントが対応する上書き機能またはマージ設定を使いましょう。

移行前にローカルルール、ポリシーグループの選択、必要な設定を保存してください。新しい環境ではまず基本的な接続を確認し、その後TUN、DNS、ルールセットを1つずつ有効にします。コアの制御用インターフェースとローカルの待ち受けポートは、想定した範囲内に保ちましょう。リモート管理が不要なら、待ち受けアドレスを安易に広げないでください。ログを確認する際は、関連するエラーと項目名だけを保存し、共有する前にサブスクリプションのURLと認証情報を削除します。設定テストに成功してもインターネットに接続できない場合は、システム連携とノードのハンドシェイクを順に確認してください。

各プラットフォームで保守中のクライアントを選ぶ

当サイトではClash Plusを第一候補として紹介しています。WindowsとmacOSではClash Verge RevやFlClash、WindowsではClash Nyanpasuも比較できます。AndroidではClash Meta for Android、FlClash、Surfboardを比較できます。LinuxではClash Verge RevまたはFlClashを選べます。Surfboardが採用する設定エコシステムには個別の確認が必要です。Clash for WindowsとClashX Metaは保守が終了したアーカイブ版です。古い環境で使い続ける場合は、新しいプロトコルやOSとの互換性に特に注意してください。

クライアントのインストーラーはダウンロードページから入手できます。iOS版Clash Plusの情報は、ストアの説明と公式サイトclashplus.ioを確認してください。プロトコルを選ぶために、アプリ内部のバイナリーを安易に置き換えるべきではありません。特に署名済みアプリやモバイルOS環境では避けてください。まずクライアントが提供する更新方法を使い、コアの説明と対応するサブスクリプション形式を確認しましょう。

サブスクリプション形式、項目変換、複数端末の互換性

サブスクリプションは設定を配布する仕組み

サブスクリプションURLはノードや設定を更新するための入口であり、プロキシプロトコルの一種ではありません。Clash YAML全体、ノード一覧のみ、Base64エンコードされた共有リンク、他のクライアント向け形式などが返されることがあります。拡張子やURL名だけでは実際の内容は分からず、サーバーがクライアントからのリクエストに応じて異なる形式を返す場合もあります。インポートに失敗したら、ダウンロードの失敗と解析の失敗を分けて確認してください。前者はURL、認証、ネットワーク、後者は返された内容とクライアントが受け入れる構造に関係します。

完全な設定には、ノード、ポリシーグループ、ルール、DNSなどを含められます。プロキシプロバイダーは通常ノードの一覧のみを提供するため、それを参照するメイン設定が別途必要です。ノード一覧を完全な設定として有効にすると、ポリシーグループやルールが不足することがあります。逆に、ノード一覧しか受け付けない画面に完全な設定を渡すと、拒否される可能性があります。クライアントの説明に従ってインポート先を選び、「新しい設定を作成」「ノードを追加」「プロバイダーを追加」を同じ操作と考えないようにしてください。

共有リンクの変換では情報が失われることがある

ss://、vmess://、trojan://、vless://などのリンクにはノード設定が含まれますが、オプション項目の扱いや対応状況はツールによって異なります。変換ツールがアドレスや認証情報を正しく変換しても、通信パス、プラグイン、REALITY、UDP設定が失われることがあります。変換後のYAMLを解析できても、それは構文が有効であることを示すだけで、すべてのプロトコル設定が等価である証明にはなりません。新しいプロトコルを使う場合は、利用するコアが標準対応しているサブスクリプション形式を優先してください。

変換後は、プロトコル種別、ポート、セキュリティ層、サーバー名、通信方式の項目を個別に比較します。クライアント側でDNSがすでに上書きされているのに、変換ツールがノードを変更したと誤認しないでください。また、ポリシーグループから参照されていない名称をプロトコルの失敗と混同しないようにしましょう。ノード名を変更するとルールやグループから参照できなくなることがあります。非対応ノードを削除した結果、グループが空になる場合もあります。互換性の確認では、項目が維持されているかだけでなく、参照関係が成立しているかも確認してください。

更新失敗とノード一覧が空の場合を分けて調べる

更新に失敗した場合は、ネットワークエラー、HTTPステータス、解析メッセージを確認します。ログイン画面やエラーページ、空の応答がダウンロードされ、クライアントに形式エラーと表示されることもあります。以前の設定がまだ使えるなら残したうえで、サブスクリプションの有効性を確認してください。唯一の利用可能な設定を先に削除しないようにしましょう。更新に成功したのにノード一覧が空の場合は、グループの絞り込み、キーワード検索、プロトコルの互換性を確認します。一部のノードだけが欠けている場合は、除外された種類を比較し、変換時に情報が失われた可能性を調べてください。

複数端末で同じサブスクリプションを使っていても、ローカルポート、TUNの権限、上書き設定は端末ごとに異なる場合があります。ノードを共有しても設定全体が一致するとは限りません。スマートフォンではバックグラウンド動作に適した設定を維持し、PCでは詳細なルールを利用できますが、双方のクライアントがノードのプロトコルに対応している必要があります。設定の同期方法はPCとスマートフォンの設定同期、初回の操作はサブスクリプションの追加方法を参照してください。

サブスクリプション形式を比較する際は、動作確認済みのノードを1つ基準として残し、まず単独で接続できることを確認してからポリシーグループとルールを戻してください。こうすれば形式変換の互換性とルーティングの問題を切り分けられ、複雑な設定に含まれる複数の問題が「サブスクリプションが使えない」という曖昧な結論になるのを防げます。

ルール分岐と用途に合わせた選び方

ルールが実際に選択している出口を確認する

ルールモードでは通常、接続に対してルールを順番に照合し、最初に一致したルールがポリシーを決めます。ポリシーには直接接続、拒否、プロキシノード、ポリシーグループを指定できます。ノードを切り替えてもアクセス結果が変わらない場合、DIRECTに一致しているか、既存の接続がまだ再確立されていない可能性があります。プロトコルを選ぶ前に接続履歴で宛先、一致したルール、実際に選ばれたポリシーを確認すれば、使われていないノードの性能を評価する事態を避けられます。

ドメインルールはコアが宛先ドメインを取得できる場合に利用でき、IPルールは宛先アドレスに基づいて照合します。システムプロキシ、TUN、DNSの処理、スニッフィングの方法によって、接続履歴に表示される情報も異なります。ドメインが取得できていない場合、DOMAIN-SUFFIXを変更しても反映されるとは限りません。まずアプリがどのように名前解決しているか、コアがドメインを認識できているかを確認してからルールを調整しましょう。DNSは宛先の名前解決を担い、ルールは出口を決めます。両者は影響し合いますが、同じ設定ではありません。

以下はルールの順序とポリシー参照を説明するための基本的なルーティング設定です。リモートノードを含む完全なサブスクリプションではありません。実際の設定に組み込む際は、PROXYポリシーグループから実在するノードを参照する必要があります。DIRECTは組み込みの直接接続ポリシー、REJECTは組み込みの拒否ポリシーです。PROXYは例として定義するポリシーグループ名であり、どの設定にも自動的に存在するキーワードではありません。

mode: rule
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-SUFFIX,example.org,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この設定例では、リモートの認証情報がなくても構文とルールを確認できるよう、PROXYにはDIRECTのみを指定しています。リモートプロキシへの接続は確立されません。実際に使うには利用可能なノードをグループに追加し、該当するノードを選択してください。GEOIPルールにはコアが利用できる地理データも必要です。データベースの更新問題をノードのプロトコルのせいにしないでください。MATCHはどのルールにも一致しなかった接続を処理するため末尾に置きます。先頭に置くと、後続のルールが照合されません。

用途に応じて最初に試す候補を決める

一般的なWeb閲覧やオフィス業務では、設定がそろっていて接続が安定しているSS、Trojan、または動作確認済みのVLESSノードから試せます。正常に動作している設定を、プロトコル名だけを理由に変更する必要はありません。大容量ファイルの転送では、同じ接続ネットワークでHysteria2やTUICも試し、パケット損失がある条件で持続的なスループットが改善するか確認します。リアルタイム通信では、まずアプリのUDP通信がクライアントに届き、リモート側も対応していることを確認してから遅延の揺らぎを見ます。測定遅延が最小のノードが、実際の通信でも最も安定するとは限りません。

複数端末で使う場合は、まず共通で対応しているプロトコルとサブスクリプション形式を確認し、その後に端末ごとの最適化を検討します。スマートフォンを長時間バックグラウンドで使う場合は、頻繁な再接続や自動チェックをバッテリー消費の確認対象にします。ルーターやサーバーでは、ハードウェア暗号化機能、同時接続数、コアのリソース使用量を確認しましょう。ポリシーグループに異なる通信方式の利用可能なノードを残し、ネットワークが変わったときに手動で切り替えて検証してください。未確認の自動選択によってテスト条件を次々に変えるのは避けましょう。

障害が発生したら階層ごとに原因を絞り込む

アプリが接続履歴に表示されない場合は、システムプロキシ、アプリ側の設定、TUNを確認します。履歴に表示されても誤ったポリシーに一致する場合は、ルールの順序とグループ参照を確認してください。ノードを選択した後にハンドシェイクで失敗する場合は、認証、TLS、通信方式、UDP経路を確認します。接続は成功するのに通信が遅い場合は、出口、宛先、継続的な転送を比較します。Windows Storeアプリはループバック制限の影響を受ける場合があります。詳しくはUWPのループバック制限への対処を参照してください。この種の問題はプロトコルを切り替えても解決しません。

最終的な選択では、次の3点を満たす必要があります。現在のコアが設定を正しく理解できること、接続ネットワークが通信方式を利用できること、実際の用途とリソース消費が要件に合うことです。具体的な手順はクライアント設定ガイドを、更新やクライアントの変更はインストーラーを参照してください。プロトコル名は仕組みを知る手掛かりですが、安定性は実際の接続、有効な設定、用途に沿ったテストで確認する必要があります。