Shadowrocket Trojan Setup: Password, SNI, and TLS Certificate Checks

At a glance

This guide is for users who already have server details or a subscription and want to check their Trojan settings in Shadowrocket. It explains the difference between the connection address, authentication password, and TLS identity verification, then walks through the Home → Add Server setup and troubleshooting for timeouts, certificate errors, and authentication failures. This site does not provide, sell, or recommend servers or subscriptions.

What TLS and the password each verify in a Trojan connection

The Trojan option in Shadowrocket connects to a compatible Trojan server. A typical connection first establishes TCP, then completes a TLS handshake, and finally sends Trojan authentication details and the target request through the encrypted channel. Resolving the address and connecting to the port only confirms that the initial network steps are possible; it does not mean certificate verification or password authentication has succeeded.

TLS encrypts traffic and verifies the server's identity; the Trojan password authenticates the client to the server. Neither replaces the other: a correct password cannot fix a certificate name mismatch, and a valid certificate will not make an incorrect password work. When troubleshooting, distinguish between “cannot connect to the port,” “TLS handshake failed,” and “request failed after the handshake.”

443

Common TLS server ports; use the port in your existing server details

TCP

The basic transport flow for a Trojan connection discussed here

3 items

Check the certificate name, validity period, and trust chain separately

Bottom line: identify which layer is failing first

For a connection timeout, check the address and port first. For a certificate error, check the SNI, certificate, and device clock. Changing the password or enabling Allow Insecure is not a general fix for every failure.

Enter Trojan settings in Add Server

To add a server manually, start from Home; do not edit a rules file in Config. Config manages configuration files and rules, while this section covers server connection settings. Before you begin, keep a copy of the original server details and confirm the provider specifies Trojan—port 443 alone does not identify the protocol.

Open the Add Server screen

On Home, tap “+” in the upper-right corner to open Add Server. Tap Type, select Trojan, then return to the settings screen. If you are editing an entry created by a subscription, note its original values first so you can compare them after a subscription update.
Enter the connection address

Enter the domain name or IP from your existing server details in Address, and the corresponding port in Port. Do not include https://, a path, or a port suffix in Address. For example, enter the domain and 443 in separate fields.
Check the authentication password

Enter the password specifically provided for Trojan in Password. Do not use your App Store account password, and do not assume it is the same as your provider account password. Check capitalization, leading or trailing spaces, and line breaks. When entering it manually, use the original password—not the percent-encoded form from a share link.
Check the TLS settings

Enter the supplied SNI and make sure Allow Insecure is off. If the configuration includes additional transport options, match each one as well; copying only the address and password may leave out essential settings.
Save and test

Tap Done to save, then return to Home and select the entry. The first time you connect, follow the system prompt to authorize the VPN configuration, then test an actual request. Saving confirms only that the settings were entered; it does not confirm that the server accepted the connection.

How Address, SNI, and the certificate name relate

Address determines where the network connection goes. SNI is the server name sent in the TLS handshake, allowing a server hosting multiple sites to select the corresponding certificate. SNI is not a webpage URL: it has no scheme, port, or path, and choosing any reachable domain will not necessarily work. Its value must match the actual server configuration.

After the server returns a certificate, the client still has to verify its identity. The expected server name must match a name permitted by the certificate; check the Subject Alternative Name in particular. Changing SNI to another domain does not change the certificate or automatically route the network request to the server associated with that domain.

Field	Example or value	What to check
Type	`Trojan`	Must match the protocol actually used by the server
Address	`edge.example.com`	Enter the connection domain only; do not include a URL path
Port	`443`	Example value, not a protocol-mandated port
Password	Your Trojan authentication password	Keep the original characters; do not add spaces
SNI	`tls.example.com`	Illustrates that the address and name can differ; the actual values come from the server
Allow Insecure	Off	Keep standard certificate verification enabled

The domain names in the table illustrate how the fields relate; they are not usable connection settings. If Address is an IP, check whether your existing server details specify an SNI. If the certificate covers only a domain but the client verifies the identity against an IP, the names may not match. If the SNI is correct but verification still fails, check whether the certificate has expired, whether the server returned the wrong certificate, and whether the intermediate certificate chain is complete.

What Allow Insecure does—and when to keep verification on

Allow Insecure is not a routine performance setting for “better compatibility.” Enabling it relaxes TLS certificate verification, so you can no longer rely on normal checks to confirm the identity of the server you connected to. It will not fix DNS, an incorrect port, a wrong password, or a server outage, and it should not be your first change when a connection fails.

Allow Insecure off

Recommended

Keep certificate verification enabled. If you see a certificate error, correct the SNI, device clock, certificate validity, or server certificate chain so the connection passes normal verification.

Best for: everyday use and configurations with a trusted server certificate

Allow Insecure on

Relaxes certificate verification and reduces confidence in the server's identity. If a request succeeds with this option enabled, that only suggests certificate verification may have blocked the connection; it does not prove the configuration is secure or the issue is fixed.

Best for: brief, controlled troubleshooting by maintainers who understand the risks—not for everyday use

Bottom line: make certificate repair the end goal

If the connection works only when Allow Insecure is enabled, ask the server maintainer to check the certificate being returned, its name coverage, and the certificate chain. Once fixed, turn the option off and test the request again.

Troubleshoot by symptom: timeouts, certificate errors, and authentication failures

Change one variable at a time, and note the network, selected entry, Global Routing setting, and error message. A latency test returning a result does not mean a full Trojan request passed authentication. Also test a known reachable destination and check whether all destinations fail or only some do.

It keeps timing out after setup. Is the password wrong?

Not necessarily. Reopen the entry on Home and check Address and Port, then confirm the server is listening on that port. If Address is a domain, check whether the current network can resolve it. Verify basic connectivity first, then check TLS and the password. Do not change several fields at once.

The certificate name does not match. What should I change?

First, check that SNI exactly matches the name supplied by your provider, with no https://, path, or trailing spaces. If it matches, ask the maintainer to check the name on the certificate actually returned. When multiple TLS sites share an address, an incorrect SNI may return another site's certificate.

The certificate is still valid. Why does verification fail?

A valid date range is only one requirement. First, check the device clock in Settings → General → Date & Time, then ask the maintainer to inspect the intermediate certificate chain and trust source. A name mismatch, incomplete chain, or incorrect device clock cannot be fixed simply by changing the password.

The connection drops immediately after it starts. How do I check the password?

Open Password for the entry and copy the value again from a trusted source. Check capitalization, line breaks, and leading or trailing spaces. If you previously split the fields manually from a share link, make sure you did not enter encoded characters as-is. A disconnection alone does not prove the password is wrong; ask the maintainer to confirm the authentication result in the server logs.

I selected the Trojan entry. Why are requests still going direct?

Check Home → Global Routing first. Direct sends traffic directly; Config follows the current configuration rules; Proxy sends requests to the proxy policy; and Scene depends on the configured scene. Selecting an entry alone does not override the current routing setting, so also check which policy the request actually uses.

After connecting, check rules and on-demand connection settings

After the Trojan settings pass verification, return to your regular routing configuration. When Global Routing is set to Config, rules are matched in order. FINAL is the fallback when no earlier rule matches; it does not mean every request will use the selected Trojan entry. Also check the policy group targeted by the rule and which server that group selects.

Check the active configuration: In Config, confirm which file is currently in use; do not rely on the rules in a file that is not enabled.
Check where the rule sends traffic: DOMAIN-SUFFIX,example.com,PROXY matches the domain suffix and sends the request to the PROXY policy. Check the configuration to see which server that policy ultimately selects.
Check the fallback behavior: FINAL,DIRECT sends requests that do not match earlier rules directly. It does not prove that the Trojan connection has failed.
Check on-demand conditions: Go to Settings → On Demand to review the configured triggers. On Demand starts connections based on those conditions; it does not fix the server password, SNI, or certificate.
Keep records you can review: Note which fields you changed and the result. Before sharing an error report, redact Password and subscription authentication details; never share complete configuration credentials.

To identify which layer is failing, see the connection troubleshooting guide. For questions about rule and policy names, see the glossary. If the same issue returns after a subscription update, compare the address, port, SNI, and transport settings before changing anything; do not disable certificate verification as a first step.