Shadowrocket プロトコル技術ガイド：設定項目・速度・バッテリー消費を解説

01 · 選ぶ前に4つの情報層を区別する

プロトコル名だけでは分からないこと

Shadowrocketのサーバー項目に含まれるのは、プロトコルだけではありません。アドレスとポートは接続先を指定します。ShadowsocksやVMess、VLESSなどの種類は、プロキシ要求のやり取り方法を決めます。TCPやWebSocketなどの伝送方式はデータの運び方を、TLSは暗号化と証明書の検証に関わります。ルールとポリシーは別の層で、そのリクエストをどの項目に渡すかを決定します。これらはすべて結果に影響しますが、互いに置き換えることはできません。

同じアドレスだからといって、種類を自由に切り替えられるわけではありません。ポートやパスワードが似ていても、VLESSをTrojanに変更しただけでサーバーが新しい要求を理解することはありません。サーバー側に該当する接続口があり、認証情報、伝送方式、安全設定も一致している必要があります。ここでいう「プロトコルを選ぶ」とは、手元にある、対応が明示された項目から選択することです。項目の種類名を別の名前に変更することではありません。

既存の情報をもとに確認する順序

既存のサブスクリプションをインポートしたら、まずHomeで項目を確認し、編集画面で種類とサーバーアドレスを確認します。手動で追加する場合は、Add Serverからサーバーの説明に合った種類を選びます。種類によって表示される項目は異なります。項目の有無、選択肢、表示位置は、現在のアプリ画面で確認してください。説明に項目名があるからといって、名前の似た別の入力欄に入力しないでください。

確認は、アドレスとポート、認証情報、伝送方式、安全設定、最後にルールの順で行うのがおすすめです。障害が発生する層に沿った順序です。アドレスが誤っていれば接続先に到達せず、認証情報が誤っていれば本人確認を通過できません。伝送方式が一致しなければ要求を正しく解析できず、証明書の検証に失敗すれば安全な接続が成立しません。先にルールを変更しても、こうした問題は解決しにくく、かえってテスト対象が分かりにくくなることがあります。

層	主な情報	確認ポイント
接続先	Address、Port	完全なアドレス、ポート番号、名前解決
認証情報	Password、UUID、キー	種類と認証情報が正しく組み合わされているか
伝送方式	TCP、WebSocket、Path	サーバーの接続口や中継設定との整合性
安全設定	TLS、SNI、証明書	接続先の名前と信頼関係を確認

アプリ、サービス、ストアの情報をそれぞれ確認

Shadowrocketはクローズドソースの商用アプリです。このページでは主にiPhoneとiPadについて説明します。iPhone と iPad は App Store の買い切り、Mac、Windows、Android、Linux は無料です。アプリの買い切り購入と接続サービスの契約は別です。購入するのはアプリの利用権で、接続にはユーザー自身が用意したサブスクリプションまたはサーバー情報が必要です。当サイトでは接続先やサブスクリプションを提供、販売、推奨していません。サブスクリプションの有効性やサーバーが対応するプロトコルは、契約元の説明で確認してください。アプリに表示できる種類から推測することはできません。

iPhoneとiPadはApp Storeで買い切り、ほかのプラットフォームは無料です。購入や製品情報の確認は正規の入手方法と確認ガイドをご覧ください。デベロッパ名がShadow Launch Technology Limitedであること、公式アイコン、アプリIDが932747118であることを確認できます。システム要件と購入対象地域はApp Storeの掲載内容をご確認ください。接続の失敗と購入状況は別の問題です。アプリが正常に開けても、サーバー情報が有効とは限りません。

02 · Shadowsocks：暗号化方式と認証情報を確認

軽量プロキシの設計思想から設定項目を理解する

Shadowsocksは、比較的シンプルなプロトコルでプロキシ通信を運び、クライアントとサーバーが共通の暗号化方式とパスワードを使ってデータをやり取りする設計です。デバイス全体を遠隔地のLANに接続するものではなく、Webサイトへのリクエストをすべて自動的にプロキシ経由にするものでもありません。Shadowrocketでは現在のGlobal Routingの状態と設定ルールに基づいてリクエストの経路を決めます。プロトコルが扱うのは、そこに渡された通信です。

この役割分担により、主に確認する項目はサーバーアドレス、ポート、暗号化方式、パスワードに絞られます。項目が少ないからといって、推測で設定してよいわけではありません。特に、パスワードが正しければ認証情報はすべて正しいと判断するのは禁物です。暗号化方式は、双方がデータを解釈するための取り決めです。誤っていると、サーバーが接続を受け付けても内容を解析できず、パスワード誤りに似た症状が出ることがあります。通常、接続を繰り返すだけでは解決しません。

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

現在の構成では、認証に加えてデータの改ざんも検出する暗号化方式がよく使われます。方式ごとに、鍵の長さ、生成方法、データ形式が異なります。サーバーから提示された方式名は省略せず、そのまま使用してください。名前の一部が似ていても同じ方式とは限りません。別の項目のパスワードをコピーして、互換性があると決めつけるのも避けてください。プロトコルの種類によって認証情報の形式が異なる場合もあります。

新しいShadowsocksの方式では、任意のパスフレーズではなく、指定された形式や長さのキーを使うことがあります。入力欄の文字列が普通のテキストに見えても、定められた形式の鍵情報である場合があります。独自に短くしたり、文字を補ったり、再エンコードしたりしないでください。インポートは成功するのに手入力で再現できない場合は、コピー時に末尾の文字が欠けていないか、改行が混入していないか、リンクのエスケープ済み文字列を元の認証情報として使っていないかを確認します。

UDPや追加の伝送方式は名前だけで判断しない

アプリによってはUDPを使って通信します。TCPを使うWebページが表示できても、その項目の関連経路が使えることを示すだけで、UDPも使えるとは限りません。サーバー側で該当する転送が許可されているか、現在のネットワークがデータを通せるか、項目の設定が手元の説明に合っているかも確認してください。UDPの失敗を「プロトコル全体が不安定」と判断すると、サーバー側の制限やネットワーク経路の違いを見落とすおそれがあります。

既存の項目に追加の伝送設定が含まれている場合は、各設定の用途を確認してください。Shadowsocksだから追加設定はないと決めつけてはいけません。追加層はコアプロトコルとは別に確認が必要です。コアのパスワードが正しくても追加層の設定が誤っていれば接続できず、分からない設定を削除すると正常だった接続口を壊す可能性もあります。まずサブスクリプションからインポートした元の項目を使うほうが、手動で設定を省くより再現しやすい基準になります。

iPhoneで適性を見極める

条件が同じであれば、カプセル化の層が少ないことで一部の処理負荷が下がる可能性はありますが、速度や電池持ちが保証されるわけではありません。実際の使用感は暗号化処理、デバイスの性能、サーバー負荷、パケットロス、往復遅延にも左右されます。短時間のWeb閲覧では接続確立や少量データの転送が中心となり、継続的なファイル転送ではスループットを確認します。テストによって印象が異なることがあるため、分けて記録してください。

既存のShadowsocks項目で日常の通信が安定しているなら、別のプロトコル名のほうが新しいという理由だけで切り替える必要はありません。接続できるのに特定のアプリだけ使えない場合は、名前解決、TCP・UDPの経路を切り分け、そのアプリに別のポリシーが適用されていないか確認します。すべてのリクエストが失敗する場合は、電池関連の設定より先に、アドレス、ポート、暗号化方式、パスワードを確認してください。

03 · VMessとVLESS：認証情報、伝送方式、TLS

似た設定項目でも、プロトコルは同じではない

VMessは認証とプロトコル独自のデータ保護機能を組み合わせており、UUIDがよく使われる認証情報です。VLESSはより簡潔な認証とリクエスト形式を採用し、通信経路の保護を外部のセキュリティ層に委ねます。どちらも複数の伝送方式と組み合わせられるため、編集画面に似た項目が表示されることがありますが、種類を変更して相互変換できる形式ではありません。サーバーが実際に提供する接続口と一致するものを選びます。

こうした設計の違いを理解すれば、「項目が少ないから安全」または「速い」と短絡せずに済みます。VLESS自体はVMessと同じコンテンツ暗号化機能を持たないため、構成時に外側の保護方法を確認する必要があります。VMessには独自の安全機構がありますが、外側の伝送設定を無視してよいわけではありません。項目を評価するときは、プロトコル、伝送方式、安全設定をひとまとまりとして考え、名前だけで判断しないでください。

UUIDは表示名ではなく認証情報

UUIDは一文字ずつ元の値を保ってください。項目名は地域や用途の識別に使え、通常、名前を変えても認証には影響しません。一方、UUIDは本人確認に直接使われるため、変更するとサーバーが認識できなくなります。コピー時はハイフン、前後の空白、自動改行に注意してください。複数の項目で同じUUIDを使っていても、アドレス、ポート、その他の設定が同じとは限りません。項目ごとにすべて確認してください。

VMessの認証では時刻情報も関係します。デバイスの時刻が大きくずれていると、設定が正しく見えても認証に失敗する場合があります。まずシステム設定で日付と時刻が正しいか確認し、その後にサーバーの認証情報を調べてください。テスト目的でUUIDを何度も変更するのは避けます。既存の情報に互換性に関わる追加項目がある場合はサーバーの説明に従い、異なる時期のサンプルから値を混ぜて使わないでください。

WebSocketのHost・PathとTLSのSNI

WebSocketは所定の接続上にプロキシデータを載せます。よく確認する項目はHostとPathです。Pathはサーバーのルーティング設定と一致させる必要があります。先頭のスラッシュ、大文字と小文字、末尾のパスも意味を持つことがあります。Hostは関連リクエストのホスト情報として使われ、サーバーが値に応じて接続先を振り分ける場合があります。これらが誤っていると、対象ポートに接続できても、その後のプロトコルのやり取りに失敗することがあります。

SNIはTLSハンドシェイクで使うサーバー名情報です。証明書の検証では、想定する名前と証明書が一致しているか確認します。サーバーの接続アドレス、WebSocketのHost、SNIは構成によって同じ場合も異なる場合もあるため、3つの入力欄に同じ値を自動的に入力しないでください。IPアドレスで下位の接続を確立する場合でも、安全な接続を正しく確立するために、サーバーの説明にあるドメイン名が必要なことがあります。

情報	役割	代用できない項目
UUID	ユーザーを識別する	TLSの検証は代替できない
Host / Path	対応する伝送接続口に合わせる	サーバーアドレスとポートは代替できない
SNI	TLSサーバーに接続先の名前を伝える	認証情報は代替できない
Flow	特定の組み合わせにおけるデータ処理要件を指定する	非対応サーバーに機能を追加することはできない

選ぶときは接続設定一式を単位にする

VLESSの組み合わせによってはFlowや特定の安全設定も必要です。サーバーが明示的に要求し、現在のクライアントにも該当する選択肢がある場合にのみ設定してください。別の項目で使われている値を見て、すべてのVLESS項目にコピーするのは避けます。組み合わせごとに条件は異なり、空欄が正しい場合もあります。判断の基準は常に、現在のサーバー接続口の設定情報です。

iOSで両者を比較する際は、まず伝送方式と安全層の違いを揃えてください。直接TCPを使う項目と、多層のカプセル化を使う項目を比べても、結果をVMessまたはVLESSだけの差とは判断できません。元のサブスクリプション項目は使えるのに手動設定した項目が失敗する場合は、UUID、伝送方式、Host、Path、TLS、SNIを順に照合します。すべて一致して初めて、処理負荷を比べる意味が生まれます。

04 · Trojan、HTTP、SOCKS5：安全性の境界

TrojanではTLSが重要

Trojanは一般に、TLS接続内でプロキシ要求を運び、パスワードなどでユーザーを識別します。実績のある安全な伝送方式を利用しますが、クライアント側ではサーバーアドレス、ポート、パスワード、検証名を正しく設定する必要があります。ポートに接続できても、確認できるのは下位の経路が存在することだけです。パスワードが正しくても、証明書の名前が一致しなければ解決しません。トラブル時はハンドシェイクの失敗と認証の失敗を別々に扱います。

ドメイン名、SNI、証明書の関係は特に重要です。証明書は想定するサービス名をカバーし、有効で信頼されている必要があります。接続先アドレスと検証名が異なる構成では、サーバー情報に従って別々に入力してください。証明書エラーが出たら、まずデバイスの時刻、名前、サーバーの証明書チェーンを確認します。検証を無効にする方法は接続先を識別する能力を弱めるため、通常の解決策にしないでください。

HTTPプロキシですべての通信が保護されるわけではない

HTTPプロキシはアプリケーション層のプロキシとして使われ、リクエストの転送や、CONNECTによる接続先へのバイトストリーム確立を行います。項目には通常、アドレス、ポート、ユーザー名、パスワードが含まれます。ここでは、デバイスからプロキシサーバーまでと、アプリから接続先サイトまでの2つの接続を区別する必要があります。接続先サイトがHTTPSでも、デバイスからプロキシへの認証情報が同じ方法で保護されるとは限りません。外側の接続でTLSを使うかどうかは別途確認してください。

既存の説明にHTTPとある場合、TLS付きのプロキシ接続口と同じだと決めつけないでください。安全な伝送が必要と説明されている場合も、通常のプロキシ項目だけを設定して済ませないでください。両端で対応方式が異なると、ハンドシェイクに失敗する可能性があります。ユーザー名とパスワードが正しいか、プロキシがCONNECTを許可するか、接続先ポートが制限されていないかも、「一部のWebサイトだけ使える」という症状に関係します。

SOCKS5は汎用的な接続交渉を行うが、暗号化は備えていない

SOCKS5は接続交渉によって接続先アドレスや要求内容を指定します。ユーザー名とパスワードによる認証が使え、UDP関連の仕組みも定義されています。ただし、プロトコル自体がすべての通信内容を暗号化するわけではありません。本人確認と通信内容の秘匿は別の機能です。パスワードが必要だからといって、通信経路が暗号化されているとは限りません。実際の安全性はネットワーク環境、外部のセキュリティ層、アプリ自体の接続保護にも左右されます。

SOCKS5の項目で接続できても、UDPが使えるとは限りません。サーバーがTCPのみを許可している場合や、ネットワークがUDP関連のデータを通せない場合があります。ドメイン名をどこで解決するかも区別が必要です。実際の経路はアプリ、クライアント設定、プロキシ要求の形式によって変わります。ドメイン名では失敗するのに、直接アドレスでは結果が異なる場合は、プロキシのパスワードを繰り返し変更するのではなく、DNSとルールを確認してください。

種類	主な確認項目	重要な注意点
Trojan	Password、TLS、SNI	パスワード認証と証明書検証はそれぞれ必要
HTTP	認証、CONNECT、外側の安全設定	接続先がHTTPSでも、プロキシ経路の設定が完了しているとは限らない
SOCKS5	認証、TCP / UDPへの対応	プロトコル自体は通信内容を暗号化しない

名前で安全性を順位付けせず、既存の環境に合わせて選ぶ

既存の環境で使えるプロキシ接続口が1種類だけの場合は、まず伝送保護とアクセス権を確認し、用途に合うか判断してください。クライアントの種類選択だけでサーバーにTLSを追加することはできません。HTTPをSOCKS5に変更しても認証の失敗は解決しません。組織が管理する既存の接続口では、アクセス範囲やデバイス利用ルールにも従ってください。用途が限定されたプロキシを汎用の通信経路として扱わないようにします。

iPhoneでは、これらの種類の速度差がネットワーク経路の影響に隠れることがあります。ハンドシェイクの回数、接続の再利用、サーバーの応答、Wi-Fiの状態が、プロトコル解析の負荷より大きく影響する場合があります。正しく比較するには、同じ作業を近い環境で行い、各項目の安全設定が揃っていることを確認してください。証明書検証を無効にした場合だけ使える項目は、性能上の利点と捉えるのではなく、サーバー情報を修正してください。

05 · WireGuard：キー、アドレス、トンネルの範囲

ネットワーク層のトンネルとしての違い

WireGuardは、比較的シンプルなプロトコルと固定の現代的な暗号方式の組み合わせで、ネットワーク層のトンネルを確立することを目的に設計されています。プロキシ要求で接続先を指定するプロトコルとは異なり、トンネル内のIPパケットを扱います。この違いは設定項目にも表れます。接続先アドレスに加えて、ローカルのトンネルアドレス、双方のキー、対向側に通すアドレス範囲も理解する必要があります。通常のプロキシと同じパスワード設定をそのまま当てはめないでください。

ShadowrocketでWireGuardを使う場合も、項目自体のトンネル設定とクライアントのルーティング判断を分けて考えてください。項目は対向先との通信方法を定め、Global Routingと設定はどのリクエストをそこに渡すかを決めます。トンネル内のアドレスが表示されても、デバイスのすべてのリクエストが想定どおりトンネルを通るとは限りません。クライアントの接続スイッチがオンでも、接続先が必要な宛先へのアクセスを許可しているとは限りません。

Private Key、Public Key、Endpoint

Private Keyはローカルの認証情報であり、秘密に保管してください。対向側のPublic Keyはリモート側を識別するために使います。両者は同じ文字列の別名ではなく、入れ替えることもできません。既存の設定にPreshared Keyがある場合は、追加の共有キーとして双方で一致させる必要があります。トラブルシューティングでは、項目の有無と一致を記録するだけにし、完全なキーを公開スクリーンショット、ログの説明、問い合わせコメントに貼り付けないでください。

Endpointは接続可能なリモートアドレスとポートを指定し、トンネル内部のアドレスとは異なります。設定内のローカルアドレスはトンネル内通信に使うもので、任意のプライベートアドレスを選べばよいわけではありません。サーバー側で該当するクライアントとアドレスの対応を把握している必要があります。不適切なアドレスや認証情報を再利用すると競合することがあります。新しいデバイスで同じ情報を使えるかは、既存のサーバー設定ルールに従って確認してください。

Allowed IPsとルーティングは別の表

Allowed IPsは対向側が扱えるアドレス範囲に関わり、トンネル内の経路選択や送信元の制約を理解するうえでも重要です。ShadowrocketのDOMAIN-SUFFIXなどのルールとは別の層にあります。外側のルールでリクエストをWireGuardに渡しても、トンネルや接続先で該当範囲が許可されていなければ通信は失敗します。反対に、トンネルである範囲が許可されていても、クライアントが関連するリクエストを必ずそこへ送るとは限りません。

既存の内部リソースへアクセスする場合は、接続先での転送、宛先からの戻り経路、名前解決も確認します。トンネルのハンドシェイクが成功しても、接続先デバイスが応答を返す方法を知らなければ、リクエストはタイムアウトします。ドメイン名だけ失敗し、該当する内部アドレスには到達できる場合は、内部DNSへの接続と設定を優先して確認してください。内部アドレスがすべて使えない場合は、アドレス範囲、接続先の権限、ルーティングを確認します。

MTUとPersistent Keepaliveの調整

MTUは、1つのトンネルパケットで運べるデータ量を制限します。カプセル化で追加のデータが増える一方、経路にも上限があるため、設定が適切でないと小さなリクエストは成功しても大きな転送が止まることがあります。遅延を感じるたびに値を下げるのではなく、まずパケットサイズと障害の関係を確認し、元の値を記録してください。変更後は同じ宛先、同じ転送作業で再テストし、短時間のネットワーク変動をMTU調整の効果と誤認しないようにします。

Persistent Keepaliveは、一部のネットワークアドレス変換環境でマッピングを維持するために使われますが、定期的なパケット送信によって無線通信が増えます。間隔を短くすれば安定するわけではなく、すべてのネットワークで必要な設定でもありません。アイドル後に戻り経路が使えなくなり、既存の設定で変更が許されている場合に限って検討してください。iPhoneのモバイル通信では復帰時の電力消費も観察し、再接続が一度速くなったかだけで判断しないでください。

06 · Hysteria2：UDP経路と帯域幅の推定

パケットロスがある経路での通信に着目した設計

Hysteria2はQUICをベースにしたプロキシ伝送方式で、QUICは通常UDP上で動作します。パケットロスや長い往復遅延がある経路でも、伝送効率を保つことを重視しています。ここでいう「ロスがある」とはネットワーク環境を表すもので、すべてのモバイル回線が同じ条件だという意味ではありません。現在の環境に適するかは、プロトコル名から速度を推測するのではなく、まずUDP経路が使えることを確認し、実際の作業で試してください。

QUICは安全なハンドシェイクと伝送機構を組み合わせ、1つの接続上に複数のストリームを持てます。単一の順序付きバイトストリームによる相互待ちを一部減らせる場合がありますが、回線の混雑、無線のパケットロス、サーバーリソースの制限は残ります。実際の帯域幅を増やしたり、接続先の応答を速くしたりするものではありません。特定のWebサイトの表示が遅い場合は、引き続きDNS、ルール、接続先自体を確認してください。

まず認証情報と証明書を確認し、その後に性能設定を見る

基本的な項目には、サーバーアドレス、ポート、認証情報、TLS関連の設定が含まれます。認証情報は既存の情報を完全な形で使い、見た目が似ているからといって別のプロトコルのUUIDやパスワードで代用しないでください。SNIと証明書の検証も正しく成立する必要があります。QUICがUDPを使うからといって、サーバーの身元確認を省略できるわけではありません。証明書のエラーとUDPの不通は症状が異なることがあるため、分けて記録してください。

既存のサーバーで追加のObfuscation方式やパスワードが必要な場合は、クライアントとサーバーで設定を一致させます。これは接続口を構成する一部であり、自由に有効にすれば性能が向上するボタンではありません。明確な設定がない場合は追加せず、既存の設定に含まれている場合も削除しないでください。ポート範囲やポートの切り替えも、接続先が明示的に対応している必要があります。片側の数値を変更しただけで新しい接続先が使えるようにはなりません。

帯域幅の設定値は推定であり、速度の保証ではない

一部の伝送方式では、送信制御にユーザーが入力した上り・下りの帯域幅を使います。クライアントから見た方向を確認し、単位も正しく照合してください。数値を大きくしても物理回線の容量は増えません。実際の経路に合わない値を設定すると、キューの増加、パケットロス、通信の変動につながることがあります。値が小さすぎると利用効率を制限する場合もあるため、現在の方式に応じて判断してください。

利用できる帯域幅はネットワークによって変わります。自宅のWi-Fiでの結果を、そのままモバイル通信に当てはめることはできません。テスト時は既存の設定値を基準にし、上り、下り、その他の伝送設定を同時に変更しないでください。現在の画面やサーバーで自動推定を使う場合は、その説明に従い、別の方式で必要な設定をそのまま当てはめないでください。大きな数値を追うより、設定項目の意味を理解することが大切です。

UDP経路の制限を見分ける

対象の項目を経由しない場合は通常のWeb閲覧ができるのに、Hysteria2では接続が完了しない場合、現在のネットワークでUDPが使えるか、サーバーのポート、リモート側の稼働状況を確認します。ただし、タイムアウトだけでUDP制限と断定することはできません。アドレスの名前解決、認証、安全設定の誤りも原因になり得ます。信頼できる別のネットワークで同じ元の項目を使って再テストすると、経路の影響を絞り込めます。

接続できても継続的な転送が大きく変動する場合は、無線の電波状況、上り回線の占有、デバイスの発熱を確認してください。特定の経路では積極的な送信制御によってスループットが改善する場合がありますが、再送、無線通信、電池消費が増えることもあります。モバイルデバイスでは、同じ作業にかかった時間と電池消費を合わせて記録します。短時間のピークだけでは、長時間の利用に適するか判断できません。

07 · iOSで速度と電池消費を分けて確認

「速さ」を3つの観察項目に分ける

ページを初めて開くまでの待ち時間、継続的な転送のスループット、長時間接続の安定性は、それぞれ異なる指標です。待ち時間にはDNS、下位接続の確立、プロトコルのハンドシェイク、安全な接続の確立、接続先の応答が含まれます。継続的なスループットは、主にボトルネックとなる帯域幅、輻輳制御、サーバー負荷に左右されます。長時間接続にはネットワークの切り替え、アイドルタイムアウト、バックグラウンド状態が影響します。1つの遅延値だけで、これらすべてを評価することはできません。

Connectivity Testの結果は、テスト方法と対象によって異なります。特定の接続可否や相対的な変化を確認するのに役立ちますが、実際のアプリ通信の全経路を示すものではありません。テストに成功してもページが表示されない場合は、DNS、ルール、接続先のリクエストを引き続き確認してください。結果の見方は遅延テストと実際の読み込み速度の違いをご覧ください。最小の数値だけで接続可否を判断しないようにします。

プロトコルを比べるときに揃える条件

できるだけ同じデバイス、同じネットワーク、近い時間帯、同じ接続先を使ってください。接続先の場所、回線、サーバー負荷に大きな差がある場合、結果が示すのは主に2つの経路全体の違いであり、プロトコルだけの差ではありません。条件を揃えられない場合は実際の使用感を記録してもかまいませんが、「このプロトコルは常に速い」と一般化せず、「この項目は現在のネットワークでこのような動作をした」と記録してください。

1回のテストでは変更する要素を1つだけにし、短いリクエストと継続的な作業を分けて観察します。初回はキャッシュ、ハンドシェイク、無線状態の影響を受けることがあります。再テストの間隔も一定にしてください。帯域幅を使い切るテストを続けると、デバイスの温度やネットワークの混雑が変わり、結果に影響します。テスト中にWi-Fiを切り替えたり、電波の弱い場所へ移動したり、別の大容量通信が発生した場合、その回は異なる条件として扱い、単純にまとめて比較しないでください。

電池消費はデータ量だけでなく無線通信にも左右される

暗号化やカプセル化には処理時間が必要ですが、モバイルデバイスの電池消費は電波強度、無線の起動、再送、画面、バックグラウンド処理にも影響されます。あるプロトコルの処理負荷が低くても、実際の総消費電力が小さいとは限りません。接続が頻繁に失敗して再試行したり、接続維持のパケットで無線モジュールが動き続けたりすると、その追加コストが暗号化方式の差を上回ることがあります。作業終了後の全体的な結果で判断してください。

電池消費を観察するときは、動画の継続再生、能動的なデータ転送、アイドル時の接続維持を分けます。継続的な作業では同じ作業にかかる時間と電池残量の変化を比較し、アイドル時は不要な定期テスト、Keepalive、再接続がないか確認します。システムのバッテリー統計は一定時間の動作を示す手がかりであり、厳密なプロトコル別の消費電力測定ではありません。短時間で残量の割合が変わらなくても、追加の消費がないとは限りません。

On Demandと接続の再利用に関する注意点

On Demandはネットワーク条件に応じて接続を開始する機能であり、誤った設定に合わせてサーバーのプロトコルを自動調整するものではありません。まず手動接続で安定した基準を作り、その後で接続条件を追加すると、プロトコル接続の失敗と自動起動の失敗を切り分けられます。条件設定はOn Demandのネットワーク条件ガイドをご覧ください。テスト時はネットワークの変化と接続状態も記録します。

接続を再利用するとハンドシェイクを減らせますが、複数のリクエストが同じ接続の混雑や障害状態を共有することもあります。有効にするかどうかは、既存のサーバーの対応状況と現在の画面の説明に従ってください。一部のリクエストが停止するとき、「再利用すれば通常は速い」という理由だけで影響を除外しないでください。元の項目を残し、同じ作業で一度に1つの条件だけを変えて比較し、変化が再現することを確認します。

08 · 用途に合わせて選び、層ごとにトラブルを切り分ける

用途から既存の項目を選ぶ

日常のブラウジングでは、短いリクエストの安定性、正常な名前解決、安全設定の整合性が重要です。すでに使える項目があれば、それを出発点にします。継続的な転送では、最初のテスト結果だけでなく、安定したスループットとデバイスの温度を確認してください。既存の内部ネットワークへアクセスする場合は、WireGuardのアドレス範囲と戻り経路が重要になることがあります。パケットロスのある経路では、既存のHysteria2項目を評価できますが、UDPが使えることが前提です。いずれも確認の観点であり、プロトコルの優劣を示すものではありません。

手元の情報にプロトコルが1種類しかない場合は、他の接続口を探して比較する必要はありません。まずそのプロトコルを正しく設定します。複数の完全な項目がある場合は、それぞれの元の設定を保存し、用途ごとにテストしてください。ある項目のTLS、別の項目のPath、さらに別の項目の認証情報を組み合わせないでください。設定を混ぜて失敗しても、どのプロトコルが適しているかは判断できません。

まずGlobal Routingのテスト状態を確認

Configは設定ファイルのルールに従ってポリシーを選びます。Proxyは対象の通信をプロキシ経路に渡し、Directは直接接続で処理します。状態を切り替えるとテストの経路も変わるため、各回で現在の選択を記録してください。Proxyでも項目やリクエストが対応する範囲を超えることはできず、認証情報の誤りも修正できません。Directは経路の比較に使えますが、すべてのリクエストの成功を保証するものではありません。

プロトコル項目を確認したら、Configに戻ってルールの順序を確認します。以下はマッチングの仕組みを説明するための.confの抜粋であり、汎用の設定ではありません。PROXYポリシーは、実際の設定で正しく解釈できる必要があります。ルールは通常、記述順に照合され、FINALはそれまでのルールに一致しなかったリクエストに使われます。ドメインルールとIPルールは異なる情報に依存し、DNSの名前解決も最終的な照合に影響することがあります。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、example.comとそのサブドメインをPROXYに渡し、指定したプライベートアドレス範囲とGEOIPに一致するアドレスをDIRECTに渡します。すべての環境で同じポリシーを使うべきという意味ではありません。また、GEOIPの判定はアドレスと使用するデータに依存します。セクション名や設定の範囲を理解するには、.confの各セクションの役割をご覧ください。ルールの誤一致を直す代わりに、プロトコルを変更しないでください。

失敗した箇所から原因を絞り込む

まったく接続できない場合は、まず現在のネットワーク、アドレスの名前解決、ポート、サーバーの状態を確認し、その後で認証情報を調べます。証明書の問題が明示されている場合は、時刻、SNI、名前、証明書チェーンを確認してください。接続確立後に失敗する場合は、伝送の接続口、接続先へのアクセス権、転送機能を確認します。一部のドメインだけで問題が起きる場合は、すべての項目を作り直すのではなく、DNS、ルールの一致状況、接続先の状態を優先して調べます。

Webページは正常でも特定のリアルタイムアプリが使えない場合は、TCPとUDPを個別に確認します。小さなリクエストは成功しても大容量転送が止まる場合は、MTU、再送、混雑を観察してください。アイドル後に通信できなくなる場合は、マッピングのタイムアウトとKeepaliveの要否を確認します。ネットワーク切り替え後だけ問題が起きる場合は、切り替え前後のアドレスと接続の復旧状況を記録します。問題に関係する設定だけを変更し、同じ作業で再テストしてください。成功したら、他の自動化条件を元に戻してから確認します。

認証情報を公開せずに結果を記録する

役立つトラブルシューティング記録には、プロトコルの種類、伝送方式、ネットワーク環境、失敗した段階、現在のGlobal Routingの状態、再現可能な症状が含まれます。Password、UUID、Private Key、サブスクリプションの完全なURLは公開記録に含めないでください。アプリのログやスクリーンショットに認証情報が含まれることがあります。共有前に、項目名だけを隠すのではなく、内容を一つずつ確認してください。項目名は通常、最も機密性の高い情報ではありません。

最終的に残すべき結論は、抽象的な速度順位ではなく、「どの設定一式が、どの作業に適し、どのネットワーク環境で使えたか」です。初回の操作はガイドの手順に戻り、よくある症状はよくある質問で確認できます。購入や復元についてはApp Storeでの確認ガイドをご覧ください。購入、インポート、プロトコル接続、ルールの適用を分けて扱えば、次回は確認済みの層からトラブルシューティングを再開でき、最初から推測し直す必要がありません。