Experience from V2Ray to Xray
Recently, serendipitously guided by YouTube’s recommended videos, I stumbled upon a new creation within the Xray realm: REALITY.
To be candid, my current architecture still clings to the system of the year 2020. It operates on the foundation of Docker and Watchtower, ensuring seamless automated updates. It has remained steadfast for two years, encountering no significant issues, except for a minor April tweak to facilitate WARP for accessing ChatGPT.
The last time I closely followed Xray-related developments was during the “forking watermelon” days of 2021. Hence, I embarked on a journey to the Xray project to uncover the latest advancements. Regrettably, the official website offers limited insights, prompting me to navigate through various issues to glean traces of progress.
Following a cost assessment of the migration process, I transitioned from V2Ray to Xray. The overarching architectural framework remains unchanged – it still relies on Nginx for traffic distribution. The alteration pertains to the underlying network tools, and I took the liberty to introduce a few new protocols (VLESS, Vision, gRPC) along the way.
Xray: Origins and Relationship with V2Ray
Both Xray and V2Ray share a common lineage, stemming from the same project and later undergoing forks and iterations. For more extensive insights, please refer to this article 🍉.
REALITY and Vision: Their Birth and Purpose
TLS communication tools like Trojan have been plagued by the TLS in TLS issue, where the “encryption nesting” may imbue them with certain statistical characteristics. For a detailed analysis, please peruse the discussion in the GitHub thread, particularly the section titled “生死 5 包” (Life and Death of Five Packets).
In response, RPRX initiated the Trojan-killer project. I encourage you to delve into the source code for an in-depth understanding. In essence, the project’s overarching approach revolves around validating the “encryption nesting.”
XTLS, Vision, REALITY: What Are They, and How Do They Function?
XTLS represented an early solution to the TLS in TLS quandary. Its implementation required modifications to the official TLS/uTLS libraries, raising concerns about long-term maintainability. However, the conceptual foundation remains sound.
Vision can be regarded as a refined version of XTLS. It, too, addresses the TLS in TLS issue, now referred to as “stream control” under the moniker xtls-rprx-vision.
For a comprehensive understanding of the workings of XTLS and Vision, I direct your attention to the previous elucidation: 👉 V2Ray, Trojan, XRay.
REALITY, on the other hand, was conceived to further obliterate server TLS fingerprint characteristics, mitigating SNI censorship and similar challenges. Details regarding its operation are scattered across various GitHub issues. By examining the project’s code alongside, I conducted a rudimentary analysis of REALITY’s modus operandi.
Broadly, REALITY relies on camouflage to deceive inspectors. It appropriates handshake packet characteristics from legitimate well-known websites, adding its own authentication elements. The general workflow comprises:
- The server requests Server Hello packets during the TLS handshake phase from reputable websites like Apple and Bing.
- Armed with this authentic handshake packet, the server interacts with the client, albeit infused with verification elements crafted by Xray.
- As the packet contents undergo modifications, the client cannot directly process this Hello packet. It necessitates validation and processing before communication can proceed.
From an external perspective, these proceedings closely resemble interactions with major websites like Apple and Bing. Traditional methods like certificate chain analysis are rendered futile, as it merely dons the skin of prominent websites, concealing its core validation algorithms.
An introduction to the TLS handshake process is available at the inception of Trojan Shared 443 Port Scheme.
In summary, REALITY’s design philosophy is undeniably unconventional!
Relevant GitHub Issues:
Potential Drawbacks of REALITY
Firstly, support for accompanying tools remains limited. Any solution must be user-friendly and easy to adopt to gain widespread acceptance. Currently, the range of supported tools is rather constrained.
Secondly, protocol refinement is crucial. While the current approach seems theoretically sound, the act of camouflage itself might introduce new characteristics. This remains unverifiable and necessitates ongoing observation.
Performance is another aspect worth considering. The additional step of the server retrieving handshake packets from websites like Apple introduces a network overhead. Fortunately, there is room for optimization, with reports suggesting the addition of caching.
Lastly, there’s the matter of DNS, as discussed in this issue. Essentially, it concerns traffic distribution. While interactions are disguised as traffic from major websites, the associated IP addresses remain visible. Hence, there’s a statistical footprint when certain IP addresses suddenly exhibit traffic for domains like Apple and Bing 😂. Is this, in itself, a new characteristic? Similarly, only time will provide clarity.
Given that this is a nascent endeavor, I believe it merits ongoing observation. Innovation is essential to uncover new possibilities 👏.
My Choice
The overarching criteria for my selection remain consistent: security > stability > speed.
The final tool selection encompasses:
- V2Ray => Xray
- ClashX => Clash.Meta (Client configuration compatible)
Regarding protocols, I opt for:
- VLESS+Vision+TLS (default, newly introduced)
- Trojan+TCP+TLS (legacy, retained)
- VLESS+gRPC+TLS (newly introduced)
- VMess+WebSocket+TLS+CDN (emergency, retained)
To be candid, I’ve encountered no issues using Trojan thus far, as I don’t utilize any online services. Even during sensitive times, it has proven resilient.
I believe the greatest risk lies in the “online neighbors” one might encounter rather than the characteristics of various tools and protocols 🙈.
This transition primarily aims to explore new tools and address potential risks:
- TLS in TLS Characteristics: Employing Vision, specifically
xtls-rprx-vision - Client TLS Fingerprints: ClashX lacks support for Vision (VLESS), hence the shift to Clash.Meta, which incorporates
client-fingerprintby default - Server TLS Characteristics: REALITY is not yet in use; if it ever is, the migration cost within my existing architecture remains minimal
In comparison to my system from 2020, the new solution remains largely unchanged. It still relies on Nginx for SNI-based routing, with inter-container communication transitioning to Unix Sockets. This architecture fully leverages Fallback for supporting multiple protocols.
graph LR
A["Client"] -->|HTTPS Request| B("Nginx")
A["Client"] -->|HTTPS Request| B0("CDN")
B0-->|Only White List \n and No TLS|B
B -->C{"dispatch"}
C -->|SNI Socket|D["VLESS+Vision+TLS"]
C -->|SNI Socket|E["Trojan+TCP+TLS"]
C -->|SNI Socket|F["Nginx Web No TLS"]
C -->|SNI Socket|J["Other Services"]
D -->|Fallback|F
E -->|Fallback|F
F -->|Path Socket|G["VLESS+gRPC"]
F -->|Path Socket|H["VMess+WebSocket"]
F -->|Fallback|I["Default Page"]
J -->|Socket|J0["PHP"]
J -->|Socket|J1["GO"]
J -->|Socket|J2["..."]
Various configurations can be explored in the lxhao61/integrated-examples project, aligning with my current setup. Performance optimization varies from person to person, allowing for individual adjustments.
Now, let’s run some tests 🏃!
The speed test results have surprised me. The lag in VLESS+gRPC+TLS was unexpected, especially in Multi and Single modes, where the difference is negligible. This might be attributed to link reuse 🤔️. The disparity between VLESS+Vision+TLS and Trojan+TCP+TLS is minimal, as anticipated. VMess+WebSocket+TLS+CDN falls in the middle ground. In any case, it serves as an emergency fallback 🚑.
Conclusion
My personal conclusion remains unaltered: presently, protocols based on TLS hold the key to the future, while the greatest risk still emanates from “online neighbors.”
Though TLS-based solutions exhibit issues like TLS in TLS, client fingerprints, and server characteristics, it’s heartening to see numerous individuals actively engaging in this field, striving to resolve these challenges.
Throughout this journey, new protocols and tools continue to emerge. Nevertheless, it’s essential not to expend excessive energy on protocol experimentation. If your current protocol isn’t facing interference, there’s no need to chase after others. Stay informed and vigilant.
Our goal is to access internet resources freely, acquire desired content, not to dwell on the transport tools themselves. It’s akin to embarking on a journey not for the means of transportation but for the experience of the journey itself.