This guide is for users who have received Trojan settings from their provider and need to add or check a configuration manually in Shadowrocket. First, distinguish the server address, authentication password, and TLS identity, then enter each value in the corresponding Add Server field. If you see a certificate error, authentication failure, or no access after connecting, troubleshoot by connection stage rather than treating Allow Insecure as a universal fix.
What the address, password, and TLS each do in a Trojan connection
Trojan in Shadowrocket is a proxy protocol. A typical connection first reaches the server and establishes a TCP connection, then completes a TLS handshake before sending Trojan authentication details and the destination request. TLS protects traffic and verifies the server's identity; the Trojan password authenticates with the server. They serve different purposes and cannot replace each other.
Before you start, get the complete settings from your provider: server address, port, password, TLS domain, and any additional transport settings. Don't guess the remaining fields based only on the word “Trojan.” If you have a subscription, import it first and check individual fields only when you need to compare settings. This helps avoid omissions when copying values manually.
Complete the settings before creating an entry
If you only have the address and password, ask your provider to confirm the port and TLS domain. Don't try random ports or disable certificate verification to guess the right settings.
Add Server fields: which values to enter exactly as provided
On Home, tap “+” in the upper-right corner to open Add Server, then set Type to Trojan. Field order may vary between platforms, so check each field by its meaning rather than copying values based on their position in a screenshot. The example below uses reserved example domains to explain how the fields relate; it is not a working configuration.
| Field | What to enter | Common mistake |
|---|---|---|
| Type | Select Trojan. | Changing only the entry name without changing the protocol type. |
| Address | Enter the domain or IP address provided by your service provider, such as edge.example.com. | Pasting a full URL that includes https://, a path, or a port. |
| Port | Enter the integer port provided, such as 443. Valid values range from 1–65535. | Assuming the example port is fixed, or entering the port in the address field. |
| Password | Enter the Trojan authentication password exactly as provided, preserving capitalization and special characters. | Entering a subscription token or account password, or accidentally including leading or trailing spaces. |
| SNI | Enter the specified TLS domain, such as tls.example.com. | Entering a URL, path, or port, or mistakenly using the domain of the website you're visiting. |
| Allow Insecure | Leave this off for normal use so the client verifies the server certificate. | Treating certificate verification bypass as a connection speed boost or an authentication fix. |
A Trojan Password is usually an authentication string, not an encryption algorithm you need to choose or a combination of username and password. Enter the string from your provider as-is. Don't Base64-encode it, hash it, or add quotation marks. If you extract the password manually from a share link, watch for percent-encoding. Importing the full link in the client is usually safer than mistaking encoded text for the original password.
If your settings also specify a transport such as WebSocket, configure its transport parameters as instructed. SNI, the WebSocket Host, and the path serve different purposes. Even if a configuration uses the same domain for more than one field, don't assume those values are interchangeable across services. Don't enable options that aren't specified just because their names sound related.
SNI and the certificate domain: a server IP is not the TLS identity
SNI is the server name sent during the TLS handshake. It's commonly used to select a certificate and service when multiple domains share a server. Address specifies where to connect; SNI identifies the name requested for the TLS connection. They may be the same or different—use the values provided by your service provider.
- Address is a domain: If the address is the domain covered by the certificate and your provider hasn't specified a different SNI, follow its import or setup instructions. Don't assume a configuration needs no SNI just because the field can be left blank.
- Address is an IP: For example, if you connect to
192.0.2.10but the certificate coverstls.example.com, you usually need to set the specified TLS domain. Don't assume a certificate issued for a domain also covers its IP address. - There are multiple domains: The node's display name, the domain in the subscription URL, and the TLS domain are different things. The display name is just a label, and the subscription URL retrieves the configuration. Neither tells you what to use for SNI.
- Certificate verification fails: Check the domain spelling, certificate validity period, certificate chain, and device date and time. Correct SNI alone won't make an expired certificate or an untrusted certificate chain pass verification.
For SNI, enter only the hostname, such as tls.example.com. Don't enter a URL like https://tls.example.com:443/path. TLS certificate verification typically checks whether the certificate name matches the expected server identity. Changing SNI doesn't let you arbitrarily change the connection destination, and entering the website's domain won't fix the proxy server's certificate.
Allow Insecure: the difference between verifying and bypassing certificates
Allow Insecure relaxes server certificate verification. Even when the connection is still encrypted with TLS, skipping identity checks makes it harder to confirm that you're connected to the intended server. It won't fix a wrong password, open a port the server isn't listening on, or restore an expired subscription.
Allow Insecure off
RecommendedThe server certificate is verified. If the domain doesn't match, the certificate has expired, or there's a trust-chain issue, check the configuration and server certificate instead of bypassing the error.
Use for: everyday connections and Trojan configurations with valid certificates
Allow Insecure on
Relaxes certificate verification, reducing confidence in the server's identity. Consider it only for controlled troubleshooting when you understand the risks. A successful connection after enabling it does not mean the configuration is correct.
Use for: temporary certificate troubleshooting explicitly directed by the service maintainer; not for long-term use
Handle certificate errors at the right stage
If the certificate error persists after checking the device time and SNI, report the error type to your provider and confirm the server certificate status. Once the issue is resolved, test again with Allow Insecure turned off.
From setup to testing: change one setting at a time
The steps below cover manual setup. If you already have a subscription, get its URL from your provider and follow the import process. Don't delete the existing subscription just to test a setting. Subscription-managed entries may be overwritten on the next update, so confirm the provider's configuration before making a change you want to keep.
-
Check your settings
Prepare the address, port, Password, SNI, and any transport requirements. Note your current Global Routing mode. If Settings → On Demand is enabled, it may trigger reconnections during testing; don't mistake an automatic reconnect for an unsaved manual change.
-
Create an entry
Home → “+” → Add Server → Type → Trojan. Enter the address and port separately. Don't paste a full share link into Address or use a subscription URL as the server address.
-
Check the identity settings
Enter the original authentication string in Password, set SNI as specified, and leave Allow Insecure off. Add transport settings only if your provider specifies them. Save the entry, return to Home, and select it.
-
Run a test
Use Connectivity Test on Home to check basic connectivity, then connect and visit a destination that should use the proxy. A successful response doesn't verify every website, rule, or UDP request.
-
Check routing
To isolate rule-related issues, temporarily set Global Routing to Proxy and repeat the same request. After testing, restore your previous Config and other settings to avoid changing your normal routing behavior.
Change one field at a time and note what happens before and after. For example, if correcting SNI clears the certificate error but causes an authentication failure, you've reached a different troubleshooting stage. Check Password instead of randomly changing more TLS options. Don't share passwords, full share links, or subscription tokens in screenshots or reports.
Troubleshooting: check where the failure occurs
I entered the address and password. Why does it keep timing out?
Check the port and address first, and make sure the address doesn't include a protocol prefix or path. DNS resolution failures, network connectivity issues, or a closed server port can all cause timeouts; the connection may not have reached TLS or password authentication yet. Repeat the same test on a working network, then ask your provider to check the server status. Don't enable Allow Insecure as a first step.
I see a certificate error. Does that mean the password is wrong?
Start with the TLS stage: check the SNI spelling, device date and time, and server certificate status. Password is used later for Trojan authentication, so changing it usually won't fix a certificate name mismatch. Report the exact error text; it helps identify the cause better than repeatedly switching TLS options.
The connection is active. Why is my browser still connecting directly?
Check Home → Global Routing. Direct doesn't test the proxy route; Config applies the policies defined by the current configuration. Temporarily retry with Proxy. If that changes the result, check the active configuration and rule order in Config. Don't mistake a routing issue for a Trojan password error.
I fixed it manually yesterday. Why did it change after updating the subscription?
A subscription update may recreate the entries it manages. Check whether Address, Port, and SNI reverted to the values from the source, and ask your provider to confirm the subscription data. To compare settings, keep a separate manual test entry rather than repeatedly changing a subscription-managed entry to mask an issue with the source.
Don't confuse Global Routing options—Proxy, Direct, Config, and Scene—with protocol settings. They affect routing decisions, while Trojan parameters determine how the client connects to the server. Scene applies its configured behavior, so check which policy is active when troubleshooting. A connection icon alone doesn't prove that a particular website request used the selected Trojan entry.
Verify rules and protect your settings
After restoring Config, test the rules with a request you can identify. The snippet below shows only how matching works: requests for the example domain go to PROXY, and all others go to DIRECT. PROXY must resolve to a usable proxy policy in your configuration; copying rule text alone does not create a Trojan server.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTRules are checked in order. DOMAIN-SUFFIX matches a domain and its subdomains; FINAL is the fallback when no earlier rule matches. If your configuration already has matching rules above these, check those too—not just the two lines you added. For more syntax, see the Rules reference. Don't change SNI to alter website routing.
- Keep certificate verification enabled for everyday use, and restore your original Global Routing and On Demand settings after testing.
- Treat passwords, node share links, and subscription links as sensitive information. When reporting an issue, share only redacted field relationships, the exact error text, and the stage where it occurred.
- A share link typically contains a single connection configuration; a subscription link retrieves and updates a set of configurations. Get either from your service provider if you need it.
- If a new password is already in use, update or remove saved copies in old entries too. This prevents accidentally selecting one later and troubleshooting an authentication issue that's already been resolved.