Shadowrocket プロトコルガイド

プロトコル選びで確認する4つの層

プロトコル・転送・暗号化・ルーティングを区別する

Shadowrocketでプロトコルを選ぶことは、既存のサーバーとの通信方式を指定することであり、接続に速度ランクを付けることではありません。通信には少なくとも4つの層があります。プロトコルはリクエストと認証の形式、転送方式はデータの送り方、暗号化は通信中のデータの保護、ルーティングはどのリクエストをその経路に流すかを決めます。各層は関連していますが、互いに置き換えることはできません。正しいプロトコルを選んだ後も、サーバーアドレス、ポート、認証情報、転送設定を個別に一致させる必要があります。名称が同じだけでは、通信できるとは限りません。

たとえば、VLESSはリクエストと認証の形式、WebSocketはデータを運ぶ方式、TLSは該当する接続の暗号化と相手の認証を担い、DOMAIN-SUFFIXは特定のドメインにどのプロキシポリシーを適用するかを決めます。同じプロトコルでも異なる転送方式を組み合わせられ、同じ転送方式で複数のプロトコルを運べる場合があります。設定はサーバーから提供された一式を単位として扱ってください。ある設定の認証情報と別の設定の転送方式を組み合わせてはいけません。読み込み後に異なる名称が表示された場合は、まずそれぞれがどの層を示すのか確認しましょう。

比較する利用目的を明確にする

ウェブ閲覧では短いリクエストが多く、接続開始までの時間や名前解決、接続の再利用が体感速度に影響します。大容量ファイルの転送では、継続的なスループットや輻輳制御、サーバー側の帯域制限が表れやすくなります。音声通話やインタラクティブなアプリでは、遅延の変動、パケットロス、UDPの利用可否が重要です。そのため「ページの表示が速い」と「データを継続して速く転送できる」は別の評価です。1回のダウンロード結果をすべてのアプリに当てはめると、その後のトラブル対処を誤ることがあります。先に目的を決め、それに合ったテストを行いましょう。

iPhoneやiPadでは、利用時間帯とネットワーク環境も記録してください。Wi-Fiに接続したままの利用と、移動中のモバイル通信では、IPアドレスの変化、無線の再送、バックグラウンド処理の条件が異なる場合があります。プロトコルのカプセル化、暗号化、キープアライブには処理コストがかかりますが、画面の明るさ、電波強度、通信量もバッテリー消費に大きく影響します。条件をそろえない比較から分かるのは、あくまでそのときの結果です。プロトコルごとの消費電力を固定的に順位付けしたり、新しい名称のプロトコルほど省電力だと判断したりすることはできません。

元に戻せる手順で選ぶ

プロトコル選びは、まず利用中のサーバーが対応している方式に左右されます。設定が1つだけなら、提供された情報に沿って種類を選び、比較のためだけにプロトコルを書き換える必要はありません。利用できる設定が複数ある場合は、各設定で個別に接続できることを確認してから、同じ目的に対する初回アクセス、再アクセス、継続利用を比較します。元の設定を複製し、1回のテストで変更する項目は1つだけにして、そのときのネットワークも記録してください。調整して改善しなくても、確認済みの状態に戻せます。変更を重ねて基準を見失うことも防げます。

最後に、維持管理の手間も考慮しましょう。設定項目が多い接続では、情報をより詳しく保存する必要があります。証明書、ドメイン、転送経路にも、それぞれ変更時期がある場合があります。一時的に速くても、設定情報の出所が不明確な構成は長期利用に向かないことがあります。情報がそろっていて、用途に合い、動作を確認しやすい設定を優先してください。このガイドは方式ごとの違いと適用範囲を説明するもので、サーバー設定の代わりにはなりません。特定のプロトコルがあらゆるネットワークで最適だと示すものでもありません。

Shadowsocks、HTTP、SOCKS5

Shadowsocks：シンプルな暗号化プロキシ

Shadowsocksは、比較的シンプルなプロトコルでプロキシ通信を行い、合意された暗号化方式と鍵情報を使って通信します。複雑な転送方式の組み合わせのように、複数層の経路設定が常に必要なわけではありません。ただし、すべての設定を相互に流用できるという意味ではありません。暗号化方式によって必要な鍵情報やデータ処理が異なり、サーバー側の対応状況も異なる場合があります。利用する際は、提供された情報の方式がクライアントの選択肢と一致することを確認し、サーバー、ポート、認証情報も照合してください。

パスワードと暗号化方式はセットで確認してください。通常のパスワード文字列を使う設定もあれば、鍵のエンコードや長さに決まりがある方式もあります。エンコード済みの情報を通常のパスワードとして扱ったり、「より強そう」という理由だけで暗号化方式を変えたりすると、認証に失敗することがあります。サブスクリプションから読み込んだ設定は、まず読み込み値をそのまま使ってください。手動で追加する場合は、提供された情報を項目ごとに入力し、記載のない設定を独自に追加しないでください。追加の転送方式が含まれる場合は、その設定も個別に確認します。サーバーが既定で対応しているとは限りません。

iOSでの利用では、カプセル化の層が少ないほど追加の処理を抑えやすくなりますが、実際の速度はサーバーのリソース、通信品質、接続先サイトにも左右されます。最新のデバイスでは暗号化処理だけがボトルネックとは限らず、アルゴリズム名だけでバッテリー消費を判断することはできません。継続的な通信中にだけ端末が熱くなる場合は、同程度の通信量で比較してください。通信していないときにも電力消費が大きい場合は、再接続、電波状況、キープアライブを確認し、すぐに暗号化方式を変更しないでください。設定の誤りは、長く待っても通常解消しません。

HTTP：プロキシへの接続と接続先への通信を区別する

HTTPプロキシは、ウェブリクエストの転送を目的として使われてきました。通常のHTTPリクエストを転送するほか、CONNECTを使って対象へのトンネルを確立できます。ここでは、デバイスからプロキシサーバーまでと、プロキシサーバーから接続先サイトまでの2つの区間を区別してください。接続先のウェブサイトがHTTPSでも、デバイスからHTTPプロキシまでの区間にTLSが使われているとは限りません。サーバーが暗号化されたプロキシ接続を明示している場合は、提供された情報に従って接続方式を設定してください。接続先URLがHTTPSで始まるという理由だけで、通信経路全体の性質を判断しないでください。

HTTPプロキシでよく使う項目は、アドレス、ポート、必要に応じてユーザー名とパスワードです。認証方式はサーバー設定によって異なり、認証情報が空の場合と誤っている場合で結果が変わることもあります。CONNECTで接続できるポートはサーバーのポリシー次第です。通常のウェブページにはアクセスできても特定のサービスにつながらない場合、クライアントのプロトコル実装が原因とは限りません。まず接続可能なことが分かっている宛先を使い、対象サービスで実際に使われるポートと転送方式を確認してください。アクセス制限を速度不足と取り違えないようにしましょう。

SOCKS5：汎用転送でも暗号化が標準とは限らない

SOCKS5は幅広い接続の転送を目的としており、認証のネゴシエーション、接続リクエスト、UDPアソシエーションなどの仕組みを定義しています。プロトコル自体に、通信経路全体を暗号化する一般的な機能はありません。ユーザー名とパスワードを設定しても、データが暗号化された経路で送られるとは限りません。信頼できる既存ネットワーク、または別途用意された安全な転送方式と組み合わせて利用できます。選ぶ前に、サーバーのアクセス範囲と通信の保護方法を確認してください。設定項目の数だけでSOCKS5と暗号化機能を備えたプロトコルを同等だと考えてはいけません。

SOCKS5でUDPを利用するには、クライアントとサーバーの双方が対応し、サーバー側で許可され、中間ネットワークから到達できる必要があります。TCPで接続できても、UDPアソシエーションが正常だとは限りません。ウェブは使えてもリアルタイム通信に失敗する場合は、その通信経路を個別に確認してください。ドメイン名をどちら側で解決するかによっても、結果やアクセス方法が変わります。サーバーアドレス欄だけを見て判断しないでください。設定を管理する際は、認証、名前解決、UDP関連の元の情報を残し、実際の用途に沿って順番に確認すると、設定を手当たり次第に切り替えるより原因を特定しやすくなります。

VMessとVLESSの設計上の違い

VMess：認証とプロトコル設定をまとめて確認

VMessにはユーザー認証とプロトコル層のデータ処理機能があり、UUIDでユーザー情報を識別するのが一般的です。ほかの転送方式と組み合わせて使われることが多く、1つの設定にUUID、プロトコルのセキュリティ設定、転送方式、外側のTLS設定が含まれる場合があります。UUIDがあっても接続設定が完了したとは限りません。アドレスとポートは接続先を、認証情報はサーバーが接続を許可するかどうかを、外側の設定は実際のサービスにリクエストを届ける方法を決めます。どれか1つでも一致しなければ、タイムアウトや接続切断として表れることがあります。

手動で確認する場合は、まずUUIDが完全かを調べます。コピー時に空白や改行が入っていないか、文字が欠けていないかも確認してください。次にサーバーが指定するセキュリティ設定を確認し、最後に転送方式の項目を見ます。以前の設定には追加項目が含まれる場合があります。別の設定値を流用せず、現在利用するサーバーの明確な説明に従ってください。認証に時刻が関係する場合は、デバイスの時刻が大きくずれていても接続に影響することがあります。認証情報を更新する前に、正確な時刻に設定してください。

VLESS：シンプルなプロトコルでも安全性の確認は必要

VLESSは、比較的シンプルな認証とリクエストのカプセル化を重視し、通常はUUIDを使います。プロトコル自体が汎用的なデータ暗号化層を提供することを主眼としていません。実際の接続では、組み合わせるセキュリティ機能や転送方式も含めて考える必要があります。「設定項目が少ない」ことは、接続先の本人確認を省いてよいという意味ではありません。UUIDは認証情報であり、証明書の検証に代わるものではありません。転送方式、TLS設定、サーバー指定のその他の項目も、完全な接続設定の一部として保存してください。

既存の設定によっては、特定のストリーム処理オプションが指定されている場合があります。この項目はサーバー側の処理方法や対応する転送方式に関係するもので、速度を上げる汎用スイッチではありません。情報に記載がなければ、別の設定例を参考にして値を追加しないでください。指定されていても、クライアントの選択肢と一致しない場合は、似た名前の値に置き換えてはいけません。誤った組み合わせを試す前に、アプリの対応状況とサーバーの条件を確認しましょう。

WebSocketなどの転送方式は関連項目をまとめて確認する

WebSocketでは、リクエストパスとHostが主な確認項目です。パスがサーバー側の振り分けに使われることがあり、大文字と小文字、先頭のスラッシュ、その他の部分にも意味がある場合があります。任意に削除しないでください。Hostは該当リクエストのルーティングに使われますが、実際の接続先アドレスやTLSのServer Nameと同じとは限りません。サーバーが層ごとにリクエストを振り分ける場合、値ごとに役割があります。すべてのドメインを1つのアドレスに置き換えると、正しい設定を壊すことがあります。

別の転送方式を使う場合も、その方式に応じた項目を確認してください。サービス名を使う場合、パスと同じテキスト項目だからといって相互に置き換えられるわけではありません。外側の接続は確立しているのにリクエストが失敗する場合、入口には届いていても正しいバックエンドに転送されていない可能性があります。その場合はUUIDを作り直すのではなく、転送設定とサーバー側の振り分け条件を合わせて確認してください。認証情報を変えても、パスの誤りは直りません。その逆も同様です。

iPhoneで実際の負荷を比較する方法

VMessとVLESSの体感差は、組み合わせる転送方式やサーバーから切り離して評価できません。TLSハンドシェイク、接続の再利用、追加のカプセル化、サーバー負荷のほうが、プロトコル形式自体より初回アクセスに影響する場合があります。一方がシンプルな接続で、もう一方に追加の転送層がある場合、速度差のすべてをプロトコル名に帰属させることはできません。比較時はネットワーク、接続先、転送条件、テスト時刻をできるだけそろえ、初回接続と後続リクエストを分けて記録してください。

長期利用では、接続直後だけでなくネットワーク切り替え後の復旧も確認してください。Wi-Fiからモバイル通信に切り替えると、既存の接続を確立し直す必要が生じる場合があります。実際の挙動は転送方式とシステムの処理に左右されます。切り替え時だけ失敗する場合は、いったん切断して再接続すると復旧するか、また、どのサービスに影響するかを記録してください。この結果から、接続維持の問題と固定的な設定ミスを区別しやすくなります。再現できるネットワーク条件を、プロトコルが常に利用できないという問題と取り違えないでください。

TrojanとTLSの設定確認

Trojanの外側を保護する接続

TrojanはTLS接続の内側でプロキシリクエストと認証を行い、実績のある安全な転送方式で通信します。利用するには、パスワード、サーバーアドレス、TLSによる相手の確認がすべて正しく設定されている必要があります。いずれか1つを選べばよいわけではありません。パスワードが正しくても、サーバー名が一致しない、信頼されない証明書が返される、ポートが違うといった場合は、正しい接続になりません。トラブル対処は外側の接続から内側の認証へ順に進めてください。

TLSは暗号化だけでなく、証明書チェーンと名前の照合によって接続先の本人確認も行います。ハンドシェイクの失敗は、通信データが正常に転送される前に起きます。そのため「ウェブページが開かない」という結果だけでは、パスワードの誤りとは判断できません。まず接続先に到達できるか確認し、次に証明書に関する条件を調べます。安全な接続が確立してから、内側の認証と接続先へのリクエストを確認してください。この順序で進めれば、複数の項目を同時に変更して作業を繰り返す事態を減らせます。

接続先アドレス、Server Name、Host

サーバーアドレスは「どこにネットワーク接続するか」を示します。一方、Server NameはTLSハンドシェイクのサーバー名表示や、接続先の確認に使われます。項目名は利用中の画面をご確認ください。既存の設定では、あるアドレスに接続しつつ、別途指定されたドメイン名で本人確認を行うことがあります。見た目だけを理由に修正してはいけません。Server Nameを接続先アドレスに変更すると証明書が一致しなくなる場合があります。アドレスだけを変更してサーバーの入口を確認しないと、別のサービスに接続する可能性もあります。

Hostは該当するアプリケーション層のリクエストで使われ、Server Nameとは役割が異なります。その項目を使う転送方式の場合に限り、提供された情報に従って設定してください。項目のない接続に独自の意味を加える必要はありません。複数のドメインが記載された設定では、各値がどの層で使われるかを対応づけて記録してください。「サーバードメイン」だけを保存するより、接続先アドレス、TLS名、リクエストの振り分け先をそれぞれ明記し、既定値の項目も記録したほうがトラブル対処に役立ちます。

証明書エラーを検証の無効化で回避しない

証明書の問題は、主に3点を確認します。デバイスの時刻が正確か、設定した名前が証明書の対象範囲と一致しているか、サーバーが信頼できる完全な証明書チェーンを提供しているかです。証明書の期限切れ、チェーンの不備、名前の不一致は別々の問題であり、対処方法も異なります。クライアントで確認できるのはローカル設定や時刻です。サーバー証明書の設定は、利用中のサービスの管理者による対応が必要です。パスワードを何度も変えても証明書チェーンは修復されず、原因の確認にもなりません。

証明書検証を無効にすると、接続先の本人確認条件が変わります。日常的なトラブル対処で最初に行う操作ではありません。検証を無効にした場合だけ接続できても、サーバーが信頼できると証明されたわけではありません。元の設定を残し、どの項目が一致しないのか確認したうえで、通常の検証に戻してください。追加の信頼情報が必要なサービスでは、その情報の入手元と適用範囲も確認します。別の接続からコピーした証明書設定を、現在の設定に安易に適用しないでください。

TLSの処理負荷と長時間接続

TLS接続の確立には追加の通信往復と処理が必要ですが、その後のリクエストでは接続を再利用できる場合があります。実際の影響はアプリの動作とネットワーク条件によって異なります。短い通信のたびに切断と再接続を繰り返す場合と、大容量通信で接続を維持する場合は、初回の表示時間だけで比較できません。電波が弱いと再試行が増え、ハンドシェイクの負荷が大きくなり、プロトコル固有の特性のように見えることがあります。初回接続、連続アクセス、アイドル状態からの復帰を分けてテストし、どの段階で差が出るか確認してください。

Trojanの設定でUDPを利用できるかどうかは、TLSが正常でも判断できません。サーバーの対応状況と実際の用途を確認してください。ウェブは使えてもリアルタイム通信に問題がある場合は、ルーティングを確認してからUDP経路を個別に検証します。証明書、ドメイン、転送方式の確認方法はTLSを使う他のプロトコルにも応用できますが、異なるプロトコルのパスワードやリクエスト形式を使い回せるわけではありません。共通する層では同じ考え方で確認し、各プロトコル固有の設定は一致させてください。

WireGuardの鍵とルーティング

リクエスト型プロキシと比較する際の違い

WireGuardはIP層のトンネルを目的とし、公開鍵方式で接続先を識別して、UDPで暗号化データを転送します。接続先ごとのリクエストをプロキシ経由で送る方式とは、確認や設定の層が異なります。Shadowrocketで利用する場合は、クライアントからその接続へどのように通信を渡すか、受信したデータを接続先でどう転送するかも考慮してください。トンネルが確立しても、宛先へのルーティング、名前解決、戻りの経路がすべて正しいとは限りません。実際のサービスへの接続を確認する必要があります。

WireGuardは、暗号方式の組み合わせが明確で、プロトコルの状態管理も比較的シンプルです。利用者が暗号方式を自由に組み合わせる必要を減らしています。ただし、シンプルだからといってすべての項目を空欄にできるわけではありません。ローカルアドレス、鍵、接続先、許可するアドレス範囲は、それぞれ異なる役割を担います。サーバー側ではクライアントの公開鍵を認識し、それに合ったネットワーク設定が必要です。設定内の秘密鍵だけを変更し、サーバー側の対応情報を更新しなければ、元の認証関係が成立しなくなることがあります。

Private Key、Public Key、Endpoint

Private Keyはローカルの秘密情報です。信頼できる設定領域でのみ使用してください。Public Keyは接続先が相手を識別するために使うもので、同じように秘密にするものではありません。接続先のPublic Keyには、情報に明記された相手側の公開鍵を指定します。自分の公開鍵を再度コピーしてはいけません。設定によっては追加の秘密情報として事前共有鍵が含まれます。任意のメモではありません。どちらも名前にKeyが含まれるからといって、相互に置き換えたり、項目の削除で簡略化したりしないでください。

Endpointは接続先のアドレスとポートを示し、トンネル内で使用するローカルアドレスとは異なります。前者は現在のネットワークからサーバーを見つけるため、後者はトンネル内の通信に使われます。アドレスのプレフィックス長にもネットワーク上の意味があります。装飾的な文字として削除しないでください。読み込み後に項目不足が表示された場合は、元の情報を確認します。デバイスが現在接続しているWi-Fiのアドレスで代用してはいけません。物理ネットワークのアドレスとトンネル内のアドレスは別の層に属し、混同するとトラブル対処が難しくなります。

Allowed IPs、DNS、MTU

WireGuardのAllowed IPsは、接続先に転送する対象範囲や、受信元の検証に関係します。クライアントに表示される項目や、ルーティングとの組み合わせ方は、現在の画面と既存の設定を基準にしてください。Shadowrocketのルールリストと同じ形式だと考えて、任意に書き換えてはいけません。内部ネットワークだけを許可する設定を選んでも、インターネット全体へアクセスできるようになるわけではありません。接続先の転送、出口、戻りのルートが対象に対応しているかも確認してください。

DNSは名前をアドレスに変換し、トンネルのルーティングは変換後の宛先までの経路を決めます。両方を分けて確認してください。既知のアドレスには接続できてもドメイン名で失敗する場合は、まず名前解決の経路を確認します。名前解決はできても接続できない場合は、宛先範囲と接続先の転送を調べます。MTUはカプセル化後のデータパケットサイズに影響します。値が大きすぎると、小さなリクエストは通るのに大きなレスポンスが止まることがあります。一般的な数値をむやみに設定せず、元の値を保ち、症状を確認してからサーバーの推奨に基づき一度に1項目ずつテストしてください。

モバイルネットワークでのキープアライブと復旧

キープアライブは、特定の環境でネットワーク上のマッピングを維持するために使います。頻度を上げるほどよいわけではありません。アイドル状態の後も着信データを受け取る必要がある場合に役立つことがありますが、定期的な通信や無線の起動が増えます。必要性や間隔は、サーバーの役割、ネットワークのマッピングが維持される時間、実際の用途に基づいて判断してください。画面上で接続中に見せるために設定するものではありません。通常のアクセスを自分から開始するだけなら、間隔を短くしてもすべての通信が速くなるわけではありません。

WireGuardの接続先識別は、条件によって接続先アドレスの変化に対応できます。ただし、ネットワーク切り替え後の復旧はシステム、サーバー、現在のUDP到達性に左右され、接続が途切れないとは限りません。アイドル状態からの初回アクセスと、ネットワーク切り替え後の実際のリクエストをテストし、対象の通信が本当にトンネルを通っているか確認してください。診断情報を共有する際は、Private Key、事前共有鍵、内部ネットワークの情報を隠し、必要な症状、項目名、エラーの種類だけを残してください。設定一式を共有してトラブル対処を簡単にしようとしないでください。

Hysteria2の利用に適したネットワーク条件

パケットロスと輻輳への設計から見る

Hysteria2はQUICを基盤にしたプロキシ通信方式です。QUICはUDP上で動作し、安全なハンドシェイク、ストリーム管理、輻輳制御などを備えています。通信品質が異なるネットワーク経路に応じて転送を調整することも設計上の特徴です。ただし、物理的な通信経路の制限を解消するものではありません。電波が弱い、サーバーの帯域が不足している、中継ネットワークで必要なUDP通信が許可されていないといった場合は、接続に失敗したり通信速度が低下したりします。まず転送に必要な条件を確認してから、現在のネットワークでの性能を評価してください。

QUICの複数ストリーム機能は、転送層で順番どおりのデータ配送が必要なために、あるストリームの遅延が別のストリームを妨げる状況を一部減らせます。ただし、回線速度、輻輳、サーバーリソースの共有は引き続き全体の制約になります。あらゆるリクエストが待たなくなるわけではなく、ゲームや音声通話の遅延が必ず下がるわけでもありません。インタラクティブな通信では待ち行列やパケットロス、継続的な転送では安定したスループットが重要です。同じ設定で一方が改善しても、もう一方が改善するとは限らないため、別々に記録してください。

認証、名前、難読化の設定

設定時はまずサーバーアドレス、ポート、認証情報を確認し、続いてTLS名と証明書検証を確認してください。認証情報は省略せず、完全な値を使います。メモのように見えても途中で切り詰めてはいけません。TLSを使う他の接続と同様に、実際の接続先アドレスと認証に使う名前は役割が異なる場合があります。既存の設定情報どおりに入力してください。セキュリティ接続がまだ確立していない場合は、認証情報が無効だと判断する前に、外部からの到達性と名前の一致を確認します。

サービスによっては追加の難読化設定があります。サーバー側で同じ仕組みと設定値が使われていると明記されている場合に限り、有効にしてください。本人確認の代わりにはならず、速度を上げるスイッチでもありません。クライアントとサーバーで有効・無効の設定が異なる場合や、パスワードが一致しない場合は、通常のプロトコル処理が始まる前にデータを認識できないことがあります。読み込んだ設定は一式をそのまま保管してください。手動で変更する前に複製を保存し、別の設定にある似た項目を使って不足を補わないでください。

帯域設定は条件を指定するもので、速度を保証する値ではない

既存の設定に上り・下りの帯域項目が含まれる場合は、方向と単位を確認し、輻輳制御に影響する可能性を理解してください。現在の回線能力を大幅に上回る値を設定しても、利用できる帯域は増えません。待ち行列やパケットロスが増えたり、他の通信と競合したりすることがあります。モバイル通信の実効速度は場所や時間によって変わるため、固定値が常に適切とは限りません。まずサーバーの推奨値またはクライアントの妥当な既定値を使い、継続的なテストで調整が必要か判断してください。

ウェブページは最初の表示が正常でも、大容量データの転送が不安定な場合は、異なるネットワークで比較し、他の通信にも影響があるか確認します。通信を始めてから音声が途切れる場合、認証やTLSの問題ではなく、回線の待ち行列やリソース競合が原因かもしれません。同時に行うテストを減らし、ほかの大容量通信を一時停止して、同じ宛先に再度接続すると、負荷が主な原因か判断しやすくなります。原因が分からないまま帯域設定を繰り返し上げて、ボトルネックを覆い隠さないでください。

UDPの到達性とバッテリー消費の範囲

ウェブサイトにアクセスできるネットワークでも、必要なUDPポートへの接続が許可されているとは限りません。Hysteria2があるネットワークでは使えて、別のネットワークでは失敗する場合は、設定を維持したまま、ネットワークの到達性に違いがないか確認してください。パスワードを何度も変更しても、正しい設定を壊すだけで、転送経路の制限は解決しません。ほかに利用できる完全な設定があれば、同じネットワークで比較できます。ただし、結果はそのネットワーク条件での評価にとどめ、あらゆる環境でのプロトコルの優劣に当てはめないでください。

iPhoneでは、スループットが高いと短時間でより多くのデータを処理できる一方、無線通信やプロセッサの負荷が増えることもあります。連続動作時間、総通信量、アイドル後の再接続もバッテリー消費に影響するため、画面に表示された瞬間的な速度だけでは判断できません。ネットワーク切り替え後は、接続スイッチを見るだけでなく、実際の通信が復旧したか確認してください。頻繁に失敗する場合は、テストの負荷を下げて状況を記録し、確認済みの設定に戻してから、転送経路、設定項目、サーバー側の条件を順に切り分けます。

設定項目の確認とルールによる振り分け

設定の読み込み成功は、接続確認の成功ではない

Subscribeから既存のサブスクリプションを読み込めた場合、確認できるのはクライアントが情報を読み取り、解析できたことまでです。含まれるすべての接続で認証が通る、または同じ機能が使えるとは限りません。読み込み後は対象の設定を開き、種類、アドレス、ポート、必要な転送項目が提供された情報と一致するか確認してください。表示名は識別用のラベルにすぎず、プロトコルの種類を示す根拠にはなりません。ラベルと実際の種類が異なる場合は、ラベルをもとに推測して書き換えず、元の情報を確認してください。

QRコードや共有テキストも設定情報の入れ物です。エンコード、エスケープ処理、項目の対応づけによって読み込み結果が変わる場合があります。コピー時に文字が欠ける、説明文まで一緒に選択する、内容の一部しか読み取れないといったことで、異常が起こることがあります。手動で補う前に、元の情報が完全か確認してください。サブスクリプションの更新でローカルの変更が上書きされる場合もあります。調整前に別のコピーを保存し、情報の出所を記録してください。一時的な修正が次の更新後も残るとは限りません。

Global Routingでルールが適用されるか確認

Global RoutingのConfig、Proxy、Directはそれぞれ、設定に基づく処理、プロキシ経由、直接接続という全体の動作モードです。ウェブサイトごとに振り分ける場合は、まずConfigを選び、使用中の設定ファイルを確認してください。Proxyは影響範囲を理解したうえでプロキシ経路を調べるときに役立ちますが、ルール全体の確認には代わりません。Directではプロキシプロトコルの動作を検証できません。動作モード、使用中のサーバー、設定ファイルは別々に記録してください。

ルールは通常、上から順に確認されます。先に一致した項目があると、後の詳細なルールは適用されない場合があります。DOMAINは完全なドメイン名、DOMAIN-SUFFIXは該当するドメインとサブドメイン、DOMAIN-KEYWORDはドメイン名に含まれるキーワードに一致します。IP-CIDRはアドレス範囲を対象とし、GEOIPは該当するIPアドレスの地域分類に基づいて処理します。FINALは、先行するルールに一致しなかった場合の最終処理です。対象が異なるため、どれもドメインやアドレスを記述できるという理由で置き換えることはできません。名前解決の条件も、一部のアドレスベースの判定に影響します。

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

この例はルールの順序を示すもので、サーバー情報を含まず、単体で接続できる完全な設定でもありません。より広いDOMAIN-SUFFIXより前に、対象を絞ったREJECTを置くことで、先に後者に一致することを避けています。PROXYは利用可能なプロキシ接続と合わせて考えてください。FINAL,DIRECTは、他のルールに一致しなかったリクエストを直接接続する指定です。例のドメインは構文を説明するためのものです。既存の設定に独自のポリシー名がある場合は、該当する定義を確認してください。見慣れない名称をすべてPROXYに置き換えてはいけません。

実際の接続記録で判断する

1つのサービスでも、ページ本体、静的ファイル、認証、リアルタイム通信など、複数のドメインへ同時にアクセスすることがあります。メインページが開いても、すべてのリクエストが同じポリシーに一致したとは限りません。逆に、一部の機能が失敗してもプロトコル全体が使えないとは限りません。実際の接続先と適用されたポリシーを確認し、ルールに一致しない、接続を確立できない、接続先からエラーが返る、といった状態を区別しましょう。1つのリソースを直すためにルールをすべて削除すると、元の設定の目的を損ない、変更の効果も判断できなくなります。

一致する対象について詳しくはルールキーワードの解説をご覧ください。指定したウェブサイトだけをプロキシ経由にする方法は特定サイトをルールで振り分ける方法で説明しています。REJECTを使う場合は、REJECTを適用する際の注意点もご確認ください。プロトコルは接続の確立方法、ルールは接続を使う条件を決めます。まずそれぞれを個別に確認してから組み合わせると、トラブル対処の記録を適切に判断できます。

速度、バッテリー消費、トラブルの切り分け

条件をそろえてテスト結果を記録する

利用中の設定を比較するときは、デバイス、ネットワーク、接続先、Global Routingをそろえ、ほかの大容量通信を停止し、できるだけ近い時間帯にテストしてください。各回で初回接続、再アクセス、継続的なデータ転送を記録し、結果を混同しないようにします。Connectivity Testは接続可能かを見る参考になりますが、テスト対象や接続方式が実際の通信と異なる場合があります。1回の結果だけで、実際のサービスが使えるとは判断できません。テスト後は元のルーティング設定に戻し、一時的な設定が通常の接続に影響しないようにしてください。

バッテリー消費を比較するときは、利用時間と総通信量を近づけ、画面、電波、バックグラウンドの動作も調整してください。システムのバッテリー画面に表示される値は、アプリの動作とシステムの集計方法に基づくもので、プロトコル単体の消費電力を測定した結果ではありません。短時間のテストは、起動直後の処理、キャッシュ、無線の状態に特に左右されます。端末が熱くなり続ける場合は、高負荷のテストを中止し、大量通信や頻繁な再接続がないか確認してください。原因が分からないまま同時接続を増やすと、比較条件がさらに不安定になります。

設定を手当たり次第に変えず、失敗した段階から切り分ける

接続を確立できない場合は、まず現在のネットワークが正常か、接続先アドレスとポートが正しいかを確認し、次にプロトコルの種類を調べてください。UDPを使う接続は、その経路に到達できるかも確認します。TLSを使う接続では、名前、デバイスの時刻、証明書の条件を確認してください。外側の接続が成立したうえで認証に失敗する場合は、パスワード、UUID、鍵を調べます。毎回変更する項目は1つにし、元の値を記録してください。改善しなければすぐに元に戻し、正しかった項目を新たな問題にしないようにしましょう。

接続は正常に見えるのにサービスを利用できない場合は、実際の通信が想定したポリシーを通っているか確認し、名前解決、接続先への通信、サービスからの応答を切り分けます。既知のアドレスには接続できてもドメイン名で失敗する場合は、まずDNSを確認します。特定の接続先だけ失敗する場合は、その接続先やサーバー側のアクセス条件を調べます。大きな応答だけ止まる場合は、MTU、パケットロス、通信品質を確認します。これらは原因を探る手がかりであり、症状だけで断定はできません。次のテストで別の可能性を確認してください。

ネットワークの切り替え後や、しばらく使わなかった後にだけ失敗する場合は、発生条件、待ち時間、再接続後の変化を記録してください。手動で再接続すると復旧するなら、少なくとも設定項目が正常に使えた実績があります。すべての認証情報をすぐに入力し直すのではなく、接続の復旧、ネットワークのマッピング、サーバー側のセッション処理を確認しましょう。On Demandの設定も接続動作に影響するため、記録に含めてください。ただし、誤った認証情報やサーバー側にない機能を修正するものではありません。まず手動接続で再現可能な結果を確認してから、オンデマンド接続の条件を調整してください。

利用シーンに合わせて比較対象を絞る

一般的なウェブ閲覧では、利用中の設定から、安定していて設定項目が明確であり、初回と再アクセスで同じように動作するものを選びます。リアルタイム通信では、UDPの利用可否と遅延の変動を確認します。アクセスを制限した内部ネットワークでは、ルーティング範囲、アドレスの競合、DNSを確認します。大容量通信を続ける用途では、スループットの安定性と他の通信への影響を見ます。これはテストの進め方であり、プロトコルの順位付けではありません。サーバーが実際に対応している機能だけを比較対象にしてください。

管理記録には、プロトコルの種類、外側の転送方式、利用ネットワーク、Global Routing、失敗した接続先の種類、再現手順を記載してください。サービス管理者と共有する前に、サブスクリプションURL、認証情報、秘密鍵などの機密値を隠します。スクリーンショットもトラブル対処に必要な範囲だけにしてください。初回接続時にシステムの許可を求められた場合は、VPN構成の追加確認についてをご覧ください。項目の意味は用語集で、操作全体の順序はクイックスタートガイドで確認できます。