Shadowrocket プロトコル解説

01 / Connection Model

接続の仕組み：まず4つのパラメータ層を区別する

プロトコル選びの基本は、性能を名前から推測するのではなく、サーバー側の設定と一致させることです。Shadowrocketの接続項目には通常、サーバーアドレス、認証情報、転送方式、安全設定が含まれます。どの通信をその項目に渡すかはルールで決まります。どれか1つでも設定が合わないと、接続タイムアウトなどの症状が起こることがあります。変更を始める前に、現在使える設定を保存し、情報がご自身の契約先または管理するサーバーから提供されたものか確認してください。不明な項目を記憶だけで補うのは避けましょう。

プロトコル、転送方式、TLSはそれぞれ別の要素

Shadowsocks、VMess、VLESS、Trojanはそれぞれ異なるプロトコルの仕組みを表します。TCP、UDP、WebSocketはデータを運ぶ方法に関わり、TLSは特定の接続層で暗号化と認証を担います。1つの接続項目にプロトコル名、WebSocket、TLSが同時に含まれていても、3つから1つだけを選ぶという意味ではありません。提供された接続情報に沿って各層の項目を対応させてください。TLSを有効にしたからといってプロトコルの認証を省略できるわけではなく、UUIDを入力しただけで転送層まで正しいとは限りません。

アドレスと各名称にも異なる役割があります。Serverは通常、接続先の入口を指定し、Portは接続するサービスのポートを指定します。SNIはTLSハンドシェイクでサーバー名を通知するための項目です。WebSocketのHostはHTTPリクエスト情報に属し、Pathはサーバー側で指定されたパスを表します。これらの値が偶然同じ場合もあれば、意図的に異なる場合もあります。相互に置き換えられる予備の入力欄ではありません。接続情報に指定されていない項目は、読み込み時の値または初期値を維持し、すべてをサーバーアドレスで埋めないでください。

Global Routingで通信が接続項目に渡るかを決める

Global RoutingのConfigは、現在の設定ファイルにあるルールに従って通信を振り分けます。Proxyはクライアントの処理対象となる通信をプロキシポリシーに渡し、Directは直接接続します。切り替わるのはルーティング先であり、サーバー側のプロトコルではありません。ProxyではアクセスできるのにConfigに戻すと失敗する場合は、サーバー項目をすぐ作り直すのではなく、ルールと実際に適用されたポリシーを確認してください。反対に、Directでアクセスできても、プロキシ接続が確立した証拠にはなりません。

DNSはこれらの層すべてに関わる前提条件です。クライアントはサーバーのドメイン名を先に名前解決する必要があり、接続先のWebサイトも別途名前解決が必要な場合があります。サーバー名を解決できない場合、認証はまだ始まっていません。接続先のドメイン名の解決に問題がある場合でも、接続項目自体は使える可能性があります。「サーバーが見つからない」と「サーバー経由で特定の接続先にアクセスできない」を区別し、エラーに含まれるドメイン名と発生段階を記録してください。名前解決の問題をすべてプロトコルの非互換とみなすのは避けましょう。

iPhoneやiPadでの実際の動作は、Wi-Fiやモバイル通信の電波状況、ネットワークの切り替え、バックグラウンド処理、サーバー負荷にも左右されます。低レイテンシは特定のテストにおける往復時間が短いことを示すだけで、大容量データの転送速度が高いとは限りません。一度すばやく読み込めても、待機中のバッテリー消費が少ないとは言えません。プロトコルを比較するときは、同じ端末、同じ接続ネットワーク、近い時間帯、同じ接続先を使い、追加の転送層を有効にしたかも記録してください。条件がそろわないと、結果を再現しにくくなります。

このページでは各項目の役割と確認手順を説明します。サーバー側の設定案内に代わるものではありません。読み込み後にここで触れていない拡張項目が表示された場合は、変更する前に現在のサーバーで必要な項目か確認してください。転送方式の組み合わせによって利用できる項目は異なります。アプリ内に実際に表示される内容を確認してください。設定を保存するときは、関連する項目を一度に1組だけ変更し、元の値を記録しておくと、次回のテストでどの層の変更が影響したか判断できます。

02 / Shadowsocks

Shadowsocks：暗号化方式とパスワードの組み合わせ

Shadowsocksは、少ないプロトコル上のやり取りでプロキシ転送を行うことを念頭に設計され、暗号化とデータ転送を組み合わせています。端末全体を接続するためのトンネルプロトコルではなく、証明書名でユーザーを識別する仕組みでもありません。利用者が確認する基本項目は、サーバーアドレス、ポート、暗号化方式、パスワードがサーバー側の設定と一致していることです。同じ名前のサーバー項目でも値が共通とは限りません。特にサーバーのポートや認証情報が変更された後は、古い項目が残っていても使えない場合があります。

Methodでパスワードの使われ方が決まる

Methodは自由に変更できる性能設定ではありません。方式ごとに鍵導出、データのカプセル化、検証方法が定められており、クライアントとサーバーの両方が対応している必要があります。認証付き暗号化方式は、データの保護と改ざん検知を同時に行えますが、どの方式名でもすべてのサーバーで使えるわけではありません。提供された暗号化方式を正確に照合してください。同じアルゴリズム系列という理由だけで別方式に置き換えたり、「名前が長いほうが安全」と考えて自分で選んだりしないでください。

Passwordも元の値をそのまま使ってください。コピー時に空白や改行が混ざったり、見た目が似た文字を取り違えたりしがちです。プロトコルの種類によっては、鍵のエンコードや長さに決まりがあり、一般的なテキストパスワードのように再入力できません。リンクから読み込んだパスワードが長くても、構造を保ち、大文字・小文字を変えたり末尾の記号を削除したりしないでください。再確認が必要な場合は、現在お持ちの情報を管理する窓口で照合し、パスワード全体をスクリーンショットや公開の場に貼り付けないようにしましょう。

代表的なAEAD方式にはAES-GCMやChaCha20-Poly1305系列があります。処理負荷は端末のハードウェア命令、実装方法、通信の特性によって異なるため、アルゴリズム名だけでiPhoneのどの方式が常に省電力かは判断できません。連続転送ではプロセッサの効率がスループットに影響することがあります。一方、断続的なアクセスでは端末の起動回数や無線通信の稼働時間がより重要な場合があります。サーバー側で互換性のある方式が複数提供されている場合に限り、アルゴリズムを比較する意味があります。

TCPが使えてもUDPが使えるとは限らない

Shadowsocksはさまざまな種類の通信を転送できますが、UDP転送にはサーバー、クライアントの設定、現在のネットワーク環境がすべて対応している必要があります。Webページは通常TCPで接続できますが、リアルタイム通信を利用するアプリの中にはUDPが必要なものもあります。そのため、「Webページは表示できるのに別のアプリは使えない」という状況も起こり得ます。まず、その機能にUDPが必要か確認し、現在のサービスで転送が許可されているか調べてください。Webページが表示されることをUDPの確認代わりにしないでください。

接続情報に追加のプラグインや転送パラメータが含まれている場合、それらも接続設定の一部です。基本プロトコル名が同じでも、追加のカプセル化設定を削除して使えるとは限りません。一方、一般的な接続項目に、指定されていないTLS、Host、Pathを追加する必要もありません。項目を増やすと照合条件が増えるだけで、アドレスの誤り、無効なパスワード、到達できないポートが自動で直るわけではありません。

iPhoneで継続利用する価値を見極める

現在のShadowsocks接続が日常の用途で安定しているなら、名前が複雑なプロトコルに変えるだけで必ずメリットが得られるわけではありません。まず、起動直後のアクセス、連続転送、画面ロック後の復帰という3つの使い方を記録してみましょう。初回アクセスでは接続確立までの時間、連続転送では安定したスループット、復帰テストではシステムのネットワーク変化後に再接続できるかを確認します。それぞれ目的が異なるため、すべてを1つの「速度スコア」にまとめないでください。

接続に失敗したら、まずサーバー名を名前解決できるか、ポートが正しいかを確認し、次にMethodとPassword、最後にUDPや追加の転送要件を確認してください。同じネットワークで接続項目のすべての接続先にアクセスできない場合は、入口と認証を優先して確認します。特定の接続先だけに問題がある場合は、ルール、接続先の名前解決、サーバーから接続先までの経路を確認してください。暗号化方式を次々に変えるより、層ごとに原因を絞るほうが再現性のある結果につながります。

サブスクリプションから読み込んだ接続項目を管理するときは、更新と手動変更を区別してください。更新によってサービス提供元が管理する項目が上書きされたり、似た名前の項目が追加されたりする場合があります。テスト前に、確認した接続項目が実際に選択されているか確かめてください。別の項目を変更して、もう一方をテストしてしまうのを防げます。カスタム設定を長期的に使う場合は、アプリ内でその項目が更新時にどう扱われるか確認し、復元できるよう元の接続情報を保存しておきましょう。

03 / VMess · VLESS

VMessとVLESS：認証と転送方式を分けて確認

VMessとVLESSはいずれもさまざまな転送方式と組み合わせて使われますが、互換性のある別名ではありません。VMessは独自の認証とデータ保護の仕組みを持ちます。VLESSはプロトコル自体を簡素化し、安全性の確保を組み合わせるセキュリティ層に委ねる設計です。これは設計上の違いであり、単純な速度アップグレードではありません。サーバー側で使われているプロトコルに合わせて選択してください。UUIDだけ残してプロトコル名を切り替えることはできません。

UUIDは識別情報であり、設定一式ではない

UUIDは接続するユーザーの識別に使われることがありますが、正しいUUIDだけでは必要な接続情報がそろいません。Server、Port、転送方式、関連するセキュリティ設定も一致させる必要があります。読み込みに失敗した後、UUIDだけを再入力してWebSocket Pathの誤りをそのままにしても、接続結果は変わりません。別の接続項目のUUIDを試しに使うのも避けてください。ユーザーごとに権限、有効状態、接続先が異なる場合があります。

VMessの認証では時刻が関係するため、端末の時刻が大きくずれていると接続に失敗することがあります。トラブルシューティングでは、システムの日付と時刻の設定で自動設定が有効か確認し、タイムゾーンや手動設定にずれがないか調べてください。表示されているタイムゾーンが異なるだけで、必ずしもシステム時刻が間違っているとは限りません。重要なのは実際の時刻が正しいことです。時刻の問題を補うために認証関連の古い項目を何度も変更せず、まず端末とサーバーの時刻が正しくなるようにしてください。

VLESS自体はTLSと同等の転送暗号化を提供しないため、「認証に成功した」だけで接続経路が十分に保護されているとは言えません。現在のサービスで明示され、クライアントが対応しているセキュリティ設定を使用してください。TLSが指定されている場合は、サーバー名の検証と証明書チェーンを確認します。ほかの専用セキュリティパラメータがある場合は、提供情報に沿って1つずつ設定してください。アプリで空欄のまま保存できるからといって、その組み合わせが実際のネットワークに適しているとは限りません。

WebSocketのHostとPathは役割を保つ

WebSocketは、決められた接続方式でデータを転送するために使われ、接続時にHTTPリクエスト、TLS、リバースプロキシを経由する場合があります。Hostは入口でリクエスト先を識別するための情報で、Pathはサーバー側のパスを指定します。どちらも飾りの項目ではありません。Pathは大文字・小文字を区別することがあり、先頭のスラッシュやクエリ部分にも意味がある場合があります。情報をコピーするときに、独自に短くしないでください。Webページや一般的なHTTPエラーが返ってくる場合は、UUIDより先に入口のルーティングを確認しましょう。

接続情報によっては、特定のフロー制御や多重化の設定が関係する場合もあります。通常、サーバー側の実装、プロトコルの種類、転送方式の組み合わせによって条件が異なるため、別の接続項目の設定をそのまま流用しないでください。特に、Webで見つけた項目名を異なる組み合わせに追加すると、使えていた接続が動かなくなることがあります。設定する前に、アプリに該当項目が表示されることと、サーバー側が明示的に必要としていることを確認してください。項目名が新しそうかどうかは判断基準になりません。

追加のカプセル化によるコストの見方

モバイルネットワークでは、追加のハンドシェイクによって初回アクセスに時間がかかることがあります。一方、接続確立後は後続の通信によってそのコストが分散されます。転送層が通る入口や経路の長さ、サーバーの負荷も、プロトコルヘッダーのオーバーヘッドより大きく影響する場合があります。そのためVMessとVLESSを比較するときは、できる限り同じサーバー入口と転送方式を使ってください。サーバーの場所まで異なると、測定結果の差をプロトコルだけの影響とは言えず、ほかの利用者にも当てはめられません。

「プロトコルと識別情報、転送パラメータ、セキュリティパラメータ、端末の時刻」の順に確認し、同じ接続先で繰り返しテストしてください。サブスクリプション更新後に項目が変わった場合は、まず情報の更新による変更か確認してから、以前の値に戻すか検討しましょう。タイムアウトと時刻設定の具体的な確認手順は接続できないときの3ステップをご覧ください。原因を特定する前に、複数の層を同時に変更しないでください。

04 / Trojan · TLS

TrojanとTLS：まずサーバーの身元を確認

Trojanは、プロキシの認証とデータ転送をTLS接続内で行い、広く使われているセキュアな転送方式で通信を保護します。設定では、TLS接続が正しく確立することと、その後にサーバーがプロトコルのパスワードを受け入れることの両方が必要です。パスワードが正しくても証明書名の不一致は解決しません。TLSハンドシェイクに成功しても、Trojanの認証成功を意味しません。接続エラーを理解するには、この2つの段階を分けて考えることが重要です。

Server、SNI、証明書名の関係

Serverは接続先のネットワーク入口、SNIはハンドシェイクでクライアントが送るサーバー名、証明書はサーバーの身元を証明するものです。構成によっては、入口のアドレスと証明書に対応するドメイン名が異なるため、接続情報でSNIが別途指定されます。その場合は指定された対応関係を維持し、見た目を統一しようとしてすべての名前を入口アドレスに変更しないでください。証明書の検証では接続先として想定された身元を確認するため、アドレスに接続できるだけでは省略できません。

入口にIPアドレスを使う場合は、特にサーバー名の検証に注意してください。ドメイン名に対して発行された証明書が、そのIPアドレスも対象にしているとは限りません。自分で推測せず、サーバーから指定された名前を接続設定に使用してください。反対に、見慣れたドメイン名をSNIに適当に入力するのも避けましょう。その名前で入口がサービスを提供しているとは限りません。名前の誤りで認証前に接続が終了することがあり、その場合Passwordを変更しても解決しません。

証明書の検証には、証明書チェーン、有効期限、端末の信頼状態も関係します。システム時刻が大きくずれていると、有効な証明書がまだ有効でない、または期限切れと表示されることがあります。サーバーから中間証明書が正しく提供されず、端末によって結果が異なる場合もあります。トラブルシューティングでは、エラーに示された名前と検証段階を記録し、サーバー管理者に証明書の設定を確認してもらいましょう。証明書検証を常に無効にして解決するのは避けてください。サーバーの身元を確認する機能が弱まります。

PasswordとALPNの役割

Passwordはプロトコルの認証情報であり、現在のサーバー設定と完全に一致させる必要があります。TLS証明書の秘密鍵とは別物で、SNI、Host、Pathに入力するものでもありません。コピー後に文字が欠けていないか確認しつつ、入力ミスを調べるために公開の記録へ元の値を載せないでください。サポートを依頼するときは、項目を確認済みか、どの段階でエラーが発生したかだけを伝え、認証情報全体は隠してください。

ALPNはTLS内でアプリケーション層のプロトコルをネゴシエートするために使われます。構成によってはネゴシエーション結果が指定されている場合も、標準の動作を使う場合もあります。すべての接続で手動入力が必要な高速化スイッチではなく、任意のプロトコル名を追加して互換性を高めるものでもありません。接続情報にALPNが指定されている場合は、順序と内容をそのまま維持してください。指定がなく読み込み値も空欄なら、まずはそのままにし、サーバー側の要件を確認してから変更しましょう。

ハンドシェイク、バッテリー消費、接続の再利用

TLSの初回ハンドシェイクでは通信の往復と暗号処理が必要ですが、それだけでTrojanがiPhoneのバッテリーを必ず多く消費するとは言えません。接続を維持すればハンドシェイクのコストは分散され、端末の暗号アルゴリズム対応状況も処理効率に影響します。実際の消費電力は、電波が弱いときの再送、ネットワークの頻繁な切り替え、接続の繰り返しなどにも左右されます。比較では単発のアクセスと連続転送を分け、一度の起動時間だけで1日分のバッテリー消費を推測しないでください。

小さなリクエストは正常でも大きなファイルが頻繁に中断する場合は、回線品質、タイムアウト、MTUの問題を確認してください。すべてのリクエストが接続確立の段階で失敗するなら、まず入口とTLSを調べます。特定のドメインだけに問題がある場合は、Global Routing、ルール、接続先の名前解決も確認してください。セキュリティ層があるからといって、その後のあらゆる問題が証明書に関係するわけではありません。エラーが発生した段階を基に、原因を絞り込みましょう。

メンテナンス時は元の読み込み項目を残し、複製した項目で条件を絞ってテストしてください。サーバーの証明書や入口が変更された場合は、検証を無効にした項目を増やすのではなく、まず接続情報が更新されているか確認します。接続が復旧したら、不要なテスト用の複製を削除し、似た名前の項目を誤って選ばないようにしましょう。購入とシステム互換性の情報は、App Storeでの正規購入の確認方法からご確認ください。プロトコル設定で購入条件が変わることはありません。

05 / HTTP · SOCKS5

HTTPとSOCKS5：プロキシ機能と暗号化機能は別

HTTPプロキシとSOCKS5は、アプリが中間サーバーを経由して接続先のリソースにアクセスするための仕組みです。端末全体を接続するトンネルとは明確に異なります。HTTPプロキシはHTTPリクエストと接続トンネルを扱い、SOCKS5は接続先のアドレスや接続要求をより汎用的に表現します。選択時は、現在お持ちのサーバーが実際にどちらを提供しているかを確認し、安全な転送方式が用意されているかも調べてください。「プロキシ対応」と「クライアントからプロキシまでの通信が暗号化されている」は同じ意味ではありません。

HTTPプロキシのCONNECT

HTTPプロキシは通常のHTTPリクエストを処理できるほか、CONNECTリクエストで接続先までのバイト列トンネルを確立できます。接続先のWebサイトがHTTPSを使う場合、通常はクライアントと接続先の間のTLSによってWebサイトの内容が保護されます。ただし、クライアントからプロキシまでの区間も別途TLSで保護されるかどうかは別の問題です。プロキシは接続先などの情報を扱うため、Webブラウザーのアドレス欄がHTTPSであることだけでは、プロキシ入口の認証やメタデータの転送方法を判断できません。

サーバーがTLS対応のHTTPプロキシ入口を提供している場合は、クライアント側でもその入口に指定されたセキュリティ設定を選ぶ必要があります。通常のHTTPプロキシ項目をTLS必須のポートに向けたり、その逆を行ったりすると、プロトコルのネゴシエーションに失敗することがあります。ポート番号に決まった対応関係はありません。同じ番号を異なるサービスが使う場合もあります。よくある番号から推測せず、サーバーから提供された情報に従ってください。

UsernameとPasswordが必要かどうかは、プロキシサービスの認証要件によります。空欄だから認証不要とは限らず、単に読み込み情報が不完全な可能性もあります。認証エラーが出た場合は、アカウントが現在の入口用か、文字が欠けていないか、認証方式が現在の組み合わせに対応しているかを確認してください。Webサイトへのログインパスワードをプロキシ認証欄に入力しないでください。対象となるアカウントが異なります。

SOCKS5の接続とUDPの制約

SOCKS5は接続先をドメイン名またはIPアドレスで指定でき、複数のコマンドに対応しています。UDP転送では一般にUDP ASSOCIATEを使用します。ただし、仕様上の機能に対応していても、すべてのサーバーで利用できるわけではありません。どの接続ネットワークでも通るとは限りません。実際に使う前に、サーバーでUDP転送が許可されていること、クライアント設定が用途に対応していること、ファイアウォールや戻り経路に問題がないことを確認してください。SOCKS5という名称だけで、リアルタイム通信が必ず使えるとは判断できません。

SOCKS5の一般的な認証方式は、暗号化方式と同じではありません。サーバーでユーザー名とパスワードが要求されても、入口までの通信が保護されているかは別に確認する必要があります。接続先アプリのTLSは該当する通信内容を保護できますが、プロキシ入口を信頼できるかどうかの判断に代わるものではありません。既存サービスが信頼できる内部ネットワークからの接続を条件としている場合は、その条件に従ってください。内部用途のプロキシアドレスを、設計上想定されていない環境でそのまま使わないでください。

ドメイン名をどちらで解決するかは設定による

プロキシリクエストにドメイン名を含める場合もあれば、クライアントが解決したアドレスを使う場合もあります。実際の動作はアプリ、ルール、DNS設定によって異なります。そのため、内部ドメインやネットワークごとの名前解決に問題がある場合、HTTPとSOCKS5を切り替えるだけでは解決しません。まず、どのネットワーク環境でドメイン名を解決する必要があるか、解決結果がサーバー側で利用できるかを確認し、実際のリクエスト経路も調べてください。入口には接続できても内部サイトにアクセスできない場合、認証エラーではなく、名前解決やアクセス権の問題である可能性があります。

iPhoneやiPadでの速度も、環境によらず一律に決まるものではありません。ハンドシェイクが簡潔で短時間の接続にかかるコストを抑えられる場合はありますが、接続先までの距離、プロキシサーバーの性能、ネットワーク品質が引き続き使用感を左右します。利用に適しているのは、すでに使えるプロキシサービスがあり、認証やセキュリティの条件が明確で、実際の用途がサービスの機能に合っている場合です。設定項目が少ないという理由だけで、あらゆる接続の代替として使うのは適切ではありません。

確認する際は、アクセスが許可された固定の接続先を1つ選び、認証とTCP転送を確認してから、ほかの用途もテストしてください。内部リソースだけにアクセスできない場合は、現在のサービス管理者に権限、接続先の名前解決、アクセス範囲を確認しましょう。診断情報を保存するときは、状態と接続先の種類だけを記録し、アカウント全体や内部アドレスの一覧は含めないでください。プロトコル選択で決まるのはクライアントと入口の通信方法であり、もともとないリソースへのアクセス権が自動で付与されるわけではありません。

06 / WireGuard

WireGuard：鍵、アドレス、ルーティングをまとめて理解する

WireGuardは、暗号化されたIPトンネル向けのプロトコルで、簡潔な暗号スイートとピアモデルによる通信を重視しています。接続先ごとにプロキシ接続を確立するプロトコルとは異なり、サーバー入口に加えて、ローカルトンネルアドレス、鍵、ルーティング範囲も設定します。WireGuardを選ぶのは、Passwordの表記を別のものに置き換えることではありません。サーバー側で割り当てられ、互いに対応したトンネル設定一式が必要です。

Private KeyとPublic Keyの使い分け

クライアントのPrivate Keyはクライアント自身の身元を証明するために使われ、サーバー側の対応設定にはクライアントのPublic Keyが保存されます。クライアント項目に設定する対向側のPublic Keyは、サーバーを識別するためのものです。2種類の公開鍵を逆に設定すると、アドレスとポートが正しくても想定どおりのハンドシェイクは完了しません。Private Keyは機密性の高い認証情報です。公開スクリーンショット、ログの添付ファイル、問い合わせ文には載せず、再作成する前にサーバー側も合わせて変更する必要があるか確認してください。

設定によってはPreshared Keyが提供されることがあります。これは既存の鍵交換に共有の秘密情報を追加するものです。サーバー側で同じ値が設定されている場合に限って入力してください。自分で値を作っても、サーバーに自動で受け入れられるわけではありません。サーバーで要求されていない場合は、接続情報のままで構いません。鍵の長さ、エンコード、文字列にはそれぞれ意味があります。手動で削除・変更したり、見た目が似た鍵を置き換え可能なパスワードとして扱ったりしないでください。

Address、Endpoint、Allowed IPs

Addressはクライアント側に割り当てられたトンネル内アドレス、Endpointは対向側への接続に使うネットワークアドレスとポートです。前者はトンネルの内側、後者は外部からの接続先を示し、互いに代用できません。通常、複数の端末にはそれぞれ異なる識別情報とアドレスを割り当てます。同じクライアント鍵を複数の端末にコピーすると、サーバーから見た接続先が頻繁に変わり、端末同士で影響し合う可能性があります。各端末用に現在のサービスから提供された情報を使ってください。

WireGuardの仕組みでは、Allowed IPsはピアのルーティング先を選ぶと同時に、そのピアから受け入れる送信元アドレスの範囲も制限します。Webサイトのドメイン名一覧ではなく、DOMAIN-SUFFIXの構文で入力するものでもありません。ShadowrocketのGlobal Routingや設定ルールは、さらに別の層にあります。広い範囲のトンネルルートを設定しただけで、すべての通信が必ず通るわけではありません。アプリがリクエストを接続項目に渡す仕組みと、トンネルがIPパケットを処理する仕組みを分けて確認してください。

DNSオプションは名前解決の動作を指定しますが、どの種類の問い合わせに適用されるかは、クライアント全体のDNS設定にも左右されます。接続後にIPアドレスではアクセスできてもドメイン名ではアクセスできない場合は、鍵をすぐに作り直さず、DNSへの到達性とルールを確認してください。トンネル内にプライベートアドレス範囲がある場合は、現在接続中のWi-Fiネットワークとの競合も調べましょう。アドレス範囲が重複すると、リクエストが誤ったインターフェースに送られ、接続先から応答がないように見えることがあります。

MTUとPersistent Keepaliveの影響

WireGuardは通常、UDPでトンネルデータを転送します。追加のカプセル化でパケットの領域を使うため、実際の経路に合わないMTUを設定すると、小さなリクエストは通るのに大きな転送が停止することがあります。MTUは大きければ速い、小さければ安定するというものではありません。症状を確認し、再現できるテストを行ってから調整してください。まずはサーバー側で提供された設定や検証済みの値を使い、元の値を記録したうえで少しずつ確認します。DNS、ルーティング、MTUを同時に変更しないでください。

Persistent Keepaliveは、必要に応じてネットワークアドレス変換装置内のマッピングを維持するために使われます。空き時間後の到達性が改善する場合がありますが、定期的にデータを送るため、モバイル端末のネットワーク活動も増えます。すべての利用状況で設定が必要なわけではなく、間隔を短くすれば必ず安定するとも限りません。現在のサービスの要件と、放置後に接続できなくなる症状を基に判断してください。一般的な省電力や高速化の設定として扱わないでください。

WireGuardの簡潔な設計は一部の処理負荷を抑えるのに役立ちますが、モバイル端末のバッテリー消費は通信量、再送、キープアライブにも左右されます。Wi-Fiとモバイル通信を切り替えた後の接続先の変化は、ネットワーク側の方針にも関係する場合があります。トラブルシューティングでは、鍵の方向、Endpoint、トンネルアドレス、ルーティング範囲、DNSの順に確認してください。パケットサイズに関係する症状がある場合に限り、MTUを重点的にテストします。すでに利用できるプライベートネットワークへの接続が主な目的なら、カバー範囲を広げることより、サーバーで許可されているアドレス範囲を先に確認してください。

07 / Hysteria2

Hysteria2：UDP経路と帯域設定

Hysteria2はQUICなどの仕組みを基に、遅延やパケットロス、帯域の変化があるネットワークに向けた転送方法を採用しています。主にTCPを使う接続とは設計上の違いがありますが、あらゆるネットワークで速いとは限りません。まず、現在の接続ネットワークからサーバーが必要とするUDP入口に到達できることが必要です。次に認証、セキュリティ、帯域に関する設定が一致しているか確認します。入口に到達できない状態では、アプリの速度に関する期待値を変えても意味がありません。

まずUDP入口を確認し、その後に認証を調べる

ServerとPortは、すでにお持ちの接続情報に記載された実際の入口を指定してください。一般的なWeb通信は許可されていても、UDP通信が制限されているネットワークがあります。Webサイトに直接アクセスできるからといって、Hysteria2の入口に到達できるとは限りません。同じ項目がWi-Fiでは使えてモバイル通信では使えない場合は、認証設定を変えず、まずネットワーク経路を比較しましょう。ネットワークを切り替えるたびにパスワードを再生成すると、ネットワークの問題と認証の問題が混在します。

認証情報は現在のサーバーの要件に従って入力してください。追加の混淆設定が提供されている場合でも、ログイン認証とは別の層です。混淆方式、関連するパスワード、有効・無効の設定をひと組として一致させる必要があり、クライアント側のオプションだけを有効にしても使えません。必須項目のどれかが欠けると、より早い段階で接続に失敗することがあります。読み込み後に用途の異なる秘密情報の欄が2つ表示されても、管理を簡単にするために同じ値へ変更しないでください。

TLSのサーバー名と証明書を確認する原則は前述のとおりです。サーバー入口に特定のアドレスを使っていても、証明書がそのアドレスを対象にしているとは限りません。サーバー指定のSNIを維持してください。QUICがUDPを使うからといって、TLSの身元確認を省略できるわけではありません。ハンドシェイクの失敗がすべてパケットロスによるとも限りません。時刻、サーバー名、証明書チェーン、認証エラーをそれぞれ切り分けてください。「タイムアウト」という曖昧な説明より、どの段階でエラーが発生したかのほうが診断に役立ちます。

帯域の設定値は実測値や保証値ではない

Hysteria2の帯域設定は、サーバーやアプリが提供する項目に応じて、送信動作や輻輳制御の選択に影響する場合があります。上りと下りを区別し、入力する単位も確認してください。通信事業者が公表する回線速度、無線接続のリンク速度、特定の速度テストで出たピーク値をそのまま入力しても、実際に継続できる経路の帯域を示すとは限りません。実際の回線を大きく上回る値を入力すると、パケットロスや再送、揺らぎが増え、かえって応答性が低下することがあります。

上り帯域は特に見落としやすい項目です。ダウンロード中も確認応答や制御情報の送信が必要です。バックグラウンド処理で上りが占有されると、下りの容量に余裕があっても通信が遅くなることがあります。ネットワークが比較的空いているときにテストし、バックグラウンド同期が同時に行われていないか確認してください。サービスで自動調整が明示的に対応されている場合や推奨値が示されている場合は、その指示を優先しましょう。すべての場面で帯域を手動設定する必要はありません。

スループット、遅延、バッテリー消費は別々に確認する

積極的な転送方式は、状態の悪い回線でスループットを維持できることがあります。一方、継続的な送信、パケットロスからの復旧、ユーザー空間での処理にもリソースを使います。iPhoneではダウンロードが速く終わることで、無線通信の稼働時間が短くなる場合があります。ネットワークのパケットロスが続けば、再送が増えて発熱やバッテリー消費が大きくなることもあります。影響の方向はそれぞれ異なるため、プロトコル名だけで判断しないでください。タスクの完了時間、操作時の安定性、端末の状態をあわせて記録しましょう。

大きなファイルをテストするときは、最初の数秒のピーク速度だけを見ないでください。まず最後まで安定して転送できるかを確認し、転送中に通常のWebページやほかの操作に影響が出るかも確認しましょう。スループットは上がっても短いリクエストがすべて遅くなる場合は、キューの滞留や回線の占有が考えられます。テスト条件や帯域の想定を見直してください。モバイル通信では電波状況によって利用できる容量が時間とともに変化するため、固定値がすべての場所に適するとは限りません。

小さなリクエストは使えるのに大容量の通信が停止する場合は、パケットサイズ、ネットワークのパケットロス、帯域設定、サーバーのリソースを確認します。接続自体を確立できない場合は、入口とセキュリティ層に戻って調べてください。特定の接続ネットワークでのみ失敗するなら、設定を次々に変えるより、同じ項目のままネットワークを切り替えて確認するほうが有効です。最終的に使う設定は、実際の用途を安定して処理でき、情報の出所が明確で、結果を再現できる組み合わせです。一度のテストで最大の数値が出た組み合わせとは限りません。

08 / Selection · Diagnostics

選び方とトラブルシューティング：同じ条件で結果を確かめる

実際の選定は、現在利用できるサービスが対応している組み合わせから始めます。使える入口が1つだけなら、その設定を正しく行うことが目的です。すでにお持ちのサービスで複数の選択肢が提供されている場合に、プロトコルを比較できます。まず用途に必要なTCP、UDP、プライベートアドレス範囲、セキュリティ条件を満たしたうえで、接続の安定性や操作の手間を比較してください。項目を1つ減らすために必要な認証を省略したり、サーバーが対応していないカプセル化を追加したりしないでください。

用途の条件から選択肢を絞る

日常的なWebやアプリの利用では、初回接続、継続的な利用可否、ネットワーク切り替え後の復帰を確認しましょう。連続転送ではスループットと、同時に操作したときの反応を確認します。既存のプライベートネットワークに接続する場合は、アドレス割り当て、接続先のネットワーク範囲、DNSを確認してください。UDPが必要な用途では、転送機能も別途テストします。用途に応じて適切な組み合わせは異なりますが、いずれもサーバー側で提供され、利用が許可されている機能が前提です。クライアント側で不足している機能を補うことはできません。

ルールでテスト通信の経路を確認する

テスト前にGlobal RoutingでConfigが選択されていることと、変更対象の設定ファイルが有効になっていることを確認してください。以下の例はルールのマッチングを示すもので、サーバー情報は含みません。PROXYは現在の設定で有効なプロキシポリシーに対応している必要があります。より広い範囲に適用するルールより先に個別のドメインを記述し、最後にFINALで残りの通信を処理します。それ以外の通信を直接接続したい場合は、末尾のポリシーを目的に合わせて変更し、例をそのまま流用しないでください。

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

ルールは上から順に評価され、最初に一致した項目で通信の行き先が決まります。GEOIPはIPアドレスの所属範囲を判定するもので、Webサイトの表示言語から場所を推測する機能ではありません。ここに記載したドメインは構文の説明用であり、速度テストの接続先ではありません。実際の確認には、アクセス権があり結果が安定しているリソースを使い、接続ログで適用されたポリシーを確認してください。詳しい書き方はルールキーワードとマッチ範囲をご覧ください。一部のWebサイトだけを振り分ける場合は、指定サイトのルーティングガイドも参考にしてください。

エラーが発生した段階ごとに調べる

第1段階は入口の名前解決と到達性です。Server、Port、現在のネットワークを確認し、サーバー名から想定したアドレスが得られるか調べます。第2段階はセキュリティと認証です。プロトコルに応じて証明書名、端末の時刻、パスワード、UUID、鍵を確認してください。第3段階は用途とルーティングです。ルール、DNS、UDP、接続先へのアクセス権、大きなデータの転送を調べます。認証の段階に到達していないなら、識別情報を作り直す必要はありません。入口が確立しているなら、ポートだけを何度も変更しないでください。

Connectivity Testの結果は、そのテストが具体的に何を測っているかに基づいて解釈してください。特定の接続やリクエストにかかる時間を示すことがありますが、実際の用途のすべての経路を確認しているとは限らず、継続的なスループットを示すものでもありません。テストに成功してアプリが使えない場合は、実際のリクエストで使用されるドメイン、プロトコル、ポリシーを確認してください。テストに失敗しても一部の用途が正常なら、テスト対象自体に到達できるか調べます。1回の結果だけで結論を出さず、関連する複数の情報を照らし合わせましょう。

速度を比較するときは、1回につき変更する項目を1つにし、同じ端末とネットワークで、テスト時間もそろえてください。バックグラウンド同期、システムアップデート、ほかの端末による帯域使用はできるだけ避けます。初回接続か、接続確立後か、電波の弱い場所かどうかも記録してください。バッテリー消費の比較には、同じタスクを長時間、繰り返し行う必要があります。システムのバッテリー使用状況は手がかりになりますが、ネットワーク消費のすべてを特定のプロトコルに結び付けることはできません。短時間の発熱も通信量とあわせて考えてください。

確認が終わったら、日常利用に必要なGlobal Routingとルールに戻し、不要なテスト用の複製を削除します。元の情報と有効な設定の対応関係は保管してください。初回の接続手順は使い方ガイド、よくある利用上の疑問は初心者向けFAQをご覧ください。このページではプロトコル選びと各項目の意味を説明しており、サーバー管理の代わりにはなりません。また、App Storeでの購入対象も変わりません。システム要件はApp Storeのページでご確認ください。