VLESS 的核心受众由于缺乏对 PoC 概念的基本理解，只能将PoC中的假阳率当作救命稻草。既然如此，笔者决定求锤得锤，更新了可以开箱即用的版本。若读者拥有网络管理员权限，现在即可将其部署于教育网或公司网络出口路由上，亲自验证该协议在实网环境中的真实表现，看一下都是哪位同学在用VLESS翻墙。
至于 RPRX，不出笔者所料，依然在使用一贯的话术，试图轻描淡写地掩盖漏洞的严重性。然而事实如下：
-
所有当前 xray-core 版本的用户均已直接暴露。即便使用笔者提供的非工程化版本 PoC，也能轻松将其识别。
-
至于掩耳盗铃式修补后的新版 xray-core，笔者已在漏洞详解中给出了应对思路。由于变种方案需要主动修改数据包进行探测，在标准Linux环境下难以直接提供傻瓜式的 PoC 代码，但网络安全领域的专业人士完全可以轻松验证。
所以事实上，本文已正式宣告 VLESS 协议死亡。笔者确实无法叫醒装睡的人，VLESS 及其核心群体早已完成了邪教化的提纯。笔者已无意与这群没有思考能力的邪教徒继续作无谓的纠缠，接下来只需静待第三方中立机构或其他安全研究员对本漏洞予以独立确认即可。
由于RPRX和其信徒的一些回应与动作实在滑稽可笑，此等笑料笔者不敢独享，一位小学弟自告奋勇建立了一个Telegram频道，供大家围观：
各位好。笔者作为一名网络安全行业的从业者，出于工作原因及个人志趣，自2010年前后起便持续关注突破网络审查（翻墙）协议社区的发展，并对绝大多数现有协议进行过深入的技术剖析。长期以来，笔者时常目睹RPRX（社区常俗称R主席）发表的诸多违背常理之言论，对此颇为反感。近期适逢防火长城（GFW）封锁加剧，RPRX再度声称唯有其主导的VLESS/XTLS/REALITY协议方能实现直连，并将其他协议贬低为毫无价值之物。笔者本对此类营销式说辞不屑一顾，然出于探究之目的略作审视，未曾想仅耗时十分钟，便触及该协议之致命漏洞——该漏洞能够以近乎100%的准确度探测出VLESS/XTLS/REALITY流量，且误判率极低。
应当明确，几乎所有主流翻墙协议面对审查时，皆仅存在概率性被封锁的风险，而极难被精准识别。笔者在此必须强调一个严峻的事实：倘若翻墙协议能够被精准定性，那便意味着翻墙者本人的网络行为及物理位置，亦可被审查方精准定位。
在具体探讨该漏洞的技术细节之前，笔者认为有必要先行阐明，为何笔者对RPRX及其协议持有如此强烈的反对态度，以及笔者决定公开此漏洞的初衷。
（提示：本文包含大量技术细节及翻墙协议社区之历史争议。若读者对相关背景不甚了解，笔者建议可将全文交由AI，要求其逐条进行事实核查。）
首先，关于VLESS/Vision/XTLS/REALITY这一系列协议（鉴于其官方文档表述含糊不清，且社区内称呼亦莫衷一是，笔者在此将其统称为“R协议”），笔者认为，这是笔者所见过的架构设计中表现第二劣质的翻墙协议（居首位者为VMess，其逻辑之混乱已达匪夷所思之境地）。
更为关键的问题在于，纵观整个社区，从未有哪位协议开发者如RPRX这般，在不遗余力吹嘘自身协议的同时，日复一日地攻讦同行。其言辞中屡屡暴露出常识性错误，这足以说明其根本未曾系统性地学习过网络安全与密码学。由此推断，该协议的底层质量必然是千疮百孔的。
笔者注意到，RPRX在攻击如SS（Shadowsocks）等其他协议时，最常引用的论点是：若SS协议的流量密码泄露，其流量便可被解密；若服务商（机场）采用共享密码，用户便等同于在网络中“裸奔”。他据此得出“SS缺乏安全性”的结论。
在密码学领域，此概念被称为“前向安全”（Forward Secrecy），并非什么前沿理论。笔者必须指出，R协议所谓的前向安全，实际上完全继承自其底层的TLS协议本身。所有基于TLS构建的翻墙协议均天然具备此特性，然而RPRX在宣传中却将其包装为R协议独有的核心优势，甚至试图让大众误以为这是其本人的研发成果。
此外，笔者需要客观说明，实现前向安全的代价是协议在握手阶段必然会增加一个RTT（往返时延），除非引入会话复用机制。因此，所有TLS类代理协议在握手延迟上，均不可避免地慢于SS或同类协议。实际上，是否启用前向安全，在工程实践中是一个需要权衡（trade-off）的设计抉择，而非绝对的优劣之分。
就翻墙协议的应用场景而言，其承载的上层流量几乎皆为TLS流量，本身已具备强加密属性，唯一可能泄露的仅为SNI（服务器名称指示）。并且，若企图通过共享密码进行解密，攻击者不仅需要掌握密码，还必须具备截获加密流量的能力。在现实中，能同时满足这两个条件的，几乎只有机场主本人，或者是机场主受意。笔者认为，若机场主意欲监控，直接在服务器端进行抓包岂不更为便捷？何必采取这种本末倒置的嗅探手段？
针对这一问题，RPRX曾提出过一个更为荒谬的假设：未来相关部门将在所有人的手机上预装CA证书，因此一旦代理协议的流量被破解，通信明文便会被完全解密。且不论这种假设何等脱离现实，亦暂且不提关键应用通常配有SSL Pinning（证书锁定）机制进行防护；笔者认为，RPRX显然忽略了一个基础常识：中间人攻击（MITM）的前提是必须完成流量劫持。即便拥有CA证书，也绝非仅凭旁路嗅探便可实现解密，这正是其被称为“中间人”的原因。若真要实施此类解密，必须依赖机场主配合，将流量重定向至中间人服务器。然而，一旦流量到达代理服务器出口，这一切便与所谓“高级”的R代理协议毫无关联了，这对业内人士来说，属于常识性错误。
笔者认为，即便用户确实追求更为全面的安全性，理性的选择也应当是使用基于标准TLS的加密协议，例如Trojan、MASQUE、Hysteria2等等。这些皆是优秀的协议，其设计理念简单、优雅且高效。反观RPRX，其在对TLS进行非标准化改造时的表现，纯属对自身技术实力的误判。更为恶劣的是，无论这是出于专业知识匮乏导致的无意之失，还是出于某种不可告人的恶意，RPRX通过夸大其他协议的缺陷，虚构叙事的方式，成功制造了用户的恐慌情绪，进而迫使他们迁移至R协议。
探讨完安全性，笔者再来剖析其隐蔽性。R协议在宣传中强调的一个重要特性是，可以通过“借用”知名网站的证书，来避免因个人小众证书被作为特征而遭到封锁。对此，笔者的评价是“欲盖弥彰”。除非网络审查真正进入全面白名单时代，否则GFW极小概率会仅凭证书的发证信息作为判定标准；相反，使用的证书信息与实际IP地址不匹配，反而极易构成一项重大的判定特征。
此外，RPRX一直宣称传统的TLS代理协议（如Trojan）存在“TLS in TLS”的流量特征问题，并标榜R协议解决了这一痛点。然而在笔者看来，TLS in TLS的流量特征非常微弱，几乎无法作为单一的判别依据，至多只能作为复杂流量模型中的一个次要维度。并没有任何事实数据可以证明该特征有被 GFW 所利用。（笔者曾与业内某服务商交流，他们在灰度测试部分R协议线路后发现，其被封锁的概率与Trojan并无实质性区别）。
R协议为解决这些所谓的“痛点”，提出了一套双栈TLS架构：若客户端未能通过验证，便将流量回落至目标网站，以此抵御针对服务端的探测。RPRX对自己的这套架构极其自负。笔者让AI对其用词进行统计，RPRX曾使用过诸如“划时代”、“终极协议”、“THE FUTURE”等极度浮夸的词汇来修饰他的R协议。
然则事实究竟如何？笔者通过研究证实，正是由于R协议架构自身的缺陷，它将原本传统TLS代理协议中微弱的特征，直接转化为了极其明确的强特征。审查系统完全可以做到100%准确的探测与封锁，此等结果，实在令人啼笑皆非。
笔者认为，倘若仅仅是一个开源项目的技术实现存在瑕疵，本不足以招致严厉指责。真正的症结在于，RPRX常年来不遗余力地推广其R协议，行事刚愎自用、好大喜功。他习惯于凭空捏造一个伪命题再假意提出解决方案；通过不断贬损其他协议与同侪，强行将一个二流产物推上神坛，借此满足其个人的“救世主情结”。他试图营造一种错觉：仿佛离开了R协议，公众便彻底丧失了突破信息封锁的能力。实质上，他是将全体用户都无情地裹挟为其个人表演与操控游戏（play）中的一环。
（笔者补充一句，此类行径并非全无先例。十年前，一款名为ShadowsocksR的协议亦采用过如出一辙的运作套路。）
此外，RPRX似乎已不再满足于单纯的虚荣心作祟，甚至开始涉足发行代币与NFT，接受来自VPN厂商的赞助并发布广告，进行流量变现。
而这一切的代价是什么？本就十分脆弱的翻墙协议开源社区，被其一人搅得乌烟瘴气，导致诸多优秀的开源项目维护者心灰意冷，黯然离场。真正具备技术实力与责任心的开发者逐渐疏远，最终只留他一人在社区内肆意妄言。
鉴于此，笔者认为必须有人挺身而出揭露这一乱象。而最为直接、最具威慑力的方式，莫过于抛出能够以100%准确率检测R协议的方法，以此彻底击碎RPRX的狂妄与谎言。
出于对该漏洞潜在影响面的审慎评估，同时本着给予RPRX纠正自身错误之机会的原则，笔者在此定下期限：若RPRX能在三日之内，公开向开源社区致歉，并正式撤回其过往发表的不负责任之言论，笔者将按照标准的漏洞披露流程，通过私密渠道向其提交该漏洞的技术细节，以确保该漏洞在被恶意利用前能够得到修复更新，之后再酌情进行公开。
倘若三日届满，笔者仍未看到RPRX诚恳的公开致歉，笔者将于此repo中公开发布实装该漏洞探测逻辑的 PoC 代码。经笔者实测，若将该程序部署于路由设备或旁路网络节点，仅需耗时不足一分钟，即可精准识别出R协议代理流量，并一并提取出用户端及服务端的IP地址。
俗语云：“欲戴王冠，必承其重。”RPRX在过去数年间，以近乎强迫的姿态推销其R协议，甚至对未能采用该协议的机场或客户端进行恶毒的口诛笔伐。对此，笔者不禁要试问一句：如今正是由于R协议存在此等致命漏洞，导致所有使用该协议的翻墙用户及服务商面临被精准定位的巨大风险，这份沉重的后果与责任，究竟该由谁来承担？
因此，这三日的窗口期，同样也是笔者留给现存R协议用户的缓冲时间，强烈建议各位尽快迁移至其他协议。
截止时间：UTC+8 2026年5月11日 15:00
笔者预见到本文必然会引发大量质疑，故在此先行拟定FAQ，以避免后续的重复性回应：
问：目前有众多用户使用R协议且未遇阻碍，笔者凭何断言其存在问题？若缺陷如此严重，为何未被全面封锁？
答：笔者认为，这属于典型的“幸存者偏差”。GFW在应对TLS类翻墙协议时，本就采用非单一特征的综合检测模型。尽管目前R协议尚可使用，但诸如Trojan等其他基于TLS的协议同样运转正常，二者并无区别。至于审查系统为何尚未对R协议实施针对性封杀，笔者的推测是“缺乏必要性”。既然现阶段TLS类代理协议整体难以被彻底封锁，单独封杀R协议的最终结果，仅仅是迫使这部分用户迁移至其他TLS协议罢了，此举对GFW而言缺乏实际意义。 此外，笔者亦不妨效仿RPRX惯用的“阴谋论”逻辑给出一个推测：审查系统在R协议存在如此显著漏洞的情况下，仍未对其予以直接阻断，极可能是一种蜜罐策略。与其贸然阻断导致用户转向其他更难探测的协议，倒不如予以纵容——因为保留这种带有明确特征的流量，反而更有利于精准定位翻墙行为的具体实施者。
问：笔者公开漏洞的行为，是否等同于“向GFW递刀子”？若导致大众无法翻墙，此后果笔者是否愿意承担？
答：笔者需要在此厘清一个逻辑：广大网民是否具备翻墙能力，与R协议的存废毫无关联。自始至终，社区内皆有大量可靠的替代协议可供选择，R协议不过是在浑水摸鱼。如前文所述，对于整个开源社区而言，清除RPRX这种破坏生态的“毒瘤”，才是当前最为重要的议题。这正是笔者决定披露漏洞并撰写此文的根本动因。 同时，鉴于该漏洞的触发机制被笔者发现得如此轻易，笔者有理由推测：针对该漏洞或同类缺陷的探测利用，在实网环境中有可能早已存在，仅仅是尚未被公之于众罢了。单从这一技术视角的考量而言，笔者选择公开漏洞并全面解构R协议所谓的隐蔽性，其对社区的保护价值是利大于弊的。
问：既然仅为单一漏洞，进行修补即可，笔者为何将其渲染为R协议的末日？
答：笔者指出，该漏洞以铁一般的事实证明，R协议绝非如RPRX所吹嘘的那般“无懈可击”。更为严峻的区别在于：其他主流翻墙协议，审查系统往往只能基于流量模型或部分统计特征，以一定的概率性进行“猜测与封锁”；然而，R协议却能够被100%精确探测。这不再是模糊的概率封锁，而是对翻墙者行为的直接、明确的暴露。由此可见，该协议的底层缺陷已达到何等灾难性的程度，自是不言而喻。
问：笔者采取直接公开漏洞这种“核打击”式手段是否具有正当性？众多使用R协议的用户仅为被蒙蔽的无辜小白，该如何考量？
答：笔者确实曾对该问题进行过审慎考量。然而，笔者目睹RPRX在社区内肆无忌惮地行事已达数年之久。除了采取此种手段，直接在小白群体面前彻底摧毁其技术公信力之外，笔者实未寻得其他反制方案。（当年SSR作者遭遇身份曝光导致退网是另一种维度的反制，但笔者认为此举已然过火。）
问：笔者究竟是谁？为何不放弃匿名，以真实身份示人？
答： 对翻墙社区发展脉络较为了解的朋友应当清楚，绝大多数早期开发者基本都是以实名状态参与互联网活动的。其原因可以理解：长期维持一个严密的匿名身份需要极高的成本。突破审查的初衷本是为了追求真实，若因此反被逼迫戴上面具，实属无奈。加之许多开发者初创项目时仅凭一时兴起，并未深谋远虑，待到意识到需要匿名保护时往往为时已晚。
然而，RPRX却自始至终保持匿名，且行事风格极为高调、极具攻击性。其最擅长的手段便是撰写大篇幅的批判文章（其行文中大量使用的加粗字体，实质上已沦为网络时代的“大字报”，是打着翻墙旗号的党同伐异）。反观其他采取实名活动的开发者，因深知项目存在法律风险，往往不愿声张。在面对冲突时，他们多选择退让或直接退出圈子。这种理性的退避，反而显得RPRX仿佛“取得了胜利”，实则不过是他人不愿与其作无谓计较罢了。
综上所述，笔者认为RPRX的种种行径，若非出于极度愚昧，便是包藏极大恶意。这一幕与当年ShadowsocksR的作者如出一辙：在外部环境最为敏感的时期，大肆攻击SS协议及作者，从而引发海量关注，直接或间接导致SS作者被有关部门约谈（喝茶）。而在其自身真实身份面临暴露风险时，ShadowsocksR作者立刻光速注销账号，销声匿迹。
因此，关于“笔者是谁”这个问题，笔者的答复是：待到什么时候RPRX敢于以实名状态面对公众了，阁下再来诘问笔者不迟。
最后，笔者重申，笔者的唯一目的，便是清除如RPRX这般扰乱社区生态的破坏者。当然，笔者已为其预留了悔过的机会。至于他是选择继续冥顽不灵，还是能够痛定思痛、改过自新，全凭其自身决断。
笔者呼吁，请将各位的赞美与祝福，留给社区中那些真正默默无闻、无私奉献的技术开发者们，而非参与到这种充满个人崇拜的闹剧之中。