How to Add a Trojan Server in Shadowrocket: Protocol Basics and Add Server Settings

1. Trojan and TLS: How the connection works

Trojan is a proxy protocol. TLS encrypts traffic between the client and server and verifies the server’s identity. A typical Trojan connection starts with a TCP connection, followed by a TLS handshake, then sends authentication details and the destination address through the encrypted channel. A successful TLS handshake confirms only that the secure channel is established; it does not mean the password is correct or that the destination website is reachable.

TLS here does not mean the proxy server decrypts all of your HTTPS traffic. When you visit an HTTPS site, your browser will typically establish a separate TLS connection with that site. Trojan’s TLS is the outer connection between your device and the proxy server. These two connections involve different certificates and failure points, so a server certificate error should not be confused with a website certificate error.

TCP port 443 is common, but it is not required by the protocol. If the server listens on another port, enter that port instead. Trojan is also not QUIC: don’t change the transport to Hysteria2 just because the configuration mentions UDP forwarding, or assume that all games and voice apps will behave the same way.

2. Add Server: What to prepare and how to add a server

First, find the server address, listening port, password, and TLS name requirements in your existing configuration. If you have a subscription URL, import it using the existing subscription workflow rather than guessing parameters from a name or screenshot. Manually entered records and subscription records may be maintained differently when updated, so confirm which record you’re editing before making changes.

1. Open the add-server screen. On Home, tap the add button in the upper-right corner to open Add Server, then set Type to Trojan. Don’t enter a Trojan password in a UUID or identity field for another protocol.
2. Enter Address. Enter only the hostname or IP address, such as example.com. Don’t include https://, a webpage path, or subscription query parameters. The domain in this guide is an example of the format, not a working service.
3. Enter Port. Use the number in your original configuration. For example, enter 443 only if the server is explicitly configured to use port 443. A domain opening in your browser does not mean the proxy server listens on port 443.
4. Enter Password. Match every character, including capitalization and symbols. Check for spaces or line breaks copied along with it. Password is not the full query string from a subscription URL, and it cannot be replaced with your provider website login password.
5. Check the TLS settings. Set SNI as specified in your configuration. If the interface has a TLS switch, leave it enabled for a standard Trojan TLS setup. Keep Allow Insecure off, and don’t add transport extension parameters that weren’t provided.
6. Save and select the server. After saving, return to Home, select the record you just added, and run a connection test. When creating the system VPN configuration for the first time, grant permission when prompted. System permission and server authentication are separate steps.

3. How Address, SNI, and certificate names relate

Address determines the network address the client connects to. SNI is the server name sent during the TLS handshake, often used to select the right certificate when multiple services share an address. They’re often the same, but don’t have to be. Setting SNI does not send traffic to a different network address, and it cannot fix an incorrect Address.

If Address is an IP address but the certificate was issued for a domain, the configuration will usually specify the correct SNI. Don’t simply copy the IP address into SNI. The certificate must also be within its validity period and have a trusted certificate chain. A correctly spelled domain alone doesn’t guarantee these checks will pass. If the configuration doesn’t specify the required name, ask the person who provided it rather than trying unrelated domains.

Allow Insecure relaxes certificate verification; it is not a general setting for improving network compatibility. Enabling it may let a connection proceed despite an invalid certificate, but it also weakens server identity verification. For certificate issues, check SNI, device time, certificate validity, and the server’s certificate chain. If your environment requires a specific trust configuration, follow its certificate deployment instructions instead of leaving verification disabled.

4. Test after saving: distinguish protocol failures from rule mismatches

A successful save only means the record was stored. After returning to Home, check that the Trojan record you just added is selected, then run Connectivity Test. Results depend on the test target, network path, and test method. A latency result does not verify access to every website, UDP app, or routing policy.

1. Check the connection status. Turn on the connection switch on Home and see whether it disconnects immediately. If the app hasn’t established the system VPN connection, resolve permission or local configuration issues first rather than changing the remote port.
2. Temporarily isolate routing variables. On a network where this is permitted, temporarily set Global Routing to Proxy and use the selected server to access a specific test target. Proxy helps rule out most rule-selection issues; it won’t fix TLS or password errors.
3. Switch back to Config. Once the server works, set Global Routing back to Config and check which configuration is active. Direct is not suitable for testing Trojan forwarding because requests may not use the proxy at all.
4. Check automatic connection settings. While troubleshooting, check Settings → On Demand so automatic connection conditions don’t change the test state. Restore your previous settings when you’re done. On Demand controls when connections start; it does not fix Password or SNI.

The rules below show matching order and do not include a working server. They send example.com and its subdomains to PROXY, send documentation-only reserved address ranges to DIRECT, and route all other requests to PROXY. Add rules only to the [Rule] section of an existing configuration; don’t replace the entire file with this snippet.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

Rules are checked from top to bottom. After the first match, later rules are skipped, and FINAL provides the fallback. PROXY is a policy identifier, not a server address or a place to enter your Trojan password. Confirm that the active policy selects the server you’re testing. If Proxy works but Config doesn’t, check rule matching, policy selection, and DNS first rather than re-entering the same server details.

5. Troubleshoot timeouts and authentication failures by stage

Narrow down the cause by identifying where the failure occurs. A client error may be generic; a timeout alone does not prove the password is wrong. Change one setting at a time and record what happens before and after. When testing on Wi-Fi and cellular, keep the same server record and test target so you don’t change too many variables at once.

A server address displaying an HTTPS page in a browser does not prove that the Trojan password and forwarding settings are correct. Browser access and Trojan authentication are separate requests. Likewise, one unreachable test target does not necessarily mean the entire server is unavailable. Use the failure stage and several controlled tests to diagnose the issue. This guide makes no claims based on speed or availability testing.

6. Common setup questions