2021 年 2 月 19 日新增 xray-plugin v1.3.0 日志：

1. 使用 Xray-core v1.3.0 作为核心；
2. 使用 Go 1.15.8 编译；
3. 用法等同于 v2ray-plugin；
4. 版本号的命名方式沿用 Xray-core。

下载地址详见：
https://github.com/teddysun/xray-plugin/releases

Xray-core is the fastest Shadowsocks AEAD server implementation, with exclusive Single-port Multi-user support, including API.

When using same software at both sides:
- AES-256-GCM: Xray-ss > go-ss2 = ss-rust >> v2ray-ss
- ChaCha20-Poly1305: ss-rust > Xray-ss > go-ss2 >> v2ray-ss

未来，Xray-core 还会精简架构，以进一步提升整体性能。

利用防重放机制自动对 Shadowsocks、VMess 等未知流量代理进行“隐蔽式拒绝服务攻击”

https://github.com/shadowsocks/shadowsocks-org/issues/184

Xray-core v1.3.1

https://github.com/XTLS/Xray-core/releases/tag/v1.3.1

Features

Enable (X)TLS hot reloading by default #281
Add /opt/share/xray/ to assets location @kidonng

Fixes

Fix key derivation function panic in Go 1.16 @rprx
Fix freedom outbound UDP redirect @rprx
Fix context canceled while dialing HTTP/2 @JimhHan
Restrict tags to be unique @JimhHan
Skip closed client being chosen for reverse connection @Xray9
Fix ALPN being set to h2 by default when using TCP transport with (X)TLS @AkinoKaede
Remove useless imports in main/run.go @rprx

Chores

Add GitHub Actions @kokeri @xinb @AkinoKaede @JimhHan
Use Go 1.16.0
Upgrade dependencies

Xray-core v1.4.0

https://github.com/XTLS/Xray-core/releases/tag/v1.4.0

Topic: WebSocket 0-RTT & gRPC Transport，均可用于 CDN

WebSocket 0-RTT

快速上手

1. 客户端、服务端均升至 Xray-core v1.4.0+，注意不需要改服务端的任何配置
2. 只需在客户端的 path 后加上 ?ed=2048 即可减少 1-RTT，2048 代表 early data 的长度上限，目前建议写 2048

比如 path 本来是 /example，则只需改为 /example?ed=2048 - Xray-core WebSocket 0-RTT 整体设计理念

长度上限

1. 取决于整个反代链路均可接受的 header 长度，比如 Nginx 默认 4K，而 Fallbacks 不是反代故没有限制
2. Base64 编码会使数据膨胀 4/3，比如 2048 长度编码后约长 2731，这还不包括 header 中其它部分

所以订阅下发者应确保该值有效，若无特殊需求，2048 即可 - 其实你现在就可以下发带 ?ed=2048 的订阅

gRPC Transport

我们在此版本中引入了对 gRPC Transport 的试验性支持，它的积极意义在于：

1. 能够以 alpn h2, http/1.1 通过 CDN
2. 自带的 mux 可以降低延迟、减少特征

Xray-core 专门对它进行了性能优化，并且支持 multi 模式，详见 gRPC 文档

十分感谢 @DuckSoft @JimhHan @xiaokangwang

Features

Fake DNS

- Add Fake DNS support, and more contribution @yuhan6665
- Use 198.18.0.0/16 as default Fake IP Pool, and more contribution @JimhHan

DNS and Dialer

- Dialer 支持先用内置 DNS 服务器解析出 IP：配置 sockopt 的 domainStrategy @JimhHan
- 支持带传输层链式代理：配置 sockopt 的 dialerProxy @JimhHan
- 增加 DNS 查询日志 @JimhHan
- 修复 DoH 遗留问题 @JimhHan

TCP Fast Open

- Linux Server 支持指定 TCP Fast Open 队列长度 @risetechlab
- "tcpFastOpen": true 的默认队列长度由 1 改为 256

VMess

- Add VMess zero encryption (but still slower than VLESS and Trojan) @AkinoKaede
- You can set XRAY_VMESS_AEAD_FORCED = true at server side @AkinoKaede

Fixes

UDP

- Skip Port 53, 443 before using single XUDP for VLESS & VMess，这项改变带来了更强的兼容性
- Freedom Outbound will use buf.PacketReader when UDPOverride is available（UDP 重定向）

Fallbacks related

- Stop at '?' when reading HTTP PATH before shunting，这是配合 WebSocket 0-RTT 的重要更改
- Do not cause error when json:"fallback" is null @RManLuo

Others

- Fix panic: Header called after Handler finished @JimhHan, Thank @liang-chang
- Fix panic: runtime error: slice bounds out of range [15:14], Thank @rurirei

Chores

- Adjust release.yml @AkinoKaede @JimhHan
- linux-rppc64le -> linux-ppc64le
- Use Go 1.16.2
- Upgrade dependencies

Notices

- 毫无悬念：下个版本会有 uTLS
- 欢迎讨论：想象一下用浏览器中转 WSS、H2、QUIC？现在我们正式发布这一想法 v2ray/discussion#754 (comment)

Xray-core v1.4.2

https://github.com/XTLS/Xray-core/releases/tag/v1.4.2

Topic: TLS Fingerprint

WSS Browser Dialer

在这个版本中，我们推出了意义非凡的 Browser Dialer，你可以轻松地借助任一浏览器改变 WSS 的 TLS 指纹、行为特征：

1. 由真实浏览器建立 WSS 连接，TLS 指纹、行为与真实浏览器完全一致，每个人的浏览器还不尽相同，更利于抗封锁。
2. 通过设置环境变量 XRAY_BROWSER_DIALER 开启此功能，支持 Xray-core 的 early data，详见 Configuration

uTLS fingerprints

如果你希望改变 TLS Client Hello 指纹，但是觉得 Browser Dialer 过于繁琐，可以来试试 uTLS (TCP+TLS)：

1. 通过 uTLS 库 模拟 Chrome / Firefox / Safari 的 TLS 指纹（不含行为），或使用随机生成的指纹。
2. 这也是一项重要的功能，GUI 应提供相应的选项，详见 Configuration

Fixes

uTLS

- 发现在调用 Write 前调用 Read 会导致指纹模拟失效的问题，需要提前调用 Handshake。 @HirbodBehnam

gRPC

- 修复无法获取远程地址的问题。 @maskedeken
- 修复 Multi 模式发送/接收空 Buffer 的问题。 @JimhHan
- 修复同一目标地址只有第一个 TLS 设置生效的问题。 @JimhHan

Commands

- 修复配置文件读取不遵循 format 参数的问题，并将 JSON 作为标准输入的默认配置格式。 @AkinoKaede
- 补全了 xray help tls cert 的说明。 @AkinoKaede

Others

- 修复 DoH 无法被正确路由的问题。 @JimhHan
- 修复在某些入站代理开启嗅探可能导致程序崩溃的问题。 @JimhHan
- 修复 TCP 与 WS 强制覆盖 sockopt 的 acceptProxyProtocol 的问题。 @JimhHan
- 修复 TCP Fast Open 的 AsIs 问题。 @risetechlab

Chore

- Upgrade dependencies

Notice

- Compilation requires Go 1.16+

X-flutter 前瞻

https://github.com/XTLS/X-flutter/issues/1

关于开发者 gcc 在 Qv2ray 代码中下毒的说明

2021.04.27，在本相安无事的情况下，gcc 单方面删除了 Qv2ray 中对 Xray 的支持代码，并且本着对使用者极不负责的态度，添加了“检测到 Xray 就自爆”的恶意代码：

https://github.com/Qv2ray/Qv2ray/commit/c20e3378c397ae2cab09b71042e1b1381d0a8859
https://github.com/Qv2ray/Qv2ray/commit/3959c928621c04d988fd84eac1241bea21b28ab1

公然在代码中下毒，这不是一个开源项目中该发生的事情。联想到之前还有人讨论过担心闭源项目的安全性，现在，到底谁会在代码中下毒，一目了然。
一直以来，我们能感受到，有些人以开源自居，做的却尽是限制、滥权、diss 他人的事情，这是否也是一种假开源？

事实上，对于 Qv2ray 这个客户端，我（RPRX）从一开始写 VLESS 时就一直在力推，把它放到了 VLESS 文档推荐的最上面，还把 v2fly 文档客户端列表的 Qv 从最下面改到了最上面，这些都是大家记忆清晰且有迹可循的。之后创立 Project X 时，我更是亲自对 Qv2ray 进行了 PR，并且同样在项目 README 中推荐了该客户端。
我对 Qv2ray 是问心无愧的，也从来没有主动诋毁过 Qv 或者 gcc，即使此前 gcc 已多次发表对我或 Xray 不友好的言论，且多次承认对我以及 Xray 抱有奇怪的偏见，这些大家都看在眼里。

DuckSoft 认为在代码中下毒是非常过分的行为，推掉了工作来处理这件事。与 gcc 多次协商无果，最后无奈将 gcc 移出 Qv2ray 组织，并清理掉了有问题的代码：

https://github.com/Qv2ray/Qv2ray/commit/ee32372bbf301f6ad273f91fe9f6962e8a26969b

截至目前，Xray 仍然可以在 Qv2ray 中使用。

上个月我没有活跃在这方面的开发，期间我用 flutter 写了另一个跨平台软件，效果良好，并本地修复了一个 flutter 框架的非常影响 Windows 中文用户体验的 BUG，今天已提交 PR 给 flutter 项目：

https://github.com/flutter/flutter/pull/84292

至于移动端，此前我修改了 badvpn tun2socks 的代码，使其可以高效地本地响应 ICMP PING requests (IPv4 & IPv6)：

https://github.com/XTLS/badvpn/commit/c440609ca7fb8b85d83d528526b3f02c1a63376d

这一成果是可视的：

1. 使用较新版本的 v2rayNG 或 SagerNet
2. 打开 termux，ping example.com
3. 可以看到 ping 请求被瞬间响应（以前是无响应）

临近期末，忙于复习，一个月后见。在此感谢坚持维护项目/文档/群组/答疑的朋友们。毫无疑问，Project X 将更上一层楼。