この記事では、利用中のサービスから接続情報やサブスクリプションを入手済みで、ShadowrocketのTrojan設定を確認したい方を対象に、接続先、認証パスワード、TLSのサーバー認証を整理します。Home → Add Serverの順に設定し、タイムアウト、証明書エラー、認証失敗を切り分けます。当サイトでは接続先やサブスクリプションの提供・販売・推奨は行っていません。
Trojan接続でTLSとパスワードがそれぞれ確認すること
ShadowrocketのTrojanタイプは、対応するTrojanサーバーへの接続に使います。一般的な接続では、まずTCP接続を確立し、次にTLSハンドシェイクを行い、暗号化された通信経路でTrojanの認証情報と接続先へのリクエストを送信します。アドレスを名前解決でき、ポートに接続できても、それはネットワーク上の前段が機能していることを示すだけで、証明書の検証やパスワード認証の成功を意味しません。
TLSは通信を暗号化し、サーバーの身元を確認します。Trojanのパスワードは、サーバーがクライアントを認証するために使います。両者は代用できません。パスワードが正しくても証明書名の不一致は解消されず、証明書が有効でも誤ったパスワードでは認証されません。調査時は「ポートに接続できない」「TLSハンドシェイクに失敗する」「ハンドシェイク後にリクエストが失敗する」を分けて記録してください。
結論：まず失敗している層を特定する
接続がタイムアウトする場合はアドレスとポートを確認します。証明書エラーの場合はSNI、証明書、端末の時刻を確認してください。パスワードの変更やAllow Insecureの有効化を、あらゆる失敗に対する万能策として扱わないでください。
Add ServerでTrojanの設定項目を順に入力
サーバーを手動で追加するにはHomeから操作します。Configでルールファイルを編集するわけではありません。Configは設定ファイルやルールの管理に使い、このセクションではサーバーへの接続情報を入力します。始める前に既存の接続情報をそのまま控え、ポートが443という理由だけで判断せず、提供元が示すタイプがTrojanであることを確認してください。
-
サーバー追加画面を開く
Homeの右上にある「+」をタップしてAdd Serverを開きます。Typeを開いてTrojanを選び、設定画面に戻ります。サブスクリプションから追加された項目を編集する場合は、後で更新前後を比較できるよう、先に元の値を記録してください。
-
接続先アドレスを入力
Addressには接続情報に記載されたドメイン名またはIPアドレスを、Portには対応するポート番号を入力します。Addressには
https://やパス、ポート番号を含めません。たとえばドメイン名と443は、それぞれ別の項目に入力します。 -
認証パスワードを確認
PasswordにはTrojan専用のパスワードを入力します。App Storeアカウントのパスワードや、サービスのウェブサイトへのログインパスワードを使わないでください。大文字・小文字、前後の空白、改行の有無を確認します。手入力する場合は元のパスワードを使い、共有リンク内のパーセントエンコードされた文字列をそのままパスワードとして入力しないでください。
-
TLSの設定を確認
手元の接続情報に従ってSNIを入力し、Allow Insecureがオフになっていることを確認します。追加の通信オプションが含まれている場合も、一つずつ値を合わせてください。アドレスとパスワードだけをコピーして、ほかの項目を無視しないようにします。
-
保存して接続を確認
Doneをタップして保存し、Homeに戻って該当する項目を選びます。初めて接続を有効にする際は、システムの案内に従ってVPN構成を許可してから、実際のリクエストを確認します。保存できたことは設定値が登録されたことを示すだけで、サーバーが接続を受け付けたことを意味しません。
Address、SNI、証明書名の対応関係
Addressはネットワーク接続先を指定します。SNIはTLSハンドシェイクで送るサーバー名の情報で、同じサーバー上に複数のサイトがある場合に、対応する証明書を選ぶために使われます。SNIはウェブサイトのURLではなく、プロトコル、ポート、パスを含みません。また、アクセスできるドメイン名を適当に選んでも機能するものではありません。値は実際のサーバー設定に基づいて指定します。
サーバーから証明書を受け取った後も、クライアントはサーバーの身元を検証します。想定するサーバー名が証明書に記載された名前と一致している必要があります。通常は証明書のSubject Alternative Nameを確認します。SNIを別のドメイン名に変えても証明書の内容は変わらず、ネットワークリクエストがそのドメインに対応するサーバーへ自動的に転送されることもありません。
| 項目 | 例または設定値 | 確認ポイント |
|---|---|---|
| Type | Trojan |
サーバーで実際に使用されているプロトコルと一致させる |
| Address | edge.example.com |
接続先のドメイン名のみ。URLのパスは含めない |
| Port | 443 |
設定例であり、プロトコルで必須のポートではありません |
| Password | 自身のTrojan認証パスワード | 元の文字列を保ち、空白を追加しない |
| SNI | tls.example.com |
AddressとSNIの値が異なる場合の例。実際の値はサーバーから指定されます |
| Allow Insecure | オフ | 通常の証明書検証を維持 |
上の表のドメイン名は項目間の関係を説明するための例であり、そのまま接続に使える設定ではありません。AddressにIPアドレスを使う場合は、手元の接続情報でSNIが指定されているか特に確認してください。証明書が特定のドメイン名のみを対象としているのに、クライアントがIPアドレスで身元を検証すると、名前が一致しない場合があります。SNIを正しく入力してもエラーが出る場合は、証明書の期限切れ、サーバーから誤った証明書が返されていないか、中間証明書チェーンが完全かどうかも確認してください。
Allow Insecureの役割と証明書検証を維持する判断
Allow Insecureは「互換性を高める」ための一般的なパフォーマンス設定ではありません。有効にするとTLS証明書の検証が緩和され、通常の検証によって接続先の身元を確認できなくなります。DNSや誤ったポート、パスワード、サーバーの停止を解決するものではなく、日常的な接続エラーに対して最初に変更する項目でもありません。
Allow Insecure：オフ
推奨証明書検証を維持します。証明書エラーが発生した場合は、SNI、端末の時刻、証明書の有効期間、サーバーの証明書チェーンを修正し、通常の検証を通過できる状態にします。
適した用途：日常利用、信頼できる証明書を使用するサーバーの設定
Allow Insecure：オン
証明書検証が緩和され、サーバーの身元を確認する能力が低下します。有効にした後にリクエストが成功しても、証明書検証がそれまでの阻害要因だった可能性を示すにとどまり、設定が安全になったことや問題が解決したことの根拠にはなりません。
適した用途：リスクを理解した保守担当者が、管理された環境で短時間の原因切り分けに使う場合。日常的な設定には使用しないでください。
結論：証明書の修復を完了条件にする
Allow Insecureを有効にした場合にしか接続できないときは、サーバーの保守担当者に、実際に返される証明書、証明書が対象とする名前、証明書チェーンを確認してもらってください。修正後はこの項目をオフに戻し、リクエストを再確認します。
症状別の確認：タイムアウト、証明書エラー、認証失敗
一度に変更する項目は一つにし、ネットワーク環境、選択した項目、Global Routingの状態、エラー内容を記録してください。遅延テストに結果が表示されても、Trojanのリクエストが認証まで正常に完了したとは限りません。アクセス可能と分かっている宛先へのリクエストも確認し、すべての宛先で失敗するのか、一部だけ失敗するのかを切り分けます。
入力後ずっとタイムアウトします。パスワードが間違っていますか？
必ずしもそうとは限りません。まずHomeで該当する項目を開き直し、AddressとPortを確認して、サーバーが実際にそのポートで接続を待ち受けているか確認します。Addressがドメイン名の場合は、現在のネットワークで名前を解決できるかも確認してください。まず基本的な接続が可能か確かめてから、TLSとパスワードを確認します。複数の項目を一度に置き換えないでください。
証明書名が一致しないと表示されます。どこを変更すればよいですか？
まず、SNIがサービス提供元から指定された名前と一文字ずつ一致しているか確認し、https://、パス、末尾の空白が含まれていないことを確かめます。一致している場合は、保守担当者に実際に返される証明書の名前を確認してもらってください。同じアドレスで複数のTLSサイトを運用していると、SNIが誤っているために別のサイトの証明書が返されることがあります。
証明書の有効期間内なのに、なぜ検証に失敗するのですか？
有効期間が正常であることは、条件の一つにすぎません。まずシステムのSettings → General → Date & Timeで端末の時刻を確認し、次に保守担当者へ中間証明書チェーンと信頼元の確認を依頼してください。名前の不一致、チェーンの不備、端末時刻の誤りは、パスワードを変更しても解決しません。
接続直後に切断されます。パスワードはどう確認すればよいですか？
項目のPasswordを開き、信頼できる元の接続情報からもう一度コピーして、大文字・小文字、改行、前後の空白を確認します。共有リンクから手作業で項目を分けた場合は、エンコードされた文字列をそのまま入力していないか確認してください。切断されたという状況だけではパスワードの誤りと断定できません。保守担当者にサーバーログを確認してもらい、認証結果を確かめてください。
Trojanの項目を選択したのに、リクエストが直接接続されるのはなぜですか？
まずHome → Global Routingを確認します。Directは直接接続、Configは現在の設定ルールに従って通信経路を決定し、Proxyはリクエストをプロキシポリシーに渡します。Sceneの動作は設定されたシーンによって異なります。項目を選択しただけでは現在のルーティング設定は変更されないため、リクエストに実際に適用されているポリシーも確認してください。
接続できた後に確認するルールと自動接続の状態
Trojanの設定を確認できたら、日常利用のルーティング設定を見直します。Global RoutingでConfigを使用している場合、ルールは上から順に照合されます。FINALはそれ以前のルールに一致しなかった場合の最終処理であり、すべてのリクエストが必ず現在のTrojan項目を経由するという意味ではありません。ルールが指定するポリシーグループと、その選択内容も確認してください。
- 現在の設定を確認：Configで、ルールの内容を表示しているだけの未有効ファイルではなく、実際に使用中のファイルを確認します。
- ルールの振り分け先を確認：
DOMAIN-SUFFIX,example.com,PROXYは、ドメインのサフィックスで照合し、PROXYポリシーに渡す指定です。そのポリシーが最終的にどのサーバーを選択するかは、設定で確認してください。 - 最終ルールの動作を確認：
FINAL,DIRECTは、それ以前のルールに一致しなかったリクエストを直接接続します。これだけでTrojan接続の失敗とは判断できません。 - 自動接続の条件を確認：Settings → On Demandで、設定済みの接続条件を確認します。On Demandは条件に応じて接続を開始する機能であり、サーバーのパスワード、SNI、証明書を修正する機能ではありません。
- 後から確認できる記録を残す：変更した項目と結果を記録します。エラー情報を共有する際はPasswordとサブスクリプション内の認証情報を隠し、設定情報全体を公開しないでください。
故障している層の判断に迷う場合は接続トラブルシューティングを参照してください。ルールやポリシー名については用語集をご覧ください。サブスクリプションの更新後に同じ問題が再発した場合は、証明書検証を無効にする前に、更新前後のアドレス、ポート、SNI、通信設定を比較してください。