公式マニュアル · プロトコル技術ガイド

Shadowrocket
プロトコル解説・選び方

まずサーバーの対応状況を確認し、通信方式・速度・バッテリー消費を比較します。

このページは、サブスクリプションまたはサーバー情報をすでにお持ちの方向けの技術ガイドです。プロトコルの種類や設定項目を確認できます。初めて追加・接続する場合は、まずクイックスタートの手順に沿って設定し、その後、該当する章で違いを確認してください。各項目の確認方法は、操作ガイドからも参照できます。

接続の仕組みと確認する順番

プロトコル、通信方式、セキュリティ層、ルールを切り分け、一度に複数の条件を変更しないようにします。

プロトコルの種類は速度ランクではありません

Add ServerでTypeを選ぶのは、クライアントと接続先サーバーがデータをやり取りする際の形式を指定するためで、速度のランクを選ぶ操作ではありません。サーバーが使用するプロトコルに対応したTypeを選び、合致する認証情報を入力します。同じアドレスで複数のポートが使われていても、各ポートのサービスが同じとは限りません。Shadowsocksの項目をTrojanに変更しても、サーバー側のプロトコルは切り替わりません。まず手元のサーバーがどの方式に対応しているか確認し、そのうえで利用可能な選択肢を比較してください。

接続設定には、多くの場合4種類の情報が含まれます。アドレスとポートは接続先を指定し、プロトコルと認証情報はセッションを確立し、TCP、WebSocket、UDPベースの方式などはデータを運び、TLSなどのセキュリティ層は暗号化や本人確認を担います。プロトコル自体が暗号化する場合もあれば、外部のセキュリティ層を使う場合もあります。必要な項目が少ない方式もあれば、通信経路の設定が必要な方式もあります。名前が同じでも通信方式が異なる設定は、アドレスとパスワードが一致するだけでは置き換えられません。サブスクリプションから読み込む場合も、追加情報が保持されているか確認してください。

アプリのリクエストが通る経路

iPhoneまたはiPadでShadowrocketを有効にすると、システムは該当する通信をネットワーク拡張機能に渡し、現在の設定に基づいて接続方法が決まります。Global RoutingのConfigは現在の設定ルールに従って処理し、Proxyは対象範囲のリクエストにプロキシ経路を使い、Directは直接接続します。これらはルーティング先を選択するもので、プロトコルの認証エラーを直したり、サーバーにない機能を補ったりするものではありません。リクエストがすでにDIRECTに一致している場合、接続先プロトコルを変更しても、そのリクエストの経路は通常変わりません。

DNSによる名前解決、ルール判定、クライアントからサーバーへの接続、サーバーから接続先への通信は、それぞれ異なる障害箇所です。Webページを開けない原因は、名前解決の失敗、TLSの検証エラー、認証の失敗、接続先の到達不能などが考えられます。Connectivity Testで確認できるのは指定したテストの結果であり、すべての接続先・ポートやUDPを使うアプリの正常動作までは保証しません。判断するときは「接続できた」「速度が出ない」と一括りにせず、どの段階で起きたかを記録してください。

レイヤー確認項目よくある誤解
接続先Address、Port、接続可否アドレスを解決できればポートにも接続できる
プロトコル認証Type、Password、UUIDまたは鍵ポートが同じなら認証方式も共通
通信方式とTLS通信方式、Path、SNI、証明書どのプロトコルもパスワード1つで使える
ルーティングとDNSGlobal Routing、ルールの一致、名前解決の結果すべてのリクエストが選択中の項目を通る

条件をそろえて再現性のある比較を行う

速度やバッテリー消費にはプロトコルも影響しますが、経路の距離、サーバーの負荷、無線状況、接続先のサービス、データの種類などの影響が大きい場合もあります。比較するときはデバイス、ネットワーク、接続先、テスト時間をそろえ、短いページを開くまでの待ち時間と、継続転送の安定性を確認します。遅延を一度測るだけでは、DNSキャッシュや接続再利用の差をプロトコルの優位性と誤認することがあります。大容量ファイルの最高速度だけを見ると、日常的な短時間の通信や頻繁な接続の負荷を見落としかねません。抽象的なプロトコルの順位付けより、比較条件の記録が役立ちます。

バッテリー消費を比べる際は、無線通信がアクティブな時間、バックグラウンドでの接続維持、再試行回数、転送効率に注目してください。暗号化方式が軽量でも、必ず省電力になるとは限りません。接続に失敗して再接続を繰り返す設定は、単純に見えても多くの電力を消費することがあります。Wi-Fiとモバイル通信を切り替えながら判断せず、同じネットワークで観察してください。リクエストがどの経路を選ぶか確認するには、Global Routingの3つのモードの解説も参照できます。初めて設定する場合は、クイックスタートに戻り、順番に確認してください。

Shadowsocks

設定項目は比較的少なく、暗号化方式、認証情報の形式、接続先の対応状況を一致させることが重要です。

設計の背景と主な特徴

Shadowsocksは暗号化プロキシ接続向けに設計され、一般的な設定項目はサーバーアドレス、ポート、暗号化方式、パスワードです。インターフェースアドレスやルーティング一式を設定する仮想ネットワークトンネルとは異なり、該当するリクエストをクライアントから接続先へ転送します。項目が少ないため手動で確認しやすい一方、すべての方式を互換利用できるわけではありません。プロトコルの世代、暗号化方式、拡張オプションによって互換性の条件は変わります。設定を受け取ったら、Shadowsocksという総称だけで判断せず、方式の正式名称を確認してください。

一般的なAEAD方式は、機密性を確保しながらメッセージを認証し、データの改ざんを検出します。新しいプロトコル設計では、セッション、リプレイ攻撃への対策、鍵の形式が変更されている場合があるため、どの方式にも任意のテキストパスワードを入力できるわけではありません。特定の長さや形式の鍵が必要な方式では、認証情報もその形式に合わせる必要があります。名称だけで速度や安全性を決めつけることはできません。まず接続先の実装とアプリの対応状況で選択肢が決まり、その後、デバイスとネットワークでのテスト結果をもとに判断します。

Address、Port、Method、Password

Addressにはドメイン名またはIPアドレス、Portにはサービスの待ち受けポートを入力します。どちらも同じ有効な設定情報から確認してください。ドメイン名にWebページのパスを含めたり、サブスクリプションのURL全体をサーバーアドレス欄に貼り付けたりしないでください。Methodは接続先と完全に一致させ、Passwordは元のまま入力します。コピー時に先頭・末尾の空白、改行、全角記号が混入していないかにも注意してください。サブスクリプションに似た名前の項目がある場合、表示名だけで同じものと判断しないでください。アドレス、ポート、方式を個別に照合し、別の無効な項目を変更しないようにします。

既存の設定にプラグインや追加の通信パラメータが含まれる場合もありますが、すべてのShadowsocks接続に共通して必要な項目ではありません。接続先が該当機能を明示的に使用し、現在のアプリで対応するパラメータを設定できる場合にのみ入力してください。他の人のスクリーンショットを参考に、TLS、Path、Hostを根拠なく追加しても、設定がより確実になるわけではありません。読み込み後に不明な項目があったり、情報が欠けていたりする場合は、情報の提供元に対応形式を確認してください。推測でパラメータを次々に追加するのではなく、元の設定を照合しましょう。

TCP、UDPとモバイルデバイスでの動作

Web閲覧では通常TCPが主に使われますが、UDPベースのアプリ通信が必要な場合もあります。Shadowsocksの設定でどの通信を処理できるかは、クライアント、接続先、経由するネットワークが該当する転送に対応しているかで決まります。Webページが開けてもUDP経路が正常とは限らず、リアルタイムアプリが動かないからといって、パスワードの誤りとも限りません。まず通常のページで基本接続を確認し、UDPを必要とする接続先を個別にテストして、接続先の関連ポートやネットワークのポリシーも確認してください。

iOSでは接続構成がシンプルな場合、日常的な短いリクエストが安定しやすいこともありますが、遅延やスループットは実際の経路によって変わります。継続的な通信では暗号化処理、無線状況、サーバーの送信性能がバッテリー消費に影響します。アクセスが少ない場合は、接続確立や無線の起動がより大きく影響することもあります。ネットワークが不安定でタイムアウトを繰り返すとき、暗号化方式を変えても改善するとは限りません。「接続が確立しない」のか「確立後の転送が遅い」のかを切り分けてから、接続先の到達性または転送条件を確認してください。

適した場面とトラブル対処の範囲

手元のサーバーがShadowsocksのみを提供している場合は、元の情報どおりに設定を読み込めばよく、プロトコル名だけを理由に切り替える必要はありません。同じサーバーが複数の方式に対応している場合は、項目が少なく基本的な問題を切り分けやすい設定を比較対象にできます。接続に失敗したら、まずDNS、ポート、Method、Passwordを確認し、次にUDPと追加オプションを確認します。ネットワークを変えると接続できる場合は、認証情報を何度もリセットするのではなく、ネットワーク条件を調べてください。ルーティングも別途確認し、DIRECTに一致したリクエストをShadowsocksのテスト結果と取り違えないようにしましょう。

VMessとVLESS

認証プロトコル、通信方式、セキュリティ層をそれぞれ確認してください。UUIDだけで設定が完結するわけではありません。

2つのプロトコルは異なる設計です

VMessはユーザー認証やデータ保護などの仕組みをプロトコルに組み込み、UUIDを識別情報として使うのが一般的です。一方、VLESSはプロトコル自体をよりシンプルにし、通常はデータ保護を組み合わせるセキュリティ層に委ねます。VLESS自体はVMessと同じ暗号化機能を備えていません。どちらも同じ形式のユーザー識別子を使う場合がありますが、互換性のある種類として切り替えられるわけではありません。サーバーが実際に待ち受けているプロトコルに合わせてTypeを選び、UUIDの有無だけで判断しないでください。

これらのプロトコルはTCP、WebSocket、TLSなどの設定と組み合わせて使われることが多く、プロトコルと通信方式を混同しやすい点に注意が必要です。階層を分けて考えると、UUIDはユーザー識別、通信方式はデータのやり取り、TLSは対応するセキュアな通信経路を担います。サーバーが特定の組み合わせだけを受け付ける場合、UUIDが正しくてもPathやセキュリティ層が一致しなければ接続できません。ここで挙げた組み合わせは仕組みを理解するための例です。具体的な選択肢は、アプリの現在の画面と接続先の説明を確認してください。

認証項目と時刻の条件

UUIDはそのままコピーしてください。表示名、一般的なパスワード、サブスクリプションの識別子では代用できません。サブスクリプションURLのアクセス認証情報と、個別サーバーのUUIDは用途が異なります。前者は設定の取得、後者は該当サービスへの接続に使います。VMessの古い設定には追加の認証パラメータが含まれる場合もありますが、過去の例にある数値をすべてのサーバーに適用しないでください。情報に項目が記載されている場合は一つずつ照合します。リンクのみの場合は、推測で値を追加するのではなく、読み込み時に情報が保持されているか確認してください。

VMessの認証には時刻条件が関係するため、デバイスの時刻が大きくずれていると接続に失敗することがあります。システムの日付と時刻が正しく同期されているか確認し、同じ項目で再試行してください。ただし、すべての接続エラーを時刻の問題と決めつけないようにします。VLESSは設定項目が少なくても、TLSや他の関連検証が不要になるわけではありません。どちらのプロトコルでも、ユーザー識別情報の誤り、別のサービスを指すポート、通信経路の不一致、セキュリティ層の不整合があると、すぐに切断される場合があります。待ち時間だけでは原因を確実に特定できません。

WebSocket、Host、Path、TLS

WebSocketを使う場合、Pathはサーバー側で接続を処理するパスです。先頭のスラッシュ、大文字・小文字、必要なクエリ文字列をそのまま保ってください。HostはHTTPリクエストのルーティングに使われる場合があり、TLSのSNIはハンドシェイク時の名前選択に使われます。両者が同じことも、サーバー構成によって異なることもあります。「統一する」目的で両方をAddressに変更しないでください。Addressは接続先の入口、HostとSNIはそれぞれ異なる階層の名前を示します。正しい組み合わせは接続先の構成情報で確認してください。

TLS証明書の検証では、想定するサーバー名と一致している必要があります。証明書エラーが出た場合は、検証を無効にしてエラーを隠すのではなく、SNI、デバイスの時刻、証明書の有効性、接続先アドレスを確認してください。VLESSで追加のセキュリティ機能や特定の通信方式を使う場合、アプリと接続先の双方が対応している必要があります。他の設定にある項目をそのまま流用しないでください。設定を読み込めても、すべての組み合わせで接続できるとは限らず、接続先が該当機能を有効にしているとも限りません。

速度・バッテリー消費の比較方法

WebSocketにTLSを重ねると、それに伴うハンドシェイクやカプセル化の負荷が発生しますが、日常の通信が必ず遅くなるとは限りません。接続の再利用、接続先の位置、経路の品質、サーバーの負荷によって差が小さくなったり、大きくなったりします。短いリクエストが多い場合は初回と2回目以降の表示を比べ、継続的な通信では速度が安定して保たれるか確認してください。初回のハンドシェイクと再利用中の接続をそのまま比較しないようにします。iOSのバッテリー消費も同じネットワーク条件で観察してください。設定項目の数より、接続の再試行が続いていないかが重要な場合もあります。

手元の情報にVMessとVLESSの両方がある場合、名称の新旧ではなく、設定が明確で、現在のアプリが対応し、接続先で維持管理されている方式を選んでください。トラブル対処では、設定一式を固定したうえでType、UUID、通信方式、Path、Host、TLSを順に確認し、元の情報と異なる項目を一度に一つだけ修正します。読み込み後に項目が欠けている場合は、サブスクリプションの解析とリストが空の場合の確認方法を参照し、設定取得の問題とプロトコル接続の問題を分けて対処してください。

TrojanとTLSの確認

パスワード認証だけでなく、証明書名やハンドシェイクの条件も接続の成否を左右します。

TLSを基盤とする設計の特徴

TrojanはTLS接続上にプロキシセッションを構築し、対応するパスワード認証でユーザーを識別します。外側のTLSと内側の認証を分けて考えてください。TLSはセキュアな通信路を確立し、サーバーの身元を検証します。パスワードはプロトコル層でアクセスを認証します。TLSのハンドシェイクが成功しても、パスワードが正しいとは限りません。パスワードが正しくても、証明書名の不一致は解消されません。暗号化方式だけを確認する設定に比べて、Trojanではドメイン名、証明書、接続先の対応関係を詳しく確認する必要があります。

この設計は成熟したTLSの仕組みを利用する一方で、証明書の有効期間、名前の検証、ハンドシェイクのネゴシエーションなどの条件も伴います。通常のWeb接続と同じものではなく、HTTPSに対応するアドレスならどれでもTrojanサーバーとして使えるわけではありません。接続先で該当サービスが提供され、認証が設定されている場合にのみ、クライアントはセッションを確立できます。必要なのはすでに設定済みのサーバー情報一式です。Webサイトのアドレスやよく使われるポートから設定を推測して作らないでください。

Address、Password、SNIの役割

Addressはネットワーク接続先の入口、Portはサービスのポート、Passwordは接続先の認証情報です。SNIはTLSハンドシェイクで接続先の名前を伝え、サーバーが証明書や処理経路を選ぶ際に使われることがあります。IPアドレスに接続する場合でも、ドメイン名形式のSNIが必要なことがあります。逆にAddressがドメイン名でも、元の設定で指定されている項目を省略してよいとは限りません。既存情報にSNIが明記されている場合は保持し、現在表示されているサーバー名に置き換えないでください。

証明書の検証では通常、証明書チェーンが信頼でき、有効期間内であり、検証対象の名前が証明書に含まれている必要があります。エラーが出たら、まずデバイスの時刻と名前を確認し、次にサーバー証明書が正しく設定されているか確認してください。接続先の入口が変わった場合は、クライアント側で検証を無効にするのではなく、サーバー設定の説明で関連項目を確認します。検証を省略するとサーバーの身元確認が弱まり、パスワードの誤りも直らず、想定どおりのサービスに接続できる保証もありません。

ハンドシェイク、アプリのリクエスト、UDPの範囲

TLSハンドシェイクが成功しても、確認できたのは接続経路の一部です。その後、Trojanの認証を通過し、接続先サーバーから目的のアドレスに接続して、データを返す必要があります。「ハンドシェイクは成功するのにページが読み込まれない」場合は認証と接続先への通信を確認します。「ハンドシェイク前にタイムアウトする」場合は名前解決と接続先の到達性を先に調べます。特定のサイトだけで起きる場合は、ルールの一致状況とDNSの結果も確認してください。段階を切り分けることで、すべての問題を証明書のせいにしたり、正しいパスワードを繰り返し変更したりせずに済みます。

TrojanでUDPを転送するには、クライアントとサーバーの双方が対応している必要があります。実際の動作は通信方式にも左右されます。TCPでページを開けても、リアルタイム通信にも適しているとは限りません。通信構成によっては、パケットロスによる待ち時間が目立つこともあります。単一のWebページの結果で判断せず、対象アプリの実際の通信をテストしてください。追加の通信レイヤーを使う設定は元の情報に照らして確認し、基本的なTrojanの項目一覧をすべての構成にそのまま当てはめないでください。

iOSでの速度とバッテリー消費の確認

TLSハンドシェイクには通信の往復と処理が必要なため、遠距離の経路では初回接続の待ち時間が長く感じられる場合があります。次回以降の接続で負荷が下がるかどうかは、セッションや実装によって異なります。継続的な通信では、初回のハンドシェイクより経路の品質、混雑状況、接続先の性能が重要になることが多いです。バッテリー消費を抑えるには安定した接続と再試行の削減が役立ちますが、長時間の接続維持は無線通信を増やす場合もあります。「TLSを使っている」という理由だけで電力消費が大きいと決めつけず、すべてのネットワークで他のプロトコルより優れているとも考えないでください。

手元のサーバーに安定したTrojan設定があり、証明書名、パスワード、通信方式の情報がそろっている場合は、検証可能な選択肢として使えます。比較時は接続先とネットワークを固定し、まずセッションを安定して確立できるか、次に継続的な通信とバックグラウンドでの動作を確認してください。更新後に接続できなくなった場合は、サブスクリプションに証明書関連の名前や接続先の変更が反映されているか確認します。更新方法についてはサブスクリプションの手動・自動更新ガイドを参照し、新しいパラメータを推測して補わず、設定を同期してください。

HTTPとSOCKS5

汎用プロキシのインターフェースは暗号化トンネルと同じではありません。名前解決とUDPへの対応は個別に確認してください。

汎用プロキシプロトコルの基本

HTTPプロキシは、HTTPリクエストを中継するために使われます。HTTPSの接続先を扱う場合は、通常CONNECTを使って指定先までのバイト通信路を確立します。SOCKS5は、より汎用的なプロキシネゴシエーションを提供し、Webに限らず接続先のアドレスとポートを指定できます。これらのプロトコルは、既存の社内ネットワークや管理されたプロキシの接続先で使われることがあります。設定項目がシンプルでも、安全性と利用可能な機能は実際の構成で確認が必要です。「プロキシに対応」というだけで暗号化されるとは限りません。

通常のHTTPプロキシとHTTPSプロキシは区別してください。前者はクライアントからプロキシまでの基本プロトコルを指し、後者はその区間でTLSを使用します。接続先がHTTPSサイトでも、クライアントとHTTPプロキシ間のネゴシエーション情報まで同じように保護されるわけではありません。SOCKS5の基本プロトコルも、通信全体を暗号化する機能は備えていません。利用中のネットワークで機密性が必要な場合は、接続先にセキュリティ層があるか確認してください。URLがHTTPSで始まることだけで判断しないようにしましょう。

ユーザー名、パスワード、接続先の範囲

AddressとPortは実際のプロキシ接続先を指定します。UsernameとPasswordは、接続先が認証を求める場合にのみ入力してください。認証情報を空欄にする場合と誤った情報を入力する場合では結果が異なることがあります。任意のアカウント情報をプロキシのパスワードとして使うことはできません。HTTPプロキシではCONNECTで許可されるポートや接続先に制限がある場合があります。特定のページが開けても、メール、リアルタイム通信、他のポートが使えるとは限りません。トラブル対処の前に、既存のプロキシで許可されている範囲を確認し、ポリシーによる制限をクライアントの問題と誤認しないようにします。

SOCKS5は複数の認証方式をネゴシエーションできますが、クライアントとサーバーが同じ方式に対応している必要があります。読み込み時には、ポート番号だけで判断せず、TypeがSOCKS5として認識されているか確認してください。よく使われるポート番号は慣例にすぎず、実際のサービスは別のポートを使うことがあります。同じ一般的なポートで別のサービスが動いている場合もあります。接続を拒否されたら、まずアドレスと待ち受け状態を確認します。認証に失敗する場合は該当するアカウントを確認し、ポート、種類、パスワードを同時に変更して、原因を再現できなくしないでください。

項目HTTPSOCKS5
主な仕組みHTTPリクエストの転送またはCONNECT汎用プロキシのネゴシエーションと接続先への接続
基本プロトコルの暗号化通常のHTTP自体はTLSを提供しない基本プロトコル自体は暗号化を提供しない
UDP通常のCONNECTを汎用UDP転送として扱うことはできないUDP ASSOCIATEが定義されているが、双方の対応が必要
接続先の制限CONNECTで利用できるポートや接続先が制限される場合がある認証、アドレスのポリシー、転送機能による制限を受ける場合がある

DNSの名前解決が行われる側

プロキシのネゴシエーションでは、ドメイン名を送る場合と、すでに解決したIPアドレスを送る場合があります。これにより、どちら側で名前解決するかが変わります。実際の動作はクライアント設定、ルールの要件、プロトコルの使い方によって異なります。SOCKS5を選んだだけでDNSが必ず接続先で解決されるとは限りません。IPルールとの照合が必要な設定では、ローカルで名前解決が行われることもあります。診断時は、ドメインが解決できるか、結果が妥当か、プロキシ側から接続先に到達できるかを個別に確認してください。DNSアドレスだけを変えてすべての問題が解決すると考えないようにしましょう。

SOCKS5ではUDP ASSOCIATEが定義されていますが、接続先で無効になっていたり、ネットワークで応答経路が許可されていなかったり、クライアントがその機能を使っていなかったりする場合があります。HTTPプロキシの通常のCONNECTを汎用UDP転送として扱うことはできません。Webページは開けてもリアルタイムアプリが使えない場合は、そのアプリがUDPを必要とするか、接続先が対応機能を提供しているかを確認してください。転送機能が不足している問題に対し、ユーザー名を何度も変更しないでください。両者は異なる層の問題です。

速度・バッテリー消費と利用範囲

カプセル化が少なければ一部の処理負荷を抑えられる場合がありますが、経路の混雑、認証の待ち時間、接続先の制限は解消されません。iOSで短時間だけテストすると、キャッシュや接続先の違いによって相反する結果が出ることがあります。接続先を固定し、接続確立とデータ転送を別々に記録してください。HTTPやSOCKS5の接続先は、明確に対応している用途で使用します。あらゆるトンネルプロトコルの代わりになると考えないでください。名前解決も確認する場合は、DNSとDNS over HTTPSの設定ガイドを参照し、現在のルールと照らし合わせてリクエストの経路を確認してください。

WireGuard

鍵と仮想ネットワークアドレスを使うトンネルです。一般的なプロキシのパスワードの考え方をそのまま当てはめないでください。

トンネルプロトコルとプロキシ項目の違い

WireGuardは構成をシンプルにした暗号化ネットワークトンネルを構築するために設計され、固定の暗号方式を使い、公開鍵で接続先を識別します。ネットワーク層のパケットを扱うため、設定にはインターフェースアドレス、接続先の鍵、ルーティング範囲などが含まれ、プロキシのパスワードだけでは構成できません。Shadowrocketで該当項目を使う場合は、クライアントによる通信の取り込みやルールの仕組みも踏まえてください。独立したトンネル設定の項目を、確認せずにアプリ内の項目と同じ意味だと考えないようにしましょう。

ユーザー名やUUIDを使うプロトコルとは異なり、WireGuardではローカル側の秘密鍵と接続先の公開鍵が正しく対応している必要があります。接続先もローカル側の公開鍵を認識し、適切なアドレスと到達範囲を設定していなければなりません。Endpointだけ、または接続先の公開鍵だけでは、完全な接続設定になりません。設定ファイルを受け取った場合は、まずInterfaceとPeerがそれぞれどちら側を示しているか確認し、現在のアプリが対応する方法で読み込みます。項目ごとに照合できるよう、元のファイルも保管してください。

鍵、Endpoint、アドレスの項目

PrivateKeyは自分側の秘密情報です。公開スクリーンショットや問い合わせ本文に掲載しないでください。通常、PeerのPublicKeyは接続先の公開鍵を指し、両者を取り違えてはいけません。設定によっては追加の共有秘密情報であるPresharedKeyも含まれ、双方で一致させる必要があります。形式の例が実際の認証情報と誤認されないよう、ここでは鍵の例を掲載しません。問題を相談するときは、項目があるか、読み込み時にエラーが出たか、エラーの種類を伝えれば十分です。実際の鍵を提出する必要はありません。

Endpointは接続先のアドレスとUDPポートを示します。一方、Addressは通常、トンネル内でローカル側に割り当てられたアドレスを示します。両者は異なるアドレス空間で別々の役割を担います。DNSは名前解決の設定、AllowedIPsはWireGuardにおいて接続先が処理できるアドレス範囲とルーティングの選択に関係します。接続先が特定の内部ネットワークしか許可していない場合、クライアント側で範囲をすべてのアドレスに広げても転送機能は増えません。サーバー側のルーティング、転送、応答経路も正しく設定されている必要があります。

UDP、Keepalive、モバイルネットワーク

WireGuardは通常UDPで通信するため、クライアントとEndpointの該当ポート間でデータを送受信できるネットワークが必要です。Wi-Fiでは動くのにモバイル通信で失敗する場合は、鍵の失効だけでなく、UDP経路、アドレスの変更、ネットワークのアドレス変換が関係している可能性があります。まず有効なハンドシェイクがあるかを確認し、次に実際の通信ができるか調べてください。ハンドシェイクが成功しても、DNS、接続先へのルート、応答経路が正しいとは限りません。内部ネットワークに接続する場合は、そのネットワークと現在のローカルネットワークのアドレス範囲が重複していないかも確認してください。

PersistentKeepaliveは必要に応じてネットワークのマッピングを維持するための設定ですが、値を小さくすれば安定するとは限りません。頻繁にパケットを送ると無線通信が増え、バッテリー消費が大きくなる場合があります。不要な状況で有効にしても効果があるとは限りません。設定するかどうか、値をどうするかは、既存の構成要件と実際にアイドル時の接続が切れるかどうかを基に判断し、どの場面にも同じ値を当てはめないでください。モバイルデバイスでは、画面ロック中、ネットワークの切り替え後、スリープからの復帰後の動作も個別に確認します。画面を点灯した状態で一度成功しただけでは、バックグラウンドで安定するとは判断できません。

MTUと適用範囲

MTUは関連するインターフェースが扱えるデータパケットのサイズを示します。カプセル化後のパケットが経路の許容サイズを超え、必要な通知も正しく届かない場合、ハンドシェイクや小さなリクエストは成功するのに、大きな応答が止まることがあります。ただし、これは調査項目の一つです。速度の問題が起きるたびに、最初にMTUを変更しないでください。まず経路、DNS、ルーティングを確認し、接続先の説明に沿って必要な範囲で調整し、元の値を記録します。小さくしすぎるとパケットの分割や数が増え、大きくしすぎると元の問題が残ることがあります。

管理対象の内部ネットワークへの接続が目的で、管理者からWireGuardの設定一式が提供されている場合、アドレスと接続先を表す仕組みがこの用途に適しています。一般的なプロキシ用途では、接続先が実際に必要な転送を担っているか確認してください。内部ネットワークへのトンネルが設定されているだけでは、プロキシとして使えるとは限りません。速度とバッテリー消費は、無線状況、パケットサイズ、Keepalive、通信量によって変わります。ハンドシェイク、ルーティング、DNS、接続先からの応答がすべて正しく機能することを確認し、設定にトンネル名があるだけで判断しないでください。

Hysteria2

QUICベースの通信には利用可能なUDP経路が必要です。帯域幅の設定は実際の通信環境に合わせてください。

不安定な経路を想定した設計

Hysteria2はQUICベースの通信方式を使い、高遅延やパケットロスがある環境でのデータ転送を考慮した設計です。QUICはUDP上で動作しますが、信頼性のあるストリーム通信を提供できます。そのため、下位層にUDPを使うことは、すべてのアプリのデータが保証なく失われるという意味ではありません。一方で、不安定なネットワークなら必ず速くなるわけでもありません。UDPが使えない、厳しく速度を制限される、接続先の負荷が高いといった状況は、プロトコル設計だけでは解消できません。選ぶ前に、手元のサーバーがHysteria2に対応していることを確認してください。

Hysteria2は、名前が似ている旧世代のプロトコルと表示名だけで互換性を判断できません。読み込み形式と認証項目も、現在のアプリに照らして確認してください。設定によっては難読化やその他の拡張パラメータを使いますが、接続先が同じ機能を有効にしている場合にのみ入力します。追加オプションは、どの環境でも使える性能向上スイッチではありません。片側だけで追加すると通信条件が変わり、接続できなくなる可能性があります。項目を保存できても、接続先がその組み合わせを受け入れるとは限りません。セッション全体を通して確認してください。

認証、TLS、サーバー名

基本項目としてAddress、Port、認証情報、TLS関連の名前を確認します。認証情報は同じ設定一式から取得してください。サブスクリプションURLの認証情報で代用することはできません。読み込みツールが各情報を別の項目に分けている場合は、すべて正しく解析されたか確認してください。QUICに変更しても、SNIと証明書名の対応は重要です。デバイスの時刻が不正確、想定する名前と証明書が一致しない、証明書の設定に誤りがあるなどの理由で、認証の前後に接続が中断することがあります。

接続先の設定で特定の難読化方式とパスワードが指定されている場合は、元の情報を保ち、現在のアプリがその項目に対応しているか確認してください。通信できないからといって、難読化方式を片端から試さないでください。元の問題に新たな問題が加わります。ポートを変更する場合も、接続先がそのポートで実際に待ち受けている必要があります。クライアント側だけで新しい接続先を作ることはできません。情報の出所は明確でも項目の説明が不十分な場合は、性能を比較する前に説明を確認し、設定に誤りのある項目をテスト対象に含めないようにしてください。

帯域幅の設定は速度測定の結果ではありません

設定によっては、上り・下りの帯域幅や輻輳制御に関する項目があります。これらは送信方法や想定する通信環境を示すもので、実際の速度を保証する値でも、大きければよいという値でもありません。持続可能な能力を超える値は、輻輳、パケットロス、通信の変動を増やす場合があります。低すぎる値は利用可能なスループットを制限することがあります。画面に自動ネゴシエーションや初期設定の動作がある場合は、まず接続先の説明に従ってください。再現性のある問題が確認でき、該当パラメータを理解している場合に限り、変更内容を記録して調整しましょう。

モバイル通信で使える帯域幅は、電波状況、場所、基地局の混雑によって変わります。短時間の速度測定で得たピーク値が、長期利用に適した設定とは限りません。Wi-Fiの公称リンク速度も、サーバーまでの実効帯域幅と同じではありません。比較時は一瞬の最高値ではなく、継続通信中に安定する範囲を確認してください。確認や制御の通信にも経路のリソースが必要なため、上りの帯域幅も無視できません。帯域幅の設定変更後にバッテリー消費や通信の変動が増えた場合は、元の値に戻して条件を再確認してください。

iOSでの性能確認と障害の切り分け

パケットロスがある経路では、適切な通信方式や輻輳制御によって継続通信が改善することがありますが、実際の効果は両端の実装とネットワーク環境によって異なります。積極的に通信を行うと、無線通信、処理負荷、バッテリー消費が増える可能性もあります。高スループットが省電力を意味するわけではありません。短いページの表示待ち時間、長時間の通信の安定性、アイドル状態からの再接続を分けて観察し、同じ時間帯に他の利用可能な設定と比較してください。遅延を一度測るだけでは、QUICセッション全体の動作は判断できません。

特定のネットワークだけで失敗する場合は、設定項目を変えずに、利用可能な別のネットワークへ切り替えてUDP経路との関係を確認してください。どのネットワークでも失敗する場合は、アドレス、ポート、認証、証明書、追加パラメータを順に確認します。通常のページは開けても特定のリアルタイムアプリが失敗する場合は、アプリの通信を転送できるかと、下位層のQUICが確立しているかを切り分けてください。Hysteria2は、手元で利用可能な選択肢の一つとしてテストするものであり、どの接続も無条件に改善する万能な解決策ではありません。

利用場面に応じた選択と段階的なトラブル対処

手元の利用可能な条件から始め、一貫した確認手順で原因を絞り込みます。

確認可能な条件に基づいて選択肢を絞る

日常的なWeb閲覧やアプリ利用では、設定がそろい安定してセッションを確立できる既存の設定を優先し、初回の応答と継続通信を比較します。内部ネットワークへの接続では、WireGuardのアドレス、ルーティング、接続先の許可範囲を確認してください。UDPが必要な通信では、プロトコル、接続先、現在のネットワークがすべて該当する転送に対応している必要があります。不安定なネットワークではHysteria2などの利用可能な選択肢を試せますが、接続先の到達性確認を省略しないでください。選択は、プロトコル名を基準に統一するのではなく、接続先が実際に提供している機能の範囲内で行います。

バッテリー消費を抑えたい場合は、実際の使用時間を通して、アイドル時の接続、バックグラウンドでの再試行、ネットワーク切り替え後の動作を確認してください。On Demandは接続を開始するタイミングを制御し、ルールは通信経路を決めます。プロトコル選択と関係しますが、同じ問題ではありません。必要なリクエストが適切な経路を通り、接続が安定して維持される場合に初めて、プロトコルごとの負荷を比較する意味があります。接続失敗の再試行が続く場合は、まず失敗の原因を解決してください。設定項目が少ないプロトコルに変えても、同じネットワーク問題が残ることがあります。

利用場面まず確認する項目比較するポイント
短いページと日常的なアプリ認証、DNS、ルールの一致初回と2回目以降の応答、再接続
長時間の継続通信接続先の負荷と持続可能な通信品質安定したスループット、変動、デバイスの発熱
リアルタイム通信UDP転送と双方向の到達性遅延の変動、パケットロス、復旧時間
特定の内部ネットワークアドレス、ルーティング、応答経路接続先への到達性、ネットワーク範囲の重複、DNS

まずリクエストがテスト対象の設定を通っているか確認

Configではルールの優先順によってリクエストの一致先が決まります。以下はShadowrocketの.confルールの一部を示す例で、設定全体ではありません。ドメインのサフィックスをPROXYに、記載されたプライベートネットワークをDIRECTに振り分け、それ以外はFINALで最終的な処理を指定しています。実際に使う前に、現在の設定で参照先のポリシーが利用できることと、FINALの影響を確認してください。特定のドメインをテストするために元の設定全体を上書きしないでください。まず現在の設定を保存し、変更範囲を最小限にして確認します。

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

同じリクエストがDirectでは正常でProxyでは失敗する場合、接続先サーバーへの通信を調べます。ただし、ネットワーク全体の最終診断にはなりません。経路によって名前解決の結果や接続先の入口が異なることがあります。Configでは失敗しProxyでは正常な場合は、ルールとDNSの関連を優先して確認してください。Home、Config、Data、Settingsの場所は画面上の英語表記ガイドで確認できます。画面の場所を取り違え、実際には存在しないプロトコル設定を探さないようにしましょう。

失敗した段階ごとに必要最小限の記録を残す

まずサブスクリプションを取得できたか、項目がそろっているかを確認します。次にアドレスを解決できるか、ポートに接続できるかを調べます。その後、Type、認証、通信方式を確認し、次にTLSと名前を確認します。接続先へのアクセスやアプリの通信機能を調べるのは最後です。リストが空の場合は、まだプロトコルの接続段階に達していません。サブスクリプションの取得または解析を先に確認してください。ハンドシェイクが成功しても接続先から応答がない場合は、同じサブスクリプションを何度も読み込み直すのではなく、サーバーから接続先までの経路、接続先の制限、応答データを調べます。

デバイスが使用していたネットワークの種類、エラー発生時のGlobal Routing、選択したプロトコル、サブスクリプションを直近で更新したか、再現可能なエラーの段階を記録してください。エラーの種類と、機密情報を除いた項目名は記録できますが、実際のパスワードや鍵、サブスクリプションURL全体は含めないでください。各試行で変更するのは明確な差異がある項目一つだけにして、変更前の値も記録します。効果がなければ元に戻して、次の層を確認してください。ネットワークを比較するときはサーバー設定を固定し、設定項目を比較するときはネットワークと接続先を固定すると、他の条件による影響を減らせます。

設定変更をやめて基本確認に戻るタイミング

同じネットワークですべてのプロトコルが失敗する場合は、まずデバイスのネットワーク、DNS、システムの許可設定を確認してください。一つの項目だけ失敗する場合は、その認証情報と接続先の状態を優先して確認します。特定の接続先だけで失敗する場合は、ルールと接続先そのものを調べてください。すべての障害をプロトコル選びの問題にしないようにします。よくある疑問はよくある質問を、初めて接続する場合はクイックスタートを参照し、アクセス許可とスイッチの状態を確認してください。アプリの入手、購入、互換性についてはダウンロードと対応状況の確認で案内しています。価格とシステム要件はApp Storeの製品ページをご確認ください。