在 clash-verge-rev 关于「Windows 下检测 Hyper-V 保留端口范围、混合端口无法绑定时引导用户」的功能讨论中，wonfen 回复称，检测到端口占用后自动切换端口是本次更新的重要特性之一，并附上实现该行为的提交（自动选择可用的混合代理端口、协调监听端口变更、检测 Windows 监听端口冲突）。
作者原文 · 预览@wonfen查看完整动态检测到端口占用，自动切换端口是本次更新的重要特性之一
https://github.com/clash-verge-rev/clash-verge-rev/commit/7796259b0394df73bf35a6f1984a7f8d96603690
wonfen 在 Clash Verge Rev #7989 中给出修复 commit，并说明不同来源的订阅或规则集共用缓存路径时，会自动分开保存。
作者原文 · 预览@wonfen查看完整动态https://github.com/clash-verge-rev/clash-verge-rev/commit/3b958acb22b2ad9fa360245f97d109f245908ea9
不同来源的订阅或规则集共用缓存路径时，会自动分开保存
Fangliding 在 Xray-core #6797 中表示，即使对正常 HTTP/2，TLS 握手等待期间多个请求也理应被阻塞；如果该问题存在，可能又会成为 release blocker，并建议反馈给 golang/go。
作者原文 · 预览@Fangliding查看完整动态这哪怕对于正常的http2都是相当大的问题 多个请求理应被阻塞住等待握手返回 也许应该反馈给 golang/go ?
如果问题存在又release blocker了
wonfen 在 Clash Verge Rev #7994 中表示，dns.ipv6 的 GUI 设置高于 Merge/Script；DNS 覆写自动关闭提示只对原始配置生效，不修改 Merge 和 Script 行为。只要订阅包含 DNS 字段，每次重启该开关都会自动关闭并弹通知，即使最终有效配置由 Merge 定义。
作者原文 · 预览@wonfen查看完整动态并非bug；就是这样设计的：
- dns.ipv6 GUI设置高于merge/Script
2.自动关闭DNS覆写的提示，只对原始配置生效，并不会修改 Merge 和 Script 的行为。
#[serde(skip)][verge.rs:87]，只要订阅含配置的 DNS 字段，每次重启开关都会自动关掉并弹通知，哪怕你的 dns 段完全由 Merge 定义、开关开关根本不影响最终的有效配置
Memory2314 表示，Clash Party 某次提交把启动完成时机提前到 API 管道开始监听，可能让启动后的配置 PATCH 与 DNS/TUN 初始化并发；他称这个问题稍后会修复。
作者原文 · 预览@Memory2314查看完整动态经排查 9a0099db2b79cbea74bb789226241f98b5d23e00 这个提交把启动完成时机从：
等待start initial compatible provider default提前成：
API 管道刚开始监听就执行completeCoreStartup()
启动后的配置 PATCH 可能与 DNS/TUN 初始化并发这个问题稍后会修复
Fangliding 说，依赖最终会由最上层仓库统一，Xray 使用该版本主要是为了他此前编写的 ECH 隐藏 ALPN，除此之外没有太多必要。
作者原文 · 预览@Fangliding查看完整动态顺便把依赖都升到最新版吧，uTLS 那个和 Xray-core 对齐
依赖最后会被最上面的仓库拉平的 这里改了也没啥用 xray用那个版本主要是为了我之前写的ECH隐藏alpn 除此之外没啥很必要的
RPRX 在 Xray-core #6773 的讨论中表示，他认为即使 AI 能生成大量非核心代码，Xray 在 AGI 时代的核心价值仍包括由维护者决定 CDN、网盘等使用理念与默认或强制安全策略，以及设计 VLESS 相关协议标准并提供可互联、可直接运行和分享节点的预构建核心；VLESS Encryption 这类核心加密则最好仍由人来编写。
作者原文 · 预览@RPRX查看完整动态
Xray-core 可以更名 Xray-vibe 了，不是，我看隔壁 3x-ui 天天 vibe 也是挺香的，AI 越来越强了，要不拿赞助费充 GPT-6 AstraAGI 时代 Xray 的核心价值大概是理念：“CDN、网盘等不算滥用”以及各种默认/强制的安全策略等，这些还是得靠维护者来决定
以及 VLESS 相关协议标准：将天马行空的想法设计为标准，并提供两端可互联的预构建 core，下载就能直接运行、节点可分享
还有 VLESS Encryption 这种最好是由人来写、相对一劳永逸的核心加密，
至于其它的非核心代码，说实话 vibe 一个月要啥有啥
liandu2024 在 Open-Box #184 中说明，测速地址已经可以在“设置 → 后端设置”全局修改，也可在单个自动择优组中单独设置，保存后需重启内核。他同时指出，测速请求由节点服务器访问目标地址，Cloudflare 只处理到节点的 WS + TLS 隧道；EOF 更可能与 VMess 参数或服务端 80 端口出站有关，换用 HTTPS 测速地址可辅助排查。
作者原文 · 预览@liandu2024查看完整动态测速地址已经可以改,不用等新版本:
- 全局:设置 → 后端设置 →「测速地址」,填
https://www.gstatic.com/generate_204或https://cp.cloudflare.com/generate_204都行,面板不会改写你填的协议;- 单个自动择优组:代理组编辑框里也有「测速地址」,只对这个组生效。
改完重启内核再测一次,把结果告诉我。
但有一点要纠正:那次 HEAD 请求不是 Cloudflare 处理的。测速是内核让节点服务器去访问
www.gstatic.com,Cloudflare 只负责你到节点之间那段 WS + TLS 隧道,它看不到也碰不到 gstatic 那个请求。所以EOF更可能是:① VMess 握手参数对不上(alterId / 加密方式 / ws path、Host),服务端直接关连接;② 你的服务器不允许出站到 80 端口。换成 https 测速地址能顺带排掉 ②。另外第一次要的东西还是缺:一条脱敏的节点链接(uuid、域名打码,但要保留
aid、scy、net、path、host、tls、sni这些字段)。小火箭能用而这里不行,十有八九差别就在这几个字段上,没有它我只能猜。
liandu2024 在 Open-Box #151 中说明，单个代理 DNS 上游经节点卡住时只能等待客户端超时；Open-Box v0.1.230 起允许直连侧和代理侧各配置最多四个上游，并使用 sing-box 1.14 的 evaluate + race 并发查询，采用最先返回的结果。对于直连 UDP 上游自身的偶发丢包，也可增加备用上游或改用 TCP。
作者原文 · 预览@liandu2024查看完整动态你这组对照已经说明问题了:同样是 TCP/53,换成 8.8.8.8 之后 180 多次查询 0 超时 —— 不是内核的 DNS 模块有毛病,是代理 DNS 上游只有一个,它经节点卡住时只能干等到客户端超时。
v0.1.230 起改掉了这个限制:DNS 上游可以配多个,并发查询,谁先返回结果就用谁的。
- 位置:设置 → DNS 设置 →「DNS 上游」,右上角加号添加,选这条用在兜底直连还是代理;
- 同一侧的第一条是主上游,后面的是备用,一起并发查 —— 一个上游卡住,另一个正常就照常出结果;
- 每侧最多 4 个;没加备用上游时生成的配置和以前一字不差。
用的是 sing-box 1.14 自带的并发机制(evaluate + race),不是我们在外面轮询。
你第 3 点里那次 apple.com 超时走的是直连上游 223.5.5.5 的 UDP,和代理 DNS 不是一条路;你自己直查 223.5.5.5 也复现了 1/20,那是上游 UDP 偶发丢包 —— 现在直连侧同样可以加备用上游,或者把直连 DNS 的协议改成 TCP。
升上去配两个上游再用几天,没再复现的话我就关掉这条。
liandu2024 在 Open-Box #157 中说明，sing-box 为跳过 TUN 设置的 0x2024 标记仍会继续匹配 GL.iNet 的 VPN 断网保护黑洞规则，导致内核自身的直连和代理连接全部报 no route to host。临时可关闭 VPN 策略路由或断网保护；Open-Box v0.1.230 起会在更高优先级让该标记查询主路由表，并在停内核时撤销规则。
作者原文 · 预览@liandu2024查看完整动态找到原因了,你贴的
ip rule就是答案:9000: from all fwmark 0x2024 goto 9002 ← sing-box 装的"跳过 tun" 9002: from all nop 9910: not from all fwmark 0/0xf000 blackhole ← GL.iNet 的 VPN 断网保护 9920: from all iif br-lan blackhole内核自己发出去的流量会打上
0x2024这个标记,好让策略路由跳过 tun。但 sing-box 装的那条是goto一个空规则(9002 nop),查找不终止 —— 接着就撞上你固件的 9910:0x2024 & 0xf000 = 0x2000 ≠ 0,正好命中,整包丢弃。所以日志里直连和代理全部connect: no route to host,连国内 IP 直连都不通。两个办法:
1. 立刻能用:在 GL.iNet 后台关掉 VPN 策略路由 / 断网保护(Kill Switch),9910、9920 这两条就没了。临时验证可以直接:
ip rule del pref 9910(重启会回来。)
2. 升级到 v0.1.230 及以上:我们在内核启动时补了一条优先级更高的规则,让带这个标记的流量查到主路由表为止,到不了后面的黑洞:
8999: from all fwmark 0x2024 lookup main停内核时会自己撤掉,普通固件上行为不变。
升级后如果还不通,把新的
ip rule和logread -e sing-box | tail -n 40贴上来。
liandu2024 在 Open-Box #192 中说明，Open-Box 以内核 TUN 配合 auto_redirect 接管流量；auto_redirect 在 nft 中使用 TCP redirect 与 UDP TPROXY，终端 TCP 连接会在进入路由器转发前被重定向进内核，因此终端无需另设代理。若仍有流量未被接管，需要结合设备、应用、主路由或旁路由模式和目标域名规则结果排查。
作者原文 · 预览@liandu2024查看完整动态Open-Box 的入口用的就是这一套:内核以 tun +
auto_redirect接管,auto_redirect在 nft 里装的是 redirect(TCP)+ tproxy(UDP) 的重定向链,效果和你说的 "Redirect TCP" 是一回事 —— 终端的 TCP 连接在进路由器转发之前就被重定向进内核,不需要在终端上设代理。所以这项不用另外加。如果你遇到的是某类流量没被接管(某些设备、某些端口),那是另一个问题,麻烦说清楚:
- 什么设备 / 什么应用没走代理;
- 路由器是主路由还是旁路由;
- 「规则」页查那个目标域名的结果。
这样能具体看是哪一层没接住。
liandu2024 在 Open-Box #207 中说明，模拟终端测试会以 veth 和独立网络命名空间模拟新终端；ESXi 端口组需要允许“MAC 地址更改”和“伪传输”，混杂模式并非必需。其同时表示 Open-Box 不会修改 bridge-nf-call-iptables；该值为 1 时，桥内二层流量也会进入 netfilter，在旁路由同网段场景被重定向链处理，建议保持为 0，或将受影响设备设为“不进内核”。
作者原文 · 预览@liandu2024查看完整动态分开说这两件事。
1. 虚拟终端在 ESXi 下建不起来
这个是 ESXi 的安全策略挡的,不是 bug。「规则」页的模拟终端测试会建一对 veth(
obprobe0挂进br-lan,obprobe1放进独立网络命名空间),给它一个自己的 MAC,然后在里面跑udhcpc去问主路由要地址 —— 相当于临时插了一台新终端。ESXi 的 vSwitch / 端口组默认:
- MAC 地址更改:拒绝
- 伪传输(Forged transmits):拒绝
这两项任一为"拒绝",虚拟机发出来的、源 MAC 不等于网卡自身 MAC 的帧都会被 vSwitch 丢掉 ——
obprobe0的 DHCP 请求正好就是这种帧,所以必然udhcpc: no lease。要跑这个测试,需要在对应端口组上把 MAC 地址更改 和 伪传输 改成"接受"(混杂模式不是必需的,我们不抓包)。这只影响「规则」页的这一个测试功能,不影响正常分流和代理。
2.
bridge-nf-call-iptables=1时同网段间歇断网Open-Box 不会动这个 sysctl(代码里没有任何地方设置它),所以这是固件默认或别的软件打开的。
它打开之后,桥内的二层转发流量也会走一遍 netfilter,于是同网段设备之间本不该进内核的流量也会被内核的重定向链看到 —— 旁路由 + 同网段的场景下这正是断网的来源。建议保持
0:sysctl -w net.bridge.bridge-nf-call-iptables=0如果因为别的组件必须打开它,可以在「终端分流」里把受影响的设备设成「不进内核」,那些设备的流量会在进内核前就被放行。
麻烦你按第 1 条放开端口组策略再试一次虚拟终端,第 2 条确认一下 sysctl 关掉后断网是否消失,结果贴出来我再跟进。
liandu2024 在 Open-Box #201 中说明，安装和升级脚本会在 apk 或 opkg 环境检查并补齐 kmod-nft-queue，安装失败时只警告而不中断；该模块用于 sing-box auto_redirect 的 nft queue 表达式。若固件不允许安装额外内核模块，需要改用包含该模块的固件。
作者原文 · 预览@liandu2024查看完整动态安装和升级脚本本身会检查并补齐这个依赖(apk 和 opkg 都支持),装不上时只警告、不中断安装。手动装也可以:
apk add kmod-nft-queue || opkg install kmod-nft-queue
kmod-nft-queue是 sing-box 的auto_redirect用到的 nft queue 表达式需要的。如果固件本身不让装额外内核模块(部分官方固件是这样),那就像楼上说的换一个带这个模块的固件。先关掉,装完还有问题请重开。
作者说明当前 Linux 构建直接在进程内运行 mihomo，安装的 helper 不会被使用；0.9.3 先明确支持系统代理，pkexec、Unix socket 和 systemd 状态接线及真实发行版测试仍属后续变更。
作者原文 · 预览@Nemu-x查看完整动态Thanks for the precise report, and sorry for the confusing behaviour.
This is not Wayland-specific. Two things were going on:
The Linux build currently runs the mihomo core in-process and does not talk to the privileged helper service at all. So TUN mode has no root path on Linux yet, and a successfully installed service would not have been used anyway.
"Install service" launched the installer without elevation. The password prompt you saw came from systemctl (polkit), after which the copy into /usr/local/lib/sloth-clash failed with a permission error that never made it to the UI.
0.9.3 replaces the dead button with an honest message: the helper is not wired on Linux yet, and Proxy mode (system proxy) is the supported path for now.Proper privileged TUN on Linux (pkexec-elevated install, unix-socket IPC like on macOS, systemd status) is scheduled as its own change. The service side is already Linux-ready; the desktop side needs the wiring plus testing on a real distro. I'll keep this issue open to track it and will ping here when there is a build to try. If you are up for testing an early build on Garuda/Sway when it's ready, that would help a lot.
针对 XHTTP 无法使用的问题，作者说明这不是 OwnBox 的 bug，并区分了 Sing-box 与 Xray 的实现范围。
作者原文 · 预览@Own716查看完整动态这不是 bug。
Singbox 内核一直不支持 XHTTP。
XHTTP 是 Xray 发的。
Sitoi 引用 mihomo 源码说明 ClashBar 不会改写用户配置；建议向 mihomo 提交支持请求，或手动将订阅转换为 proxy-providers。
作者原文 · 预览@Sitoi查看完整动态https://github.com/MetaCubeX/mihomo/blob/Alpha/hub/route/configs.go
mihomo 源码中确实无法修改 DNS 配置，clashbar 不会考虑修改用户配置文件。
- 你可以尝试向 mihomo 提交 issue，让他们支持
- 你可以自己编写配置文件，将订阅转换成 proxy-providers，参考配置文件 https://github.com/Sitoi/ClashBar/blob/main/Sources/ClashBar/Resources/ConfigTemplates/ClashBar.yaml ，可以让ai 帮你修改
作者说明补丁统一 ReadPacket 的原子占用逻辑，并报告竞态检测与回归用例结果；v0.1.223 会连同 1.14.1-openbox-tcp8 内核下载，仍建议继续观察。
作者原文 · 预览@liandu2024查看完整动态你这份栈直接把问题指出来了,已定位并修好,v0.1.223 发出去了,内核版本
1.14.1-openbox-tcp8。是什么
问题在依赖库
github.com/sagernet/singv0.9.4 的CachedPacketConn:同一个 UDP 缓存包有两条"取走"的路,却用了两套不同的同步——
ReadCachedPacket()用原子标志taken.CompareAndSwapReadPacket()只是裸检查if c.buffer != nil并发时
ReadPacket检查完、还没来得及DecRef,缓存就被另一边置成 nil 了,于是refs.Add(-1)打在空指针上——正是你栈里的sync/atomic.(*Int32).Add buf.(*Buffer).DecRef buffer.go:297 bufio.(*CachedPacketConn).ReadPacket cache.go:187
addr=0x30正好是Buffer.refs的偏移。你那次slice bounds out of range [:1232] with capacity 0是同一个竞态的另一面:读到了已经Release回收的内存。你的栈里有
route.(*fakeIPNATPacketConn).ReadPacket,说明你开着 FakeIP,走 FakeIP 的 UDP 流量最容易撞上这条路径(不开 FakeIP 也有机会,只是概率低)。反过来还有一份:
ReadPacket先取走时不会置taken,随后的ReadCachedPacket仍会赢下 CAS,把一个Buffer已经是 nil 的包交给调用方——那是另一个空指针入口。怎么修的
让
ReadPacket也走同一个taken原子标志,谁抢到谁处理。上游 main 分支我今天核对过,至今仍是裸检查,所以这个补丁是 Open-Box 自己打的(也是我们第一个改依赖库而不是 sing-box 本体的补丁)。验证:
- Go 竞态检测器:打补丁前稳定报
DATA RACE(读 cache.go:182 / 写 cache.go:200),补丁后干净;- 三条回归用例进了内核构建,两个架构都跑;
- 反向验证:拿未打补丁的库跑,用例当场失败并打印出那个
Buffer:<nil>的包。你需要做的
面板里点升级到 v0.1.223。这一版会连内核一起下载(约 16 MB),不像前几版只下面板;升级过程中内核重启一次。
升完请留意一两天。如果还崩,麻烦再贴一次
logread -e sing-box | tail -n 80—— 那就是另一条路径,我接着查。感谢你把完整栈贴出来,没有这个定位不到。
liandu2024 说明后端设置可执行不可撤销的恢复出厂，目标分流页也可单独恢复默认规则；两项操作的影响范围不同，升级后即可使用。
作者原文 · 预览@liandu2024查看完整动态v0.1.222 已经加上了,而且是两个入口:
后端设置 → 恢复出厂设置(启停按钮那一行,分隔线后面那个红色按钮)
完全回到刚装好的样子:订阅、出站节点、目标分流、终端分流、链式代理、共享网络、面板外观设置、背景图、面板密码、流量统计与延迟历史全部清空,再按安装包自带的默认重新初始化;内核会停止运行。恢复后打开面板会像第一次那样让你重新设置密码。不可撤销,点之前有确认框。目标分流页右上角 → 恢复默认分流(加号左边那个回退图标)
只把目标分流恢复成安装包自带的那套(Speed / AI / Youtube …… 共 12 条),订阅、节点这些一概不动。想重配分流但不想全清的话用这个。面板里点升级即可。
sing-box-lx 当前只识别 sing-box 命名；LxBox 计划先用 contract_draft 覆盖 Xray 的 sessionIDPlacement/sessionIDKey，待别名同步后移除。
作者原文 · 预览@Leadaxe查看完整动态Живые vless+xhttp ссылки несут в
extraproto-имена Xray, а реестр читает только sing-box написание.Что теряется
В
extra(URL-encoded JSON) Xray пишет:{ "sessionIDPlacement": "cookie", "sessionIDKey": "stream_auth", "seqPlacement": "cookie", "seqKey": "part_index" }Запись
sessionPlacementсмотрит только:
extra.sessionPlacement/extra.session_placementquery.sessionPlacement/query.session_placement
sessionIDPlacement/sessionIDKeyни extra, ни query не читает.seqPlacementдоезжает (имя совпадает с каноном). Session id уходит в дефолт ядраpath, хотя сервер ждал cookie с кастомным ключом.Ядро sing-box-lx это уже документирует (
option/v2ray_xhttp.go): proto —sessionIDPlacement, JSON —session_placement. PARAM_MAP 002 то же:Config.SessionIDPlacement/SessionIDKey.Значения не дефолт дампа: дефолт placement —
path, дефолт ключа для cookie —x_session.cookie+stream_auth— настройка сервера.Что просим
В source записей
sessionPlacementиsessionKey(URI extra/query и Xray-JSON extra) добавить:
sessionIDPlacement→transport.session_placementsessionIDKey→transport.session_keyКанон extra по-прежнему первый.
sessionIDLength/sessionIDTableне трогать:"0"без таблицы — «не задано»; протащить без пары — ошибка ядра «must be set together».Пустые
host/path/modeиз extra не трогать (D-097).LxBox
До синка зеркала повесим оверлей
contract_draftна те же две записи. Снимем, когда алиасы будут в реестре.@Cursor (сессия LxBox)
在 Xray 配置字段校验讨论中，他表示多数软件会忽略未知字段，而 GUI 客户端可能把管理数据写入 JSON，修改这些字段可能损坏客户端。
作者原文 · 预览@Fangliding查看完整动态大多数软件来说好像都会忽略配置文件中的未知字段
有的GUI Client会往json中塞入他们自己的数据进行节点管理什么的 改了会损坏这些Client
OwnBoxs 频道说明 OwnBox 已上线 Windows，当前仅视为测试，部分功能待完善；项目仓库为 Own716/OwnBoxForWin，建议和 bug 可在 GitHub issue 反馈。
频道原文 · 预览@OwnBoxs查看完整动态OwnBox 已上线 Windows
https://github.com/Own716/OwnBoxForWin
目前仅是测试，有些功能还是挺好玩的，也有部分有待完善。
可能效果与市面上的那些相差太远，请谅解。
有任何功能建议、想法，或者 bug，可以在 GitHub 上提 issue（议题）。提的东西 90% 概率会实现。嘿嘿嘿😝
liandu2024 在 Open-Box #136 中说明，v0.1.213 在订阅编辑框加入「节点域名解析」：左侧填写机场提供的 DoH 地址，DoH 主机名为域名时右侧填写用于解析它的 DNS；保存后重启内核，只影响该订阅节点服务器域名、订阅测速和链式代理测速，诊断包会抹掉 DoH 主机名与路径。自动从订阅带出 DoH 暂未实现。
作者原文 · 预览@liandu2024查看完整动态v0.1.213 加上了:订阅编辑框里的「节点域名解析」。
- 左边填机场给的 DoH 地址,可以带端口和私有路径,如
https://dns.example.net:2096/<私有路径>;- DoH 地址是域名时,右边填一个解析它用的 DNS(IP,UDP 53),如
223.5.5.5。保存后重启内核生效。它只用来解析这份订阅的节点服务器域名(这份订阅的节点出站带上
domain_resolver),普通网站和局域网 DNS 不受影响;订阅编辑框里的测速、以这些节点当上游的链式代理测速也按它解析。诊断包里会把 DoH 的主机名和路径抹掉。「从订阅里自动带出 DoH(nameserver-policy / proxy-server-nameserver)」暂时没做,先手动填。
liandu2024 在 Open-Box #187 中说明，v0.1.213 的「设置 → 终端分流」可按 IP 或 MAC 选择终端，并把处理方式设为「只让这些终端进内核」；有这类规则时局域网只有列出的终端进入内核，其余终端和未安装 Open-Box 一样，DNS 也不经内核。按 MAC 最稳；按 IP 依赖防火墙标记，IPv6 需另列；需要 auto_redirect，纯 TUN 兼容模式下白名单不生效。
作者原文 · 预览@liandu2024查看完整动态v0.1.213 终端分流新增「只让这些终端进内核(白名单)」,终端可以按 IP 或按 MAC 填(编辑框里两个页签二选一)。
用法:「设置 → 终端分流」新建一条规则,选好终端,处理方式选「只让这些终端进内核」,保存后重启内核。有这类规则时,局域网里只有列出来的终端进内核,其余终端和没装 Open-Box 一样(DNS 也不经内核)。
几点说明:
- 按 MAC 最稳,IP 变了也认得出;
- 按 IP 时靠防火墙打标记实现,名单外的终端不走 mwan3 多 WAN 分流;终端有 IPv6 的,v6 地址要另外列;
- 需要 auto_redirect(默认就是开的),纯 tun 兼容模式下白名单不生效。
dyhkwong 在 Exclave #485 中说明，Exclave 已移除非 SIP003 的插件支持；NaiveProxy 适用 grandfather clause（保留例外）。除非新协议足够好且无法用 Go 实现，他认为不会再新增插件。
作者原文 · 预览@dyhkwong查看完整动态Plugin (not SIP003 plugin) support has been removed. NaiveProxy is applicable to the grandfather clause. Unless a new protocol is good enough like NaiveProxy and can't be written in Go, I don't think there will be any new plugins.
liandu2024 在 Open-Box #175 中说明，概览连接数、内存、流量与连接等实时数据使用 /api/controller-ws/… WebSocket，其他页面使用普通 HTTP；自定义域名反向代理若未转发 WebSocket Upgrade 头，就会只缺少这些实时数据。nginx 需要使用 HTTP/1.1 并转发 Upgrade、Connection 与 Host，Lucky、NPM 等工具需开启 WebSocket 支持。
作者原文 · 预览@liandu2024查看完整动态概览的实时数据(左下角的连接数和内存、概览页的流量和连接)走的是 WebSocket(路径
/api/controller-ws/…),其他页面是普通 HTTP 请求。反向代理没转发 WebSocket 的升级头时,就正好只有这几处是空的。以 nginx 为例,要加上这几行:
location / { proxy_pass http://<路由器IP>:2026; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; }Lucky、NPM 这类工具一般是在反代规则里勾上「WebSocket 支持」。
xchacha20-poly1305 在 husi #954 中回复 PR：希望该功能更接近 zashboard，提供全局搜索栏，并区分「节点搜索」（只保留匹配节点并隐藏没有匹配的代理组）和「代理组搜索」（过滤匹配关键字的代理组）；他还希望保留针对单个代理组的搜索，并移除当前的 8 项限制。
作者原文 · 预览@xchacha20-poly1305查看完整动态Thank you for your pull request! But I'd rather like this feature can more like zashboard:
- A global search bar with two mode
- Node search: only keeps the matched node and hide the proxy set that have no matched.
- Proxy set search: filter the proxy set that matches the search key word.
- Search for a special proxy set. This is want you have done currently. And I want to remove the
8limitation.
yiguodev 在 Xray-core #6773 中说明，已用四组真实 Linux 场景复测确认无 DNS、空 DNS 和 gateway-source-IP 到 blackhole 等修复有效；但新增只对 example.com 使用 localhost 且 finalQuery/skipFallback 的上游后，接管会被接受而查询 4/4 超时。他认为应在可选解析路径可能依赖系统解析器时拒绝接管，并在 README 明确 source-port-independent DNS path 等限制。
作者原文 · 预览@yiguodev查看完整动态Thanks for the three commits and the explicit clarification of their scope. I retested
71b70211daf9ebe25500f64d8f8634be32fd2c3dwith four real Linux matrices, nine scenarios each. This follow-up focuses on functional behavior rather than style.Confirmed fixes
- No
dnssection, an empty DNS configuration, and the gateway-source-IP → blackhole case now correctly refuse takeover while system resolution remains usable.- The dirty-state fix works: real private-bus ACL denials cause another revert attempt at shutdown. After restoring the private policy, I captured successful Revert method-return replies, correlated by caller and serial—not merely the absence of an error log. With permission still denied, the retry receives an error and the per-link state disappears with the TUN on exit.
Please keep the small
app/dnsaccessor; covering the empty-server case is justified. The real-router tests are also useful, CI-friendly regression coverage. They test decisions rather than DNS responses, but that does not negate their value.New counterexample: mixed independent and system-resolver upstreams
Starting from the working independent-upstream configuration, add this DNS server:
{ "address": "localhost", "domains": ["full:example.com"], "finalQuery": true, "skipFallback": true }The takeover is accepted, but
example.comtimes out in 4/4 runs. Queries reach the DNS outbound, and logs show lookups returning to the private system stub and timing out. An unrelated domain resolves successfully before and after the failing query in the same instance.
UsesSystemResolver()returns false as soon as any upstream is non-local, whereas the domain-specific selection can still choose only localhost. This is an additional configuration case, not a claim that your no/empty-DNS fixes failed.A conservative fix would refuse takeover when a selectable resolution path may depend on the system resolver, rather than checking whether all clients do. A
MayUseSystemResolver-style check and a mixed-server regression case would make that distinction explicit; do not silently remove the user's local resolver.Source ports: the limitation you already disclosed
I acknowledge your statement that the representative source port cannot predict the real query's port. The live consequence is reproducible: with source port
49152→ DNS and remaining TUN/53 traffic → blackhole, preflight accepts takeover; real queries from49152answer, while49153and the system resolver's actual ephemeral ports fail, in all four runs.Could the README explicitly require a source-port-independent DNS path and clarify whether unsupported configurations should be refused? We should avoid presenting the synthetic check as a guarantee for arbitrary routing rules. I am not asking for a general Router redesign in this PR.
Scope and evidence limits
Deferring godbus is fine. Fixture duplication and missing full TUN E2E coverage are not additional observed functional failures. The remaining
.Base(err).Base(cause)overwrite is a diagnostic improvement, not evidence that cleanup is skipped.The real TUN/gVisor, DNS and resolvectl path ran inside private mount/PID namespaces with a private bus/resolved. This does not establish normal-host authorization or general leak coverage. Four seconds is the client's timeout limit.
One supplementary rollback-recovery run also had a DNS timeout before policy restoration; Revert succeeded and the next identical run answered normally. That failure is retained and unexplained—not attributed to rollback or dismissed as proven network noise.
All 36 Core instances exited 0, their TUNs disappeared automatically, and all four host-preservation audits passed.
作者原文 · 预览@RPRX查看完整动态@Risaro 0xe5554cceca6db722bebc4028b466d20e33d63029534ecb5875218943742cca90
我觉得最可贵的是能实时测试 Google Drive 等 backend 并改进 XDRIVE 的代码，
是否 vibe 的倒不重要，可能明年全靠 AI 都行目前比较需要一份 Google Drive API 配置教程，半年前我和 @iambabyninja 通过邮箱讨论过，但不确定是否适用于这个 PR
HyNetworks 团队表示，经过内部讨论和社区请求，已重新公开 OpenGFW 仓库；目前暂无大幅更新计划，后续将把更多精力投入 Hysteria 和其他反审查项目，同时保持仓库公开、接受 PR 并按需要发布新版。
作者原文 · 预览@hysteria_releases查看完整动态Earlier this year, we removed the OpenGFW repository from GitHub. This decision was made primarily because we discovered that Geedge Networks, a company with close ties to the Chinese government that sells censorship solutions to governments around the world, was plagiarizing OpenGFW's code and incorporating it into its products.
OpenGFW was created for purposes such as network research, ad blocking, and parental controls. It was never intended to enable or assist state censorship. Seeing the project used in this way was fundamentally at odds with why we built and released it.
After further internal discussion and requests from the community, we have decided to make the repository publicly available again for the benefit of the broader community.
For now, we do not plan to actively continue developing OpenGFW ourselves. Instead, we intend to focus more of our efforts on Hysteria and other upcoming anti-censorship projects. However, if members of the community would like to continue developing OpenGFW, they are more than welcome to do so. We will keep the repository available, accept pull requests, and publish new releases as appropriate. Thank you to everyone in the community who has supported our projects and shared their feedback with us.
今年早些时候我们将 OpenGFW 的代码仓库从 GitHub 上撤下。做出这一决定，主要是因为我们发现 Geedge Networks（积至海南信息技术有限公司） ——一家与中国政府关系密切、向世界各国政府出售网络审查方案的公司——抄袭了 OpenGFW 的代码，将其整合进自己的产品中。
OpenGFW 是为网络研究、广告拦截、家长控制等用途而开发的。我们不希望它被政府用于实施或协助实施网络审查。看到这个项目被用于这样的目的，与我们开发并开源它的初衷完全背道而驰。
经过进一步的内部讨论，同时考虑到社区成员的呼声，我们决定重新公开 OpenGFW 的代码仓库，让更广泛的社区能够继续受益于这个项目。
目前我们暂无大幅更新 OpenGFW 的计划。接下来我们希望将更多精力投入 Hysteria 以及其他即将推出的反审查项目。不过，如果社区成员愿意继续推动 OpenGFW 的开发，我们保持欢迎。我们会继续保持代码仓库公开，接受 PR，并在需要的时候发布新版。感谢大家一直以来对我们项目的支持，以及意见和反馈。
https://github.com/HyNetworks/OpenGFW
频道原文 · 预览@projectXtls查看完整动态💬 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”，以及检测配置：需开启 mux.cool ~~可能还需要一些…