If you already have a provider and valid Trojan settings, check Address, Port and Password against the original details, then confirm that SNI matches the certificate name. Don’t disable certificate verification to compensate for an incorrect field. This guide covers manual setup, the TLS connection process, how subscription updates can affect settings, and a step-by-step approach to “connected but can’t access websites” issues. Example domains, addresses and passwords are for illustration only and won’t connect to a server.
Trojan settings fall into three groups: connection, authentication and TLS
Selecting Trojan in Shadowrocket does not mean you only need to enter a password. The app first connects to a server, establishes a TLS connection, then sends the Trojan authentication details. Address and Port determine where to connect; Password is used for Trojan authentication; SNI and certificate verification help confirm the server’s identity during TLS. These settings serve different purposes and cannot substitute for one another.
This guide assumes you already have valid settings. If you received a complete subscription, keep the imported configuration where possible. Open Add Server only when you need to check individual fields or have been asked to add a server manually. Don’t enter a subscription URL as the server Address or use a token from a subscription link as the Trojan Password.
Bottom line: adjust settings based on where the connection fails
For a certificate name error, check SNI and the certificate first—not Password. For a connection timeout, check Address, Port and network reachability rather than repeatedly changing the password.
Add a server manually: save first, then test
To add a server manually, tap “+” in the top-right corner of Home, open Add Server, then select Trojan under Type. The displayed fields can vary with Type and transport settings; this guide covers the fields to check for a standard Trojan connection. If your original details specify a transport or additional parameters, enter those as provided. Don’t replace them with the basic example in this guide.
-
Choose the type
Go to Home → “+” → Add Server → Type and select Trojan. Don’t choose a different Type just because its settings also include a domain and password.
-
Enter connection details
Return to Add Server and enter Address and Port separately. Enter only a domain name or IP address in Address. Enter the server-specified port as an integer in Port, without a protocol prefix.
-
Enter authentication details
Enter the supplied password in Password, preserving its capitalization and symbols. Check that the copied value has no extra spaces or line breaks at either end.
-
Check server identity
Check SNI and certificate verification under the TLS settings. If your provider specifies an SNI value, enter it exactly as provided. Keep Allow Insecure off so normal certificate verification remains enabled.
-
Save and test
After saving, return to Home, select the record and connect. When prompted for the first time, allow the VPN configuration. Before testing, note the current selection under Home → Global Routing so you don’t mistake routing behavior for a server connection issue.
Change only one setting at a time when testing. For example, correct Port, reconnect and observe what happens. Don’t change Address, Password and SNI all at once. If you change several settings and the connection starts working, you won’t know which one was wrong—and the same issue may return after a subscription update.
What to enter for Address, Port, Password and SNI
The sample settings below are not valid for connecting to a server. 192.0.2.10 is a documentation-only IP address, and example.com is an example domain. The table shows how the fields relate; it does not represent an available service.
| Field | Example value | What to check |
|---|---|---|
| Type | Trojan |
Must match the protocol specified in the original settings. |
| Address | 192.0.2.10 |
Use an IP address or domain name. Don’t include https://, a path or query parameters. |
| Port | 443 |
Must match the port the server actually listens on; don’t automatically change it to 443 just because TLS is used. |
| Password | Demo-Only-Not-A-Real-Password |
Enter the original password. Don’t calculate a hash or substitute a subscription token. |
| SNI | tls.example.com |
Use the TLS name specified by the server. Don’t include a protocol, port or path. |
| Allow Insecure | Off | Keep certificate verification enabled. If the certificate is invalid, correct the settings or contact the maintainer of your existing service. |
Address and SNI don’t have to match
Address determines the destination for the network connection. SNI tells the server which hostname is being requested during the TLS handshake; the server may use it to select a certificate or handle the connection. If you use an IP address for Address, SNI may still need a domain name, such as tls.example.com in the table. There’s no conflict, and it doesn’t mean you should replace Address with that domain.
If Address is already the domain name on the certificate and your original settings don’t specify a separate SNI, keep the imported value or default setting for now. If you see a certificate name error, ask the maintainer of your existing service which name to use. Don’t enter a random website domain: SNI isn’t a free-form note. An incorrect value may cause the server to return a different certificate or make the handshake fail.
Password is not the entire share link
- When entering settings manually, use the decoded field value. Don’t paste an entire
trojan://share link into Password. - Take URI encoding into account when reading settings from a share link. Special characters in a password may be percent-encoded, so copying the encoded text may not give you the original password.
- If you have a complete share link, use an import option supported by the app to preserve its settings, then open the record to check them. This is usually less error-prone than parsing the link by hand.
TLS certificate verification: a connection alone doesn’t confirm server identity
TLS does more than encrypt traffic; it also verifies the server’s identity. Proper verification depends on the certificate chain being trusted, the certificate being valid and the name matching. A correct Password can’t compensate for a certificate error. Likewise, a successful TLS handshake doesn’t mean the server has accepted the Trojan password.
If you see a certificate error, check SNI first, then make sure the date and time on your iPhone or iPad are correct and that the server certificate hasn’t expired. The service maintainer needs to fix a missing certificate chain or an incorrect name. Don’t change your device clock to an incorrect date just to dismiss the warning.
Keep normal certificate verification enabled
RecommendedKeep Allow Insecure off. A certificate error should prompt you to check the name, expiration date or trust chain—not hide the problem.
Use for: everyday connections and confirming that a corrected setting actually fixed the issue.
Skip certificate verification
Turning on Allow Insecure weakens server identity verification. Even if the connection status changes, that doesn’t prove the certificate issue is fixed or that you’re connected to the intended server.
Use for: understanding what this troubleshooting option does and the risks involved—not as a fix recommended by this guide.
Bottom line: fix the name, then reconnect
If correcting SNI restores the connection, keep certificate verification enabled and test actual access. Don’t leave verification disabled or weakened after troubleshooting.
Connected but can’t access websites: check the server, routing and on-demand settings separately
A VPN status of Connected means the tunnel is established; it doesn’t guarantee that every destination can be reached through the selected Trojan server. Selecting a record on Home also doesn’t guarantee that every request will use it. Check the server settings separately from the routing policy applied to each request.
- Home → Global Routing → Proxy: Temporarily use this to isolate the effect of routing rules and see whether test requests routed through the proxy can reach their destination using the selected server. Restore your previous selection after testing.
- Home → Global Routing → Direct: Requests are handled as direct connections. A website opening successfully in this mode does not prove that the Trojan settings are correct.
- Home → Global Routing → Config: Traffic is handled according to the current configuration. Check the enabled file and its rules under Config; don’t assume all traffic goes through the selected server.
- Home → Global Routing → Scene: Check the settings for the current Scene. Don’t assume its behavior is the same as Proxy or Config.
- Settings → On Demand: Check whether on-demand settings affect automatic connection triggers. On Demand controls when the connection starts; it doesn’t fix the Trojan password, SNI or certificate.
In Config, DOMAIN-SUFFIX matches domain suffixes, GEOIP matches IP geolocation, IP-CIDR matches IP ranges, and FINAL handles traffic that didn’t match earlier rules. Rule order and the final policy both affect how traffic is routed. The example below illustrates rule syntax only; it isn’t a complete configuration and doesn’t need to replace your existing file.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYFor example, a request matching DIRECT won’t test whether the current Trojan server is available. Conversely, if a request works with Proxy temporarily selected but fails after you restore Config, check the rules, policies and domain resolution settings before changing Password. When recording test results, note the destination, routing selection and error message. This guide doesn’t provide made-up latency or success-rate figures.
Common setup mistakes and what to check after subscription updates
A subscription is a source of configuration; a server record is an individual entry imported from it. Updating a subscription may change the address, port, authentication or TLS settings, and later updates may overwrite manual changes. Before troubleshooting, note the field names and error message, but don’t post complete details containing a password or token in a public forum.
Should I include https:// in Address?
No. Go to Home and open the record’s edit screen. Keep only the domain name or IP address in Address, and enter the port in Port. A website URL, subscription URL and server address serve different purposes and shouldn’t be used interchangeably.
The supplied port isn’t 443. Should I change it to 443?
No. Port must match the value the server actually listens on. If the supplied value is 8443, enter 8443. Trojan uses TLS, but that doesn’t mean the server must listen on port 443.
The certificate name doesn’t match. Is the password wrong?
First check that the record’s SNI matches what the server requires and that you haven’t included a protocol prefix or port. Then check your device’s date and time. Certificate identity verification and Trojan password authentication are separate steps. Changing Password repeatedly won’t fix a certificate name mismatch.
What should I do if a subscription update changes my manually set SNI?
After updating the subscription on Home, reopen the record and check SNI, Address and Port. If updates keep returning an incorrect value, report the specific field to the maintainer of your existing service. If you need to keep test settings, create a separate manual record and give it a distinct label.
Why does the server still fail to connect when the subscription updates successfully?
A successful subscription update only means that the configuration was retrieved and parsed; it doesn’t mean the server passed a connection test. Return to Home, select the relevant record, check Global Routing and test again. Then troubleshoot timeouts, certificate errors or authentication failures separately.
What to include when reporting a problem
- Note whether the record was added manually or imported from a subscription, and whether the issue started immediately after a subscription update.
- Note the current Type, Port, Global Routing selection and full error message. For sensitive fields, state only whether they match the original settings.
- Record each individual change and its result—for example, “Correcting SNI cleared the certificate name error, but the destination is still inaccessible.”
- Hide Password, subscription tokens and complete share links. If sensitive information has already been exposed, use the account management channel for your existing service to replace the affected credentials.
After troubleshooting, restore your intended Global Routing and On Demand settings, confirm that normal certificate verification is still enabled, then check the destinations you use regularly. This separates temporary diagnostic settings from your final configuration and helps prevent a successful test from leaving you with settings that aren’t suitable for everyday use.