华润赢
群组频道

RPRX的动态

Project X 与 Xray-core 创始人

共 31 条动态，按原始发布时间排列。

查看人物介绍
来源：GitHub

RPRX 谈 Xray-core 依赖策略：非必要不引入外部库，便于他人 fork 定制，许可证永远是 MPL

在 Xray-core PR #7130（TUN 入站改用内置轻量 TCP/IP 栈替换 gVisor）的讨论中说明：以 TUN 把一部分数据直穿到 WG、MASQUE 出站为例，可能需要往解析 TCP/IP 的代码里插点东西；认为 Xray-core 这种非必要就不引入外部库的开发模式更好，别人想 fork 搞定制的话也少些麻烦，许可证永远是 MPL 不会改。

查看完整动态
来源：GitHub

RPRX 在 Xray-core PR #7103 讨论 h3 支持设计：可否让写 https:// 的地方都支持 http3://，h3 均需支持 quicParams

在 Xray-core PR #7103（xdns 增加 DoT/DoH 支持）的讨论中提出：TLS、ECH、DoH 暂不支持 h3 分享就有点尴尬了，要不 core 内所有能写 `https://` 的地方都能写 `http3://`？以及 Xray-core 内的 h3 都得支持 `quicParams`，这些都加起来好麻烦，得想想怎么设计了，或许以后往 `tlsSettings` 里塞一份。

查看完整动态
来源：GitHub

RPRX：XDNS 的 types/names 缺省语义——客户端 types 默认 16，服务端空 names 允许任何

在 XDNS infra（Xray-core PR #7090，LjhAUMEM 提交，尚未合并）的讨论中，RPRX 就配置缺省值说明：底层传输代码里 types 没值的话，客户端默认 16、服务端默认允许任何；服务端 names 为空的话也允许任何，会比较方便，也就是说 infra 也得加个缺省的。用户可以空 names 兜底。另外他表示尚未确认该实现是支持通配符、还是只按后缀匹配、还是只接受 equal，总之文档得写清楚。

查看完整动态
来源：GitHub

RPRX：XDNS 暂不做 domain 与 resolver 绑定，resolvers×addrs 不复用以避免 QoS

在 XDNS infra（Xray-core PR #7090）的讨论中，RPRX 就配置结构说明：先别做 domain 与 resolver 的绑定——最初加入多个 resolvers 的主要目的是 speed up，先按配置示例改以方便这个目的。对于 resolvers × addrs，为避免潜在的 QoS 问题，肯定是不复用、开多个 socket 最好；这也是此前改成基于 fm dial 的收益之一。

查看完整动态
来源：GitHub

RPRX 评 Xray-core 的 MASQUE WARP 支持 PR：认证信息宜置传输层，证书校验仅 pin 公钥未验签名

在 Xray-core PR #6878（CluvexStudio，MASQUE: Support WARP，开放未合并）的评审中，RPRX 就 WARP 支持的实现提出：认证信息填在传输层，他查看后认为 Hy2 客户端实现也是这样，而入站的认证填在代理层方便 API；支持 WARP 显然仅客户端。关于客户端发送证书，他认为 WARP 这个特征有点扎眼，并问相关代码是否会让 uTLS 有独特逻辑。特地查看验证服务端证书的代码后，他提出：pin 完公钥之后是否不再验证 sign…（节选）

查看完整动态
来源：GitHub

RPRX：XDNS 重构后配置结构宜调整，服务端 name 改 names、客户端仅需 resolvers

在 Xray-core「XDNS finalmask: Fix resolver close deadlock and socket leaks」PR #7089 的讨论中，RPRX 就 PR #6718 重构后的 XDNS 配置结构提出调整意见：服务端的 `name` 应改为 `names`，这样多个 domain 可以共享同一套 `types`，不必多写一份 `domains`；客户端问题较大，以前支持「哪个 domain 只走哪个 resolver」，现在不行了，应改为…（节选）

查看完整动态
来源：GitHub

RPRX：XDNS 解析器配置宜合并写法，共用 TLS 需把 addr 改为数组

在 Xray-core「XDNS finalmask: Fix resolver close deadlock and socket leaks」PR #7089 的讨论中，就多台 DoH 使用不同 SNI 能否共用 TLS 配置，RPRX 表示：若要共用，TLS 配置还是得放在外层，这不是同一个问题；要实现该想法得把 `addr` 改成 `addrs` 数组。他还提到有人可能想共用 sockopt，那样 `type` 一配多会有些尴尬，实际上这里还是合并成一项写最好，例如 …（节选）

查看完整动态
来源：GitHub

RPRX：Xray-core 这个回归修复 PR 先按 bug fix 合并，底层传输架构后续再重整

在 Xray-core PR 6877（gRPC 客户端用首次请求的已取消上下文重拨的回归修复，作者 LevL-max，2026-10-05 01:26 UTC 合并）下，RPRX 于 2026-10-05 01:17 UTC 回复：统一的调用路径会让逻辑简单很多，后续修改也不用考虑不同逻辑分支的可能性，减轻心智负担；他表示这个 PR 可以先按 bug fix 合并，后续还是要按前述方向重整底层传输的架构。原文中另有一条带删除线的表述（作者已撤回），未予收录。

查看完整动态
来源：GitHub

RPRX：以后所有 dial/hub 都走 Finalmask，并精简底层传输的嵌套

RPRX 在 Xray-core PR #6877（修复 gRPC 出站重拨使用首次请求已取消 context 的回归）讨论中表示：像这样分两个路径，就可能会出现有一侧有 bug、另一侧没 bug 的情况；他的意思是以后所有 dial/hub 都一定走 Finalmask，它可以把 internet 那块代码吸收进来，底层传输这里的套娃还要精简下，只要不影响 v2rayNG 的自定义 dialer 就行。

查看完整动态
来源：GitHub

RPRX：Xray 的 XDNS 配置改为结构化 JSON 的设计可以接受

在 Xray-core「XDNS finalmask: Refactor and new parameters」PR（LjhAUMEM 提交，2026-09-29 17:17Z 合并）下，RPRX 表示他只看了配置：原先全部编码进一行的语法已彻底改成结构化的 JSON 配置，并新增了一些参数（「以后加别的新参数也方便些」一句被他自己划去）。他想过之后认为，这里既然不是 TLS DoH 那种直接放进分享链接、而是分享整个 JSON 的形式，改成这种设计也可以（「趁着 XDNS …（节选）

查看完整动态
来源：GitHub

RPRX 谈 Xray-core 的 NEXT 架构方向：组件可任意串联、配置与 API 改为脚本加载

在 Xray-core 一个「为 DNS 查询引入 Lua 脚本」的开放 PR 讨论中（该 PR 目前仍 open、未合并），RPRX 描述了 NEXT 架构的大致方向：组件可任意串联，尤其是路由/DNS 可以插在任何位置；增强匹配与行为语法（他举的例子就是这个 Lua 脚本）；配置文件与 API 改为一行行加载脚本的形式，而不是现在这种固定 JSON 加 gRPC API。原话里「最好还能判断/修改一些内部变量」和「貌似应当全用 lua」两处被他自己用删除线划去。他没有给出…（节选）

查看完整动态
来源：GitHub

RPRX：能用 Finalmask 实现的功能就用它，不能实现的才去改 WireGuard 的代码

在 Xray-core 的 MASQUE 入站 PR #6844（已合并）合并后的后续讨论中，Fangliding 质疑为 WireGuard 增加 AWG 类改动与 finalmask.salamander 重叠、并追问为何放着 quic(h3) 与 noise 不用；RPRX 答复：此前说过能用 Finalmask 实现的功能就用它来实现，正如当初不加旧版 AWG 的理由，不能用 Finalmask 实现的才去改 WG 的代码。同一句里「谁来写篇教程」一句已被他自己用删除…（节选）

查看完整动态
来源：GitHub

RPRX：Xray-core TUN 新增 autoSystemDNS，Linux 上的 DNS 泄漏问题已解决

RPRX 在 Xray-core issue #6454（「tun模式存在dns泄漏」，2026-07-08 由 PhoenixNil 提交，仍 open）下于 2026-09-27 20:24:11Z 答复：PR 6773 已解决 Linux 上的问题，并新增了一个配置项 autoSystemDNS；他感觉改用 gateway 这种做法在 FreeBSD 上同样适用，并请 drTr0jan、brookwko 试试。他还说这个 issue 上面的讨论已确认 Windows 上…（节选）

查看完整动态
来源：GitHub

RPRX：Xray-core 减少 error 日志的改动确实提升了性能，先按此方案推进

在 Xray-core PR 6796（减少 error 日志使用以提升性能）讨论末尾，RPRX 表示「先这样吧」：热点代码里有很多 debug log，之前虽然没输出但那些调用仍然存在，这样改确实提升了性能。他另有一段已划去的话，曾考虑改成 call log 模块、往里塞函数参数的方案，给出的顾虑是层层返回 error 的情况不太好做，而且这个 err 还用于实际的逻辑控制。该 PR 由 Fangliding 于 9 月 21 日提交、9 月 25 日 17:49Z 合并（…（节选）

查看完整动态
来源：GitHub

RPRX 在 GitHub 的公开发言

再多说一点其实就是，有死要面子活受罪的比如 Surge 刘某人，还有“只要 RPRX 支持的就必须是错的”比如 sing-box 世某人的 CDN 是滥用等言论，还有可能是为了兼容性而“把选择权交给用户”的 Mihomo，他们当初还说我批评面板呢，**真给我整笑了机场专用内核的白得不能再白的用户自己竟然有选择的能力说是，我说过历史会证明我推的一系列默认/强制的安全策略是正确的**

查看完整动态
来源：GitHub

RPRX：AGI 时代 Xray 仍由维护者决定理念、安全策略与协议标准

RPRX 在 Xray-core #6773 的讨论中表示，他认为即使 AI 能生成大量非核心代码，Xray 在 AGI 时代的核心价值仍包括由维护者决定 CDN、网盘等使用理念与默认或强制安全策略，以及设计 VLESS 相关协议标准并提供可互联、可直接运行和分享节点的预构建核心；VLESS Encryption 这类核心加密则最好仍由人来编写。

查看完整动态
来源：GitHub

RPRX 在 GitHub 的公开发言

@Risaro 0xe5554cceca6db722bebc4028b466d20e33d63029534ecb5875218943742cca90 我觉得最可贵的是能实时测试 Google Drive 等 backend 并改进 XDRIVE 的代码，~~是否 vibe 的倒不重要，可能明年全靠 AI 都行~~ 目前比较需要一份 Google Drive API 配置教程，半年前我和 @iambabyninja 通过邮箱讨论过，但不确定是否适用于这个 PR

查看完整动态
来源：Telegram

@projectXtls 频道 在 Telegram 的公开发言

💬 New comment on Xray-core#6748 XDRIVE transport: Add the Google Drive backend by @RPRX 为了凑到第 2000 个 commit ~~以及给 Risaro 的生日补个礼物~~，我打算现在就分两步合并 XDRIVE 相关的 PR 进 main 代码仍需完善，比如上面我提到的 XMUX，以及 config 的“Google Drive”改为“google-drive”，以及检测配置：需开启 mu…（节选）

查看完整动态
来源：GitHub

RPRX 在 GitHub 的公开发言

为了凑到第 2000 个 commit ~~以及给 Risaro 的生日补个礼物~~，我打算现在就分两步合并 XDRIVE 相关的 PR 进 main 代码仍需完善，比如上面我提到的 XMUX，以及 config 的“Google Drive”改为“google-drive”，以及检测配置：需开启 mux.cool ~~可能还需要一些 deVibe~~，好在代码一旦进入 main 就会开始接受更广泛的 PR，会有很多人来完善，就像 XHTTP 那样 还需配套的文档、Googl…（节选）

查看完整动态