adminIntroduction: The Philosophy of Disguise
The Trojan Protocol emerged as a direct and elegant response to the rising complexity and inevitable detection of earlier proxy protocols like Shadowsocks and the increasing overhead of VMess. Its core philosophy is one of radical simplicity and perfect imitation: traffic should look indistinguishable from the most common, trusted, and unblockable traffic on the internet—HTTPS.
Trojan operates on a stealth principle far simpler than its VLESS and VMess counterparts, which rely on custom authentication protocols layered inside the TLS handshake. Trojan bypasses this complexity by relying on the strength of raw, standard web infrastructure. It is designed to be a lightweight multiplexing transport over raw TCP, secured by a standard TLS (Transport Layer Security) connection on Port 443. The only unique identifiers for Trojan are a shared password and the subsequent data flow. The name “Trojan” reflects its ability to sneak past network defenses by disguising itself as legitimate web traffic.
Section 1: Core Mechanism: Password + Standard TLS
The success of the Trojan protocol relies entirely on two foundational principles: minimal authentication and absolute reliance on standard web infrastructure.
1. The Simple Authentication Model
Trojan eliminates the need for complex UUIDs or continuous time synchronization (required by VMess). Instead, it uses a simple password or hash that serves as the user ID. This credential is sent during the connection handshake immediately after the standard TLS layer is established. The authentication payload is minimal, reducing overhead compared to older, more verbose protocols.
- Authentication Flow (The Two-Part Handshake):
- Standard TLS Handshake: The client connects to the Server IP on Port 443. A standard, legitimate TLS Handshake occurs, and the server presents a valid domain certificate. To the outside world, this is just another secure website connection.
- Trojan Authentication: Immediately after the TLS layer is fully established, the client sends the shared password/hash. The server verifies this password.
- Proxying: If verified, the server begins proxying the raw data stream.
If the password is incorrect or the connection is a random probe, the server immediately drops the connection, often by sending a fake 400 Bad Request HTTP message. This response looks exactly like a benign error from a regular web server failing to process an unrecognized HTTP request, which confuses censorship firewalls and prevents them from learning that a proxy service is operating on that port.
2. Mandatory TLS and Port 443
For Trojan to achieve its goal of perfect camouflage, two requirements are non-negotiable:
- It must run on Port 443 (the default HTTPS port).
- It must present a valid, unexpired, and trusted TLS certificate for a domain name.
If the certificate is self-signed, invalid, or expired, or if it runs on a non-standard port, it instantly loses all camouflage benefits and is easily flagged by state-level filtering systems. This perfect reliance on legitimate TLS infrastructure is the source of Trojan’s resilience and stealth.
Section 2: Configuration and Simplicity
The Trojan configuration in V2Ray is perhaps the cleanest among all protocols, as it delegates all cryptographic complexity to the TLS layer handled by the operating system.
Key Configuration Parameters
| Setting | Type | Description | Importance |
|---|---|---|---|
passwords | array | A list of shared passwords (user IDs) that clients can use to authenticate. | Must be long, random, and unique. |
dest | string | The default destination address, often set to 80 or 443 to complete the HTTPS illusion. | This defines where unauthorized traffic is harmlessly forwarded. |
V2Ray Trojan Inbound Example
V2Ray supports the Trojan protocol natively, allowing it to function as a highly stealthy entry point. This example uses raw TCP/TLS, which is the default, high-speed configuration.
"inbounds": [
{
"port": 443,
"protocol": "trojan",
"settings": {
"clients": [
{ "password": "MyTrojanSecretKey_2025" } // The authentication key for this client
],
"fallbacks": [] // Crucial for defeating probes (see Section 3)
},
"streamSettings": {
"network": "tcp", // Raw TCP transport
"security": "tls",
"tlsSettings": {
// Must use a certificate matching the client's domain (SNI)
"certificates": [
{ "certificateFile": "/path/to/fullchain.cer", "keyFile": "/path/to/private.key" }
]
}
},
"tag": "trojan_in"
}
]
Section 3: Fallbacks and Defeating Misdirection
A defining and unique feature of V2Ray’s Trojan implementation is the seamless integration of Fallbacks. This mechanism solves the critical vulnerability of any masquerading server: what happens when a legitimate, non-Trojan user or, more importantly, an Active Probe attempts to load a regular webpage from your server’s IP address on Port 443?
- The Vulnerability: Without a fallback, if a regular user or a censor tries to load a webpage from your Trojan IP, the V2Ray core will drop the connection after authentication fails, which looks suspicious to the censor.
- The Fallback Solution: The
fallbacksarray tells V2Ray, “If the incoming traffic fails to authenticate as Trojan, check the SNI and redirect that traffic to a real web service instead of dropping it.”
Example Fallback: Redirect all failed or suspicious Port 443 traffic to the local Nginx web server running a decoy blog on Port 8080.
"fallbacks": [
{
"dest": 8080, // Redirect failed connection attempts to Nginx running on localhost:8080
"xver": 1
}
]
With the fallback in place, the V2Ray server is guaranteed to always respond like a real, functioning web server to external probes, while only users with the correct password can initiate the hidden proxy session. This is a robust defense against active probing and fingerprinting.
Section 4: Limitations and the Modern Landscape
While Trojan’s stealth on raw TCP/TLS is superb, its original design has three main limitations in the modern era:
- Direct IP Exposure: Trojan typically relies on raw TCP and cannot be easily routed through standard CDNs (like Cloudflare) because most CDNs require HTTP-based transports (like WebSocket or gRPC). Your VPS IP address is directly exposed, relying entirely on the perfect HTTPS masquerade to prevent blocking.
- HOLB Vulnerability: Because Trojan uses raw TCP, it is susceptible to Head-of-Line Blocking (HOLB) on poor or lossy networks (Article 11), leading to connection stalls.
- Password Management: Trojan uses a shared password model. If a single password is leaked, all clients using that password are immediately compromised, making multi-user management less flexible than VLESS/REALITY (which uses individual UUIDs that can be revoked).
The Trojan-Go Evolution
Recognizing these limitations, extensions like the popular Trojan-Go project have introduced transport flexibility, allowing Trojan traffic to be carried over WebSocket and gRPC. However, the core V2Ray implementation remains focused on the original raw TCP/TLS approach, emphasizing maximum simplicity and perfect, direct HTTPS mimicry.
Conclusion: Simplicity and Trust
The Trojan protocol’s genius lies in its unwavering trust in the existing internet infrastructure—TLS and Port 443. It trades the complexity of VLESS and the anonymity of a CDN for the sheer speed and ubiquity of raw HTTPS. By maintaining a perfect illusion of legitimate web traffic through valid certificates and intelligent fallbacks, Trojan continues to be one of the most effective and low-maintenance protocols available for high-stealth, direct-connection V2Ray deployments.
