How to Configure a Trojan Server in Shadowrocket: Password, SNI, and TLS Settings

1. What Each Trojan Setting Does

Trojan uses TLS to protect communication between the client and server, with protocol authentication taking place over the encrypted connection. To understand the setup sequence, think of it in stages: resolve the address, connect to the port, complete the TLS handshake, submit authentication details, and forward requests. If an earlier stage fails, later settings usually have no effect yet. So a connection failure does not automatically mean the Password is wrong.

Address specifies where to connect; Port specifies which server endpoint to use. SNI supplies the server name during the TLS handshake, while certificate verification checks the server's identity. Password is used for Trojan authentication. A correct Password does not guarantee a valid certificate, and an open port does not mean Trojan authentication has succeeded.

Port 443 is a common example, not a requirement for Trojan. If your details specify 8443, enter 8443. Standard Trojan settings also cannot be applied automatically to other transport combinations. If your details call for additional transport settings, check each one; Address, Port, and Password alone do not guarantee a complete configuration.

2. Add a Server from Home → Add Server

Before adding a server manually, save a copy of the existing settings so you can distinguish the original values if anything changes. These steps are for standard Trojan. If the details came from a subscription, inspect the imported fields first and then decide whether to create a separate entry manually. Options may appear in different places depending on the interface layout; follow the English field labels shown on the current Add Server screen.

1. Choose a type

   Open Home, tap “+” in the upper-right corner to open Add Server, and select Trojan under Type. Don't reuse an entry for another protocol and change only the Password; the protocol type determines what the other fields mean.

2. Enter Address and Port

   Enter the domain name or IP address from your server details in Address, and the corresponding number in Port. Do not include https://, a webpage path, or a trailing slash in Address. Enter the port separately rather than appending it to the address.

3. Check the Password

   Paste the complete authentication Password and check for leading or trailing spaces and line breaks. The Password is not a subscription URL or a website login password. Don't add quotation marks or replace characters in the supplied value.

4. Check the SNI

   Enter the server name specified in your details under SNI. Check this field carefully if Address is an IP address but the certificate was issued for a domain name. Keep certificate verification enabled; don't use Allow Insecure as a routine connection setting.

5. Save and test

   After saving, return to Home, select the server you just added, check Global Routing, and turn on the connection. Approve the system prompt the first time you connect. Test with a known accessible webpage rather than relying on the switch state alone.

3. Address vs. SNI: What to Enter

Address is the network connection target; SNI is the name sent during the TLS handshake. They can be the same or different. For example, if you connect to an IP address but the certificate is for a domain, the client connects to the specified port at that IP while still sending the domain during the handshake. The server may need that name to select the right certificate or handle the connection correctly.

SNI cannot make an unreachable IP address reachable, and you cannot enter just any website domain. It must match the existing server details and server configuration. Randomly changing SNI for the same address is not a reliable fix and can make certificate name mismatches harder to diagnose.

The 192.0.2.10 address in the table is reserved for documentation examples and cannot be used to test a real service. If your details don't specify SNI, don't guess a name; check the imported entry and original instructions first. Automatic handling when SNI is blank is no substitute for checking the actual certificate name, especially when Address is an IP address.

• Enter only the name in SNI—not https://, :443, or a path.
• A certificate covering *.example.com does not necessarily match subdomains at every level. For example, a.b.example.com is not covered by a typical single-level wildcard.
• Name matching is only one part of certificate verification. An expired certificate, an invalid trust chain, or an incorrect device clock can also cause the handshake to fail.

4. TLS Certificate Verification and Allow Insecure

Trojan uses TLS not only to encrypt traffic but also to verify the server's identity. Settings such as Allow Insecure change certificate verification requirements; they do not fix the server Address, Port, Password, or listening status. Even if the connection works with verification disabled, that only suggests a certificate-related condition needs checking—it does not prove all settings are correct.

If the server uses a special certificate setup, your existing server details should explain how verification is meant to work. Disabling certificate checks in the client at random does not establish trust. When reporting an issue, you can share the error type and the stage where it occurred, but don't disclose your Password, full subscription URL, or other authentication details.

5. Can't Open Webpages After Saving? Troubleshoot by Stage

When the Home connection switch is on, the local connection feature is running; that does not mean the remote server has authenticated successfully. Distinguish between a server connection failure, a failure to reach the destination website, and requests that are not using this server. Change one variable at a time and note the test time, network, and result.

1. First, confirm the selected entry. Return to Home and check which server is active. You may have edited a new entry while still using the original one. If your configuration uses a policy group, also check which server is actually selected within the group.
2. Next, check the routing mode. In Home → Global Routing, Direct connects directly, Config follows the active configuration, and Proxy can help test the proxy route temporarily. Scene is a context-based selection; check what is actually active rather than assuming the name represents a fixed rule.
3. Check the Address and Port. If the connection times out, first check that the domain resolves and the Port matches your details, then compare Wi-Fi and cellular results. A timeout alone does not prove the Password is wrong.
4. Check the TLS stage. For a certificate or handshake error, verify the SNI, device clock, certificate validity period, and whether the server provides the expected TLS service on that port.
5. Finally, check authentication and the destination. If the connection is established but then closed, recheck the Password and consider the server's status. If only one website fails, check that destination and its rules instead of immediately rewriting the entire server entry.

With Config selected, open Config and check the Rule section of the active file. Rules are matched in order. A request matching DOMAIN-SUFFIX,example.com,DIRECT uses DIRECT, so visiting that domain cannot confirm that Trojan is working. If no rule matches, check the FINAL policy and which server the policy group ultimately selects.

6. Common Questions About Password, SNI, and Imported Entries

After checking the settings, keep a password-free record of the protocol type, Port, whether Address and SNI differ, certificate verification status, Global Routing mode during the test, and the stage where the error occurred. This makes future troubleshooting more systematic than repeatedly switching settings.