ShadowrocketのTrojan設定方法｜Password・SNI・TLSの各項目を解説

この記事の概要

この記事は、利用中のサービス提供元からTrojanの接続情報を受け取り、Shadowrocketに手動で追加する方や、設定内容を確認したい方に向けた解説です。まずサーバーアドレス、認証Password、TLSの接続先名を確認し、Add Serverの各項目に入力します。証明書エラー、認証失敗、接続後に通信できない場合は、発生した段階に沿って原因を切り分けましょう。Allow Insecureを有効にすれば直るとは限りません。

Trojan接続におけるアドレス・Password・TLSの役割

ShadowrocketのTrojanは、プロキシプロトコルの一つです。一般的な接続では、まずサーバーを特定してTCP接続を確立し、TLSハンドシェイクを行った後、Trojanの認証情報と接続先へのリクエストを送信します。TLSは通信の保護とサーバーの身元確認に使われ、TrojanのPasswordはサーバー側での認証に使われます。それぞれ役割が異なり、相互に代用することはできません。

入力前に、サービス提供元から必要な情報を一式入手してください。サーバーアドレス、ポート、Password、TLSで使用するドメイン、追加の通信設定の有無を確認します。「Trojan」という情報だけで、ほかの項目を推測してはいけません。すでに利用中のサブスクリプションがある場合は、まずその設定をインポートしてください。差分を確認する必要があるときだけ各項目を見直すと、手入力による抜けを防げます。

3項目

基本の接続情報：アドレス、ポート、Password。どれか一つでも不足していれば、先に確認してください。

443

記事内のポート番号は例です。すべてのTrojanサービスで同じポートが使われるわけではありません。

2つの役割

アドレスは接続先を指定し、TLSドメインはサーバーの身元確認に使われます。

必要な情報をそろえてから設定を追加

アドレスとPasswordしか分からない場合は、ポートとTLSドメインをサービス提供元に確認してください。ポートを次々に変えたり、証明書の検証を無効にしたりして設定を探るのは避けましょう。

Add Serverの各項目：値をそのまま入力する項目

Homeの右上にある「+」をタップしてAdd Serverを開き、TypeでTrojanを選びます。プラットフォームによって項目の並び順が異なる場合があるため、画面上の位置ではなく項目名と意味を確認して入力してください。以下の例では予約済みのサンプルドメインを使っています。実際に接続できる設定ではありません。

項目	入力方法	よくある間違い
Type	Trojanを選択します。	項目名だけを変更し、プロトコルの種類を変更していない。
Address	サービス提供元から指定されたドメイン名またはIPアドレスを入力します。例：`edge.example.com`。	`https://`、パス、ポートを含むURL全体を貼り付けてしまう。
Port	指定された整数のポート番号を入力します。例：`443`。入力可能な範囲は1～65535です。	例のポート番号を固定値だと思い込む、またはアドレス欄にポート番号を入力する。
Password	Trojanの認証Passwordを、大文字・小文字や記号も含めてそのまま入力します。	サブスクリプションのトークンやアカウントのログインPasswordを入力する、または前後に空白を含めて貼り付けてしまう。
SNI	指定されたTLSドメインを入力します。例：`tls.example.com`。	URL、パス、ポート、または現在アクセス中のWebサイトのドメインを入力してしまう。
Allow Insecure	通常はオフのままにし、クライアントによるサーバー証明書の検証を有効にします。	証明書検証のスキップを、接続の高速化や認証エラーの修正に使える設定だと思い込む。

TrojanのPasswordは通常、認証に使う文字列です。自分で選ぶ暗号化アルゴリズムでも、「ユーザー名とPassword」の組み合わせでもありません。サービス提供元から指定された文字列を、そのまま該当欄に入力してください。Base64エンコードやハッシュ化、引用符の追加は不要です。共有リンクからPasswordを手動で取り出す場合は、パーセントエンコードに注意してください。エンコード済みの文字列を元のPasswordと取り違えないよう、可能であればリンク全体をクライアントにインポートしましょう。

WebSocketなどの追加の通信方式が指定されている場合は、指示に従って該当する項目も設定してください。SNI、WebSocketのHost、パスはそれぞれ役割が異なります。ある設定で同じドメインが使われていても、ほかのサービスでも共通とは限りません。指定されていない項目を、名前が似ているという理由だけで有効にしないでください。

SNIと証明書のドメイン：サーバーのIPアドレスとTLS上の身元は別

SNIはTLSハンドシェイク時に送信されるサーバー名で、同じサーバー上でドメインに応じた証明書やサービスを選択するために使われます。Addressは接続先を指定し、SNIはTLS接続で要求する名前を示します。両者が同じ場合も異なる場合もあるため、サービス提供元の指定に従ってください。

アドレスがドメイン名の場合：アドレスに証明書の対象となるドメイン名を使い、サービス提供元から別途SNIを指定されていない場合は、インポートした設定または入力手順に従ってください。項目を空欄にできるからといって、SNIが不要だと決めつけないでください。
アドレスがIPアドレスの場合：たとえば192.0.2.10に接続し、証明書の対象がtls.example.comであれば、通常は指定されたTLSドメインを設定します。ドメイン名向けに発行された証明書が、そのIPアドレスも対象にしているとは限りません。
複数のドメインがある場合：ノードの表示名、サブスクリプションURLのドメイン、TLSドメインはそれぞれ別のものです。表示名はメモにすぎず、サブスクリプションURLは設定の取得に使われます。どちらからもSNIを推測することはできません。
証明書の検証に失敗する場合：ドメイン名のスペル、証明書の有効期限、証明書チェーン、端末の日付と時刻を確認してください。SNIが正しくても、期限切れの証明書や信頼されていない証明書チェーンは検証に通りません。

SNIにはtls.example.comのようにホスト名だけを入力し、https://tls.example.com:443/pathの形式にはしないでください。TLS証明書の検証では通常、証明書に記載された名前が想定するサーバーの身元と一致するかが確認されます。SNIは接続先を自由に置き換えるための設定ではありません。プロキシサーバーの証明書エラーを直す目的で、アクセス先Webサイトのドメインを入力するのも誤りです。

Allow Insecure：証明書を検証する場合と省略する場合の違い

Allow Insecureは、サーバー証明書の検証を緩和する設定です。TLSによる暗号化が続いていても、身元確認を省略すると「接続先が意図したサーバーか」を確認する能力が低下します。誤ったPasswordを直したり、待ち受けていないサーバーポートを開いたり、無効になったサブスクリプションを復旧させたりする設定ではありません。

Allow Insecureをオフ

推奨

サーバー証明書を検証します。ドメイン名の不一致、証明書の期限切れ、信頼チェーンの問題が発生した場合は、エラーを回避して使い続けるのではなく、設定とサーバー証明書を確認してください。

適用例：日常的な接続、有効な証明書を使用するTrojan設定

Allow Insecureをオン

証明書の検証を緩和し、サーバーの身元を確認する能力を低下させます。リスクを理解したうえで行う、範囲を限定した診断時にのみ検討してください。「有効にしたら接続できた」だけで、設定が正しいと判断することはできません。

適用例：管理者が明確に指示した一時的な証明書トラブルの切り分け。長期利用の設定にはしないでください。

証明書エラーは原因に応じて対処する

端末の時刻とSNIを確認しても証明書エラーが続く場合は、エラーの種類をサービス提供元に伝え、サーバー証明書の状態を確認してください。問題を解消した後、Allow Insecureをオフにして再テストします。

追加から接続確認まで：設定は一度に一つだけ変更

以下では手動追加の手順を説明します。すでにサブスクリプションを利用している場合は、サービス提供元から取得したURLをインポート手順に沿って使用してください。パラメーターを一つ確認するために、既存のサブスクリプションを削除する必要はありません。サブスクリプションで管理される項目は、次回の更新時に上書きされる場合があります。継続的に修正が必要な設定は、まずサービス提供元に確認してください。

接続情報を確認

アドレス、ポート、Password、SNI、追加の通信設定を用意します。現在のGlobal Routingの設定を控えてください。Settings → On Demandで自動接続が有効な場合、テスト中に再接続が発生することがあります。自動再接続を、手動設定が保存されていないと誤解しないようにしましょう。
設定を追加

Home →「+」→ Add Server → Type → Trojanの順に選びます。アドレスとポートはそれぞれ別に入力してください。Address欄に共有リンク全体を貼り付けたり、サブスクリプションURLをサーバーアドレスとして入力したりしないでください。
サーバーの身元を確認

元の認証文字列をPasswordに入力し、指定に従ってSNIを設定します。Allow Insecureはオフのままにしてください。追加の通信設定も指定されたものだけ入力し、保存後にHomeへ戻って設定した項目を選びます。
接続をテスト

HomeのConnectivity Testで基本的な接続を確認し、その後接続して、プロキシ経由でアクセスする必要がある接続先を開きます。テストに応答があっても、すべてのWebサイト、ルール、UDP通信が確認できたとは限りません。
ルーティングを確認

ルールの影響を切り分ける必要がある場合は、一時的にGlobal RoutingをProxyにして同じアクセスを再テストします。テスト後は元のConfigなどの設定に戻し、ルーティングの動作を意図せず変えたままにしないでください。

一度に変更するのは一つの項目だけにし、変更前後のエラーを記録してください。たとえば「SNIを修正したら証明書エラーが消えたが、認証失敗が出た」場合は、次の確認段階に進んでいます。TLS設定を手当たり次第に変えるのではなく、Passwordを確認しましょう。スクリーンショットや問い合わせに、Password、共有リンク全体、サブスクリプショントークンを載せないでください。

よくある質問：エラーの発生段階から原因を確認

アドレスとPasswordを入力したのに、接続がタイムアウトするのはなぜですか？

まずPortとアドレスを確認し、アドレス欄にプロトコルの接頭辞やパスが入っていないか確認してください。ドメインの名前解決に失敗している、ネットワークに到達できない、サーバーのポートが開いていないといった原因でタイムアウトすることがあります。この段階では、TLSやPassword認証まで進んでいない場合もあります。利用可能な別のネットワークでも同じテストを行い、サーバーの状態をサービス提供元に確認してください。最初からAllow Insecureを有効にするのは避けましょう。

証明書エラーが表示されます。Passwordが間違っていますか？

まずTLSの段階を確認します。SNIのスペル、端末の日付と時刻、サーバー証明書の状態を確認してください。Passwordは後続のTrojan認証に使われるため、Passwordを変えても証明書のドメイン不一致は通常解消しません。TLS設定をすべて切り替えて試すより、エラーメッセージをそのまま伝えるほうが原因の特定に役立ちます。

接続済みなのに、Webページが直接接続されるのはなぜですか？

Home → Global Routingを確認してください。Directではプロキシ経由の通信を確認できません。Configでは、現在の設定にあるルールに基づいて通信方法が決まります。一時的にProxyにして再試行し、現象が変わった場合はConfigで有効な設定とルールの順序を確認してください。ルーティングの問題をTrojanのPasswordエラーと混同しないようにしましょう。

昨日は手動で直せたのに、サブスクリプションを更新したら元に戻ったのはなぜですか？

サブスクリプションの更新時に、管理対象の項目が再生成されることがあります。更新後のAddress、Port、SNIが元の値に戻っていないか確認し、サブスクリプションの内容をサービス提供元に問い合わせてください。比較が必要な場合は、手動テスト用の項目を別に作成しましょう。サブスクリプション管理下の設定を繰り返し書き換えて、元データの問題を見えなくしないでください。

Global RoutingのProxy、Direct、Config、Sceneは、プロトコルの設定とは別のものです。これらはルーティングの判断に影響し、Trojanのパラメーターはサーバーへの接続方法を決めます。Sceneはシーンごとの設定に従って動作するため、トラブルの切り分けでは実際に適用されているポリシーも確認してください。接続アイコンが表示されても、特定のWebリクエストが選択中のTrojan設定を通ったとは限りません。

ルールの確認と接続情報の管理

Configに戻した後、判別できるリクエストを使ってルールを確認してください。以下の例はマッチングの仕組みを示すものです。サンプルドメインへのリクエストをPROXYに、それ以外をDIRECTに振り分けます。PROXYが、設定内に実際に利用可能なプロキシポリシーを参照している必要があります。ルールのテキストを貼り付けるだけでは、Trojanサーバーは追加されません。

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

ルールは上から順に判定されます。DOMAIN-SUFFIXはドメイン名とそのサブドメインに一致し、FINALは先行するルールに一致しなかった場合のフォールバックです。実際の設定に優先度の高いルールがある場合は、それらも含めて確認してください。追加した2行だけを見ても十分ではありません。構文の詳細はルールリファレンスを確認し、Webサイトのルーティングを変えるためにSNIを変更しないでください。

通常は証明書の検証を有効にし、テスト後にGlobal RoutingとOn Demandの設定を元に戻してください。
Password、ノードの共有リンク、サブスクリプションURLは機密情報として管理してください。問題を報告する際は、値を伏せた項目の関係、エラーメッセージ、発生した段階だけを伝えます。
共有リンクは通常、一つの接続設定を表します。サブスクリプションURLは複数の設定を取得・更新するためのものです。追加情報が必要な場合は、サービス提供元から入手してください。
新しいPasswordが有効になった場合は、保存してある古い設定も更新または整理してください。次回誤って選択した際に、解決済みの認証エラーを再調査しないようにしましょう。