Shadowrocket Trojan Setup: How the Protocol Works and How to Fill In Add Server

How Trojan Works: TLS First, Then Protocol Authentication

Trojan carries proxy traffic over an encrypted TLS connection. A typical basic connection uses TCP: the client connects to the server address and port, completes the TLS handshake and certificate verification, then sends Trojan authentication details and the target request. The server forwards traffic only after authentication succeeds. So “port reachable,” “TLS handshake successful,” “password accepted,” and “website accessible” are separate checks; none can stand in for another.

TLS encrypts the connection and verifies the server’s identity. The Trojan password authenticates access to the protocol; these serve different purposes. A correct password won’t fix an expired certificate, and a valid certificate doesn’t mean the password is correct. If a server uses port 443, that only means it accepts connections on that port—not that it necessarily runs Trojan.

This guide covers basic Trojan over TLS. If your provider also specifies WebSocket, a path, or other transport settings, Address, Port, and Password alone may not be enough to connect. Check the complete set of details from the same configuration. Don’t mix SNI, Password, or transport settings from different services.

Before Add Server: Gather the Complete Settings

Before entering anything manually, confirm that the details explicitly specify Trojan; don’t infer the protocol from a port or domain alone. Importing a subscription preserves the complete set of fields supplied by your provider. Manual setup is useful when you want to check each setting yourself. Both methods use the same connection details; the difference is who enters them.

• Server address: The full hostname or IP address, without https://, a path, or a port.
• Server port: Enter the port number on its own, such as 443. If your details specify a different port, use that value.
• Password: Preserve uppercase and lowercase letters and every symbol. Make sure you don’t copy leading or trailing spaces, line breaks, or quotation marks.
• SNI and certificate requirements: Note the TLS hostname specified by your provider and whether any additional trust settings are required.
• Additional transport settings: If your details include a transport type, Host, or path, first confirm which fields this configuration requires, then enter them under the relevant options.

Home → Add Server: Enter Address, Port, and Password

On Home, tap the add button in the upper-right corner to open Add Server. Set Type to Trojan, then fill in the fields below. Field order and optional settings may vary in the current app interface. Match each detail to its field by meaning rather than relying on the position shown in an older screenshot.

1. Enter Type, Address, and Port first. Make sure the port isn’t duplicated in Address.
2. Paste the Password and check that every character is present. Enter the password as provided; don’t URL-encode it yourself.
3. Set SNI according to your details and check the certificate verification option. Include any required transport settings.
4. Save, return to Home, select the new entry, then connect. If iOS asks to add a VPN configuration, follow the system prompt.

Matching ports don’t make settings interchangeable, and changing Port won’t change the server’s listening configuration. If no port is provided, ask your service provider instead of trying common ports one after another. Password is also not your app purchase password or device passcode.

SNI and Certificate Verification: The Address Isn’t the Identity

Address determines where the client connects. SNI is the server name sent in the TLS handshake, allowing the server to select the appropriate site and certificate. In a typical domain-based setup, the client also needs to verify that the certificate is trusted, within its validity period, and matches the expected identity. SNI is neither a password nor a switch that makes a certificate trusted.

For example, if the connection address is an IP but the server certificate is issued to tls.example.com, you can’t simply use that IP as the certificate name. Conversely, entering an unrelated website domain won’t give the server its certificate or configure its site automatically. SNI must be a name the connection actually supports.

Custom certificates or special trust settings require separate verification. Don’t leave certificate verification disabled just to make an error disappear temporarily. A successful TLS handshake only describes the connection between the client and that server; it doesn’t mean every destination website is reachable.

After Saving: Separate Protocol Issues from Routing Issues

Saving successfully only means the settings are stored locally; it doesn’t mean the server has authenticated you. First check the selected entry and Global Routing, then run a repeatable access test. Under Config, rules determine the policy for each request; some requests may use DIRECT. So one website loading doesn’t prove that Trojan is working.

1. Check the selected entry: Return to Home and make sure the newly saved Trojan entry is selected, not another item in the list.
2. Check the routing mode: In Global Routing, see whether the current mode is Proxy, Direct, Config, or Scene. Direct won’t test this proxy. For Scene, first check which policy it actually uses.
3. Run an isolated test: If needed, switch to Proxy briefly and test a known HTTPS page you’re authorized to access. Restore your previous setting when done. Proxy helps rule out routing as a variable; it won’t fix an incorrect password.
4. Check request logs: Use the request log and any available error details to distinguish DNS lookup, connection, TLS, and subsequent forwarding stages. Interpret test results according to the test type; a latency reading alone doesn’t prove the service is fully usable.
5. Recheck Config: If Proxy works but Config doesn’t, check rule order and the associated policy. Confirm that the request actually selects the expected proxy.

Rules are generally matched from top to bottom, and the first match determines the policy. The example below illustrates rule behavior; it isn’t a complete configuration to replace your existing Config. In an actual configuration, PROXY must refer to an available policy.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

This example routes example.com and its subdomains through PROXY, while unmatched requests go through DIRECT. If you test only a different domain, its traffic may never use Trojan. The same applies to rules such as GEOIP and IP-CIDR in your configuration: first identify which rule matched, then check whether the outbound settings are at fault. Put FINAL at the end of the rules.

Troubleshooting: Check the Failure Stage Instead of Rebuilding Repeatedly

The steps below are troubleshooting pointers, not definitive diagnoses for any single error. The same timeout could mean the address is unreachable, the server isn’t responding, or a later request isn’t getting a response. Consider the error together with the stage where it occurs.