ShadowrocketでTrojanを追加する方法｜Password・SNI・Allow Insecureの設定 | Shadowrocket 設定センター

この記事の概要

Trojanを追加する際、Addressは接続先、Portは接続先ポート、Passwordはプロトコル認証、SNIはTLSハンドシェイクで使うサーバー名を指定します。4項目は手元の設定情報に従って入力し、Allow Insecureは通常オフにします。手動でノードを追加する場合や、インポート後に接続できない場合の確認に役立つよう、ネットワークに接続できない場合、証明書の検証エラー、Passwordの誤りを区別し、証明書検証を無効にして設定ミスを覆い隠さない方法を説明します。

TrojanとTLS：接続・証明書・認証を切り分ける

TrojanはTLS上でプロキシプロトコルのデータをやり取りします。通常、まずAddressとPortで指定したサーバーに接続し、TLSハンドシェイクの後、暗号化された通信路でTrojanの認証とリクエストの転送を行います。TLSは通信の暗号化とサーバー認証を担い、PasswordはTrojanのアクセス認証に使います。両者は互いに置き換えられる設定ではありません。

そのため、Passwordが正しくても証明書が有効とは限らず、ポートに接続できてもTrojanの認証に成功したとは限りません。一般的なHTTPSサイトもTrojanサーバーも443番ポートを使うことがありますが、任意のHTTPSアドレスをAdd Serverに入力してもTrojanノードとしては使えません。

接続層：Addressが名前解決できるか、指定したTCPポートに到達できるかを確認します。接続がタイムアウトする場合は、まずここを確認してください。
TLS層：サーバー証明書の有効期限、信頼チェーン、検証対象の名前を確認します。SNIが正しくないと、サーバーから一致しない証明書が返されることがあります。
認証層：Passwordがサーバー側の設定と完全に一致するかを確認します。TLSハンドシェイクに成功しても、ここで拒否される場合があります。
転送層：接続後は、Global Routing、ルール、接続先サイトの名前解決と到達性も確認します。

Add Serverの各項目：Address・Port・Password・SNI

まず、利用中のサービスから正確な接続情報を入手してから編集画面を開きます。以下のドメイン名とポート番号は項目の関係を説明する例であり、接続に使える情報ではありません。実際の値は元の設定どおりに入力してください。例が443だからといって、別のポートを443に変更しないでください。

項目	入力する値	よくある間違い
Type	Trojanを選択し、サーバー側のプロトコルと一致させます。	ポート番号が同じという理由だけで、別のプロトコルを選ぶ。
Address	サーバーのドメイン名またはIPアドレス。例：`edge.example.com`。	`https://`やパス、ポート番号を含むURL全体を貼り付ける。
Port	サーバーが待ち受けるポート番号。例：`443`。有効範囲は1～65535です。	入力し忘れる、自分で推測する、またはAddressにポート番号を重ねて入力する。
Password	元の設定に記載されたTrojanのPassword。文字と大文字・小文字を変えずに入力します。	アカウントのログインパスワードを入力する、またはコピー時に空白や改行が混入する。
SNI	元の設定で指定されたTLSサーバー名。例：`tls.example.com`。	URLやポート番号付きのIPアドレスを入力する、または任意の別サイトのドメイン名に変更する。
Allow Insecure	通常はオフのままにして、証明書を正しく検証します。	エラーが出るたびにオンにして、証明書の問題を覆い隠す。

AddressとSNIが異なる場合がある理由

Addressはネットワーク接続先、SNIはTLS ClientHelloに含まれるサーバー名です。サーバーはSNIを使って証明書や仮想ホストを選択する場合があります。両者は同じこともあれば、設定で異なる値が指定されることもあります。たとえば接続先がIPアドレスで、TLS名には証明書の対象ドメインを使う場合です。このときは元の設定にある名前を維持し、SNIをそのIPアドレスに変更しないでください。

SNIは証明書の検証に関係しますが、「SNIを送信した」だけで「証明書の検証に成功した」ことにはなりません。証明書には有効期限、信頼チェーン、名前の一致などの条件があります。不完全な設定を直すために、SNIを空欄にして自動判定に頼らないでください。AddressがIPアドレスの場合や証明書の名前と異なる場合は、元の設定で指定されたTLS名を確認してください。

SNIにはホスト名を入力します。https://tls.example.com/やtls.example.com:443は入力しません。
証明書の名前は、Subject Alternative Nameに記載された範囲と一致する必要があります。ワイルドカード証明書でも、任意の階層のドメイン名に一致するわけではありません。
元の設定に伝送方式、Host、Pathなどの項目もある場合は、あわせて維持してください。これらの項目をSNIで代用することはできません。

手動で追加する手順：設定を保存して実際の通信を確認

ここではTrojanノードを1つ手動で追加する方法を説明します。既存のサブスクリプションからノードを追加した場合は、元の設定内容を確認し、配信元と異なる設定に変更しないようにしてください。サブスクリプションを更新すると項目が再び書き換えられることがあります。問題点を記録し、配信元の設定を修正するようにしてください。一時的な手動変更に頼り続けないでください。

追加画面を開く

Homeを開き、右上の「+」をタップしてAdd Serverを開きます。新しい項目を作成していることを確認し、使用中のほかの設定を誤って編集しないようにしてください。
プロトコルを選択する

Type → Trojanを選択します。プロトコルは元の設定に合わせてください。AddressとPortが同じでも、Typeを間違えると接続できません。
接続情報を入力する

Add Serverに戻り、Address、Port、Passwordを入力します。Addressにはホスト部分だけを入力し、Passwordは元の値をそのままコピーしてください。引用符を追加したり、ハッシュ値に変換したりしないでください。
セキュリティ設定を確認する

その項目のTLS関連設定でSNIとAllow Insecureを確認します。SNIには元の設定で指定された名前を入力し、Allow Insecureはオフにしてください。ほかの伝送設定がある場合も、元の設定と照合します。
保存してテストする

保存後、Homeに戻って追加した項目を選択します。ルールの影響を切り分けるには、一時的にGlobal RoutingをProxyに設定し、接続スイッチをオンにして、システムの案内に従ってVPN構成を許可します。動作確認済みのHTTPSページにアクセスし、確認後は元のルーティングモードに戻してください。

Allow Insecure：証明書検証の設定を比較

Allow Insecureを有効にすると、通常のTLS証明書検証が緩和または省略されますが、通信が平文に切り替わるわけではありません。ただし、暗号化されていても通信相手の身元を確実に確認できなければ、偽装サーバーに接続するおそれがあります。また、Passwordの誤り、閉じたポート、名前解決の失敗、サーバー側とのプロトコル不一致も解決できません。

Allow Insecure：オフ

推奨

証明書を正しく検証します。証明書の名前が一致しない、有効期限が切れている、信頼チェーンに問題がある場合は接続エラーとなり、修正が必要な認証上の問題を確認できます。

適した用途：日常的な利用、正式な設定、通常のトラブルシューティング。

Allow Insecure：オン

証明書検証を緩和すると、リクエストを続行できてもサーバーの身元が信頼できるとは限りません。証明書切れやSNIの誤りに対する恒久的な対処として使わないでください。

適した用途：証明書のリスクを理解したうえで設定の違いを確認する場合。日常的な利用には推奨しません。

結論：証明書の問題を修正し、検証回避の設定は残さない

同じ設定でAllow Insecureをオンにした場合にしか接続できないときは、オフに戻してからSNI、デバイスの日時、サーバー証明書チェーンを確認してください。自分で修正できない場合は、エラーの種類を利用中のサービスの管理者に伝えてください。

まずデバイスのシステム設定で日付と時刻が正しいことを確認します。次に、証明書の有効期限、証明書の対象ドメインに想定した名前が含まれているか、サーバーが中間証明書チェーンをすべて送信しているかを確認してください。自己署名証明書には個別の信頼設定が必要です。検証を長期的に省略して、信頼できる設定の代わりにしないでください。

症状別のトラブルシューティング：タイムアウト・証明書エラー・認証失敗

接続エラーは発生した段階に応じて確認します。ネットワークやサーバーによっては、似たタイムアウトや切断が起きることがあります。以下は確認の順序であり、エラーメッセージだけから原因を断定する方法ではありません。エラーの種類を記録する際は、Password、サブスクリプションのトークン、接続情報全体を隠してください。

タイムアウトが続きます。Passwordが間違っていますか？

まずHomeに戻り、該当項目の編集画面でAddressとPortを確認します。次に、現在のネットワークからそのアドレスとポートに接続できるか確認してください。タイムアウトは接続の確立時やハンドシェイク中にも発生するため、Passwordの誤りとは限りません。利用可能な別のネットワークで同じテストを行うと、現在のネットワークが原因かどうかを判断しやすくなります。

証明書エラーが表示されます。SNIにはどのドメイン名を入力しますか？

ブラウザーでアクセスするWebサイトのドメイン名ではなく、既存の設定で指定されたTLS名を入力します。SNIにプロトコルの接頭辞、ポート番号、空白が含まれていないか確認し、デバイスの日時も確認してください。名前が正しいのにエラーが続く場合は、Allow Insecureをすぐにオンにせず、サーバー証明書の有効期限と証明書チェーンを確認します。

接続直後に切断されます。Passwordを再生成する必要がありますか？

まずPasswordとTypeを1文字ずつ照合し、コピー時に改行が混入していないか、元の設定にある伝送設定が抜けていないかを確認します。Passwordを自分で再生成しないでください。サーバー側の設定は自動的には変わりません。TLS確立後すぐに切断される場合も別の原因が考えられるため、サーバー側の記録とあわせて確認してください。

テスト結果は表示されるのにWebページを開けない場合は？

Homeで対象の項目が選択されていることを確認し、一時的にGlobal Routing → Proxyに設定して同じページにアクセスします。Proxyでは使えてConfigでは使えない場合は、現在のConfigで有効になっているルールとポリシーの行き先を確認します。どちらのモードでも失敗する場合は、認証、DNS、接続先サイトを確認してください。遅延の測定値だけでノードが正常だと判断しないでください。

確認後：Configに戻し、ルールと更新を確認する

Global Routing → Proxyは、今回ルールの影響を切り分けるための設定です。すべての状況で長期的にこのモードを使うべきという意味ではありません。Directは直接接続を表し、Trojan経由の転送確認には使えません。Configは現在の設定ルールに従ってリクエストを処理し、Sceneは設定済みのシーンに応じてルーティング動作を選択します。日常利用では、元の有効なモードに戻してください。

Proxyでは正常で、Configでは期待どおりにアクセスできない場合は、現在のConfigでルールの順序とポリシーを確認します。たとえば次の構文例では、example.comとそのサブドメインにPROXYを適用し、それ以外のリクエストにはDIRECTを適用します。これはルールの意味を示す例であり、既存の設定を置き換える指示ではありません。実際の設定では、ポリシーの適用先が有効である必要があります。

DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

ルールの順序を確認：先にあるルールがリクエストに一致すると、後ろのDOMAIN-SUFFIXルールが適用されない場合があります。特定の行を検索しただけで振り分け結果を判断しないでください。
配信元の設定を維持：サブスクリプションの項目を更新した後、Address、Port、SNI、伝送設定に変更がないか再確認してください。一度手動で修正しただけで、配信元の設定が恒久的に直ったと思い込まないでください。
自動接続を確認：手動で切断した後に接続が復帰する場合は、Settings → On Demandで有効になっているオンデマンド接続条件を確認します。自動再接続を、ノードの編集が反映されていない状態と混同しないようにしてください。
認証情報を保護：管理者に問題を伝える際は、エラーが発生した段階、ネットワークの種類、Configでのみ失敗するかどうかを伝えてください。PasswordやサブスクリプションURLが見えるスクリーンショットは送信しないでください。