This guide is for users who already have configuration details they are authorized to use and want to add a Trojan connection in Shadowrocket. First, distinguish the server address, authentication password, and TLS certificate name. Then follow Home → + in the top-right corner → Type → Trojan. Use the checklist to verify each setting, and use connection errors to determine whether to check the network, certificate, or password—instead of repeatedly toggling Allow Insecure.
How Trojan works: the roles of TLS and the password
Shadowrocket is a paid client for Apple platforms. This guide covers entering and verifying an existing configuration; it does not provide, sell, or recommend servers, subscriptions, or connection services. Purchasing the app is separate from obtaining a connection service and does not automatically provide a usable server address or password.
A typical Trojan connection first establishes an encrypted channel with TLS, then sends authentication information and proxy requests through that channel. TLS protects data in transit and checks the server's identity against its certificate. The Trojan password lets the server identify users authorized to use the connection. These steps are separate: a correct password does not mean the certificate can be ignored, and a valid certificate does not guarantee the password is correct.
In short: check TLS first, then the password
For certificate or TLS handshake errors, first check Address, SNI, the device's date and time, and certificate validity. Verify the Trojan password only after TLS connects successfully. Do not disable certificate verification as a substitute for checking the settings.
Trojan does not mean that entering any domain name is enough to connect. The server may use a different port or require a specific transport. If your existing configuration also specifies WebSocket, Host, or Path, keep those settings intact. Do not replace them with values from another connection just because both use Type Trojan.
Parameter reference: Address, Port, Password, and SNI
Before you start, get a complete set of matching parameters. Do not combine the address from one connection, the password from another, and the SNI from a third configuration. The domain names and ports in the table below illustrate field formats only; they are not connection details.
| Field | What to enter | What to check |
|---|---|---|
| Type | Trojan | Choose the protocol specified by the server. Do not use field requirements from another protocol. |
| Address | The domain name or IP address in your existing configuration | Enter only the hostname, such as gateway.example.com. Do not include https:// or a webpage path. |
| Port | The port the server is actually listening on | 443 is common, but if your configuration specifies 8443, keep 8443. |
| Password | The password for this Trojan connection | Passwords are case-sensitive. Check for leading or trailing spaces and line breaks. Do not enter your App Store account password. |
| SNI | The TLS server name specified in your existing configuration | For example, tls.example.com, without a scheme, port, or path. |
| Allow Insecure | Usually leave this off | This setting affects certificate verification; it is not a general fix for connection failures. |
Address specifies where to connect, and Port specifies which listening endpoint on that host to use. Password is the credential provided by the server; it does not have to follow a UUID format. After copying the password, you can check its length and first and last characters, but do not post the complete password in a public support request.
Add a connection: save a Trojan entry from Home
The steps below show how to enter a connection manually. If you already have an entry imported from a subscription, check its original parameters first rather than creating a duplicate. Managing a subscription and editing an individual connection are different tasks; a later subscription update may recreate an entry and overwrite local changes.
-
Get the parameters ready
Gather the address, port, password, SNI, and transport requirements from your existing configuration. Confirm they all belong to the same Trojan connection before entering them.
-
Choose the protocol
Go to Home → + in the top-right corner → Type → Trojan. Select the Type before entering its fields to avoid leaving values from the wrong protocol.
-
Enter connection details
Enter Address, Port, and Password in that order. Put only the host in the address field and only numbers in the port field. Copy the password as provided; do not encode it or add quotation marks.
-
Check TLS settings
Check SNI and Allow Insecure in the TLS settings. Use the SNI specified in your existing configuration. Keep certificate verification enabled in most cases, and check any additional transport fields.
-
Save and test
After saving, return to Home, select the entry you just added, and start the connection. The first time, follow the system prompt to allow adding a VPN configuration. Test with a normal webpage request; the connection toggle alone does not confirm connectivity.
Before testing, also check Home → Global Routing. Temporarily selecting Proxy can help rule out interference from rules in Config. Direct does not test proxy traffic through the selected Trojan connection. Config routes requests according to the active configuration's rules, while Scene requires checking the selected scene's settings. After testing, restore your usual setup so troubleshooting changes are not left in place.
SNI and certificates: a different connection address is not necessarily an error
SNI is the server name sent during the TLS handshake. The server can use it to select a certificate or virtual host. In a typical configuration, SNI matches a domain covered by the certificate. Address and SNI are often the same, but serve different purposes; do not change them to match just because they differ.
For example, an existing configuration may specify an IP address for Address and the certificate's domain name for SNI. The client then connects to the IP address and sends the specified name during the TLS handshake. Conversely, entering an arbitrary domain unrelated to the server's certificate will not make certificate verification succeed.
- Name match: Check that SNI is spelled correctly and covered by the certificate's valid names. Do not enter a full webpage URL here.
- Validity period: An expired certificate, one that is not yet valid, or an incorrect device date can cause verification to fail. Check the device's system time first.
- Trust chain: A correct name does not guarantee that the certificate chain is complete. The configuration maintainer should investigate an invalid server certificate chain; changing the password will not fix it.
- Empty values: If no SNI is provided, check the instructions for the original configuration. Do not guess another domain or assume that leaving this field blank works for every connection.
If the same configuration specifies both a WebSocket Host and a TLS SNI, check them separately. Host is related to the HTTP request; SNI is part of the TLS handshake. They may have the same value, but they are different fields. Do not overwrite both just to make them look consistent.
Allow Insecure: don't bypass verification to hide a problem
Allow Insecure generally permits TLS connections that do not meet normal certificate verification requirements. Even if traffic remains encrypted when this setting is enabled, that does not mean the server's identity has been reliably verified. Encryption and identity verification are separate requirements; skipping the latter weakens protection against man-in-the-middle attacks.
For certificate errors, first check SNI, the device's date and time, the certificate's validity period, and the trust chain. If the configuration instructions explicitly require a special certificate, confirm the certificate setup with the configuration maintainer. Do not assume the configuration is correct just because enabling Allow Insecure lets it connect.
Change only one field at a time while troubleshooting, and note its original value. If you change SNI, Port, Password, and Allow Insecure all at once, you will not know which change fixed the problem. In particular, do not copy settings from one problematic connection to every Trojan entry.
- Port unreachable: check Address, Port, and connectivity on the current network. The certificate setting cannot make a port that is not listening start working.
- Password mismatch: check Password against the original configuration. Relaxing TLS verification does not change the server's authentication result.
- Certificate mismatch: check the name, date and time, and certificate chain. Keep the error details for the configuration maintainer to investigate.
Troubleshoot connection failures: narrow down the problem by layer
A connected status on Home only means that the local connection process has started. It does not by itself confirm successful authentication with the remote Trojan server or prove that the current webpage is using this connection. First confirm that the correct entry is selected, then check the error details and test an actual request. The table below suggests where to look; it is not the only possible explanation for every error.
| What you see | Check first | What to do next |
|---|---|---|
| Connection timed out | Address resolution, port, network route, and server status | Check Address and Port again. Repeat the same request on another available network and compare the results. |
| Certificate or TLS error | SNI, device date and time, and certificate chain | Keep the original error message, check the server name, and ask the configuration maintainer to verify the server certificate. |
| Disconnects immediately after the handshake | Password, server authentication, and transport settings | Copy the password again, then check the transport, Host, Path, and other parameters in your existing configuration. |
| Only some websites fail | Global Routing, rule matches, and DNS | Temporarily test with Proxy for comparison, then return to Config and check which rule actually matches. |
With Config selected, a domain rule such as DOMAIN-SUFFIX may route a website through DIRECT. It may also match IP-CIDR, GEOIP, or the FINAL policy at the end. So if a website still connects directly, that does not necessarily mean the Trojan settings are wrong. Check the policy being applied before changing connection parameters; troubleshoot rules and protocol settings separately.
When sharing troubleshooting details, include your current network, selected Global Routing mode, error message, and the fields you changed. Hide Password, tokens in subscription links, and other personal connection credentials. Check for sensitive details before sharing screenshots or copied logs, too.
FAQ: what to check after saving the settings
Does the port have to be 443?
No. Open the entry's edit screen on Home and check Port against your existing configuration. If the server listens on 8443, enter 8443; changing it to a commonly used port does not change the server's listening settings.
Can I use Address as the SNI?
Only if your existing configuration and the certificate name allow it. If Address is an IP address or a domain that differs from the certificate name, use the SNI specified in the configuration rather than copying Address automatically.
If the connection works after enabling Allow Insecure, can I leave it on?
Turn verification back on first, then check SNI, the system time, and the certificate chain. This behavior points to a certificate verification issue that needs investigation; it does not prove the server's identity is trustworthy. Ask the configuration maintainer to confirm and resolve the cause.
Why did my manual changes revert after a subscription update?
A subscription update may recreate entries based on remote content. Check the original parameters in your own subscription and its maintenance instructions. If the remote content is wrong, have the configuration source corrected rather than repeatedly changing local fields.
How can I tell whether a connection that starts automatically after a network change is a problem?
Check whether Settings → On Demand is enabled and review its conditions to see if they triggered the connection. On Demand controls when a connection starts; it does not fix an incorrect Trojan password or SNI. Verify automatic startup and successful remote connectivity separately.