Fangliding：Lua 沙箱下任意代码执行权限过危险，建议特权功能需启动时加 flag 显式开启
在 Xray-core PR #7136（为 Lua 增加沙箱机制）的讨论中，Fangliding 提出安全顾虑：理论上一个恶意的 Lua 脚本甚至可以访问 Xray 内置的 DNS，通过 DNS 隧道获得网络后挖矿等，任意代码执行权限还是太危险；他建议改成使用 Lua 的特权功能需要在启动时加一个 lua-(privileged) 的 flag。该 PR 为开放状态、尚未合并。
Fangliding的动态
Xray-core 代码贡献者
共 33 条动态，按原始发布时间排列。
查看人物介绍Fangliding：依赖优先用正式版本号，没有则取两周后的最新 commit
在 Xray-core PR #7135（把 uTLS 升到 6ebdceb / Chrome 155、注册 hellochrome_155）的讨论中，有人问为什么取 6ebdceb 这个提交而不是最新提交，Fangliding 回应：不用这么急，如果发布了（有 tag）肯定优先用正常的版本号，就算没有也是取两周后的最新 commit。该 PR 为开放状态、尚未合并。
Fangliding：直言面向 Cloudflare 的话，用 L4 模式不用 MASQUE 不到一千行就能做完，但不支持 UDP
在 Xray-core PR #7121 关于 WARP/MASQUE 与 L4 模式的讨论中，Fangliding 表示：愿意直说的话，这就是面向 Cloudflare 编程（毕竟以前连注释都避个嫌）；用 L4 模式、不用那个 MASQUE，不到一千行代码就做完了，他自己以前其实也写过，不过不支持 UDP。
Fangliding：Xray 固定 uTLS 提交是异常情况；Chrome 133 指纹实际覆盖 133~154，并不远古
在 Xray-core issue #7131（Bump uTLS: chrome fingerprint is still Chrome 133）中，Fangliding 回应：用 pinned commit 是异常情况，因为他在 uTLS 加了 ECH 的 ALPN 伪装后也没法催他们发版，所以 Xray 这边只好指定 commit 来实装这个功能。对「Chrome 155 是当前稳定版、133 已是少数派」的说法，他表示这说不准：大量其他使用 chromium 的框架（…（节选）
Fangliding：功能字段与接口设计不必统一，不同的人设计出的 TUN 接口不同很正常
在 Xray-core PR #7130 关于是否引入外部 TCP/IP 库的讨论中，Fangliding 回应 RPRX：bool 就 bool 呗，实际上这些功能字段设计不一定就非得长这样；这些字段就是提出之后 patt 那些人跟 AI 说了、AI 再弄的，不同的人设计出不同的接口是完全正常的事，谁优谁劣很难说，也没有人类讨论是否就非得写成这样。各种 TUN 需要的东西八成隔壁（sing-tun）也处理过，说用隔壁的设计接口处理不好也是不太可能的。
Fangliding：内置 TCP/IP 栈之所以有一千多行是因为它简陋，全抄约等于复制/引入依赖
在 Xray-core PR #7130（TUN 入站改用内置轻量 TCP/IP 栈替代 gVisor）的讨论中，Fangliding 回应 RPRX 关于 tcp_lightweight.go 只有一千行、没有必要引入外部库的说法：它能有一千多行是因为它简陋，mips 里 commit history 中标出的那一堆 fix 都不是假的，这个（外部库）八成也都有，全抄了约等于复制 / go get 进来。
Fangliding：SS2022 的问题只在许可证，此前 ss 超时本质是 sing-bridge 模块的 bug
在 Xray-core PR #7130 关于是否引入外部 TCP/IP 库的讨论中，Fangliding 回应 RPRX：ss2022 的问题不就只有许可证么；同样都是动不了的外部库，gvisor 不是好好的，以及所有 gomod；之前 ss 超时那些问题本质是 sing-bridge 模块的 bug，而不是 sing ss 这个库本身有多大问题。
Fangliding：uTLS 没有 release，且 Chrome 155 很新，立刻迁移不全是好事
Fangliding 在 issue #7131（把 Xray-core 的 uTLS 依赖从 Chrome 133 指纹升级到 Chrome 155）中表示：uTLS 并没有 release（如果 release 了会自动更新）；并且 155 这个版本非常新，立刻迁移也不全是好事。
Fangliding 建议 Xray-core TUN 入站改用 MetaCubeX/mipstack 以去掉 gVisor 依赖
Fangliding 在 PR #7130（TUN 入站改用内置 TCP/IP 栈替代 gVisor）中向 RPRX 建议：可以考虑直接使用 MetaCubeX/mipstack，理由是同类翻墙软件已经踩过各种坑，其许可证为 MPL 2.0，也方便一并替换 wireguard 和 masque 等依赖，这样才能去掉 gVisor 依赖。
Fangliding：内联文本形式的 script 不需要热重载
Fangliding 在 PR #7124（Finalmask noise 的 Lua 脚本）关于 script 配置与热重载的讨论中表示：传文本就不重载；证书和 geofile 属于无人值守更新，一更新就希望立刻生效，与文本配置不同，别到时候又只能加个 fswatch 进来。
Fangliding：反对为 (x)mux 引入上千行状态的 ACK 机制，认为是在重新引入 TCP 已抽象掉的问题
在 Xray-core issue #7115 关于 (x)mux 连接稳定性的讨论中，Fangliding 对「引入 ACK 机制」的提议提出反对：为部分网络一分钟断一条连接的情况引入上千行、涉及各种状态的 ACK 状态管理并不值得；TCP 已费大力气把这些问题抽象掉，再引入进来不划算；HTTP/2 也没有做这类机制，仅处理队头阻塞的 window update 就已带来很大麻烦。
Fangliding：xray api 子命令的定位是自动化调用与 gRPC 范例，不需要宽松的解析器
在「API: Accept flags after arguments in `xray api`；修复无 outbound tag 时 `xray api bo` 的 panic」PR 中，Fangliding 表示 api 子命令主要用于不想编写 gRPC 代码的自动化工具调用，以及作为 gRPC 调用方法的范例，不太需要宽松的参数解析器。该 PR 已被关闭。
Fangliding：Hysteria 连接回收中子元素取父元素的锁容易死锁，用 status 屏蔽不可用连接
在「Hysteria: Remove closed instance conn」PR 讨论中，Fangliding 指出子元素的方法去取父元素的锁确实很容易导致死锁；防止新建 QUIC 连接靠他此前推的 commit 已经做了，即多一个 status 表示连接不再可用，自然把新建屏蔽掉。该 PR 用于在 instance 关闭后正确回收连接（关联 #7102、#7100）。
Fangliding：被吊销的 CA 极少，改用内置 CA 库是为安卓上跑 Linux ARM 取不到 CA
在「Use bundle CA as default」PR 中，Fangliding 表示因丑闻被吊销的 CA 非常少，得是上新闻的级别；因为每个被广泛使用的 CA 都可能攻击无法更新的设备，所以新增本就很谨慎。这个改动最初来自在安卓上运行 Linux ARM 会取不到 CA 的场景。
Fangliding：vlessRoute 为 0 的规则也会选中无 VLESS route 的协议
在 XTLS/Xray-core issue #7094「vlessRoute: "0" 规则匹配非 VLESS 入站的流量」讨论中，Fangliding 确认该现象，并表示 0 也可以算一个 feat——它能够选中无 vless route 的协议，因此请不要使用 0。
Fangliding：gRPC 拨号回归源于 Finalmask 把 dialsystem 封成变量，路径有限
Fangliding 在 Xray-core PR #6877（修复 gRPC 出站重拨使用首次请求已取消 context 的回归）讨论中回应 RPRX：有 bug 再修就是了，隔三岔五一大堆 AI PR 还怕扫不出 bug；Finalmask 内部就是把本来直接的 dialsystem 当变量封了进去而已，UDP 是拼连接的类型问题，就这么多路径，以后不会再有类似情况了。
Fangliding：核心架构从未设计处理半关闭，为老旧协议开口子不合适，建议考虑 uplinkonly=0
在 Xray-core 一个关于 TUN 与 WireGuard 入站在响应结束时半关闭连接的 PR 讨论中（klokv 提交，用于修复 Moonlight/Sunshine 的 RTSP 握手因响应 EOF 延迟累积而失败，该 PR 已关闭、未合并），Fangliding 表示：整个核心的架构从未被设计过处理半关闭，那么多年了也没见到很大问题，为了这个老旧协议开口子似乎还是不太行，并问是否考虑过 uplinkonly=0。
Fangliding：WireGuard 内核 TUN 的表号向下搜索因该 bug 实际失效，多个 WireGuard 出站会坏掉
Fangliding 在 Xray-core PR #6881（Linux 内核 TUN 配置含 IPv6 时提示 failed to find available ipv6 table index）下说明：这段向下 search 最早是为控制多个出站的场景而加，但由于该 PR 所修复的 bug（循环内只递减局部变量、从未把新表号写回过滤器，每次都在查同一张表），search 实际上一直是失效的；只要多于一个 WireGuard 出站就会坏掉。他表示早年接到相关 issue …（节选）
Fangliding 关闭 Xray-core XHTTP 32 KiB 批量读写 PR，称本地回环吞吐不是首要考虑
Fangliding 在 Xray-core PR 6837（作者 4RH1T3CT0R7，2026-09-27 08:28:45Z 提交，把 XHTTP 传输的读写由按 8 KiB 缓冲改为 32 KiB 批量）下留言，并于同一时刻关闭该 PR（未合并）：本地跑对拷的吞吐不是首要考虑，尤其这套改动还要处理穿透与 stat.CounterConnection 的一层层包装；他还提到，此前某次更新之后本地回环性能已经跌了一大半。 被关闭的 PR 自述：Windows 回环上传输…（节选）
Fangliding：Xray-core 多实例状态在设计上本就不保证，自定义连接应由调用方从 proto 构建 outbound
在 Xray-core PR 6833（让 sockopt 的 dialerProxy 与 domainStrategy 在发起拨号的那个实例里解析，由 patterniha 提交，已关闭未合并）下，Fangliding 反对为此往各处塞 context。他说多 instance 的状态在设计之初就是不保证的，并指向 core/xray.go 的注释：Server 是 Xray 的一个实例，任何时刻最多只能有一个 Server 实例在运行。他给出的正确做法是，由调用方代码从 …（节选）
Fangliding 反对为 Xray-core 的 DNS 引入 Lua 脚本引擎
在 Xray-core 一个「为 DNS 查询加入 Lua 脚本」的开放 PR 讨论中，Fangliding 表示反对。他说自己看到了上面提到的二进制体积膨胀，但问题不只这一处，还有引入这东西带来的额外逻辑和维护问题：它不是一个纯粹因为需要复杂逻辑才引入的图灵机，而是为了这个 Lua 引擎，需要把各种本来在 Go 里的对象捏成 Lua 可调用的东西，这些都要写代码，之后还得维护一份文档；现在捏了一个可调 geodata，以后还得要 balancer 变更的回调，回头可能再看一…（节选）
Fangliding 质疑 Xray-core 让取消调度连带取消 tagged 拨号的改动
在 Xray-core PR 6828（Burst observatory：取消待处理的 HTTP 检查）讨论中，Fangliding 提出质疑：tagged dialer 的 ctx 控制和默认 net 的 ctx 不一样，取消它会导致整个连接被关掉；并说没真出问题的话，不要靠盯着代码就改。该 PR 由 wywywywycloud 提交，改动是把检查上下文贯穿到 MeasureDelay、HTTP 请求、响应体读取与连通性探测，使取消旧调度时不再遗留飞行中的 tagged …（节选）
Fangliding：Xray-core 的 MASQUE 实现是复制 connect-ip-go，以后同步只能复制粘贴，且只有客户端实现
在 Xray-core 的 MASQUE 出站与传输层（IETF CONNECT-IP，RFC 9484）pull request 6807 讨论中，Fangliding 表示：这个实现是从 connect-ip-go 复制过来的（因为 Xray 用的是 quic-go 的 fork），以后要同步上游只能复制粘贴，而且只有客户端实现。他还说，让 AI 把 usque 缝进去也就几分钟的事情，自用的情况下无人在意多余的导入。
Fangliding：Xray-core 上行 splice 收益有限，且无法排除有人在 Android 上运行 Linux arm64 构建
在 Xray-core PR 6805（[perf] tcp uplink fixes，作者 JkLondon，已关闭未合并）下，Fangliding 表示：对方看到的大量上行可能来自 pprof 测试，实际网络请求不会有特别多的上行；他认为只做下行 splice 大概就够了，再加一个上行 splice 无法增加太多性能，而且无法排除有人在 Android 上运行 Linux arm64 构建。
Fangliding：已将 Xray-core XHTTP 在 Go 1.27 下的连接问题反馈给 Go 上游
在 Xray-core 关于 Go 1.27 构建下 XHTTP 多路复用失效、TLS 握手挂起并导致内存占用的讨论中，Fangliding 表示已将该问题反馈给 Go 上游（golang/go#81646，标题为 x/net/http2 在 go1.27+ 的新包装实现缺少 single flight 机制）。此前同一议题中有贡献者认为该改动是有意为之、不建议向上游反馈。
Fangliding 报告 Go 1.27 新版 net/x/http2 缺少单连接复用机制
在 golang/go 的一个问题中，Fangliding 报告 Go 1.27 起新的包装式 net/x/http2 实现缺少旧实现的单连接复用（single flight）机制：以 100 个并发请求测试，新版会为每个请求各发起一次 TCP 拨号（共 100 次），而加 `-tags http2legacy` 的旧实现只拨号 1 次。他认为 net/http 因为事先不知道服务端 HTTP 版本才需要多次拨号，而 x/net/http2 已有前置信息，建议增加一个开关启用…（节选）
Fangliding 指出 XHTTP 握手阻塞问题可能成为 release blocker
Fangliding 在 Xray-core #6797 中表示，即使对正常 HTTP/2，TLS 握手等待期间多个请求也理应被阻塞；如果该问题存在，可能又会成为 release blocker，并建议反馈给 golang/go。
Fangliding：Xray 保留该依赖版本主要是为了 ECH 隐藏 ALPN
Fangliding 说，依赖最终会由最上层仓库统一，Xray 使用该版本主要是为了他此前编写的 ECH 隐藏 ALPN，除此之外没有太多必要。
Fangliding 提醒 GUI 客户端写入的未知字段可能受损
在 Xray 配置字段校验讨论中，他表示多数软件会忽略未知字段，而 GUI 客户端可能把管理数据写入 JSON，修改这些字段可能损坏客户端。
Fangliding 谈 Xray-core 对纯 AI 代码投稿的审查要求
Fangliding 在 Xray-core PR #6755 中表示，一般情况下不接受纯 AI 代码，并质疑该投稿说明能否体现提交者实际阅读过所引用的其他 PR。此条记录该次贡献审查中的公开回应，不将其扩大为禁止所有 AI 辅助开发的政策。