この記事は、サービス提供元から接続情報を入手し、ShadowrocketにTrojanを手動で追加する方向けです。サーバーアドレス、TLSで使うホスト名、プロトコル認証用のPasswordを区別し、Add Serverの各項目に入力して接続を確認する手順と、失敗した段階に応じた確認方法を説明します。サブスクリプションやノードはサービス提供元から入手してください。記事中のドメインや設定値は項目を説明するための例であり、接続には使用できません。
Trojanの仕組み：TLS接続の確立後にプロトコル認証
Trojanは、プロキシプロトコルのデータをTLSで暗号化された接続に載せます。一般的な基本接続ではTCPを使い、クライアントがサーバーのアドレスとポートに接続した後、TLSハンドシェイクと証明書検証を行い、Trojanの認証情報と宛先へのリクエストを送信します。サーバーは認証が通ると、トラフィックの転送を開始します。そのため、「ポートに接続できる」「TLSハンドシェイクが成功する」「Password認証が通る」「宛先のWebサイトにアクセスできる」はそれぞれ別の確認結果であり、相互に代用できません。
TLSは接続の暗号化とサーバー認証を担い、TrojanのPasswordはプロトコルへのアクセス認証に使われます。用途は異なります。Passwordが正しくても期限切れの証明書は修復できず、証明書が有効でもPasswordが正しいとは限りません。サーバーが443ポートを使用していても、そのポートで接続を受け付けていることが分かるだけで、Trojanサービスを提供しているとは限りません。
この記事では基本的なTrojan over TLSを例に説明します。サービス提供元からWebSocket、パス、その他のトランスポート設定も指定されている場合、アドレス、ポート、Passwordだけでは接続できないことがあります。同じ設定一式を確認し、別々の設定からSNI、Password、トランスポート項目を組み合わせないでください。
Add Serverの前に：必要な設定情報をそろえる
手動入力の前に、ポート番号やドメイン名だけで判断せず、設定情報にTrojanと明記されていることを確認してください。サービス提供元の設定をすべて保持したい場合はサブスクリプションの読み込みが適しています。手動追加なら項目ごとに設定を確認できます。どちらも同じ接続情報を使い、入力を誰が行うかが異なります。
- サーバーアドレス：完全なホスト名またはIPアドレスを入力します。
https://、パス、ポートは含めません。 - サーバーポート：
443のような数字を入力します。設定資料に別のポートが記載されている場合は、その値を使います。 - Password：大文字・小文字や記号を含め、元の文字列をそのまま入力します。コピー時に前後の空白、改行、引用符が入らないようにしてください。
- SNIと証明書の要件：サービス提供元が指定するTLSホスト名と、追加の信頼設定が必要かどうかを確認します。
- 追加のトランスポート設定：トランスポートの種類、Host、パスが指定されている場合は、必要な項目を確認して該当する設定欄に入力します。
Home → Add Server：アドレス、ポート、Passwordを入力
Homeの右上にある追加ボタンをタップしてAdd Serverを開き、TypeをTrojanに設定してから、下表の項目を入力します。項目の並び順や表示される追加設定は、アプリの現在の画面に従ってください。古い画面の位置を頼りにするのではなく、項目の意味を確認して設定情報と照合しましょう。
| 項目 | 入力する値 | 入力を誤った場合の主な影響 |
|---|---|---|
| Type | サーバー側のプロトコルに合わせてTrojanを選択 | アドレスに接続できても、プロトコル認証に失敗することがある |
| Address | サービス提供元が指定するホスト名またはIPアドレス（例：edge.example.com） | ドメインの名前解決失敗、誤ったアドレスへの接続、または接続タイムアウト |
| Port | サーバーの待受ポート（例：443） | 接続拒否、タイムアウト、または別のサービスへの接続 |
| Password | サービス提供元が指定するTrojanのPassword | TLS接続は成功しても、その後の認証やリクエストに失敗することがある |
| SNI | サービス提供元が指定するTLSホスト名（例：tls.example.com） | 誤った証明書が提示される、またはホスト名の検証に失敗することがある |
| Allow Insecure | 有効な証明書を使う通常の設定ではオフにし、証明書検証を維持 | オンにするとサーバー認証が弱まり、接続設定の誤りも解決しない |
- Type、Address、Portを入力します。Addressにポート番号を重複して含めていないか確認してください。
- Passwordを貼り付け、文字がすべて正しく入力されているか確認します。手動入力する場合は、URLエンコードせずPasswordの文字列をそのまま使ってください。
- 設定資料に従ってSNIを入力し、証明書検証の設定を確認します。追加のトランスポート要件がある場合は、それらも設定してください。
- 保存後にHomeへ戻り、追加した項目を選んで接続を有効にします。VPN構成の追加を求められた場合は、システムの案内に従って許可してください。
ポート番号が同じでも、設定を互いに置き換えられるわけではありません。Portを変更してもサーバーの待受設定は自動で変わりません。ポートが記載されていない場合は、一般的なポートを次々と試すのではなく、サービス提供元に確認してください。Passwordはアプリの購入時に使うパスワードでも、デバイスのロック解除用パスコードでもありません。
SNIと証明書検証：接続先アドレスとサーバーの認証名は別
Addressは接続先を指定します。SNIはTLSハンドシェイクでサーバー名を通知する仕組みで、サーバーが適切なサイトと証明書を選ぶために使われます。通常のドメイン設定では、クライアント側で証明書が信頼できること、有効期間内であること、証明書の名前が想定するサーバー名と一致することも検証します。SNIはPasswordではなく、証明書を信頼させる設定でもありません。
| サービス提供元から指定された設定 | 確認方法 |
|---|---|
| AddressとTLSホスト名が同じ | 指定されたホスト名をそのまま入力し、プロトコル名やパスは追加しない |
| AddressがIPアドレスで、別途SNIが指定されている | IPアドレスは接続先の指定に、ホスト名はTLSに使用。それぞれ別に設定する |
| AddressとSNIが異なるドメイン | サービス提供元が指定した組み合わせを維持し、SNIをAddressに変更しない |
| 証明書の検証に失敗 | デバイスの日時、SNI、証明書の有効期間、証明書チェーンを確認し、サーバー側の証明書設定も確認する |
ポイント：証明書エラーが出たら、検証を無効にせず認証名を確認
Allow Insecureはオフのままにし、まずSNIがサービス提供元の指定と完全に一致するか確認します。デバイスの日時が正しいのにエラーが続く場合は、エラーの種類をサービス提供元に伝え、証明書チェーンと有効期間を確認してもらってください。
たとえば、接続先がIPアドレスで、サーバー証明書がtls.example.com向けに発行されている場合、そのIPアドレスを証明書の名前として扱うことはできません。反対に、無関係なWebサイトのドメインを入力しても、サーバーがその証明書を持つことにはならず、サイトの設定が自動で整うわけでもありません。SNIには、その接続で実際にサポートされている名前を指定してください。
独自証明書や特別な信頼設定を使う場合は、信頼方法を個別に確認してください。エラーを一時的に消すために証明書検証を無効にした状態を常用しないでください。TLSが確立していることは、クライアントからそのサーバーまでの接続状態を示すだけで、すべての宛先Webサイトにアクセスできることを意味しません。
保存後に接続を確認：プロトコルとルールの問題を切り分ける
追加に成功したのは設定情報が端末に保存されたという意味であり、サーバー認証の成功を示すものではありません。選択中の項目とGlobal Routingを確認してから、再現可能な方法でアクセスをテストしてください。Configではルールに応じて接続先のポリシーが選ばれ、一部のリクエストはDIRECTになる場合があります。そのため、Webページが開けたことだけではTrojanが使えた証明にはなりません。
- 選択中の項目を確認：Homeに戻り、リスト内の別の項目ではなく、保存したばかりのTrojan設定が選択されていることを確認します。
- ルーティングモードを確認：Global Routingで、現在Proxy、Direct、Config、Sceneのどれが使われているか確認します。プロキシの検証にDirectは適しません。Sceneの場合は、実際に適用されるポリシーを確認してください。
- 切り分けテストを行う：必要な場合に限り、一時的にProxyへ切り替え、自分がアクセス権を持つ既知のHTTPSページをテストします。完了したら元の設定に戻してください。Proxyへの切り替えはルール振り分けの影響を切り分けるためのもので、Passwordの誤りは修正できません。
- リクエスト履歴を確認：リクエスト履歴と表示可能なエラー情報から、名前解決、接続確立、TLS、後続の転送のどの段階で失敗したかを切り分けます。テスト結果の数値はテストの種類に応じて解釈してください。遅延の数値だけで接続全体の可用性は判断できません。
- Configを再確認：Proxyでは使えるのにConfigで問題が起きる場合は、ルールの順序と各ルールのポリシーを確認し、そのリクエストに想定したプロキシが実際に選択されているか確かめます。
ルールは通常、上から順に照合され、最初に一致したルールのポリシーが適用されます。以下はルールの動作を示す例であり、既存のConfigを置き換えるための完全な設定ではありません。例のPROXYは、実際の設定で利用可能なポリシーに対応させてください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTこの例では、example.comとそのサブドメインをPROXYに、それ以外の一致しないリクエストをDIRECTに振り分けます。別のドメインだけを使ってテストすると、Trojanを経由していない可能性があります。Config内のGEOIP、IP-CIDRなどのルールも同様です。まずリクエストがどのルールに一致したかを確認してから、接続先の設定に問題があるか判断してください。FINALはルールの末尾に置きます。
よくある質問：何度も作り直さず、失敗した段階を確認
以下はトラブルシューティングの手がかりであり、特定のエラーを断定するものではありません。同じタイムアウトでも、アドレスに到達できない、サーバーが応答しない、後続のリクエストに応答がないなど、原因は異なります。エラー内容と発生した段階を合わせて確認してください。
アドレスとPasswordを入力しても、接続がタイムアウトするのはなぜ？
Homeに戻って該当項目を編集し、まずAddressにプロトコル名、パス、空白が含まれていないか確認します。次にPortがサービス提供元の設定と一致しているか確認してください。接続が確立していない段階では、Passwordを変更しても原因の特定には通常役立ちません。別の利用可能なネットワークでも同じテストを行い、そのうえでサービス提供元にアドレスとポートの稼働状況を確認してください。
証明書エラーが表示されたら、Allow Insecureをオンにすべき？
まずはオフのままにしてください。デバイスの日時を確認し、設定情報と照らしてSNIを確認します。完全なURLを貼り付けていないことも確かめてください。それでも失敗する場合は、サービス提供元に証明書の名前、有効期間、証明書チェーン全体を確認してもらいましょう。検証をスキップしても、誤ったポートは修正されず、想定したサーバーに接続した証明にもなりません。
TLSエラーはないのにWebページが開かない場合、まず何を確認する？
まず選択中の項目とGlobal Routingを確認し、次にPasswordに余分な空白がないか、追加のトランスポート設定が漏れていないか確認します。Proxyでは正常でConfigでは異常がある場合は、ルールとポリシーを確認してください。どちらのモードでも失敗する場合は、リクエスト履歴を参照しながら認証とサーバー側の転送を確認します。
サブスクリプションにTrojanがある場合、手動でも追加する必要はある？
通常は必要ありません。まずサービス提供元から入手したサブスクリプションを使い、読み込まれた設定がすべて揃っているか確認してください。手動でテストする必要がある場合は、別の名前で個別に保存します。サブスクリプションを更新しても、別途作成した手動設定は通常同期されません。Passwordやアドレスが変更された場合は、それぞれ確認してください。
接続に失敗したとき、SNIを任意のドメインに変えてもよい？
任意のドメインを汎用的な修正値として使うことはできません。SNIはサーバーが選択するTLSサイトに影響し、証明書もサーバー認証の要件を満たす必要があります。サービス提供元が指定した値に戻し、証明書やネットワークの問題を確認してください。追加のHostやパスが指定されている場合も、同じ設定一式の組み合わせを維持します。