ShadowrocketのTrojan設定方法｜Password・SNI・TLSの確認ポイント

Trojanの設定項目を個別に確認する理由

TrojanはTLSでクライアントとサーバー間の通信を保護し、その接続上でプロトコル認証と転送を行います。一般的なTrojanはTCP上で動作します。TLS接続が確立しても、Passwordの認証に成功したとは限らず、接続先のWebサイトにアクセスできるとも限りません。この3つの段階は分けて確認しましょう。

サーバーアドレスは接続先を、Portはサーバー上の接続先サービスを指定します。SNIはTLSハンドシェイクでサーバー名を通知し、PasswordはTrojanの認証に使います。同じ設定一覧に記載されていても、互いに置き換えることはできません。特に、サブスクリプションURLのtoken、アカウントのログインパスワード、別プロトコルのUUIDをTrojanのPasswordとして使わないでください。

Add Serverで項目を入力する

ここではHomeから手動で追加する手順を説明します。プラットフォームによってフォームの配置は異なる場合がありますが、各項目の役割は同じです。サブスクリプションに必要な設定がすべて含まれている場合は、配信された値をそのまま使ってください。サービス提供元から補足や修正の指示がある場合に限り、該当項目を手動で変更します。

1. フォームを開く

   Home → 右上の「+」→ Add Serverを開き、TypeでTrojanを選択します。ノード名に「TLS」とあるだけでプロトコルを判断せず、まずTypeを確認してください。

2. アドレスを入力する

   Addressにはサービス提供元が指定したホスト名またはIPを、Portには指定されたポート番号を入力します。たとえばポートが443の場合、Portには443だけを入力します。Addressにhttps://、パス、末尾のスラッシュは付けません。

3. Passwordを入力する

   該当するTrojanノードのPasswordを貼り付けます。大文字・小文字、前後の空白、改行が含まれていないか確認してください。文字を書き換えたり、元のパスワードをあらかじめURLエンコードしたりしないでください。

4. TLSを確認する

   フォームのTLS設定を開き、サービス提供元の案内に従ってSNIと証明書の検証設定を確認します。ALPN、転送方式、WebSocketの設定も指定されている場合は、それぞれの値を一致させてください。他のノードの設定を流用しないでください。

5. 保存してテストする

   保存後、Homeに戻って追加したノードを選択します。ルールの影響を切り分けるには、一時的にGlobal RoutingをProxyに設定し、接続をオンにして、アクセス可能と確認済みのHTTPSページを開きます。テスト後は普段の振り分け設定に戻してください。

Address・Password・SNIを入力する際の注意点

以下では、予約済みの例示用ドメインで各項目の形式を示します。gateway.example.comとtls.example.comは、この記事で提供する接続先ではありません。AddressとSNIが異なっていても、必ずしも誤りではありません。接続用の入口とは別の名前をTLSハンドシェイクで指定し、その名前が証明書に含まれる構成もあります。

SNIとHTTP Hostは別の項目です。サービス提供元がWebSocket転送を使っている場合は、HostやPathも指定されることがあります。Pathは/で始まる場合がありますが、SNIにパスは含めません。通常のTrojanで追加の転送方式が指定されていない場合、WebSocketを独自に有効にしたり、推測したPathを追加したりしないでください。

• Passwordに特殊文字が含まれる場合：Password欄に直接入力するときは元の値を使います。共有リンクから読み込む場合はインポート処理でエンコードが処理されるため、手動で再度デコードやエンコードをしないでください。
• AddressにIPを使う場合：サーバー証明書に一致させるため、SNIにはドメイン名を指定する必要があることがあります。AddressがIPだからといって、SNIもIPに変更しないでください。
• SNIが指定されていない場合：有名サイトのドメインを適当に入力しないでください。サブスクリプションの設定一式を確認するか、Addressのドメイン名をサーバー名として使う構成か、サービス提供元に問い合わせてください。

TLS検証の問題をPasswordの変更で解決しない

TLS証明書の検証では、接続先の相手が正しいか確認します。通常は証明書の信頼チェーン、有効期間、名前の一致を確認します。サーバーに接続できても、その証明書が現在のSNIに適合するとは限りません。端末の日付やタイムゾーンが正しくないと、有効な証明書がまだ有効でない、または期限切れと判定されることもあります。

SNIによってサーバーが選択する証明書が変わる場合があり、クライアントはその証明書が想定する名前をカバーしているか検証します。両者には関係がありますが、「任意のドメインを入力すれば暗号化できる」というものではありません。Passwordの誤りはその後の認証段階の問題です。証明書名の不一致は、Passwordを何度変更しても解決しません。

ALPNはアプリケーション層のプロトコルをネゴシエートするためのもので、速度を上げる汎用スイッチではありません。サービス提供元から指定がない場合は設定を変更せず、h2やhttp/1.1を無理に入力しないでください。エラーを消すためにTLS設定をむやみに弱めることも避け、まずサーバー側の要件を確認しましょう。

接続後はルールとノードを分けて確認する

Homeの接続スイッチをオンにするとクライアントの接続処理が始まりますが、すべてのリクエストが現在のTrojanノードを経由するとは限りません。Global RoutingがDirectならリクエストは直接接続されます。Configでは有効な設定のルールに従ってポリシーが選ばれます。Proxyはルールによる振り分けの影響を一時的に切り分けるために使えます。Sceneを使う場合は該当するシーン設定も確認してください。最初のトラブルシューティングでは、余分な変数を増やさないようにしましょう。

1. まずHomeでテストするTrojanノードを選択し、一時的にGlobal Routing → Proxyに設定します。再接続して、決めたテストページにアクセスしてください。
2. ProxyではアクセスできるのにConfigでは動作が異なる場合は、Configを開き、有効な設定とその[Rule]を確認します。すぐにSNIを変更しないでください。
3. ルールがDIRECTに一致していないか、またPROXYを指定したリクエストが実際にどのノードまたはポリシーグループを選択しているか確認します。
4. 自動再接続の影響も切り分ける場合は、Settings → On Demandの現在の設定を確認します。On Demandは接続を開始する条件を管理するもので、Trojanの認証設定を修正する機能ではありません。

たとえば以下のルールでは、例示用ドメインとそのサブドメインだけがPROXYを通り、それ以外の一致しないリクエストはDIRECTになります。これはルール構文の例であり、接続情報や完全な設定ではありません。ルールは上から順に評価されるため、FINALは末尾に配置します。使用前に、現在の設定でプロキシポリシーが意図どおり選択されることも確認してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

この設定では、ほかのWebサイトにアクセスしてもTrojanの通信が見られないのは想定どおりです。証明書エラーは通常TLS設定を確認し、「特定のサイトがプロキシを経由しない」場合はルールの一致状況を確認します。両者を混同すると、正しいノード設定まで何度も変更してしまうおそれがあります。

よくあるエラーとサブスクリプションによる上書き

トラブルシューティングでは、エラー発生時刻、使用中のネットワーク、選択したノード、Global Routingの状態を記録し、確認可能な接続診断情報を調べてください。以下は原因を切り分けるための手順であり、エラーメッセージだけで障害を断定するものではありません。同じ「タイムアウト」でも、発生する段階は異なる場合があります。

サービス提供元から個別ノードではなくサブスクリプションが提供されている場合は、Home →「+」→ Type → Subscribeから自分のリンクを読み込み、Homeに戻ってサブスクリプションを更新します。例のリンクhttps://example.com/sub?token=xxxxは形式を示すだけで、接続には使えません。トラブルシューティングのスクリーンショットを共有するときは、Password、サブスクリプションのtoken、サブスクリプションURL全体を隠してください。問い合わせには項目名、エラーの種類、必要な部分を伏せた状況だけを記載します。

問い合わせ前の確認リスト

条件をそろえたテストを1回行ってから、サービス提供元への問い合わせが必要か判断してください。ネットワーク、ノード、SNI、ルールを同時に切り替えると、問題を再現しにくくなります。比較するテストでは同じWebページを使い、名前が似た別のサブスクリプションノードを選んでいないことも確認してください。

• 接続先：AddressとPortを元の情報と照合し、WebページのURLをAddress欄に貼り付けていない。
• 認証情報：TypeがTrojanで、Passwordは該当ノードのもの。前後に空白や改行が含まれていない。
• TLS設定：SNIと証明書検証がサービス提供元の指定どおりで、端末の日付も正しい。ALPNを独自に追加していない。
• 転送設定：元の設定で明確に指定されている場合に限り、WebSocket、Host、Pathを設定する。
• テスト方法：ProxyとConfigで実際にどう異なるかを記録し、リクエストが想定したポリシーに一致するか確認する。
• 設定の更新元：手動で追加した項目とサブスクリプションの項目を区別し、次回の更新で手動変更が上書きされるか確認する。

設定を確認したら、Global Routingを普段使う設定に戻し、Configで有効になっている設定も再確認してください。項目の構成を確認するには設定項目の説明、ルーティング方式の違いを確認するにはプロキシモードの説明をご覧ください。プロトコル設定が正しいこと、証明書で接続先の身元を確認できること、リクエストが想定したルールに一致することは、それぞれ別に満たす必要があります。