关于 V2Ray 的配置文件格式，这种青菜萝卜的事情就不要一遍一遍地提了。如果你喜欢另一种格式的配置文件，可以自己写一个转换器，把你心仪的格式转成 protobuf，再传给 V2Ray 即可。如果你创造的格式接受度高的话，官方会考虑纳入 Core 的。

V2Ray 3.2 中移除了对官方服务器的支持，长期以来官方服务器一直遭受攻击而产生高昂的维护费用，停用是不得以而为之。目前官方正在寻找更合适的服务器方案，敬请期待😘

如果你不花一分钟时间看一眼issue模板，我是一秒钟都不会花在你的issue上的。尊重是相互的。

新年新版本，愿Project V成为你手边最没有存在感的工具。祝各位新年快乐，吃好喝好，没有烦心事。顺带提一句，先升级服务器，再升客户端。

关于日常GFW的封锁话题，协议特征就摆在那里你们不去研究，整天讨论IP段、流量过大过小什么的，一点意思也没有。

VMess协议的特征是在目前常见协议中最弱的。即如果你认为VMess具有某个特征，那么在ss/ssr/其它协议中一定存在同样或更强的特征；反之则不然。

“未知大流量”这种玄学就不要再讨论了。100块人民币对你来说是巨款么，一百万对你来说是巨款么，十亿对你巴菲特来说是巨款么？美元对你来说是未知货币么，欧元对你来说是未知货币么，₡对银行来说是未知货币么？形容词仅和你的见识有关，和客观现实无关。

想让V2Ray增加新功能/移植/改善用户体验的方法: 1) 耐心等待 2)捐款，四位数USD起步 3) 自力更生提交PR。具体的更新时间表之前解释了，往上翻翻。

仁者见仁，如果你希望V2Ray停止开发，那么V2Ray已经与你没有关系了。早日退散，且勿扰乱视听。

使用加密货币捐款的金主们，可以事先或事后用邮件联系项目组，用于接收回馈。事后联系需要附带私钥签名，事先只需要描述汇款金额即可。

Q: 在你们需要保持匿名的情况下，为什么会选择这种方式的私下回馈？
A: 这样你们就知道开发人员没有跑路，也没有被喝茶了。

Project V的所有讨论区（包括 Github）不欢迎任何政治相关内容。一旦发了相关内容，要么自裁，要么就等着收机票吧。

随便说几句关于单端口多用户的设计。简单来说这是一个先有鸡还是先有蛋的问题，服务器要知道连进来的是哪个用户，但流量是加密的，要知道用户ID才能进行解密。于是用户ID需要一套额外的沟通机制。

1. 总体性能最优的方案是 TLS 的证书交换机制，除了证书相关的几百个字节之外没有额外的开销，通讯性能也相当好。唯一的问题是证书交换时有明显的握手特征。
2. Shadowsocks 不支持多用户。服务器唯一的兼容做法是尝试使用每一个用户密钥解密流量，在用户量大的时候会影响握手性能。
3. SSR 支持多用户但有一个问题，其对用户ID的加密没有满足密码学的要求。
4. VMess 对于多用户的解决方案是预生成大量的密钥(每秒钟N个，N = AlterID + 1)并缓存哈希后的数据，用空间换时间的方式判断用户ID，并保证ID不会被破解。

Q: 用户ID被破解有什么意义？
A: 由于单个客户端长期使用单个ID(密钥），如果能从流量反推出稳定的ID，那也就间接证明了这些流量都用了某一种协议。

开通了新的捐助方式: https://www.patreon.com/v2ray 😘

TLS的握手过程有一个规律，客户端发出的第一个数据包（称为ClientHello），大约是170字节左右，然后服务器会回复一个数据包（称为ServerHello），大约是70字节左右。之后还有一些交换证书之类的流程，数据包的大小都是有规律的。参考: http://netsekure.org/2010/03/tls-overhead/

尽管加密之后，这几个数据包的内容无法被破解，但它们的长度规律是不会变的。这就成为了一个特征。至于这个特征会不会被墙利用，我们不得而知，当然他们也不会明说。于是为了防范于未然，V2Ray 3.31 中加入了一个实验性功能。

开启方式，在启动 V2Ray 客户端之前设置环境变量 V2RAY_VMESS_PADDING=1 。服务器端自适应，即可以同时接收不同设定的客户端发来的数据。

它的作用是在每一个 VMess 数据包的结尾都添加若干个随机字符，以干扰第三方对于数据包长度的判断。这一功能对连接的吞吐量几乎没有影响（< 3%）。

另外，还可以开启 Mux 把数据包的特征减到最小。

请不要质疑更新日志中的日期问题，开发团队的一个超能力就是预测下一版本的新功能。

主repo求一波star: https://github.com/v2ray/v2ray-core

为了减轻主repo的issue压力，新开了一个repo用于常规讨论，所有非直接的代码问题，都会被移到这里。https://github.com/v2ray/discussion

解释一些有关UDP的误解：
1. VMess协议只使用TCP协议，服务器端只需要开放TCP端口即可。（用mKCP的话另说）
2. VMess协议可以承载UDP流量，即所谓的UDP over TCP。
3. 即使用了VMess/mKCP也是流式转发，不是包式转发。（差异请自己学习网络基础知识）
4. 推荐使用Mux/VMess以达到最优的转发效率。
5. UDP数据的转发效率见人见智，可能没有专业的游戏加速器来得好，毕竟人家是专业的。V2Ray也不是为了游戏而生。

Q: 为什么要UDP over TCP?
A: 1) 这样UDP流量也可以使用WebSocket之类的伪装；2) 同端口的TCP和UDP流量，在日常使用中不常见。