The Trojan protocol is a proxy protocol that sends authenticated forwarding requests through a real TLS connection. It borrows the protected connection used by HTTPS, while its application messages tell a remote server which destination to contact; it is unrelated to the malware category called a Trojan.［1］

Key Takeaways:

TLS establishes the protected client-to-server channel before proxy authentication.

A trusted certificate and an accepted proxy credential answer different questions.

Fallback handles unrecognized traffic after TLS; it does not repair a failed handshake.

A working proxy request proves one path, not whole-device coverage or invisibility.

How does the Trojan protocol fit into a connection?

Think of three separate conversations: an application talks to its local proxy client, that client talks to a remote Trojan server, and the server talks to the requested destination. The client-to-server conversation starts with TLS. Only after that succeeds does the client send the credential, destination request, and application payload.［1］

The diagram places the decision inside the TLS endpoint. The upper branch carries recognized proxy traffic to the requested destination; the lower branch forwards unrecognized input to a configured fallback service. The destination and fallback service have different roles, even when both happen to be web servers.

A proxy does not automatically capture everything

The protocol tells the server what to forward, but your client integration determines which application traffic enters it. A browser proxy setting is not evidence that another application's connections, DNS queries, or UDP traffic use the same path. A TUN-based client can capture a broader set of traffic, but that is an additional integration layer rather than the definition of Trojan.

The broader VPN connection model helps distinguish traffic capture from forwarding. Keep those questions separate when reading a client screen: a running process, a selected profile, and an application actually using that profile are three different observations.

What does Trojan TLS protect?

Trojan TLS protects data exchanged between its client and server. TLS supplies channel confidentiality and integrity when correctly implemented and authenticated; it does not assign a privacy policy to the endpoint or make every application protocol HTTPS. The current TLS 1.3 specification is RFC 9846, which supersedes RFC 8446.［3］

An HTTPS website connection can exist inside the proxy's protected channel. In that case, the browser still establishes its own encrypted session with the website, and the proxy forwards those bytes. If the application sends plaintext onward, the Trojan server's TLS connection does not extend that protection beyond the server.

Similar transport does not mean identical behavior

A network observer may see timing, packet sizes, addresses, and connection patterns without seeing the encrypted application payload. A real TLS handshake therefore supports a narrower claim than “this is impossible to recognize.” The protocol's camouflage design cannot certify resistance to every passive classifier, active probe, endpoint block, or future network policy.

The distinction between protocol and camouflage makes this easier to evaluate. Ask which part of a claim follows from a standard, which part comes from a particular implementation, and which part would need a dated test on the network you actually use.

Why does Trojan certificate validation matter?

Trojan certificate validation is how the client checks the remote TLS identity before sending its proxy credential. A certificate chain must be trusted under the client's policy, and the presented service identity must match the intended name. A certificate for some other legitimate website does not authenticate the endpoint you meant to contact.［2］［4］

Server identity and permission are separate

The certificate answers whether the client has reached the expected TLS peer. The proxy credential answers whether that peer will authorize forwarding. Neither answer proves that the endpoint has an acceptable logging policy, that every destination is reachable, or that the software receiving the credential is maintained safely.

Disabling verification to dismiss a warning removes an important part of that first answer. An expired certificate, unexpected name, missing trust anchor, or incorrect clock needs an explanation; a connection that starts working after a check is disabled is not evidence that the original check was unnecessary. Do not send credentials to an endpoint whose identity you cannot establish.

For a managed service such as AethoVPN, evaluate the documented client and service trust boundary instead of treating a protocol name as a certificate guarantee; the protocol selection overview gives you a way to compare the evidence each connection method actually offers. The same distinction matters whenever a client hides low-level details behind a simple connect button.

What happens after authentication, and when does fallback apply?

The Trojan protocol places a password-derived SHA-224 hexadecimal value before a SOCKS-like request containing a command and destination address. The server checks that input and, for an accepted request, forwards traffic according to the requested operation. This framing belongs inside TLS; the password-derived value is not a substitute for channel protection.［1］

Forwarding and fallback are different outcomes

Trojan fallback sends unrecognized or invalid post-handshake input to a preset endpoint. It can let ordinary web traffic receive an ordinary web response rather than a proxy-specific rejection. This fallback destination is selected by server configuration, not by an unauthenticated visitor's arbitrary proxy target.［1］

A failed TLS handshake happens earlier. It cannot become a successful authenticated proxy request merely because a fallback website exists. Likewise, seeing a webpage from the server can be evidence of the fallback branch without being evidence that your proxy credential was accepted.

This is a useful troubleshooting boundary: “the address responds,” “TLS validates,” “authentication succeeds,” and “the destination responds” describe successive properties. Record the strongest one your observation actually establishes. Treat the next property as unproven until you have evidence for that stage, rather than collapsing every failure into “Trojan is blocked.”

What do TCP and UDP support actually tell you?

The documented requests include TCP CONNECT and UDP ASSOCIATE. UDP payloads have their own destination and length framing within the protected connection. The familiar command names resemble SOCKS, but the remote Trojan exchange is its own protocol, not a bare local SOCKS connection exposed to the Internet.［1］

A supported operation can still fail in a client

Support in a specification does not establish support in every client build or local application interface. A program may use only a TCP proxy setting, perform DNS outside the proxy, or never send its UDP traffic to the client. Conversely, a failure at the destination does not necessarily mean the protected client-to-server channel is broken.

Do not infer that a successful browser request establishes voice-call or game behavior. These can use different traffic types, destinations, or routing rules. Similarly, do not apply performance rankings without comparable measurements of device, network, server, direction, and workload.

For an alternative encrypted application-proxy model, the Shadowsocks definition and coverage boundaries explain what remains an integration question. That article is a terminology reference, not evidence that switching protocols will solve a particular failure.

What can observed behavior prove?

Use this table as an evidence map, not a list of diagnostic commands. Each observation has a boundary, and several possible causes can produce the same symptom. The interpretations follow from the separation of TLS, proxy authentication, forwarding, and traffic capture described above.

Observation	What it supports	What it does not establish
The server address accepts a connection	A listener is reachable on that tested path	The expected TLS identity or accepted proxy credential
TLS succeeds with identity verification enabled	The checked peer identity and protected channel under that policy	Logging behavior, proxy permission, or all destination reachability
An ordinary webpage is returned	A web or fallback path can respond	An authenticated Trojan request succeeded
An authenticated request reaches one destination	That application request traversed the tested forwarding path	Other applications, DNS, UDP, or whole-device coverage
One connection is slow or fails	That specific path or workload has a problem	A universal protocol ranking or proof of deliberate filtering

Keep the protocol and implementation names apart

A client may run a core that implements multiple protocols. Xray and V2Ray's component roles explain why the core name does not tell you which wire protocol a selected profile uses. Read the active configuration's documented identity rather than assuming the application name supplies it.

If your actual decision is between different protected connection models, the Trojan and VLESS/REALITY comparison develops that separate question. The definition here supplies vocabulary for the comparison; it does not endorse a deployment, promise regional availability, or provide bypass parameters.

Summary

Trojan is authenticated proxy forwarding carried inside a real TLS connection.
Certificate validation, proxy authentication, and destination success are separate evidence stages.
Fallback concerns unrecognized input after TLS, not recovery from a failed handshake.
Traffic coverage depends on the application and client integration; encryption alone does not prove anonymity.

FAQ

Is the Trojan protocol malware?

The Trojan protocol is a network proxy protocol, while a Trojan in malware terminology is malicious software disguised as something legitimate. Sharing a name does not establish a security relationship. You still need to trust the source and behavior of any client software you install.

Is Trojan the same as HTTPS?

Trojan uses a real TLS connection, which is also part of HTTPS, but its authenticated application messages request proxy forwarding. HTTPS carries HTTP semantics. A protected transport in common does not make those higher-level protocols identical or guarantee identical observable behavior.

Does Trojan require a valid certificate?

A certificate-based deployment needs a certificate that the client can validate for the intended service identity under its trust policy. Merely possessing any certificate is insufficient. Disabling checks to accept an unexpected identity weakens the protection before the proxy credential is sent.

Does fallback prove that the proxy works?

A responding fallback website proves only that the corresponding web path can respond. It does not prove that an authenticated proxy request was accepted or that its destination can be reached. TLS failures occur before the normal post-handshake fallback decision.

Can Trojan forward UDP?

The documented protocol includes UDP ASSOCIATE and framing for UDP payloads. Whether your traffic uses it depends on the implementation and local application integration. A successful TCP webpage does not demonstrate that the same client carries UDP correctly.

Is Trojan a whole-device VPN?

Trojan defines a proxy exchange, not automatic capture of every device packet. A client may add a TUN interface and system routing, but those components determine coverage. Check application traffic, name resolution, and policy separately rather than inferring them from the protocol label.

Can Trojan be detected or blocked?

No protocol definition proves universal immunity to detection or blocking. TLS protects the payload, but addresses, timing, connection patterns, endpoints, and implementation behavior can still matter. Availability claims require evidence for a specific network, date, client, and server.

Disclaimer: This is a conceptual explanation, not a deployment guide or a claim of tested availability. Follow applicable laws and network policies; review the official documentation for your actual implementation.

Sources

Sources checked 5 October 2026.

What Is the Trojan Protocol? How It Blends Into HTTPS