Shadowrocketのプロトコル解説｜種類・設定項目・接続トラブルの確認

1. プロトコル選び：認証・通信方式・ルーティングを区別する

Shadowrocketのプロトコルタイプは、クライアントとサーバー間のデータのやり取りを決めるもので、サーバーの設置場所や回線速度、サービス品質を決めるものではありません。利用するには、手元にあるサーバー情報が前提です。サーバー側が提供するタイプに合わせて設定してください。Add Serverの選択項目を変えるだけで、接続方式を別のプロトコルに変更することはできません。サブスクのURLは利用中のサービス提供元から入手してください。インポート後も、タイプ、アドレス、認証情報を確認しましょう。アプリの買い切り購入と通信サービスの契約は別々に管理されます。アプリの入手方法はApp Storeで正規版を確認する方法をご覧ください。

接続を4つの層に分けて考える

第1層は認証とメッセージ形式です。パスワード、UUID、鍵のほか、サーバーがリクエストをどう解釈するかが含まれます。第2層はTCP、UDP、WebSocket、QUICベースの通信など、データを運ぶ方式です。第3層はセキュアなセッションで、プロトコル自体の暗号化を使う場合もあれば、TLSなど外側の仕組みに頼る場合もあります。第4層がルーティングで、アクセスごとにPROXYとDIRECTのどちらを使うかを決めます。各層は結果に影響しますが、互いに置き換えられるものではありません。Global RoutingをProxyに変更すれば通信先は変わりますが、誤ったパスワードは直りません。TLSを有効にしても、サーバー側と合わない通信形式が受け入れられるわけではありません。

同じプロトコル名でも、利用できる拡張機能がすべて共通とは限りません。サーバー側で特定の通信方式、パス、証明書名、追加項目が必要な場合があり、クライアントがその組み合わせの一部にしか対応しないこともあります。VMessやVLESSを使う場合は、外側の通信方式も確認しましょう。HTTPの場合は、プロキシの接続口自体がTLSで保護されているかを確認してください。画面に表示される設定項目は選択したタイプによって異なります。別の設定画面の並び順ではなく、現在のクライアントで選べる項目とサーバー側の説明を判断基準にしてください。

速度・バッテリー消費・安定性に単純な順位はない

ウェブページの表示速度には、DNSの問い合わせ、接続、認証、最初の応答、コンテンツの転送など複数の段階が関わります。長時間のダウンロードでは、出口の回線速度、パケットロスからの復旧、サーバー負荷の影響が大きくなります。小さなファイルの読み込みが速い方式でも、大容量の転送で優位とは限りません。iPhoneやiPadのバッテリー消費は、モバイル回線の電波状況、画面の明るさ、無線通信が維持される時間、バックグラウンドでの再接続にも左右されます。カプセル化の層が少ないからといって、必ず省電力になるわけではありません。通信速度が高くても、タスク全体の消費電力が少ないとは限らないため、条件をそろえて比較してください。

ネットワークの切り替えも別の要因です。Wi-Fiからモバイル回線に変わると、ローカルアドレスや通信経路が変わることがあります。既存のセッションが復旧するかどうかは、通信方式、サーバーの動作、アプリ側の再試行によって異なります。回線切り替え後に一時停止しただけで、プロトコルが使えないと判断するのは避けましょう。複数のスイッチを次々に切り替えて問題を覆い隠すのも適切ではありません。まず再現可能なアクセス操作を一つ決め、接続前と通信中のどちらで失敗するかを記録してから、確認する層を絞ります。

判断する層	確認する項目	代わりにはならないもの
認証	パスワード、UUID、鍵、有効性	サーバーへの到達性
通信方式	TCP、UDP、パス、外側のカプセル化	証明書の本人確認
セキュアなセッション	暗号化方式、TLS、サーバー名	ルールのマッチ判定
ルーティング	Global Routingとルールの順序	プロトコル設定の修正

このページでは、クライアント側の選択と設定の範囲を解説します。サービス提供元の評価は行いません。システム要件はApp Storeの掲載内容をご確認ください。対応するプロトコルや設定項目は、現在のクライアントで確認してください。出所を確認できない追加項目は、名称から推測して変更せず、インポート時の値を維持するのが無難です。サーバー側のどの設定に対応する項目かを理解してから変更してください。

2. Shadowsocks：軽量なプロキシと暗号化方式の照合

Shadowsocksは、比較的シンプルな暗号化プロキシ接続を提供するよう設計されています。クライアントが宛先アドレスとデータをサーバーに送り、サーバーが宛先へアクセスするため、両端を完全なプライベートネットワークで結ぶネットワーク層トンネルではなく、プロキシプロトコルに分類されます。基本設定は、サーバーアドレス、ポート、暗号化方式、パスワードです。項目が少なくても確認を省略してはいけません。特に暗号化方式はプロトコルのやり取りに関わる項目で、クライアント側だけで決める性能設定ではありません。サーバー側と一致しない場合、タイムアウト、即時切断、認証失敗などが起こることがあります。

暗号化方式とパスワードをセットで確認

現在のShadowsocksの構成では、受信側がデータを復号するだけでなく、改ざんも検出できる認証付き暗号化方式がよく使われます。方式によって鍵の長さや導出方法が異なり、任意のテキストパスワードではなく、形式に合ったエンコード済みの鍵が必要なものもあります。インポート時は方式名とパスワードを一字ずつそのまま保ってください。エンコードされた文字列を再度デコードして貼り付けたり、末尾の記号を不要と判断して削除したりしないでください。サブスク更新後に突然接続できなくなった場合は、まずパスワードの更新やタイプの変更がないかを確認し、その後でネットワーク層を調べます。

Add Serverで手動入力する場合は、最初にShadowsocksを選び、元の情報に従って入力してください。アドレス欄にはホスト名またはIPアドレスだけを入力し、ポートは別の欄に入力します。共有リンク全体をサーバーアドレスとして入力しないでください。プラグインや追加のカプセル化が記載されている場合は、現在のクライアントに該当する項目があり、正しくインポートされているかも確認しましょう。基本プロトコル名が同じでも、異なるプラグインの組み合わせがそのまま相互接続できるとは限りません。追加項目が不明な場合は、複数の選択肢を手当たり次第に切り替えず、利用中の設定に関する説明を確認してください。

TCPとUDPは別々に動作を確認する

ウェブ閲覧ではTCPがよく使われますが、一部のリアルタイムアプリ、音声通信などではUDPを使います。ShadowsocksではTCPとUDPの転送が関係する場合があり、サーバー側の有効化状況、ネットワークからの到達性、クライアント側の処理方法がそれぞれ異なることがあります。ウェブページが開けても、UDP経路が正常とは限りません。逆に、特定のアプリが使えなくても、必ずしもプロトコルの問題ではなく、DNS、ルール、接続先サービスの影響も考えられます。診断では、まずそのアプリが実際に使う通信の種類を確認し、該当するリクエストがプロキシに送られているかを調べます。

UDPにはTCPのような接続状態の仕組みがなく、ネットワーク機器がアイドル状態のマッピングを早めに削除することがあります。バックグラウンドから戻った後の最初のリクエストだけが失敗し、再試行で回復する場合は、マッピングの期限切れや経路変更が関係している可能性があります。すぐにKeepaliveの頻度を上げるのは避けてください。モバイル回線が長くアクティブになり、バッテリー消費が増える場合があります。まず、長時間のアイドル後だけ起きるのか、特定のネットワークだけで起きるのかを確認してから調整の必要性を判断します。通信中は安定し、復帰後に失敗する場合と、最初から認証できない場合では、調査する箇所が異なります。

モバイルデバイスでの性能の見方

Shadowsocksは基本的なカプセル化が比較的シンプルなため、プロトコル層による追加負荷を抑えられる場合があります。ただし、実際の速度は暗号化の実装、デバイスの性能、サーバーの出口回線、往復遅延に左右されます。暗号化アルゴリズムの性能はプロセッサによって異なります。名称に大きな数字が含まれているからといって、より安全または高速とは判断できません。速度を求めてサーバー側が提供していない方式に変更するのも避けてください。バッテリーを比べる際は、一瞬表示される通信速度だけでなく、同じタスクの完了時間、再接続の回数、バックグラウンドでの状態を確認しましょう。

対応するサーバーをすでに利用していて、明確なアドレスと認証情報でプロキシ接続したい場合に適しています。プライベートネットワーク間の接続、両端の鍵による認証、ネットワーク層のルーティングが必要なら、Shadowsocksに無理に要件を当てはめず、WireGuardの説明を確認してください。両者が解決する課題は異なるため、まずアクセス方式で選び、その後で性能を比較しましょう。サブスク内の項目が安定して使えているなら、タイプを統一するために編集するより、元の設定を保つのが適切です。

3. VMessとVLESS：認証プロトコルと外側の通信方式を分けて考える

VMessとVLESSは、ユーザー認証と外側の通信方式を含む設定で併記されることがありますが、互換性はありません。VMessはユーザー認証、リクエスト形式、暗号化方式を組み合わせています。一方、VLESSは認証とリクエストの表現をよりシンプルにし、通常は選択した外側のセキュリティ機構で通信を保護します。VLESSはVMessの名称を変えただけのものではなく、どのネットワークでも速いわけではありません。まずサーバー側がどちらを提供しているかを確認し、設定の組み合わせ全体を照合してください。UUIDだけをコピーしても設定がそろったことにはなりません。

UUIDは識別情報であり、サーバーアドレスではない

UUIDはユーザーの識別に使われ、サーバーアドレスは接続先の入口を示します。両者は異なる役割です。手動入力する場合はUUIDの全ての文字とハイフンを残し、コピー時に空白や改行が混ざらないよう注意してください。サーバー側で該当ユーザーが削除・変更された場合や、サブスクに古い値が残っている場合は、ポートに到達できても認証に失敗することがあります。古い設定には過去の互換性に関する項目が含まれる場合もあります。元の設定に基づいて維持し、無関係なガイドを見て一律に設定しないでください。過去の項目を、すべての構成で必須のものと考えるのも避けましょう。

VMessの認証処理では時刻に関する検証が行われるため、デバイスの日付や時刻が大きくずれていると、接続に繰り返し失敗することがあります。まずシステムの自動時刻が正しいかを確認してから、ほかの項目を調べましょう。ポートを何度も変更するより有効な場合があります。VLESSは認証と外側のセキュリティの仕組みが異なるため、VMessのトラブル対処をそのまま適用できません。共通する確認の考え方は、「入口に接続できない」「外側のセッションが失敗する」「認証が受け入れられない」を区別することです。接続スイッチの状態だけで判断せず、ログや接続記録から失敗した段階を確認してください。

WebSocket、パス、サーバー名

外側の通信にWebSocketを使う場合、クライアントとサーバーで通信方式とリクエストパスを一致させる必要があります。パスの大文字・小文字、先頭のスラッシュ、追加パラメーターが照合に使われることがあります。説明文のように見える値が、実際には設定値である場合もあります。HTTP Hostはリクエストでホストを識別するために使われ、TLSのサーバー名はセキュアなセッションでの名前の確認に使われます。両者は同じ場合もあれば、構成によって異なる場合もあります。サーバーアドレスがさらに別の値となることもあるため、3つの欄すべてに接続先のアドレスを入力しないでください。

TLSを使う場合は、証明書が想定するサーバー名と一致するかを確認してください。接続先がIPアドレスでも、証明書がドメイン名に対して発行されているなら、サーバー側の情報に沿って該当する名前を入力します。証明書の検証を無効にしても、項目の不一致は解消しません。接続口の前に中継層があると、リクエストはいったんその層に届いてから実際のサービスに振り分けられることがあります。この場合、パスやHostが一致しないと、応答する入口には到達しても、正しいサービスにはつながりません。パスワードの誤りも同じように失敗して見えることがありますが、確認する順序は異なります。

カプセル化によるコストと制約

通信層が増えると、通常はハンドシェイクやヘッダー、状態管理の負荷が増えます。ただし、影響の大きさは接続の再利用、ネットワーク遅延、リクエストのサイズによって異なります。短い接続を頻繁に行う通信ではセッション確立のコストが目立ちやすく、長時間の大容量通信ではサーバーの処理能力が主な制約になることがあります。VMessとVLESSを比較する際、一方だけ外側の通信方式や接続先が異なると、測定結果の差をすべてプロトコルの違いに帰属できません。サーバーの場所、ネットワーク、タスク、測定時刻をそろえ、プロトコル名だけでなく通信方式の組み合わせも記録してください。

iOSでは、少量のプロトコルヘッダーより、頻繁な再接続や再試行、ネットワーク切り替えのほうがバッテリーに影響する場合があります。項目上は接続済みでもリクエストを完了できない場合は、認証、時刻、パス、TLSを先に確認し、再試行が続いていないかを見てください。特殊なフロー制御や拡張項目は、現在のクライアントでサポートされ、資料にも明記されている場合だけ使用してください。サブスクから読み込んだ項目に必須の設定がない場合は、似た名前の項目を手動で追加するより、サブスクを更新するか元の情報を確認するほうが確実です。

4. Trojan、HTTP、SOCKS5：接続口の機能とセキュリティ上の境界

Trojan、HTTP、SOCKS5はいずれもプロキシ接続に使えますが、認証方法、通信の保護、宛先の指定方法は異なります。Trojanは通常、TLSで保護された接続内でプロキシリクエストを行い、パスワードで認証します。HTTPプロキシは一般的なリクエストやトンネルの仕組みに従い、SOCKS5は汎用的なプロキシ接続のネゴシエーションを提供します。後者2つは、基本プロトコルだけでクライアントから接続口までの通信が暗号化されるわけではありません。サーバー側が実際に提供する接続口の種類を確認してください。最終的なアクセス先が安全なウェブサイトだからといって、プロキシ接続口の保護方法を無視してはいけません。

Trojan：まずTLS、次にパスワードを確認

Trojanの一般的な設定には、サーバー、ポート、パスワード、TLS関連の項目があります。認証リクエストより先にTLSセッションが確立されるため、証明書に問題があるとパスワードの検証まで進みません。アドレスに到達できてもハンドシェイクに失敗する場合は、システム時刻、証明書の有効性、サーバー名、サーバー側のセキュリティ設定を確認します。証明書とサーバー名に問題がなく認証に失敗する場合は、パスワードが完全か、更新されていないか、見えない文字が混ざっていないかを確認してください。すべての失敗をパスワードの誤りと決めつけず、証明書エラーをルーティングモードの変更で解決しようとしないでください。

同じ接続口で複数のサービスを組み合わせる構成では、名前とリクエストの処理方法が特に重要です。ポートから応答があっても、その応答元が想定するプロキシ接続口とは限りません。クライアントでTrojanを選んだ後、インポートした情報に追加の通信設定が含まれているか、現在のクライアントがその組み合わせに対応しているかを確認してください。情報がない場合は、パスワードに引用符やエンコード、接頭辞を付けないでください。通常、入力欄にはプロトコル識別子を含む共有テキスト全体ではなく、元の値を入力します。

HTTP：トンネルと接続口の暗号化は別のもの

HTTPプロキシは通常のリクエストを転送できるほか、CONNECTで宛先とのバイト通信路を確立できます。宛先がTLSを使う場合、通信路の内側にある宛先のコンテンツは暗号化されたままの場合があります。ただし、クライアントからプロキシに送るネゴシエーション情報や認証情報が保護されるかは、プロキシ自体への接続にTLSを使っているかによります。「安全なウェブサイトにアクセスすること」と「プロキシ接続口まで安全に接続すること」を混同すると、認証情報がどこまで保護されるかを誤って判断します。TLS付きのプロキシ接続口であると資料に明記されている場合は、実際のタイプとセキュリティ項目に合わせて設定してください。ポートだけを変えても解決しません。

HTTPプロキシは明確なアクセス方針がある環境で利用されることがありますが、あらゆるUDP通信を扱えるとは限りません。ウェブページは表示できてもリアルタイムアプリが失敗する場合、クライアントのルールではなく、接続口が該当する通信に対応していない可能性があります。ユーザー名とパスワードには、アクセス範囲、同時接続数、有効期限などの制限がある場合もあります。認証を拒否された場合はアカウントの状態と元の情報を確認してください。一部の宛先だけ拒否される場合は、接続口の方針と宛先サービスの応答を切り分けます。どちらの場合も、原因の調査の代わりにサブスクを何度も更新しないでください。

SOCKS5：汎用的なネゴシエーションは暗号化を意味しない

SOCKS5では宛先のアドレスとポートを指定でき、認証のネゴシエーションやUDP転送の仕組みも定義されています。ただし、サーバー側で認証やUDPが有効かどうかは別途確認が必要です。基本的なユーザー名とパスワードによる認証自体に、通信内容を暗号化する機能はありません。利用環境には要件に合った保護が必要です。宛先をドメイン名とIPアドレスのどちらでプロキシに渡すかによって、DNSの問い合わせ先も変わることがあります。タイプがSOCKS5だからといって、すべてのドメイン検索がリモート側で行われるとは限りません。クライアントの名前解決方針、ルールの要件、実際の接続記録も確認してください。

この3種類の接続口を選ぶ際は、漠然と速度を比べるのではなく、利用中のサービスが実際に備える機能を確認しましょう。Trojanではセキュアなセッションの確立に時間がかかる場合があり、HTTPトンネルは接続口の方針に左右され、SOCKS5のUDPはネットワーク機器の制約を受けることがあります。モバイルデバイスでは、短いリクエスト、継続的な通信、アイドル後の復帰をそれぞれ確認してください。アクセス範囲やセキュリティ要件が不明な場合は、利用中のサービス提供元に項目の意味を確認しましょう。検証を無効にしたり、パスワード欄を空にしたり、似たタイプに切り替えたりして試すのは避けてください。

タイプ	主な確認項目	混同しやすい点
Trojan	パスワード、TLS、サーバー名	ハンドシェイクの成功は認証の成功を意味しない
HTTP	接続口の保護、認証、CONNECT対応	宛先の暗号化は接続口の暗号化を意味しない
SOCKS5	認証、UDP、ドメイン名の処理	基本プロトコルだけで通信路が暗号化されるわけではない

5. WireGuard：鍵、トンネルアドレス、ネットワーク層ルーティング

WireGuardはネットワーク層のトンネルとピアの識別を中心とし、シンプルなプロトコルと明確な暗号化の組み合わせを目指して設計されています。アクセス先ごとにリクエストを送るプロキシ方式とは異なり、トンネルに入るのはネットワークパケットです。そのため、接続設定にはローカルのトンネル識別情報、接続先の情報、許可するアドレス範囲も必要になります。サーバーのドメイン名とパスワードだけでは設定できません。また、他のプロトコルのパスワードを鍵の欄に入力することもできません。利用前に、現在のデバイス向けの完全な情報を入手し、サーバー側に対応する公開鍵が登録されていることを確認してください。

Private KeyとPublic Keyの役割

Private Keyはローカルの識別情報であり、秘密に保つ必要があります。Public Keyは、対向側が対応する識別情報を確認するために使います。クライアントに入力する対向側の公開鍵は、サーバー側の情報から取得してください。自分の端末の公開鍵ではありません。サーバー側にもクライアントの公開鍵が必要です。双方の設定が一致しない場合、UDPパケットが届いても、想定したセキュアな通信は確立できません。事前共有鍵が含まれている場合は、両側で共有する追加の秘密情報です。どちらかの鍵ペアの代わりにはなりません。項目をそろえるために、同じ文字列を複数の欄に貼り付けないでください。

デバイスを変更する際は、「設定を復元すること」と「複数のデバイスで同じ識別情報を同時に使うこと」を区別してください。複数のデバイスで同じ識別情報とアドレスを使うと、サーバーから見える接続元が頻繁に変わり、接続が不安定になったり、通信が別のデバイスに届いたりすることがあります。複数台での共用が許可されるかはサーバーの構成によります。設定ファイルをインポートできるからといって、同時利用できるとは限りません。トラブル時は、その識別情報を何台で使っているかを記録し、利用中のサービスの説明に従ってデバイスごとの情報を用意してください。クライアントでサーバーを何度も切り替えるより、問題の特定に役立ちます。

Endpoint、Address、Allowed IPs

Endpointは現在のネットワークから接続する相手のアドレスとポートを示し、Addressはトンネル内部のローカルアドレスを示します。両者は置き換えられません。WireGuardのプロトコルでは、Allowed IPsはピアに関連付けるアドレスの選択や受信時の検証に関わります。クライアントへの組み込みでは、アプリのルーティング機構との関係も考慮する必要があります。特定のネットワーク範囲が正しく含まれていないと、トンネルのハンドシェイクが成功しても宛先に到達できません。逆に範囲が広すぎると、本来ローカルでアクセスすべき通信まで適切でない経路に送られる場合があります。

プライベートネットワークにアクセスする場合は、戻りの経路も考慮してください。クライアントが送ったデータが相手側に届いても、その先のデバイスがクライアントのトンネルアドレスへの応答方法を知っているとは限りません。サーバー側の転送、戻りルート、アクセス方針も結果に関係します。相手側のデバイスにはアクセスできても、その先のネットワークに届かない場合は、クライアントの鍵を再生成するのではなく、サーバー側のネットワーク構成を確認してください。DNSは別の問題です。プライベートドメイン名に専用の名前解決先が必要な場合がありますが、DNSサーバーを指定しても、該当アドレスへのルートが確保されるわけではありません。

UDP、MTU、Keepaliveの実際の影響

WireGuardはUDPを使用するため、現在のネットワークが該当するUDP通信を許可していることが基本条件です。経路の実効MTUが不足すると、小さなリクエストは通っても、大きな応答や一部の通信が停止することがあります。カプセル化によってパケットのデータ量が増えるためです。この場合は、まず導入時の推奨設定と経路の状態を確認し、根拠に基づいて調整してください。特定の固定値をすべてのネットワークに適用できる答えと考えるのは避けましょう。調整するたびに同じ大容量ファイルや固定リクエストで確認し、変更が実際に改善につながったか判断できるよう元の値も記録してください。

Persistent Keepaliveは必要に応じてネットワークのマッピングを維持するためのもので、頻度を上げるほど安定するわけではありません。モバイル回線では、定期的な通信が無線のアクティブ時間を増やすことがあります。マッピングを維持する必要がなければ、過剰な設定はバックグラウンド処理を増やすだけかもしれません。WireGuardのシンプルな設計はプロトコルの負荷を抑えるのに役立ちますが、バッテリー消費は通信量、電波状況、再接続にも左右されます。必要な条件がそろったピア情報を持ち、ネットワーク層のアドレス関係を明確にしたい場合に適しており、プロトコル名だけを理由に省電力を期待するものではありません。

6. Hysteria2：QUIC、輻輳制御、帯域幅の考え方

Hysteria2はQUICベースのプロキシ通信を想定し、パケットロスや往復遅延が大きい経路でも効率的な通信を維持することに重点を置いています。QUICはUDP上で動作し、その上でセキュアなセッションや信頼性のある転送などを実現します。UDPをそのまま転送するだけの仕組みではなく、輻輳制御が不要という意味でもありません。利用には、互換性のあるサーバー情報を持っていること、現在のネットワークが該当するUDP通信を扱えることが必要です。名前が似ている別世代のプロトコルに互換性があるとは限りません。インポート時は正確なタイプを保ってください。

まずUDPとTLSの前提を確認

接続先、ポート、認証情報、TLSのサーバー名が一致している必要があります。TCPでウェブページを表示できるネットワークでも、同じ接続先のUDPが使えるとは限りません。ネットワークによってはUDPが制限されたり、継続的な通信が異なる扱いを受けたりします。すべてのリクエストがセッション確立時にタイムアウトする場合は、帯域幅の設定を変える前にUDPの到達性とサーバーの待ち受け状態を確認してください。証明書のエラーが表示されたら、システム時刻、サーバー名、証明書の信頼チェーンを確認します。速度設定を上げても、セキュアなセッションの失敗は解消できません。

サーバー情報に追加の処理項目が含まれる場合は、現在のクライアントが対応し、正しくインポートされているか確認してください。認証情報は接続に必要な権限に関わるため、ウェブサイトのログインパスワードや別プロトコルのパスワードで代用できません。ポートが変わる構成では、サーバー側の説明とクライアントの機能を含めて確認します。特定のポートに一時的につながっても、設定全体が正しいとは限りません。情報が足りない場合は推測をやめ、正確な項目をそろえてから性能を試してください。そうしないと、失敗のたびに複数の不確定要素が残ります。

帯域幅の設定値は実際の速度を保証しない

構成によっては、上りと下りの帯域幅の目安を設定します。こうした値が通信や輻輳制御に使われる場合がありますが、クライアントに入力した数字によって回線容量が増えるわけではありません。実際に使える帯域幅より大幅に高い値を設定すると、キューの滞留やパケットロスが増え、同じネットワークを使う他の通信に影響することがあります。低すぎる値は、利用可能なスループットを制限する場合があります。入力の要否や値の意味、サーバー側の設定との関係は、現在の実装と利用中のサービスの説明を確認してください。固定値をそのまま使うことはできません。

通信の方向も区別してください。デバイスから送信するデータとデバイスが受信するデータは別の方向です。速度測定のページでダウンロード結果が目立つからといって、同じ値を両方の欄に入力しないでください。モバイル回線の実効容量は場所、電波状況、時間帯でも変わります。実験室で適切だった値が、移動中にも適切とは限りません。変更する際は控えめな基準値を残し、タスクの完了時間や他のアプリへの影響を確認してから段階的に調整します。通信速度が上がっても操作時の応答が大きく遅れるなら、全体的に改善したとは言えません。

パケットロスからの復旧効果とリソースの負荷

QUICは一つの接続内で複数のデータストリームを扱えます。そのため、従来の順序付きバイトストリームで発生する制約を、すべてのストリームが共有するとは限りません。ただし、各ストリームは同じ経路と輻輳制御のリソースを共有します。パケットが失われれば該当データの復旧は必要です。実際の効果はタスクの構成や経路の状態によって異なります。特定のネットワークでは他の通信方式より優れることもあれば、安定した低遅延のネットワークでは目立った差が出ないこともあります。一度の速度測定をあらゆる場面の順位に一般化すると、サーバー設定とネットワーク環境という主要な変数を見落とします。

iPhoneやiPadでは、ユーザー空間でのプロトコル処理、暗号化、高スループットの維持、パケットロス後の復旧にリソースを使います。タスクを早く完了できれば通信がアクティブな時間を短縮できることがありますが、回線に高い負荷をかけ続けると発熱やバッテリー消費が増える場合もあります。安定性、タスクの完了時間、バックグラウンドからの復帰、デバイスの状態をあわせて確認してください。長時間待たされたり再試行を繰り返したりする接続は、バッテリー比較の対象に適しません。まず到達性の問題を解決しましょう。プロトコルは実際のアクセス要件に合わせて選ぶもので、特定の設定値を最大にすることが目的ではありません。

7. 設定項目を確認：プロトコル接続とルール振り分けを分けて検証

プロトコルの設定項目はサーバーへの接続を担い、Global Routingはその接続を通信にどう使うかを決めます。両者を分けて確認しないと、ルールの問題をプロトコルの問題と誤認しやすくなります。まずHomeで選択中のサーバーを確認し、次にGlobal Routingを確認してください。Configは設定ルールに沿った処理、Proxyは接続先を一括してプロキシにする診断用の状態、Directは直接接続です。いずれもルーティングの選択を示すもので、サーバーの認証や通信機能を書き換えるものではありません。基本操作は使い方ガイド、3つの状態の説明はGlobal Routingの解説をご覧ください。

アドレス・名前・認証を順に確認

サーバーアドレスにはホスト名またはIPアドレスを指定できます。ホスト名を使う場合は、接続前にその名前が正しく解決される必要があります。入口の名前解決に失敗すると、プロトコル認証より前の段階で問題が起きます。TLSのサーバー名はセキュアなセッションでの名前確認に使われるもので、アクセス先ウェブサイトのドメイン名とは区別してください。ポートには該当サービスが待ち受ける値を入力します。一般的なポートに変更しても、サーバー側が別のプロトコルを提供するわけではありません。ユーザー名、パスワード、UUID、鍵はそれぞれ異なる認証方式の情報です。空欄、エンコードの違い、前後の空白で意味が変わることがあるため、元の情報に沿って確認してください。

共有リンク全体を一つの設定欄に入力しないでください。また、サブスクのURLをサーバーアドレスとして扱わないでください。サブスクは複数の項目を取得するための入口で、プロトコルや認証情報を含む場合があるのは個々の項目です。更新すると既存の項目が置き換えられたり、名前が変わったり、削除されたりすることがあります。手動で変更した設定が次回の更新で上書きされる場合もあります。調整内容を継続して検証する場合は、名前を分かりやすく付けた独立したコピーを作り、名前にパスワードを含めないようにしてください。インポート方法の違いはサブスク導入ガイドをご覧ください。

項目の種類	確認するポイント	よくある誤解
サーバーとポート	接続先の名前解決、待ち受け位置	リンク全体をアドレス欄に入力する
認証情報	種類、完全性、有効性	異なるプロトコルで同じ認証情報を使う
TLSの名前	証明書とサーバー構成に一致させる	最終アクセス先のウェブサイト名を入力する
通信方式の設定	タイプ、パス、Host	外側の通信方式を確認せず、プロトコル名だけを見る
ネットワーク層の設定	アドレス範囲、MTU、戻りの経路	ハンドシェイク成功だけでネットワークに到達できると判断する

ルールは通信先を決めるもので、サーバーを修復するものではない

以下は、マッチする順序を説明するためのShadowrocket .confルール例です。サーバー定義は含まず、既存の設定をそのまま置き換えられる完全なファイルでもありません。ドメインルールで指定したサフィックスを判定し、ローカルネットワークのルールで該当アドレスを処理します。FINALは、残りのリクエストに対するフォールバック方針です。既存の設定にコピーする前に、元のルール構成とデフォルトの方針を確認し、プライベートネットワークの設定を上書きしないよう注意してください。ここでは構文を示すため予約済みの例示用ドメインを使っており、接続サービスを示すものではありません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

ルールは通常、上から順にマッチします。条件が広すぎるルールを先に置くと、後続の詳細な条件が適用されないことがあります。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲を判定するため、それぞれ必要な情報が異なります。アドレスの判定に名前解決が関わる場合は、DNSの結果が後続の動作に影響します。ただし、DNSが成功しても、プロキシ経由で宛先にアクセスできるとは限りません。トラブル時は、まず明確なドメインルールで通信先を確認し、現在の記録にある実際の宛先アドレスを調べてください。互いに重複するテストルールを一度に追加するのは避けましょう。

比較テストでルールとプロトコルを切り分ける

同じサーバーがProxyでは決まったアクセスを完了でき、Configでは失敗する場合は、すぐにプロトコルを変更せず、ルールのマッチ、ポリシーの参照、DNSを先に確認してください。どちらの状態でも失敗するなら、サーバー設定と接続経路を調べます。Directは現在のネットワークの基本的な接続を確認するために使えますが、直接接続が成功してもプロキシサーバーに到達できるとは限りません。テスト後は必要な元の状態に戻してください。診断用の設定をそのままにすると、日常の通信先が変わり、その後の確認結果が普段の設定と一致しなくなることがあります。

IPv6を使う場合は、宛先の名前解決結果、ルール、サーバーの機能が一致しているかも確認してください。IPv4だけを扱うルールではIPv6のリクエストが対象にならない場合があります。同じドメインでもネットワークによって異なるアドレスが返され、表面上は不規則な差が出ることもあります。一部のリクエストが失敗したからといって、DNS設定をすべて変更しないでください。まず実際のアドレスファミリー、適用されたポリシー、失敗した時刻を記録し、一つずつ確認します。用語の解説は用語集をご覧ください。異なる層の用語を同じスイッチとして扱わないために役立ちます。

8. 用途別の選び方：再現可能な手順で結果を判断

プロトコル選びで最優先するのは利用中のサーバーとの一致で、その次にタスクとネットワーク環境を考えます。安定して使える設定がすでにあるなら、プロトコル名を追いかけて変更する必要はありません。ウェブ閲覧やメッセージの送受信では、最初の応答、バックグラウンドからの復帰、接続成功率が重要です。継続的な通信ではスループットと長時間の安定性を確認します。プライベートネットワークへのアクセスではアドレスの関係と戻りの経路を先に確認し、UDPを使う通信ではUDP経路全体を調べてください。サーバーが複数の互換性ある方式を実際に提供している場合に限り、同じ条件での比較に意味があります。

繰り返し確認できるテスト記録を作る

デバイス、ネットワーク、宛先、テスト内容を固定し、結果に影響する他の実験設定をオフにして、現在の設定のコピーを残します。プロトコルと外側の通信方式、Global Routingの状態、直前にネットワークを切り替えたか、どの段階で失敗したかを記録してください。ウェブページを試す場合は、同じ宛先と近い内容を使います。継続的な通信を試す場合は、ファイルと時間を固定し、キャッシュにも注意してください。新しい接続の確立時間と、セッションを再利用したリクエストを直接比べてはいけません。測定時刻によるサーバー負荷の違いを、すべてプロトコルの差として扱うのも避けましょう。

Connectivity Testは、選択した項目への到達性やテストリクエストの状態を確認するのに役立ちます。ただし、一度成功してもすべての通信が正常とは限らず、単一の測定値が全体のスループットを示すわけでもありません。実際の宛先へのアクセスと接続記録をあわせて確認し、接続口への到達、認証、リクエストの送信、応答の完了を区別してください。初回接続の具体的な操作は初回接続のチェックリストをご覧ください。接続スイッチをオンにしてもウェブページが開かない場合は、サブスクの更新、DNSの変更、プロトコルの切り替えを同時に行わないでください。どの操作が影響したのか分からなくなります。

失敗した段階から原因を絞る

接続口に到達する前：ローカルネットワーク、サーバー名の名前解決、アドレス、ポートを確認し、テスト対象の項目が選択されているか確認します。
セッション確立：プロトコルタイプ、TCPまたはUDPの利用条件、TLSのサーバー名、システム時刻、証明書の問題を確認します。
認証：パスワード、UUID、鍵、サーバー側の登録状態を確認し、サブスクに無効な情報が残っていないか調べます。
リクエスト：Global Routing、ルールのマッチ、宛先の名前解決、UDPの対応状況、アドレスファミリーを確認します。
継続的な通信：パケットロス、実効MTU、サーバー負荷、帯域幅の設定値、アイドル状態のマッピング変化を確認します。

段階ごとの判断は、特定のエラー表示を必ず見つけるという意味ではありません。得られた情報を適切な箇所に当てはめます。接続口から応答がない段階では、パスワードを確認しても役に立ちません。ハンドシェイクが完了して特定のネットワーク範囲だけ使えない場合は、ルーティングと戻りの経路を調べます。すべての宛先で読み込みが始まるものの、大きな応答で停止する場合は、経路やパケットサイズを確認してください。ログに大まかなタイムアウトしか表示されない場合は、同じネットワークとルーティング状態で、利用可能と確認済みの別項目をテストするなど、比較によって情報を補います。すぐにプロトコルが不適切だと結論づけないでください。

バッテリー比較ではバックグラウンド動作と回線切り替えも確認

バッテリー消費は、同じ種類のタスクと近い使用時間を基準に比較してください。画面の明るさ、電波状況、バックグラウンドアプリ、測定時間はできるだけそろえます。発熱、頻繁な再接続、アイドル後の復帰、Wi-Fiからモバイル回線に切り替えた後の動作を記録しましょう。短時間のバッテリー残量の変化は大まかな指標であり、特定のプロトコルが常にどれだけ省電力かを断定する根拠にはなりません。接続に失敗して再試行が続く場合は、先に原因を解決してください。タスクを早く完了した場合は、その後のアイドル時間も含めて観察すると、日常の使い方に近い比較ができます。

長時間のバックグラウンド接続では、KeepaliveとOn Demandを必要に応じて設定し、両方を無条件に有効にしないでください。Keepaliveはマッピングを維持する一方で、ネットワークの活動を増やすことがあります。On Demandは条件に応じて接続を開始する機能で、認証やルールの誤りを直すものではありません。回線を切り替えるたびに手動で復旧が必要な場合は、システムの起動条件、通信の再確立、サーバーの状態を分けて確認してください。一度の切り替えテストで分かるのは手がかりまでです。同じ条件で繰り返して確認し、復旧前後の接続記録を残しましょう。

結論を出す前に、適用条件を明記する

適切な結論は、「このデバイス、このネットワーク、このタスク、このサーバー設定では、どの組み合わせがより安定したか」を示すもので、特定のプロトコルが常に最速だと断定するものではありません。日常利用では、設定が分かりやすく、確実に復旧でき、管理しやすい項目を優先します。特殊なネットワーク機能が必要なら、その要件に合うタイプを選んでください。利用可能と確認できた基準設定を残し、利用中のサブスクは元の入口から定期的に更新しましょう。用途の分からないコピーを複数管理するのは避けてください。詳しくはよくある質問、または接続後にインターネットへアクセスできない場合の確認手順をご覧ください。