VLESS Reality vs Trojan is not a one-line speed contest. VLESS plus REALITY is a layered proxy design where VLESS authorization and REALITY server authentication are configured separately, while classic Trojan over TLS is the classic trojan-gfw protocol, which authenticates a password-derived value inside a TLS connection and then requests a TCP or UDP destination; the useful choice follows traffic scope, trust, transport, and operational ownership.［1］［2］［3］

The complete VPN guide explains the general tunnel model. This article keeps the decision tied to the exact protocol generation and deployed stack.

Key Takeaways

The baseline is classic trojan-gfw over certificate-based TLS, not Trojan-Go or every Xray combination named Trojan.

VLESS authorization and REALITY server authentication are separate layers.

Classic Trojan sends password-derived authorization and a SOCKS5-like request after TLS succeeds.

Trojan fallback is a defined invalid-request path and must be tested with a controlled endpoint.

Compare trust enrollment and failure stages before comparing throughput.

VLESS Reality vs Trojan in one table

Dimension	VLESS plus REALITY	classic Trojan over TLS
System model	a layered Xray baseline using VLESS `decryption: none` and REALITY stream security; VLESS Encryption is a separate configuration outside this comparison	the classic trojan-gfw protocol, which authenticates a password-derived value inside a TLS connection and then requests a TCP or UDP destination
Traffic entry	A local Xray inbound accepts application traffic; broader capture needs explicit routing or TUN integration	Applications use a local Trojan proxy; broader capture likewise needs separate integration
Trust material	VLESS user ID plus REALITY private/public parameters, server names, and short ID	TLS certificate and hostname trust plus the SHA-224 value derived from the Trojan password
Handshake and carrier	The selected Xray transport with REALITY server authentication, followed by VLESS authorization	TLS over TCP, followed by password-derived authorization and a CONNECT or UDP ASSOCIATE request
Failure evidence	Distinguish transport, REALITY, VLESS, routing, and outbound failures	Distinguish certificate/TLS, password, request parsing, preset-endpoint fallback, and destination failures

Trojan here means the classic trojan-gfw protocol, not Trojan-Go and not every product or Xray combination that happens to use the Trojan name.［3］

What traffic scope does each design create?

Both candidates are proxy paths whose coverage depends on the local inbound or interception layer. A browser configured for one proxy is not evidence that background services, DNS, IPv6, or UDP applications use the same path. Keep the capture configuration outside the protocol comparison and verify each intended branch independently.

Classic Trojan defines CONNECT and UDP ASSOCIATE request commands after its TLS and password-derived authorization sequence. The VLESS side exposes its destination command and user settings separately from REALITY and the selected transport. Those command capabilities still do not install device routes or decide which applications enter the local proxy.［1］［3］

Scope checkpoint

For VLESS + REALITY versus classic Trojan, draw the entry path before testing: application, capture mechanism, route, resolver, outbound, and destination. Record which process installs each rule and test a destination that should use each branch. This turns the coverage claim into observable evidence and exposes the difference between a native interface and a proxy reached through optional integration.

How do VLESS REALITY authentication and classic Trojan TLS trust differ?

Classic Trojan relies on the TLS server identity presented to the client and then checks a hexadecimal SHA-224 value derived from the configured password inside the encrypted connection. VLESS plus REALITY separates VLESS user authorization from REALITY server authentication and associated public parameters. These are different trust-enrollment workflows, not interchangeable credential formats.［1］［2］［3］［4］

For Trojan, log certificate or TLS failure separately from password rejection, request parsing, preset-endpoint fallback, and destination dialing. For the VLESS-plus-REALITY side, distinguish REALITY authentication, VLESS authorization, transport establishment, routing, and outbound failure. Redact passwords, UUIDs, private keys, and short IDs while retaining the failed stage.

Trust checkpoint

Build a credential inventory for the exact pair rather than a generic encryption checklist. VLESS and REALITY parameters are not interchangeable with the password and certificate trust used by classic trojan-gfw over TLS. Record which side authenticates which party, how every secret or public parameter is issued and rotated, and which log event distinguishes transport security from proxy authorization. A copied field name is not evidence that two credential models are equivalent.

How do transport and outer behavior differ?

The classic Trojan baseline begins with ordinary TLS semantics and then places its authorization and proxy request inside that channel. REALITY uses a different server-authentication design and does not make VLESS, Vision, transport, and routing one protocol. A shared port number or TLS-like appearance is therefore insufficient evidence that the two handshakes, trust stores, or failure behavior are equivalent.［2］［3］［4］

A useful test measures TLS or REALITY establishment, proxy authorization, destination setup, sustained transfer, and recovery separately. Hold the endpoint, capture scope, payload, address family, and observation window constant. This reveals whether a difference comes from certificate handling, fallback, transport selection, or data transfer instead of attributing every delay to the protocol label.

Transport checkpoint

Capture the outer connection and identify it independently from the inner application flow. The baseline is classic Trojan over TLS, including its request and fallback behavior; optional Trojan-Go or unrelated Xray transports are outside this comparison. Test setup failures, IPv4 and IPv6 reachability, MTU-sensitive transfers, UDP-dependent applications, and recovery after path changes. Do not infer censorship resistance or throughput from a port number, encryption alone, or a project goal.

How does Trojan fallback behavior change routing and operations?

Trojan's preset endpoint deserves an explicit owner because invalid post-TLS traffic can be forwarded there rather than accepted as a proxy request. The VLESS-plus-REALITY path has different routing and rejection points. Draw both state machines, name the process responsible for each outbound, and verify that an authorization failure cannot be mistaken for a successful destination connection.［3］

Certificate issuance, renewal, name validation, and password rotation define the classic Trojan lifecycle. REALITY key material, server names or targets, short IDs, VLESS users, and the selected Xray transport form a different lifecycle. Test renewal and revocation before migration; counting fields without exercising them says little about recovery risk.

Operations checkpoint

Operate VLESS + REALITY and classic Trojan as two versioned systems. Pin client and server builds, keep configuration ownership explicit, stage changes, and retain a rollback path that restores routes and DNS. Compare monitoring coverage, secret rotation, platform compatibility, and incident isolation. A smaller file is useful only when the team can also diagnose and recover the resulting data path.

How should you choose for a real requirement?

Choose classic Trojan when certificate-based TLS trust, its defined password request, and controlled fallback behavior fit the deployment. Choose VLESS plus REALITY when its separate user-authorization and server-authentication model is the required architecture and the complete Xray stack is supportable. Reject either design if its trust enrollment, local capture, transport, or failure diagnostics cannot meet the acceptance contract.

The decision record should name the classic Trojan version and certificate setup or the complete VLESS, REALITY, flow, transport, and routing combination. Preserve controlled fallback results and credential-revocation evidence. That is more useful than a universal ranking because the two candidates solve trust and composition differently.

Selection checkpoint

The practical decision is conditional: Choose between the two complete trust and handshake designs, not between a REALITY label and an unspecified product called Trojan. Reject either candidate that cannot meet mandatory platform, address-family, traffic-scope, transport, or trust requirements. For the remaining candidates, compare repeatable distributions and failure recovery under the same endpoints and workload; do not turn one benchmark into a permanent protocol ranking.

What should a failure drill prove?

Keep the classic Trojan baseline explicit. After a successful TLS handshake, the client sends a hexadecimal SHA-224 value derived from its password, followed by a SOCKS5-like CONNECT or UDP ASSOCIATE request. If that structure or password is invalid, classic trojan-gfw treats it as another protocol and connects the decrypted TLS stream to a preset endpoint instead of authorizing the proxy request.［3］

Test those stages separately from certificate validation. For Trojan, record TLS server-name and certificate checks, password-derived authorization, request parsing, fallback routing, and destination dialing. For VLESS plus REALITY, record VLESS authorization separately from REALITY server authentication and the selected transport.［1］［2］［3］［4］

Use a harmless controlled request for fallback tests and verify only the expected preset endpoint receives it. Do not mix Trojan-Go or independently composable Xray modes into the result, and ensure diagnostics distinguish certificate, handshake, authorization, fallback, and outbound failures without logging secrets.

Does this VLESS/REALITY–Trojan comparison describe AethoVPN?

If you want a managed service instead of self-hosting, run AethoVPN on the same network where you would otherwise deploy a Trojan or REALITY server: install the client, connect to one location from the in-app list, try a second location if the first stalls, and note the network and the stage at which each attempt stops. The product pages describe no TLS camouflage or fallback design, so a stalled or successful attempt speaks for that network and location only, not for how AethoVPN compares with trojan-gfw or REALITY. Start the 3-day AethoVPN trial to gather those results.

Summary

“Trojan” here means the classic trojan-gfw protocol over TLS.
Certificate validation precedes Trojan's password-derived authorization and proxy request.
Invalid classic Trojan requests can take the configured preset-endpoint fallback path.
VLESS authorization and REALITY authentication must be observed separately.
The choice turns on trust operations and failure handling, not a universal speed ranking.

FAQ

Does Trojan in this comparison include Trojan-Go?

No. The baseline is classic trojan-gfw over TLS. Trojan-Go and independently composable Xray modes would change the object being compared.

What happens when a classic Trojan request is invalid?

After TLS, classic trojan-gfw treats an invalid structure or password as another protocol and connects the decrypted stream to its configured preset endpoint.［3］

Does a valid TLS certificate authorize a Trojan user?

No. TLS authenticates the server to the client; classic Trojan then performs its separate password-derived authorization inside that connection.［3］［4］

Is a REALITY short ID equivalent to a Trojan password?

No. The fields belong to different handshake and authorization designs. They need separate generation, distribution, rotation, revocation, and redaction rules.

How should Trojan fallback be tested safely?

Use harmless malformed requests in a controlled environment and verify that only the configured preset endpoint receives them. Never point a failure drill at an unrelated production service.

Which certificate event belongs in a Trojan runbook?

Cover issuance, renewal, expiration, hostname validation, trust-chain failure, and rollback to the last valid certificate. Keep those events separate from password rejection and destination failure.

What should be preserved before changing trust models?

Preserve the exact builds, certificate configuration, Trojan password lifecycle, REALITY parameters, VLESS users, transport settings, fallback evidence, and a tested rollback trigger.

Disclaimer: This architectural comparison is for general information and is not a performance benchmark or a guarantee of availability on any network.

Sources:

Project X, VLESS inbound configuration: https://github.com/XTLS/Xray-docs-next/blob/main/docs/en/config/inbounds/vless.md
XTLS REALITY, README: https://github.com/XTLS/REALITY/blob/main/README.en.md
Trojan-GFW, Protocol: https://github.com/trojan-gfw/trojan/blob/master/docs/protocol.md
RFC 9846, The Transport Layer Security Protocol Version 1.3: https://www.rfc-editor.org/rfc/rfc9846

Sources checked 13 September 2026.

Related Articles:

VLESS Reality vs Trojan: Key Differences