ShadowrocketでTrojanを追加する方法｜仕組みとAdd Serverの設定項目

この記事の要点

この記事は、iPhoneやiPadでShadowrocketを使い、利用中のサービスとTrojan設定情報をすでにお持ちの方向けです。追加時は元の設定情報に従ってAddress、Port、Password、SNIを入力し、証明書の検証は有効にしておきます。接続できない場合は、アドレスの名前解決、ポート、TLS、認証、ルールと振り分けの順に確認してください。Allow Insecureを有効にして問題を回避しないでください。他のプラットフォームでも各項目の意味は参考になりますが、画面の位置は実際のクライアントでご確認ください。

1. TrojanとTLS：接続の流れ

Trojanはプロキシプロトコルで、TLSはクライアントとサーバー間の通信を暗号化し、サーバーの身元を認証します。一般的なTrojan接続では、まずTCP接続を確立し、TLSハンドシェイクを行った後、暗号化された通信路で認証情報と接続先アドレスを送信します。TLSハンドシェイクが成功しても、安全な通信路が確立したことを示すだけで、パスワードが正しいことや接続先のWebサイトにアクセスできることを保証するものではありません。

サーバーの名前解決 TCP接続 TLSハンドシェイク Trojan認証接続先への転送

ここでいうTLSは、プロキシサーバーがすべてのHTTPSページをユーザーに代わって復号するという意味ではありません。HTTPSサイトにアクセスする際は、通常、ブラウザーと接続先サイトの間でも別途TLS接続が確立されます。TrojanのTLSは、デバイスからプロキシサーバーまでの外側の通信路です。2つの接続では証明書も障害箇所も異なるため、サーバー証明書のエラーとWebサイトの証明書エラーを混同しないでください。

一般的な設定ではTCPの443番ポートが使われますが、443はプロトコルで定められた必須の値ではありません。サーバーが別のポートを待ち受けている場合は、クライアントにもその値を入力してください。TrojanはQUICと同じものではありません。設定にUDP転送の記載があっても、通信方式を独断でHysteria2に変更したり、すべてのゲームや音声アプリで同じように動作すると想定したりしないでください。

443

よく使われるTLSポート（実際の値はサーバー設定によって異なります）

5項目

Address、Port、Password、SNI、Allow Insecureを確認

2層

HTTPSアクセスではプロキシのTLSとWebサイトのTLSを区別

2. Add Server：事前準備と追加手順

まず、すでにお持ちの設定情報からサーバーアドレス、待ち受けポート、パスワード、TLS名の指定を確認します。情報がサブスクリプションのみの場合は、名前やスクリーンショットから設定を推測せず、既存のサブスクリプションからインポートしてください。手入力した設定とサブスクリプションから追加した設定では、更新時の管理方法が異なる場合があります。変更前に、どの項目を編集しているか確認しましょう。

追加画面を開きます。Homeで右上の追加ボタンをタップし、Add Serverを開いてTypeをTrojanに設定します。Trojanのパスワードを、他のプロトコルのUUIDやID欄に入力しないでください。
Addressを入力します。ホスト名またはIPアドレスのみを入力します。例：example.com。https://、Webページのパス、サブスクリプションのクエリパラメーターは追加しないでください。この記事のドメイン名は書式の説明用であり、利用可能なサービスではありません。
Portを入力します。元の設定情報に記載された数値を入力します。サーバーが443を使用すると明記されている場合は、443と入力します。ブラウザーでそのドメインにアクセスできるからといって、プロキシも443で待ち受けているとは限りません。
Passwordを入力します。文字、大小文字、記号を元の設定と完全に一致させてください。コピー時に空白や改行が入っていないか確認します。Password欄にサブスクリプションURLのクエリ文字列全体を入力したり、サービス提供元のWebサイトにログインするパスワードで代用したりしないでください。
TLSの設定を確認します。元の設定情報に従ってSNIを指定します。画面にTLSのスイッチがある場合、通常のTrojan TLS設定では有効にしてください。Allow Insecureは無効のままにし、指定されていないトランスポート拡張パラメーターを追加しないでください。
保存して選択します。保存後にHomeへ戻り、追加した設定を選択してから接続テストを実行します。システムVPN設定を初めて作成するときは、システムの案内に従って権限を許可してください。システム権限の許可とサーバー認証は、別々の手順です。

3. Address、SNI、証明書名の関係

Addressはクライアントが実際に接続するネットワーク上のアドレスを指定します。SNIはTLSハンドシェイクで送信されるサーバー名で、同じアドレス上にあるサービスが適切な証明書を選ぶために使われることがあります。両者は同じ場合が多いものの、必ず一致するとは限りません。SNIを入力しても接続先のネットワークアドレスが変わるわけではなく、誤ったAddressを修正することもできません。

接続先の設定項目

Type: Trojan
Address: example.com（書式の例）
Port: 443（サーバーが実際に待ち受けている場合のみ使用）
Password: ユーザーがすでにお持ちの設定情報をそのまま入力

アドレスはサーバーの場所を、ポートはそのサーバー上で待ち受けるサービスを指定します。

TLSの認証情報

SNI: 元の設定情報で指定されたドメイン名を使用
証明書名: クライアントが検証するサーバー名と一致している必要があります
Allow Insecure: 無効にして証明書検証を維持
デバイスの時刻: 日付、時刻、タイムゾーンが正しいか確認

SNIはハンドシェイクとサーバー名の選択に影響しますが、証明書の信頼性検証に代わるものではありません。

AddressにIPアドレスを指定し、証明書がドメイン名に対して発行されている場合は、通常、設定情報に記載された正しいSNIを指定する必要があります。IPアドレスをそのままSNIにコピーしないでください。また、証明書が有効期間内であり、信頼できる証明書チェーンを構成できる必要があります。ドメイン名の入力が正しくても、これらの条件を満たすとは限りません。設定情報にサーバー名の指定がない場合は、無関係なドメインを次々に試すのではなく、元の設定提供元に確認してください。

Allow Insecureは証明書検証を緩和する設定であり、「より多くのネットワークに対応する」ための汎用オプションではありません。有効にすると不正な証明書でも接続できる場合がありますが、サーバーの身元確認が弱まります。証明書の問題がある場合は、SNI、デバイスの時刻、証明書の有効期間、サーバー側の証明書チェーンを確認してください。個別の証明書信頼設定が必要な環境では、その環境の証明書導入手順に従い、検証を長期間無効にしたままにしないでください。

4. 保存後のテスト：プロトコル障害とルール不一致を見分ける

追加が成功したという表示は、設定が保存されたことを示すだけです。Homeに戻り、追加したTrojan設定が選択されていることを確認してからConnectivity Testを実行してください。テスト結果は、テスト先、ネットワーク経路、テスト方法によって異なります。遅延時間が表示されても、すべてのWebサイト、UDPアプリ、ルール設定が検証されたわけではありません。

接続状態を確認します。Homeの接続スイッチをオンにし、すぐに切断されないか確認します。システムVPN接続がまだ確立されていない場合は、リモート側のポートを変更する前に、権限やローカル設定の問題を解決してください。
一時的に振り分けの影響を切り分けます。利用が認められたネットワークの範囲内で、Global Routingを一時的にProxyに切り替え、選択中の設定で明確なテスト先にアクセスします。Proxyは主にルール選択の影響を切り分けるためのもので、TLSやパスワードの誤りは修正しません。
Configに戻します。設定が利用できることを確認したら、Global RoutingをConfigに戻し、Configで実際に有効になっている内容を確認します。Directではリクエストがプロキシを経由しない可能性があるため、Trojanの転送確認には適しません。
自動接続の条件を確認します。トラブルシューティング中はSettings → On Demandを確認し、自動接続条件によってテスト状態が変わらないようにします。確認後は元の設定に戻してください。On Demandは接続を開始する条件を管理するもので、PasswordやSNIの誤りを修正する機能ではありません。

以下はルールの照合順を説明するための実際のルール構文で、利用可能なサーバー情報は含まれていません。example.comとそのサブドメインをPROXYに、文書用に予約されたアドレス範囲をDIRECTに振り分け、それ以外のリクエストもPROXYに送ります。このルールは既存設定の[Rule]セクションに追加し、設定ファイル全体をこの記述で置き換えないでください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

ルールは上から順に評価され、最初に一致したルールが適用されると、後続のルールは確認されません。FINALはどのルールにも一致しない場合の最終処理を指定します。ここでのPROXYはポリシー名であり、サーバーアドレスでもTrojanのパスワード入力欄でもありません。現在のポリシーで、テスト対象の設定が最終的に選択されているか確認してください。ProxyではアクセスできるのにConfigではできない場合は、ルールの一致、ポリシーの選択、DNSを優先して確認し、すぐに同じサーバー設定を入力し直さないでください。

5. エラーが起きた段階からタイムアウトや認証失敗を調べる

問題が発生した段階に応じて、原因の範囲を絞り込みます。クライアントのエラー表示は概要にすぎない場合があり、「タイムアウト」という表示だけでパスワードの誤りと判断できません。一度に変更する項目は1つにし、変更前後の状況を記録してください。Wi-Fiとモバイル通信を切り替えてテストする場合も、同じ設定と同じ接続先を使い、条件を同時に変えすぎないようにします。

確認できる症状	まず確認する項目	次に行うこと
Addressを名前解決できない	ドメイン名の入力、現在のネットワークのDNS	URLを誤って入力していないか確認し、ホスト名が元の設定情報と一致しているか確認します。
接続がタイムアウトする、または拒否される	Port、ネットワークへの到達性、サーバーの待ち受け状態	ポートを確認します。同じ設定を使って別のネットワークでも再テストし、サーバー側の状態も確認してください。
TLSまたは証明書のエラー	SNI、デバイスの時刻、証明書チェーン	Allow Insecureは無効のままにし、サーバー名と証明書の設定を確認してください。
ハンドシェイク後に切断される、または認証に失敗する	Password、Type、サーバー側の認証設定	パスワードをコピーし直し、余分な空白がないか確認して、Trojanが選択されていることを確認します。
Proxyでは使えるがConfigでは使えない	ルール、ポリシー、DNS	有効なConfigと、実際のリクエストに適用されたポリシーを確認します。
一部のアプリだけ失敗する	接続先サービス、UDP転送、アプリ独自のネットワーク動作	Webページと該当アプリを別々にテストします。Webページが一度開けただけで、すべての通信が正常とは判断しないでください。

サーバーアドレスをブラウザーで開いてHTTPSページが表示されても、Trojanのパスワードや転送設定が正しいとは限りません。ブラウザーでのアクセスとTrojan認証は別のリクエストです。同様に、特定のテスト先に接続できなくても、サーバー全体が利用できないとは限りません。エラーが発生した段階と、条件をそろえた複数のテスト結果をもとに判断してください。この記事では速度や稼働状況の実測を保証していません。

6. よくある設定ミス

アドレスにhttps://が付いています。そのまま貼り付けてよいですか？

WebページやサブスクリプションのURL全体をAddressに入力しないでください。元の設定情報で実際のサーバーホスト名を確認し、Addressにはホスト名またはIPアドレスのみを入力します。Portは別に指定します。サブスクリプションURLはサブスクリプションのインポート手順で扱うもので、URLの先頭を削除してもTrojanサーバーのアドレスにはなりません。

SNIを空欄にして接続できました。それでも入力が必要ですか？

Addressをもとにデフォルトの名前が使われる設定もありますが、すべてのサーバーで空欄にできるとは限りません。元の設定情報にSNIが明記されている場合は、その値を入力してください。特にAddressがIPアドレスの場合や、サーバー名と証明書のドメイン名が異なる場合は、指定された名前を使用してください。

Allow Insecureを有効にしたら接続できました。このまま使い続けてもよいですか？

長期的な解決策として使わないでください。この変更で接続できた場合、証明書検証の段階に問題がある可能性があります。Allow Insecureを再び無効にし、SNI、時刻、証明書チェーンを確認してください。具体的な証明書エラーは元の設定提供元に相談し、検証をスキップしてサーバー名の誤りを隠さないでください。

サブスクリプションを更新したら接続できなくなりました。追加し直す必要がありますか？

まず更新前後のAddress、Port、SNIと選択中の設定を比べ、Homeで同じ名前の古い設定を選択していないか確認してください。設定内容が変わっている場合は、ユーザーがすでにお持ちの最新情報を使用します。サブスクリプションから作成された設定を手動で変更する場合は、次回更新で上書きされて原因が分からなくならないよう、先に元の値を記録してください。