Shadowrocket
プロトコルの種類と設定項目

サーバーが対応するプロトコルを確認してからTypeを選ぶ

プロトコルの種類はサーバー側と一致させる必要があります。同じアドレスとパスワードを別の種類に切り替えて使うことはできません。Homeのサーバー編集画面またはAdd Serverで選ぶTypeは、クライアントが認証情報やデータをどのように扱うかを決めます。接続を確立するには、サーバー側も同じ形式に対応していなければなりません。既存のサブスクリプションには通常これらの設定が含まれているため、読み込み後はまず値を変更せずに確認してください。手動で項目を作成するのは、サーバー側の実際の設定を把握している場合に限ります。プロトコル名だけでは、必要な設定項目をすべて特定できません。

接続は複数の層に分けて考える必要があります。AddressとPortは接続先を指定し、プロトコル認証は相手が要求を受け入れるかどうかを決めます。通信方式はデータの運び方を定め、TLSは該当する通信経路の認証と暗号化を担います。Global Routingはどのリクエストをその経路に送るかを決めます。同じVLESSでも通信方式が異なる場合があり、TLSを使う接続同士でも認証方式が異なることがあります。これらの層を混同すると、実際には証明書の不一致が原因なのに、パスワードを変更してしまうといった誤った対処につながります。

7種類のプロトコルは速度ランキングではない

プロトコルの歴史や背景から分かるのは設計上の目的であり、あらゆるネットワークでの固定的な性能ではありません。Shadowsocksはシンプルなプロキシ転送を重視し、VMessは独自の認証とデータ保護の仕組みを備えています。VLESSは保護の多くを外側の仕組みに委ね、TrojanはTLS経由でプロキシリクエストを転送します。HTTPとSOCKS5は汎用プロキシのインターフェース、WireGuardはIP層のトンネル、Hysteria2はQUICベースの通信方式です。それぞれ解決する課題が異なるため、名称だけで古い順・新しい順に並べることはできません。

速度は通常、サーバーの外向き回線、往復時間、混雑、無線電波の状態に大きく左右され、プロトコルの処理負荷はその後に影響します。Webページの表示にはDNS検索やハンドシェイク、複数の短いリクエストが含まれますが、継続的なダウンロードではスループットがより重要です。そのため、両者で異なる結果が出ることがあります。iPhoneではモバイル回線の電波、低電力状態、バックグラウンドと前景の切り替えも考慮が必要です。速度テストの最高値を日常の使用感とみなすことはできません。比較する際は、デバイス、ネットワーク、サーバーの条件、テスト対象を固定し、変更する要素は一つに絞ってください。

用途に応じてバッテリー消費と互換性を考える

バッテリー消費は、実際の通信量、接続の維持方法、無線モジュールの稼働時間によって変わり、特定のプロトコルに固定された性質ではありません。TLS接続を頻繁に確立すると、一時的な処理負荷が増えることがあります。Keepaliveパケットを継続的に送るとネットワークが頻繁に起動し、パケットロス後の再送も消費電力を増やします。長時間の動画視聴、少量のメッセージ送信、待機の3つの状況を分けて確認してください。デバイスの温度が上がった場合は、まずDataの通信量の変化やバックグラウンド処理を確認し、すぐにプロトコル実装の問題と判断しないでください。

TCPとUDPの対応状況も分けて確認してください。Webページが開けても、それは該当経路のリクエストが成功したことを示すだけで、音声通話などのUDP通信が可能とは限りません。プロトコルがUDPに対応していても、サーバー、現在の通信方式、上位ネットワークが許可しているとは限りません。反対に、UDPを外側の通信に使うプロトコルでも、アプリのTCPリクエストを転送することがあります。「アプリの通信種別」と「外側の接続種別」は別の概念です。UDPという表示だけで、アプリの通信全体を判断しないでください。

最初に確認するのは、サーバーが実際に対応しているもの、現在のネットワークで許可されているもの、必要な通信の3点です。その後、認証情報が揃っているか、証明書を正しく検証できるか、接続に失敗したとき原因を特定しやすいかを確認します。利用可能な種類が一つだけなら、まずその設定を正しく行ってください。サーバー側に対応設定がない項目を探しても解決にはなりません。共有形式を確認したい場合は、共有リンクとサブスクリプションリンクの違いを読んでから、該当するプロトコルの章に進んでください。

UUIDが似ていても、接続方法が同じとは限らない

VMessはユーザー認証と独自のデータ保護機構を備えています。一方、VLESSはよりシンプルな識別構造を採用し、通信経路の保護を主にTLSなどの外側の仕組みに委ねます。どちらもUUIDを使うことがありますが、サーバー側の処理は異なります。TypeをVMessからVLESSに変更し、残りの項目をそのままにしても変換にはなりません。既存の共有情報で指定された種類を使用してください。サーバーに両方の接続先が設定されている場合に限り、それぞれの項目を作成して比較できます。

UUIDは識別情報であり、サーバーアドレスでもサブスクリプションリンク内の任意のクエリ項目でもありません。コピー時は空白、改行、引用符が混ざっていないか確認し、全体を欠けずに保持してください。VMessにはセキュリティ設定や互換性のための項目が含まれる場合があります。サーバー情報に従って設定し、古い解説をもとに、すべてのサーバーで同じ数値が必要だと決めつけないでください。VLESSの認証項目がシンプルでも、外側の保護を省略できるわけではありません。TLSが必要な接続先でTLSを無効にすると、通常は想定どおり接続できません。

通信方式の設定は一組として確認する

TCPやWebSocketなどの通信方式は、プロキシデータの運び方を示すもので、VMessやVLESSの認証を代替するものではありません。同じアドレスでも接続先が異なり、一方はWebSocketを要求し、もう一方は直接TCP接続のみを受け付ける場合があります。通信方式を間違えても、ネットワーク層ではポートに到達できるように見えることがありますが、その後のデータを正しく処理できません。サーバーを追加するときは、通信方式とHost、Pathなどの関連項目を合わせて確認し、先頭の選択肢だけを変更しないでください。

WebSocketのPathは、サーバーがリクエストを受け取るパスです。通常は先頭のスラッシュや大文字・小文字を含め、正確に一致させる必要があります。任意のWebサイトのディレクトリではありません。Hostは関連リクエストに含まれるホスト情報、SNIはTLSハンドシェイクで使われる情報です。同じ値になることもありますが、役割は異なります。Addressが実際の接続先を示し、HostやSNIには設定上指定された名称を使う場合もあります。3つの値が異なっていても、独自に同じ値へそろえないでください。それぞれ既存の設定情報に照らして確認します。

TLS証明書の検証は、接続先の身元を確認するためのものです。「接続できる」という理由で検証を無効にしないでください。証明書のドメイン名と想定名が一致しない、証明書チェーンが不完全、デバイスの時刻が大きくずれている、といった場合はハンドシェイクに失敗することがあります。SNI、証明書、時刻を確認し、検証をスキップしないでください。別のハンドシェイク方式や特定の設定の組み合わせを必要とする接続先では、読み込み結果をそのまま保持してください。画面に選択肢が表示されても、すべてのサーバーが対応しているとは限りません。

通信方式のオーバーヘッドも含めて比較する

追加のカプセル化やハンドシェイクは最初のリクエストにかかる処理を増やしますが、体感できるかどうかは接続の再利用、往復時間、通信内容によって変わります。連続するリクエストで既存の接続を再利用できれば、初回のコストは分散されます。短い接続を何度も確立する場合は、ハンドシェイク時間の影響が出やすくなります。安定したネットワークでのダウンロード速度から、電波の弱い環境での性能を直接推測することもできません。iPhoneの日常利用ではバックグラウンドからの復帰やネットワーク切り替えがあるため、少なくともこれらの状況を含めて確認してから、現在の環境に適した組み合わせを判断してください。

「サーバーのテスト結果は出るのにWebページが開かない」場合は、ポートへの到達とリクエスト全体の成功を分けて考えてください。まずGlobal Routingで対象の通信が該当項目に送られているか確認し、次にUUIDとType、TLS、通信方式の設定を確認します。ブラウザーに証明書関連のエラーが表示された場合は、プロキシ接続先の証明書なのか、最終的なWebサイトの証明書なのかも切り分けてください。両者は別の証明書です。具体的なエラーと発生段階を記録すると、「接続できない」とだけ記録するより、変更が必要な項目を見つけやすくなります。

複数のプロトコル接続先がある場合は、設定情報が揃い、証明書を正しく検証できるものを優先し、そのうえで実際の使い勝手を比較してください。VLESSの構造がシンプルだからといって必ず省電力とは限りません。VMessに独自の保護機構があっても、外側の設定を無視してよいわけではありません。プロトコル名を手早く確認するには、まず対応プロトコルの概要をご覧ください。この章では、項目間の依存関係と接続に失敗する条件を説明します。

プロキシの宛先だけを指定するのではなく、IPパケットを転送する

WireGuardは、シンプルなIP層の暗号化トンネルを中心に設計されており、公開鍵で接続相手を識別し、UDPでデータを転送します。宛先アドレスを指定するアプリケーションプロキシとは異なり、トンネル内部のアドレス割り当てや、宛先トラフィックを適切な相手に送る方法もクライアントとサーバーで把握する必要があります。Shadowrocketで使う場合も、外側ではアプリ全体の通信処理とルーティング機構の影響を受けます。トンネル設定の意味をGlobal Routingのモードと完全に同一視しないでください。

鍵の対応関係は問題を調べる際の出発点です。クライアントのPrivate Keyは秘密に保ち、対応する公開鍵をサーバーに登録する必要があります。クライアントのPeer Public Keyには、サーバー側の公開鍵を指定します。両者を逆にしたり、コピーが不完全だったり、古い公開鍵を使ったりすると、ハンドシェイクに失敗することがあります。事前共有鍵が設定情報に含まれる場合は、両端で一致させてください。サーバーの公開鍵をクライアントの秘密鍵欄に入力しないでください。また、接続を直すために実際の秘密鍵をフィードバック用のスクリーンショットや公開記録に載せないでください。

Endpoint、Address、Allowed IPsを混同しない

Endpointは外部ネットワークからサーバーへ接続する場所で、通常はドメイン名またはIPアドレスとUDPポートで構成されます。Addressはトンネル内部で使うアドレスであり、デバイスの現在のWi-Fiのローカルアドレスでも、サーバーのグローバルアドレスでもありません。既存の設定にアドレスとプレフィックスが指定されている場合は、そのまま使用してください。「空いていそうな」プライベートアドレスに変更すると、サーバーのルーティングやアドレス割り当てと競合することがあります。ハンドシェイクの成功で確認できるのは、鍵と接続先が基本的に利用できることだけで、内部アドレスの正しさまでは分かりません。

Allowed IPsは、相手側に関連付ける宛先アドレス範囲を表し、ルーティングの判断にも関係します。アプリケーション層のドメインルールではありません。範囲が不足していると、ハンドシェイクが成功しても業務データが想定した接続先に送られない場合があります。範囲が広くても、それだけでShadowrocketのすべてのリクエストがConfigの選択を迂回すると判断することはできません。サーバー項目のトンネル設定とアプリ側の方針を分けて確認し、実際の宛先で検証してください。IPv6を使う場合は、トンネルアドレス、宛先範囲、サーバーの転送機能がすべて対応しているか確認します。

DNSは独立した設定項目です。トンネル経由で特定のIPアドレスにはアクセスできても、ドメイン名ではアクセスできない場合、WireGuardの暗号化ではなく、DNSサーバーへの到達性が原因のことがあります。既存の設定にあるDNSアドレスがトンネル経由でしかアクセスできない場合は、関連するリクエストが通るよう経路とルールを設定する必要があります。調査ではまずIPアドレスでのアクセスとドメイン名でのアクセスを区別し、次にDNSの結果を確認してください。名前解決の失敗に対して鍵を変更したり、ハンドシェイクがあるからといってルーティングの問題を除外したりしないでください。

MTUとKeepaliveは通信経路に合わせて調整する

カプセル化には追加の領域が必要で、MTUは関連するパケットサイズを制限します。設定が大きすぎると、経路によっては大きなリクエストが止まる、一部のWebページが読み込みきれない、継続的な通信が不安定になることがあります。一方、小さすぎると実効的な転送効率が下がる場合があります。パケットサイズに関連する問題を示す根拠がある場合に限り、慎重に調整してください。元の値を記録し、同じタスクで比較します。別のネットワークの値を、そのまま全デバイス共通の固定値として流用しないでください。

Persistent Keepaliveは、必要に応じてネットワーク上のマッピングを維持するためのもので、スループットを上げるためのスイッチではありません。モバイル通信や一部のルーター環境では、戻りの経路を保つために定期的な通信が必要な場合があります。間隔を短くしすぎると、無線通信の起動が増えます。アイドル状態からの復帰に失敗する現象があるかを確認し、最初から短い間隔に設定しないでください。iPhoneでは、画面消灯後やネットワーク切り替え後の動作を、前景での継続的なダウンロードとは分けて確認します。

WireGuardは、トンネル設定がすべて揃っており、IP層でのアクセス範囲を明確にしたい場合に適しています。構造がシンプルでも、サーバー側の転送、ファイアウォール、アドレス設計は必要です。Endpointと公開鍵しか分からない場合、通常は設定全体を再構築するには情報が足りません。元の設定情報から不足項目を確認してください。問題を共有する場合は、エラーが発生した段階、ネットワーク種別、宛先範囲を記録できます。ただし、鍵や内部アクセス情報は管理された環境に保管してください。

読み込みの成功は、内容が認識されたことを示すだけ

サブスクリプションや共有リンクがShadowrocketに受け付けられても、サーバーが現在利用可能であることや、すべての項目が接続先の設定に合っていることを意味しません。読み込み後はType、Address、Port、認証項目、通信方式を確認してから、サーバーを選んでテストしてください。既存のサブスクリプションは自分の設定元から更新情報を取得し、更新によって手動の変更が上書きされる場合があることにも注意してください。長期的に残したいローカル設定は、どの項目がサブスクリプションによって管理されるかを確認し、次回の更新時にアプリが勝手に変更したと誤解しないようにします。

共有リンクとSubscribeのサブスクリプションは役割が異なります。前者は通常、一つの項目を表します。後者は複数の項目を返し、継続的に更新されることがあります。また、異なるエンコードや形式が使われる場合もあります。QRコードは内容を別の方法で読み込むためのもので、誤った設定を正しくするものではありません。Scan QR Codeで読み込んだ後も、特に特殊文字を含む認証情報、パス、追加項目を確認してください。サブスクリプションのURL自体にアクセス情報が含まれることもあります。公開スクリーンショット、記録、共有可能な障害報告に表示しないよう注意してください。

まずモードで経路を確認し、次にルールで細かく振り分ける

Global RoutingのConfig、Proxy、Directは、それぞれ設定ルールに従う、プロキシ経路を使う、直接接続する状態を表します。Configは現在有効な設定ルールに基づいてリクエストを処理し、Proxyは主にリクエストをプロキシ経路へ送り、Directは直接接続します。これらが決めるのはリクエストの行き先であり、サーバープロトコルの認証方式ではありません。特定のサーバーを調べるときは、まず明確なプロキシ状態で確認してから、Configに戻って振り分けを調べてください。テスト後は、日常の用途に適したモードに戻します。

ルールは通常、記述順に照合されます。先にある具体的な条件が、後の広い条件より先に適用されることがあります。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPv4アドレスの範囲を扱い、FINALはそれ以前のルールに一致しない場合の最終方針です。ルールでPROXYまたはDIRECTを指定することはできますが、Password、UUID、証明書の誤りは修正できません。あるドメインが直接接続なら正常でConfigでは失敗する場合は、まず適用されたルールを確認し、プロキシ接続先と宛先サービスのどちらで失敗したかを判断してください。

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

これは照合順序を説明するための.confの例であり、日常利用の完全な設定ではありません。example.comは説明用のドメインで、プライベートアドレスの範囲はアドレスルールを示しています。GEOIPの結果は、使用するデータと実際の宛先アドレスによって異なります。正しい[Rule]セクションに置いて読み取り、Add Serverの認証項目に貼り付けないでください。セクション間の関係について詳しくは、設定ファイルのGeneral、Rule、Host、URL Rewriteの解説をご覧ください。

DNSとOn Demandはプロトコル認証とは別の設定

DNSはドメイン名の解決方法を決め、ルールはリクエストの経路を決めます。両者は影響し合うことがありますが、どちらもサーバーのTypeとは別です。ドメイン名が複数のアドレスに解決される場合、アドレスごとに到達性が異なることがあります。プロトコル名だけを変更しても、名前解決の誤りは解消しません。IPv6も個別に確認してください。デバイスにIPv6アドレスが割り当てられていても、既存のサーバーがすべてのIPv6宛先を転送できるとは限りません。実際のアドレス種別とリクエスト経路を確認し、DNS、ルーティング、サーバー機能のどれを調整すべきか判断してください。

On Demandは条件に応じて接続を開始するタイミングを制御します。VMessをVLESSに変換する機能ではなく、Configのルールを代替するものでもありません。有効にした後、ネットワークの変化に合わせて自動接続が始まる場合は、まず起動条件を確認してください。接続済みなのに一部の宛先だけ失敗する場合は、ルール、DNS、プロトコルの設定に戻って確認します。「いつ接続するか」と「接続後にどう振り分けるか」を分けて記録すると、特定のWebサイトを直すために自動接続設定を繰り返し変更せずに済みます。

手動で変更する前に、復元可能な設定を残し、公開してはいけない情報が含まれていないか確認してください。アプリのDataで通信の有無を確認できます。利用可能な場合は接続記録も、適用方針やエラーの段階を判断する手がかりになります。ただし、通信量が増えてもリクエストが最終的に成功したとは限りません。効率的な確認順序は、項目の不足がないか、プロトコルが一致しているか、外側の接続先に到達できるか、認証に成功したか、ルールが適用されたか、宛先から応答があるかです。各段階の結果を明確にしてから次へ進み、複数の層を同時に変更しないでください。