Trojanを設定する前に、Type、Address、Port、Passwordを確認し、既存の設定に従ってSNIを入力します。通常、Allow Insecureはオフにします。自身で用意したサービスの接続情報やサブスクリプションを持っている方向けに、「接続確立 → 証明書検証 → プロトコル認証 → ルーティング確認」の順で各項目とトラブルシューティングを解説します。例示する値は書式の説明用で、接続には使用できません。
Trojan接続はTLSの後に認証を行う
ShadowrocketのTrojanはプロキシプロトコルの種類の一つで、パスワードだけ入力すれば使えるサービスではありません。接続先サーバーとポート、サーバーが受け付けるPasswordが必要です。アプリの購入と接続サービスの利用は別のものです。本記事は、ご自身で用意したサービスとサブスクリプションをお持ちであることを前提にしています。当サイトではサーバーやサブスクリプションを提供・販売・推奨していません。
一般的なTrojan接続では、まず接続先アドレスへの通信を確立し、その後TLSハンドシェイクを行います。TLSの段階ではサーバー証明書と名前を検証します。通信路が確立すると、クライアントはTrojanの認証情報と宛先リクエストを送信します。そのため、Passwordが正しくても証明書名の不一致は解消されず、SNIを変更してもPasswordの誤りは修正できません。
- 接続先：AddressとPortで実際に接続するサーバーの入口を指定します。ドメイン名を指定する場合、通常は先にDNSによる名前解決が必要です。
- TLSハンドシェイク：SNIはハンドシェイク時にサーバー名を指定するために使います。クライアント側では、設定に従って証明書チェーンと証明書内の名前も検証します。
- Trojan認証：Passwordはサーバーが受け付ける認証情報と一致する必要があります。サブスクリプションURLのtokenや、別プロトコルの項目で代用することはできません。
- リクエストの転送：認証後、実際のリクエストがこのサーバー経由になるかどうかは、Global Routing、現在の設定、選択中のポリシーにも左右されます。
この4段階はトラブルシューティングの順序であり、個別に切り替える4つの設定ではありません。前の段階の問題を解決してから、次の段階を確認してください。遅延テストで結果が表示されても、そのテストが対象とする処理に応答があったことを示すだけです。証明書や認証、すべての宛先へのリクエストが正常だとは限りません。
Add Server：項目ごとの入力方法
手動で追加する場合は、Home右上の「+」からAdd Serverを開き、TypeでTrojanを選択します。Portが443だからといって、別のTypeを選ばないでください。ポート番号だけではプロトコルを判断できません。以下の手順は、Trojanの接続情報一式をお持ちの場合を想定しています。項目の表示はアプリ内の現在の画面に従ってください。
-
追加画面を開く
Home → 右上の「+」 → Add Serverを開き、TypeでTrojanを選択します。既存の項目を編集する場合は、使用可能な設定を上書きしないよう、先に現在の値を控えてください。
-
接続先を入力する
既存の接続情報に記載されたサーバーのホスト名をAddressに、ポート番号をPortに入力します。たとえば、Addressが
edge.example.com、Portが443です。両方を一つのアドレスにまとめないでください。 -
認証情報を入力する
TrojanのPasswordを対応する項目にそのまま入力し、大文字・小文字と前後の空白を確認します。項目名や引用符、改行を付け加えたり、サブスクリプションURLを入力したりしないでください。
-
TLS設定を確認する
既存の接続情報に従ってSNIを入力し、Allow Insecureも確認します。SNIが明示されている場合は、その値をそのまま使ってください。よく知られたWebサイトのドメインを自己判断で入力しないでください。証明書が正しく設定されている場合、Allow Insecureはオフのままにします。
-
保存してテストする
保存後にHomeへ戻り、追加した項目を選択してGlobal Routingを確認してから接続します。初回接続時にシステムからVPN構成の許可を求められた場合は、画面の案内に従って承認し、実際のリクエストをテストしてください。
Addressにはホスト名またはIPアドレスのみを入力し、https://、パス、クエリパラメーターは付けません。Portは既存のサーバー情報と一致させます。443はよくある例ですが、TLSサービスで8443など別のポートが使われる場合もあります。自己判断で443に変更しないでください。接続情報にトランスポート層などの詳細オプションが含まれている場合も、各項目を対応させる必要があります。基本の4項目だけから設定全体を推測することはできません。
PasswordとSNI：用途の異なるパラメーター
PasswordはTrojanの認証情報、SNIはTLSの段階で使うサーバー名です。書式も用途も異なります。TrojanのPasswordはUUID形式である必要はありません。認証情報がUUIDのように見えても、全体を一つのパスワードとして扱ってください。VMessやVLESSの項目の扱いに合わせて分割・変更しないでください。
接続・認証情報の例
- Type
- Trojan
- Address
edge.example.com- Port
443- Password
DemoOnly-7qK9-p4
以下は説明用の値で、利用可能なサービスには対応していません。Passwordはご自身で用意した完全な認証情報に置き換えてください。
TLS名の例
- SNI
tls.example.com- 証明書名
tls.example.comを含む必要があります- Allow Insecure
- オフ
- 形式
- プロトコル、パス、ポートを含まないホスト名
SNIはAddressと異なる場合がありますが、既存のサーバー構成と証明書設定に合致している必要があります。任意の値を指定しないでください。
Addressは「どこに接続するか」、SNIは「TLSハンドシェイクでどのサーバー名を要求するか」を示します。同じ接続先で複数のTLSサービスを提供する場合があるため、両者が一致するとは限りません。ただし、SNIを自由に変更できるという意味ではありません。サーバーがその名前を認識し、返す証明書もクライアントが想定する名前に合致している必要があります。
AddressにIPアドレスを指定する場合は、特にサーバーから指定されたSNIを確認してください。ドメイン名をIPアドレスに置き換えるだけでは、元の名前解決を省略できても、デフォルトで使われるサーバー名も変わり、証明書検証に失敗することがあります。既存の接続情報にSNIの記載がなければ、推測で補わないでください。サーバー証明書に含まれる名前と、元の設定におけるTLS項目を先に確認します。
Allow Insecure：証明書検証と暗号化の違い
Allow Insecureが制御するのはTLS証明書の検証方法であり、「TLSを有効にするかどうか」ではありません。有効にしてもTLSによる暗号化が行われる場合はありますが、クライアントは通常の方法でサーバー証明書を検証しなくなるため、接続相手の正当性を確認できません。また、誤ったAddress、Port、Passwordを補正する設定でもありません。接続失敗時の汎用的な解決策として使わないでください。
Allow Insecureをオフ
推奨証明書検証を維持します。証明書の期限切れ、名前の不一致、信頼チェーンの問題がある場合は、検証を回避するのではなく、証明書とSNIを確認してください。
適用例：有効な証明書と一致する名前を使う通常の接続設定。
Allow Insecureをオン
証明書検証が緩和されます。TLSによる暗号化を、サーバーの身元が確認済みであることと同一視しないでください。接続が復旧しても、証明書検証の段階に問題がある可能性を示すにすぎず、設定が正しいとは限りません。
適用例：証明書の問題を把握したうえで行う、管理された一時的な診断。恒久的な解決策としては使わないでください。
オフでは失敗し、オンにすると成功する場合は、Allow Insecureを再びオフにして、端末の日付と時刻、SNIの綴り、証明書の有効期限、サーバーが証明書チェーン全体を送信しているかを確認してください。端末の時刻が大きくずれていると、証明書の有効期限判定に影響することもあります。根本的な対処は、パラメーターまたはサーバー証明書の設定を修正することです。検証を無視したまま使い続けないでください。
手動設定とサブスクリプション：設定情報の入手元を個別に確認
手動で追加した項目も、サブスクリプションから読み込んだ項目も、サーバーの実際の接続情報と一致している必要があります。異なるのは、各項目を誰が管理するかです。サブスクリプションをお持ちの場合、更新時にサーバー側で変更されたAddress、Port、認証情報が反映されることがあります。手動設定の場合は、変更を自分で同期する必要があります。読み込んだ情報にSNIやトランスポート層などの項目が含まれるかどうかは、表示名だけで判断せず、実際の項目を確認してください。
設定情報の入手元別チェック方法
手動で入力する場合
- Home →「+」→ Add Serverで、TypeにTrojanを選択します。
- Address、Port、Password、SNIを一つずつ確認します。
- サーバー側の接続情報が変わったら、ローカルの設定も更新します。
- トラブルシューティングの前に現在の値を記録し、一度に変更する項目は一つにします。
既存のサブスクリプション
- Home →「+」→ TypeでSubscribeを選択し、ご自身のサブスクリプションURLを入力して保存します。
- Homeに戻って下に引いて更新し、項目を取得できたか確認します。
- 対象の項目を開き、読み込まれたTypeとTLS関連の設定を確認します。
- ローカルでの変更は次回更新時に上書きされる場合があります。必要なトラブルシューティング記録を残してください。
サブスクリプションの取得成功はTrojan接続の成功を意味しません。それぞれ個別にテストしてください。当サイトではサブスクリプションの内容を提供していません。
よくある混同として、Homeのサーバー項目とConfigのルール設定を同じものとして扱うことが挙げられます。前者はプロキシの接続先を指定し、後者はリクエストに適用するポリシーを決めます。Global RoutingでConfigを選択すると、リクエストは現在有効な設定に従って処理されます。DIRECTに一致したリクエストは、Trojanの項目を選択していても、その経由では転送されません。
- Proxy：Configのルールによる影響を一時的に切り分けてテストします。テスト後は元のルーティング設定に戻してください。実際に選択されているプロキシの接続先も確認が必要です。
- Direct：リクエストは直接接続されます。この状態でWebページが開けても、Trojanの設定が有効だとは判断できません。
- Config：有効な設定とルールに従ってリクエストを処理します。一致したルールと、対応するポリシーの接続先をあわせて確認してください。
たとえばConfigを選択している場合、DOMAIN-SUFFIX,example.com,DIRECTは、そのドメインとサブドメインをDIRECTに振り分けます。この場合は、TrojanのPasswordを繰り返し変更するのではなく、ルールの適用状況を確認してください。ルールの問題とプロトコル接続の問題は分けて調べます。
接続できない場合：症状から確認箇所を絞る
まず、再現条件を記録します。使用中のネットワーク、選択中の項目、Global Routing、Allow Insecureの状態、失敗したのがサブスクリプション取得時か実際のリクエスト時かを控えてください。その後は一度に一つの要因だけを変更します。以下は条件に応じた確認方法であり、特定サービスでの実測結果ではありません。具体的なエラーメッセージはアプリ内の表示に従ってください。
タイムアウトが続きます。Passwordの入力ミスですか？
タイムアウトだけでは判断できません。まずHomeで項目を編集し、AddressとPortを確認します。同じ接続情報のままWi-Fiとモバイル通信を切り替えて再テストしてください。基礎となる接続が確立していない場合は、Passwordを判定できる認証段階にまだ到達していません。Port、SNI、Passwordを同時に変更しないでください。
証明書エラーが表示されます。どの項目を変更すればよいですか？
まず端末の日付と時刻を確認し、次に項目のSNIが既存の接続情報と一致するか、https://やポート番号を誤って入力していないかを確認します。名前が正しいのにエラーが続く場合は、サーバー証明書の有効期限と証明書チェーンを確認してください。Allow Insecureをオンにすることを最終的な対処にしないでください。
遅延の数値は表示されるのに、Webページが開けないのはなぜですか？
遅延テストの結果は、実際の宛先へのリクエストが完了したことを意味しません。まずHomeで対象のTrojan項目が選択されていることを確認し、Global RoutingがDirectになっていないかを確認してください。Configを使っている場合は、リクエストに適用されたポリシーを調べます。ルールの影響を切り分けるには、一時的にProxyでテストし、完了後に元の設定へ戻してください。
変更した設定がサブスクリプション更新後に元に戻りました。
更新後の項目を開き、Address、Port、Password、SNIを一つずつ確認します。サブスクリプションの更新により、配信元の項目が再設定されることがあります。同じ項目を記録なしで何度も変更するのではなく、まずサブスクリプション側の設定が修正されているか確認してください。
接続を切ったのに、また自動で接続されるのはなぜですか？
Settings → On Demandを開き、オンデマンド接続が有効か確認してから、システムのVPN状態も確認してください。自動再接続は接続を開始する動作であり、Trojanの認証に成功した証拠ではありません。トラブルシューティングでは接続のトリガー条件を一定に保ち、自動再接続を設定が有効になった結果と誤認しないようにしてください。
最終確認では、次の3点をすべて満たしている必要があります。対象項目の各値が既存の接続情報と一致していること、TLS証明書の検証に成功すること、プロキシ経由を想定した実際のリクエストが完了することです。特定のWebサイトだけが失敗する場合は、接続先サイト、DNS、ルールの問題を切り分けてください。一つの宛先で失敗しただけで、すべてのサーバー項目を書き換えないでください。DNSと接続トリガーについては、DNS設定とOn Demand設定をそれぞれご覧ください。