For a Trojan setup, first verify Address, Port, and Password, then check the TLS Server Name (SNI) and certificate validation. This guide is for users who already have a provider and connection details and are ready to fill in the Shadowrocket form on an iPhone or iPad. Checking each item in order helps distinguish connection timeouts, certificate errors, authentication failures, and unmatched rules—without blaming every issue on the password.
How a Trojan connection works: TLS first, then authentication
Standard Trojan uses TLS to protect communication between the client and server. Shadowrocket connects to the specified address and port, completes the TLS handshake and server identity verification, then sends Trojan authentication details and the destination request through the encrypted connection. So an open port does not mean the password is correct, and a successful TLS handshake does not mean the server accepted authentication.
Address identifies the server; SNI indicates the server name to use during the TLS handshake. Proper identity verification also checks the certificate against the expected name. These values may be related, but they are not interchangeable. The domain and port in this guide are examples only, not working connection details. Get your actual values from your provider.
Bottom line: Check the name first when certificate verification fails
For a clear certificate verification error, check SNI, the domain covered by the certificate, and your device’s date and time first. Don’t change the password: it cannot fix a TLS identity verification failure.
Fill in the Add Server form
Tap “+” in the upper-right corner of Home to open Add Server, set Type to Trojan, then fill in the fields. Some TLS options may be in a secondary settings screen; use the fields shown in your current app. Don’t invent values just to fill every field.
| Field | What to enter | Common mistake |
|---|---|---|
| Type | Select Trojan to match the server protocol. | Entering an address or credentials for a different protocol in the Trojan form. |
| Address | Enter the server’s domain name or IP address, such as the example domain edge.example.com. |
Pasting a full URL that includes https://, a path, or query parameters. |
| Port | Enter the value provided, such as the example port 443. |
Changing a non-443 port to 443 or appending the port to Address. |
| Password | Enter the authentication password for this Trojan service, preserving capitalization and special characters. | Using the password for the provider’s website, or including spaces or line breaks when copying. |
| TLS | Standard Trojan relies on TLS; check the related options against the configuration provided. | Treating TLS as a switch that can be turned off for extra speed. |
| SNI / Server Name | Enter the TLS server name specified by your provider. Enter the hostname only. | Entering a full URL, the domain of the website you’re visiting, or a name unrelated to the certificate. |
| Allow Insecure | Leave this off for normal use to keep server certificate verification enabled. | Turning it on whenever a connection fails, masking certificate issues. |
A Trojan password is not a UUID used by other protocols or a token in a subscription link. If you import a link, let the app parse it. When entering details manually, use the original password parsed from the link; don’t use the percent-encoded text as the password. If you’re unsure, ask your provider to confirm the field instead of guessing.
From adding a server to testing: change one variable at a time
For an initial test, start with a configuration whose details are known to be complete. Check each field before saving, then verify whether traffic actually goes through the selected server. Turning on the connection switch in Home only indicates the system connection status; it does not prove that a specific website request went through the Trojan server.
-
Select the protocol
Home → “+” in the upper-right corner → Add Server → Type → Trojan. Don’t identify the protocol by the server name alone; follow the configuration details.
-
Enter credentials
Return to the form and enter Address, Port, and Password. Don’t add a protocol prefix to the address, enter the port separately, and check for spaces at either end of the password.
-
Check TLS
Review the TLS settings. Enter the provided SNI / Server Name and leave Allow Insecure off. Don’t add extra transport parameters unless they were provided.
-
Save and select
After saving, return to Home and select the server you just added. If you were already connected, reconnect after changing the settings so you’re testing the new configuration, not an existing connection.
-
Isolate routing rules
Note the current Home → Global Routing setting, temporarily switch to Proxy, and make a new request to the same destination. Restore your original routing setting when the test is complete.
SNI, certificates, and the limits of Allow Insecure
Address and SNI don’t have to be the same. For example, Address can be the server’s IP while SNI is the domain covered by the certificate. This works if the server presents a valid certificate for that name and the client can verify its identity. Conversely, entering a domain in SNI just because its website opens won’t make a Trojan connection work.
Certificate verification typically checks the trusted issuer chain, expiration date, and name match. An incorrect device date can also cause verification to fail. SNI won’t fix an expired certificate or guarantee network connectivity. Changing SNI at random may cause the server to present a different certificate or reject the handshake altogether.
Allow Insecure off
RecommendedKeep server certificate verification enabled. If an error occurs, check the name, device time, and certificate status first, and ask your provider to fix the certificate or provide the correct details.
Use for: everyday connections and saved configurations
Allow Insecure on
This relaxes certificate verification; it does not fix the certificate. Even if traffic still uses TLS, you can’t confirm the remote server’s identity. Don’t use this as a long-term fix.
Use for: briefly diagnosing certificate verification issues in a controlled environment, once you understand the risks
Bottom line: Keep certificate verification enabled
If the connection works only with Allow Insecure enabled, note the certificate error and check with your provider. Don’t treat this as a completed configuration.
ALPN, transport type, and other advanced options must also match the server. Don’t copy h2, http/1.1, or WebSocket settings from a different configuration you found online. Trojan authentication, TLS, and the underlying transport are separate layers; adding an option doesn’t necessarily improve compatibility.
Common issues: choose your next step based on what you see
These are troubleshooting directions, not one-to-one mappings between errors and causes. Keeping the full error text and test conditions is more useful than simply saying “it won’t connect.” When contacting your provider, say whether you were using Wi-Fi or cellular and which stage failed, but don’t share your password or full subscription link.
The password is correct, so why does the connection still time out?
Go back to Home, edit the server, and check Address and Port. Then repeat the same request over Wi-Fi and cellular. A timeout can happen before authentication; if the result changes when you switch networks, investigate network reachability rather than changing only Password.
I’m getting a certificate error. Which domain should I use for SNI?
Enter the TLS server name explicitly provided by your provider, not the domain of the website you’re visiting. Check your device’s date and time, then verify the spelling. If the name is correct but the certificate still fails validation, ask your provider to check the certificate’s validity and chain.
The latency test shows a number, so why won’t webpages load?
A latency test does not replace a complete request. Make sure the server is selected in Home, then temporarily choose Proxy under Global Routing and make a new request. If it still fails, check TLS, authentication, and connectivity to the destination. Don’t assume the settings are correct just because the latency test returned a result.
Proxy works, but Config doesn’t. What should I check?
Under Config, check the selected configuration and its rules. Verify that the request is routed to the expected policy. Check the match conditions and order for DOMAIN-SUFFIX, IP-CIDR, GEOIP, and FINAL. Also check DNS before assuming the Trojan password is wrong.
My manually changed SNI reverted after updating the subscription. Why?
Check whether the updated server entry was regenerated from the subscription. Keep a manual entry for comparison and confirm the SNI and port delivered by the subscription with your provider. Get subscription links from your provider. Before editing a subscription entry, note its original values to avoid conflicts between updates and manual changes.
Checklist before saving
After testing, confirm “correct parameters” and “correct routing” separately. Proxy, Direct, Config, and Scene in Global Routing handle traffic differently. Switching to Proxy briefly is meant to reduce the number of rule variables; it doesn’t mean you should leave it that way for everyday use. Restore your usual settings and repeat the same request to confirm the result is still as expected.
- Connection details: Type is set to Trojan, and Address, Port, and Password match the values from your provider. The subscription URL has not been entered as the server address.
- Identity verification: SNI uses the specified name, Allow Insecure is off, and the device date and time are correct. Certificate errors have not been bypassed to complete setup.
- Routing: Check the current Global Routing setting. When using Config, verify the selected configuration, rule order, and policy target.
- Updates: Distinguish manually added entries from entries imported with Subscribe, and recheck changed fields after a subscription update.
- Privacy: When reporting an issue, hide the Password, authentication token, and full subscription link. Include the error type and only the necessary non-sensitive test details.
Shadowrocket is a closed-source paid app for Apple platforms, primarily used on iPhone and iPad, and is available exclusively through the App Store. Check the App Store listing for system requirements and compatibility. The app’s one-time purchase does not include a service plan. This guide assumes you already have your own provider and connection details; it does not provide, sell, or recommend servers or subscriptions.