When adding your existing Trojan settings in Shadowrocket Home, check the server address and port first, then verify Password, SNI, and certificate settings. This guide covers manual entry, checking imported settings, and troubleshooting handshake failures, assuming you already have a provider and configuration. Example domains explain the fields only; they are not working connection details.
Trojan connection sequence: establish TLS, then authenticate with Password
In Home → Add Server, set Type to Trojan and enter the remote server’s connection details. A standard Trojan connection first reaches the host specified by Address and the port specified by Port, then performs a TLS handshake before sending protocol authentication over the encrypted channel. A correct Password does not guarantee a valid certificate, and a valid certificate does not guarantee successful account authentication. Check each separately.
If your existing settings show 443, don't assume the service is available or change other ports to this value. TLS can run on other ports. Likewise, a successful TCP connection only suggests that the network path and listening service may be reachable; it doesn't confirm that the port is running a compatible Trojan service.
Add Server fields: what to enter for Address, Port, and Password
In Home, tap the add button in the upper-right corner to open Add Server. Set Type to Trojan, then enter each value from your existing settings. connect.example.com and tls.example.com below are reserved example domains. The table shows the required format, not a set of test server details. Depending on the interface language or form layout, SNI may appear under TLS options; identify it by its meaning.
| Field | What to enter | What to check |
|---|---|---|
Type | Trojan | Must match the remote server type. |
Address | The existing server's domain or IP address, such as connect.example.com | Do not include https://, a port, or a web path. |
Port | The number provided by your service provider, such as 443 | Enter it separately from Address, using standard digits. |
Password | The full password for this Trojan service | Password is case-sensitive. Check for leading or trailing spaces and line breaks copied with it. |
SNI | The TLS hostname specified in your existing settings, such as tls.example.com | Enter a hostname, not a URL, path, or port. |
Allow Insecure | Leave disabled for normal use | Don't bypass certificate verification instead of correcting the hostname, validity period, or certificate chain. |
After pasting the password into Password, compare it with the original details rather than judging by its length. A Trojan Password is neither your App Store purchase credential nor a UUID you generate yourself. If you only have your provider website login and no Trojan settings, obtain the correct connection configuration first; don't enter the website password here.
When Address is a domain, the device must resolve it before connecting. An IP address connects directly to that address, but doesn't bypass TLS hostname verification. If the service uses a domain certificate and Address is an IP, you generally still need to enter the correct SNI from your existing settings. An IP address is not a substitute for the certificate hostname.
SNI and certificate verification: the server address and verification name can differ
When you enter the hostname provided by your service provider in SNI, the TLS handshake includes that name so the remote server can select the corresponding certificate or service. Address specifies where to connect; SNI tells the TLS server which hostname you expect to reach. In a typical TLS setup, that hostname is also checked against the certificate identity. The two fields often match, but they don't have to.
Certificate verification enabled
RecommendedKeep Allow Insecure disabled, use the correct SNI, and let the system's trust mechanism verify the remote certificate. If the certificate is expired, has a hostname mismatch, or isn't trusted, correct your settings or the remote certificate.
Best for: everyday connections and validating a production configuration
Skip certificate verification
Enabling Allow Insecure relaxes certificate checks and weakens verification of the remote server's identity. It won't fix an incorrect password, port, or transport setting, and a successful connection doesn't prove the configuration is correct.
Use to understand the risks of an existing configuration, not as a routine fix
In short: correct SNI instead of bypassing verification
If the certificate hostname doesn't match, compare SNI with your existing settings and the domains covered by the certificate. If the name is correct but the connection still fails, check the device's date and time, the certificate's validity period, and the server's certificate chain.
If SNI is blank, don't assume that any server address will pass verification. The default name depends on the configuration. If your service specifies an SNI, keep that value. If the certificate covers only tls.example.com, changing SNI to another website's domain won't give the certificate that identity.
- When checking a certificate hostname, distinguish the full domain from the wildcard's coverage. A wildcard doesn't cover subdomains at every depth.
- When checking the device's time, make sure the system date and time zone are correct. An incorrect time can cause certificate validity checks to fail.
- When checking the certificate chain, the remote server must provide the correct intermediate certificates. Re-entering Password on your device can't complete the server's certificate chain.
Add and verify manually: save, then confirm the selected server
After adding a server in Home, save it, then select the new entry to verify it. Change one suspect field at a time and note the result; changing Password, SNI, and Port together makes it hard to tell what fixed the issue. On the first connection, follow the system prompt to allow the VPN configuration, then return to Shadowrocket and check the connection status.
-
Choose a type
Go to Home → add button in the upper-right corner → Add Server → Type, then choose Trojan. Confirm the protocol in your existing settings first; don't use another protocol's parameters in this form.
-
Enter connection details
Enter the existing hostname in Address, the server port in Port, and the full password in Password. Remove the URL scheme from the address and enter the port separately.
-
Check TLS
Enter the existing value in SNI or the corresponding TLS hostname field, and leave Allow Insecure disabled. If your settings include transport parameters, check those as well.
-
Save and select
After saving, return to Home and select the Trojan entry, then check Global Routing. For troubleshooting, you can temporarily choose Proxy to reduce the effect of rules on the test path.
-
Restore settings after verification
Make a normal connection request and check the connection log for the actual destination, selected server, and point of failure. After testing, restore your original Global Routing mode and automatic connection settings.
With Config selected in Global Routing, requests are matched against the current configuration's rules. Rules such as DOMAIN-SUFFIX, GEOIP, IP-CIDR, or FINAL may route traffic through different policies; a page loading doesn't mean it used the Trojan entry you just added. Direct bypasses the proxy, so a successful Direct connection doesn't prove that entry works. Check Scene against your actual setup; don't assume it's equivalent to Proxy.
Troubleshoot handshake failures: narrow it down from network to TLS to authentication
When an error appears in the connection log, first identify whether it occurred during DNS resolution, connection, or TLS, then adjust the relevant field. The table lists common symptoms, but a given message can have more than one cause; wording may vary with the system and remote server response. Don't assume a wrong Password based only on latency or a single timeout.
| Observed symptom | Check first | What to do next |
|---|---|---|
| DNS resolution failed; no connection to the remote server yet | Address spelling and DNS on the current network | First confirm that the hostname resolves. Don't change Password or disable certificate verification. |
| Connection timed out or was refused | Address, Port, remote server listener, and network path | Check the port against your existing settings. Compare using another available network, and avoid changing TLS fields repeatedly. |
| Certificate hostname mismatch | SNI and the hostname covered by the certificate | Restore the hostname specified by your service. Make sure it has no URL scheme, path, or extra spaces. |
| Certificate expired or not trusted | Device time, certificate validity period, and certificate chain | Check the system time and report the certificate issue to your service provider. Keep verification enabled. |
| Connection closes immediately after TLS, or authentication fails | Password, Type, service status, and transport settings | Check the original settings again. A closed connection by itself doesn't prove the password is wrong. |
| Connection succeeds, but the selected website won't load | Selected server, rule policy, destination DNS, and remote access | Check the request's actual route first, then distinguish a rules issue from a destination website issue. |
When reporting an issue, provide the failure stage, network type, and differences in fields with sensitive details removed. Passwords and tokens in full share links or subscription URLs are sensitive; don't share them publicly, including in screenshots. When contacting your service provider, describe the specific certificate error or connection interruption rather than just saying it doesn't work.
After importing an existing configuration: check for overrides and update sources
After importing a Trojan configuration in Home via an existing share link, QR code, or subscription, open the entry's edit screen and verify Type, Address, Port, SNI, and Allow Insecure. Importing can reduce manual entry errors, but doesn't prove that the remote settings are still valid or that the link includes all required transport settings.
- Identify the link type first:
trojan://is a common share scheme for a single configuration; it isn't a subscription URL. A subscription usually returns a list of entries. Don't enter a subscription URL in Address. - Keep a record of the original settings: Before making manual changes, note the non-sensitive fields in the original configuration and confirm whether you're editing a local entry or one managed by a subscription.
- Check again after updates: Refreshing a subscription may recreate entries or overwrite local changes. If the problem returns after a refresh, check the contents of your own subscription source instead of repeatedly changing the same field.
- Manage each area separately: Use Home to select and connect to servers, Config to manage configuration files and rules, and Settings for app preferences. Don't try to fix a Trojan authentication issue by arbitrarily deleting routing rules.
To investigate whether the issue is with routing or the connection, read the connection troubleshooting guide and the rules and policies guide. First verify that the connection settings for a single entry are correct, then test the destination request against your regular Config rules. This helps keep server settings, DNS, and policy selection from becoming one confusing issue.