Xray-core v1.1.5

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

Xray-install 有大量更新，请查收！感谢 @kirin10000 的贡献

Xray-core v1.2.0

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

Topic: Shadowsocks & Trojan UDP FullCone NAT，Xray-core 的进化

Background

v2ray 的 UDP 支持存在一些众所周知的问题，旷日持久，以至于大型联机游戏几乎和 v2 系列绝缘。相关 issues 很多，在此就不列举了。

Progress

在过去的两周内，Xray-core 进行了大量的重构与反复测试，终于迈出了一大步：全面 FullCone 化（基本完成）

Xray-core 现支持 Cone 和 Symmetric 两种策略，完美支持 FullCone 的协议有

- Shadowsocks 入站、出站
- Trojan 入站、出站
- Socks 入站、出站
- Dokodemo-door TPROXY 入站（透明代理）
- Freedom 出站，支持域名解析

VLESS、VMess 目前是 Symmetric，出站有其一且无 SS/Trojan 时，Xray-core 将会选择 Symmetric 模式，否则是 Cone 模式。

Usage

1. 首先，确保客户端与服务端均更新至 Xray-core v1.2.0+，或者其它没问题的软件。
2. 注意服务端的防火墙设置（测试时建议关闭），以及客户端不能开 Mux
3. 比如本地 TPROXY/Socks 入 + SS/Trojan + VPS Freedom 出，即可实现 FullCone
4. 解锁更多玩法：TPROXY 入、Socks 出（替代 ip2socks），Socks 入、出分流等。

对于透明代理，尤其 注意本机和网关设备的防火墙，此外 iptables 的 UDP DIVERT 规则 可能 会导致 UDP 表现不符合预期。

Future

我们很高兴地宣布，Xray-core 成为了有史以来第一个不受限制的多协议平台：只需 Xray 即可解决问题，再也不会不得不去用其它实现。

Xray-core 现支持 四大主流代理协议 的 完整可用实现，且同时包含 客户端 与 服务端

- VLESS 的 XTLS
- Trojan 的 UoT FullCone、XTLS
- VMess 的 AEAD
- Shadowsocks 的 UDP FullCone、AEAD

但这远不是终点，Xray 正计划进一步精简架构、优化整体性能、修复历史问题、增强分流功能等（包括客户端与服务端，传统艺能了）

Xray 还计划推出更多 UDP 增强，比如 XUDP（UoT 聚合隧道）、Shadowsocks 的 UDP 原生多倍发包 + 长度混淆新格式，更适合打游戏。
XUDP 可以运行在任何协议上，在它出现之前，对于主用 VLESS/VMess 的朋友，可以让 UDP 走 SS/Trojan（没错，这又是新的玩法）

对于 Shadowsocks，若只用它的原生 UDP，外面看起来就像 mKCP Seed。另外，不建议共享 Shadowsocks，相信你很快会知道原因。

Xray's Documentation

十分感谢 @badO1a5A90 @ricuhkaen 的长期贡献，Xray 的文档已初步上线：https://xtls.github.io

不过目前文档还缺很多东西，最近还会有不少大改动，包括外观、目录结构等，欢迎提任何建议/参与建设：XTLS.github.io (GitHub)

TOML & YAML

十分感谢 @AkinoKaede @yjh1021317464 的贡献，Xray 现已支持 TOML & YAML 配置格式，原理是先转换为 JSON

多文件配置也支持，但注意目前不能混合格式。

OCSP Stapling

十分感谢 @eMeab 的贡献，现在你可以开启服务端 TLS & XTLS 的 OCSP Stapling，再也不用担心 CA 域名被 Q 了。

至于如何配置，请去文档探索一番吧。

Happy New Year 🎉

Xray-core v1.2.1

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

Configuration Detector

Xray-core 现支持 FullCone 和 Symmetric 两种模式，而 VLESS、VMess、Mux 暂不支持 FullCone，需要 Symmetric 模式

所以为了防止 VLESS、VMess、Mux 被应用 FullCone，v1.2.0 开始有一个配置检测机制，说明如下：

1. v1.2.1 开始此机制被移至 core/xray.go 的 initInstanceWithConfig 函数开头，以便在 v2rayNG 上生效 #138 (comment)
2. Xray-core 默认选择 FullCone 模式，除非出站配置有 VLESS/VMess 且无 SS/Trojan，此时是 Symmetric
3. 若出站配置的任一 SS/Trojan 开了 Mux，则一票否决，Xray-core 选择 Symmetric 模式

Optimizations & Fixes

TPROXY

修复 TPROXY 的 UDP/IPv6 伪造，详见 #137 (comment) ，十分感谢 @Ninedyz @changyp6 发现、定位问题

关于 TPROXY UDP 的重要说明：

其它软件 TPROXY FullCone 的实现方式是为每一个返回的 UDP 包创建一个 connected UDP socket，write 一次即销毁
而 Xray-core 的实现方式是创建 unconnected UDP socket，且 writeTo 后不销毁，存进 map 供下次复用
这样做更优雅，理论上也有更好的性能，要求 iptables 没有针对 UDP 的“避免已有连接的包二次通过 TPROXY”规则

（实际上对于其它软件 TPROXY FullCone 的实现方式，这个 UDP 规则似乎也没有用，因为都会进 TPROXY）

UDP Worker

调整入站 UDP Worker 的 GC 策略为“每 60 秒清理一次 300 秒无活动的映射”，影响 Socks、SS、TPROXY，详见 #129 (comment)

之前没有注意到这个机制，调整后 UDP 的整体表现更加稳定了，彩虹六号再也不会掉线了，十分感谢 @GleenJi 等协助测试

Log

根据这个提议 #56 (comment) 增强 access 日志信息 @eMeab #121

现在你可以在 access 日志中看到路由信息了，格式为 [inbound tag -> outbound tag]，注意目前需经过路由才有完整信息

Socks

优化 Socks 代码、智能化 Socks5 的 UDP Associate 回应：

现在 Socks 入站开启 UDP 时无需再额外填本机 IP 了，且可以接受来自任何网口的请求（若配置中额外填了本机 IP，则以它为准）

Trojan

精简 Trojan UDP 的处理代码 @maskedeken #142

修复 Trojan 出站 TCP 行为：一些 TCP 连接是服务端先发数据，现在 Trojan 可以在此场景下正常工作了，详见 #127 (comment)

Chores

- Upgrade dependencies
- Update geoip.dat, geosite.dat

Notices

1. Socks5、Shadowsocks 都是原生 UDP，它们的 UDP 不走底层传输方式
2. VLESS、Trojan、VMess、Mux 都是 UDP over TCP，且走底层传输方式
3. HTTP 出入站不支持代理 UDP，Socks 版本 5 之前也不支持 UDP
4. 这里的 FullCone 指的是 UDP 的 NAT 行为，配置时尤其注意防火墙
5. 链式代理若要实现 FullCone，一般来说所有环节都要支持 FullCone
6. Docker 若要实现 FullCone，相关容器的网络模式需要是 Host

Xray-core v1.2.2

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

VLESS UUID v5 mapping standard

VLESS UUID 映射标准：将自定义字符串映射为一个 UUIDv5

简单来说，和 Trojan、SS 可以自定义密码一样，Xray-core 的 VLESS 和 VMess 也可以自定义 id 了，一些规则见上方链接。

- 若无特殊需求，建议首选全随机的 UUIDv4
- 若选择自定义 id，建议保持一定的复杂度

现在 VLESS、VMess 加载配置时就会检查 id 是否有效，Xray-core 自带的 UUID generator 也得到了增强：

- xray uuid 输出的全随机 UUID 现在遵循 RFC 4122 的 UUIDv4 标准
- xray uuid -i "example" 将会输出 example 的 UUIDv5 映射

VLESS fallbacks SNI shunt

VLESS 的 fallbacks 数组子元素新增 name 配置项（与 alpn 同级），作为 substr 来匹配请求的 SNI，实现 SNI 分流。

- 比如填 example.com 可以匹配 example.com 和 *.example.com
- 若另一个子元素填的是 www.example.com，则有更高的优先级

其它规则不变，Xray-core 将为每一次回落分流匹配到最精确的子元素。感谢 @eMeab 开坑。

Trojan 的 fallbacks 暂不支持此配置。

Optimizations & Fixes

小小白白话文

瓜瓜 @ricuhkaen 的小小白白话文已经完结，广受好评，快去看看吧：https://xtls.github.io/documents/level-0/

DoH

以前 non-local DoH 会走 Mux，第一个 DNS 请求返回后连接就会被关闭，导致同一个连接的其它请求均失败。

@badO1a5A90 解决了此问题，同时对 non-local DoH 应用了适当的路由策略，详见 #147

Log

这个版本进一步增强了 access 日志信息 @eMeab ，目前格式如下：

命中了路由规则：[inbound tag -> outbound tag]
未命中路由规则：[inbound tag >> outbound tag]

Trojan

Do not panic when UDP dispatcher failed to write response @maskedeken #153

Chores

- Upgrade dependencies
- Update geoip.dat, geosite.dat

Notices

- Xray-core 2k stars，再次感谢各位的支持
- Support M1 Chip，记得先 Open Anyway

Xray-core v1.2.3

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

Shadowsocks AEAD Single-port Multi-user

Xray-core v1.2.3 提供了配置便捷、开箱即用的 Shadowsocks AEAD 单端口多用户支持。

https://github.com/XTLS/Xray-examples/tree/main/Shadowsocks-AEAD

1. AEAD 加密方式使接收方能够验证解密是否成功，这是一切的基础
2. 服务端便可以通过尝试解密收到的第一个包来找到对应的用户

以下套件属于 AEAD 加密方式：

- AES-128-GCM
- AES-256-GCM
- ChaCha20-Poly1305 (alias ChaCha20-IETF-Poly1305)

希望推动 AEAD 被更广泛应用：

1. 我们只建议使用 AEAD 加密方式，且后续对 Shadowsocks 的增强只支持 AEAD
2. 老旧加密方式虽然不会被移除，但属于 deprecated，在文档中会做隐藏处理

端口复用有待进一步增强，比如实现同 IP 优先尝试机制、支持 API 动态增删用户等。

推荐一个高性能的 Shadowsocks AEAD 端口复用中转方案：mmp-go

Optimizations

TPROXY

为 FakeUDP socket 设置 SO_REUSEPORT，优化了 TPROXY UDP 的代码与 err 处理逻辑。

Trojan

Trojan fallbacks 也支持匹配请求的 SNI 了，配置方式与 VLESS fallbacks 完全一致，详见 Xray-core v1.2.2

Sniffing

Feature: Exclude some domains in sniffing destOverride (#151) @AkinoKaede

Fixes

Fix fallbacks xver when original address is not TCP address (#182) @bohanyang
Convert domain names to lowercase before matching (#195) @badO1a5A90

Chores

- Regenerate .pb.go files @JimhHan
- Use Go 1.15.7 @Beginner-Go
- Upgrade dependencies
- Update geoip.dat, geosite.dat

Notices

- 已知此版本的 fallbacks xver / acceptProxyProtocol 可能不会生效，Tracker：#182 (comment)
- M1 版本由 Go 1.16beta1 直接编译，Reproducible（2021/1/28：xray-M1 -> xray）

Xray-core v1.2.4

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

Socks

解决两个“连接至标准 Socks 服务端时可能出错”的历史遗留问题：

- 设置 Socks 出站 UDP Associate 请求中的 IP、Port 为空，符合 RFC 1928
- 修正 Socks 出站 Username/Password 认证行为，符合 RFC 1929

Xray-core 不全等于 XTLS，Xray 解决了大量的历史遗留问题、进行了性能等多方面的优化，并且拥有更丰富的功能特性。

Fixes

- Fix acceptProxyProtocol @bohanyang
- Fix OCSP Stapling @eMeab
- Fix tests @JimhHan
- Avoid panic in BytesTo func #193

Chores

- Upgrade dependencies
- Update geoip.dat, geosite.dat

Notices

- v1.2.3 的一个依赖存在问题，补发 v1.2.4，也包含其它更多修复
- M1 版本切换至由 Go 1.16rc1 直接编译，Reproducible

Xray-core 100 commits GET √

本周的更新：进阶必读：代理协议 UDP 全方位透彻解析 #237

九点 v1.3.0 的 release 为错误触发，现已删除，请忽略其 release note，等待下午 v1.3.0 正式 release（昨天的没问题）

预热：XUDP：VLESS & VMess & Mux UDP FullCone NAT #252

Xray-core v1.3.0

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

Topic: VLESS & VMess & Mux UDP FullCone NAT，Xray-core 里程碑

Background

Xray-core v1.2.x 实现并巩固了 FullCone 特性，而 VLESS、VMess、Mux 受制于协议结构，暂时无法实现 FullCone。

Progress

Xray-core v1.3.0 通过非常巧妙的机制实现了 V 系协议全部 FullCone，同时与旧版保持一定的兼容性。

Usage

客户端、服务端均升至 Xray-core v1.3.0+ 即可享受无处不在的 FullCone，软件本身无需任何额外配置，注意：

1. 服务端防火墙需要放行 UDP 高位端口（1024-65535），Docker 容器的网络模式需要是 Host
2. 此时 100% 能实现 FullCone，起作用的是 VPS 的公网 IP，与本地的 NAT 环境无关
3. 客户端 Xray-core v1.3.0+、服务端 v2fly-core 时，会测出假的 FullCone

若你需要关闭 Xray-core 的 FullCone 特性，可在客户端设置环境变量 XRAY_CONE_DISABLED = true

Milestone

至此，Xray-core 实现了全软件全协议全出入站全传输方式的全面 FullCone，这是一个里程碑式的成就：

无论你在用 VLESS/VMess/Mux/Trojan/Shadowsocks，无论你选择 XTLS/KCP/CDN/H2/QUIC，无论 Socks 还是 TPROXY... 全部 FullCone

FullCone 不再是哪个协议的专利，它已经像空气一样自然，随处可见，不留任何遗憾。

Features

Single-port Multi-user API

Xray-core 的 Shadowsocks AEAD 服务端单端口多用户现已支持 API 动态增删用户 @AkinoKaede

至此，Xray-core 的 VLESS、Trojan、VMess、Shadowsocks 入站全部支持端口复用、API。

XTLS & TLS hot reloading

服务端更新 OCSP 数据前自动检查并重载证书及私钥文件 @eMeab

证书、私钥填路径并开启 OCSP Stapling，即可无需在更新上述文件后重启 Xray-core。

Mixed JSON/TOML/YAML

多文件配置现已支持同时读取不同格式的配置文件 @yjh1021317464

Chores

Use Go 1.15.8
Update geoip.dat, geosite.dat

Happy 🐮 Year 🎉

大家给秋大的新项目 xray-plugin 点个 Star（顺便也给 Xray-core 点个 Star，谢谢！）

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 中使用。