利用中のサービスとTrojanの接続情報がある場合は、まず元の情報をもとにAddress、Port、Passwordを確認し、SNIと証明書名が一致しているか確認してください。入力ミスを補うために証明書検証を無効にするのは避けましょう。手動追加の手順、TLS接続の流れ、サブスクリプション更新の影響、「接続済みなのに開けない」場合の切り分け方法を説明します。例示するドメイン、アドレス、パスワードは説明用であり、接続には使用できません。
Trojanの設定項目は「接続」「認証」「TLS」の3種類
ShadowrocketでTrojanを選んでも、入力するのはパスワードだけではありません。まずサーバーを特定してTLS接続を確立し、その後、Trojanの認証情報をサーバーに送信します。接続先はAddressとPort、Trojanの認証はPassword、TLS接続時のサーバー確認はSNIと証明書検証が担います。それぞれ役割が異なり、相互に置き換えることはできません。
この記事では、有効な接続情報をすでに持っていることを前提に説明します。サブスクリプションを受け取った場合は、まずインポートした設定をそのまま使ってください。項目の確認や手動追加が必要な場合にのみ、Add Serverを開きます。サブスクリプションURLをサーバーのAddressに入力したり、URL内のtokenをTrojanのPasswordとして使ったりしないでください。
結論:問題が起きた段階に応じて設定を見直す
証明書名のエラーが出た場合は、PasswordではなくSNIと証明書を確認します。接続がタイムアウトする場合は、Passwordを何度も変更せず、Address、Port、ネットワークへの到達性を確認してください。
Add Serverで手動追加:保存してから接続テスト
手動追加はHome右上の「+」から行います。Add Serverを開き、TypeでTrojanを選択してください。表示される項目はTypeや通信設定によって異なります。ここでは一般的なTrojan接続で確認する項目を説明します。元の情報で通信方式や追加パラメーターが指定されている場合は、その値も反映してください。ここで示す基本例で置き換えないでください。
-
Typeを確認
Home →「+」→ Add Server → Typeの順に開き、Trojanを選択します。ドメインとパスワードが含まれているからといって、別のTypeを選ばないでください。
-
接続先を入力
Add Serverに戻り、AddressとPortをそれぞれ入力します。AddressにはドメインまたはIPアドレスのみを入力し、Portにはサーバー指定の整数を入力します。プロトコルのプレフィックスは付けません。
-
認証情報を入力
元の情報にあるパスワードをPasswordにそのまま入力します。大文字・小文字や記号も保持してください。貼り付けた内容の先頭や末尾に、余分な空白や改行が入っていないか確認します。
-
サーバーの識別情報を確認
TLS関連の設定でSNIと証明書検証の項目を確認します。SNIが指定されている場合は、その値を入力してください。Allow Insecureはオフのままにして、通常の証明書検証を有効にします。
-
保存してテスト
保存後、Homeに戻って該当の設定を選び、接続を開始します。初回接続時は、システムの案内に従ってVPN構成を許可してください。テスト前にHome → Global Routingの現在の選択を記録しておき、ルーティングの結果とサーバーの接続結果を混同しないようにします。
テストでは、一度に変更する項目を1つに絞ってください。たとえばPortを修正して再接続し、結果を確認します。Address、Password、SNIを同時に変更しないでください。複数の項目を一度に変えると、接続が回復しても原因を特定できず、次回のサブスクリプション更新後に同じ問題が再発するおそれがあります。
Address・Port・Password・SNIの設定方法
以下は接続に使用できない例示用の設定です。192.0.2.10は文書用の例示アドレス、example.comは例示ドメインです。表では各項目の関係を示すために使用しており、実際に利用できるサービスを表すものではありません。
| 項目 | 例 | 確認ポイント |
|---|---|---|
| Type | Trojan |
元の接続情報で指定されたプロトコルと一致していること。 |
| Address | 192.0.2.10 |
IPアドレスまたはドメインを入力します。https://、パス、クエリパラメーターは含めません。 |
| Port | 443 |
サーバーが実際に待ち受けているポートと一致させます。TLSを使うからといって、すべて443に変更するわけではありません。 |
| Password | Demo-Only-Not-A-Real-Password |
元のパスワードを入力します。ハッシュ値を自分で計算したり、サブスクリプションのtokenで代用したりしないでください。 |
| SNI | tls.example.com |
サーバーから指定されたTLS名を入力します。プロトコル、ポート、パスは含めません。 |
| Allow Insecure | オフ | 証明書検証を有効にします。証明書に問題がある場合は、設定を修正するか、利用中のサービスの管理者に問い合わせてください。 |
AddressとSNIは異なる場合があります
Addressは実際にネットワーク接続する接続先を指定します。SNIはTLSハンドシェイクでサーバーに伝える接続先の名前です。サーバーはSNIに応じて証明書を選択したり、接続を処理したりすることがあります。AddressにIPアドレスを指定していても、表のtls.example.comのようなドメインをSNIに指定する場合があります。これは矛盾ではなく、Addressをそのドメインに変更する必要があるという意味でもありません。
Addressが証明書に対応するドメインで、元の情報に別のSNIが指定されていない場合は、まずインポート時の設定または既定の処理を維持してください。証明書名のエラーが出た場合は、利用中のサービスの管理者に正しい名前を確認します。アクセスできるWebサイトのドメインを適当に入力しないでください。SNIは任意のメモではなく、誤った値を指定するとサーバーが返す証明書が変わったり、TLSハンドシェイクに失敗したりすることがあります。
Passwordに共有リンク全体を入力しない
- 手動入力では、デコード後の正しい項目の値を使います。
trojan://から始まる共有リンク全体をPasswordに貼り付けないでください。 - 共有リンクから設定を読み取る場合は、URIエンコードに注意してください。パスワード内の特殊文字がパーセントエンコードされていることがあります。エンコードされた部分をそのままコピーしても、元のパスワードと一致するとは限りません。
- 共有リンク全体がある場合は、アプリが対応するインポート機能を使って設定を取り込み、その後、追加された項目を確認してください。手作業で部分ごとに分解するより、入力漏れを防ぎやすくなります。
TLS証明書の検証:「接続できる」ことと「サーバーが正しい」ことは別
TLSは通信を暗号化するだけでなく、サーバーの身元を確認する役割もあります。通常の検証では、証明書の信頼チェーン、有効期限、名前の一致を確認します。Passwordが正しくても証明書のエラーは解消されません。同様に、TLSハンドシェイクが成功しても、Trojanのパスワードがサーバーに受け入れられたとは限りません。
証明書エラーが出た場合は、まずSNIを確認し、iPhoneまたはiPadの日付と時刻が正しいこと、サーバー証明書が期限切れでないことを確認します。証明書チェーンの不足や名前の設定ミスは、サービスの管理者による修正が必要です。警告を消すために、端末の日付を誤った日時に変更しないでください。
通常の証明書検証を有効にする
推奨Allow Insecureはオフのままにします。証明書エラーがあると通常の接続は確立できません。名前、有効期限、信頼チェーンを確認し、問題を隠さないようにしてください。
用途:日常の接続、および設定を修正した後に正常に戻ったか確認するとき。
証明書検証をスキップ
Allow Insecureを有効にすると、サーバーの身元確認が弱まります。接続状態が変わっても、証明書の問題が解決したことや、想定したサーバーに接続できたことの証明にはなりません。
用途:設定の役割とリスクの理解。この記事では修復手順として推奨しません。
結論:名前を修正してから再接続
SNIを修正して接続が回復した場合も、証明書検証は有効のまま実際のアクセスを確認してください。トラブル対応中に変更した検証設定を、緩和した状態のままにしないでください。
接続済みなのに開けない:サーバー・ルーティング・オンデマンド接続を切り分ける
システムにVPN接続済みと表示されても、トンネルが確立したことを示すだけで、すべての宛先に選択中のTrojanサーバー経由でアクセスできるとは限りません。Homeで設定を選択していても、現在のリクエストが必ずその設定を使うとは限りません。サーバー設定の正しさと、リクエストに実際に適用されるポリシーを分けて確認してください。
- Home → Global Routing → Proxy:一時的にルール分岐の影響を切り分け、プロキシ対象のテストリクエストが選択中のサーバー経由で処理されるか確認します。テスト後は元の選択に戻してください。
- Home → Global Routing → Direct:リクエストは直接接続として処理されます。この設定でWebページが開けても、Trojanの設定が正しいことの証明にはなりません。
- Home → Global Routing → Config:現在の設定に従って通信を処理します。Configで有効なファイルとルールを確認してください。すべての通信が選択中のサーバーを経由するとは限りません。
- Home → Global Routing → Scene:現在のSceneの設定内容も確認してください。結果をProxyやConfigと同じものとして扱わないでください。
- Settings → On Demand:オンデマンド接続の設定によって接続が自動的に開始されるか確認します。On Demandが制御するのは接続の開始条件であり、TrojanのPassword、SNI、証明書を自動修正するものではありません。
Configでは、DOMAIN-SUFFIXはドメインのサフィックス、GEOIPはIPアドレスの地理的な割り当て、IP-CIDRはIPアドレスの範囲で照合し、FINALはそれ以前のルールに一致しなかった通信を処理します。ルールの順序と最終ポリシーによって通信経路が変わります。以下はルール構文の説明用であり、完全な設定例ではありません。既存のファイルを置き換える必要はありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY
たとえば、DIRECTに一致したリクエストでは、現在のTrojanサーバーが利用可能かどうかは検証されません。一方、一時的にProxyを選ぶとリクエストが成功し、Configに戻すと失敗する場合は、Passwordをすぐに変更するのではなく、ルール、ポリシー、ドメイン解決関連の設定を優先して確認してください。テスト記録には宛先、ルーティングの選択、エラーメッセージを明記してください。実測に基づかない遅延や成功率の数値は掲載していません。
よくある入力ミスとサブスクリプション更新後の確認
サブスクリプションは設定の取得元であり、ノードの記録はインポート後の個別設定です。更新によってAddress、Port、認証情報、TLS関連の値が変わることがあり、手動で変更した項目が次回の更新で上書きされる場合もあります。トラブル対応の前に、項目名とエラーメッセージを記録してください。Passwordやtokenを含む全情報を公開の掲示板に送らないでください。
Addressにhttps://を付ける必要はありますか?
いいえ。Homeから該当する設定の編集画面を開き、AddressにはドメインまたはIPアドレスだけを入力します。ポート番号はPortに入力してください。WebページのURL、サブスクリプションURL、サーバーのAddressは用途が異なるため、混同しないでください。
案内されたポートが443以外の場合、443に変更すべきですか?
いいえ。Portにはサーバーが実際に待ち受けている値を指定します。案内が8443なら8443を入力してください。TrojanがTLSを使用するからといって、サーバーが必ず443で待ち受けているとは限りません。
証明書名が一致しないというエラーは、パスワードの間違いですか?
まず、設定のSNIがサーバーの指定と一致しているか確認してください。プロトコルのプレフィックスやポートを誤って含めていないか、端末の日付と時刻が正しいかも確認します。証明書による身元確認とTrojanのパスワード認証は別の段階です。Passwordを何度変更しても、証明書名の問題は解決しません。
サブスクリプションを更新したら、手動設定したSNIが変わってしまいました。どうすればよいですか?
Homeで該当するサブスクリプションを更新し、設定を開き直してSNI、Address、Portを確認します。更新のたびに誤った項目が戻る場合は、該当項目を具体的に示して利用中のサービスの管理者に連絡してください。テスト用の設定を残す必要がある場合は、別の手動設定を作成し、区別できる名前を付けてください。
サブスクリプションは更新できるのに、接続に失敗するのはなぜですか?
サブスクリプションの更新が成功したことは、設定を取得して解析できたことを示すだけで、サーバーへの接続テストが成功したという意味ではありません。Homeで該当する設定を選択し、Global Routingを確認してから再テストしてください。その後、タイムアウト、証明書、認証の各問題に分けて確認します。
問い合わせ用に、次の情報を記録してください
- 手動追加した設定か、サブスクリプションから取得した設定かを記録します。問題がサブスクリプション更新直後に発生したかも記録してください。
- 現在のType、Port、Global Routingの選択、エラーメッセージ全文を記録します。機密情報については、元の情報と一致しているかどうかだけを伝えてください。
- 変更した項目とその結果を1つずつ記録します。例:「SNIを修正したところ証明書名のエラーは消えたが、目的のサイトにはまだアクセスできない」。
- Password、サブスクリプションのtoken、共有リンク全文は伏せてください。機密情報をすでに公開してしまった場合は、利用中のサービスのアカウント管理窓口から該当する認証情報を変更してください。
トラブル対応が終わったら、意図したGlobal RoutingとOn Demandの設定に戻し、通常の証明書検証が有効になっていることを確認してから、普段利用する宛先でテストします。これにより、一時的な診断設定と最終的な設定を分けられ、テスト後に日常利用に適さない設定が残るのを防げます。