Add a Trojan Server in Shadowrocket: TLS, Address, Port, Password, and SNI

At a glance

This guide is for users who already have server parameters and are ready to add a Trojan connection in Shadowrocket. First, distinguish the network address, TLS identity, and protocol credentials. Then enter each value in Add Server and troubleshoot connection timeouts, certificate errors, and requests that fail after connecting. The example domain and password are placeholders and cannot be used to connect.

How Trojan works: the roles of TLS and Password authentication

The Trojan type in Shadowrocket is used to connect to a server configured for the Trojan protocol. A standard Trojan connection first establishes a TCP connection to the server, then performs a TLS handshake. Once the TLS channel is established, the client sends Trojan authentication data and the destination request. TLS protects the transport and verifies the server's identity; Password handles protocol-level authentication. Neither replaces the other.

Resolve address Establish TCP connection Perform TLS handshake Authenticate protocol Forward request

Address identifies the server to connect to, and Port specifies its listening port. During the TLS handshake, SNI tells the server which hostname the client expects to reach. Certificate verification also checks the certificate's trust chain, validity period, and hostname. A reachable address does not mean TLS verification will pass, and successful TLS verification does not mean the Password is correct.

This guide covers standard Trojan over TLS. If your parameters also specify WebSocket, Host, or Path, follow the server configuration for each value; do not overwrite the existing configuration with this basic example. Changing Type alone cannot turn a server configured for another protocol into a Trojan server.

443

Common TLS listening ports—not a fixed requirement

1–65535

Valid Port range

4 items

Check Address, Port, Password, and SNI first

Before you begin: keep connection and TLS parameters separate

The steps below assume you already have a service provider and subscription. This site does not provide, sell, or recommend nodes or subscriptions. Get the complete set of parameters before you start; do not try to infer missing fields from a server address alone. Passwords, subscription URLs, and full share links may contain access credentials. Keep them out of public screenshots and troubleshooting logs.

Basic connection example

Type: Trojan
Address: edge.example.com
Port: 443
Password: demo-only-not-valid

These are placeholders for illustration. Use the parameters you already have.

TLS verification example

SNI: tls.example.com
Certificate identity: The certificate must cover the hostname used for verification
Certificate trust: The trust chain and validity period must pass verification
Allow Insecure: If this option is available, leave it off for normal use

SNI and Address can differ, but the server configuration must support the difference.

If Address is an IP address but the server uses a domain certificate, you will usually need to enter the specified domain as SNI. Do not copy the IP address into SNI just to make the values match, and do not substitute a popular website's domain. The hostname must match both the server's TLS configuration and the certificate identity requirements.

Enter only a hostname or IP address in Address. Do not include https://, a path, or a trailing slash.
Enter Port as a number on its own. For example, if the server listens on 8443, enter 8443 in the client. Do not change it to 443 just because TLS is enabled.
Enter Password exactly as provided, preserving uppercase and lowercase letters and special characters. Check for spaces or line breaks added during copying.
Enter a hostname in SNI without a scheme, port, or path. If the value is missing, check the original parameters instead of guessing.

Using Add Server: enter the details, save, and select the connection

In Shadowrocket, Home is where you manage and select connections, Config is for configuration files and rules, and Settings contains app preferences. To add a single Trojan connection, open Add Server from the add button on Home. Do not enter Address or Password in Config's rule list.

Open Home, tap the add button in the top-right corner to open Add Server, and set Type to Trojan.
Enter Address and Port as specified in the original parameters. If the address is written as “hostname:port,” split it between the two fields.
Enter Password using the Trojan password supplied for the server. It is not your App Store purchase credential or the contents of a certificate file.
Check the TLS settings and enter SNI as specified. If Allow Insecure appears, leave it off for normal use. Any additional transport options should also match the server configuration.
After saving, return to Home, select the connection you just added, and turn on the connection switch. If iOS prompts you to authorize a VPN configuration for the first time, verify the app and complete authorization.
Check Global Routing, then try a destination that should use this connection. Note the result and any error message.

If you imported the connection from an existing subscription, check that Type, Address, Port, and TLS parameters are complete. A subscription update may overwrite entries it manages. Before troubleshooting, note what you changed and distinguish local edits from values returned by the subscription source. Do not rely on editing a subscription entry as a permanent fix for an error in the source.

Fields and symptoms: troubleshoot by failure stage, not by latency

A connection test reflects performance for a specific target and test method. A latency reading does not mean every destination is reachable, nor does it confirm that authentication, DNS, and rules are all correct. When troubleshooting, first identify the stage where the failure occurs, then check the relevant fields. The table below lists common clues; symptoms do not map to causes one-to-one.

Field or stage	Common symptom	Check first
Address	Hostname cannot be resolved; no connection established	Domain spelling, DNS on the current network, and whether a URL path was included by mistake
Port / TCP	Connection times out or is refused	Actual listening port, network reachability, and whether the server accepts connections
SNI / TLS	Certificate name mismatch or TLS handshake failure	SNI, certificate names, server TLS configuration, and device date and time
Password	Request fails or connection closes shortly after connecting	Password capitalization, whitespace, and server authentication records
Rules and destination	Some sites work, but a specific destination is unreachable	Global Routing, the matching policy, DNS for the destination, and the destination's status

In short: check SNI for certificate errors; don't disable verification to work around them

For a certificate name mismatch, compare SNI character by character with the certificate domain provided by the server. For a validity error, check the device date and the certificate status. Do not leave Allow Insecure enabled as a long-term fix.

Skipping certificate verification weakens server identity checks; it cannot fix a wrong port, incorrect password, or unreachable server. If disabling verification changes the symptoms, that only suggests TLS identity verification may be involved—it does not confirm that the connection is secure. If your environment requires custom trust materials, ask the service administrator for configuration details you can verify.

Connected but still can't access destinations: distinguish Global Routing from Trojan parameters

Trojan parameters determine how Shadowrocket connects to the selected server; Global Routing determines how requests are routed. Proxy, Direct, Config, and Scene are not four different protocols: Proxy uses the proxy route, Direct connects directly, Config applies the policy specified by the configuration rules, and Scene follows the configured scene. When troubleshooting a connection, identify the current routing mode before interpreting the result.

To test the proxy route temporarily, set Global Routing to Proxy on Home and confirm that the Trojan connection being tested is selected. Restore the previous mode after testing.
If destinations are reachable in Proxy mode but not in Config, check the active Config and matching policies before re-entering Password.
Rules are evaluated from top to bottom. The first matching rule determines the policy. DIRECT bypasses the selected Trojan connection, while REJECT blocks the request.
FINAL handles requests that did not match earlier rules and is usually placed at the end. Put exceptions for individual domains before broader rules that would otherwise match them.

This example illustrates rule order only. The domain names are placeholders, not working services. The first rule sends the more specific domain direct; the second sends other requests under that domain suffix through PROXY; and FINAL catches everything else. Before applying it, confirm that PROXY in your current configuration points to the intended proxy selection.

DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

Settings → On Demand handles connections triggered by conditions; it does not fix Trojan Address, SNI, or Password. If manual connection has not yet been verified, keep testing under manual control. Once the basic connection works, check whether the On Demand conditions behave as expected. Automatic VPN activation and a destination matching PROXY are separate decisions.

Trojan setup FAQ

Can I leave SNI blank if Address is an IP?

Check the parameters you have first. If the server uses the domain to select its TLS service or presents a domain certificate, enter the specified SNI. If you only have an IP and no TLS identity details, ask the service administrator; do not try random domain names.

Does Port have to be 443?

No. Port 443 is common, but the value must match the server's listening port. If the specified port is 8443, enter 8443 in Port and make sure it has not also been appended to Address.

Does Password need to be encoded or converted first?

When entering it manually, use the original password. Do not calculate a digest yourself or use escaped text from a share link as the password. If authentication fails after importing a link, compare the parsed Password with the original parameters, paying particular attention to special characters and extra whitespace.

Where should I start if the connection stops working after a subscription update?

Open the entry's edit screen from Home and check whether Type, Address, Port, or SNI changed. Also confirm that the selected entry is still the one you intend to use. If the subscription source keeps returning incorrect values, correct the parameters at the source; updating a subscription does not verify that the connection works.

Can I share a screenshot of a TLS error as-is?

You can share redacted error text, the failure stage, and the conditions under which it occurred. Hide Password and credentials in full subscription or share links. Troubleshooting usually only requires the port, SNI, and whether the certificate name matches; there is no need to publish the full connection details.

After configuration, review these items in order: select the correct entry, check Global Routing, test access to the destination, then restore your usual rules and automatic connection conditions. For more on protocols and rules, see Technical Reference. If the problem occurs only on a particular network, compare Wi-Fi and cellular results to avoid mistaking a reachability issue for an incorrect password.