When adding a Trojan server, Address specifies where to connect, Port specifies which port to use, Password authenticates the connection, and SNI provides the server name for the TLS handshake. Enter each value from your existing configuration, and leave Allow Insecure off in most cases. This guide is for users entering a server manually or troubleshooting a failed connection after importing one. It explains how to distinguish network reachability, certificate validation, and password issues—without masking configuration problems by skipping certificate checks.
Trojan and TLS: Separate Connectivity, Certificates, and Authentication
Trojan carries proxy protocol data over TLS. The client typically connects to the server specified by Address and Port, completes the TLS handshake, then performs Trojan authentication and forwards requests through the encrypted channel. TLS encrypts the connection and verifies the server's identity; Password authenticates access to Trojan. These settings serve different purposes and are not interchangeable.
A correct Password does not guarantee a valid certificate, and reaching a port does not mean Trojan authentication succeeded. Both ordinary HTTPS sites and Trojan servers may use port 443, but you cannot use an arbitrary HTTPS address as a Trojan server in Add Server.
- Connection: Check that Address resolves and the specified TCP port is reachable. If the connection times out, start here.
- TLS: Check the certificate's validity period, trust chain, and hostname. An incorrect SNI may cause the server to present a certificate for a different name.
- Authentication: Check that Password exactly matches the server configuration. Authentication can fail even after a successful TLS handshake.
- Forwarding: After connecting, check Global Routing, rules, and whether the destination site resolves and is reachable.
Add Server Fields: Address, Port, Password, and SNI
Get the complete parameters for your existing service before opening the edit screen. The domain and port below are examples to illustrate the fields, not usable connection details. Enter the values from your original configuration. Don't change your port to 443 just because the example uses it.
| Field | What to enter | Common mistake |
|---|---|---|
| Type | Select Trojan to match the server protocol. | Choosing another protocol just because the port is the same. |
| Address | The server's domain name or IP address, for example edge.example.com. | Pasting a full URL with https://, a path, or a port. |
| Port | The port the server listens on, for example 443. Valid values are 1–65535. | Leaving it blank, guessing, or repeating the port in Address. |
| Password | The Trojan password from the original configuration; preserve every character and its case. | Entering an account login password or copying extra spaces or line breaks. |
| SNI | The TLS server name specified in the original configuration, for example tls.example.com. | Entering a URL, an IP address with a port, or an unrelated website domain. |
| Allow Insecure | Usually leave it off to keep standard certificate validation enabled. | Turning it on for every error and masking certificate problems. |
Why Address and SNI Can Differ
Address is the network destination; SNI is the server name sent in the TLS ClientHello. The server can use it to select a certificate or virtual host. The two values may match, or the configuration may specify different values. For example, the connection may go to an IP address while TLS uses a domain covered by the certificate. In that case, keep the configured name—don't replace SNI with the IP address.
SNI is related to certificate validation, but sending an SNI value does not mean the certificate has passed validation. The certificate must still be within its validity period, chain to a trusted authority, and match the expected name. Don't rely on a default inferred from a blank SNI to compensate for missing parameters. If Address is an IP or differs from the certificate name, confirm the required TLS name in your original configuration.
- Enter a hostname for SNI—not
https://tls.example.com/ortls.example.com:443. - The certificate name must match a name covered by its Subject Alternative Name entries. A wildcard certificate does not necessarily cover domains at every level.
- If the original configuration also specifies transport, Host, Path, or other fields, keep them as provided. SNI cannot replace those fields.
Manual Setup: Save the Parameters, Then Test a Real Request
These steps cover adding a single Trojan server manually. If the server came from an existing subscription, first check its original parameters to avoid changing the entry to values that differ from the source. A later subscription update may overwrite the entry, so note the issue and correct the source parameters rather than relying on a temporary local edit.
-
Open Add Server
Go to Home → tap “+” in the upper-right corner to open Add Server. Confirm that you're creating a new entry so you don't accidentally edit another working configuration.
-
Choose the Protocol
Go to Type → Trojan. Use the protocol specified in the original configuration; choosing the wrong Type can cause a connection failure even when Address and Port are correct.
-
Enter the Connection Parameters
Return to Add Server and enter Address, Port, and Password. Enter only the host in Address. Copy Password exactly as provided, without adding quotation marks or converting it to a hash.
-
Check the Security Settings
Check SNI and Allow Insecure in the entry's TLS settings. Use the name specified in the original configuration for SNI, and leave Allow Insecure off. Check any other transport fields against the original configuration as well.
-
Save and Test
After saving, return to Home and select the new entry. To isolate routing rules during troubleshooting, temporarily set Global Routing to Proxy, turn on the connection, and allow the VPN configuration when prompted by the system. Visit a known-working HTTPS page, then restore your original routing mode.
Allow Insecure: What Certificate Validation Changes
Allow Insecure relaxes or skips standard TLS certificate validation; it does not switch the connection to unencrypted transport. However, an encrypted connection that cannot reliably verify the server's identity could still connect to an impostor. This setting cannot fix an incorrect password, a closed port, a DNS resolution failure, or a protocol mismatch on the server.
Allow Insecure Off
RecommendedStandard certificate validation remains enabled. If the certificate name doesn't match, the certificate has expired, or the trust chain is invalid, the connection should fail—surfacing an identity verification problem that needs to be fixed.
Best for: everyday use, production configurations, and routine troubleshooting.
Allow Insecure On
With certificate validation relaxed, a request may proceed, but that does not prove the server's identity is trustworthy. Don't use this setting as a permanent fix for an expired certificate or incorrect SNI.
Use for: identifying configuration differences when you understand the certificate risks—not as a day-to-day setting.
Bottom Line: Fix Certificate Problems; Don't Leave Validation Bypassed
If the same parameters connect only when Allow Insecure is on, turn it off again and check SNI, the device's date and time, and the server's certificate chain. If you can't resolve the issue, report the error type to the provider of your existing service.
First, confirm the date and time in your device's system settings. Then check whether the certificate has expired, covers the expected domain name, and is served with the complete intermediate certificate chain. Self-signed certificates require separate trust management; permanently skipping validation is not a substitute for a trustworthy configuration.
Troubleshooting by Symptom: Timeouts, Certificate Errors, and Authentication Failures
Interpret connection errors in the context of the stage where they occur. Different networks and servers can produce similar timeouts or disconnects. Use the steps below as a troubleshooting sequence, not as a way to diagnose the cause from a single message. You can include the error type when reporting the issue, but hide Password, subscription tokens, and full connection details.
It Keeps Timing Out. Is Password Wrong?
Go to Home → edit the relevant entry and check Address and Port. Then confirm that your current network can reach that address and port. A timeout can occur while connecting or during the handshake; it doesn't prove the password is wrong. Running the same test on another network you can use may help determine whether the issue is specific to your current network.
There's a Certificate Error. Which Domain Should I Use for SNI?
Enter the TLS name specified in your existing configuration, not the domain of the website you're trying to visit in your browser. Check that SNI doesn't include a protocol prefix, port, or spaces, and verify the device's date and time. If the name is correct and the error persists, check the server certificate's validity period and chain instead of turning on Allow Insecure.
It Disconnects Right After Connecting. Should I Generate a New Password?
Check Password character by character and confirm Type. Make sure copying didn't add a line break and that no transport settings from the original configuration are missing. Don't generate a new password yourself—the server won't update to match it. A quick disconnect after TLS is established can have other causes; check the server logs to investigate further.
The Test Shows a Result, but Websites Won't Load. What Should I Do?
On Home, confirm that the intended entry is selected. Temporarily set Global Routing to Proxy and try the same page again. If Proxy works but Config doesn't, check the active rules and policy targets in Config. If both modes fail, check authentication, DNS, and the destination site. A latency reading alone doesn't prove the server is working correctly.
After Testing: Restore Config and Check Rules and Updates
Use Global Routing → Proxy to isolate rule-related issues during this test; it doesn't mean you should use that mode permanently. Direct connects without a proxy and cannot test Trojan forwarding. Config processes requests according to its current rules, while Scene selects routing behavior based on the configured scene. For everyday use, restore your original working mode.
If Proxy works but Config produces unexpected results, check the rule order and policy in the active Config. For example, the syntax below sends example.com and its subdomains to PROXY, and all other requests to DIRECT. This illustrates what the rules mean; it is not a recommendation to overwrite your existing configuration. Policy targets in your actual configuration must be valid.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT- Check rule order: Earlier matching rules may handle a request first, so a later DOMAIN-SUFFIX rule may never match. Don't judge routing based on a search for just one line.
- Keep the source parameters: After a subscription entry updates, check whether Address, Port, SNI, or transport settings have changed. A one-time manual fix does not mean the source is permanently corrected.
- Check automatic connections: If the connection comes back after you disconnect manually, check the enabled conditions under Settings → On Demand. An automatic reconnect can make it look as though your edits didn't take effect.
- Protect authentication details: When reporting an issue to your service provider, describe the error stage, network type, and whether the issue occurs only in Config. Don't send screenshots showing an unredacted Password or subscription link.