When configuring Trojan, distinguish the connection address, authentication password, and TLS server name, and keep certificate verification enabled. For users who already have their own server details, this guide walks through the Add Server fields, explains why Address and Peer/SNI may differ, and covers troubleshooting timeouts, certificate errors, and authentication failures.
Trojan and TLS: Encrypt the Connection, Then Verify Credentials
Trojan in Shadowrocket is a proxy protocol option. A typical Trojan connection first establishes a TLS connection to the server, then sends authentication details and proxy requests through the encrypted channel. TLS handles encryption and server identity verification; Password is used for authentication with the Trojan server. These serve different purposes and are not interchangeable.
A website using HTTPS does not mean its server can accept Trojan connections. Your server details must explicitly specify the Trojan type, actual listening address, port, and password. You cannot infer these settings from a domain that simply opens in a browser. Examples in this guide explain the fields only; they are not usable server details.
After selecting Type → Trojan, check whether your existing server details require a specific transport. If they include additional parameters such as WebSocket, match each one to the corresponding field. Do not treat a setup with extra transport requirements as a basic configuration containing only an address, port, and password.
Add Server Fields: Address Is Not SNI
Address specifies where to connect; Port specifies which service to reach at that address. Peer/SNI identifies the server name used for TLS. In Shadowrocket, the relevant field may appear as Peer. Your provider may call it SNI or server name, so match the terms against the current interface and provider instructions.
| Field | What to enter | Common mistake |
|---|---|---|
| Type | Select Trojan. | Credentials for other protocols cannot be used as Trojan parameters. |
| Address | The server domain or IP address in your existing server details. | Pasting the entire share link, or including https:// and a path. |
| Port | The server's actual listening port, such as 443 if explicitly specified in your server details. | Changing it to 443 just because TLS is involved. |
| Password | The Trojan authentication password provided by your service provider. | Entering an account login password or UUID, or copying it with extra spaces. |
| Peer / SNI | The TLS server name specified in your server details, such as tls.example.com. | Entering a URL or port, or substituting a random popular website domain. |
| Allow Insecure | Usually leave this off to retain normal certificate verification. | Treating certificate verification bypass as the standard fix for certificate errors. |
For example, your server details may allow 192.0.2.10 as the Address and explicitly require tls.example.com as the Peer. These values are not necessarily in conflict: the first specifies the connection destination, while the second specifies the TLS name. The IP here is a documentation example and cannot be used to connect. Always use details from your own complete configuration.
Add a Trojan Server Manually: Follow These Five Steps
Save your current working configuration and original server details first. If the server came from an existing subscription, check the imported fields before making changes; a later subscription update may overwrite them. If you need to troubleshoot, keep the original entry and create a separate entry for manual comparison.
-
Open the Add Server Screen
Go to Home → tap “+” in the upper-right corner to open Add Server, then select Trojan under Type. Make sure you are editing a server entry, not a rule file in Config.
-
Enter the Address and Port
Enter the hostname or IP from your server details in Address, and the listening port in Port. Do not add a protocol prefix, path, or query parameters to the address; enter the port separately.
-
Check the Authentication Password
Enter the full password in Password, preserving capitalization and symbols. When entering it manually, use the original password. If you copy it from a share link, remember that escaped characters may not represent the original value directly.
-
Check the TLS Name
Enter Peer/SNI as specified in your server details and leave Allow Insecure off. Check any required transport settings and additional fields as well; do not guess values for fields that were not specified.
-
Save and Test
After saving, return to Home, select the server entry, and confirm the selection indicator appears before turning on the connection switch. The first time you connect, allow the VPN configuration when prompted by the system, then run Connectivity Test.
Connectivity Test checks connectivity; it does not guarantee access to every website, correct handling by every rule, or a consistently stable connection. If the test fails, note what happened and check the parameters. Even if it succeeds, test the actual destination and confirm the request is using this Trojan connection.
Allow Insecure: Encryption vs. Identity Verification
Allow Insecure relaxes certificate verification; it does not switch the connection to plaintext. Even if a TLS channel is established, without reliable certificate verification you cannot confirm the identity of the other end. A correct password does not make up for skipped server identity checks.
Allow Insecure Off
RecommendedRetains normal certificate verification. If you see a certificate error, check Peer/SNI, the device's date and time, the certificate's validity period, and the server's certificate chain rather than ignoring the error.
Best for: Everyday connections and servers with correctly configured certificates
Allow Insecure On
Relaxes certificate verification and reduces confidence in the server's identity. It does not fix an incorrect address, port, or Password, and it is not evidence that the connection is safe to use long term.
Best for: Temporary, controlled troubleshooting of certificate issues when you understand the risks—not for everyday use
Bottom Line: Match the Server Name to the Certificate
If the connection works only when Allow Insecure is on, turn it off again and ask your provider to verify the certificate error, expected Peer/SNI, and time of occurrence. Do not stop troubleshooting just because a webpage opens temporarily.
A certificate error can also result from an incorrect device date or time. Check the system clock, then verify which domain the certificate covers. If Address is an IP, check whether your server details specify a separate Peer/SNI. A certificate issued for a domain does not automatically pass identity verification when connecting by IP.
Troubleshooting Connection Failures: Check Network, TLS, Authentication, and Rules
The same “webpage won’t open” symptom can occur at different stages. First confirm that your local network has internet access, then check the error type in the connection log. The symptoms below help narrow down what to investigate; no single message necessarily identifies the cause.
- Connection timeout: Check Address and Port first, then check DNS resolution and network reachability. A timeout alone does not mean Password is wrong; authentication may not have started if the connection was never established.
- Certificate or TLS error: Check Peer/SNI, the system clock, and the server certificate. A port pointing to an unexpected service can also cause the handshake to fail.
- Disconnects immediately or authentication fails: Check that Password is complete, the service is still active, and the transport settings match. An established TLS connection does not mean every parameter is correct.
- Test passes, but the destination won't open: Check Global Routing and how the current Config handles the request. Then distinguish between a destination website issue, a DNS problem, and an incorrect rule match.
To temporarily rule out routing rules, go to Home → Global Routing, select Proxy, and test the same destination; restore the original mode when done. Proxy routes traffic through a proxy, Direct connects directly, and Config applies the current configuration rules. Interpret Scene according to the configuration in use; it is not a fixed equivalent of Proxy.
If the destination works under Proxy but not Config, check the order and target policies of DOMAIN-SUFFIX, IP-CIDR, GEOIP, and FINAL in the active rules. Editing rules will not fix an incorrect Trojan password; test these as separate issues.
Common Questions About Password, SNI, and Imported Configurations
Should I enter my service provider website login password in Password?
Enter only the authentication password for this Trojan server. Your website account password and proxy authentication password are different. Check the source of the field in your own server details; do not substitute a UUID or key from another protocol.
If Address is already a domain, do I still need to enter Peer?
Check whether the original server details explicitly specify SNI. If they do, enter that value; if they do not, do not make one up. If you see a certificate name error, ask your provider which TLS name is expected instead of trying unrelated domains.
Why does my SNI change back after importing a subscription?
A subscription update may refresh server parameters from the subscription. Keep a separate entry for manual comparison, then check Peer/SNI and transport fields before and after the update. If they keep changing, verify the original subscription configuration instead of repeatedly overwriting the same field.
Does turning on the connection switch mean my Trojan settings are correct?
No. The system connection status means the local VPN connection has started; it does not confirm successful authentication with the remote server or access to the destination. Check that the server is selected in Home, run Connectivity Test, then verify using Global Routing and an actual request.
Before sharing logs or configuration screenshots, hide Password, full subscription links, and sensitive content such as tokens. When describing the problem, include the original error message, the stage where it occurred, and the fields you checked; there is no need to disclose full credentials. Base your conclusions on your own server details, the fields shown in the app, and reproducible test results.