技術リファレンスプロトコル・コア・互換性

Clash プロトコルとコアの解説

プロトコルの種類から実際の接続性能まで、コアの対応状況やネットワーク環境、端末のリソースを踏まえて選べます。

Clash / Meta / mihomo TCP / UDP / QUIC サブスクリプション形式と設定項目の互換性

このページは体系的な情報を確認するためのもので、初回接続の手順を置き換えるものではありません。インストール、サブスクリプションの追加、接続先の確認がまだの場合は、まず使い方ガイドに沿って接続を確立し、その後でプロトコルの違いを比較してください。ここでは、現在のコアが設定を正しく解釈できるか、利用中のネットワークに適しているか、長時間の利用でどの程度リソースを消費するかを確認します。

クライアント画面に表示されるプロトコル名は、あくまで出発点です。同じプロトコルでも、トランスポート方式や暗号化パラメーター、サーバー実装によって性能は異なり、名称だけで速度は判断できません。まずクライアントとコアの役割を整理し、プロトコル、性能、電池消費、サブスクリプションを順に確認したうえで、再現可能な選び方を紹介します。

コアの系統とクライアントの役割

画面・コア・設定の役割

Clashは歴史的なプロジェクト名であると同時に、その設定形式と互換性のあるプロキシツール全般を指す言葉としても使われます。実際の動作では、GUIクライアントがサブスクリプションの管理、システムプロキシの切り替え、権限の要求、画面操作を担当し、コアが接続の確立、ルール判定、DNS処理、データ転送を担います。両者は個別に更新されることがあるため、画面が似ていても対応プロトコルや設定項目、ネットワーク機能が同じとは限りません。

設定では、ノード、プロキシグループ、ルール、DNSの各項目を連携させます。ノードの選択は特定の出口の接続パラメーターを決めるものですが、プロキシグループを選ぶと自動テストやフェイルオーバーが動く場合があります。ルールモードを切り替えると、どの接続がその出口を使うかも変わります。問題が起きたときは、設定の読み込み失敗、プロキシグループの選択ミス、プロトコルのハンドシェイク失敗を切り分けてください。原因の異なる問題を、クライアントの変更だけでまとめて解決することはできません。

オリジナル版、Meta、mihomoの関係

オリジナル版Clashは、一般的なYAML設定の構造、ルール判定、プロキシグループの概念を広めましたが、プロジェクトはすでに開発を終了しています。Clash Premiumは別系統で配布されていた過去のバージョンで、オープンソース版とは機能が異なる部分があります。旧記事を読む際は、タイトルだけで判断せず、記事内のClashがどのコアを指しているか確認しましょう。

Clash Metaは、Clashの設定エコシステムとの互換性を保ちながらプロトコルや機能を拡張し、後にmihomoの名称で開発が続いています。そのため、古い資料にあるMetaと現在のmihomoには、プロジェクトの沿革上のつながりがあります。無関係な別々のプロトコル規格というわけではありません。ただし、名称のつながりだけで、どの時期のビルドも同じ機能を備えているとは限りません。特に新しいプロトコルのパラメーター、DNSの挙動、TUNの設定は、実際に動作しているコアで確認してください。

クライアント名は旧称のままでも、新しいコアを搭載している場合があります。反対に、新しい画面のクライアントに古いビルドが含まれていることもあります。確認するには、バージョン情報や設定、診断画面でコア名を見て、起動ログで設定の解析結果を確かめます。インストーラーのファイル名だけで判断しないでください。コアの差し替えに対応したクライアントでは、案内された手順に従い、互換性のない実行ファイルを直接上書きしないようにしましょう。

クライアントは使いやすさから選ぶ

一般ユーザーは、まずダウンロードセンターでおすすめのClash Plusを試し、OSへの対応状況とサブスクリプションの互換性を確認しましょう。そのうえで、デスクトップの操作性に応じてClash Verge RevやFlClashも検討できます。GUIの機能はクライアントの実装によって異なるため、特定のコアを使っているからといって、すべての高度な設定が画面から操作できるとは限りません。GUIに項目が見当たらない場合は、設定ファイルから有効にできるかも確認してください。

アーカイブ版のクライアントは、既存環境の再現や古い設定の読み込みには向いていますが、新しいプロトコルを選ぶ際の標準には適しません。Clash for WindowsとClashX Metaは開発が終了しています。見慣れないノード形式がある場合は、エラー項目をすべて削除する前に、まずコアが対応しているか確認してください。Mihomoコアを単独で使う場合は、設定、プロセス、権限を自分で管理する必要があるため、サーバーやルーターの運用者、コマンドラインでの管理に慣れたユーザー向けです。

SSとVMessの設計上の違い

SS：比較的シンプルな暗号化プロキシ

Shadowsocksは一般にSSと略され、SOCKSプロキシの利用形態をもとに、クライアントとサーバー間で比較的シンプルな暗号化転送を行うために設計されました。すべての接続にHTTPトランスポート層を追加する必要がないため、一般的な設定は比較的わかりやすい構成です。クライアントのサーバーアドレス、ポート、暗号化方式、パスワードが接続を左右し、どれか一つでも一致しないと、接続直後に切断されることがあります。

SSを選ぶ際は、ノードの種類がSSと表示されていることだけでなく、具体的な暗号化方式も確認してください。現在の環境では認証付き暗号化方式がよく使われ、一部ではShadowsocks 2022系が採用されています。後者は鍵の情報や実装に追加の要件があるため、一般的なパスワードを互換性のある鍵として流用できるとは限りません。同じプロトコル名でも、暗号化方式が異なれば互換性があるとは限らず、サーバー側と一致させる必要があります。

SSはリソース使用量を予測しやすい傾向がありますが、CPUの命令セット、暗号化の実装、同時接続数、サーバー性能にも左右されます。同じアルゴリズムでも、デスクトップPCと低消費電力のルーターでは処理能力に大きな差が出ることがあります。プラグインや追加のトランスポートを有効にすると、シンプルな構成ではなくなるため、プラグイン名やパラメーター、ローカル環境での対応状況も互換性の確認に含めてください。基本のSSと同じ負荷だと考えるのは禁物です。

VMess：認証とトランスポートの組み合わせが多い

VMessはV2Rayのエコシステムで生まれ、認証、データ保護、トランスポートの組み合わせに独自の設計があります。一般的な共有リンクには、サーバーアドレスとユーザーIDのほか、トランスポートの種類、TLS、パス、リクエストホストなどの設定が含まれる場合があります。クライアントはこれらをまとめて解釈する必要があり、アドレス、ポート、ユーザーIDだけでは元の接続を再現できないことがよくあります。設定が複雑に感じられるのは、特定の項目が難しいというより、組み合わせが多いためです。

VMessの認証はシステム時刻の影響を受けるため、端末の時刻が大きくずれていると認証に失敗することがあります。トラブル対処では、暗号化項目を変更する前にシステムの自動時刻設定を有効にしてください。古い資料には過去の認証方式や追加のIDパラメーターが記載されていることもありますが、現在の環境にそのまま適用できるとは限りません。サーバーから提供された完全な設定と、現在のコアの対応状況を基準にし、用途のわからない古い項目を新しいクライアントに機械的に追加しないでください。

同じVMessでも、ネイティブTCPとWebSocketでは、接続経路やハンドシェイク、中継サービスの要件が異なります。WebSocketを使う場合は、パスとリクエストヘッダーを入口側の設定に合わせる必要があります。TLSを有効にしている場合は、証明書とサーバー名も確認してください。接続失敗はVMess自体が使えないことを意味するとは限りません。トランスポートの経路が書き換えられた、入口の設定が一致していない、サブスクリプションの変換時に追加項目が失われた、といった原因も考えられます。

比較するなら条件をそろえる

すでに安定して使えるSSノードがあるなら、プロトコル名だけを理由に移行する必要はありません。日常のウェブ閲覧や一般的なダウンロードには、そのままで十分なことが多いでしょう。サービス提供元から完全なVMess設定が渡されている場合は、まずトランスポートの組み合わせを維持したまま実測してください。どちらのプロトコルも、名前だけでUDPを使うアプリの動作が保証されるわけではありません。クライアント、コア、サーバー、通信の取り込み方式がそろって対応している必要があり、設定のUDPスイッチだけでサーバー側の機能を補うことはできません。

比較する際は、回線とテスト内容をそろえ、初回接続、再アクセス、継続的なデータ転送をそれぞれ確認してください。一方がWebSocketとTLS、もう一方が直接の暗号化通信を使う場合、結果に反映されるのはプロトコル単体の優劣ではなく、構成全体の違いです。解析、接続、認証、アプリの応答のどの段階で失敗したかがわかるログを残すと、すべての問題を「ノードのタイムアウト」とまとめるより、次の対応に役立ちます。

TrojanとVLESSのセキュリティ境界

Trojan：接続の基盤にTLSを使用

TrojanはTLSを前提とする接続方式で、保護された通信路を確立してから認証し、プロキシ要求を転送します。一般的な設定項目は少なく見えますが、証明書チェーン、サーバー名、パスワードのいずれも欠かせません。接続先アドレスにはドメイン名またはIPアドレスを指定できます。一方、TLS検証に使うサーバー名は、サーバー証明書や入口の設定と一致している必要があります。両者は関連しますが、必ず同じ項目とは限りません。

TLSは通信の暗号化とサーバー認証を担います。接続に失敗したからといって、証明書検証の無効化を定番の修復方法にしないでください。証明書の期限切れ、システム時刻の誤り、名前の不一致、信頼チェーンの不足は、似たハンドシェイクエラーを引き起こすことがあります。まずログで原因を特定し、その後に証明書や名前の設定を修正しましょう。サーバーが独自の信頼体系を使っている場合は、クライアントがサポートする証明書の信頼設定を利用し、検証を恒久的に無視しないでください。

Trojanの実際の性能は、TLSの実装、接続の再利用、回線状況に左右されます。初回接続では通常、下位のトランスポート接続とTLSハンドシェイクが行われます。その後のリクエストで既存の通信路を再利用できるかは、実装と設定によって異なります。TLSを使うからすべての小さなリクエストが遅いとは限りません。また、既存接続を使ったテストが一度速かったからといって、ネットワーク切り替え後の新規接続も速いとは限りません。テストでは状態を分けて確認してください。

VLESS：プロトコル層とセキュリティ層を分けて考える

VLESSはプロキシプロトコル自体の処理をシンプルにし、データ保護を選択したセキュリティ層やトランスポート方式に委ねる設計です。一般にユーザーIDで認証しますが、ユーザーIDが通信の暗号化を意味するわけではありません。設定の種類がVLESSと表示されているだけで、機密性と認証が十分だと判断しないでください。TLS、REALITYなど対応する組み合わせの実際の設定と、サーバー側の設定が一致しているかを確認する必要があります。

対応する環境では、REALITYは一般的な証明書設定とは異なる認証パラメーターを使います。公開鍵、短いID、サーバー名などの項目にはそれぞれ明確な意味があり、自由に書き換えてよいメモではありません。これらのパラメーターを使えるかどうかは、クライアントへの統合方法やコアの実装にも左右されます。共有リンクに情報が含まれていても、追加後の設定を確認してください。特に、変換ツールが未対応の項目を削除していないか注意が必要です。

VLESSでは、トランスポート方式とフロー制御の設定も個別に確認してください。他のエコシステムのクライアントで使えるノードでも、Clash系クライアントでそのまま動作するとは限りません。プロトコルの種類が同じでも、トランスポート拡張が異なれば互換性がない場合があります。未知のフロー制御値を似た値に置き換えても、通信の意味が変わる可能性があるため、安易な修正は避けてください。現在のコア向けに用意された設定を入手するのが確実です。

認証・暗号化・通信の取り込みを混同しない

パスワードやユーザーIDは認証に使い、TLSなどのセキュリティ層は接続を保護します。TUNやシステムプロキシは、アプリの通信をコアに渡す役割を担います。それぞれ異なる層の設定です。TUNを有効にしても、TLSのパラメーター不足は解消されません。ルールモードを切り替えても、証明書名の誤りは直りません。まずシステムプロキシで基本の接続を確認し、その後で通信を取り込む範囲を少しずつ広げると、条件を同時に変えずに原因を特定できます。

実際の選び方としては、Trojanは、TLSを適切に構成した環境がすでにあり、パラメーターをまとめて管理したい場合に向いています。VLESSは、必要なトランスポートの組み合わせが明確で、サーバーとコアの対応状況を確認できている場合に適しています。どちらも回線品質に関係なく高速なわけではありません。クライアントを使う側にとっては、目新しいプロトコル名より、完全で管理しやすく、検証を維持できる設定のほうが重要です。

Hysteria2とTUICのQUIC接続

QUICでできることと必要な条件

QUICはUDP上に信頼性のある転送を構築し、最新のTLSハンドシェイクを統合します。1つの接続で複数のストリームを扱えるため、あるストリームでデータが失われても、単一のTCPバイトストリームのように他のストリームの配信まで必ず止まるわけではありません。この設計は複数リクエストの並行処理や、一部のパケットロスがある環境で効果を発揮する可能性があります。ただし、QUICにも再送、輻輳制御、暗号化処理は必要で、帯域幅、遅延、サーバー負荷の制約を回避する近道ではありません。

QUIC系のプロキシを使う前に、利用中のネットワークでUDP通信が安定しているか確認してください。ウェブ閲覧には問題がなくても、UDPのセッション保持時間が短い、速度が制限される、通信自体が破棄されるネットワークがあります。その場合、TCP系ノードは使える一方でHysteria2やTUICがタイムアウトしても不思議ではありません。クライアントでUDP転送を有効にしても、接続ネットワークのUDP制限は変えられません。別のネットワークに切り替えるか、適切な代替出口を使ってください。

Hysteria2：帯域幅の設定が送信動作に影響

Hysteria2はQUICを利用するプロキシ方式です。旧世代のHysteriaとは互換性がないため、ノードの種類名を書き換えるだけでは移行できません。認証、TLS、その他のプロトコル設定をクライアントとサーバーで一致させる必要があります。サブスクリプションの表示が曖昧な「Hysteria」だけの場合は、世代と対象形式を設定提供元に確認してください。ハンドシェイクの不一致を、サーバーの一時的な負荷と誤認しないようにしましょう。

Hysteria2の輻輳制御や帯域幅のネゴシエーションは、接続性能に影響します。Brutalを使う構成では、上下の帯域幅の設定が特に重要ですが、数値を大きくすればよいわけではありません。実際の回線能力を大きく超える設定は、パケットロスやキューの増加、他のアプリの待ち時間につながることがあります。継続的に使える帯域幅をもとに控えめに設定し、単位も確認してください。最終的な動作はサーバー側の方針とクライアントの実装にも左右されます。

別の輻輳制御方式を使っている場合は、他の設定にある帯域幅パラメーターを無理に適用しないでください。まず現在のコアが項目をどう解釈するかを確認し、一度に一つの値だけ変更して再テストします。オプションの難読化もサーバー側と一致させる必要があり、設定すれば必ず接続が改善するわけではありません。一般ユーザーには、説明のない高度な設定を頻繁に試すより、提供元に確認した完全な設定を維持するほうが安定します。

TUIC：複数ストリーム接続とUDP転送

TUICもQUICを利用してプロキシ接続を運び、複数ストリーム通信やUDP転送に対応する仕組みを備えています。世代によって認証項目や動作が異なる場合があります。現在よく見られる設定には、ユーザーID、パスワード、TLS、輻輳制御などが含まれます。追加する際は、サーバーが明確に対応している世代に合わせてください。すべてのTUIC共有リンクを古いコアが認識できるとは限りません。

TUICではUDP転送の方式、キープアライブ、輻輳制御の設定によって、用途別の性能が変わります。多数の同時リクエスト、リアルタイムのデータグラム、長時間のダウンロードでは、接続に求められる条件が異なります。ダウンロードに有効な設定が、音声通話にも適しているとは限りません。0-RTT関連の設定ではリプレイ攻撃のリスクや実装の既定動作も考慮してください。速度測定の結果を短縮するだけの目的で有効にせず、クライアントとサーバーが推奨する組み合わせを優先しましょう。

TCPの予備経路を確保する

Hysteria2とTUICは、高遅延やパケットロスのあるネットワークで比較する価値があります。ただし、成功したときの速度だけでなく、接続成功率も含めて評価してください。Wi-Fiなどの無線ネットワークの切り替え、端末のスリープ、携帯電話事業者のUDP制御は、長期的な使いやすさに影響します。検証済みのTCP系ノードを予備として残し、自動プロキシグループのテストが実際のアプリの要件を反映しているか確認しましょう。ウェブの疎通確認は成功しても、リアルタイムアプリは動作しない場合があります。

接続速度とリソース使用量の比較方法

接続の各段階を分けて考える

ウェブページへのリクエストでは、DNS名前解決、プロキシサーバーへの接続、プロトコル認証、接続先への通信、アプリの応答などが発生します。画面上の遅延テストが測るのは、通常、特定の確認先へのリクエスト時間です。物理的な往復時間そのものでも、ダウンロード速度でもありません。クライアントによってテスト先やタイムアウト、接続再利用の有無が異なるため、表示値をソフトウェア間で単純に比較したり、1回のテストで長期的な性能を判断したりしないでください。

新規接続ではトランスポートとセキュリティのコンテキストを確立しますが、既存のセッションを再利用できる場合は、接続済みの状態で通信できます。短いウェブページ、頻繁に開く小さなAPI、長時間のダウンロードでは、この違いへの影響度が異なります。初回表示の速度を比べるなら、同じ条件で毎回新しく接続してください。日常的な閲覧を比べるなら、連続してアクセスして再利用の挙動を確認します。一方のプロトコルは既存の長時間接続を使い、もう一方は毎回ハンドシェイクするような条件にしないでください。

同じ用途で接続全体を比較する

できるだけ同じ地域、近いサーバー条件、同じ接続先を使い、端末とネットワークをそろえて、大量の通信を伴う他のタスクを止めてください。まず接続できたかを記録し、初回の応答と継続的なデータ転送を確認します。一般的なウェブ閲覧、大きなファイルのダウンロード、実際に使うリアルタイムアプリを分けてテストしてください。1回につき変更する条件は一つだけにし、何度か繰り返して変動幅を見ます。見栄えのよい数値を出すために、最良の結果だけを選ぶ必要はありません。

確認項目主にわかることそこからは判断できないこと
初回応答名前解決、ハンドシェイク、接続先の応答の組み合わせ継続的なダウンロード速度
継続的なデータ転送輻輳制御、回線容量、サーバー性能小さなリクエストが必ず速いこと
接続成功率プロトコルの到達性と長期的な安定性認証や証明書が常に正しいこと
CPUとメモリ現在の負荷におけるローカル処理のコスト他の端末で同じ割合になること

リソース使用量は、処理したタスク量と合わせて評価してください。同じ時間内により多くのデータを転送してCPU使用率が上がっても、実装の効率が悪いとは限りません。多数のアイドル接続、ルールセット、DNSキャッシュ、GUIもメモリを使用します。コア自体を比較する場合は、できるだけクライアントの画面状態とルール設定をそろえ、クライアントのプロセスとコアのプロセスを分けて確認しましょう。画面描画の負荷をプロキシプロトコルの負荷と取り違えないためです。

接続の再利用、並行処理、回線のボトルネック

接続を再利用するとハンドシェイクを減らせますが、再利用数が多いほどよいとは限りません。複数のアプリが一つの下位接続を共有すると、輻輳や再送、サーバーの実装がアプリ同士の影響に関わります。TCPベースの接続再利用とQUICの複数ストリームは、同じ仕組みではありません。単一接続のダウンロードは正常なのに、複数のアプリを同時に使うと遅くなる場合は、共有接続や同時接続数の制限を確認してください。すぐにルールモードをグローバルへ切り替える必要はありません。

低消費電力の端末では、回線帯域より先に暗号化の実装やデータコピーがボトルネックになることがあります。高性能なデスクトップでは、サーバーの速度制限や接続先の応答が原因となるケースのほうが一般的です。長時間のデータ転送でCPU使用率が高止まりし、端末が発熱して性能が低下している場合、より複雑なプロトコルに変えても改善しない可能性があります。まず不要なカプセル化やログ出力、並行テストを減らしてから端末性能を確認しましょう。ハードウェアの制約にネットワーク設定で対処することを避けられます。

自動プロキシグループもテスト結果を左右します。url-testは確認結果に基づいて出口を選択し、fallbackは利用可能な出口を順番に使うことを重視します。load-balanceは設定した方式で接続を振り分けるもので、すべての回線の帯域幅を単純に合算する機能ではありません。切り替え条件を詳しく知りたい場合は、3種類の自動プロキシグループの切り替え動作を参照してください。プロトコルを比較する際は、まず出口を手動で固定し、グループの切り替えによる影響を除きましょう。

モバイル端末の電池消費とネットワーク切り替え

消費電力は接続全体で決まる

スマホでのプロキシ利用による電池消費を、SS、Trojan、QUICの固定ランキングだけで比較することはできません。無線モジュールの稼働時間、モバイル通信の電波強度、バックグラウンドでの起動、暗号化処理、ログ記録、アプリの通信量がすべて影響します。同じノードを使っても、画面の明るさ、位置情報の利用状況、ネットワークの電波状況が違えば、消費電力に大きな差が出ることがあります。まずテスト中のタスクが近いことを確認してから、プロトコルによる追加の負荷を比較してください。

キープアライブはセッションの維持に役立ちますが、無線モジュールを低消費電力状態から頻繁に復帰させる場合があります。一部のネットワークではQUICやUDPのセッションを維持するために、より積極的な通信が必要ですが、間隔が短すぎると端末の起動回数が増えます。長すぎると復帰後に再接続が必要になることがあります。まずは検証済みの既定値を使い、ログや再現可能な現象からセッション切れが確認できた場合に限り、必要な範囲で調整してください。

バックグラウンドのテストとログは調整できる

自動プロキシグループが多数のノードを頻繁にテストすると、画面上で使っているアプリとは無関係な通信が発生します。複数のグループが個別にテストし、クライアントでリアルタイム統計も表示していると、追加の処理が重なる可能性があります。モバイル端末では、必要のないテスト対象を減らし、利用頻度に合わせて間隔を設定するとよいでしょう。故障の検出に必要な間隔も考慮し、電池を節約するために必要な稼働確認まで完全に止めないでください。

デバッグログは短期間の原因調査に役立ちますが、すべての情報を常時記録する用途には向きません。大量のログは文字列処理やストレージへの書き込み、画面の更新を増やす可能性があります。接続パネルを開き続けることも負荷につながる場合があります。トラブル対処が終わったら、普段使いのログレベルに戻し、不要なリアルタイム表示を閉じてください。通常利用に近い電池消費を確認できるうえ、サブスクリプションのアドレスや接続先ドメインなど、機密情報がローカルログに蓄積するのを抑えられます。

TUN、システムプロキシ、プラットフォームの機能

モバイルOSは通常、システムのVPNやネットワーク拡張APIを通じて通信を取り込みます。デスクトップのシステムプロキシとTUNの設定を、モバイル端末の動作にそのまま当てはめることはできません。Androidのアプリごとの設定、バックグラウンド制限、バッテリー最適化、iOSのネットワーク拡張の実行期間やシステムのスリープ状態は、接続の維持に影響します。クライアントを選ぶ際は各プラットフォームで実際に使える機能を確認し、別のOSの権限設定をそのまま流用しないでください。

TUNを使うと取り込めるアプリの範囲は広がりますが、すべての通信が遠隔プロキシを経由するわけではありません。最終的な経路はルールによって決まります。DNSの設定ミスは検索や再試行を繰り返す原因になり、ルールの範囲が広すぎると、本来は直接アクセスできる大容量通信まで遠回りになる可能性があります。電池消費を改善する前に、通信の振り分けが意図どおりか確認してください。プロトコルだけを変えても、頻繁な再試行や誤った出口を放置したままでは、安定した改善は期待できません。

単発の速度測定より切り替え後の復旧を重視する

Wi-Fiからモバイル通信に切り替えると、送信元アドレスやルート、セッションの対応関係が変わることがあります。QUICは接続移行に対応できる設計ですが、プロキシの実装、サーバー設定、OSのライフサイクルによっては、切り替え後も毎回同じ接続を維持できるとは限りません。TCP接続も再確立が必要になることがあります。プロトコルに特定の設計上の機能があるだけで、アプリが途切れないとは判断せず、切り替え後の最初のリクエスト、スリープ復帰、電波が弱いときの復旧を実際に確認してください。

実測では、待機、軽いウェブ閲覧、継続的なデータ転送の3つに分けて記録します。それぞれ電波状況とタスク時間をできるだけそろえ、システムのバッテリー使用状況でバックグラウンド動作も確認してください。待機中に電池を多く消費する場合は、キープアライブ、接続テスト、バックグラウンドでの再接続を確認します。大容量通信中に消費が増える場合は、CPU使用率、発熱、無線ネットワークを調べましょう。原因によって対処方法が異なるため、分けて測定することが大切です。

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

リンク集と完全な設定は別物

一般的なサブスクリプションは、ノードの共有リンク集と完全なYAML設定に大別できます。リンク集は主にサーバーへの接続方法を記述しますが、完全な設定にはプロキシグループ、ルーティングルール、DNS、実行オプションも含められます。Base64はデータのエンコード形式であり、独立したプロキシプロトコルではありません。内容がエンコードされているだけでClashに対応しているとは限らず、デコード後も別のクライアント向け形式である場合は、内部構造を確認する必要があります。

ブラウザーで開けるサブスクリプションのURLが、利用可能な設定を返すとは限りません。ログイン画面、期限切れの通知、別形式のテキストが返されることもあります。更新に失敗した場合は、ネットワークのリクエスト失敗と内容の解析失敗を分けて確認してください。前者はURLへの接続と認証状態を、後者は返された形式とコアのエラーを確認します。認証情報を含むサブスクリプションURLを公開のテストサイトに送信したり、公開の問い合わせに貼り付けたりしないでください。

変換で失われる可能性がある情報

変換ツールは、入力側のプロトコル、追加のトランスポートパラメーター、出力先のコアの構文を理解する必要があります。認識できない項目をそのまま無視する場合もあれば、解析できても接続できないノードを生成する場合もあります。VLESSのセキュリティ層のパラメーター、WebSocketのリクエストヘッダー、TUICの世代、SSの特定の暗号化方式は、特に確認が必要です。ノード名が残っていても、通信に必要な設定がすべて保持されているとは限りません。

ルールやプロキシグループが失われることにも注意が必要です。ノードだけのサブスクリプションでは、元のルーティング設定は復元されません。変換時にプロキシグループの名前が変わると、ルールの参照先が存在しなくなる場合もあります。同名のノードが統合時に上書きされる可能性もあります。追加後は、ノード数と種類が妥当かを確認し、プロキシグループの参照先、最後に適用されるルールが想定どおりかの順で確認してください。追加成功の表示だけで判断しないようにしましょう。

YAMLの構文とコアの解釈を分けて確認する

YAMLはインデントで階層を表します。インデントが異なると、項目が誤ったオブジェクトに入ることがあります。構文チェックに通っても、テキストの構造を読み取れるだけで、現在のコアがすべての項目をサポートしているとは限りません。未対応の項目は無視されることもあれば、型の不一致によって読み込み全体が失敗することもあります。エラーが出たら、ログに示された項目から親階層を順に確認し、特定できた問題を一つずつ直してください。出所のわからない長いテンプレートに設定全体を置き換えるのは避けましょう。

以下は、完全な設定がすでにある環境に追加するルール例です。プロキシグループの参照とルールの適用順を示すもので、サーバー情報を含む独立したサブスクリプションではありません。最初のルールでは例示ドメインへの接続を直接接続にし、次のルールではプライベートアドレスへの接続を直接接続にします。それ以外の通信は、既存の「手動選択」プロキシグループに送ります。このグループがあらかじめ定義されている必要があります。実際のドメインと出口は用途に合わせて変更してください。ルールの順番を変えると、結果も変わる場合があります。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,手動選択

サードパーティ製クライアントは、読み込み時に独自の設定を統合したり、既存の設定を上書きしたり、ルールを追加したりすることがあります。そのため、ディスク上のサブスクリプションファイルを編集しても、変更が永続するとは限りません。次回の更新で上書きされたり、画面からの設定が優先されたりする可能性があります。長期間維持する変更には、クライアントがサポートする上書き、マージ、独立したルールの仕組みを使い、最終的に適用された設定を確認してください。ファイルを直接編集するより、バックアップを取ってから更新し、動作を確かめるほうが確実です。

データファイルも設定と合わせて管理する

GEOIP、GEOSITE、ルールセットの参照先は、それぞれ対応するデータソースに依存します。ノードのハンドシェイクは成功しているのにルーティングがおかしい場合は、データが読み込まれ、更新されているか確認してください。データ形式が異なるファイルは、拡張子を変えるだけでは置き換えられません。GeoIPとGeoSiteの更新方法で参照元を確認し、サブスクリプションの構造を比較する際はサブスクリプション形式と変換ガイドも参考にしてください。コアやデータを更新した後は、同じ接続先で結果を再確認し、意図した設定による変化か確かめましょう。

用途別の選び方とトラブル対処

条件を満たさない組み合わせを先に除外する

選ぶときは速度より先に、必須条件を確認してください。クライアントが使うコアはプロトコルとトランスポートの組み合わせに対応しているか、サブスクリプションに完全なパラメーターが含まれているか、利用中のネットワークが必要な通信方式を許可しているか、端末が長時間の負荷に耐えられるかを確認します。一つでも満たせない条件があれば、速度測定を繰り返しても解決しません。その後で実際の用途における応答、安定性、電池消費を比較し、普段使いの出口と検証済みの予備経路を一つずつ残すと、多数の未確認の組み合わせを管理するより簡単です。

日常のウェブ閲覧やオフィス業務では、安定して動作し、認証とセキュリティの設定がそろったノードを優先してください。SS、Trojan、VMess、VLESSのいずれも用途を満たせる可能性があります。成功率、接続先の応答、管理の手間を基準に選びましょう。仕事中に頻繁にネットワークを切り替える場合は、スリープ復帰とネットワーク切り替えのテストも追加してください。LAN内の端末からアクセスする必要がある場合は、ルーティング、DNS、直接接続のルールを個別に確認し、すべての通信を遠隔サーバーに送らないようにしましょう。

長時間のダウンロードや大容量ファイルの同期では、持続的な転送速度、パケットロスからの復旧、他のアプリへの影響を確認してください。Hysteria2とTUICも比較対象になりますが、UDP通信が安定し、輻輳制御が適切に設定されていることが前提です。音声通話や対話型アプリでは、ジッター、短時間のパケットロス、接続の復旧がより重要です。ダウンロード速度の速いノードが最適とは限らないため、実際のアプリを使って双方向通信をテストしてください。

ルーターや低消費電力の端末では、CPUアーキテクチャ、メモリ、冷却性能も重視してください。一般的なデスクトップユーザーにはGUIクライアントが向いています。独立したMihomoコアはサーバー管理者向けです。インストール前にコアのダウンロードページで対象プラットフォームとCPUを確認し、OS名だけで選ばないようにしましょう。既存の設定がある場合は、まず新しい環境で動作を確認し、問題がないことを確かめてから主要な通信を切り替えてください。元に戻せるよう、設定ファイルと既存の構成を残しておきましょう。

失敗した段階から原因を絞り込む

最初に、設定が読み込まれているか確認します。未知のノード形式はコアの対応状況や変換形式に、インデントのエラーはテキストの構造に原因があることが多いです。次に、サーバーへ接続できるか確認します。タイムアウトはアドレス、ポート、ルート、トランスポートが到達不能な場合に起きることがあり、接続拒否はポートが待ち受けていない、またはサービスが起動していない可能性が高くなります。その後で認証とTLSを確認し、パスワード、システム時刻、証明書の問題を切り分けます。この段階でDNSやルールを同時に変更しないでください。

4番目に、接続先とルールを確認します。一部のアプリだけ失敗する場合は、システムプロキシやTUNに通信が取り込まれているかを確認し、適用されたルールと実際の出口を調べてください。ドメイン名で失敗し、IPアドレスへの接続は成功する場合はDNSを重点的に確認します。ただし、HTTPSの適切な検証を省略して、IPアドレスへの直接アクセスで代用しないでください。すべてのノードがタイムアウトする場合は、ノードのタイムアウトを調べる順序に沿って共通の原因を確認し、同じローカルの問題を各サーバーのせいにしないようにしましょう。

接続が復旧したら、スイッチがオンになっているかだけで判断せず、出口の情報と接続パネルを照らし合わせて確認してください。初回接続の確認手順を参考に、アプリ、ルール、出口、エラーが発生した時刻を記録できます。トラブル対処の記録を作る際は、パスワード、ユーザーID、サブスクリプションの認証情報、個人用のアドレスを削除し、プロトコルの種類、コア名、ネットワーク環境、機密情報を除いたエラー内容だけを残してください。

選び方に関するよくある質問

新しいプロトコルほど速いですか？
必ずしもそうではありません。プロトコルは特定の通信や運用上の課題を解決するもので、最終的な結果は回線、サーバー、接続先のアプリ、端末によって変わります。まず利用できるかを確かめ、同じタスクを繰り返して比較してください。世代名だけで性能を判断することはできません。
追加できたのに、ノードへ接続できないのはなぜですか？
追加に成功したという表示は、主にクライアントが設定を受け付けたことを示します。変換時に設定項目が失われたり、コアが特定のトランスポート拡張に対応していなかったりする場合があります。設定の解析、サーバーへの接続、認証、接続先からの応答の順にログを確認すると、再追加するより原因を見つけやすくなります。

選んだ構成が安定したら、適したネットワーク環境とあわせて記録し、その後の更新では重要な条件を一度に一つだけ変更してください。コアの変更、サブスクリプションの変換、DNSの調整を行った後は、基本の接続確認をやり直します。明確な問題がなければ、あらゆる高度な設定を追い続ける必要はありません。このページでは選択のポイントを解説しています。インストールと追加の手順は使い方ガイドで、用語は用語集で分類ごとに確認してください。