This guide is for users who already have connection details or a subscription from their own provider. It explains how a Trojan server address, authentication password, and TLS name map to the fields in Shadowrocket. First, distinguish network connectivity, certificate verification, and protocol authentication. Then fill in Add Server and use timeouts, certificate errors, or authentication failures to narrow down the cause. Don’t rely on disabling certificate verification as a shortcut.
The three checks in a Trojan connection
In Shadowrocket, Trojan is a connection protocol, not a subscription URL type. A typical Trojan connection first establishes a TCP connection to the server, completes a TLS handshake, then authenticates with Trojan and sends requests through the encrypted channel. TLS provides encryption commonly associated with HTTPS, but that doesn’t make traffic impossible to identify or mean destination websites will trust the proxy server.
Each of the three checks addresses a different issue: the address and port determine whether the service can be reached; TLS verification checks the server’s identity; and the Trojan password determines whether you’re authorized to use the service. A correct password can’t compensate for a certificate name mismatch, and a valid certificate doesn’t prove the password is correct. Troubleshoot in connection order, changing one field at a time.
This guide covers common Trojan over TLS settings. If your configuration also uses a transport such as WebSocket, check the transport type, Host, and path as well; don’t copy only the address, port, and password. Fields for Trojan and other protocols aren’t interchangeable. In particular, a long string in your connection details isn’t necessarily a user ID for another protocol.
How Add Server fields map to your connection details
Before adding a server manually, find the server address, port, Trojan password, and TLS service name in your own connection details. The domain and address below are examples for explaining the fields, not working services. For this example, the connection address is 192.0.2.10, the port is 443, and the TLS service name is gateway.example.com. Replace these with your own complete settings.
| Field | What to enter | Common mistake |
|---|---|---|
| Type | Select Trojan | Selecting a different protocol, which uses a different authentication method |
| Address | The server’s domain name or IP address from your connection details | Pasting the entire subscription URL, or including https:// and a path |
| Port | The port the server actually listens on, such as 443 | Changing the port to 443 just because TLS is involved |
| Password | The Trojan connection password provided by your service provider | Using your account login password, or including spaces or line breaks when copying |
| SNI | The TLS service name specified in your connection details | Entering a URL with a protocol prefix, an IP address, or an unrelated website domain |
| Allow Insecure | Leave off for normal use to retain certificate verification | Treating certificate verification bypass as a way to fix connection problems |
Password is used for protocol authentication. Enter it exactly as provided, preserving capitalization; don’t hash or encode it yourself. Passwords in imported links may be URL-encoded, so let the app parse the original link when possible. When copying settings manually from a webpage, check for invisible characters. You can change the remark, but it isn’t an authentication field and won’t change the identity of the remote service.
In short: verify where the port came from
Keep the port from your existing settings. Enter 443 only if your settings explicitly specify it. If the connection times out, check Address and Port first—not Password, and don’t disable certificate verification.
How SNI relates to the certificate name
SNI is an extension in the TLS ClientHello that tells the server which service name the client is requesting. A single IP address can host multiple TLS services, and the server may use SNI to select a certificate and backend. So Address can be the IP used to connect, while SNI remains the domain specified in your settings. There’s no contradiction: one tells the client “where to connect,” the other “which TLS service to request.”
Certificate verification also checks the trust chain, validity period, and whether the certificate covers the expected service name. For example, if the service name is gateway.example.com, don’t change SNI to www.example.com just because the server is reachable. A name mismatch can cause the connection to fail before Trojan authentication, even with the correct password.
- Address is a domain: Confirm that it resolves to the expected server. If your settings specify a separate SNI, use that value.
- Address is an IP: Check whether your settings provide a separate SNI. A certificate for a regular domain usually won’t cover a direct connection to an IP address.
- SNI is blank: Don’t guess what the app will use by default. Check the original subscription or service settings to see whether SNI must be set explicitly.
- Device time is incorrect: Check Settings → General → Date & Time on your device. An incorrect time can affect certificate validity checks.
SNI is neither a password nor an authorization mechanism. In a typical TLS handshake, SNI isn’t confidential, so don’t put sensitive tokens in it. A successful TLS connection after changing SNI doesn’t prove the configuration works; Trojan authentication and actual requests still need to be checked.
Allow Insecure: certificate verification
Allow Insecure controls whether normal server certificate verification can be skipped. Even if the connection remains encrypted with TLS, enabling this setting means the client can’t reliably confirm that the server is the one you intended to reach. Encryption and identity verification are separate. Don’t use this setting to conceal an invalid, replaced, or untrusted certificate.
Allow Insecure off
RecommendedKeep normal certificate verification enabled. If you get a certificate error, check SNI, device time, certificate validity, and the server’s certificate chain; fix the underlying cause.
Best for: everyday connections and saved configurations
Allow Insecure on
Relaxes server certificate verification and removes the corresponding identity check. It won’t fix an incorrect port, password, or transport setting.
Best for: brief, controlled diagnostics when you understand the risk—not for long-term use
If the connection works only with this setting enabled, record it as a certificate verification issue—not as a fix. Turn verification back on and ask your service provider to check the certificate error. Don’t perform sensitive activities over a connection whose identity you can’t verify, and don’t leave verification disabled as a general troubleshooting measure.
From adding settings to testing a request
If your subscription already created a Trojan entry, check it against the original settings instead of adding another one. Subscription entries may be regenerated during updates, and whether manual changes are preserved depends on how the entry was created. Note any changes before troubleshooting so you don’t mistake a local edit for a fix on the remote service.
-
Add an entry
Go to Home → tap “+” in the upper-right corner → Add Server, then select Trojan under Type. To check an existing entry, open its edit screen instead of creating a duplicate with the same name.
-
Enter the settings
Check Address, Port, Password, and SNI in order. Leave Allow Insecure off. Enter any additional transport settings only if they’re in your existing connection details, then save.
-
Select the server
Go back to Home and select the Trojan entry you just saved. Note your original Global Routing setting, then temporarily select Proxy to reduce interference from rule-based routing during the test.
-
Send a request
Turn on the connection switch and approve the VPN configuration when prompted the first time. Make a new request to a test page you know you can access, then check the result and the app logs. A latency reading alone doesn’t prove that a request completed successfully.
-
Restore routing
After testing, restore your original Global Routing setting. If the connection works with Proxy but fails with Config, check the active Config’s rule matching and policy targets instead of continuing to change the Trojan password.
Proxy in Global Routing is a routing mode; PROXY in a rule is a policy keyword. They aren’t the same field. Temporarily switching to Proxy can help isolate rule-related issues, but it doesn’t replace certificate or authentication checks. There’s no need to change Settings → On Demand during this test: on-demand connection conditions and the settings for an individual Trojan entry are separate troubleshooting areas.
Troubleshoot handshake failures in order
First identify which layer failed, then change just one variable at a time. Log messages vary by system and error source, so use the symptoms below as a guide rather than treating any single message as a definitive diagnosis. When reporting an issue, include the error type, time, network type, and fields you’ve checked. Omit your Password and full subscription URL.
- Domain won’t resolve: Check Address for typos or an extra path, then check DNS resolution on your current network. If the address itself won’t resolve, changing the Trojan password won’t help.
- Connection times out or is refused: Check Address and Port, and confirm that the service is listening on that port. A timeout may point to a network path issue, while a refusal may mean the port isn’t open; neither symptom alone identifies exactly where the problem lies.
- TLS or certificate error: Check SNI, device time, the certificate name, and its validity period. Ask your service provider to check the certificate chain and the corresponding TLS service, and keep certificate verification enabled.
- Connection drops immediately after TLS: Recheck Type, Password, and transport settings. A disconnect after the handshake doesn’t necessarily mean the password is wrong; check the server logs too.
- Some requests fail after connecting: Check Global Routing and the active Config to confirm that requests are going through the selected entry. Then distinguish between a destination site issue, a DNS problem, and a rule-related issue.
I copied the password correctly. Why won’t it connect?
First confirm you copied the Trojan Password, not your account login password. Open the entry’s edit screen in Home and check for leading or trailing spaces, line breaks, and capitalization. Then check the port and SNI; there’s no need to keep changing a password that’s already correct.
If Address is an IP, should SNI also be an IP?
Not necessarily. If your settings specify a domain as the TLS service name, use that domain for SNI and keep the connection IP in Address. Don’t substitute an example domain for your own settings or pick a random website domain that happens to load.
It connects when I turn on Allow Insecure. Can I leave it on?
Don’t treat that as a long-term fix. Turn it back off, check SNI and your device time, and ask your service provider to check the certificate’s validity and chain. This behavior points to a verification issue; it doesn’t prove the service’s identity is trustworthy.
The connection stopped working after a subscription update. What should I change?
Compare Address, Port, SNI, and transport settings before and after the update, and confirm which entry is selected in Home. If the update overwrote a local change, check the original subscription settings to verify their source. Don’t post your password or full subscription token in a public help request.
Finally, distinguish getting the app from getting a connection service. Shadowrocket is a closed-source commercial app, available as a one-time purchase through the App Store, and is primarily used on iPhone and iPad. Check the App Store listing for system requirements. Buying the app doesn’t include a connection plan. This guide explains how to use settings you already have; it doesn’t provide, sell, or recommend connection services or subscriptions.