Shadowrocketの対応プロトコル一覧|Shadowsocks・VMess・VLESS・Trojan・Hysteria2・WireGuard

Shadowrocketで追加できる各プロトコルの項目と用途を、通信方式・暗号化・ハンドシェイクの違いから解説。

この記事の概要

Shadowrocketでは複数の接続プロトコルを利用できますが、プロトコル名が同じでも設定項目をそのまま流用できるとは限りません。接続設定をすでにお持ちの方向けに、認証・通信方式・暗号化・ルーティングの4つの観点から確認方法を解説します。Password、UUID、TLS、UDP、鍵のどれを確認すべきかを把握し、決まった手順で設定を読み込んで接続を確認できます。当サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。

プロトコル・通信方式・ルーティング設定を区別する

プロトコルはクライアントとサーバーの通信方法を決め、Global Routingは通信をどの経路に送るかを決めます。この2つは別の設定です。HomeでTrojanを追加しても、すべてのリクエストが自動的にその項目を使うわけではありません。Configにルールを設定しても、サーバー側にない認証情報が補われるわけではありません。

ShadowrocketはAppleプラットフォーム向けの有料クライアントで、主にiPhoneとiPadで利用できます。入手先はApp Storeのみです。買い切りのクローズドソース商用アプリです。アプリの購入と接続サービスの契約は別です。システム要件と購入対象地域はApp Storeの掲載内容をご確認ください。

レイヤー主な設定項目確認すること
プロトコルと認証Shadowsocks、VMess、VLESS、Trojan種類、PasswordまたはUUIDがサーバー設定と一致しているか
通信方式とハンドシェイクTCP、UDP、WebSocket、TLS、QUICサーバー側で同じ通信方式とハンドシェイク条件が有効か
サーバー項目アドレス、ポート、認証情報正しい接続先に接続しているか
通信の振り分けGlobal Routing、Config内のRule対象リクエストがテストするサーバー項目を実際に使用しているか

ポート番号だけからプロトコルを判断することはできません。443はTLS接続でよく使われますが、443を入力しただけでTLSが有効になるわけではありません。サーバーが別のポートを使用している場合は、既存の設定に記載された値をそのまま入力してください。以下は設定項目を理解するための比較であり、プロトコルの性能を順位付けするものではありません。

Shadowsocks・VMess・VLESS:まず認証情報を確認

この3種類では、最初にTypeと認証情報を一致させ、その後に追加の通信設定を確認します。別のTypeのアドレスやPasswordをそのまま入力しないでください。クライアント側の選択を変えても、サーバーが対応するプロトコルは変わりません。

プロトコル主な項目暗号化と通信方式の確認点
Shadowsocksサーバー、ポート、Password、暗号化方式暗号化方式を一致させる。UDPの利用可否は両端の設定とネットワーク環境による
VMessサーバー、ポート、UUID、暗号化方式、通信設定認証には時刻の一致が必要。WebSocketやTLSを使う場合は関連項目も一致させる
VLESSサーバー、ポート、UUID、通信方式、安全性に関する設定プロトコル自体はペイロードを暗号化しない。安全性は設定で使用する外部の仕組みに依存する

Shadowsocks:暗号化方式を推測で選ばない

ShadowsocksではPasswordと暗号化方式をセットで確認します。たとえば、既存の設定にaes-128-gcmとある場合、独自にchacha20-ietf-poly1305へ変更しないでください。方式によっては鍵の形式にも条件があり、すべての認証情報を任意の長さの通常のパスワードとして扱えるわけではありません。まず読み込み後の設定を保持し、既存の設定と項目ごとに照合してください。

VMess:UUIDとシステム時刻を確認

VMessではUUIDが重要な認証情報として使われます。端末の時刻が大きくずれていると、認証に失敗することがあります。まずシステムの日付と時刻を確認し、次にUUIDが欠けずに入力されているか確認してください。サーバーがWebSocketを使用する場合はPathとHostも照合します。TLSも使用する場合は、サーバー名と証明書の検証条件も確認してください。これらの設定値をUUIDから導き出すことはできません。

VLESS:認証と暗号化は別

VLESSのUUIDは利用者の識別に使われるもので、通信内容が暗号化されていることを意味しません。既存の設定に従ってTLSや対応するセキュリティ設定を確認してください。Flowが設定されている場合は、両端が対応し、同じ設定を使っていることも確認します。VLESSとVMessのどちらもUUIDを使うからといって、Typeだけ変更してほかの設定をそのままにすることはできません。

Trojan・Hysteria2:TLSとUDPをそれぞれ確認

TrojanではPasswordとTLS、Hysteria2ではUDPを利用できるネットワーク環境かどうかが主な確認点です。どちらも「ポートに接続できた」だけでは、プロトコルのハンドシェイクや実際のリクエストが成功したとは判断できません。

プロトコル接続の特徴優先して確認する項目
Trojan一般にTLS接続内で認証とプロキシ通信を行うPassword、TLSのサーバー名、証明書、システム時刻
Hysteria2QUICを使用し、基盤となる通信にUDPが必要認証情報、TLS、UDPの到達性、既存の設定に含まれる追加項目

Trojanでドメインの証明書を使用する場合、接続先アドレスとTLS検証に使うサーバー名が異なることがあります。それぞれ設定どおりに入力してください。たとえば、サーバーアドレスがIPアドレスで証明書がドメイン名に対して発行されている場合、証明書名をそのIPアドレスに置き換えることはできません。証明書エラーが発生したら、検証を無効にするのではなく、名前、証明書の有効性、システム時刻を確認してください。

Hysteria2は、ほかのプロトコルの通信方式をUDPに切り替えるだけのものではありません。独自のハンドシェイクと認証手順があり、別世代のHysteria設定とは併用できません。現在のネットワークでUDPが制限されている場合、通常のWebページやTCPサービスにアクセスできても、Hysteria2の接続を確立できないことがあります。既存の設定に帯域幅やobfuscationの項目がある場合は、その値を照合し、経験則で大きな値を入力しないでください。

ポイント:まずネットワーク環境を確認

同じHysteria2設定が特定のWi-Fiだけで失敗する場合は、まずモバイル通信に切り替えて再テストし、結果の違いを記録します。その後、該当Wi-FiでUDPが利用できるか確認してください。先に認証情報を変更したり、この結果だけでほかのプロトコルの方が速いと判断したりしないでください。

HTTP・SOCKS5・WireGuard:プロキシ接続とトンネルを区別

HTTP、SOCKS5、WireGuardでは設定項目の構成が異なるため、同じアカウント情報を使い回すことはできません。前の2つは一般的なプロキシ接続で、WireGuardは鍵を使ってネットワーク層のトンネルを確立します。接続先のリソースにアクセスできるかどうかは、サーバー側で許可されている転送範囲にも左右されます。

WireGuardのEndpointにはサーバーアドレスとポートを指定し、トンネルアドレスはトンネル内で使用します。両者は置き換えられません。Allowed IPsはアドレス範囲と対向先の選択に関わる設定であり、ドメインルールではありません。ConfigのDOMAIN-SUFFIXをそのまま代用することもできません。トラブル時は鍵の対応関係、UDPの到達性、対向側の戻り経路をあわせて確認してください。

既存の設定を読み込む:Home → Typeを確認

複雑な設定を保つには、手動で作り直すより既存の設定を読み込む方法が適しています。ただし、読み込み後も重要な項目を確認してください。以下は、利用者がすでにサブスクリプションまたは個別の設定を持っていることを前提とします。サブスクリプションはサーバー項目を管理し、Config内の構成ファイルはルールなどの動作を管理します。両者は同じ設定ではありません。

  1. 元の設定を保持する

    現在選択されているサーバーとHome → Global Routingの設定を記録します。変更前に復元できる状態を保ち、トラブルシューティング中に元の接続情報やルールを失わないようにしてください。

  2. 読み込み方法を選ぶ

    接続を1件手動で追加する場合は、Home → 右上の「+」 → Typeの順に進み、既存の設定と同じプロトコルを選びます。サブスクリプションを使う場合は、同じ画面のTypeでSubscribeを選択し、自分のサブスクリプションURLを入力します。

  3. 項目ごとに照合する

    保存後、サーバー、ポート、PasswordまたはUUIDを確認します。続けてプロトコルに応じてTLS、WebSocket、UDP、WireGuardの鍵の項目を確認してください。サブスクリプションを更新した後は、項目がリモート側の内容で置き換わっていないかにも注意します。

  4. 接続して確認する

    Homeに戻り、テストする項目を選んで接続を有効にし、システムの案内に従ってVPN構成の追加を許可します。現在のGlobal Routingの状態を記録し、明確なテスト先にアクセスしてください。リストに表示された遅延の数値だけで結果を判断しないでください。

サブスクリプションの更新失敗とサーバーへの接続失敗は分けて対応します。前者はURLの無効化、tokenの変更、取得経路への到達不能などが原因となることがあります。後者は認証、ハンドシェイク、転送に関する問題が考えられます。既存の項目を保持し、どの段階で失敗したかを確認してからサブスクリプションを更新してください。何度削除して追加し直しても、サーバー側の設定ミスは解決しません。

Global Routingでプロトコルとルールの問題を切り分ける

プロトコルをテストするときは、サーバーと接続先を固定し、ルーティング設定を一度に1つだけ変更します。Home → Global RoutingにあるProxy、Direct、Config、Sceneはルーティングのモードであり、接続プロトコルではありません。Sceneは設定済みのシーンに応じて動作するもので、新しい通信方式が追加されるわけではありません。

Config

推奨

有効になっているConfigルールに従ってリクエストの振り分け先を決めます。ルールはDIRECT、プロキシポリシー、REJECTを指定できます。一致するルールがないリクエストがすべて自動的に直接接続されるわけではありません。

適した用途:有効なルールがあり、日常的に振り分け結果を個別に確認する場合

Proxy

プロキシ経路をグローバルなルーティング先として選び、通常の振り分けルールの影響を切り分ける方法です。システム上のすべての通信が必ず経由することを意味せず、プロトコルの認証エラーも解決できません。

適した用途:選択したサーバーと接続先の疎通を一時的に確認する場合

Direct

リクエストを直接接続で処理します。この状態でWebページが開いても、Homeで選択したプロキシサーバーのハンドシェイクが成功したとは限りません。

適した用途:切り分けの比較対象として、ローカルネットワークと接続先に到達できるか確認する場合

以下はルール構文の例であり、設定全体を置き換えてそのまま使えるものではありません。PROXYは現在の設定内で有効なプロキシポリシーを指している必要があります。ルールは上から順に判定され、FINALはそれまでに一致しなかったリクエストを処理します。

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

DOMAIN-SUFFIXはドメインのサフィックスで、IP-CIDRはIPアドレスの範囲で照合します。GEOIPは地理データベースを使ってアドレスの所属地域を判定します。ProxyではアクセスできるのにConfigでは失敗する場合は、適用されたルール、ポリシー、DNSの結果を確認し、すぐにプロトコルを変更しないでください。テスト後はルーティングモードを元に戻し、テスト設定が後続のリクエストに影響しないようにします。

プロトコル接続でよくある質問

ポートに443を入力しても、ハンドシェイクに失敗するのはなぜですか?

ポート番号でプロトコルは決まりません。Homeで該当項目を編集し、まずTypeを確認してから、TLS、サーバー名、認証情報が必要かを確認してください。WebSocketを使用する場合はPathとHostも確認します。ポートに接続できたことを、ハンドシェイク全体が成功した証拠と考えないでください。

遅延の数値が表示されるのに、Webページが開かないのはなぜですか?

遅延テストで確認できるのは、特定のテスト方法での結果だけです。まずHome → Global RoutingがDirectになっていてテスト対象を迂回していないことを確認し、Proxyに切り替えてルールの影響を一時的に切り分け、同じ接続先にアクセスします。それでも失敗する場合は、DNS、認証、TLS、サーバーの転送処理のどの段階で問題が起きているか確認してください。

Wi-Fiを切り替えた後、Hysteria2またはWireGuardだけ接続できない場合は?

設定は変更せず、モバイル通信に切り替えて再テストします。これらの接続はUDPに依存するため、ネットワーク環境の変化を優先して確認してください。次にSettings → On Demandにネットワークに応じて接続を開始する設定がないか確認します。自動接続の変化が判定に影響しないよう、手動テスト中は関連する条件を記録して一時的に無効にし、テスト後に元へ戻してください。

サブスクリプションの更新後、Typeを元のプロトコルに戻せばよいですか?

Typeだけを変更しても解決しません。まずサブスクリプションに含まれる設定項目全体を確認し、サーバー側のプロトコルが実際に変わったか確認してください。更新内容に問題がある場合は、契約先に問い合わせます。認証、通信方式、TLSの設定は一組で対応させる必要があり、以前のPasswordを残しても接続が復元するとは限りません。

トラブルの記録には、現在のネットワーク、選択中のプロトコル、Global Routing、接続先、失敗した段階を含め、「使えない」とだけ書かないようにします。変更する項目は毎回1つに絞り、同じ接続先で再テストすると、設定・ネットワーク・ルールのどこに問題があるか判断しやすくなります。初回の許可設定や基本操作から確認したい場合は、サイト内の使い方ガイドをご覧ください。

App Storeで正規品を確認