https://xtls.github.io/config/outbounds/vless.html

VLESS 后量子加密的文档已更新，各出站的文档只留新版“简化配置”

VLESS 反向代理的文档也在上面，只需加个 reverse tag，非常简单

不行了真的不行了，太典了，国内企业说的话建议大家一个字都不要信，我真的每次都想到张小龙说微信不留存聊天记录，然而国内法规定至少留存日志六个月，可笑吗，是是是你微信有那么万分之一的概率不留存，那你同步给国安那份呢？毕竟微信不留存不等于国安不留存是吧，搁这儿玩文字游戏呢

没有别的意思，我只是就是很讨厌说谎话的人，是什么就说什么不行吗，天天搁这儿骗人有意思吗，更搞笑的是但凡做技术的没有一个不懂这些潜规则，然而大家在国内平台有见过任何相关质疑吗，你敢发就敢封你号，别不识好歹，你要是真不留存就 p2p 加密，然而国内不允许这种东西，笑死我了哈哈哈

说实话我觉得国内最缺乏的东西就是听证会，无需多言懂的都懂

前段时间听说有几个中转机场上 VLESS Encryption 了，是哪些机场

为了推动客户端配置安全、前向安全在中转机场的普及，从今天起，使用 VLESS Encryption 的中转机场可以在这条消息的评论区打广告，但没入群的会被 bot 删，别刷屏就行

偶然又看到某自研协议的商业面板说 Vision 传输 TLSv1.3 与 h2 的流量特征差异巨大，唉“真是没救了”，你都知道它是拼接了，流量特征不同的唯一的可能就是你抓的两个流量本身就不同，说到流量特征，正常使用浏览器和 APP 的分布比例本身也符合自然比例，拓展一下，如果说不同网站什么的流量特征不同，解法一是 REALITY 用 ECH 的域名二是加钱多搞些 IPv6

总而言之，XTLS 这种是在不 MITM 的情况下的最优解，虽然也有缺点，但其它方案你再 padding 再整形肯定都有差异，即使哪天真弄个整形成完全一样那就会用户体验很差，没有银弹，话说回来该自研协议不是觉得自己很牛逼吗，不如把原理发出来让大家分析下？不会是就靠个闭源+小众导致 GFW 不会针对吧？笑死人了

总之就是你想推广自己的商业面板无可厚非，但你闭源的情况下靠踩 GFW 能看得到源码并且被广泛使用的协议来推广就很搞笑了，真按你说的“直连机场全别开了”那哪还会有那么多直连机场用 VLESS 活得好好的？还是说都得用那些偷个客户端配置就能把以前的流量全解密的 SS？

有些感慨，回顾历史：
https://news.1rj.ru/str/projectXtls/147
https://news.1rj.ru/str/projectXtls/948

两年前发这个消息的背景是 REALITY 刚出，但看到很多小白弄个中转什么的纯靠贿赂低级监管部门的某些人来存活的线路就洋洋自得，并且有否定开发者们对于直连协议的努力的意思，“不如中转”什么的，就很抽象，我刚发现正好两年后就给你大规模通报了日期都一样，难道

换来换去的不麻烦吗，总之该有的东西 Xray-core 迟早都会有，VLESS 也会成为全能协议，认准一个就行了，看你们天天搞那些玩具就想笑

搞这个极简反向代理的主要起因是 VLESS 入站改成 dispatchLink() 时旧的反向代理炸了，修的时候简化配置以及加上传递真实 IP、端口就是顺手的事，只是太新了所以 GUI 还没跟上，我是觉得完全可以取代 frp 等传统的内网穿透软件，也就差个打洞吧，但问题一是 IPv6 普及了二是 UDP 体验极不稳定三是最近又兴起了跨网、跨省 QoS，所以似乎也不差啥，之前都说了如果有还要改进的地方可以提建议但也没人提啥，所以

笑点解析：SS

讲真为什么我不热衷于研究 GFW RST 什么的，因为我觉得很没用，我想说这句话很久了，GFW 大致流程是什么样的猜都能猜到，内部文件泄露出来都跟我以前说的对应上了，也就起个实锤的作用没啥新东西，还有光纤分光什么的，任何人来都会这么设计啊，而有的人觉得研究 GFW 才算对抗 GFW，想笑，天天做亡羊也不补牢的事情更别说预防

https://github.com/XTLS/BBS/issues/1

上次有人问 GitHub issue id 怎么还能重置，原因是此 BBS 非彼 bbs，有人在这里发的帖我可以发一下频道，BBS 的讨论也会被转发至群内，毕竟 tg 的 GitHub BOT 不支持 discussions

另外就是 Project X Channel 的消息目前仅限群成员讨论，主要是为了防止广告机，风扇写了个 BOT 会自动删掉群外消息，好久没见广告了

💬 New comment on BBS#2 根据“2025年第五届全国刑事技术技能比武个人赛题目”分析为什么不应该使用 Shadowsocks、VMess 等不具有“客户端配置安全”的加密方式
by @RPRX

十一月第一天，一些思考

说实话推广 VLESS Encryption 比 Vision+REALITY 难一些，因为前者主要适用于中转机场，而大多数机场遵循“能用就行”，不少还死磕着 Shadowsocks AEAD 呢，~~虽然前段时间的大规模通报导致中转少了很多~~，况且 Vision+REALITY 现在在自建、机场直连中的流行也不是推广出来的，~~毕竟我们写完就没怎么管了就没推广~~，而是 GFW 用 TLS in TLS 检测加部分省市 SNI 白名单倒逼出来的结果

但也不是毫无办法，比如去年强推面板们禁止公网明文 HTTP 就取得了不错的效果，大量面板跟进了且新出现的面板基本上默认就是如此，YouTube 上面的教程现在也是以 SSH 端口转发为主，**至今客观上已经防止了无数的私钥、密码被直接泄露给 GFW**

~~不过我不确定大机场用的面板是否还是公网明文 HTTP，如果是的话那对于 SS 这种来说更是直接被解密，又一言难尽了属于是~~

所以在中转机场中推广 VLESS Encryption 是需要主动进行的，比如前几天那条频道消息允许使用了 VLESS Encryption 的机场在下面打广告就是一次尝试，~~虽然风扇写了个 BOT 把群外消息删了~~，还有 Mihomo 支持 VLESS Encryption 挺适合机场的，但是是否应该支持 XHTTP 说实话我不确定，因为它还有个身份是“避难协议”，但在 CDN 看来特征明显，如果机场上了 XHTTP 那只会加速封禁

Anyway，在 GFW 早已转向“监控为主，封锁为辅”的今天，很多人的意识还没有转过来，这确实是一个需要上点狠手段来解决的问题

Reply to this message to post a comment on GitHub.

少就不用呗，少一个用晚一天封，在 Xray 群里不想着用 Xray，来说一句客户端太少了，是不是贱，甚至 iOS 原生的都有小火箭你又不用

本来 Xray 出的协议其它软件就没有义务去支持，有些人就天天想着 NTR 让其它软件支持 Xray 的协议然后去用其它软件，那有没有一种可能 Xray 出的有些功能压根就没指望别的软件支持，才能形成 Xray 独有的优势，不然其它软件把它们全兼容完了那谁还用 Xray

反正我一向是该出什么就出什么，做好自己就行，其它软件是兼容是死活我都无所谓，如果你看了 Xray 的历史发展和未来计划就会知道该有的都会有，只是优先级先后而已，不该有的反正我是不会写，不然天天整些没用的浪费时间精力，就像有些人天天换来换去的也没换出个所以然，有这时间精力去做其它事不香吗

第一步是 VLESS 成为全能协议，第二步是 Xray 补上其它功能以及部分重构，一年后你就只需要它俩了，现在要不要再去浪费时间自己掂量

它真非常重要的话不用你们催就早上了，四年前就有人给 Xray 写了，但你觉得 XHTTP 更重要还是 tun 更重要？tun 可有可无的，但没有 XHTTP 遇到伊朗那十几天你就废了

tun 本来就在计划内啊，优先级排后而已，到底看了计划没

https://news.1rj.ru/str/projectXtls/1067

很多 end user 就觉得比我更懂什么更重要，都给 end user 懂完了

我选择花一个月去写 VLESS Encryption 都没去写 tun，哪个更重要还用说吗，tun 这种东西本来就是有了的话用户能立马换软件，迟一些无所谓，相比起来土制抗量子协议的首创重要百倍，普及也是需要时间

顺便再提一下 Vision Seed，之前说过 PR 挂了两年都没合的原因之一是想等 GFW 先封锁现有特征，况且 Vision 本身就预留了任意 padding、以及我们推个新版本就能改了默认特征的能力，多说一点就是开放用户配置 padding 没有任何难度，但麻烦的是该从哪个角度入手，因为流量整形有很多角度，大白话就是假如我们先出一套 ABI 然后被 GFW 给针对了那踏马不就废了又要重新弄，所以对于 Seed 这件事现在就是故意的在拖，甚至避开了 uTLS 的 Chrome 指纹问题，除非实在没活干了，我都有点想把 TUN 和 GUI 排 Seed 前面了

本质上这无非是 GFW 封不封 Vision 默认特征的问题，况且它若封我就直接改了推新版本，用户临时切到备用的 XHTTP 也不是不行，甚至能上下行分离让 GFW 难受去，所以在 GFW 还没封默认特征的当下我自然是更关心 GFW 拿到客户端配置能不能把你流量给解密了等问题，这类密码学问题更客观且更紧急，去年批公网明文 HTTP 面板，今年先后出抗量子的 REALITY、VLESS Encryption 就是基于这个逻辑