动态

华润赢翻墙应用商店创建者与编辑

作者发言

官方网站·2026.09.23 19:19:00（UTC+8）

新增服务端目录

yiguodevOneXray 开发者

值得推荐作者发言

GitHub·2026.09.23 12:22:05（UTC+8）

yiguodev：Xray 本地 DoH 上游的主机名引导解析可能绕回被接管的系统 DNS，实测 4 秒超时

在 Xray-core PR 6773 的复测说明中表示，混合 localhost 的拒绝接管与两条回滚错误信息的保留已通过追加验证。在 autoSystemDNS 开启、TUN/53 走 DNS outbound、上游为 https+local://dns.google/dns-query 时，本地 DoH 路径会以该上游主机名调用 DialSystem，而 MayUseSystemResolver() 未识别这一间接依赖，预检仍会放行。他在 Linux ARM64 / systemd-resolved 259 上用两组各 8 个用例、共 16 个全新 Core 与 TUN 实例实测：接口绑定并启用 DNS 接管后该上游查询超时约 4.0 秒，仅为该主机名补一条系统 /etc/hosts 记录后即恢复（约 0.22 秒）；抓包显示引导查询先到系统存根再到 TUN DNS 地址。他建议本 PR 先只记录「上游解析（含引导）必须独立于被重定向的解析路径」这一配置限制，运行期改进留作后续，方向是在 DNS 查询拨号路径使用带接口绑定的 Go 默认解析器，并强调这仅为建议、未经本次实验实现或验证。他另说明约 4 秒是客户端超时上限，实验只验证 TUN 下的 DNS。

作者原文 · 预览@yiguodev

Thanks for the update. I rechecked 8f7c97d0: the mixed-localhost refusal and preservation of both rollback error messages pass the additional probes. The source-port-independent requirement is also clear now.

One additional configuration limitation: local DoH bootstrap

With autoSystemDNS enabled and TUN/53 routed to the DNS outbound, consider an upstream such as https+local://dns.google/dns-query. The local DoH path calls DialSystem with the upstream hostname, so establishing the connection can require system DNS. The current MayUseSystemResolver() detects the empty/explicit-LocalNameServer cases, but not this bootstrap dependency, and preflight accepts it.

If that bootstrap lookup is itself redirected through the same DNS outbound, with no independent way to resolve the upstream hostname, the dependency becomes:

resolved -> TUN -> DNS outbound -> DoH hostname bootstrap -> resolved

This can prevent resolution through that upstream. Successful resolvectl calls would not trigger the configuration-failure rollback merely because later DNS queries fail.

Evidence limit: I used real Core/router/DNS/DoH objects with a reserved .invalid upstream hostname, without starting Core/TUN. The command runner only recorded calls; Go's resolver Dial was intercepted to return a controlled error without sending packets. In all three runs, the dependency check returned false, the takeover path attempted three recorded commands, and the actual DoH lookup reached the system-resolver hook. This confirms the missed dependency, not a live reproduction of post-takeover DNS failure; no host DNS was changed.

Either handling is reasonable

1. Extend the refusal check for this bootstrap case and add regression coverage; or
2. Keep the limited preflight and explicitly document this as an unsupported configuration: upstream resolution, including bootstrap, must remain independent of the resolver path being redirected. Clarify that the check detects specific known cases rather than all indirect dependencies. A warm cache or existing connection is not a lasting guarantee after expiry/reconnection.

My earlier wording about refusing system-resolver dependencies should not imply that this PR needs a general dependency analyzer. I would not require a runtime fix before merging if this is made an explicit configuration limitation. I'll leave that choice to you.

查看完整动态

Ryan YanSatelite 架构师

作者发言

GitHub·2026.09.23 10:45:31（UTC+8）

Ryan Yan：Satelite 计划增加一个直接用原始配置拉内核、跳过转换层的模式

在 satelite-proxy 的建议议题中表示，TUN 模式他自己在 macOS 与 Windows 上没有遇到问题；协议方面他自己用不到那么全的协议，部分也测不全。他希望社区开发者能针对自己碰到的问题修复并提 PR。他另表示后面会出一个模式，完全使用原始的配置拉内核、跳过转换层，以缓解一些问题。

作者原文 · 预览@zn0wii

tun模式这个，我自己osx和win没问题。 还有协议这些，我自己用不了那么全的协议，有的也是测不全。 既然项目是开源的，社区开发者如果能针对自己碰到的问题，修复提一些pr上来就好了。
后面会出一个模式，完全使用原始的配置拉内核，跳过转换层，这样可以缓解一些问题。

查看完整动态

ElegyingSSRVPN 创始开发者

作者发言

GitHub·2026.09.23 00:23:29（UTC+8）

Elegying：SSRVPN PR #257 的工作已随 5.0.15 线进入 main，不再单独合并

在关闭该 PR 的说明中表示，本 PR 的改动已由 #258（codex/windows-release-5.0.15，squash 合入）带入 main，因此不再合并，分支保留为存档不删除。给出的依据包括：本 PR 相对 v5.0.13 改动的 79 个文件中有 67 个与当前 main 逐字节一致；本分支新引入的多个实现符号在 main 上全部命中；剩余 12 个文件差异为版本号、CHANGELOG、文档，以及 main 在 5.0.15 线上继续演进的两个代码文件。另提到本分支新建的 ADR-020 与 main 上的编号冲突，以 main 侧编号为准。

作者原文 · 预览@Elegying

关闭原因：工作已随 5.0.15 线进入 main，本 PR 不再有独立价值

本 PR 的改动已由 #258（codex/windows-release-5.0.15，squash 合入）带入 main，因此不再合并。
保留分支 codex/static-wallpaper-5.0.14 作为存档，不删除。

判定依据

1. 逐文件内容比对：本 PR 相对 v5.0.13 改动的 79 个文件中，67 个与当前 main 逐字节一致。
2. 独有实现符号反查：本分支新引入的 networkFingerprintOf、PORT_MISSES_BEFORE_RESTART、
   safeRuntimeErrorCode、expectedWidth / sizeChanged、dataPlaneProbeAttempts、
   buildDataPlaneDiagnosticSummary、runNetworkChangeCheck、
   _invalidateDataPlaneObservationAndReprobe —— 在 main 上全部命中；
   Android 侧复制版 String _safeLogErrorCode 在 main 上不存在（护栏有效）。
3. squash 合入的旁证：#258 自述「本分支领先 main 共 21 个 commit（前 19 个为 5.0.14→5.0.15 既有迭代）」。

剩余差异（不构成保留理由）

12 个文件与 main 仍有差异，构成为：三端 pubspec.yaml + app_constants.dart（版本号 5.0.14 → 5.0.15）、
CHANGELOG.md、4 份文档，以及 2 个代码文件（ssrvpn_drifting_background.dart、ssrvpn_glass_capture.dart）。
后两者是 main 在 5.0.15 线上继续演进的结果，非本分支独有内容。

本分支另有 2 个未推送提交（Windows 安装位置可选、玻璃捕获改在绘制期取纹理），
main 以更简化的实现解决了同类问题（按精确映像名结束随包进程，见 ADR-021；
proxy_transaction_state.ps1 由 16 个函数收敛为 8 个），故同样被取代。

备注

本分支曾新建 docs/decisions/020-windows-install-location-and-proxy-repair.md，
与 main 上的 docs/decisions/020-installer-system-proxy-ownership.md 编号冲突。
因该文件不进入 main，此处不做处理；main 侧的 ADR-020 / ADR-021 编号为准。

查看完整动态

dyhkwongExclave 代码贡献者

值得推荐作者发言

GitHub·2026.09.22 23:38:23（UTC+8）

dyhkwong：检测是否使用代理不需要检测 VpnService，不建议把代理软件与间谍软件装在同一设备

在 Exclave 的建议议题中回应检测相关讨论时表示，检测是否使用代理的方法有很多，根本不需要检测 VpnService，检测应用同理；并认为用户不应把代理软件与间谍软件安装在同一设备上，也不应把代理软件安装在带间谍行为的系统中。对「加入外部拉起与关闭服务以配合 Tasker 自动化」的建议，他反问现有的 Tasker 支持是否已经可以做到。

作者原文 · 预览@dyhkwong

关于猫鼠游戏；#374
检测是否使用代理方法一大把，根本不需要检测 VpnService。检测应用同理。用户根本不应该将代理软件和间谍软件安装在同一个设备上，也不应该将代理软件安装在间谍系统中。

加入外部拉起服务和关闭服务功能，这样就能配合tasker自动化使用

现在已有的 Tasker 支持不是可以做到的吗？

查看完整动态

liandu2024Open-Box 核心作者

作者发言

GitHub·2026.09.22 22:40:57（UTC+8）

liandu2024：OpenClash 停掉后 dnsmasq 上游残留会让以 N1 做 DNS 的设备断网

在排查一台设备断网问题时表示，此前国外流量实际由 OpenClash 在 7892 端口代理，Open-Box 基本没参与；停掉 OpenClash 后若内核未重启会停在纯 tun 模式，而纯 tun 不接管终端的 DNS。他判断常见情况是 OpenClash 停止后仍把 dnsmasq 的上游留在自己的 DNS 端口，于是以 N1 做 DNS 的手机整体断网。他建议先彻底停用 OpenClash 并检查 dnsmasq 残留配置，再重启设备确认入口模式是否回到 auto_redirect。

作者原文 · 预览@liandu2024

有进展。先说结论:之前你的国外流量其实是 OpenClash 在 7892 上代理的,Open-Box 被它截在前面基本没干活;现在 OpenClash 停了,Open-Box 接手,但你贴的入口仍是「纯 tun」——说明停掉 OpenClash 之后 Open-Box 内核没重启过,nftables 模式还没回来。纯 tun 不接管终端的 DNS,全靠 N1 的 dnsmasq;而 OpenClash 停掉后经常把 dnsmasq 的上游留在它自己的 DNS 端口上,于是用 N1 做 DNS 的手机整个断网,电脑自己填了公共 DNS 的话国内能上、国外没有域名分流就进不了代理。

按顺序做:

1. 彻底停掉 OpenClash 并检查 dnsmasq 残留(贴文字):
   /etc/init.d/openclash stop; /etc/init.d/openclash disable uci -q get dhcp.@dnsmasq[0].server; uci -q get dhcp.@dnsmasq[0].noresolv; ls /tmp/dnsmasq.d/
   如果 server 里是 127.0.0.1#7874 这类 OpenClash 的端口:uci -q delete dhcp.@dnsmasq[0].server; uci commit dhcp; /etc/init.d/dnsmasq restart。
2. 重启 N1(最省事,顺便把 OpenClash 的残留规则清干净)。起来后看 Open-Box 内核卡片有没有「已改用纯 tun」的警告——正常应该没有;规则页测 test.ustc.edu.cn,右栏应该是「入口模式:auto_redirect」+「已旁路」。
3. 到这一步再看手机 / 电脑。还有问题就贴:
   nft list tables; ip rule logread -e sing-box | tail -n 30
   以及 Open-Box DNS 页里「DNS 劫持」选的是哪种。

查看完整动态

liandu2024Open-Box 核心作者

作者发言

GitHub·2026.09.22 21:54:27（UTC+8）

liandu2024：Open-Box v0.1.245 已发布，这类固件会自动降级成纯 tun 模式启动

在答复节点与分组缺失的问题时表示，v0.1.245 已发布，升级后重启内核即可；他提到这类固件会自动降级成纯 tun 模式启动，节点和分组就有了，内核卡片上会有一条「已改用纯 tun 模式」的说明。若升级后仍不行，他要求再贴 sing-box 日志。

作者原文 · 预览@liandu2024

v0.1.245 已发:升级后重启内核,这种固件会自动降级成纯 tun 模式起来,节点和分组就有了;内核卡片上会有一条「已改用纯 tun 模式」的说明。升完还不行的话把 logread -e sing-box | tail -n 40 贴上来。

查看完整动态

liandu2024Open-Box 核心作者

作者发言

GitHub·2026.09.22 21:50:16（UTC+8）

liandu2024：自动组放进两千多个节点会让每一轮测速变成两千多次连接

在答复「经常断网」的问题时表示，把两千多个节点全放进自动组后，内核每一轮测速就是两千多次连接，免费节点里还有大量根本连不上的，测速一轮接一轮占掉带宽和连接数，「经常断网」多半由此而来。他建议在订阅设置里按地区或关键字筛选，把每个自动组控制在几十个以内，并把免费节点单独放一个组、不与机场节点混用。

作者原文 · 预览@liandu2024

两千多个节点全放进自动组,内核每一轮测速就是两千多次连接,免费节点里还有大量根本连不上的——测速一轮接一轮,带宽和连接数都被占掉,"经常断网"多半就是这个。建议:

1. 订阅设置里用筛选(按地区 / 关键字)把每个自动组控制在几十个以内,免费节点单独放一个组、不要和机场混;
2. 「添加目标分流后外网不通」请规则页查一个不通的域名,把右栏五步的文字贴上来;
3. 断网时 logread -e sing-box | tail -n 40 贴一下。

有这些就能看是节点数的问题还是分流配置的问题。

查看完整动态

liandu2024Open-Box 核心作者

作者发言

GitHub·2026.09.22 21:49:58（UTC+8）

liandu2024：随包 Node 24 在这台机器上 V8 初始化就崩溃，安装脚本是故意在此停下

在答复安装失败的问题时表示这不是安装脚本的问题：随包的 Node 24 在该机器上 V8 初始化就崩溃（Check failed: 0 == ret），脚本是故意在这一步停下来，否则装完只会面板打不开。他怀疑是老内核 5.4 的地址空间或页大小与 Node 24 不匹配，并请对方补页大小、ulimit 与 cpuinfo，以便判断能否为这类固件出一份兼容的 Node 包；现阶段这台 QWRT 设备先用不了。

作者原文 · 预览@liandu2024

谢谢,信息够用了。这不是安装脚本的问题:随包的 Node 24 在这台机器上 V8 初始化就崩了(Check failed: 0 == ret),脚本是故意在这一步停下来的,不然装完只会面板打不开。

怀疑是老内核 5.4 的地址空间 / 页大小和 Node 24 对不上。麻烦再贴三样(getconf 没有,用这几条代替):

awk '/KernelPageSize/ {print $2; exit}' /proc/self/smaps
ulimit -v; ulimit -s
head -n 8 /proc/cpuinfo

有了这些我们看能不能给这类固件出一份兼容的 Node 包;现阶段 QWRT 这台先用不了,抱歉。

查看完整动态

liandu2024Open-Box 核心作者

作者发言

GitHub·2026.09.22 21:48:38（UTC+8）

liandu2024：v0.1.230 起内核启动时会补一条更高优先级的策略路由绕开固件黑洞规则

在关闭一个联网异常问题时表示，v0.1.230 起内核启动时会补一条更高优先级的策略路由，绕开固件的黑洞规则；该问题先关闭，升级后仍不通可回复重开。

作者原文 · 预览@liandu2024

v0.1.230 起内核启动时补了一条更高优先级的策略路由绕开固件的黑洞规则,结论见上;先关了,升级后还不通再回复重开。

查看完整动态

wonfenClash Verge Rev 创世维护者与发起人

值得推荐作者发言

GitHub·2026.09.22 21:39:28（UTC+8）

wonfen：多数用户其实不了解 DNS 覆写的作用，这是订阅更新后自动关闭覆写的原因

在回应「新增 DNS 覆写保护：订阅含自定义 DNS 时先确认，订阅更新后自动关闭覆写」的质疑时表示，不认同「会用 DNS 覆写的人都知道在干嘛」的说法；从大量用户反馈看，大部分用户并不知道 DNS 覆写是干什么的，就把它打开了。

作者原文 · 预览@wonfen

"新增 DNS 覆写保护：订阅含自定义 DNS 时先确认，订阅更新后自动关闭覆写"，不明白这功能何意味，会用DNS覆写都知道在干嘛吧，你给别人自动关了干嘛

不，从大量用户给我们的反馈来看，大部分用户都不知道 DNS 覆写是干什么的，就打开了。

查看完整动态

liandu2024Open-Box 核心作者

作者发言

GitHub·2026.09.22 21:35:53（UTC+8）

liandu2024：sing-box 不会删自己的 nftables 表，常见原因是别的插件执行了 nft flush ruleset

在排查 29 条 create/list nftables table: no such file or directory 日志时表示，其含义是内核要往入口的 nftables 集合写入时发现 inet sing-box 这张表已经不在了，因此 DNS 还进得来而数据流量不再被送进内核。他表示 sing-box 自己不会删自己的表，常见情况是别的代理插件或某个脚本执行了 nft flush ruleset，并请对方下次出现时贴 nft 表列表与相关日志。他还说明 tosv.byted.org、detect-online.volcanicengine.com 每 5 秒一次的探测是局域网里字节系 App 的联网探测，与 Open-Box 无关。

作者原文 · 预览@liandu2024

感谢挖日志。那 29 条 update route address set: create/list nftables table: no such file or directory 的含义是:内核要往入口的 nftables 集合里写东西时,发现 inet sing-box 这张表已经不在了。表没了就是你看到的现象——DNS 还进得来(dnsmasq 转给 7853),数据流量不再被送进内核,连接页只剩 dnsmasq 那些。

问题是谁把表冲掉的。sing-box 自己不会删自己的表,常见的是别的代理插件或某个脚本执行了 nft flush ruleset。下次出现时麻烦贴文字(附件我这边不下载,用 ``` 包起来贴):

nft list tables
logread | grep -iE "firewall|flush|clash|passwall|ssr" | tail -n 30
ps | grep -iE "clash|mihomo|passwall|ssr" | grep -v grep

以及 /etc/init.d/openbox restart 之后是否立刻恢复。另外「问题二」那两条(tosv.byted.org、detect-online.volcanicengine.com 每 5 秒一次)是局域网里字节系 App 的联网探测,和 Open-Box 无关。

查看完整动态

liandu2024Open-Box 核心作者

值得推荐作者发言

GitHub·2026.09.22 21:35:52（UTC+8）

liandu2024：v0.1.243 及之前在纯 tun 模式下会整份丢掉扣过段的旁路集合，v0.1.244 已修

在定位一台设备旁路失效时给出两点结论：一是该设备运行在「纯 tun（兼容）」模式，auto_redirect 的 nftables 规则起不来时面板会自动降级再起一次；而 v0.1.243 及之前在纯 tun 下会把扣过段的旁路集合整份丢掉，默认分流的 geoip-cn 与 geoip-private 恰好都是扣过段的，于是一份都没旁路、白名单也不会启用，规则页却仍写着「已配置」，他称这是缺陷并已在 v0.1.244 修好，纯 tun 也改用扣段后的集合编进路由表。二是连接被 DNAT 到 192.168.2.2:7892，而 7892 是 OpenClash / ShellCrash 一类插件的默认透明代理端口，他判断设备上还有别的代理插件在跑，其规则让 auto_redirect 起不来并先把流量截走，建议停用该插件后重启内核。

作者原文 · 预览@liandu2024

谢谢,文字证据把原因定死了,两件事:

1. 你这台 Open-Box 跑在「纯 tun(兼容)」模式——「入口模式:纯 tun」「nft 里当前没有旁路集合」、nft list set 报 No such file、meta 里没有 entryMode,都指向这一点。auto_redirect 的 nftables 规则起不来时,面板会自动降级成纯 tun 再起一次(内核卡片应该有一条「auto_redirect 起不来,已改用纯 tun 模式」的警告)。而 v0.1.243 及之前在纯 tun 下把扣过段的旁路集合整份丢掉了——默认分流的 geoip-cn / geoip-private 恰好都是扣过段的,所以一份都没旁路、白名单也不会启用,规则页却还写「已配置」。这是我们的缺陷,v0.1.244 已修:纯 tun 也用扣段后的集合(编进路由表),规则页「业务入口」会写明「路由表」和「纯 tun 只用黑名单」的原因。请先升到 v0.1.244。

2. 更关键的:是谁把连接改写到了 7892? conntrack 那行显示连接被 DNAT 到 192.168.2.2:7892。Open-Box 的重定向端口是随机高位端口(比如 33897),7892 是 OpenClash / ShellCrash 一类插件的默认透明代理端口。N1 上多半还有别的代理插件在跑,它的 nft / iptables 规则让 sing-box 的 auto_redirect 起不来(所以才降级),并且把流量先截走了。麻烦确认一下,贴文字:

netstat -lnp | grep 7892
ps | grep -iE "clash|mihomo|passwall|ssr|shellcrash" | grep -v grep

把那个插件停掉(或卸掉)之后重启 Open-Box 内核,内核卡片的降级警告应该消失;再用规则页测 test.ustc.edu.cn,右栏「业务入口」应该是「已旁路」。停掉 Open-Box 能跑 578M 说明硬件够,进用户态(不管是哪个插件的)就是 200M 左右,只有入口旁路真正生效才能回到接近 578。

查看完整动态

FanglidingXray-core 代码贡献者

作者发言

GitHub·2026.09.22 20:30:12（UTC+8）

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

我向上游反馈了这个问题 https://github.com/golang/go/issues/81646

查看完整动态

dyhkwongExclave 代码贡献者

值得推荐作者发言

GitHub·2026.09.22 19:06:56（UTC+8）

dyhkwong：Exclave 将按 ALPN 兼容性中断调整既有配置、新建配置与内核行为

在跟踪 V2Ray QUIC 传输 ALPN 兼容性中断的议题中，dyhkwong 列出 Exclave 需要的改动：既有配置把「无 ALPN」改写为 ALPN h2 与 http/1.1；新建配置中「无 ALPN」表示 ALPN h3；exclave-core 目前接受 h3、h2 或 http/1.1 之一（他注明这暂不具备抗主动探测能力），未来版本起只接受 h3；Shadowsocks v2ray-plugin 短期内不太可能更新，Exclave 对其始终使用 ALPN h2 与 http/1.1；分享链接始终带上 ALPN 参数，以避免隐式和含糊的默认值。

作者原文 · 预览@dyhkwong

So Exclave needs the following changes:

• For existing profiles in Exclave, rewrite "no ALPN" into ALPN "h2" and "http/1.1".
• For newly created profiles in Exclave, "no ALPN" means ALPN "h3".
• For exclave-core, accepts one of ALPN "h3", "h2" or "http/1.1" for now (not active-probing resistant). Starting from a future version, only accepts ALPN "h3".
• It is unlikely for Shadowsocks v2ray-plugin to receive an update in the near future. Exclave has to always use ALPN "h2" and "http/1.1" for Shadowsocks v2ray-plugin.
• For share link, always add the ALPN parameter to avoid implicit and ambiguous default values.

What a drama.

查看完整动态

dyhkwongExclave 代码贡献者

值得推荐作者发言

GitHub·2026.09.22 19:00:15（UTC+8）

dyhkwong：V2Ray 开发者确认 QUIC ALPN 变更属意外的破坏性改动，服务端临时接受多种 ALPN

在跟踪 V2Ray QUIC 传输破坏性变更的议题中，dyhkwong 表示已向 V2Ray 开发者反馈服务端一侧仍未修复、且这属于破坏性改动；V2Ray 开发者确认这是意外的破坏性改动，V2Ray 服务端目前临时接受 ALPN h3、h2 或 http/1.1 之一。他同时给出了 v2fly/v2ray-core v5.54.2 的发布页面链接。

作者原文 · 预览@dyhkwong

https://github.com/v2fly/v2ray-core/releases/tag/v5.54.2

Reported to V2Ray's developer that server side is not fixed and this is a breaking change. V2ray's developer confirmed it is an unexpected breaking change. V2Ray server now accepts one of ALPN "h3", "h2" or "http/1.1" temporarily.

查看完整动态

OneOhCloudOneBox 架构师

作者发言

GitHub·2026.09.22 18:11:17（UTC+8）

OneOhCloud：OneBox 自研内核与客户端仍处于内测阶段

在关于 iOS 移动网络下 TUIC 异常的讨论中，OneOhCloud 提醒：自研的内核与客户端仍处于内测阶段，可能会存在影响体验的 bug，UI 设计也非最终定稿版本。

作者原文 · 预览@OneOhCloud

注意自研的内核与客户端仍旧处于内测阶段，可能会存在影响体验的 bug ，UI 设计也非最终定稿版本。

查看完整动态

2dustv2rayN 与 v2rayNG 核心维护者

作者发言

GitHub·2026.09.22 18:08:31（UTC+8）

2dust 说明 v2rayNG 真实延迟测试看起来变慢的原因

在 v2rayNG 真实延迟测试（real ping）的反馈中，2dust 说明：新版本测试时把延迟和 IP 信息一起返回，所以会比较慢；旧版本先返回延迟再返回 IP 信息，看着比较快。

作者原文 · 预览@2dust

新版本测试时，把延迟和IP信息一起返回，所以会比较慢。
旧版本测试时，新返回延迟后再返回 IP 信息，看着比较快

查看完整动态

yosebyteNodePass / Nowhere 代码贡献者

作者发言

GitHub·2026.09.22 14:45:06（UTC+8）

yosebyte：Nowhere TUI 保留 TCP/UDP 命名，不改为 SOCKS5 TCP/UDP

在 NodePassProject/Nowhere 关于「上下行独立」的问题讨论中，有用户建议把 `nowhere tui` 里的 TCP / UDP 标签改名为 SOCKS5 TCP / SOCKS5 UDP，yosebyte 回应称倾向保留现有命名：TUI 里的 TCP / UDP 表示被代理的流类型，不是底层承载，也不特指 SOCKS5 协议，改成 SOCKS5 TCP / SOCKS5 UDP 会把流量统计与代理前端耦合，反而让抽象更不清晰。他给出的模型是：TUI 的 TCP / UDP = 被代理流类型；TLS / QUIC = Vector 与 Portal 之间的承载；up / down = 各方向载荷的承载选择。

作者原文 · 预览@yosebyte

Regarding the TUI naming, I would prefer to keep TCP and UDP as they are.

They represent the proxied flow type, not the underlying carrier and not specifically the SOCKS5 protocol. Naming them SOCKS5 TCP and SOCKS5 UDP would couple the flow statistics to the proxy frontend and could actually make the abstraction less clear.

The intended model is:

• TCP / UDP in the TUI = proxied flow type
• TLS / QUIC = carrier between Vector and Portal
• up / down = carrier selection for each payload direction

So I think keeping these concepts separate is preferable.

查看完整动态

liandu2024Open-Box 核心作者

作者发言

GitHub·2026.09.22 13:55:31（UTC+8）

liandu2024：Open-Box 入口旁路问题按已验证关闭，tun MTU 不在面板层固定

在 Open-Box 关于 auto_redirect 吞吐与入口旁路的问题讨论中，liandu2024 确认重新编译的入口旁路集合为 37110 字节、与预期一致（比原始拷贝略大是因为 36.96.0.0/12 被切成几段），并把「入口旁路」这条按已验证关闭，后续测速数字可在该问题下追加。关于 tun MTU，他表示不打算在面板层固定：65535 是 sing-box 自己在 Linux 上选的默认值，tun 上 MTU 越大，走 tun 的那条路（纯 tun 模式的 TCP 以及 UDP）每个包越大、系统调用越少；固定成 1500 会让纯 tun 模式变慢，对当前 auto_redirect 路径（TCP 在入口 REDIRECT、不经 tun）没有任何影响。他补充用户本地改了也不会坏，只是没有收益。

作者原文 · 预览@liandu2024

验证结果收到，多谢。37110 字节那份就是扣掉 CloudFront 中国段之后重新编的集合（比原始拷贝还大一点是因为 36.96.0.0/12 被切成了几段），和预期一致。方便的话把客户端重新测速的数字也贴一下，好和 616 / 1331 对个账。

MTU 这个我们不打算在面板层固定：65535 是 sing-box 自己给 Linux 选的默认值，tun 上 MTU 越大，走 tun 那条路（纯 tun 模式的 TCP、以及 UDP）每个包越大、系统调用越少；固定成 1500 会让纯 tun 模式变慢，对你现在的 auto_redirect 路径（TCP 在入口 REDIRECT、不经 tun）则没有任何影响。你本地改了也不会坏，只是没收益。

入口旁路这条按已验证关掉；测速数字或别的情况直接在这里追加就行。

查看完整动态

FanglidingXray-core 代码贡献者

值得推荐作者发言

GitHub·2026.09.22 13:15:28（UTC+8）

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 已有前置信息，建议增加一个开关启用单连接复用，或在 ALPN 只包含 h2 时自动启用。该问题目前仍为 open，尚无官方结论。

作者原文 · 预览@Fangliding

Go version

go 1.27 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/codespace/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/codespace/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2735046389=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/workspaces/Xray-core/go.mod'
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/codespace/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.26.1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

run this code to count dial calls in http2

package main

import (
	"context"
	"crypto/tls"
	"fmt"
	"io"
	"net"
	"net/http"
	"sync"
	"sync/atomic"

	"golang.org/x/net/http2"
)

func main() {
	totalRequests := 100
	targetURL := "https://cp.cloudflare.com/cdn-cgi/trace"

	var dialCount atomic.Int64

	client := &http.Client{
		Transport: &http2.Transport{
			DialTLSContext: func(ctx context.Context, network, addr string, cfg *tls.Config) (c net.Conn, err error) {
				dialCount.Add(1)
				dialer := &tls.Dialer{Config: cfg}
				return dialer.DialContext(ctx, network, addr)
			},
		},
	}

	var wg sync.WaitGroup
	start := make(chan struct{})

	for range totalRequests {
		wg.Add(1)
		go func() {
			defer wg.Done()
			<-start
			resp, err := client.Get(targetURL)
			if err == nil {
				io.Copy(io.Discard, resp.Body)
				resp.Body.Close()
			}
		}()
	}

	close(start)
	wg.Wait()

	fmt.Printf("Total Dial Calls: %d\n", dialCount.Load())
}

What did you see happen?

It made 100 tcp dial calls for every http request

Total Dial Calls: 100

What did you expect to see?

In old http2 implementation, instantly sending multiple requests will only make one TCP dial, this is the expected behavior of http2
run code above with this

go run -tags http2legacy .

And it will return

Total Dial Calls: 1

I understand that HTTP package needs to dial multiple connections because the server HTTP version is unknown, but we have prior knowledge in net/x/http2, and perhaps we can add a config to enable the single flight mechanism in http package (or automatically use when alpn only contains h2?)

查看完整动态

snakem982Pandora Box 架构师

作者发言

GitHub·2026.09.22 11:44:56（UTC+8）

snakem982：Pandora-Box v1.0.24-pre 新增右键修改配置，其余建议暂不考虑

在功能建议讨论中，作者回复：v1.0.24-pre 已添加右键修改配置；配置目录无法迁移的问题希望对方录制短视频后才能进一步分析；其他问题暂时不考虑。

作者原文 · 预览@snakem982

感谢建议

v1.0.24-pre

已添加右键修改配置

配置目录无法迁移的问题，希望录制个短视频才能进一步分析

其他问题暂时不考虑

查看完整动态

liandu2024Open-Box 核心作者

值得推荐作者发言

GitHub·2026.09.22 11:44:36（UTC+8）

liandu2024：核实 sing-box 1.14 的 tun MTU 默认值，Open-Box 暂不改动 MTU

在 auto_redirect 吞吐讨论中，作者核实：sing-box 1.14 不写 mtu 时 Linux 上默认就是 65535（源码 protocol/tun/inbound.go），不是 9000。开启 auto_redirect 时 LAN 的 TCP 在入口 REDIRECT 到内核的真实 socket、不经过 tun，MSS 按 LAN 口协商；经过 tun 的只有 UDP/ICMP，回程报文大小由远端数据报决定，也到不了分片。因此固定 1500 没有害处、也不会更快，先不动它。

作者原文 · 预览@liandu2024

MTU 核实了：sing-box 1.14 不写 mtu 时 Linux 上默认就是 65535（源码 protocol/tun/inbound.go），不是 9000。不过开着 auto_redirect 时 LAN 的 TCP 是在入口 REDIRECT 到内核的真实 socket，不经过 tun，MSS 按 LAN 口协商；经过 tun 的只有 UDP / ICMP，回程报文大小由远端那个数据报决定，也到不了分片。所以你固定 1500 没有害处，也不会更快，我们先不动它。

查看完整动态

wonfenClash Verge Rev 创世维护者与发起人

值得推荐作者发言

GitHub·2026.09.22 10:59:14（UTC+8）

wonfen：Clash Verge Rev 的 Merge dns 字段被覆盖属 bug，已修复

在 clash-verge-rev 关于 Global Merge 的 dns 段被「DNS 覆写」开关影响的问题讨论中，wonfen 表示 merge 的 dns 字段被合并属于 bug，已由提交 6a85d03「fix(enhance): replace DNS fields in merge overrides」修复，该提交改为替换 DNS 映射字段与 hosts 而非保留旧条目，同时保留未指定的 DNS 字段、DNS 覆写优先级与显式空值。他同时说明优先级规则：除 `dns.ipv6` 外，其余 dns 键在 GUI 设置里没有开启或留空值时，由 Merge / Script 覆盖 GUI。

作者原文 · 预览@wonfen

1. merge dns字段是合并是bug，已修复：https://github.com/clash-verge-rev/clash-verge-rev/commit/6a85d0344e5df34c750ca3158e53b8b37a5ddf82

dns.ipv6 以外的 dns 键，是 Merge/Script 压过 GUI，不是 GUI 压过 Merge/Script

如果GUI设置里没有开启或留空值的话，是 Merge/Script 压过 GUI

查看完整动态

wonfenClash Verge Rev 创世维护者与发起人

作者发言

GitHub·2026.09.22 10:57:28（UTC+8）

wonfen：Clash Verge Rev 修复切换订阅后 DNS 覆写自动关闭的问题

在「切换订阅 DNS 覆写自动关闭」问题讨论中，作者回复：merge dns 字段的合并是 bug，已修复（提交 6a85d03）；目前已改为首次提示，且 DNS 覆写与订阅绑定。

作者原文 · 预览@wonfen

merge dns字段是合并是bug，已修复：https://github.com/clash-verge-rev/clash-verge-rev/commit/6a85d0344e5df34c750ca3158e53b8b37a5ddf82

目前已改为首次提示，且DNS覆写和订阅绑定

查看完整动态

yiguodevOneXray 开发者

作者发言

GitHub·2026.09.22 10:57:12（UTC+8）

yiguodev：OneXray 的 JSON 编辑器补上全选/复制/剪切/粘贴菜单

作者回复：JSON 编辑器在与 re_editor 集成时缺失选择菜单，已在移动端长按菜单与桌面端右键菜单中加入全选、复制、剪切、粘贴，覆盖 Raw JSON、高级自定义路由 JSON 与节点 JSON 编辑器；菜单行为已由 iOS、Android、macOS 的自动化组件测试覆盖，尚未在 iOS 18.7.8 真机上验证；该修复将包含在下一个版本中。

作者原文 · 预览@yiguodev

Thanks for reporting this. The JSON editor's selection menu was missing from OneXray's integration with re_editor.

We have added Select All, Copy, Cut, and Paste through a long-press menu on mobile and a right-click menu on desktop. The fix applies to Raw JSON, advanced custom routing JSON, and node JSON editors.

The menu behavior is covered by automated widget tests for iOS, Android, and macOS. We have not yet verified it on a physical device running iOS 18.7.8.

The fix will be included in the next release. Closing this issue as fixed.

查看完整动态

dyhkwongExclave 代码贡献者

作者发言

GitHub·2026.09.22 10:21:34（UTC+8）

dyhkwong：Exclave 说明不支持 AmneziaWG 的理由

在 AmneziaWG 支持请求讨论中，作者列出不支持的理由：协议设计与质量不佳（作者称其只是带易检测混淆头的 WireGuard，完全不抗封锁）；没有协议规范，他人只能逐 bug 兼容或直接引入其库；付费高级版背书，对方可随时改变对免费版的态度；Exclave 是支持代理协议的代理软件而非 VPN 软件，支持 VPN 协议需做三层-四层-三层转换，性能与体验较差，且只能代理 TCP 与 UDP。作者并表示 Exclave 支持 WireGuard 本身是个失误，只对 Cloudflare WARP 滥用者有利，WireGuard 适用既往条款，新协议不适用。

作者原文 · 预览@dyhkwong

• Poor protocol design and quality. It is only the WireGuard protocol with some easily detectable obfuscation headers. It is not resistant to the firewall at all.
• No protocol specification. They did not document the protocol details, so others can only bug-to-bug compatible with them or import their library directly.
• Paid premium version endorsement. They can change their attitude at any time towards their free (gratis) version. We don't want to endorse them.
• VPN protocol. Exclave is a proxy software with the support for proxy protocols, and is NOT a VPN software. Supporting a VPN protocol requires to proceed a layer3-layer4-layer3 conversion, which will make the performance and user experience pretty poor. What's worse, we can only proxy TCP payload and UDP, and can not handle Layer 3 protocols and other Layer 4 protocols, and can not establish a virtual private network, defeating the purpose of a VPN protocol. Exclave did support WireGuard, but I think supporting WireGuard was a fault, which was only beneficial to Cloudflare WARP abusers. WireGuard is applicable to grandfather clause, but new protocols are not.

查看完整动态

lmlmHey 开发者

作者发言

GitHub·2026.09.22 09:57:11（UTC+8）

lmlm：Hey v1.3.5 升级到 libXray v26.7.28，并说明此前回退的原因

在支持 libXray v26.7.28 的问题讨论中，作者更新：v1.3.5 已升级到 libXray v26.7.28（工具链换成 star4277/ohos-go v1.26.5）。此前回退是因为升级后 VPN 扩展进程在启动 Xray 时会 SIGSEGV（日志停在 VPN created，没有 Xray started）；根因是自身桥接代码：新版 libXray 加载后又调用 setenv 设置资源目录，而 Go 的 c-shared 库在 dlopen 返回后会另起线程异步初始化运行时，此时改环境变量会与初始化线程竞争并读到野指针崩溃，与工具链本身和 TLS 无关。修法是把设置资源目录的时机挪到首次加载库之前，已在真机反复验证。sing-box 同步用新工具链重编，版本仍是 1.12.25，1.13.18 因 libbox API 大改暂缓。

作者原文 · 预览@popsiclelmlm

更新：v1.3.5 已升级到 libXray v26.7.28（工具链换成 star4277/ohos-go v1.26.5）。

之前回退是因为升级后 VPN 扩展进程在启动 Xray 时会 SIGSEGV（日志停在 VPN created，没有 Xray started）。定位下来根因是我们自己桥接代码的问题：新版 libXray 加载后，代码里紧接着又调用了 setenv 设置资源目录，而 Go 的 c-shared 库在 dlopen 返回后会另起线程异步初始化运行时，这时候再改环境变量会和初始化线程产生竞争，导致其读到野指针崩溃。和工具链本身、TLS 都没有关系——这也印证了你和 @huopingzi 反馈的「TUN fd → setTunFd()」路径本身是可行的。修法是把设置资源目录的时机挪到首次加载库之前，真机上反复验证过（连续多次连接均正常，VLESS/REALITY 通，sing-box 切换到新核心跑 VLESS 也验证了数据面有真实吞吐）。

sing-box 同步用新工具链重编了（版本仍是 1.12.25，1.13.18 因 libbox API 大改暂缓）。

感谢你和 @huopingzi 提供的工具链信息和调用方式参考，这个 issue 先关闭，后续如果要跟进原生 TUN 直连（去掉 tun2socks 这一跳）或 sing-box 1.13.18 会再开新 issue 跟踪。

查看完整动态

dyhkwongExclave 代码贡献者

值得推荐作者发言

GitHub·2026.09.22 09:48:03（UTC+8）

dyhkwong：记录 V2Ray v5.54.1 修改 QUIC 传输默认 ALPN 造成的兼容性中断

作者开帖跟踪：V2Ray 在 v5.54.1 中为了修复「安全问题」，把 QUIC 传输的默认 ALPN 从 h2 和 http/1.1 改为 h3，且未说明这是破坏性变更；更严重的是只改了客户端、没改服务端。作者认为即便要做破坏性变更，也应默认不设 ALPN 而不是 h3，但由于 V2Ray 的基础设施，默认不设 ALPN 并不容易实现。该变更还会破坏他们自己的 Shadowsocks v2ray-plugin 实现。作者说明这并非新发现的问题，已在 Exclave wiki 的配置页记录，因为改动会破坏与 V2Ray 的兼容性，一直没有机会调整该行为。

作者原文 · 预览@dyhkwong

https://github.com/v2fly/v2ray-core/releases/tag/v5.54.1

In this version, to fix the "security issue", V2Ray changed the default ALPN of QUIC transport from "h2" and "http/1.1" to "h3", without mentioning this is a breaking change.

What's worse, they only changed the client side and forgot to change the server side.

What's worse, even if they need to make some break changes, the should default to no ALPN rather than ALPN "h3". However, due to V2Ray's infrastructure, defaulting to no ALPN is not an easy task.

What's worse, this will also break our Shadowsocks v2ray-plugin implementation.

This is NOT a newly discovered problem. We have documented this in Exclave wiki. Because changing this behavior will break the compatibility with V2Ray, we have never had the chance to change this behavior.

查看完整动态

wonfenClash Verge Rev 创世维护者与发起人

作者发言

GitHub·2026.09.22 09:04:31（UTC+8）

wonfen：Clash Verge Rev 增加重装 Service 可修复目录权限的提示

在 tun 模式程序卡住断网（code 1003）的问题讨论中，作者贴出提交 bffe91d 并说明：增加了重装提示，重装 Service 可以修复目录权限。

作者原文 · 预览@wonfen

https://github.com/clash-verge-rev/clash-verge-rev/commit/bffe91db5eed88995ed1d3becc211e6f590ed47f

增加了重装提示：重装 Service 可以修复目录权限

查看完整动态