这里是 Project X 的频道
Project X 提供 v2ray 的超集 X-ray,含更好的整体性能和 XTLS 等一系列增强,且完全兼容 v2ray-core 的功能及配置。
“配置兼容,整体更好”
补:
简单说就是兼容 core 的配置,且性能更好,功能更多
Project X 提供 v2ray 的超集 X-ray,含更好的整体性能和 XTLS 等一系列增强,且完全兼容 v2ray-core 的功能及配置。
“配置兼容,整体更好”
补:
简单说就是兼容 core 的配置,且性能更好,功能更多
❤2👀1
Xray-core v1.0.0
https://github.com/XTLS/Xray-core/releases/tag/v1.0.0
New Beginning
Xray-core 基于 v2ray-core 修改而来,改动较大,你只需知道:
- 只有一个可执行文件,含 ctl 的功能,run 为默认指令
- 配置上完全兼容,环境变量和 API 对应要改为 XRAY
- 全平台开放了裸协议的 ReadV,有待更多测试与反馈
- 提供完整的 VLESS & Trojan XTLS 支持,均有 ReadV
Credits
https://github.com/XTLS/Xray-core/blob/main/README.md
- 感谢 v2fly 项目
- 感谢 badO1a5A90 的长期性能测试与反馈
- 感谢 qjebbs 提供合并 ctl 的代码
- 感谢 teddysun 第一时间打包 docker 镜像
Performance
与 v2ray-core v4.32.1、v4.33.0 的一些测试与对比
https://github.com/badO1a5A90/v2ray-doc/blob/main/performance_test/Xray/speed_test_20201124.md
https://github.com/XTLS/Xray-core/releases/tag/v1.0.0
New Beginning
Xray-core 基于 v2ray-core 修改而来,改动较大,你只需知道:
- 只有一个可执行文件,含 ctl 的功能,run 为默认指令
- 配置上完全兼容,环境变量和 API 对应要改为 XRAY
- 全平台开放了裸协议的 ReadV,有待更多测试与反馈
- 提供完整的 VLESS & Trojan XTLS 支持,均有 ReadV
Credits
https://github.com/XTLS/Xray-core/blob/main/README.md
- 感谢 v2fly 项目
- 感谢 badO1a5A90 的长期性能测试与反馈
- 感谢 qjebbs 提供合并 ctl 的代码
- 感谢 teddysun 第一时间打包 docker 镜像
Performance
与 v2ray-core v4.32.1、v4.33.0 的一些测试与对比
https://github.com/badO1a5A90/v2ray-doc/blob/main/performance_test/Xray/speed_test_20201124.md
GitHub
Release Xray-core v1.0.0 · XTLS/Xray-core
New Beginning
Xray-core 基于 v2ray-core 修改而来,改动较大,你只需知道:
只有一个可执行文件,含 ctl 的功能,run 为默认指令
配置上完全兼容,环境变量和 API 对应要改为 XRAY
全平台开放了裸协议的 ReadV,有待更多测试与反馈
提供完整的 VLESS & Trojan XTLS 支持,均有 ReadV
Credits
http...
Xray-core 基于 v2ray-core 修改而来,改动较大,你只需知道:
只有一个可执行文件,含 ctl 的功能,run 为默认指令
配置上完全兼容,环境变量和 API 对应要改为 XRAY
全平台开放了裸协议的 ReadV,有待更多测试与反馈
提供完整的 VLESS & Trojan XTLS 支持,均有 ReadV
Credits
http...
🔥1
Project X 的 GitHub 主仓库 Xray-core 已获 500+ stars,并登上了 GitHub Trending;Project X 群人数破千,频道订阅数 500+,感谢各位的支持!同时十分感谢各类脚本、Docker 镜像、客户端支持...感谢所有帮忙完善生态的大佬们!
为方便日常交流,Xray 可以简写为 x 或 xr
Xray-examples 的 issue 区为 Xray 配置交流区
https://github.com/XTLS/Xray-examples/issues
Xray-examples 的 issue 区为 Xray 配置交流区
https://github.com/XTLS/Xray-examples/issues
GitHub
Issues · XTLS/Xray-examples
Some examples of uses for Xray-core. Contribute to XTLS/Xray-examples development by creating an account on GitHub.
Xray-core v1.1.2
https://github.com/XTLS/Xray-core/releases/tag/v1.1.2
Topic: Linux Kernel Splice(适用于 Android、路由器等 Linux 环境)
What's Splice
Splice 是 Linux Kernel 提供的函数,系统内核直接转发 TCP,不再经过 Xray 的内存,大大减少了数据拷贝、CPU 上下文切换的次数。XTLS Direct Mode 读取数据时不需多余处理,此前引入了默认的全平台 ReadV 增强,性能已与 VLESS 裸奔持平。而现在,你可以选择性开启 Splice 增强:经测试,性能达到了 VLESS 裸奔的两倍。你没看错,比现在的裸奔更省资源。
Scene Limits
1. Linux 环境,入站为 任意门、Socks、HTTP 等纯净的 TCP 连接。
2. 出站为 VLESS XTLS。Trojan XTLS、裸奔等尚未增加此项优化。
Usage
1. 客户端 flow 改为
2. 服务端 flow 保持 Direct。以后服务端也会有 Splice 优化。
More
1. 若你开了流量统计,Splice 转发完一整条 TCP 才会反馈数据量。
2. 其实应用 Splice 后,性能已与软件架构无关,只取决于你的机器和系统内核的表现,非常纯粹。
Xray-core 1k stars 啦,感谢各位的支持!文档 coming soon
Performance
- 与 v2ray-core v4.32.1、v4.33.0 的一些 测试与对比,含 Splice 的数据 https://github.com/badO1a5A90/v2ray-doc/blob/main/performance_test/Xray/speed_test_20201202.md
- 实际环境中,硬路由上 XTLS Splice 的上限已是普通 TLS 的数倍。
Other Changes
- 修改包名:去除包名中的
- 日志中路径不再包含包名,更加清晰。
- API Handlers 添加对
- 新的
Chores
- Regenerate .pb.go files
- Use Go 1.15.6
- Upgrade dependencies
- Update geoip.dat, geosite.dat
Notices
- 新增 Xray-android-arm64-v8a.zip,建议 Magisk 和 Termux 优先用此版本。
- 可执行文件均 Reproducible,相同版本 Go 交叉编译即可验证。
https://github.com/XTLS/Xray-core/releases/tag/v1.1.2
Topic: Linux Kernel Splice(适用于 Android、路由器等 Linux 环境)
What's Splice
Splice 是 Linux Kernel 提供的函数,系统内核直接转发 TCP,不再经过 Xray 的内存,大大减少了数据拷贝、CPU 上下文切换的次数。XTLS Direct Mode 读取数据时不需多余处理,此前引入了默认的全平台 ReadV 增强,性能已与 VLESS 裸奔持平。而现在,你可以选择性开启 Splice 增强:经测试,性能达到了 VLESS 裸奔的两倍。你没看错,比现在的裸奔更省资源。
Scene Limits
1. Linux 环境,入站为 任意门、Socks、HTTP 等纯净的 TCP 连接。
2. 出站为 VLESS XTLS。Trojan XTLS、裸奔等尚未增加此项优化。
Usage
1. 客户端 flow 改为
xtls-rprx-splice
。若不需拦截 QUIC,填写 xtls-rprx-splice-udp443
。2. 服务端 flow 保持 Direct。以后服务端也会有 Splice 优化。
More
1. 若你开了流量统计,Splice 转发完一整条 TCP 才会反馈数据量。
2. 其实应用 Splice 后,性能已与软件架构无关,只取决于你的机器和系统内核的表现,非常纯粹。
Xray-core 1k stars 啦,感谢各位的支持!文档 coming soon
Performance
- 与 v2ray-core v4.32.1、v4.33.0 的一些 测试与对比,含 Splice 的数据 https://github.com/badO1a5A90/v2ray-doc/blob/main/performance_test/Xray/speed_test_20201202.md
- 实际环境中,硬路由上 XTLS Splice 的上限已是普通 TLS 的数倍。
Other Changes
- 修改包名:去除包名中的
v1
。- 日志中路径不再包含包名,更加清晰。
- API Handlers 添加对
v2ray.core
开头的兼容,解决 v2rayN 等无法显示流量统计的问题(但请优先调用 XRAY
)。- 新的
xray api
指令,执行 xray help api
查看用法。输出格式均为 JSON。Chores
- Regenerate .pb.go files
- Use Go 1.15.6
- Upgrade dependencies
- Update geoip.dat, geosite.dat
Notices
- 新增 Xray-android-arm64-v8a.zip,建议 Magisk 和 Termux 优先用此版本。
- 可执行文件均 Reproducible,相同版本 Go 交叉编译即可验证。
GitHub
Release Xray-core v1.1.2 · XTLS/Xray-core
Topic: Linux Kernel Splice(适用于 Android、路由器等 Linux 环境)
What's Splice
Splice 是 Linux Kernel 提供的函数,系统内核直接转发 TCP,不再经过 Xray 的内存,大大减少了数据拷贝、CPU 上下文切换的次数。XTLS Direct Mode 读取数据时不需多余处理,此前引入了默认的全平台 ReadV ...
What's Splice
Splice 是 Linux Kernel 提供的函数,系统内核直接转发 TCP,不再经过 Xray 的内存,大大减少了数据拷贝、CPU 上下文切换的次数。XTLS Direct Mode 读取数据时不需多余处理,此前引入了默认的全平台 ReadV ...
Xray-core v1.1.3
https://github.com/XTLS/Xray-core/releases/tag/v1.1.3
Topic: Transparent Proxies & Hardware NAT
REDIRECT
在此版本前,我们进行了大量的研究与尝试,并最终重构了透明代理的 REDIRECT 模式 f1eb5e3,使之同时支持 IPv4 和 IPv6。这项重构解决了一个历史遗留问题 v2ray/v2ray-core#1309 (comment)
Suggestion
我们偶然发现 Linux 内核的一些参数设置对处理数据包的性能有影响,但大多数硬路由等带硬件 NAT 的设备不会受到明显影响。若你的中间设备只是透明代理,不涉及 NAT 转换(即内核直接在多网段间修改并转发数据包),建议设置(并重启):
#59 有更详细的信息,希望有更多实测与反馈,因为不同环境的受影响程度不同。说实话,专门的硬件 NAT 是个好东西。
Other Changes
- 调整切换至 Splice 前的 CPU 出让方式为Trojan XTLS Outbound 现已支持 Splice 请用之后的版本
- 修正一些 Code generator 的行为
- 完善对
Chores
- Upgrade dependencies
- Update geoip.dat, geosite.dat
Notices
- 若你需要缩小可执行文件的体积,推荐使用 UPX
- 手工编译 Xray-core 时,建议关闭 CGO
https://github.com/XTLS/Xray-core/releases/tag/v1.1.3
Topic: Transparent Proxies & Hardware NAT
REDIRECT
在此版本前,我们进行了大量的研究与尝试,并最终重构了透明代理的 REDIRECT 模式 f1eb5e3,使之同时支持 IPv4 和 IPv6。这项重构解决了一个历史遗留问题 v2ray/v2ray-core#1309 (comment)
Suggestion
我们偶然发现 Linux 内核的一些参数设置对处理数据包的性能有影响,但大多数硬路由等带硬件 NAT 的设备不会受到明显影响。若你的中间设备只是透明代理,不涉及 NAT 转换(即内核直接在多网段间修改并转发数据包),建议设置(并重启):
net.ipv4.ip_forward=0在测试机器上,任开其一即会严重拉低各协议组合的性能,包括 Splice。而对于仅透明代理,实测这两个参数都是不必开启的。事实上,即使存在多个网段,不带硬件 NAT 的设备也完全可以配成仅透明代理 —— 毕竟路由器本质上也相当于“透明代理”。
net.ipv6.conf.all.forwarding=0
#59 有更详细的信息,希望有更多实测与反馈,因为不同环境的受影响程度不同。说实话,专门的硬件 NAT 是个好东西。
Other Changes
- 调整切换至 Splice 前的 CPU 出让方式为
runtime.Gosched()
- - 修正一些 Code generator 的行为
- 完善对
v2ray.core
API 的兼容方式Chores
- Upgrade dependencies
- Update geoip.dat, geosite.dat
Notices
- 若你需要缩小可执行文件的体积,推荐使用 UPX
- 手工编译 Xray-core 时,建议关闭 CGO
GitHub
Release Xray-core v1.1.3 · XTLS/Xray-core
Topic: Transparent Proxies & Hardware NAT
REDIRECT
在此版本前,我们进行了大量的研究与尝试,并最终重构了透明代理的 REDIRECT 模式 f1eb5e3 ,使之同时支持 IPv4 和 IPv6。
十分感谢 @badO1a5A90 @LGA1150 协助测试,这项重构解决了一个历史遗留问题 v2ray/v2ray-core#1309 ...
REDIRECT
在此版本前,我们进行了大量的研究与尝试,并最终重构了透明代理的 REDIRECT 模式 f1eb5e3 ,使之同时支持 IPv4 和 IPv6。
十分感谢 @badO1a5A90 @LGA1150 协助测试,这项重构解决了一个历史遗留问题 v2ray/v2ray-core#1309 ...
Xray-core v1.1.4
https://github.com/XTLS/Xray-core/releases/tag/v1.1.4
Optimize Memory Usage
Xray-core 及 v2ray-core v4.32.0+ 均默认内部读取 json 并反复解码整个 dat 文件,启动时会消耗非常多的内存,且迟迟不还给系统。#68
于是,现在 Xray-core 会先 预解析 dat 文件的 pb 结构,只 Unmarshal 需要的部分,并多次主动 GC,加载完配置主动触发 FreeOSMemory 释放内存。这大幅降低了启动时的瞬时内存占用,解决了默认 jsonem 带来的问题,预解析更是让更多的设备可以直接加载配置。45f44c4
目前 VMess 协议常与 WSS 等结合使用,此时服务端的 drain 机制是没有必要的,所以非纯 TCP/DS 时关闭了此机制以节省资源。f390047
More Configurable TLS
此版本开始,Xray 的 tlsSettings & xtlsSettings 新增了四项配置:
此外,早已弃用的
More Powerful XTLS
现在你可以在更多场景下使用 XTLS Splice 了:出站的 Splice 现已支持入站是 XTLS 的场景(即入站是任意 XTLS 且出站是 XTLS Splice)。关于 Linux 内核参数,我们有了新的进展:已确认大多数硬路由等带硬件 NAT 的设备不会受到明显影响,详见 v1.1.3 的最新说明
Trojan XTLS 已就绪,使用方式及规则与 VLESS XTLS 完全相同:支持 Splice、Direct 等,服务端 Trojan XTLS 兼容客户端普通 Trojan TLS。理论上,Xray-core 的 Trojan 与 VLESS 在性能上没有区别,包括 XTLS 系列,可直接参考以往 VLESS XTLS 的性能测试
Other Changes
- Fix: HTTP dialer uses ctx instead of context.Background() @JimhHan
- Config loader returns error instead of directly panic @JimhHan
Chores
- Upgrade dependencies
- Update geoip.dat, geosite.dat
Notices
- Xray-core releases 中的 Linux 预编译版不再附带 service 文件。
- Xray-install 内置 service 文件,暂时不含自动重启功能。
https://github.com/XTLS/Xray-core/releases/tag/v1.1.4
Optimize Memory Usage
Xray-core 及 v2ray-core v4.32.0+ 均默认内部读取 json 并反复解码整个 dat 文件,启动时会消耗非常多的内存,且迟迟不还给系统。#68
于是,现在 Xray-core 会先 预解析 dat 文件的 pb 结构,只 Unmarshal 需要的部分,并多次主动 GC,加载完配置主动触发 FreeOSMemory 释放内存。这大幅降低了启动时的瞬时内存占用,解决了默认 jsonem 带来的问题,预解析更是让更多的设备可以直接加载配置。45f44c4
目前 VMess 协议常与 WSS 等结合使用,此时服务端的 drain 机制是没有必要的,所以非纯 TCP/DS 时关闭了此机制以节省资源。f390047
More Configurable TLS
此版本开始,Xray 的 tlsSettings & xtlsSettings 新增了四项配置:
minVersion
、maxVersion
、cipherSuites
、preferServerCipherSuites
。十分感谢 @eMeab 的多个 PR,现在你可以自由配置它们以改变客户端的 TLS 指纹、提升服务端的网站评级等,详见 #56 (comment)此外,早已弃用的
allowInsecureCiphers
已被完全移除。注意,allowInsecure
仍然保留。这些改动可能需要重新生成 pb 配置。More Powerful XTLS
现在你可以在更多场景下使用 XTLS Splice 了:出站的 Splice 现已支持入站是 XTLS 的场景(即入站是任意 XTLS 且出站是 XTLS Splice)。关于 Linux 内核参数,我们有了新的进展:已确认大多数硬路由等带硬件 NAT 的设备不会受到明显影响,详见 v1.1.3 的最新说明
Trojan XTLS 已就绪,使用方式及规则与 VLESS XTLS 完全相同:支持 Splice、Direct 等,服务端 Trojan XTLS 兼容客户端普通 Trojan TLS。理论上,Xray-core 的 Trojan 与 VLESS 在性能上没有区别,包括 XTLS 系列,可直接参考以往 VLESS XTLS 的性能测试
Other Changes
- Fix: HTTP dialer uses ctx instead of context.Background() @JimhHan
- Config loader returns error instead of directly panic @JimhHan
Chores
- Upgrade dependencies
- Update geoip.dat, geosite.dat
Notices
- Xray-core releases 中的 Linux 预编译版不再附带 service 文件。
- Xray-install 内置 service 文件,暂时不含自动重启功能。
GitHub
Release Xray-core v1.1.4 · XTLS/Xray-core
Optimize Memory Usage
Xray-core 及 v2ray-core v4.32.0+ 均默认内部读取 json 并反复解码整个 dat 文件,启动时会消耗非常多的内存,且迟迟不还给系统。#68
于是,现在 Xray-core 会先 预解析 dat 文件的 pb 结构,只 Unmarshal 需要的部分,并多次主动 GC,加载完配置主动触发 FreeOSMemory 释放...
Xray-core 及 v2ray-core v4.32.0+ 均默认内部读取 json 并反复解码整个 dat 文件,启动时会消耗非常多的内存,且迟迟不还给系统。#68
于是,现在 Xray-core 会先 预解析 dat 文件的 pb 结构,只 Unmarshal 需要的部分,并多次主动 GC,加载完配置主动触发 FreeOSMemory 释放...
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 🎉
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 🎉
GitHub
Release Xray-core v1.2.0 · XTLS/Xray-core
Topic: Shadowsocks & Trojan UDP FullCone NAT,Xray-core 的进化
Background
v2ray 的 UDP 支持存在一些众所周知的问题,旷日持久,以至于大型联机游戏几乎和 v2 系列绝缘。相关 issues 很多,在此就不列举了。
Progress
在过去的两周内,Xray-core 进行了大量的重构与反复测试,终于迈出了一大步...
Background
v2ray 的 UDP 支持存在一些众所周知的问题,旷日持久,以至于大型联机游戏几乎和 v2 系列绝缘。相关 issues 很多,在此就不列举了。
Progress
在过去的两周内,Xray-core 进行了大量的重构与反复测试,终于迈出了一大步...
❤1
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 的
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 日志中看到路由信息了,格式为
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
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
GitHub
Release Xray-core v1.2.1 · XTLS/Xray-core
Configuration Detector
Xray-core 现支持 FullCone 和 Symmetric 两种模式,而 VLESS、VMess、Mux 暂不支持 FullCone,需要 Symmetric 模式
所以为了防止 VLESS、VMess、Mux 被应用 FullCone,v1.2.0 开始有一个配置检测机制,说明如下:
v1.2.1 开始此机制被移至 core/xra...
Xray-core 现支持 FullCone 和 Symmetric 两种模式,而 VLESS、VMess、Mux 暂不支持 FullCone,需要 Symmetric 模式
所以为了防止 VLESS、VMess、Mux 被应用 FullCone,v1.2.0 开始有一个配置检测机制,说明如下:
v1.2.1 开始此机制被移至 core/xra...
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 也得到了增强:
-
-
VLESS fallbacks SNI shunt
VLESS 的 fallbacks 数组子元素新增
- 比如填
其它规则不变,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 ,目前格式如下:
命中了路由规则:
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,记得先
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]
TrojanDo 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
GitHub
Release Xray-core v1.2.2 · XTLS/Xray-core
VLESS UUID v5 mapping standard
VLESS UUID 映射标准:将自定义字符串映射为一个 UUIDv5
简单来说,和 Trojan、SS 可以自定义密码一样,Xray-core 的 VLESS 和 VMess 也可以自定义 id 了,一些规则见上方链接。
若无特殊需求,建议首选全随机的 UUIDv4
若选择自定义 id,建议保持一定的复杂度
现在 VLESS...
VLESS UUID 映射标准:将自定义字符串映射为一个 UUIDv5
简单来说,和 Trojan、SS 可以自定义密码一样,Xray-core 的 VLESS 和 VMess 也可以自定义 id 了,一些规则见上方链接。
若无特殊需求,建议首选全随机的 UUIDv4
若选择自定义 id,建议保持一定的复杂度
现在 VLESS...
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:
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
)GitHub
Release Xray-core v1.2.3 · XTLS/Xray-core
Shadowsocks AEAD Single-port Multi-user
Xray-core v1.2.3 提供了配置便捷、开箱即用的 Shadowsocks AEAD 单端口多用户支持。
https://github.com/XTLS/Xray-examples/tree/main/Shadowsocks-AEAD
AEAD 加密方式使接收方能够验证解密是否成功,这是一切的基础
服...
Xray-core v1.2.3 提供了配置便捷、开箱即用的 Shadowsocks AEAD 单端口多用户支持。
https://github.com/XTLS/Xray-examples/tree/main/Shadowsocks-AEAD
AEAD 加密方式使接收方能够验证解密是否成功,这是一切的基础
服...
❤1
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
- 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
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 √
GitHub
Release Xray-core v1.2.4 · XTLS/Xray-core
Socks
解决两个“连接至标准 Socks 服务端时可能出错”的历史遗留问题:
设置 Socks 出站 UDP Associate 请求中的 IP、Port 为空,符合 RFC 1928
修正 Socks 出站 Username/Password 认证行为,符合 RFC 1929
Xray-core 不全等于 XTLS,Xray 解决了大量的历史遗留问题、进行了性能等多方面的优化,并...
解决两个“连接至标准 Socks 服务端时可能出错”的历史遗留问题:
设置 Socks 出站 UDP Associate 请求中的 IP、Port 为空,符合 RFC 1928
修正 Socks 出站 Username/Password 认证行为,符合 RFC 1929
Xray-core 不全等于 XTLS,Xray 解决了大量的历史遗留问题、进行了性能等多方面的优化,并...
九点 v1.3.0 的 release 为错误触发,现已删除,请忽略其 release note,等待下午 v1.3.0 正式 release(昨天的没问题)
预热:XUDP:VLESS & VMess & Mux UDP FullCone NAT #252
预热:XUDP:VLESS & VMess & Mux UDP FullCone NAT #252
GitHub
XUDP:VLESS & VMess & Mux UDP FullCone NAT · XTLS Xray-core · Discussion #252
#237 已阐明 V 系协议的 UoT 结构无法实现 FullCone,然而 Xray-core v1.3.0+ 却神奇地做到了本被认为是不可能的事情: 昨天的灵感,通过非常巧妙的机制实现了 V 系协议全部 FullCone,同时与旧版保持一定的兼容性。 这篇文章主要是说明原理及行为,以便其它软件的开发者实现这个 FullCone 方案。 前期探索 最初的思路是只能 breaking:设计新...
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-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 🎉
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 🎉
GitHub
Release Xray-core v1.3.0 · XTLS/Xray-core
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 ...
Background
Xray-core v1.2.x 实现并巩固了 FullCone 特性,而 VLESS、VMess、Mux 受制于协议结构,暂时无法实现 FullCone。
Progress
Xray-core v1.3.0 通过非常巧妙的机制实现了 V ...
❤1🔥1