Shadowrocketのプロトコル解説
種類の選び方と設定項目の確認

まず接続する両端を確認

Shadowrocketでプロトコルを選ぶことは、サーバーが解釈できる通信形式をクライアント側で指定することです。Typeは速度の設定ではありません。サーバーがShadowsocksを提供している場合、クライアントをTrojanに変更するだけで別の接続ができるわけではありません。アドレス、ポート、認証情報、暗号化方式、通信条件がそろって初めて設定が有効になります。重要な条件が一つでも欠けると、接続を確立できないことがあります。サブスクリプションには通常これらの情報が含まれますが、インポートできたことは情報を読み取れたという意味であり、サーバーに現在接続できることを保証するものではありません。

接続を理解するには、リクエストを三つの要素に分けて考えます。アプリがアクセスする宛先、Shadowrocketが接続するサーバー、リクエストをサーバーへ送るローカルネットワークです。接続先サイトのHTTPSと、クライアントからサーバーまでのTLSは別の階層です。ブラウザーに安全な接続と表示されても、それは接続先との通信における証明書検証の結果を示すにすぎず、選択したプロキシプロトコルの外側の通信も暗号化されているとは限りません。逆に、外側の通信でTLSを使用していても、接続先の証明書をアプリが検証する必要はなくなりません。

プロトコルの種類と通信方式は別

Shadowsocks、VMess、VLESS、Trojanはそれぞれ異なる仕組みを定めています。TCPとUDPは下位の通信方式であり、WebSocket、HTTP/2、QUICにもそれぞれ異なるセッションやカプセル化の方式があります。あるプロトコルが特定の通信方式に対応していても、サーバー側で有効になっているとは限りません。また、任意のクライアントとの組み合わせで通信できるとも限りません。情報を確認するときは、プロトコルの種類、通信方式、TLSの条件を分けて記録してください。名称が並んでいても、自由に置き換えられる同義語ではありません。

一連の処理全体で速度と電池消費を評価

速度を評価するには、接続確立までの待ち時間、最初の応答が届くまでの時間、継続的な転送速度、切断後の復旧をそれぞれ見る必要があります。簡単な接続テストで分かるのは、その一部にすぎません。TCPの接続確立が速くても、大きなファイルの転送が速いとは限りません。ダウンロード速度が高くても、短いリクエストへの応答が速いとは限りません。モバイル端末の通信は、電波状況、通信事業者の制御、サーバー負荷、接続先サイトの制限にも左右されます。そのため、このマニュアルではプロトコル名だけで速度を順位付けしたり、一度の測定値を長期的な性能の指標にしたりしません。

電池消費は、同じ作業を完了するまでに必要な総処理量によって変わります。暗号化処理、データのカプセル化、再送、接続維持、無線モジュールの起動はいずれも電力を消費します。電波が弱い場合は、プロトコルの違いより無線通信の負荷が大きくなることもあります。比較する際は、端末、ネットワーク、サーバー、テスト内容をそろえて、一定時間の動作を確認してください。接続を有効にした直後の電池残量だけでは判断できません。接続維持を続けると一部の復旧待ち時間を短縮できますが、バックグラウンドでの起動が増える可能性もあります。使い方に応じて調整してください。

ルーティングは別の判断経路です。サーバー情報が正しくても、リクエストがDirectで直接送信される場合があります。トラブルを確認する前に、Global Routingのモードと実際に適用されたルールを確認してください。そのうえで、プロトコルが機能しているかを調べます。設定、プロキシ、直接接続は、画面上のConfig、Proxy、Directにそれぞれ対応します。これらはリクエストの経路を決めるものであり、サーバーのプロトコルを別の種類に変えるものではありません。

設計の背景と主な特徴

Shadowsocksは、比較的軽量な暗号化プロキシ転送を実現する設計です。クライアントが接続先へのリクエストをカプセル化してサーバーへ送り、サーバーが接続先にアクセスします。仮想ネットワークインターフェース全体を提供するプロトコルではなく、端末にリモート側のLAN上のアドレス一式を割り当てるものでもありません。通常、ユーザーが設定する主な項目はサーバーアドレス、ポート、暗号化方式、パスワードです。設定項目が少なく見えても、暗号化方式を省略できるわけではありません。また、名称が似た実装をすべて同じ互換方式とみなすこともできません。

暗号化方式によって、鍵の扱い方やデータ形式は異なります。AEAD方式では機密性とメッセージの完全性を同時に扱い、新しい方式では鍵情報の形式や長さの要件が変わる場合もあります。情報に記載された方式名は、クライアントで実際に選べる項目と一字ずつ照合してください。AESを含む名称だからといって別の方式に置き換えたり、「より強い」方式を選んだりしないでください。サーバー側で設定されていない方式に変更すると、両端でデータを正しく解釈できないことがあります。

四つの主要項目を確認する

Serverにはドメイン名またはIPアドレスを入力します。ここで指定するのはプロキシサーバーであり、アクセスしたいWebサイトではありません。Portにはサーバー側で指定された待ち受けポートを入力します。プロトコル名から推測してはいけません。Methodはクライアントとサーバーで合意した暗号化方式、Passwordは元の内容をそのまま入力します。パスワードをコピーするときは、前後の空白、改行、よく似た文字に注意してください。方式によっては定められた形式の鍵情報を使います。自分で別の形式に変換してから入力しないでください。

共有リンク内のエンコードは情報の表現方法にすぎず、基礎となるプロトコルを変えるものではありません。リンクには方式と認証情報がまとめて含まれる場合も、追加パラメーターが付く場合もあります。クリップボードから名称を読み取れても、すべての拡張パラメーターが正しく復元されたとは限りません。インポート後は項目を開き、Type、Server、Port、Method、Passwordを確認してください。プラグインや特殊な通信条件が含まれる場合は、両端が対応していることも確認します。基本の四項目だけでは、元の設定を再現できないことがあります。

TCPは動くのにUDPで問題が起きる理由

ShadowsocksはTCPを転送でき、対応する実装と設定でUDPを扱うこともできます。それぞれの経路を個別に確認してください。サーバーでTCPポートが開いていても、同じポートのUDPが開いているとは限りません。Webページを見られても、あらゆるUDP通信が許可されているとは限りません。Webページは使えるのに一部のリアルタイム通信が失敗する場合は、まず対象の通信方式を確認し、次にUDPの条件を調べてください。すぐにパスワードを変更する必要はありません。DNSの名前解決経路が他の通信と異なる場合もあるため、別途確認してください。

iOSでのShadowsocksのリソース消費は、使用する暗号化方式、データ量、プロセッサー性能によって変わります。ハードウェアによる特定アルゴリズムの高速化で処理負荷が下がることはありますが、すべての端末や方式に当てはまるわけではありません。軽量なカプセル化は一部の処理を減らせても、電波が弱いときの再送やサーバーの混雑を解消するものではありません。継続的に通信する場合は、同じファイルを完了するまでの時間と安定性を比較してください。「階層が少ないから省電力」とは判断できません。

トラブル時は、まずアドレスの名前解決とポートへの到達性を確認し、その後で暗号化方式と認証情報を照合します。基本的な通信が成功しているのに特定のアプリだけ問題がある場合は、暗号化項目を何度も変えるのではなく、ルール、DNS、UDPを確認してください。一度に変更する条件を一つに絞り、動作している元の項目を残すと、経路の問題と認証の問題を切り分けやすくなります。

二つのプロトコルは役割が異なる

VMessはプロトコルに認証とデータ保護の仕組みを含み、UUIDなどの情報でクライアントを識別します。認証方式には複数の世代があります。一方、VLESSはよりシンプルなプロトコル構造を採用しており、VMessと同じ組み込みのデータ暗号化機能はありません。通常は組み合わせるセキュアな通信方式で、クライアントからサーバーまでの通信を保護します。どちらもUUIDを使う場合がありますが、UUIDが同じでもプロトコルを置き換えられるわけではありません。Typeはサーバー側の設定と一致させてください。

VLESSのシンプルさは、あらゆる状況でVMessより速いことを意味しません。実際の接続にはTLS、各種通信方式、多重化、サーバーでの転送が組み合わさる場合があり、全体の構成によって処理負荷が変わります。VMessの古い設定では追加の互換パラメーターが使われることもあります。既存の情報にそうした項目がある場合は、サーバーの要件に照らして確認してください。一律の値を当てはめてはいけません。不明な項目があれば、まず適用される世代を調べ、古いパラメーターを新しい認証方式に無理に追加しないでください。

UUID、時刻、安全な通信層

UUIDは認証情報であり、サーバーアドレスでも任意のメモでもありません。貼り付ける際はハイフンを含め、すべての文字をそのまま保持してください。クライアントが大文字・小文字を自動で整えても、欠けた文字まで修復されるわけではありません。時刻を基準とするVMess認証では、端末の時刻が大きくずれていると認証に失敗することがあります。まずシステムの日付と時刻を自動設定にしてください。それでも失敗する場合はUUID、プロトコルの世代、サーバーの状態を確認します。あらゆる認証エラーをネットワーク到達不能のせいにしないでください。

VLESSの設定で資料にnoneと指定されていても、接続全体が保護されないと即断したり、外側のTLSを無視したりしないでください。プロトコル層の項目とセキュアな通信方式の項目を分けて確認します。逆に、外側に安全な通信路がない場合、プロトコル名だけで同等の保護があると判断することもできません。TLSの有無、サーバーの認証方法、特定のFlowの有無は、いずれも元の情報と一つずつ照合する必要があります。

WebSocket、Host、Pathの関係

既存の設定でWebSocketを使う場合、クライアントは対応するHTTP Upgradeの手順で接続を確立し、その中でプロトコルのデータを転送します。Pathはサーバーまたはリバースプロキシがリクエストを識別するためのパスです。先頭のスラッシュや大文字・小文字を含め、通常はそのまま保持します。HostはHTTPリクエストで指定するホスト情報で、仮想ホストの選択に使われることがあります。実際の接続先アドレスと異なる場合もありますが、その場合はサーバー側の設定に根拠が必要です。よく使われるドメイン名を試しに入力するのは避けてください。

SNIはTLSのハンドシェイクで使われ、サーバーが証明書やサイト設定を選択するのに役立ちます。SNIとWebSocketのHostは異なる階層の項目です。一般的な設定では同じドメイン名を使うことがありますが、一方の項目がもう一方を自動的に示すわけではありません。ServerにIPアドレスを指定し、証明書がドメイン名に対して発行されている場合は、通常、本人確認に適切なサーバー名が必要です。SNIを確認せずHostだけを変更すると、HTTP層は通ってもTLS層で失敗することがあります。

iOSでは、外側のTLSや通信方式によってハンドシェイクの手順が増えることがあります。短い接続を頻繁に作り直すと、待ち時間に影響しやすくなります。接続の再利用は一部の再接続コストを抑えられますが、複数のリクエストが同じ通信を共有し、特定の混雑の影響が広がることもあります。常に最適な設定はありません。まず既存サーバーとの互換性を確認し、実際のアプリで挙動を見てください。速度が上がりそうな設定を一度にすべて有効にするのは避けましょう。

長い共有リンクをインポートしたら、画面のスクリーンショットだけでなく、項目を文字でも記録してください。特にTransport、TLS、Host、Path、SNI、Flowの元の組み合わせを残しておきます。サブスクリプションの更新で項目が再生成されることがあり、更新によって作成された項目への直接変更は残らない場合があります。検証が必要なときは独立したテスト項目に複製し、用途を明記してください。次回の更新後に設定が消えたと誤解しないためにも有効です。

TrojanでTLS設定が必要な理由

TrojanはTLSで保護された接続内で認証を行い、プロキシリクエストを転送する設計です。TLSはクライアントからサーバーまでの通信を暗号化し、サーバーの身元を検証します。Passwordはプロトコルの認証に使われ、TLSの代わりにはなりません。パスワードが正しくても証明書名が一致しなければ、TLSの段階で接続が止まることがあります。証明書が正常でもパスワードが違えば、その後の認証に失敗する場合があります。確認するときは、まず安全な通信路を確認してから認証情報を照合してください。

Serverは実際の接続先を指定し、SNIはTLSハンドシェイクで使うサーバー名を示し、証明書は接続先の身元を証明します。既存の情報でドメイン名を使っている場合は、通常そのまま保持し、名前解決で得たIPアドレスに安易に置き換えないでください。ドメイン名は接続先の振り分けや証明書の確認にも使われることがあります。IPアドレスを固定して一時的に接続できても、サーバー移行後に使えなくなる可能性があります。独自のテスト環境で特殊な証明書を使う場合は、明確な信頼関係に基づいて設定してください。検証を無効にする方法を通常のトラブル対応にしないでください。

HTTPプロキシとHTTPSの接続先は別

HTTPプロキシは通常、リクエストの宛先に応じてHTTP通信を転送します。また、CONNECTメソッドで接続先へのバイトトンネルを確立できます。HTTPSサイトにアクセスするときは、一般的にプロキシへCONNECTを要求し、そのトンネル内で接続先とのTLSを確立します。この接続先とのTLSと、クライアントからプロキシまでの通信でTLSを使うかどうかは別の問題です。プロキシ自体への接続が暗号化されていない場合、接続先URLがHTTPSで始まっていても、プロキシ認証情報を含む外側の通信が同じように保護されるわけではありません。

Shadowrocketの項目では、Type、TLS、関連する認証項目を既存の情報に沿ってそれぞれ確認してください。UsernameとPasswordはプロキシの認証情報である場合があり、接続先サイトのアカウント情報を入力する欄ではありません。従来型のHTTP CONNECTは主にTCPを対象とするため、あらゆるUDP通信もプロキシ経由になるとは限りません。より多様な通信を扱う拡張方式もありますが、クライアント、サーバー、設定のすべてが明確に対応している場合に限られます。一般的なHTTPプロキシ設定に、そうした機能があると想定しないでください。

SOCKS5でできること、できないこと

SOCKS5は汎用プロキシリクエスト向けのネゴシエーションプロトコルです。接続先、認証方式、UDP ASSOCIATEなどの操作を指定できます。基本プロトコル自体はデータを暗号化しません。ユーザー名とパスワードによる認証も、通信の暗号化を意味しません。利用するネットワークと外側のセキュリティ条件を確認してください。管理されたネットワークや用途が明確なプロキシ接続に適していますが、「汎用」だからといって、あらゆるサーバーに自動で対応したり、すべての通信を自動的に保護したりするわけではありません。

SOCKS5のUDP転送では、UDP ASSOCIATE、サーバーが返す中継情報、その後のデータ経路も確認する必要があります。TCPの制御接続が確立できても、UDP中継が使えるとは限りません。サーバー側の権限、NAT、ポートの許可状況が結果に影響することがあります。ドメイン名をどちら側で解決するかも確認してください。リクエストでドメイン名を送る場合と、ローカルで名前解決してからIPアドレスを送る場合とでは、名前解決の経路が異なります。実際の動作はクライアントのルーティング、DNS設定、リクエストの種類によって決まります。

モバイル端末でのTLSハンドシェイクには、ネットワークとの往復通信や証明書の処理が必要です。既存の接続を再利用すれば一部の処理を省けますが、電波が弱い場合やネットワークを頻繁に切り替える場合、サーバーが接続を閉じた場合には再接続が発生します。プロトコルが「一般的なHTTPSに見える」からといって、電池消費が少ないとは限りません。同じ作業での接続成功率、バックグラウンドからの復旧速度、端末温度を比べてください。画面の明るさやアプリ自体の動作も考慮します。

プロトコルを単純に順位付けする必要はありません。既存サーバーがTrojanを提供しているなら、TLSとパスワードの組み合わせを確認します。管理されたHTTPまたはSOCKS5の接続先を使う場合は、利用権限、外側の保護、対象となる通信の範囲を確認してください。プロトコル名だけで複雑な構成を選ぶより、サーバーの条件に正しく合わせることが大切です。

プロキシリクエストからIPパケットへ

WireGuardは暗号化されたIPトンネルを基本とし、固定された最新の暗号アルゴリズムと公開鍵による識別を使います。多数の暗号化方式から選ぶ仕組みではありません。接続先へのリクエストを中心とするプロキシプロトコルと比べると、指定した相手にIPパケットを転送する方式です。この仕組みは、対応するネットワーク、アドレス、ルーティングがすでに用意された環境に適しています。ローカルのトンネルアドレス、相手の識別情報、トンネル経由を許可する宛先をまとめて設定する必要があり、サーバーアドレスだけでは不十分です。

WireGuardは通常UDPで通信し、IPトンネル全体を信頼性のあるバイトストリーム一つに固定して包む方式ではありません。プロトコルのシンプルさは実装の複雑さを抑える一助になりますが、Shadowrocketでの実際の性能は、クライアントへの統合、システムのネットワーク拡張、サーバーの処理能力、ネットワーク経路にも左右されます。他のOSでの測定結果をそのままiPhoneに当てはめたり、暗号アルゴリズムが固定されていることだけで、あらゆる用途で省電力だと判断したりしないでください。

Private KeyとPublic Keyの対応関係

Private Keyはローカルの秘密鍵です。公開スクリーンショット、ログ、問い合わせメッセージには記載しないでください。Public Keyは接続相手の識別に使います。両端で鍵の組み合わせを正しく設定し、クライアントにはサーバーの公開鍵を保存し、サーバーにはクライアントの公開鍵を登録します。両方を逆に入力したり、別の端末用の設定をコピーしたりすると、ハンドシェイクに失敗します。Preshared Keyは追加で共有する任意の秘密情報です。両端の設定が一致している場合にのみ使用でき、片側だけで追加してはいけません。

Addressはトンネルインターフェースに割り当てるアドレス、Endpointは接続相手に実際に連絡するための外部または到達可能なアドレスとポートです。役割はまったく異なります。トンネル内のアドレスをEndpointに入力すると、通常、外部ネットワークから最初の接続を確立できません。IPv4とIPv6もそれぞれ確認してください。既存の設定に一方のアドレスファミリーしかない場合、もう一方のアドレスを推測して追加しないでください。DNS設定はドメイン名の解決方法を決めるものであり、Endpointのアドレス欄の代わりにはなりません。

Allowed IPsは全体のルールを置き換えるものではない

WireGuardの仕組みでは、Allowed IPsは相手に対応するパケットの範囲の判定に使われ、どの宛先をその相手へ送るかを決めることもあります。ただし、Shadowrocketのルール全体を表すものではありません。アプリのリクエストがこの項目に入るかどうかは、Global Routingと設定のポリシーによっても決まります。トンネルのハンドシェイクは正常なのに内部ネットワークへ到達できない場合は、宛先が許可範囲に含まれるか、リモート側に転送機能があるか、戻りの経路からクライアントのトンネルアドレスへ返せるかを確認してください。

MTUが大きすぎると、経路上で一部の大きなパケットが正常に通らず、小さなリクエストは成功するのに多くのデータを読み込むと停止することがあります。MTUを小さくすると原因の特定に役立つ場合がありますが、小さいほどよいわけではありません。小さすぎると分割処理が増え、負荷が高まります。まず既存の設定を使い、大きなパケットで再現できる問題がある場合に限って少しずつ変更し、結果を記録してください。実際の原因がDNSやリモート側のルーティングなら、MTUを変えても安定した改善は見込めません。

Persistent Keepaliveは、必要に応じてNATのマッピングを維持します。クライアントがNATの内側にあり、リモート側から連絡する必要がある場合によく使われます。間隔を短くすると無線通信が増え、モバイル端末の待機時の電池消費に影響することがあります。完全に無効にすると、しばらく使わなかった後の最初の通信が遅れる場合もあります。必要かどうかはネットワーク構成と用途に応じて判断し、特定の間隔をすべての端末に推奨する設定として扱わないでください。

WireGuardのトラブル確認では、ハンドシェイクと実際のデータ通信を分けて考えます。ハンドシェイクの成功は、鍵と基本的な経路の一部が機能していることを示しますが、DNS、Allowed IPs、リモート側の転送、宛先から戻る経路まで正しいとは限りません。Wi-Fiとモバイル回線を切り替えた後の復旧が遅い場合は、相手側の更新とUDPの到達性を確認してから、Keepaliveの設定を調べてください。認証項目を確認する前に、アドレス、ルーティング、MTUを同時に変更しないでください。

QUICを採用する理由

Hysteria2はQUICベースの通信方式を使用します。QUICはUDP上で動作し、安全な接続や複数ストリームなどの機能を提供します。遅延やパケットロス、帯域の変動があるネットワークでの通信性能を考慮し、対応する輻輳制御方式を組み合わせています。UDPを使うからといって、信頼性の確保をすべてアプリの利用者に委ねるわけではありません。QUIC自身が必要な確認応答、パケットロスの検出、再送を行います。「UDPだからデータが自由に失われる」「必ずTCPより速い」と単純に考えないでください。

QUICの独立したストリームの仕組みは、信頼性のあるバイトストリームの順序どおりの配信によって生じる、一部のストリーム間のブロッキングを抑えられます。ただし、同じストリーム内には順序の制約があり、すべてのストリームが利用可能な帯域と輻輳の影響を受けます。ローカルネットワークがUDPを制限している場合や、UDPの速度やマッピングに厳しい制約がある場合は、プロトコルの利点が表れないことがあります。サーバーがHysteria2に対応していても、現在のネットワークで接続できるとは限りません。まずポート、UDPの経路、認証情報を確認してください。

認証、セキュリティ、追加条件

ServerとPortは実際のサーバーを指定します。認証項目は既存の情報に合わせてください。QUICを使う場合も、TLS関連のサーバー名や証明書検証を正しく設定する必要があり、身元確認を省略できるわけではありません。情報に難読化の条件が含まれる場合は、有効化の有無と対応する秘密情報も照合してください。両端の設定が一致しないと、通信の初期段階で失敗することがあります。難読化用のパスワード、認証パスワード、証明書名は役割が異なるため、代わりに入力しないでください。

Hysteria2と旧世代のプロトコルは、名称が似ているだけで同じように使えるわけではありません。インポート後にTypeを確認し、共有リンクから読み取られた種類が現在の情報と一致するか確かめてください。サーバーが要求するALPN、証明書の条件、その他の拡張項目がクライアントに正しく反映されていないと、ハンドシェイクに失敗することがあります。リンクを認識できない場合は、理解できない項目を削除して何度もインポートするのではなく、情報の提供元にある設定項目の説明を確認してください。

帯域の設定値は速度を保証しない

設定によっては、特定の輻輳制御方式の動作に影響する上り・下りの帯域情報が指定されています。これはアルゴリズムが参考にする条件であり、ネットワークの帯域を割り当ててもらう設定ではありません。数値を上げても、その分だけ通信速度が上がるわけではありません。実際の回線能力を大きく上回る値を入力すると、キューの増加、パケットロス、再送が発生し、操作への応答が遅くなることがあります。低すぎる値も利用可能な帯域を制限する可能性があります。クライアントとサーバーが使う方式での値の意味を確認し、別のネットワークの数値をそのまま流用しないでください。

単位も重要です。毎秒メガビットと毎秒メガバイトは別の単位です。通信事業者が示す回線速度、システムのダウンロード表示、設定項目では単位が異なる場合があります。上りと下りも分けて確認してください。モバイル回線の通信速度は非対称なことがよくあります。一度のダウンロード速度だけでは、継続的なアップロード能力は分かりません。ビデオ通話やファイルのアップロードでは、上り側のキューが他のリクエストに影響することもあります。変更する前に元の値を保存し、戻せる基準を残してください。

iOSで高い速度の通信を続けると、無線機能とプロセッサーが動作し続けます。UDPベースの通信、ユーザー空間での処理、パケットロスからの復旧も負荷を増やす要因です。一方、同じ作業を短時間で終えられれば、無線通信の時間が短くなる場合があります。瞬間的な消費電力だけで総電力を判断しないでください。短い作業、連続ダウンロード、バックグラウンドでの待機を分けて観察し、最大速度での通信とアイドル状態を直接比べてプロトコルの電池消費を結論づけないようにします。

UDPの通信が不安定なネットワークでは、比較用に別の既存の接続設定も残してください。帯域の設定値を何度も上げるのは避けましょう。ネットワーク経路が通らない、証明書が一致しない、アルゴリズムの設定が適切でない、といった問題はそれぞれ別の階層で確認します。まず正しく接続できる状態にしてから転送速度を調整すると、無駄な試行を減らせます。

項目ごとの役割からインポート結果を確認

サブスクリプションをインポートすれば手入力を減らせますが、内容の確認は必要です。四つのグループに分けて確認してください。アドレスにはServerとPort、認証情報にはPassword、UUID、鍵、通信方式にはTransport、Host、Path、セキュリティにはTLS、SNI、証明書の検証設定が含まれます。プロトコルによって必要な項目は異なります。すべてを「そろえる」ために、存在しない項目を追加する必要はありません。同じ名前の項目でも、使用中のプロトコルに応じて意味が異なる場合があります。特にPasswordと各種の追加秘密を混同しないでください。

アドレスに含まれるドメイン名は、ローカルのDNSで先に解決される場合もあれば、クライアントのDNSポリシーの影響を受ける場合もあります。接続先サイトのドメイン名は、別の経路で解決されることもあります。サーバーのドメイン名を解決できないと、プロキシにまったく接続できません。接続先のドメイン名の解決に問題がある場合は、プロキシにはつながるのに特定のサイトだけ開けないことがあります。この二つを混同しないでください。まず、どのドメイン名の解決に失敗したかを確認し、該当するDNS経路を調べると、すべてのDNS設定を変更するより原因を特定しやすくなります。

三つのモードでリクエストの経路を決める

Global RoutingのConfigは、現在の設定に含まれるルールに従ってリクエストを処理します。Proxyは処理可能なリクエストをプロキシ経由にし、Directは直接接続します。中国語での設定、プロキシ、直接接続は、それぞれ画面上のこれらの用語に対応します。「プロキシ経由」にするには有効な項目とポリシーの選択も必要です。Proxyに切り替えるだけでサーバーが自動的に見つかるわけではありません。ConfigではリクエストがDirectに振り分けられることもあります。Webサイトを開けるだけでは、選択したプロトコルが実際に通信に使われた証拠になりません。

ルールは通常、上から順に照合されます。より具体的な条件は、意図した動作になる位置に配置してください。DOMAIN-SUFFIXはドメインのサフィックスに、GEOIPはIPアドレスの地域データベース判定に、IP-CIDRはアドレス範囲に一致します。FINALは、それまでのルールに一致しなかったリクエストを処理します。ドメインルールとアドレスルールでは使用する情報が異なり、アドレスの判定に名前解決結果が必要な場合もあります。データベースの範囲、IPv6、実際の接続先アドレス、名前解決のタイミングによって、ルールの適用結果が変わることがあります。ルールのキーワードをプロトコルの項目と混同しないでください。

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

この例はShadowrocketの設定で使うルール行の構造を示すもので、設定全体をそのまま置き換えるための完成版ではありません。ここで使っているPROXYとDIRECTはポリシー名です。実際に使うには、有効なプロキシの選択先やその他の必要項目も設定してください。1行目は例のドメインサフィックスにプロキシを適用し、2行目は指定したプライベートアドレス範囲へ直接接続し、3行目はアドレスの地域情報で判定し、最後の行は他のルールに一致しないリクエストを処理します。順序の説明だけを目的とした内容で、バックアップしていない個人設定を上書きしないでください。

設定ファイルとサブスクリプションは役割が異なる

サブスクリプションは通常サーバー項目を更新し、設定ファイルにはルールやその他の設定を保存できます。両者は別のものです。サブスクリプションを更新してサーバー項目が使えるようになっても、Configの参照先が古いポリシーのままなら、期待どおりに動作しないことがあります。逆に、ルールファイルが正しくても項目の認証情報が期限切れなら、リクエストをプロキシ経由にできません。トラブルの確認では、現在使っている「項目」と「設定」を別々に記録してください。表示名だけを保存するのは避けましょう。同じ名前が更新後にも使われることがあります。

IPv6にも注意が必要です。サーバーのドメイン名からIPv4とIPv6の両方のアドレスが返ることがあり、接続先サイトもデュアルスタックで到達可能な場合があります。ローカルネットワークで一方のアドレスファミリーが不完全だと、接続が不安定になったり、一部の接続先だけ長く待たされたりします。すぐにプロトコルの非対応が原因だと決めつけないでください。実際に選択されたアドレスを確認し、それぞれの経路を個別に検証します。ルールのIP-CIDRとIP-CIDR6もアドレスファミリーに合わせて使ってください。IPv4用の範囲指定でIPv6まで対象になるわけではありません。

プロトコルを検証するときは、選択したポリシーに確実に入るテストリクエストを使い、接続記録で実際の経路を確認してください。その後、普段使うConfigに戻し、よく使うアプリで再テストします。一時的なテスト用モードを最終設定と取り違えないためです。プロトコルで接続できることは基本条件にすぎません。ルーティングと名前解決が正しく行われて、初めて一連の動作が完了します。

まず条件を整理し、組み合わせを比較

最初に考えるのは「どのプロトコルが最速か」ではなく、既存のサーバーが実際にどのような組み合わせを提供しているかです。利用可能なプロトコル、UDPの条件、証明書の要件、用途を挙げ、互換性のないものを除外します。使える設定が一つだけなら、まずその設定を正しく使ってください。複数の組み合わせを比べる場合は、サーバーの場所、時間帯、テスト内容をできるだけそろえ、サーバー性能の差をプロトコルの性能差と取り違えないようにします。

安定したWi-FiでのWeb閲覧では、短いリクエスト、DNS、接続確立が重要です。長時間のファイル転送では、継続的な速度と輻輳が影響します。Wi-Fiとモバイル回線を頻繁に切り替える場合は、復旧にかかる時間やアプリが再接続できるかを確認してください。既存の内部ネットワークにアクセスする場合は、アドレス設計、戻りの経路、権限も考慮します。WireGuardのIPトンネル、汎用プロキシのリクエスト方式、QUICの通信上の特徴にはそれぞれ適した条件があります。名称だけで一律に順位付けしないでください。

六つの段階で障害の範囲を絞る

第1段階では、ローカルネットワークの基本状態を確認します。Directでネットワーク自体に必要な接続機能があるか、ネットワークへのログインが必要かを調べてください。第2段階では、Serverのドメイン名解決とポートの条件を確認します。特にTCPとUDPを区別してください。サーバーにまったく接続できない場合、UUID、Password、ルールの順序を変更しても改善しないことがほとんどです。エラーの状況を記録し、別の利用可能なネットワークで比較してください。設定項目を次々と大量に試すのは避けましょう。

第3段階では、システム時刻、SNI、証明書のドメイン名、証明書チェーンなど、TLSと証明書を確認します。第4段階では、Typeに応じて暗号化方式、パスワード、UUID、鍵の組み合わせなどの認証項目を確認してください。ハンドシェイクのエラーと認証エラーは、画面上ではどちらも接続失敗に見えることがあります。ログに記録された段階をもとに判断してください。ログだけでは判断できない場合は、その不確実性を明記します。「タイムアウト」だけを根拠に、パスワードが正しい、または間違っていると決めつけないでください。

第5段階では、ルーティングとDNSを確認します。テストリクエストが選択したポリシーに入り、接続先のドメイン名を正しく解決できること、必要なアドレスファミリーが使えることを確かめてください。第6段階で、MTU、UDP中継、輻輳制御の設定、サーバー負荷、大容量通信の制限など、継続的な転送の問題を調べます。前の段階に問題がないことを確認してから性能に関する設定を調整してください。小さなリクエストは成功するのに大きな通信で失敗する場合は、再現可能なタスクを使って検証し、Connectivity Testを一度繰り返すだけで判断しないでください。

電池消費と速度を意味のある条件で比較する

同じ端末で電波状況をできるだけそろえ、テストと無関係な大容量通信を停止して、同じWebページのセットや同じサイズのファイル転送を行います。開始から完了までの時間、失敗回数、ネットワーク切り替え後の復旧、システムのバッテリー統計における一定時間の変化を記録してください。画面の明るさ、電波状況、前面で動作するアプリが異なる結果を比べないでください。一時的な温度変化や一度だけの電池残量の変化には他の原因も考えられます。参考になる結果を得るには、繰り返し観察してください。

On Demandは、「条件に応じて接続を開始する」機能であり、「すべてのアプリの接続を常に維持する」機能ではありません。システムによるネットワーク切り替え、アプリの一時停止、リモート側からの切断によって、接続を再確立する場合があります。Keepaliveの頻度を上げると、アイドル状態からの復旧が改善することもありますが、待機中の通信が増える可能性があります。長時間の接続を再利用すればハンドシェイクを減らせますが、複数のリクエストが同じ輻輳経路を共有することもあります。まず元の設定で動作を確認し、明確で再現可能な問題がある場合に限って変更してください。

検証済みの基準設定を一つ残し、その後で項目を一つずつ調整してください。プロトコルの設定はこのページの該当章で、初回接続の手順は使い方ガイドで、繰り返し起きる問題はトラブルシューティングで確認できます。入手や初回インストールの問題についてはインストール時の許可設定をご覧ください。適切な結論は、「このネットワークで、この設定を使い、このタスクを完了できた」です。すべての端末やネットワークに共通する、永続的な最適プロトコルを決めることではありません。