プロトコル解説:プロキシプロトコルとコア選定の技術リファレンス

CL-01解説の位置付けと読み方

まず、この解説がサイト内でどこに位置するのかを説明する。Clash資源站のコンテンツは収蔵物のように体系化されている——ダウンロードセンターはプラットフォーム別のクライアントインストーラーを配布し、チュートリアルページは「サブスク導入、モード選択、接続確認」という導入の本線を担当し、選び方ガイドはクライアントソフト同士の横並び比較を扱う。本ページが扱うのはもう一段深い問題——クライアント内で動くプロトコルとコアをどう選ぶかだ。多くのユーザーはノードリストに並ぶss、vmess、trojan、vless、hysteria2、tuicといったタイプ表示に困惑した経験があるはずだ。名前が違うだけに見えて、実際には接続確立の速さ、不安定な回線での挙動、スマートフォンの消費電力、さらには古いコアでは読み込めない互換性の問題まで左右する。

読み方について、本ページは頭から通読する必要はない。8つの章はそれぞれ独立した構成になっている——CL-02は6大プロトコルの「プロフィールカード」で出自と設計思想を一つずつ説明し、CL-03とCL-04は性能面の横並び比較で、前者は速度、後者はリソースと消費電力を扱う。CL-05はコアファミリー——無印Clash、Clash Premium、Clash Meta、mihomoの継承関係を解説し、「同じ設定が一部のクライアントではエラーになる理由」を理解する鍵となる。CL-06はサブスク形式と設定項目の互換性、CL-07はそれまでの結論を用途別選定表にまとめ、CL-08は選定時に最も多い誤解を収録する。各章の冒頭にリード文があるので、まずそこを読んで深く読むかどうか判断してほしい。

2点、執筆上の注意事項を記しておく。第一に、本ページは技術解説と選定リファレンスに専念し、ネットワーク規制に関する話題は一切扱わない。プロトコルの比較軸はあくまで技術面——ハンドシェイクのコスト、暗号化の負荷、トランスポート層の特性、生態系の成熟度に限定する。第二に、本ページでは長い設定コードは掲載しない——プロトコルのパラメータは数十項目に及ぶこともあり、そのまま転記しても実用性は低い。フィールド構造を理解する助けとなる最小限のサンプルのみを必要に応じて示し、実際の設定操作はチュートリアルページで手順通りに行ってほしい。本文中に登場するサーバーアドレスやパスワードはすべて説明用の仮の値であり、そのまま使用することはできない。読み進める中でまだ馴染みのない用語があれば、技術ノートで該当する専門記事を検索し、その後本ページに戻るとよい。

CL-02プロトコル総覧:6大プロトコルの誕生背景と設計思想

プロトコルとはクライアントとサーバーの間で取り決められた「話し方」だ。6つの主要プロトコルはそれぞれ誕生した時代も解決したい課題も異なるため、絶対的な優劣は存在せず、あるのは設計上のトレードオフの違いだけだ。まず全体表で座標を掴み、その後ひとつずつ詳しく見ていく。

Shadowsocks:ミニマリズムの原点

Shadowsocksは6つの中で最も歴史が長く、「やることを減らす」という設計思想を持つ——クライアントとサーバーがパスワードを共有し、トラフィックを対称暗号で封装してそのまま転送するだけで、ハンドシェイクの折衝も証明書の仕組みも存在しない。現行の実装はいずれもAEAD暗号スイート(aes-128-gcm、chacha20-ietf-poly1305など)を採用し、完全性検証と性能の両立を図っている。ミニマリズムには2つの直接的な利点がある——CPU負荷が最も低く実装も最も容易で、ほぼすべてのコア・クライアントが対応していること。代償は、プロトコルの特徴が長年にわたり研究され尽くしており単体での対抗力は限定的な点で、実運用ではobfsやv2ray-pluginといったプラグインでトランスポート層を拡張することが多い。選定の基準として、SSは今も「古い端末・低スペックルーター・省電力重視」というシーンで第一候補であり続けている。

VMess:トランスポート層組み合わせの先駆け

VMessはV2Rayプロジェクト由来で、核心的な貢献は「プロトコル本体」と「トランスポート層」の分離だ——同一のVMessセッションは生のTCP、WebSocket、HTTP/2など複数のトランスポート上で動作でき、必要に応じてさらにTLSを重ねられる。このモジュール化設計により、長らく柔軟性の代名詞として知られてきた。トレードオフとしては、プロトコルヘッダにユーザーID・暗号化方式の宣言・タイムスタンプ検証などのフィールドを含み、パケットごとの固定オーバーヘッドがSSより明らかに大きい点がある。タイムスタンプ検証はクライアントとサーバーの時刻差が約90秒以内であることを要求し、スマートフォンの時刻がずれているとそのままハンドシェイク失敗につながる——これはVMessノードの「原因不明のタイムアウト」を調査する際に最初に確認すべき点だ。今日のVMessは通常WebSocket + TLSの組み合わせで使われ、互換性は非常に高いが、性能の上限は後発のプロトコルに及ばない。

Trojan:HTTPSに紛れ込む

Trojanの発想は前2つとは逆で、新しい暗号封装を発明せず、標準的なTLSをそのまま利用する。クライアントとサーバーは正真正銘のTLSハンドシェイクを行い、トラフィックの挙動は通常のHTTPSアクセスとほぼ同一——認証に失敗した接続はサーバー側で実在のWebサイトへ転送され、識別されにくさをさらに高めている。この設計によりTrojanの実装は非常に軽く、プロトコル本体はパスワードのハッシュ値と接続先アドレスのみで、追加のオーバーヘッドはほぼゼロ、性能は生のTLSの理論上限に近い。敷居はサーバー側にある——ドメインと有効な証明書が必須で、SSより導入が複雑だ。クライアント側ではsniフィールドがサーバー証明書と一致している必要があり、設定を誤るとTLSハンドシェイクエラーになる点に注意。クライアント利用者にとって、Trojanは「安定・低オーバーヘッド・行儀の良い挙動」の確実な選択肢だ。

VLESS:引き算で作られた次世代フレームワーク

VLESSはVMessの後継として登場した軽量版で、同じ生態系の出自を持つ。VMessで冗長とされた部分をすべて削り落とした——独自の暗号化を持たず(外側のTLSに委ねる)、タイムスタンプ検証も行わず、プロトコルヘッダは最小限に圧縮されている。本体が軽くなった分、安全性は組み合わせるトランスポート層に完全に依存する——一般的な組み合わせはVLESS + TLS + Visionフロー制御、あるいはVLESS + REALITY(独自の証明書を必要とせず実在するサイトのTLSフィンガープリントを利用するハンドシェイク方式)だ。設計思想は非常に明快で、「本体を暗号化ゼロにする」ことで封装オーバーヘッドを最小化し、その分を現代的なトランスポート層でカバーする。VLESSの各種フロー制御やトランスポートの組み合わせは更新が速く、古いコアでは新しいフィールドを認識できないことが多い点に注意——これがコアのバージョンに最も敏感な理由で、詳細はCL-05・CL-06両章を参照。

Hysteria2:荒れた回線のために生まれた

Hysteria2はQUICの上に構築されており、プロトコル全体がUDP上で動作し、暗号化はTLS 1.3が担う。独自性は積極的な輻輳制御を内蔵している点だ——従来のTCPはパケットロスが起きると大きく送信を控えるため、高パケットロス回線での実際のスループットは帯域幅を大幅に下回る。Hysteria2は設定した帯域幅に応じて送信を継続し、冗長化と高速再送でパケットロスに対抗する。技術的な結論は明快だ——長距離の国際回線、混雑するピーク時間帯、電波状態の悪い無線環境といった「高遅延・高パケットロス」の環境では、Hysteria2のスループットはTCP系プロトコルを大きく上回ることが多い。一方、そもそも快調な回線では優位性は目立たず、積極的な送信が同じネットワーク内の他デバイスの帯域を圧迫する可能性もある。前提条件として必須なのはUDP経路が使えることだ——一部の通信事業者や公共Wi-FiではUDPが制限・遮断される場合があり、その際Hysteria2は全体的に機能しなくなるため、選定時にはTCP系プロトコルを保険として用意する必要がある。

TUIC:QUIC生態系の軽量路線

TUICも同様にQUICを基盤とするが、「標準化・軽量化」という路線を取る——独自の輻輳制御を書き直すHysteria2とは異なり、QUICのマルチプレクシングと0-RTTハンドシェイクの能力をそのまま活用し、BBRやCubicといった標準アルゴリズムから選択できる。0-RTTは、一度接続したことのあるサーバーへの再接続がラウンドトリップ時間をほぼ消費しないことを意味し、「ネットワークを頻繁に切り替えるモバイル端末」に特に向いている。QUICが元来持つUDP転送能力も、ゲームや音声通話といったUDPトラフィックの処理を自然にしている。弱点は生態系だ——TUICは比較的新しく、対応サーバーの導入や機場(サービス提供元)の対応度は前の5つに及ばず、同様にUDP経路の可用性に依存する。「マイルドなQUICソリューション」と理解するとよい——QUICの低遅延という恩恵を得たいがHysteria2の積極的なスタイルは避けたい場合、TUICが対応する答えとなる。

CL-03接続速度とスループット:体感を決める3つの要素

ユーザーが口にする「このノードは速い」という感覚は、実際には3つの要素——接続確立の速さ(新しいサイトを開くまでの待ち時間)、安定時のスループット(ダウンロードや動画がどこまで速く流れるか)、並列処理の挙動(ページから数十のリクエストが同時に飛んだときに互いを妨げないか)——によって決まる。3つの要素を左右する要因は完全に異なるため、分けて見ないと正確な結論は得られない。

接続確立:ハンドシェイクの往復回数が決め手

プロキシ接続の確立にかかる時間はおおむね「ハンドシェイクの往復回数 × 回線遅延」で決まる。SSはハンドシェイクがなく、最初のパケットを送った時点で接続が完了する理論上最速の方式だ。Trojan、VLESS + TLS、VMess + TLSはいずれも完全なTLSハンドシェイクを1回必要とし、TLS 1.3では1往復で済む。VMessがさらにWebSocketを重ねる場合はHTTP Upgradeの往復がもう1回増え、TCP系の中では接続確立が最も遅い組み合わせとなる。QUIC陣営のHysteria2とTUICはトランスポートのハンドシェイクとTLSハンドシェイクを同一の往復にまとめ、再接続時には0-RTTによって「最初のパケットがそのままデータ」という形も実現できる。回線遅延が大きくなるほどこの差は顕著になる——同じハンドシェイクの差でも、遅延が非常に低い近距離回線ではほぼ気づかない一方、遅延が明らかな遠距離回線では数倍に拡大され、「新しいページを開く前の白画面の時間」の差として現れる。

安定時のスループット:輻輳制御と暗号化コスト

接続確立が終わった後、長時間の大容量転送(ダウンロード、高画質動画)の限界は輻輳制御と暗号化オーバーヘッドに移る。快調な回線では6種のプロトコルの安定時スループットの差は小さく、いずれも回線帯域幅に近づける——この場合は暗号化コストが上限を決める要因になる。SSとTrojanは封装が最も薄く、VMessはパケットごとのヘッダオーバーヘッドのために、小さなパケットが密集するシーン(画像の多いページなど)ではやや不利になる。回線に持続的なパケットロスが発生すると状況は一変する——TCP系プロトコル(SS/VMess/Trojan/VLESS over TCP)はカーネルTCPの送信抑制ポリシーに縛られ、パケットロス率の上昇に応じてスループットが急落する。Hysteria2は独自の輻輳制御により同等のパケットロス下でも設定帯域幅に近いスループットを維持でき、TUICもBBRを選べば従来のTCPより明らかに優れる。これが「ピーク時間帯にQUIC系プロトコルの方が体感が良い」という技術的な根拠だ。

並列処理とヘッドオブラインブロッキング

現代のWebページは数十のリクエストを同時に発することが珍しくない。単一のTCP接続上で動作するマルチプレクシング(VMessのmuxなど)にはヘッドオブラインブロッキングの問題がある——1つのパケットロスが接続上のすべてのリクエストを止めてしまう。QUICはトランスポート層でこの問題をネイティブに解決し、各ストリームが個別に再送されるため互いに影響しない——Hysteria2とTUICが「ページ内の多数の小さなリクエストが並列に飛ぶ」シーンで体感が滑らかなのはこのためだ。TCP系プロトコルの対応策はマルチプレクシングを使わず、カーネルにリクエストごとに個別接続を張らせる方法で、接続の再利用プールと組み合わせれば悪くない並列処理性能が得られるが、代償として接続確立の頻度が増える。実際にテストする際はシーンを分けて考えるとよい——大容量ダウンロードでスループットを測り、画像が並ぶページで並列処理を測り、新しいドメインへの初回アクセスで接続確立を測る。単一の遅延値(ping)は回線の距離しか反映せず、この3つのいずれとも等価ではない——この誤解はCL-08でさらに詳しく取り上げる。

CL-04リソース消費とモバイル端末での消費電力

デスクトップ利用者はプロキシコアがどれだけCPUを使うかをあまり気にしないが、スマートフォン利用者は毎日バッテリー残量とにらみ合っている。この章では「リソース消費」を暗号化計算・プロトコルスタックの位置・無線モジュールのウェイクアップという3要因に分けて解説し、モバイル端末での実践的なアドバイスを示す。

暗号化計算:ハードウェアアクセラレーションが分かれ目

対称暗号はプロキシトラフィックの固定コストだ。この十年に登場したスマートフォンやPCのCPUには一般にAES命令セットが内蔵されており、aes-128-gcmのようなスイートの暗号化・復号はほぼ感知できないほどCPU負荷がかからない。ハードウェアアクセラレーションのない古い機器(一部の低スペックルーター、古いテレビボックスなど)ではchacha20-ietf-poly1305を選ぶべきで、これは純粋なソフトウェア実装向けに最適化されており、同等の安全強度でソフトウェアAESの数倍の速度を実現できる。プロトコルの観点では、SSとTrojanは暗号化が1層のみで計算コストが最も低く、VMessは独自の暗号化に外側のTLSが重なる二重暗号化構成となり、6つの中で単位トラフィックあたりのCPUコストが最も高い組み合わせだ。VLESSが本体を暗号化しない設計を取っているのは、まさにこの冗長な層を排除するためだ。ルーターでmihomoコアを動かす場合、この差がデバイスが帯域幅を使い切れるかどうかを直接左右する。

QUICのユーザー空間コスト

TCPのプロトコルスタックはオペレーティングシステムのカーネル内で動作し、数十年にわたり最適化が重ねられている。一方QUICは現在主にユーザー空間で実装されており、同じトラフィック量でもCPU使用率は概してTCP系プロトコルより高く、メモリ使用量もやや多い。デスクトップではこの差はさほど問題にならないが、スマートフォンで大容量トラフィックを長時間Hysteria2/TUIC経由で流すと、発熱と消費電力がSS/Trojanよりも明らかに一段上がる。結論は「スマートフォンではQUICを使うな」ではなく、「QUICの恩恵は使うべき場面に絞る」ことだ——回線が悪いときに得られる体感の向上は消費電力の代償を大きく上回るが、回線が良いときには使わないパケットロス耐性のために電力を払う必要はない。ポリシーグループの自動切り替えに対応したクライアントであれば、QUICノードとTCPノードを混在させ、ルールに応じて選択させるとよい。

無線モジュールのウェイクアップとハートビート:モバイル端末の消費電力の大半

スマートフォンの消費電力の本当の大半は、計算処理ではなく、モバイル通信/Wi-Fiモジュールが休止状態から何度も呼び戻されることに起因する。長時間接続を保つプロトコルが頻繁にハートビートを送っていると、たとえ1回数十バイト程度でも無線モジュールが深い休止状態に入るのを妨げてしまう。この点でQUIC系にはよく見過ごされる利点がある——接続マイグレーションだ。スマートフォンがWi-Fiとモバイル通信を切り替える際、TCP接続は一度切断して再確立する必要があり(完全なハンドシェイクとトラフィックの再送が1回発生する)、QUIC接続はそのまま新しいネットワークに移行して使い続けられる——通勤時の頻繁な再接続こそ消費電力とカクつきの原因のひとつだ。実践的なアドバイス:モバイル端末ではAndroid向けのClash PlusやFlClashといったmihomoコアベースのクライアントを優先し、TUNモードは必要に応じてオンオフする(仮想ネットワークカードが全体を引き受けることで常駐の追加負荷が生じる仕組みは、技術ノートのTUNモード解説を参照)。ポリシーグループの自動測定間隔は詰め過ぎないように——数百ミリ秒ごとのヘルスチェックはスマートフォンでは典型的な電力消耗の元だ。

CL-05コアファミリー:無印Clash・Meta・mihomoの関係

「コア」とはクライアントの画面の裏で実際にトラフィックを処理するエンジンのことだ。市場に出回るClash系クライアントはすべて同じ設定文法を共有しているが、エンジンには世代の違いがある——この関係を理解していないと、「同じサブスクがクライアントAでは使えるのにクライアントBではエラーになる」という現象を説明できない。

3世代コアの継承関係

無印Clashコアがこの生態系の基礎をすべて確立した——YAML設定、プロキシグループ(ポリシーグループ)、ルールベースの振り分けだ。対応プロトコルはSS、VMess、Trojan、Socks5、HTTPが中心だった。原作者はその後クローズドソースのPremium版を保守し、TUNモードやルールセット(rule providers)といった上級機能を追加した。無印のリポジトリが更新停止した後、コミュニティ派生版のClash Metaが主線を引き継ぎ、対応プロトコルを大幅に拡張しながら活発な開発を続けた。その後Metaプロジェクトはmihomoに改称された——今日「Clash Metaコア」と「mihomo」と言うとき、指しているのは同一プロジェクトの同一主線のことだ。この継承関係を理解すれば、選定ルールは一言に凝縮できる——設定文法は後方互換、対応プロトコルは増える一方、新しいプロトコルは必ずmihomoで判断する。

機能差の対照表

クライアントとコアの対応関係

クライアントはコアの見た目の皮に過ぎず、クライアントを選ぶことは実質的にコアを選ぶことに等しい。当サイトのダウンロードセンターに掲載されている現行クライアント——Clash Plus(全プラットフォームで第一推奨)、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android——はいずれもmihomoコアをベースとしており、6種すべてのプロトコルが利用可能だ。アーカイブ区分のClash for WindowsとClashX Metaは保守終了済みで、前者が搭載する無印/Premiumコアはvless、hysteria2、tuicノードを読み込めず、サブスクにこれらのプロトコルが含まれると「unsupported proxy type」エラーが出るか設定全体の読み込みに失敗する。これが「Clash for Windowsの代替を探す」が検索頻度の高いキーワードになっている理由だ——古いソフトが壊れたわけではなく、プロトコルの生態系が前に進んだだけだ。各クライアントの画面や機能の違いは選び方ガイドの項目別比較を参照。サーバーやルーターの利用者はmihomoコアの単体バイナリをダウンロードセンターから直接取得し、GUIを介さずに動かすことができる。

CL-06サブスク形式と設定ファイルの互換性

プロトコルとコア以外に、もうひとつよくつまずくポイントがサブスク形式だ。同じノード群が複数の形式にパッケージ化されて配布されることがあり、クライアントがそのサブスクを読み込めるか、読み込んだ後にフィールドが失われないかには明確な傾向がある。

主流の3つの配布形式

現在流通しているサブスクは大きく3種類に分かれる。1つ目はClash YAML完全設定——proxies、proxy-groups、rulesを含む完全なYAMLファイルで、Clash系クライアントに直接インポートでき、情報の保持が最も完全なため、当サイトのチュートリアルでも標準採用している形式だ。2つ目はBase64共有リンク集——ss://、vmess://、trojan://といった単体ノードのURIをBase64エンコードして行単位で連結したもので、汎用性は最も高いが、ノードの接続パラメータしか持たず振り分けルールやポリシーグループは一切含まれないため、Clash系クライアントに導入する前に変換が必要になる。3つ目はsing-box JSONなど他の生態系の形式で、Clash系クライアントは直接対応しておらず、変換サービスで翻訳する必要がある。手元のサブスクがどれに当たるかは、サブスクリンクをブラウザで開いて内容を見れば分かる——YAMLはインデントが整った構造をしており、Base64はスペースのない長い英数字の連なりになっている。

フィールドの互換性:同じYAMLでも世代差がある

Clash YAML文法は全体として後方互換だが、mihomoが拡張したフィールドは無印コアでは拒否または無視される。代表例は、新しいプロトコルのtype値(vless、hysteria2、tuic)、rule-providersルールセット、sniffer検知セクション、GEOSITE系ルール、そしてVLESS関連のflowやreality-optsといったトランスポートフィールドだ。逆方向は問題ない——無印コア向けに書かれた古い設定は、mihomoでもそのまま読み込める。ノード項目のプロトコルタイプを見分けるにはtypeフィールドを確認すればよい。以下は構造を把握するための最小限のサンプルだ(パラメータはすべて仮の値で、構造確認のみを目的としている):

proxies:
  - name: "サンプル-Hysteria2"
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: "your-password"
    sni: hy2.example.com

  - name: "サンプル-Shadowsocks"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

サブスク変換と複数設定の管理

形式がクライアントと一致しない場合に登場するのが「Clashサブスク変換」だ——変換サービスが元のサブスクを読み込んで目的の形式を出力し、変換時にリモートテンプレートを適用してポリシーグループや振り分けルールを補完することもできる。変換サービスを使う際は2点注意したい——サブスクリンクは第三者サービスを経由するため、プライバシーに敏感なユーザーはサブスク提供元にClash YAML形式を直接発行してもらうよう優先的に求めるべきだ。また変換テンプレートは最終的なポリシーグループの構造を決めるため、複雑すぎるテンプレートは設定の読み込みを遅くするので、シンプルなテンプレートを選ぶのがよい。複数のサブスクを併用する際の命名・更新・切り替え戦略については、技術ノートのProfileの基本概念という記事に詳しくまとめている。具体的なクライアントでのインポートボタンの位置や更新間隔の設定方法はチュートリアルページのプラットフォーム別セクションを参照し、ここでは繰り返さない。

CL-07用途別の選定ガイド

前の6章の結論をここでまとめる。選定の正しい順序は——まずコアを確認し(mihomo系クライアントならプロトコルは全対応)、次に自分の主な用途に応じてプロトコルを選び、最後に異なるトランスポート層のプロトコルを保険として用意する。以下、5つの典型的なシーン別に参考結論を示す。

デスクトップでの日常業務とWebブラウジング

回線品質は概して安定しており、接続確立の速さと並列処理の体感が極限のスループットより重要になる。TrojanかVLESS + TLSが第一候補——暗号化が1層で軽く、挙動も安定しており、TLS 1.3の1往復ハンドシェイクによって新しいページが軽快に開く。SSも十分に使えて、どのクライアントでも導入の敷居がない。ポリシーグループは同じプロトコルの複数ノードをurl-test自動選択グループにまとめるとよく、ヘルスチェックの間隔は数分に1回程度で十分——デスクトップならバックグラウンドトラフィックはさほど気にならないが、詰め過ぎたチェックはノード側にも無駄な負荷をかける。クライアントはダウンロードセンターのWindows区分の順に選び、まずはClash Plusがおすすめだ。

モバイル端末での通勤利用と省電力優先

スマートフォンのシーンで重要なキーワードは、ネットワークの切り替えと消費電力の2つだ。プロトコルはTUICかTrojanの二択がおすすめ——TUICの0-RTTと接続マイグレーションの特性は「エレベーターを出た瞬間の通信断・再接続」に効果的で、Trojanは単位トラフィックあたりの消費電力が最も低いのが強みだ。VMessはスマートフォンでは比較的割に合わない選択肢だ——二重暗号化で電力を消耗し、タイムスタンプ検証もスマートフォンの時刻のズレによるハンドシェイク失敗を招きやすい。CL-04の省電力チェックリストに沿ってクライアントの設定を調整しつつ、Android利用者はダウンロードセンターのAndroid区分からClash PlusまたはFlClashを取得し、iOS利用者はダウンロードページのiOS区分の案内に従ってApp StoreからClash Plusを導入するとよい。

不安定な回線・高パケットロス・ピーク時間帯

判断基準:遅延が大きく揺れる、ダウンロード速度が帯域幅より明らかに低い、動画が何度もバッファリングする——これがHysteria2の本領発揮の場面だ。独自輻輳制御が高パケットロス回線で発揮するスループットの優位性はCL-03で説明した通りで、体感差は「高画質動画を快適に見られるかどうか」というレベルになることが多い。確認すべき前提が2つある——利用中のネットワークでUDP経路が制限されていないこと(公共Wi-Fiや一部モバイル通信でよく起きる問題)、そしてノード側に設定された帯域幅パラメータが実際の線路と一致していること——帯域幅の値を過大に設定すると無効な再送が大量発生し、逆に遅くなる。保険は必須だ——同じポリシーグループにTrojanかSSのノードを入れておき、UDPが通らない場合は手動またはルールで切り替える。

ゲーム・リアルタイム音声通話・低遅延が必要な場面

リアルタイム系アプリの悩みはUDPトラフィックの転送と遅延のブレだ。第一候補はTUIC——QUICネイティブのUDP転送経路はクリーンで、標準的な輻輳制御はHysteria2のようにスループットのために滑らかさを犠牲にすることがなく、安定した小さなパケットの流れに向いている。次点はHysteria2。TCP系プロトコルがUDPを転送するには余分な封装が必要で、遅延とブレが一段増える傾向があり、できれば避けたい。加えて振り分けルールにも注意——ゲームトラフィックはプロセスまたは宛先ネットワーク帯で固定ノードを直接指定するのがよく、自動測定グループには任せない方がよい。測定による切り替えの瞬間に起こる接続マイグレーションはダウンロードには影響しないが、進行中の対戦では切断につながる。ルールの書き方はチュートリアルページのルールセクションに入口がある。

古い機器・ルーター・常駐サービス

Raspberry Pi、ソフトルーター、NASといった機器の制約はCPUとメモリだ。プロトコルはSS(ハードウェアAESがない場合はchacha20スイート)かTrojanを選び、QUIC系のユーザー空間コストとVMessの二重暗号化を避ける。コアは直接mihomo単体バイナリを使い、機器のアーキテクチャに応じてAMD64/ARM64/ARMv7/MIPS版を選び、GUIは動かさない。常駐サービスでは設定の複雑さも抑える必要がある——数千のルールと数十のポリシーグループはメモリ使用量を大きく押し上げるため、ルーターでは簡素なルールセットを使い、複雑な振り分けはデスクトップ側に任せるのがよい。

CL-08選定でよくある誤解と検索の手引き

最終章では相談頻度の高い認知の誤解をいくつか収録し、サイト内での続きの検索経路を示す。これらの誤解に共通するのは——結論だけを見ると筋が通っているように見えるが、その推論過程には重要な一段が欠けているという点だ。

誤解その1:プロトコルは新しいほど良い

プロトコルの「新しさ」が解決するのは特定の場面における特定の課題であり、全面的な性能向上ではない。VLESSはVMessに対する明確な引き算の最適化だが、Hysteria2とTUICがTrojanに対して世代を超えた優位性を持っているわけではない——回線が快調であればこの3つの体感差はほとんどなく、QUIC系はむしろユーザー空間CPUとUDPの可用性という2つのコストを追加で払っている。正しいやり方はCL-07の用途別シーンに当てはめて選ぶことであり、無条件に新しいものを追い求めることではない。同様に「あるプロトコルは既に古い」という言い方も割り引いて考えるべきだ——SSは最も早く生まれたプロトコルだが、低スペック機器のシーンでは今も代替のない最適解であり続けている。

誤解その2:遅延の数字がそのまま体験を表す

クライアント内の遅延テスト(テストURLへのHTTPリクエストにかかる時間など)が反映するのは「今この瞬間そのノードへ1往復するのにどれくらいかかるか」だけで、スループット・パケットロス率・並列処理の挙動とは別問題だ。遅延の数字が良いノードでも帯域幅が極端に狭い場合があり、ピーク時にパケットロスが激しいノードでも深夜にテストすれば良い数字が出ることもある。ノード選びは時間帯を変えて複数回テストし、大容量トラフィックのシーンではさらに実際のダウンロードテストを補うべきだ。ノードが全滅した場合もすぐにサブスクを変えようとせず、技術ノートの切り分けの順序に沿って自分のネットワークから確認していくとよい——大半の問題は自分に最も近い部分に潜んでいる。

誤解その3:暗号化の層数が多いほど安全

VMess over TLSの二重暗号化は歴史的な負の遺産であり、安全性の向上ではない——外側のTLSがすでに確立されている前提では、内側の暗号化は追加の秘匿性を提供せず、CPUを消耗するだけだ。VLESSが本体の暗号化を削除し完全にTLS 1.3を信頼する設計にしても、安全強度は損なわれない。これはまさに現代のプロトコル設計における共通認識だ——信頼できる暗号化1層は、重複した多層の暗号化に勝る。安全性を評価する際は暗号スイートと実装の質を見るべきで、層の数を数えることではない。

誤解その4:コアのバージョンをむやみに追うか、旧版に固執する

どちらの極端にも代償がある。更新停止したコアに固執する問題はCL-05で十分説明した通り——新しいプロトコルが一切使えなくなる。一方、コアのメジャーバージョン更新には設定フィールドの調整が伴うことがあり、むやみに即時アップグレードすると旧設定に小さな修正が必要になる場合がある。無難なペースは——クライアントを活発に保守されているバージョン系列に保つこと(ダウンロードセンターの推奨順はこれに基づいている)、メジャー更新後はまずバックアップした設定で検証し、それから日常利用に切り替えることだ。設定ファイルのバックアップと複数Profile管理の方法は、CL-06章末に示したノートのリンクを参照。

次はどこへ進むか

本解説を読み終えたら、サイト内の続きの経路は必要に応じて利用してほしい——実際にインストールするならダウンロードセンターからプラットフォーム別に取得する。初めての設定はチュートリアルページの3ステップの本線に沿って進める。クライアントソフト同士で迷ったら選び方ガイドの横並び比較を確認する。TUNモード、DNSリーク、macOSの権限といった専門的な問題は技術ノートでタグから検索する。本ページはプロトコル生態系の進化に応じて不定期に改訂され、登録情報はページ冒頭の収蔵カードを正としてほしい。