V2Ray 4.7新增了Quic传输方式。基于IETF QUIC标准实现，目前处于测试阶段。初步的实验表明Quic有效减少连接握手的延迟，网页加载速度有明显提升。但传输速度上限，尤其是在丢包率较高的环境下，相比KCP或TCP没有优势。
Читать полностью…
V2Ray的常规更新时间是每周五，通常包含新功能或者累积小bug修复; 在非常规时段的更新，通常只包含重要的bug修复。
Читать полностью…
V2Ray Core目前支持的分发源有：Snapcraft (https://snapcraft.io/v2ray-core), Homebrew (https://github.com/v2ray/homebrew-v2ray), Archlinux (https://www.archlinux.org/packages/community/x86_64/v2ray/, Docker (https://hub.docker.com/r/v2ray/official/)。如果你正在维护一个分发源，请私下联系开发人员。同时衷心感谢所有分发源的维护者。
Читать полностью…
Q: V2Ray 什么时候会支持 TLS 1.3?
A: 等 Golang 支持，乐观估计 Go 1.12 会支持 TLS 1.3。见 https://github.com/golang/go/issues/9671
V2Ray 3.37开始将使用Go 1.11编译。自行编译V2Ray的同学请及时升级编译环境，以免出现各种奇怪的错误。
Читать полностью…
Q: 为什么要UDP over TCP?
A: 1) 这样UDP流量也可以使用WebSocket之类的伪装；2) 同端口的TCP和UDP流量，在日常使用中不常见。
为了减轻主repo的issue压力，新开了一个repo用于常规讨论，所有非直接的代码问题，都会被移到这里。https://github.com/v2ray/discussion
Читать полностью…
请不要质疑更新日志中的日期问题，开发团队的一个超能力就是预测下一版本的新功能。
Читать полностью…
开通了新的捐助方式: https://www.patreon.com/v2ray 😘
Читать полностью…
Project V的所有讨论区（包括 Github）不欢迎任何政治相关内容。一旦发了相关内容，要么自裁，要么就等着收机票吧。
Читать полностью…
使用加密货币捐款的金主们，可以事先或事后用邮件联系项目组，用于接收回馈。事后联系需要附带私钥签名，事先只需要描述汇款金额即可。
Читать полностью…
想让V2Ray增加新功能/移植/改善用户体验的方法: 1) 耐心等待 2)捐款，四位数USD起步 3) 自力更生提交PR。具体的更新时间表之前解释了，往上翻翻。
Читать полностью…
V2Ray的兼容性保证
* 配置文件向后兼容至少一个大版本，即 V2Ray 4.x 可以正常加载 3.x 的配置文件。
* 所有基于 Protobuf 的通信协议，如 Api，向后兼容至少一个大版本。
* 所有基于二进制的通信协议，如 Shadowsocks 和 VMess。当服务器版本不低于客户端版本时，保持永久兼容；当客户端版本超过服务器版本时，保持至少 12 个小版本的兼容性。
https://v2ray.com/chapter_00/faq.html#backward-compatibility
V2Ray 的部分功能并不是设计来使用的。在看到一个配置项的时候，请先想一下它有什么用，开启之后有什么好处，不开启有什么坏处，而不是盲目尝鲜。最基本的VMess/TCP在大多数场景下已经够用了。
Читать полностью…
经过了过去的几个版本中的大量优化，V2Ray的内存使用已大幅减少，可适用于各种设备。特别是在低端设备(MIPS/ARM)上有更为严格的默认设置，比X86/X64上的用量更少。
Читать полностью…
由酒店脱库事件想到的：虽然Shadowsocks和V2Ray都是代理工具，但也具备了一些VPN的特性。比如用户可以强制中转127.0.0.1的流量，把服务器当成内网。复杂一点的做法是把一个域名解析为内网IP，从而绕过一些基于IP的防御机制。所以，所有不能实时解析DNS并拦截内网请求的代理工具，都是有安全隐患的。在选择代理工具时，请仔细查阅其文档或源代码。当然，V2Ray的出厂设置(Linux)，就已经包含了上述的拦截。
Читать полностью…
V2Ray 3.36的路由规则中，域名匹配的性能获得了巨大提升。请按以下优先级选择匹配方式: 完整匹配(full) > 子域名匹配(domain) > 字符串匹配 > 正则表达式匹配(regex)。前三种对应的Surge规则分别是DOMAIN, DOMAIN-SUFFIX和DOMAIN-KEYWORD，Surge似乎不支持正则表达式。
Читать полностью…
解释一些有关UDP的误解：
1. VMess协议只使用TCP协议，服务器端只需要开放TCP端口即可。（用mKCP的话另说）
2. VMess协议可以承载UDP流量，即所谓的UDP over TCP。
3. 即使用了VMess/mKCP也是流式转发，不是包式转发。（差异请自己学习网络基础知识）
4. 推荐使用Mux/VMess以达到最优的转发效率。
5. UDP数据的转发效率见人见智，可能没有专业的游戏加速器来得好，毕竟人家是专业的。V2Ray也不是为了游戏而生。
主repo求一波star: https://github.com/v2ray/v2ray-core
Читать полностью…
TLS的握手过程有一个规律，客户端发出的第一个数据包（称为ClientHello），大约是170字节左右，然后服务器会回复一个数据包（称为ServerHello），大约是70字节左右。之后还有一些交换证书之类的流程，数据包的大小都是有规律的。参考: http://netsekure.org/2010/03/tls-overhead/
尽管加密之后，这几个数据包的内容无法被破解，但它们的长度规律是不会变的。这就成为了一个特征。至于这个特征会不会被墙利用，我们不得而知，当然他们也不会明说。于是为了防范于未然，V2Ray 3.31 中加入了一个实验性功能。
开启方式，在启动 V2Ray 客户端之前设置环境变量 V2RAY_VMESS_PADDING=1 。服务器端自适应，即可以同时接收不同设定的客户端发来的数据。
它的作用是在每一个 VMess 数据包的结尾都添加若干个随机字符，以干扰第三方对于数据包长度的判断。这一功能对连接的吞吐量几乎没有影响（< 3%）。
另外，还可以开启 Mux 把数据包的特征减到最小。
随便说几句关于单端口多用户的设计。简单来说这是一个先有鸡还是先有蛋的问题，服务器要知道连进来的是哪个用户，但流量是加密的，要知道用户ID才能进行解密。于是用户ID需要一套额外的沟通机制。
1. 总体性能最优的方案是 TLS 的证书交换机制，除了证书相关的几百个字节之外没有额外的开销，通讯性能也相当好。唯一的问题是证书交换时有明显的握手特征。
2. Shadowsocks 不支持多用户。服务器唯一的兼容做法是尝试使用每一个用户密钥解密流量，在用户量大的时候会影响握手性能。
3. SSR 支持多用户但有一个问题，其对用户ID的加密没有满足密码学的要求。
4. VMess 对于多用户的解决方案是预生成大量的密钥(每秒钟N个，N = AlterID + 1)并缓存哈希后的数据，用空间换时间的方式判断用户ID，并保证ID不会被破解。
Q: 用户ID被破解有什么意义？
A: 由于单个客户端长期使用单个ID(密钥），如果能从流量反推出稳定的ID，那也就间接证明了这些流量都用了某一种协议。
Q: 在你们需要保持匿名的情况下，为什么会选择这种方式的私下回馈？
A: 这样你们就知道开发人员没有跑路，也没有被喝茶了。
仁者见仁，如果你希望V2Ray停止开发，那么V2Ray已经与你没有关系了。早日退散，且勿扰乱视听。
Читать полностью…
