V2Ray, Trojan, XRay

This article exclusively delves into the relationships between V2Ray, Trojan, and XRay, shedding light on select technical aspects of their protocols.

The V2Ray Tool

V2Ray stands as the quintessential tool under the Project V initiative, currently referred to as V2Ray-Core. It is primarily responsible for the implementation of networking protocols, routing, and other facets of network communication.

What Is Project V?

Project V has evolved into a toolkit for custom communication networks. Initially, Project V bore the moniker V2Ray, but after the immense popularity of V2Ray, numerous contributors expanded it into a broader Project V ecosystem. Consequently, today’s V2Ray-Core retains traces of its original name in its README.md as Project V.

While V2Ray boasts outstanding design and high customization capabilities, it has dominated the custom communication network sphere for quite some time. However, this very success has brought along certain vulnerabilities.

Introducing V2Fly

The genesis of V2Fly occurred due to the sudden disappearance of Victoria Raymond, the founder of the V2Ray project. As other maintainers lacked complete project permissions, they established a new community: V2Fly. Subsequently, V2Fly has taken charge of all updates related to V2Ray.

The TLS Traffic Recognition Controversy

V2Ray-Core faces a contentious issue in its TLS implementation, with a hard-coded list of Cipher Suites that make TLS traffic easily identifiable through precise signature matching. See the discussion here.

VMess Protocol

Even with the establishment of a new community, V2Ray’s core updates and maintenance have remained stable. Its flagship VMess protocol, in particular, has faced minimal issues, warranting no extensive introduction.

The VMess Protocol’s Active Recognition Controversy

Through replay attacks, VMess services can be accurately identified. This event dealt a severe blow to V2Ray, leading to the birth of VMessAEAD. See the discussion here.

VMess prioritizes security in its design. However, while ensuring security is paramount, the pursuit of speed and performance has gained momentum. Consequently, a new player emerged with a fresh design approach: Trojan.

The Trojan Tool

The popularity of Trojan can be attributed, in part, to the widespread coverage of HTTPS.

Trojan’s ingenious design lies in its direct utilization of HTTPS for communication. Consequently, its traffic characteristics appear akin to vast quantities of HTTPS traffic, remaining concealed. Discuss its design approach here.

With its straightforward design, relying solely on TLS as a trusted channel, Trojan offers stable core communication functions without additional encryption. Moreover, it exhibits commendable performance without added features. Despite its direct handling of traffic, which results in port 443 occupancy, comprehensive solutions are available. Explore these solutions here.

The Outstanding Emulator: Trojan-Go

Trojan-Go is a Trojan implementation in Go, featuring additional functionalities as a superset of Trojan. It introduces many enhancements, including multiplexing, custom routing, and CDN forwarding, while retaining Trojan’s original protocol.

Since the Trojan approach has proven effective, why layer on additional custom encryption protocols like VMess over TLS? While this may provide extra security, for the majority of users, it results in unnecessary overhead. This paved the way for V2Ray’s VLESS protocol.

VLESS Protocol

VLESS protocol, also originating from the V2Fly community, follows a design philosophy similar to Trojan. Both rely on trusted channels for transmission and avoid additional encryption. While Trojan employs TLS as its trusted channel, VLESS, as per its documentation, appears more versatile, not limited to TLS. However, it has not provided examples of alternative trusted channels.

All “Trojan-like” designs invariably involve a “trusted channel.” Trojan relies on TLS, which seems to be the most suitable choice. The performance overhead mentioned earlier is due to TLS. As a result, XTLS protocol emerged to optimize TLS performance.

XTLS Protocol

The principle behind the XTLS protocol is the merging of two TLS requests in the proxy process into a single TLS request. This reduces one TLS encryption process, thus improving performance.

When we browse HTTPS websites or use mobile apps via TLS-based proxies, there are effectively two layers of TLS: an outer layer for the proxy and an inner layer for the website or app.

XTLS starts from the second inner TLS data record, bypassing secondary encryption and forwarding data directly. It seamlessly splices two authentic TLS streams, presenting an uninterrupted standard TLS stream from an external perspective. Consequently, most traffic requires no additional decryption.

Currently, there is limited documentation on this topic, and official documentation has yet to be updated. View the release introduction here.

While XTLS protocol also originated from the V2Fly community, it was removed from V2Ray-Core due to licensing issues. See the discussion about licensing here. In reality, most discussions occur on Telegram. Ultimately, the creator of the XTLS protocol established the XRay community.

The XRay Tool

XRay, a core tool under Project X, currently referred to as XRay-Core, closely resembles V2Ray-Core. It handles network protocols, routing, and other networking communication functions, albeit as a superset of V2Ray-Core. While both support VLESS, only XRay supports XTLS.

What Is Project X?

The creator of the XTLS protocol branched out to establish the XRay community, the counterpart to Project V.

How to Choose

Regarding personal choices, the quality of the network connection significantly influences the experience. No amount of optimization can overcome a poor connection.

It is advisable to avoid using CDNs unless necessary, as each additional hop introduces some level of latency, even with the option of “self-selecting IP addresses.”

The choice of UI tool should prioritize platform support and user experience, with the selection of the underlying communication tool as the final consideration.

When selecting an underlying tool, prioritize security, stability, and speed, in that order.

Taking all factors into account, the current optimal choice remains the “Trojan-like” approach. While it has its drawbacks, such as TLS overhead, optimization of TLS would render it the best solution. After all, TLS is a widely recognized and accepted protocol in the internet security domain, forming the foundation of secure internet transmissions. Reusing established protocols is more mature and stable than creating new ones.

As of now, XTLS shows promise, but both VLESS and XTLS lack stable versions, and the surrounding ecosystem support and stability are insufficient. Therefore, the final choice essentially narrows down to Trojan and V2Ray (utilizing VMess and TLS without encryption).

Since XTLS is a custom interaction protocol currently only usable in XRay, it is incompatible with Clash, which I use. Currently, there are no explicit plans for support. Given the numerous custom rules in Clash, I opted against it.

Simultaneously, there is ongoing discussion about the “protocol fallback” for V2Ray/XRay. This is essentially old wine in new bottles, but if it proves stable, it can be quite convenient due to its intricate details.

Ultimately, I personally use Trojan. I find its design simple, efficient, and stable, embodying the principle of Occam’s razor.

Entities should not be multiplied unnecessarily.

Occam's Razor Principle

In the realm of open-source projects, “history often repeats itself”: project gains popularity, community forms, founder goes missing, community rebuilds, fork due to unforeseen circumstances, one fork turns out poorly.

XRay and V2Ray are already in a relationship of core functionality, and once the uniqueness is lost, the necessity for independent existence is questionable.