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 将更上一层楼。

Xray-core v1.4.3

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

Topic

这是一个 xray 的阶段性维护版本.

- 非常感谢 xray 诞生以来各位贡献者的支持和付出, 以及关心和使用 xray 的各位.
- 合并了一系列 PR 以增强性能 / 增强稳定性 / 修复bug等.
- go1.17 已经发布, 参见此处[Go 1.17 Release Notes](https://golang.org/doc/go1.17)
- 更新了依赖, 解决各种不支持 go1.17 的问题.
- 发布使用 go1.17 编译. 提升安全性以及性能.(按 go 官方说法, go1.17 的编译器可能带来约 5% 的性能提升)
- xray 会一直维护和更新下去. @RPRX Helden sterben nicht !
- 再次感谢各位贡献者.

Features

[新的 DomainMatcher](https://github.com/XTLS/Xray-core/pull/348)

- 速度更快占用更小的 DomainMatcher
- 默认开启, 如果需要使用原 DomainMatcher, 请在每条使用了 domain 的路由规则里, 添加 "domainMatcher": "linear"
- 如果设置为 "domainMatcher": "hybrid", 则是指定使用新的 DomainMatcher. (等同于默认)
- 感谢 @AkinoKaede @darsvador

Enhances

[health check for h2 & gRPC](https://github.com/XTLS/Xray-core/pull/633)
- 为 gRPC 与 h2 开启了健康检查, 当健康检查失败后，gRPC/h2 将会重新打开一个新的底层连接。
- 此功能默认不启用, 如需要启用, 相关配置请[点击此处](https://github.com/XTLS/Xray-core/pull/633#issuecomment-878989087)
- 感谢 @hmol233

[reject unknown SNI](https://github.com/XTLS/Xray-core/pull/553)
- 在 tlsSettings 或 xtlsSettings 中配置 "rejectUnknownSni": true 以开启
- 感谢 @hmol233 @AkinoKaede

[Check buffer before releasing and reusing](https://github.com/XTLS/Xray-core/pull/599)
- 感谢 @hmol233

[gRPC: Use PathEscape encoded service name](https://github.com/XTLS/Xray-core/pull/618)
- 感谢 @hmol233

Fixes

- [fix grpc dial ipv6 address](https://github.com/XTLS/Xray-core/pull/476) @lucifer9
- [fix QUIC disconnecting issue](https://github.com/XTLS/Xray-core/pull/475) @bhoppi
- [fix new cert issuing is incorrectly delayed](https://github.com/XTLS/Xray-core/pull/589) @bhoppi
1. 修复[自签CA证书签发的域名证书有效时间不连续](https://github.com/v2fly/v2ray-core/issues/997)
2. 修复bug的同时，将生成证书的提前时间从1分钟增加为2分钟。为的是在VMess协议允许的C/S两端时间误差（90s）内，保证生成的证书依旧可用
3. 在生成证书和丢弃证书时，输出相应日志信息，便于排查相关问题

- [Move DomainStrategy & DialerProxy to DialSystem](https://github.com/XTLS/Xray-core/pull/609) @hmol233
- fix https://github.com/XTLS/Xray-core/issues/608
- [Fix cannot disable ReadV](https://github.com/XTLS/Xray-core/pull/669) @AkinoKaede
- updated dependencies to Golang 1.17 and upgraded various internal workflows to better utilize its modern features.

Chores

- Use Go 1.17
- Update geoip.dat, geosite.dat

Notice

- Compilation requires Go 1.17+
- 自 Go v1.17 后, (X)TLS 设置中的 cipherSuites, 只指定启用哪些加密套件, 而不能决定顺序, 顺序由 go 根据硬件自动择优选择
- 同样的, 自 Go v1.17 后, (X)TLS 设置中的 preferServerCipherSuites 也已被弃用.
- 某些版本,比如android-arm64-v8a, 可能会有问题
1. 原因出在上游. 也即go本身的原因, go目前版本有 bug 导致交叉编译可能产生问题, 参见 https://github.com/golang/go/issues/47760.
2. go 已经在 https://github.com/golang/go/commit/47a57bc4f0c6a2b7ac12d4eed4ce305446654459 修复, 但还没 release 新版本. (需要等go release 新版本后重新编译一遍)
3. 目前暂时的方式是可以使用 linux 的对应版本

Xray-core v1.4.3 已用 Go v1.17.1 重新编译并发布

下载地址不变
https://github.com/XTLS/Xray-core/releases/tag/v1.4.3

本次重新编译发布仅为了解决 Go v1.17 的 bug 引起的交叉编译问题,无其他任何变化

Go 已发布 v1.17.1, 理论上解决了交叉编译可能产生的问题

- Go v1.17 编译时, 某些版本,比如android-arm64-v8a, 可能会有问题导致无法运行
1. 原因出在上游. 也即go本身的原因, go目前版本有 bug 导致交叉编译可能产生问题, 参见 https://github.com/golang/go/issues/47760.
2. go 已经在 https://github.com/golang/go/commit/47a57bc4f0c6a2b7ac12d4eed4ce305446654459 修复,
3. 之前暂时的方式是可以使用 linux 的对应版本

已重新用 Go v1.17.1 重新编译并发布.

如果您在 Xray v1.4.3 最初发布时下载对应版本出现无法运行问题的, 可重新下载对应版本并尝试运行.
如果您在 Xray v1.4.3 最初发布时下载版本运行后无问题的, 则可以无需关心.

PS: 运行 xray version 您可以看到编译所使用的 Go 的版本号

Project X 的文档站已切换至 更加丝滑的大H 的docs-next版本. 浏览体验更好!
访问网址不变, 仍然是

https://xtls.github.io/

文档仓库URL: https://github.com/XTLS/Xray-docs-next
文档将会不断的继续新增,完善和补全(包括原来文档站搬运中遗漏部分及翻译等).
感谢大家以往对文档站的翻译, 完善 , 纠错等等各种添砖加瓦, 欢迎继续PR和提issue.