Shadowrocket Trojan Setup: Password, SNI, and Allow Insecure Explained

Trojan connections use TLS before authentication

In Shadowrocket, Trojan is a proxy protocol type, not a service you can use by entering a password alone. The client needs the server address, port, and Password accepted by the server. Buying the client and obtaining a connection service are separate matters. This guide assumes you already have your own provider and subscription; this site does not provide, sell, or recommend servers or subscriptions.

A typical Trojan connection first establishes a connection to the destination address, then performs a TLS handshake. The TLS stage involves verifying the server certificate and its name. Once the channel is established, the client sends Trojan authentication information and the destination request. So a correct Password cannot fix a certificate name mismatch, and changing SNI cannot fix an incorrect Password.

1. Connection target: Address and Port determine the server endpoint the client connects to. A domain name usually needs to be resolved through DNS first.
2. TLS handshake: SNI specifies the server name during the handshake. The client also verifies the certificate chain and the name on the certificate according to its configuration.
3. Trojan authentication: Password must match the credentials accepted by the server. A subscription URL token or a field from another protocol cannot be used instead.
4. Request routing: After authentication, whether a request uses this server also depends on Global Routing, the active configuration, and the selected policy.

These four steps are a troubleshooting sequence, not four independent switches. Resolve each stage before diagnosing the next. A latency test returning a result only shows that the parts covered by that test responded; it does not prove that the certificate, authentication, or every destination request is working.

Add Server: Enter Each Field

To add a server manually, tap “+” in the upper-right corner of Home, open Add Server, and set Type to Trojan. Do not choose another Type just because it also uses port 443; the port number does not identify the protocol. The steps below assume you already have a complete set of Trojan settings. Field labels may vary with the current in-app interface.

1. Open the Add Server screen

   Go to Home → “+” in the upper-right corner → Add Server, then select Trojan for Type. If you are editing an existing entry, note its current values first so you do not overwrite a working configuration.

2. Enter the server endpoint

   Enter the server hostname from your existing settings in Address, and the port number in Port. For example, set Address to edge.example.com and Port to 443. Do not combine them into one address.

3. Enter the credentials

   Copy the full Trojan Password into the corresponding field, checking capitalization and any leading or trailing spaces. Do not add a field name, quotation marks, or line breaks, and do not enter a subscription URL.

4. Check TLS settings

   Enter SNI as specified in your existing settings, and check Allow Insecure. If your settings specify an SNI, use it exactly as provided; do not enter a popular website’s domain by guesswork. For a properly configured certificate, leave Allow Insecure off.

5. Save and test

   After saving, return to Home, select the entry you just added, and check Global Routing before connecting. If iOS prompts you to authorize a VPN configuration on the first connection, follow the system prompt, then test an actual request.

Enter only a hostname or IP address in Address, without https://, a path, or query parameters. Port must match the server settings you already have. While 443 is common, TLS services may use other ports, such as 8443; do not change the port to 443 without confirmation. If the supplied settings include transport or other advanced options, match each one as well. The four basic fields alone are not enough to infer a complete configuration.

Password and SNI: Two Different Settings

Password is the Trojan authentication credential; SNI is the server name used during the TLS stage. They serve different purposes and use different formats. A Trojan Password does not have to be a UUID. Even if a credential looks like a UUID, treat it as a complete password; do not split or rewrite it based on VMess or VLESS field conventions.

Address answers “where to connect”; SNI tells the TLS handshake “which server name to request.” A single endpoint may host multiple TLS services, so these fields do not always match. That does not mean you can choose any SNI: the server must recognize the name, and the certificate it returns should match the name the client expects.

When Address is an IP address, be sure to check the SNI supplied by the server. Replacing a domain with an IP may bypass the original address lookup, but it can also change the server name used by default and cause certificate verification to fail. If your existing settings do not specify SNI, do not guess. First confirm the name covered by the server certificate and the TLS settings in the original configuration.

Allow Insecure: Certificate Verification vs. Encryption

Allow Insecure controls TLS certificate verification; it does not control whether TLS is enabled. When enabled, the connection may still be encrypted with TLS, but the client no longer verifies the server certificate in the usual way, so the server’s identity is not confirmed. It also cannot correct an invalid Address, Port, or Password, so it should not be used as a general fix for connection failures.

If the connection fails with this option off but works when it is on, turn it off again and check the device’s date and time, the SNI spelling, the certificate’s validity period, and whether the server sends the complete certificate chain. A significantly incorrect device clock can also affect certificate validity checks. The lasting fix is to correct the settings or server certificate configuration, not to keep bypassing verification.

Manual Settings and Subscriptions: Check Their Sources Separately

Both manually added entries and imported subscription entries must match the server’s actual settings. The difference is who maintains those fields. If you already have a subscription, an update may include a changed Address, Port, or credential from the server. With a manual entry, you need to update changes yourself. Check the imported entry to see whether the subscription includes SNI, transport, and other fields; the entry name alone does not tell you.

Another common mix-up is treating the server entry in Home and the routing configuration in Config as the same thing. The former describes how to connect to a proxy endpoint; the latter determines which policy a request uses. When Global Routing is set to Config, requests follow the active configuration. If a request matches DIRECT, it will not go through the selected Trojan entry.

• Proxy: Use this temporarily to rule out the effect of Config rules, then restore the previous routing mode. Still verify which proxy target is actually selected.
• Direct: Requests connect directly. A website opening in this mode does not prove that the Trojan settings work.
• Config: Requests follow the active configuration and its rules. Check the matching rule and the policy target it selects.

For example, in Config mode, DOMAIN-SUFFIX,example.com,DIRECT sends that domain and its subdomains to DIRECT. Check which rule matched instead of repeatedly changing the Trojan Password. Troubleshoot routing rules separately from protocol connectivity.

Connection Failures: Narrow Down the Cause

First, preserve the conditions needed to reproduce the issue: note the network, selected entry, Global Routing setting, whether Allow Insecure is on, and whether the failure occurs while fetching a subscription or making an actual request. Then change just one variable at a time. The checks below are conditional guidance, not test results for any particular service. The exact error text depends on what the app displays.

A final check should confirm all three: the target entry matches your existing settings, TLS certificate verification succeeds, and an actual request expected to use the proxy completes. If only one website fails, also distinguish between a destination issue, DNS, and routing rules. Do not rewrite every server field just because a single destination fails. For details on DNS and connection triggers, see DNS settings and On Demand settings.