Shadowrocketのプロトコル解説

01 / CONNECTION MODEL

プロトコルの階層と設定項目を確認する順序

プロトコルの種類は接続経路の一部にすぎません

端末から接続先のサービスへリクエストを送る際は、通常、ローカルルーティングの判定、サーバーアドレスの名前解決、下位層の接続、プロトコル認証、接続先への転送を経由します。Shadowsocks、VMess、VLESSなどの名称は、主にクライアントとサーバーがプロキシリクエストをどうやり取りするかを示すものです。サーバーまでの距離、帯域幅、混雑状況を直接表すものではありません。同じプロトコルでも実際の使用感は大きく異なります。反対に、異なるプロトコルでも、同じネットワークと同程度のサーバー条件なら近い使用感になることがあります。

設定項目は、サーバーアドレス、認証、通信方式、セキュリティ、ルーティングに分けて考えましょう。サーバーアドレスは接続先を指定します。パスワード、UUID、鍵は接続元の身元を証明します。TCP、UDPとその上位のカプセル化方式はデータの運び方を決めます。TLSは該当する接続の暗号化と証明書の検証を担います。ルールはどのリクエストをこの接続に通すかを決めます。ある階層で問題がなくても、後続の階層が正常とは限りません。そのため、遅延を測定できても、実際のアクセス確認の代わりにはなりません。

情報提供元の設定に従い、値を推測で補わない

Add Serverで種類を選ぶ前に、手元の情報に記載されたプロトコルを確認してください。ポートが同じでもプロトコルが同じとは限らず、TLSを使うからといって必ずTrojanとは限りません。サブスクリプションをインポートした後は、種類、サーバー、ポートが妥当かを確認し、認証項目と通信設定も照合します。項目名や並び順は種類によって異なる場合があります。アプリに表示される内容を確認してください。受け取っていない設定値を、よくある例というだけで追加するのは避けましょう。

サーバーのドメイン名、TLSのSNI、WebSocketのHostは、同じ場合も異なる場合もあります。ドメイン名は接続先アドレスを特定するために使われます。SNIはTLSハンドシェイク時に接続先のサービスを選ぶために使われ、通常は証明書の名前の確認にも関係します。Hostはアプリケーション層でリクエストを振り分けます。いずれか一つを変更しても、他の項目が変わるとは限りません。3つを自由に置き換えられるサーバーアドレスとして扱わないでください。

UDP対応とアプリでの実際の利用可否を分けて考える

「UDP対応」には、少なくともクライアントのプロトコル実装、サーバーの転送許可、中間ネットワーク、接続先サービスの4つの条件が関わります。ストリーム接続内にUDPデータをカプセル化するプロトコルもあれば、データグラムを直接使うもの、追加の拡張機能に依存するものもあります。音声通話、リアルタイム通信、HTTP/3が使えるかどうかは、プロトコル名だけでは判断できません。通常のWebページが表示できても、実際に使うアプリごとに確認し、Webページへのアクセス成功をすべての通信が利用可能な証拠とみなさないようにしましょう。

以降の章でいう「選び方」とは、すでにお持ちで、サーバー側が明確に対応している設定の中から選ぶことです。アプリのメニューで別の種類に切り替えても、サーバーのプロトコルは変わりません。インポート結果が元の情報と異なる場合は、共有リンクが完全か、解析後も項目が保持されているかを確認してから、再インポートするか情報の提供元に問い合わせてください。種類を間違えたまま設定を何度も変更するのは避けましょう。

02 / SHADOWSOCKS

Shadowsocks：暗号化方式と転送の範囲

少ないプロトコル階層でプロキシ転送を行う

Shadowsocksは、クライアントとサーバーの間に暗号化されたプロキシ転送経路を確立し、接続先のアドレスとアプリのデータをサーバー側で処理する仕組みです。完全な仮想LANプロトコルではなく、システム内の各リクエストのルーティングを自動で決めるものでもありません。Shadowrocketは端末上で処理対象の通信を受け取り、Global Routingと現在の設定に基づいて、選択中のShadowsocks接続に渡すかを判断します。プロトコルとローカルでの通信振り分けは、別々の役割を担います。

カプセル化の階層が少ないと、ハンドシェイクや処理にかかる一部のコストを抑えられる場合がありますが、それだけで速度が上がるとは限りません。実際のスループットは、暗号化の実装、端末の負荷、サーバーの性能、回線品質にも左右されます。サーバーが混雑している場合、暗号化方式を変えても通常は解決しません。追加の通信方式を使う場合は、その分のコストも含めて考え、種類名だけから実際の経路を判断しないでください。

MethodとPasswordをセットで確認する

基本となる情報は、サーバー、ポート、暗号化方式、パスワードです。Methodは自由に選べる速度設定ではなく、通信する両端で共通して使うアルゴリズムとメッセージ形式を指定します。AEAD方式は通信内容を秘匿するだけでなく、データの完全性も検証します。方式によって鍵の長さや導出方法が異なる場合があります。Passwordが正しくてもMethodが間違っていれば、認証や復号に失敗します。接続が確立したように見えても、正しい応答が返らないことがあり、必ずしも「パスワードが違います」と表示されるとは限りません。

固定長のエンコード済み鍵を使うプロトコルの種類では、一般的な短いパスワードをそのまま鍵として入力できません。元の情報に複数の認証項目や特殊な形式が含まれる場合は、区切り文字を削除せず、そのまま保持してください。コピー時は末尾の空白や改行、入力方法による句読点の置き換えにも注意します。手入力し直せば正確になるとは限りません。信頼できる元情報からコピーし、インポート後の内容を項目ごとに照合しましょう。

TCPが正常でもUDPの確認にはなりません

Shadowsocksはさまざまなアプリの通信を運べますが、UDPを利用できるかは両端の対応状況とネットワーク条件によります。Webページが表示できても、確認できたのは経路の一部だけという場合があります。音声通話がつながらない、特定のネットワークでリアルタイムアプリに問題がある場合は、まずサーバーでUDP転送が許可されているか、クライアント側の関連設定が受け取った情報と一致しているか、現在のWi-Fiやモバイルネットワークで該当する通信が可能かを確認します。パスワードや暗号化方式を先に変更するのは避けてください。

UDPのデータグラムには、通常、TCPと同じ信頼性の高い転送機能がありません。パケットが失われた場合に再送するかは、上位のアプリが決めます。そのため、テストで遅延が小さくても通話が途切れることはあり、矛盾ではありません。遅延の測定値に反映されるのは応答が届いたリクエストであり、すべてのデータグラムが適時に到着したことまでは示しません。確認時は最小遅延だけでなく、損失、ジッター、セッションの継続性も見ましょう。

iPhone・iPadでの評価方法

すでにお持ちの設定がすべて使える場合、Shadowsocksは比較的シンプルな構成の基準として使えます。短いWebリクエストでは初回応答と再アクセス、大きなファイルでは安定したスループット、リアルタイムアプリでは長時間のジッターを確認します。地域も出口も異なる設定を比較して、その差をすべてプロトコルに結びつけないでください。サーバーの場所や負荷は、カプセル化の階層数より大きく影響することがあります。

端末のバッテリー消費を抑えたい場合は、まず不要な継続通信や、失敗を繰り返す再接続を減らし、その後で暗号化処理の影響を確認します。長時間接続を維持しながら通信がほとんどない状態と、ダウンロードで高いスループットを維持する状態では、電力消費の要因が異なります。前者ではバックグラウンドでの起動やネットワークのKeepalive、後者では無線通信、暗号化処理、端末温度の変化が関係します。バッテリー画面の一つの割合だけでは、プロトコルの問題を特定できません。

03 / VMESS & VLESS

VMessとVLESS：認証・通信方式・TLS

名前が似ていても、互換性のある種類ではありません

VMessは、プロキシリクエストの認証とデータ処理をプロトコル自体に組み込んでいます。一方VLESSは、リクエストと識別情報の仕組みをよりシンプルにし、接続のセキュリティを組み合わせる通信レイヤーに委ねます。どちらも複数の通信方式と組み合わせられるため、情報にTCP、WebSocket、TLSなどの記載がある場合は、具体的な組み合わせまで確認してください。VMessの項目をVLESSに変更しても、認証方式、メッセージ形式、サーバー設定は自動で変換されません。

VLESS自体には、TLSと同等のデータ暗号化保護はありません。VLESSの設定でUUIDだけを確認して、安全性が確保されていると判断しないでください。元の情報で指定されたセキュリティ方式とその設定が実際に有効か確認します。説明が不足している場合は、証明書検証を推測で無効にせず、必要な構成情報を確認してください。拡張機能への対応状況は、使用中のクライアントとサーバーの実際の機能に基づいて判断します。

UUID・時刻・認証情報

UUIDはこの種の設定でよく使われる識別情報であり、機密情報として扱ってください。サーバーのドメイン名ではなく、表示用の名前とも区別します。VMessの認証には時刻条件が関係するため、端末の時刻が大きくずれていると認証に影響する場合があります。同じ情報が別の端末では使える場合、アプリを再インストールするだけでなく、時刻の自動設定が正常かも確認してください。VLESSの認証方式は異なるため、VMessのトラブルシューティングをそのまま当てはめないでください。

インポートした情報に追加の認証項目やフロー制御の設定が含まれる場合、UUIDだけでは接続できないことがあります。古い設定の項目は、現在の組み合わせでは不要な場合があります。フォームを埋めるためだけに任意の値を入力しないでください。サーバーから提供された接続情報を参照し、その項目が現在のプロトコルで使われるか確認します。別の通信方式やセキュリティ構成に属する項目であれば、流用をやめてください。

WebSocketで追加される確認項目

WebSocketは、対応するアプリケーション層のセッションに接続を載せる方式で、既存のHTTPサービスを使った転送構成でよく利用されます。Path、Host、中継の動作など、追加の確認項目が生じます。Pathは正確な一致が必要な場合が多く、大文字・小文字の違い、末尾のスラッシュ、必要なプレフィックスの欠落によって、サーバーがリクエストを正しい処理に渡せないことがあります。HTTPレスポンスを受け取れても、プロキシ認証に成功したとは限りません。通常のWebサイトに到達しただけの場合もあります。

外側にTLSを使う場合、最初にセキュリティハンドシェイクが行われ、その後にWebSocketの確立とプロキシプロトコルのやり取りが続きます。証明書のエラー、Pathの誤り、UUIDの誤りは発生する段階が異なるため、状況を観察して階層ごとに判断してください。中継側に長時間接続のアイドルタイムアウトがあると、しばらく通信がない後に接続が切れることがあります。接続直後から認証できない場合とは異なり、パスワードを長くしても解決しません。

速度の違いとトラブルシューティングの順序

通信方式が一層増えると、ハンドシェイク回数、メッセージのオーバーヘッド、中継機器の処理が増える場合があります。一方で、サーバー構成上その方式が必要なこともあるため、クライアント側だけで無効にしてはいけません。性能を比較するときは、正しく構成された一式の設定を使ってください。短い接続を繰り返す用途では接続確立のコストが表れやすく、長時間の接続では帯域幅、パケットロス、接続の再利用方法が影響しやすくなります。1回の遅延測定だけで両方を評価することはできません。

アドレスの名前解決、ポート、TLS、通信経路、認証、実際の接続先へのアクセスの順に確認してください。すべての接続先で失敗するなら、まず共通する接続レイヤーを確認します。一つのドメインだけで失敗する場合は、ルール、名前解決、接続先の状態を調べます。サブスクリプションの更新後に設定が急に使えなくなった場合は、その項目の通信設定が変更されたか、手動での変更が更新で上書きされたかも確認してください。更新前の記憶だけと照らし合わせないようにしましょう。

04 / TROJAN · HTTP · SOCKS5

Trojan、HTTP、SOCKS5：セキュリティ境界とプロキシの仕組み

Trojanでは正しいTLS接続が必要です

TrojanはTLS接続の内側にプロキシプロトコルを配置し、所定の認証情報を使ってサーバーにプロキシリクエストを識別させます。外側のTLSと内側の認証を分けて考えることが重要です。サーバーアドレスへのTCP接続に成功しても、確認できたのはポートに到達できることだけです。TLSハンドシェイクの後も、認証と接続先への転送が必要です。Password、SNI、ポート、サーバーの構成がすべて正しくなければ接続できません。パスワードだけで接続が成立するわけではありません。

証明書の検証は、接続先の身元を確認するために行います。名前が一致しない場合は、情報に記載されたSNI、サーバーのドメイン名、証明書の対象範囲を確認してください。証明書の有効期間に問題があるという表示が出た場合は、端末の時刻とサーバー証明書を確認します。検証を常にスキップすると、身元確認の保護が失われ、実際の設定不備も見えにくくなります。エラー表示を消すだけでなく、名前、証明書チェーン、時刻を修正してください。

HTTPプロキシは、接続先のWebサイトがHTTPであるという意味ではありません

HTTPプロキシとは、クライアントとプロキシサーバーが通信する方法を指します。通常のHTTP接続先には、プロキシが該当するリクエストを処理できます。HTTPS接続先には、通常CONNECTメソッドで接続先までのトンネルを確立し、その中を接続先とのTLSセッションが通ります。したがって「HTTPプロキシ」だからといって、ブラウザーで通常のHTTPサイトしか開けないわけではありません。また、クライアントからプロキシサーバーまでの通信が必ずTLSで保護されることを意味するものでもありません。

情報にHTTPSプロキシと明記されている場合は、クライアントとプロキシの間にもTLS接続があり、証明書と名前の確認が必要です。ユーザー名とパスワードは通常、プロキシ認証に使われますが、それ自体は完全な暗号化方式ではありません。セキュリティの範囲を判断するには、「端末からプロキシまでの通信は暗号化されているか」「アプリから接続先までの通信は暗号化されているか」をそれぞれ確認してください。Webページに安全な接続と表示されても、各階層が同じように保護されているとは限りません。

SOCKS5は汎用的な接続先への転送方式です

SOCKS5では、プロキシサーバーとのネゴシエーションで接続先のアドレス、ポート、実行する操作を伝えます。ドメイン名とIPアドレスのどちらも指定できます。標準のSOCKS5には、TLSと同等の通信暗号化はありません。ユーザー名とパスワードによる認証も、安全な通信経路の代わりにはなりません。このインターフェースがサーバー側で明確に提供されている場合に使用し、選ぶ前に接続経路のネットワーク環境と追加の保護条件を確認してください。設定項目が少ないという理由だけで、モバイル端末に適していると判断しないようにしましょう。

SOCKS5でUDPを転送するには追加のネゴシエーションとデータグラム経路が必要です。実際に使えるかは、サーバーの実装、クライアント設定、ネットワークの到達性によります。TCPリクエストが正常でも、UDPの関連付けが確立した証拠にはなりません。また、接続先のドメイン名をどこで名前解決するかも結果に影響します。ローカルで先にIPアドレスへ変換すると、プロキシサーバーには元のドメイン名が届かない場合があります。名前解決の違いとドメインルールの照合は、実際の通信経路に沿って確認してください。

既存の環境に応じた選び方

組織や自分のサーバーが特定のプロキシインターフェースを提供している場合は、より馴染みのある名前の種類に置き換えず、提供されたプロトコルに合わせて設定してください。サーバーの待ち受けポートが同じでも、ハンドシェイクの形式が異なることがあります。証明書とドメイン名が明確に設定されているTrojanでは、まずTLSを漏れなく確認します。HTTPやSOCKS5では、インターフェースの信頼範囲、認証要件、接続先として許可されている範囲を確認してください。

CONNECTが拒否される、特定のポートだけ失敗する、認証が何度も通らない場合は、サーバー側のアクセス制限も考慮してください。接続先への権限による制限は、無線電波の弱さとは異なり、すべてのプロトコルに共通する問題でもありません。エラーが発生した接続先の種類と段階を記録すると、認証の失敗、接続先への到達不能、サーバーのポリシーによる拒否を区別しやすくなります。根拠がないまま、すべての項目を同時に変更しないでください。

05 / WIREGUARD

WireGuard：鍵・トンネルアドレス・IPルーティング

接続先へのプロキシからIPトンネルへ

WireGuardの仕組みは、前述した接続先へのプロキシとは異なります。暗号化トンネルでIPパケットを運び、鍵と対向情報を使って通信を確立します。プロトコルはシンプルさを重視し、選択可能な暗号アルゴリズムを多数提示して個別にネゴシエーションする仕組みではありません。Shadowrocketでは、確認の重点が「プロキシのアカウントと接続先アドレスの形式」から、鍵、Endpoint、トンネルアドレス、到達可能なネットワークへ移ります。

このプロトコルは下位の通信方式としてUDPを使うため、外側のUDP経路が利用できる必要があります。トンネル内ではさまざまなアプリのIP通信を運べますが、外部ネットワークですべてのUDP通信が許可されるわけではありません。同じ設定がWi-Fiでは使えてモバイルネットワークでは失敗する場合は、トンネル内の接続先ルールを先に変更せず、外側の通信経路と名前解決を確認してください。トンネル内のアプリでTCPが使えることと、外側でUDPに到達できることは別の問題です。

Private KeyとPublic Keyの役割を取り違えない

Private Keyは自分側の識別情報であり、秘密にしておく必要があります。Public Keyは対向側が自分を識別するために使います。クライアント設定に入力する対向の公開鍵はサーバーの識別情報に対応するものであり、自分側の公開鍵をそのままコピーしてはいけません。情報にPreshared Keyが含まれる場合は、両端で一致させる必要があります。鍵は通常、決められた形式でエンコードされています。文字の欠落や空白の混入、秘密鍵を公開スクリーンショットに載せることは、それぞれ接続やセキュリティの問題につながります。

Endpointは通信開始時に使う外部のアドレスとポートであり、トンネル内部のアドレスではありません。Addressなどの項目は、トンネル内での自分側のアドレスを指定し、ネットワーク設計と一致させる必要があります。Endpointの公開アドレスをトンネルアドレスに入力したり、両端に競合する内部アドレスを設定したりすると、ハンドシェイク後に通信を正しく転送できないことがあります。どちらもIPアドレスのように見えるからといって、形式だけで判断せず、項目ごとの役割を確認してください。

Allowed IPsとローカルの通信振り分けは別の設定です

WireGuardの仕組みでは、Allowed IPsは対向のアドレス範囲と送信先の選択の両方に関係します。これはリモートサイトの一覧ではなく、ShadowrocketのRuleをそのまま置き換えるものでもありません。まずクライアントのローカルルールでリクエストを該当する接続に通すか決まり、WireGuardに入った後はトンネルのアドレス範囲とサーバー側の転送設定によって接続先への到達可否が決まります。どちらか一方に広い範囲を指定しても、もう一方で同じ範囲が自動的に許可されるわけではありません。

すでにお持ちのリモート内部ネットワークに接続する場合は、接続先のネットワーク範囲、戻りのルート、サーバー側の転送許可を確認してください。ローカルWi-Fiとリモートネットワークで同じプライベートアドレス範囲を使っていると、アドレスが重複することもあります。同じ接続先がローカル端末にもリモート端末にも見えてしまう状態です。その場合はネットワーク設計とルールを確認してください。DNSを変更するだけで、すべての競合を解決できるわけではありません。変更前に、そのアドレスがどちらのネットワークに属するかを確認しましょう。

Keepalive・MTU・モバイルネットワーク

Keepaliveは、ネットワーク機器上のマッピング状態を維持するのに役立ちます。外部からの通信を実際に受け付ける必要がある場合や、マッピングを維持したい構成で使用しますが、間隔を短くしすぎるとバックグラウンドの通信が増えます。どんな場合にも使える最適化だと考えて、任意に短い間隔を設定しないでください。モバイルネットワークの切り替えで外部アドレスやマッピングが変わる場合があります。プロトコルに対向情報を更新する仕組みがあっても、新しいネットワークでデータが届くこと、経路が復旧するまで時間を置くことが必要です。

MTUは一度に運べるパケットの最大サイズを表します。カプセル化には追加の領域が必要です。経路で許容されるサイズが不足すると、短いリクエストは成功するのに大きなレスポンスが途中で止まることがあります。まずサーバーと接続先の問題を除外し、実際の経路に応じて慎重に調整したうえで元の値も記録してください。すべてのタイムアウトがMTUの問題とは限りません。むやみに小さくするとパケット数と処理負荷が増え、速度が改善する保証もありません。再現できる接続先で変更の効果を確認しましょう。

06 / HYSTERIA2

Hysteria2：QUIC・帯域幅の設定・パケットロスへの対応

QUICをベースにした接続方式

Hysteria2はQUICをベースとする通信方式を採用しています。QUICはUDP上で、安全な接続、ストリーム管理、信頼性の高い転送などの機能を提供し、一つの接続の枠組みで複数のストリームを管理できます。すべてのデータを単一の順序付きバイトストリームに載せる場合と比べ、通信層での各ストリームの受け渡しをより独立して処理できますが、帯域幅、輻輳制御の情報、端末のリソースは共有されます。各ストリームがそれぞれ独立した通信容量を持つという意味ではありません。

この設計は往復遅延が大きい経路やパケットロスのある経路について語られることがありますが、「パケットロスがあれば必ず速くなる」とは限りません。パケットロスの原因には、輻輳、無線信号、ネットワーク機器の制限、経路の変化などがあります。送信方法はこうした条件に適応する必要があります。外側のUDP通信が安定しなければ、その上で動くプロトコルだけで到達性を生み出すことはできません。プロトコルの機能と現在のネットワークで許可される通信条件の両方を満たす必要があります。

認証・TLS・サービス名も確認する

Hysteria2の接続情報には通常、サーバー、ポート、認証情報、TLS関連の設定が含まれます。認証と証明書の検証は別の処理です。前者ではサーバーがクライアントの利用権限を確認し、後者ではクライアントがサーバーの身元を確認します。Server、SNI、証明書名が一致するか、サーバーの構成情報に基づいて確認してください。QUICを使っているからといって、証明書の確認を省略したり、任意の名前を使用したりしないでください。

構成で追加の難読化設定を使う場合は、両端の種類と対応する設定値を確認してください。認証パスワードの別名ではなく、任意の文字列を入力すれば有効になる速度設定でもありません。名前が似ているからといって、Hysteria2と他のプロトコルや異なる世代のプロトコルの設定を混用しないでください。インポート後に理由の分からない空欄がある場合は、別の種類の設定をそのままコピーせず、元の情報に戻って意味を確認しましょう。

帯域幅の設定値は実際の速度を保証しません

設定によっては、送受信の制御や帯域幅のネゴシエーションに使う帯域幅の値を指定します。これらは動作条件や制御に使われる値であり、購入した利用権でも、端末が必ず得られるスループットの保証でもありません。単位の違いには特に注意してください。ビット毎秒とバイト毎秒は異なります。画面の表示単位と情報に記載された単位が異なる場合は、まず換算し、項目の指定に従って入力します。桁を誤ると動作に影響するおそれがあります。

実際に利用できる容量を大幅に上回る帯域幅を設定しても、物理的な回線容量は増えません。むしろ送信が過剰に積極的になると、キューが溜まってほかのアプリの応答が遅くなり、パケットロスや速度の大きな変動につながることがあります。値が低すぎれば利用可能なスループットを制限する場合があります。明示的な入力が必要か、現在の構成で設定がどう反映されるかは、両端の実装と構成説明を確認してください。他の人の数値を定番の推奨値として使うのは避けましょう。

モバイル端末で追加コストを評価する

QUICでは暗号化、パケット管理、通信の復旧処理に端末のリソースが必要です。電波の弱い環境や制限のあるネットワークで外側のUDP通信が何度も再試行されると、無線通信やバッテリー消費が増える場合もあります。高スループット時に端末が熱くなっても、プロトコル名だけが原因とは限りません。画面、接続先のアプリ、継続的なデータ通信も関係します。比較する際は、タスク、画面の明るさ、端末温度、測定時間をできるだけ揃え、環境の違いをプロトコルの違いと取り違えないようにしましょう。

すでにお持ちのHysteria2設定が、あるネットワークでは何度も失敗し、別のネットワークでは安定する場合は、まずネットワークごとに比較し、ハンドシェイク自体が完了しているか記録してください。ハンドシェイクは正常でも、負荷をかけると長時間不安定になる場合は、帯域幅の設定、サーバーのリソース、経路上のパケットロスを確認します。一つのアプリだけで問題がある場合は、その通信が実際に該当する接続を通っているか、接続先のサービスが正常かを確認してください。一つの現象だけからプロトコル全体が使えないと判断しないでください。

07 / IOS & IPADOS

iPhone・iPad：速度、バッテリー、ネットワーク切り替え

速度を3つの観点から確認する

1つ目は接続確立までの時間です。アドレスの名前解決、サーバーまでの下位層の接続、セキュリティハンドシェイクを含みます。2つ目は接続先から最初の応答が返るまでの時間で、接続先にアクセスするサーバー側の処理時間も関係します。3つ目は継続通信のスループットで、帯域幅、パケットロス、輻輳制御、両端の処理能力に左右されます。普段のWeb閲覧は前の2項目、大容量ファイルの転送は3つ目の影響を受けやすい傾向があります。1回の遅延値で3項目を同時に評価したり、動画、通話、操作時の使用感に直接置き換えたりすることはできません。

Connectivity Testの結果は、現在の測定方法とあわせて判断してください。方法によってはサーバーに到達できるかだけを確認し、別の方法ではプロキシを経由した接続先へのアクセスを試みることがあります。何を測定しているか分からない状態で、その数値を通信全体の往復時間とみなさないでください。地域名もメモにすぎず、実際の通信経路を測定した結果の代わりにはなりません。テストの意味と地域の見方については、遅延、地域、プロトコルの種類の関係もご覧ください。

バッテリー消費は接続全体で決まる

接続中は、アプリの通信、システムのネットワーク処理、プロトコルの暗号化、無線通信、必要なバックグラウンド処理が動作します。高スループット時は処理と無線通信のコストが増えます。通信がない状態では、Keepalive、自動チェック、接続失敗後の再接続に注目するとよいでしょう。バッテリー統計の割合はほかのアプリの使用量にも左右されるため、使用条件の異なる日の数値をそのまま比べて、プロトコルの効率を判断しないでください。

適切に比較するには、まず端末を同程度の温度に戻し、ネットワーク、画面の明るさ、タスクを揃え、近い時間だけ実行してから、バッテリーの変化、通信量、接続の失敗状況を記録してください。一方が充電中で、もう一方が低電力モードだったり、バックグラウンドで大量の同期が行われたりすると、結果を判断しにくくなります。数分間のごく小さな割合の差を追うより、継続的に異常な通信が起きていないかを確認しましょう。

Global Routingでテストの条件が変わる

Global RoutingのConfig、Proxy、Directは、それぞれ設定に従う、プロキシ、直接接続の各モードに対応します。Configではルールによって特定の接続先が直接通信することがあります。Proxyで比較する場合も、システムや特別な通信に対するクライアントの処理範囲を理解する必要があります。Directではリモートプロキシが利用できるか確認できません。比較する前に、同じ接続先が同じ種類の経路を通っているかを確認してください。そうでなければ、測定結果に表れるのはプロトコルではなくルーティングの違いです。

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

上はルールの順序を示す例です。接続先のドメインがexample.comに該当する場合はPROXY、指定したプライベートネットワークはDIRECT、それ以外はFINALに送ります。この例には接続先のサーバー情報が含まれていないため、単独で接続を確立することはできません。ルールは上から順に照合され、先行する条件が後続ルールに影響します。変更前に現在有効なConfigを確認し、必要に応じて設定ファイルの各セクションの解説を参照してください。

ネットワークを切り替えた後に再確認が必要な理由

Wi-Fiからモバイルネットワークに切り替えると、ローカルアドレス、デフォルトルート、DNS、ネットワーク機器上のマッピングが変わる場合があります。接続が有効と表示されていても、通信経路を再確立する必要があるかもしれません。QUICやWireGuardには経路の変更に対応する仕組みがありますが、正常に切り替わるかは両端の実装と現在のネットワークに左右され、すべてのセッションが途切れずに保たれるとは限りません。切り替えを何度も素早く繰り返すより、経路が安定するまで待ってから新しいリクエストで確認するほうが判断しやすくなります。

On Demandは、条件に合ったときに接続を開始する動作を設定する機能です。誤ったパスワード、無効な証明書、到達できないサーバーを修復するものではありません。ネットワーク切り替え後に接続を繰り返す場合は、自動接続の動作とプロトコルの再試行を分けて確認し、ルールが変わっていないか、ネットワークへの接続が完了しているかも調べてください。Settingsの関連項目は機能と設定をご覧ください。一時的な切断への対処として、すべての自動接続条件を変更しないようにしましょう。

最後にIPv4とIPv6の経路も区別して確認してください。ドメインによって異なるアドレスファミリーのアドレスが返される場合があり、ネットワーク切り替え後に使われるアドレスが変わることもあります。一部の接続先だけ失敗する場合は、名前解決の結果、サーバーの出口、該当するルーティング条件を確認し、すぐにどちらかのアドレスファミリーを無効にしないでください。DNSで変更できるのは名前解決の段階だけです。証明書、プロトコル認証、サーバーのアクセス権限、接続先サービス自体の問題は自動で修復されません。

08 / SELECTION & DIAGNOSTICS

用途に応じた選び方と階層別のトラブルシューティング

利用条件を確認してから使用感を比較する

プロトコルを順位付けする前に、まずお持ちのサーバーが何に対応しているか確認します。有効な設定が一つだけなら、まずその設定を正しく構成してください。複数の設定がある場合は、認証情報の不足、セキュリティ構成の不明確さ、ネットワーク条件との不一致を確認して候補から外します。残った設定を、普段の用途に合わせて比較します。プロトコル名だけでは、サーバーの到達不能、出口の混雑、誤ったルーティングを補えません。クライアントで、サーバーに用意されていないプロトコルを使えるようにすることもできません。

タスクを固定して再現可能な比較を行う

実際に使う接続先を2〜3個選び、短いリクエスト、継続的なデータ転送、必要に応じてリアルタイム通信をテストします。各回でネットワークと端末を同じにし、近い時間帯に実施して、接続先への経路が一致していることを確認してから、お持ちの設定を切り替えます。最良の結果だけでなく、典型的な使用感と失敗回数を記録してください。設定ごとに地域やサーバーが異なる場合、比較しているのは接続全体の使用感です。プロトコルの性能だけを証明するものではありません。

バッテリー消費が気になる場合は、安定して接続できる設定を対象に、アイドル時の維持と実際に通信している状態をそれぞれ比較します。何度も接続に失敗する設定は、ときどき速くても長時間の利用に向かないことがあります。操作への応答を重視する場合は、負荷がかかったときの応答の変化を確認してください。リモートネットワークへの接続では、アドレス設計と権限の確認を優先します。用途によって重視する条件は異なるため、あらゆるネットワーク、端末、接続先に使える固定のプロトコル順位はありません。

障害が起きたら4つの階層で原因を絞り込む

まずローカルネットワークを確認します。端末がWi-Fiに接続済みか、通常の直接接続先にアクセスできるか、ネットワークの切り替えが完了しているかを見ます。次にサーバー接続を確認します。Serverの名前解決結果、Port、必要なTCPまたはUDPの経路に到達できるかを調べます。この時点ですぐUUIDを変更しないでください。認証情報を変えてもアドレスの誤りは修正できません。一つのネットワークだけで失敗する場合は、設定を変えずに別のネットワークで比較してください。

3つ目にセキュリティと認証を確認します。TLSの名前、証明書、端末時刻、Password、UUID、鍵がすべて正しいか照合してください。ログでハンドシェイクと認証の段階を区別できる場合は、失敗した段階に応じて対処し、すべての問題を「接続タイムアウト」として扱わないようにします。4つ目は実際の転送です。Global Routing、現在のConfig、接続先のDNS、サーバーの権限、UDPの条件、戻りの経路を確認してください。ハンドシェイクが成功して接続先に届かないなら、最初の段階で確認したサーバーのポート以外に原因がある可能性が高くなります。

更新・元に戻す・問題を記録する

Subscribeの更新によってサーバー項目や設定内容が変わることがあり、手動での変更がそのまま保存されない場合もあります。更新前後に差が生じたら、表示名だけでなく実際の項目を比較してください。サブスクリプションURLを公開の場に貼り付けないでください。アクセス情報が含まれている場合があります。トラブルシューティングの記録には、プロトコルの種類、ネットワーク、失敗した段階、接続先の種類、機密情報を隠したエラーメッセージがあれば十分です。秘密鍵や認証情報の全文を公開する必要はありません。

変更しても改善しなければ、元の値に戻して別の仮説を確認してください。さらに相談する場合は、大量の未整理なスクリーンショットより、「どのネットワークで、何に接続し、いつ失敗したか、何を確認済みか」を伝えるほうが役立ちます。初回インポートの問題ははじめにの手順を、購入、再インストール、購入済みアプリの復元については入手ガイドをご覧ください。App Storeでの入手に関する問題とプロトコルの接続問題を、同じトラブルシューティングで扱わないようにしましょう。

最後に、動作を確認した基準となる設定を一つ保存し、プロトコル、認証方式、セキュリティレイヤー、ルーティングモードを把握しておきましょう。個別の設定値の組み合わせを暗記するより、こうした境界を理解しておくほうが環境の変化に対応できます。設定はサーバーと一致し、テストは実際の用途に即したもので、結論は実際に確認したネットワーク条件の範囲内に限られます。