v1.0.33 — 降低 NPanel 用户快照同步内存峰值

本版发布 x86_64 与 aarch64 两个 Linux GNU 架构的 Node，内部版本为 0.4.31。

配套升级要求

• SimNet 客户端仍要求 SDK 0.4.28 及以上（独立 TCP、capability bit3）。从 v1.0.32 升级可沿用现有客户端、配置和 systemd 单元。
• NPanel 可继续使用现有用户列表 API、ETag 和 304 响应。v1.0.32 的订阅凭据不限目标语义继续适用。

变更

• 降低大用户列表同步的内存峰值。面板缓存与 Node 运行时共享不可变用户快照。收到 HTTP 304 时复用已校验用户表并更新快照时间。全量响应按容量档位缓冲，并串行处理刷新，避免多份全量响应同时占用内存。
• 保持用户快照与 ETag 一致。完整校验通过后一起提交。收到无效快照、重复用户或响应读取超时时，继续使用上一份有效快照，并遵循原有陈旧期限。
• 修复 VLESS Vision 部分写入。底层短写或暂不可写时保留待发送的帧尾，完整刷新后再切换 Direct，避免截断或丢失数据。

本地验证

• 两个架构均按 GLIBC 2.28 构建并通过 ELF 架构、加载器、包内文件及 SHA256 校验。
• AMD64 Ubuntu 20.04 与 ARM64 Debian 10 容器均在无网络、只读模式下通过 dbk-node --check。
• cargo test --workspace 通过 2,664 项，6 项忽略。工作区格式检查和 Clippy -D warnings 通过。
• 完整 cargo xtask ci 未通过。静态门禁报告 59 项既有问题，依赖审计报告许可证和安全公告问题。相对 v1.0.32，锁文件中的第三方依赖版本相同。
• 生产部署、真实节点流量和 Linux 2 GB 内存实测待验收。

产物身份

• GitHub 安装仓库标签为 npanel-dev/Daybreak v1.0.33，指向安装脚本所在提交。
• Rust 分支为 dev/simnet-session-isolation，源码提交为 518158eca609e7ec3fcdc527df5894453c73a767，构建工作区为 dirty=false。
• Cargo.lock SHA256 为 49fb21ff1ae00894ccc3230e7d127c04e8cc8e8c5f704c6deced96f2f74da56c。
• 使用 rustc 1.94.1 (e408947bf 2026-03-25) 在 macOS 上通过 cargo-zigbuild 交叉构建。构建时间（UTC）为 x86_64 2026-11-05T17:49:29Z、aarch64 2026-11-05T17:50:31Z。

四个 Release 附件为两架构 tar.gz 和各自的 .sha256。包内包含 dbk-node、systemd 单元、配置样例和 VERSION。

升级

已安装节点可重跑 install.sh，脚本会下载最新 Release、替换二进制并保留配置。若现有配置中的 report_online 为 false，升级时带上 --no-report-online。

v1.0.32 — 订阅凭据不限目标（面板标记 unrestricted_targets）

本版发布 Node 两个 Linux GNU 架构，内部版本升到 0.4.30。相对 v1.0.31 只改面板快照解码与
目标授权逻辑，线上协议（wire）与配置不变。Node 包不包含 SDK 或 Android App。

配套升级要求

• SimNet 客户端要求不变：仍须嵌入 SDK 0.4.28 及以上（独立 TCP、capability bit3）。
  从 v1.0.29 / v1.0.30 / v1.0.31 升到本版不需要换客户端，也不需要改配置；
  node.toml 样例与 systemd 单元与 v1.0.31 逐字节相同。
• 本版是 MoonPanel「订阅 key 不限目标」功能的前置条件：面板按节点 status 上报的
  version 门控该字段，只对 0.4.30 及以上的节点输出；旧节点收到空 targets 会拒收整份
  快照并在租约到期后拒绝所有用户。因此先把全部节点升到本版，再发布对应的面板。
  面板未升级时本版行为与 v1.0.31 完全相同。

变更

• 订阅凭据不限目标（crates/dbk-control、apps/dbk-node-state）：面板快照里带
  unrestricted_targets: true 的凭据（软路由用的订阅 URL key）跳过目标白名单、按请求目标
  拨号并放行 UDP；targets 允许为空，附带目标的 DNS 解析失败不再拒绝该凭据。
  App 的会话 key 永远不带该字段，行为不变。
• 撤回即撤销：同一 key 前后两份快照该字段取值不同（面板回滚）即换会话 epoch，
  在途流在 50ms 内被撤销。v1 用户身份摘要不剥离该字段；非 bool 取值拒绝整份快照。
• apps/dbk-node 中继代码零改动：无固定地址时本就走 resolver.connect。

本地验证

• dbk-control、dbk-node-state、dbk-node 三个 crate 全量 cargo test：21 个套件 341 项通过；
  新增解码用例 3 条、授权用例 2 条（含真实 socket：空 targets 建流、撤回标记后关闭）。
  变异验证：去掉「标记翻转换 epoch」的比较后撤回用例转红，还原后转绿。
• cargo fmt --check 与三个 crate 的 clippy -D warnings 通过。
• 静态包校验：两架构 VERSION 为 dirty=false，ELF 依赖 GLIBC 最高 2.28。
• 隔离加载冒烟：ARM64 Debian 10 与 AMD64 Ubuntu 20.04 容器内 --network none --read-only
  执行 dbk-node --check，均 exit 0（配置校验通过），未启动监听或业务流量。
• 未做：cargo xtask ci 全量门禁、节点部署与现场验证、软路由真机验收。

产物身份

• GitHub 安装仓库标签：npanel-dev/Daybreak v1.0.32；该 tag 的提交只标识脚本/文档，不是 Rust 实现源码。
• Rust 分支：dev/simnet-session-isolation；源码提交 be94e72b5576b9b0486e194dbeb03dee9a515991，
  构建前工作区干净（dirty=false）；内部版本 0.4.30。
• Cargo.lock SHA256：83b4d8d7b4bd1b38dbbe1111a91370b89d6087913144e77881f1af1ee7ff1b67（相对 v1.0.31
  只变了工作区 crate 的版本号）。
• 工具链：rustc 1.94.1 (e408947bf 2026-03-25)，macOS 上 cargo-zigbuild 交叉构建；
  Node 构建时间（UTC）：x86_64 2026-10-19T18:46:11Z，aarch64 2026-10-19T18:46:28Z。

四个 release 资产为两架构 tar.gz 及各自同名 .sha256；包内保留可执行文件、
systemd 单元、配置样例与 VERSION。

升级

已装机器重跑 install.sh 即升级到本版（自动取 Releases latest、只换二进制、保留配置）。
升级前先确认 /etc/daybreak/node.toml 里的 report_online：为 false 时须带 --no-report-online。

mihomo-sdk-v1.0.0 — mihomo 内核客户端 SDK 首个发布（Android / iOS / macOS / Windows）

这是客户端 SDK，不是 Node。 标签 mihomo-sdk-v1.0.0 与 Node 的 vX.Y.Z 相互独立。本 Release 没有标为 Latest，install.sh 仍然安装和升级 Node，不受影响。
它也不是 Rust 的 dbk-sdk：本 SDK 基于 mihomo（Clash.Meta）内核，内置 SimnetV2 出站，供 Flutter / Dart 客户端集成。

配套要求

• Node：v1.0.29 及以上（内部 0.4.28）。SimNet 每条 TCP 独立建连（capability bit3），UDP 按入口关联复用 Datagram 载体。连接 ≤ v1.0.28 的旧共享复用 Node 会在业务开流前失败，没有回退。
• 建议节点升级到 v1.0.31。v1.0.29 / v1.0.30 在多用户同时建连时会出现最长 30 秒的监听自锁。本 SDK 把握手许可持有到 ServerAccept，单个客户端自己不会触发这个问题，但多用户场景仍需要节点升级。

内容

主要能力

• 统一 JSON 接口：各平台都是 invokeMethod 一个入口，20 个方法，包括初始化、配置热重载、关闭、节点列表与切换、并发测延迟、流量、连接、模式、日志事件、系统 DNS。Dart 端 MihomoService 在各平台用法一致。
• SimNet 提速：
  • 预建载体：近 60 秒内有新连接时，保持最多 2 条已认证载体备用；
  • 冷建连时 ClientOpen 和 Open 一次发出；
  • S5 握手一次发完，遇到不兼容的服务器自动回退；
  • 实测（SDK → SimNet → Node → S5 链路）：新连接首包延迟从 415ms 降到 151ms，6 连接突发与 VLESS 持平。
• 连接突发：每个出站最多 256 条载体，满了改为排队等待，并回收空闲超过 30 秒的流，不再直接拒绝（97d7ce9）。
• 桌面 TUN：参考 FlClash 的做法。macOS 内核进程通过 Unix socket 通信，并校验 socket 属主；Windows 系统服务通过回环 TCP + 令牌通信，令牌目录受权限保护，homeDir 限定在用户个人目录内，内核崩溃后自动重启。会话结束时内核会关闭 TUN、恢复路由。

接入方法见 GUIDE.md。

本地验证

• go test -race ./mobile/... ./transport/simnet/ ./adapter/... 通过。
• 五个平台二进制内的版本字符串均为 9781cd6；架构齐全；Windows 为 GUI 子系统 PE。
• macOS：Dart 集成测试用真实 MihomoCore 跑 3 项（Unix socket、TCP + 令牌、错误令牌被拒绝），全部通过；框架实际调用通过。root 实测 TUN：utun 接管默认路由，经 TUN 出网，关闭后路由恢复。
• iOS：iPhone 16 Pro 模拟器内实际调用通过；真机 arm64 链接通过；文档中的 NetworkExtension 示例能编译。
• 未做：
  • Android 真机或模拟器运行，以及 VpnService TUN；
  • iOS NetworkExtension TUN，以及扩展的内存实测；
  • Windows 上的任何运行：服务安装、卸载，wintun TUN，PowerShell 和注册表脚本。只做了交叉编译、vet 和代码审查；
  • 客户设备验收。

产物身份

• 源码：vfawn/mihomo main 分支，提交 9781cd60dc310dfd77e228863ec876698bcb1c39，构建前工作区干净。
• 工具链：Go 1.27.1，gomobile（sagernet v0.1.13），Android NDK 28.2，Xcode 26.6（iOS SDK 26.5）。
• 构建标签：Android with_gvisor,cmfa；其余平台 with_gvisor；Windows 另加 -H windowsgui。
• 构建时间（UTC，2026-10-17）：Android 20:03，macOS 框架 20:42、内核 20:42，Windows 20:42，iOS 20:44。

包内每个二进制的 SHA256 见 mihomo-sdk-v1.0.0-SHA256SUMS.txt。

v1.0.31 — 修复认证门等待导致的监听自锁

本版发布 Node 两个 Linux GNU 架构，内部版本仍为 0.4.28（Cargo 版本未变）。相对 v1.0.30
只改 Node 监听的准入逻辑，线上协议与配置不变。Node 包不包含 SDK 或 Android App。

配套升级要求

与 v1.0.29 / v1.0.30 相同：SimNet 每条 TCP 独立建连（capability bit3），须与嵌入 SDK 0.4.28
的客户端配套，旧共享 TCP 客户端仍不能混用。从 v1.0.29 / v1.0.30 升到 v1.0.31 不需要换客户端，
也不需要改配置；node.toml 样例与 systemd 单元与 v1.0.30 逐字节相同。

v1.0.29 / v1.0.30 的节点建议尽快升级：下面这个问题在多用户同时建连时可稳定触发。

修复

• 监听自锁（apps/dbk-node/src/listener.rs）：accept 循环在准入时原地等待进程级认证门
  （16 个许可），等待期间不再推进已准入的连接；而许可只在这些连接认证结束时归还。
  第 17 条已接受的连接会让整个监听停转，直到 30 秒阶段期限才恢复。客户端连发
  ClientOpen/Open、或多个用户同时建连即可复现，表现为节点间歇性 30 秒连不上。
• 现在等门时与已准入连接的推进同处一个 select，许可能被及时归还；worker panic 仍按原合同上报。

本地验证

• 新增回归测试 waiting_for_the_authentication_gate_keeps_admitted_handshakes_running：
  还原修复后失败、修复后通过（发布前实测）。dbk-node 监听相关 6 项测试全部通过。
• 静态包校验：两架构 VERSION 为 dirty=false，ELF 依赖 GLIBC 最高 2.28。
• 隔离加载冒烟：ARM64 Debian 10 与 AMD64 Ubuntu 20.04 容器内 --network none --read-only
  执行 dbk-node --check，均 exit 0（配置校验通过），未启动监听或业务流量。
• 未做：完整 workspace 测试 / CI、节点部署与现场多用户并发验证、客户设备验收。

产物身份

• GitHub 安装仓库标签：npanel-dev/Daybreak v1.0.31；该 tag 的提交只标识脚本/文档，不是 Rust 实现源码。
• Rust 分支：dev/simnet-session-isolation；源码提交 0f93c81071c84a472d99cf9a9de6429a47b63adf，
  构建前工作区干净（dirty=false）；内部版本 0.4.28。
• Cargo.lock SHA256：52492e560c95c88234dfb97d6983393f5106bd4431cf0e0d7e253d888442df1e（与 v1.0.30 相同）。
• 工具链：rustc 1.94.1 (e408947bf 2026-03-25)；Node 构建时间（UTC）：x86_64
  2026-10-15T21:43:26Z，aarch64 2026-10-15T21:43:36Z。

四个 release 资产为两架构 tar.gz 及各自同名 .sha256；包内保留可执行文件、
systemd 单元、配置样例与 VERSION。

升级

已装机器重跑 install.sh 即升级到本版（自动取 Releases latest、只换二进制、保留配置）。
升级前先确认 /etc/daybreak/node.toml 里的 report_online：为 false 时须带 --no-report-online。

v1.0.30 — Node 独立 TCP 中继降 CPU（wire 不变）

本版发布 Node 两个 Linux GNU 架构，内部版本仍为 0.4.28（Cargo 版本未变）。相对 v1.0.29
只改 Node 中继的写出与读缓冲路径，线上协议与配置不变。Node 包不包含 SDK 或 Android App。

配套升级要求

与 v1.0.29 相同：SimNet 每条 TCP 独立建连（capability bit3），须与嵌入 SDK 0.4.28 的客户端配套，
旧共享 TCP 客户端仍不能混用。从 v1.0.29 升到 v1.0.30 不需要换客户端，也不需要改配置；
node.toml 样例与 systemd 单元与 v1.0.29 逐字节相同。

主要变化

• Single writer 批量写出（dbk-proto-simnet）：已排队的 Data 至多 4 帧合并为一次写出、
  一次 flush；每帧仍各自独立 nonce/HMAC，帧格式不变。
• ByteBridge 合并读（dbk-mux）：Bytes 模式 poll_read 一次取走已排队的多个块，少一轮唤醒。
• relay 缓冲自适应（dbk-node-state）：中继读缓冲从 16 KiB 起，读满后扩至 64 KiB。
• 提交说明记录的实测：下行每 GB Node CPU -28%、上行 -12%。本次发布没有在节点上重新跑分，
  该数字不代表现场吞吐提升。

本地验证

• 与 v1.0.29 的源码输入清单（SHA256 fe7c3374…）逐文件对比：构建输入只差上述 9 个源文件；
  包内 dbk-node.service、node.toml.example 与 v1.0.29 逐字节相同。
• 改动范围测试：dbk-node-state tcp_relay 8 项、dbk-mux byte_bridge 19 项、
  dbk-proto-simnet single 29 项全部通过。
• 静态包校验：两架构 VERSION 为 dirty=false，ELF 依赖 GLIBC 最高 2.28。
• 隔离加载冒烟：ARM64 Debian 10 与 AMD64 Ubuntu 20.04 容器内 --network none --read-only
  执行 dbk-node --check，均 exit 0（配置校验通过），未启动监听或业务流量。
• 未做：完整 workspace 测试 / CI、节点部署与现场吞吐对比、客户设备验收。

产物身份

• GitHub 安装仓库标签：npanel-dev/Daybreak v1.0.30；该 tag 的提交只标识脚本/文档，不是 Rust 实现源码。
• Rust 分支：dev/simnet-session-isolation；源码提交 d500a8480be0e2abcd9aa90f4ce4ddcc6affc573，
  构建前工作区干净（dirty=false）；内部版本 0.4.28。
• Cargo.lock SHA256：52492e560c95c88234dfb97d6983393f5106bd4431cf0e0d7e253d888442df1e。
• 工具链：rustc 1.94.1 (e408947bf 2026-03-25)；Node 构建时间（UTC）：x86_64
  2026-10-15T20:42:33Z，aarch64 2026-10-15T20:42:44Z。

四个 release 资产为两架构 tar.gz 及各自同名 .sha256；包内保留可执行文件、
systemd 单元、配置样例与 VERSION。

升级

已装机器重跑 install.sh 即升级到本版（自动取 Releases latest、只换二进制、保留配置）。
升级前先确认 /etc/daybreak/node.toml 里的 report_online：为 false 时须带 --no-report-online。

v1.0.29 — SimNet 每 TCP 独立连接、UDP 按关联复用

本版发布 Node 两个 Linux GNU 架构，内部版本 0.4.28；配套客户端 SDK 为
0.4.28，本批重编 Android 与 macOS。Node 包不包含 SDK 或 Android App。

配套升级要求

本版改变 SimNet TCP 连接模型，不能与旧共享 TCP 客户端混用。新 SDK 与新 Node
通过已认证 capability bit3 确认独立 TCP；新 SDK 连接不支持 bit3 的旧 Node 时，在
业务 Open 前失败。新 Node 的 Datagram 会话只接受 UDP，不接受旧 TCP mux Open。
没有 shared 配置、旧池旋钮或自动回退；旧 session_pool_size JSON 键明确拒绝。

请将 Node 与嵌入 SDK 0.4.28 的客户端配套切换。旧发布中的「新旧任意组合互通」
不适用于本版。本次只重编 Android/macOS SDK，其余平台的旧库不能标为支持新模型。
普通 VLESS 的协议路径没有因此改成 SimNet；本次升级要求针对 SimNet TCP。

主要变化

• 每条 TCP 业务重新建立独立 TCP/TLS/carrier 和认证会话，最多一个 TCP Open。
  Raw、H2、WebSocket 和已有 XHTTP 分支都经过同一实际拨号路径，不共享父 TCP。
  TCP 专用 IO 使用实际缓冲和背压，不使用旧应用信用、WU 或通用 TCP mux actor。
• UDP 同一入口关联共用一条 Datagram 会话，关联内各目标分别开流；不同关联、
  节点配置或授权域不共享会话。保留原 Datagram 帧、认证和数据报边界。
• 配套有界资源账本、认证拨号门、取消与真实关闭屏障。SDK 的 64 MiB 是自管
  backing 额度，256 是 owner 总上限；不能解释成进程 RSS 或 256 个 UDP 会话保证。
  TLS/H2/WS、relay、内核与 TUN 缓冲另计。
• 初始准入/首 Open 为 30 秒；已交付业务空闲或写出无进展为 300 秒；单向 FIN
  后按 30 秒无业务进展收尾，正常 full Drop 以同一个 30 秒绝对期限覆盖主任务和
  载体后代。已开始的系统 DNS 不能靠 abort 强停，真实 join/stop 可能超过 30 秒。
  更短调用方期限仍优先；撤权和 stop 立即取消，不继续排空禁止的字节。
• 防重放记录覆盖原 30 秒槽、±2 槽的完整 150 秒跨度，进程内共享，不随短 TCP
  或监听重建清空。没有重新分配历史 bit2、修改旧固定认证向量或增加未分配 TLV。
• 用户速率桶继续由同 key 的全部会话、两个方向共享。无 producer 时仍保留未补满
  的桶债务，重连不能白领满桶；仅无 producer 且桶已补满或原 rate=0 才回收。
  原速率、桶深、IP 设备去重、read 字节计费算法保持。
• SDK session=null，新增 outbound_connections 表示同寿资源账本；保留原
  connections.* 业务路由计数。探测成功不代表持续 established，也不是单独的 VPN
  健康判据。C ABI 未改。

本地验证与性能边界

本次功能验收来自指定单元/文件及先前阶段证据，未重新执行完整 workspace/CI。
Raw 8 个并行 TCP 对应 8 carrier/8 Open；同关联两目标为 1 carrier/2 Open，另一
关联使总数成为 2 carrier/4 Open。四份回显及真实收尾后的 owner/dial/backing 均核验。
此前 Raw/H2/WS/XHTTP 的 90 秒停读恢复证据保留；256 idle 仅验证了 Raw。
限速债务先 RED，修改文件 6/6 与维护单元 2/2 GREEN；SDK DNS 业务边界 3/3、
FFI JSON 4/4、实际 FFI 入口 1/1，以及修改范围的 lint/格式/实际 AST 核验通过。

本机性能采集五组×0/10/25/100 ms，共 20 例结束，不是 20 例全通过。
新 Single 与实际普通 VLESS/REALITY 各 4/4 成功；变更前 913 项 dirty 输入的冻结
旧构建，以及同旧信用引擎 shared/independent 两组，共 12 例在慢消费者恢复时截断，
旧 executable exit=101、运行器 exit=1 均保留。该旧快照不是 v1.0.28 发布包。
新成功组实际停读至少 90 秒后完整校验 64 MiB，再完成双向各 8 MiB；Single 的
Node 根关闭四例观察完成，外部 Xray 的该字段为 null。

该负荷每方向总限速约 100 Mbps，延迟为用户态字节交付延迟，不能证明真实 TCP
RTT、丢包或最高吞吐。新 Single 没有显示比 VLESS 更快，冷连接 TTFB 较高。
旧引擎改成物理独立仍截断，因此共享不是全部稳定性问题的解释；旧 typed 关闭原因
缺失，不把整套 IO/预算/生命周期变化唯一归因删除信用。性能证据来自优化测试产物，
不能代替以下重新构建的 release 二进制现场跑分。

完整 CI、实际 TUN、同 S5 第二跳、真实丢包、Vision 内层 TLS及部署/真机接受仍
未验收；本次两架构 Node 与 Android/macOS 出包不等于五平台 SDK 全部重新验收。
最终静态包校验与隔离加载冒烟结果：两个架构静态包/ELF/GLIBC≤2.28校验通过；ARM64 Debian 10 与 AMD64 Ubuntu 20.04 的 --network none / --check 均 exit0，未启动监听或业务流量。

产物身份

• GitHub 安装仓库标签：npanel-dev/Daybreak v1.0.29；安装仓库提交：
  以该 tag 的实际 Git 提交为准（安装脚本基线 a16ec84）。该提交只标识脚本/文档，不是 Rust 实现源码。
• Rust 分支：dev/simnet-session-isolation；内部版本：0.4.28。
• Rust 起点 HEAD：f4fb96812bd64f9ab5e1a860cf6eb70493e331ea；构建输入 dirty：true。
  若为 dirty，HEAD 只标识起点；完整输入由下面的快照摘要标识，不能称干净提交构建。
• 本批源码输入清单：本地 target/simnet-isolation-release-20261014/source-inputs.json（只发布二进制包，不上传源码快照）；SHA256：
  fe7c3374ace33669718b4d5e4dcc2a6517bf8d6dc4d5ceda72f45652c488d692；Cargo.lock SHA256：52492e560c95c88234dfb97d6983393f5106bd4431cf0e0d7e253d888442df1e。
• 工具链：rustc 1.94.1 (e408947bf 2026-03-25)；Node 构建时间（UTC）：x86_64
  2026-10-13T22:28:22Z，aarch64 2026-10-13T22:28:57Z。

四个 release 资产为两架构 tar.gz 及各自同名 .sha256；包内保留可执行文件、
systemd 单元、配置样例与 VERSION，GNU/glibc 静态核验上限为 2.28。

配套 SDK 0.4.28

Android：bin/android/daybreak.aar、arm64-v8a/x86_64 JNI/C 库。
macOS：bin/macos/libdbk_ffi.a 与 libdbk_ffi.dylib，arm64+x86_64 universal，
另有 bin/macos/daybreak.xcframework 仅 macOS 新切片。完整旧 bin/apple 仍为 0.4.27。
源码输入、每个新产物哈希及实际构建/验证范围记录在更新后的
bin/sdk-build-manifest.json、平台 VERSION 和校验和清单中。
SDK 交付组包时间（UTC）：2026-10-13T22:33:31.197611+00:00。manifest 和各文件的 SHA256 以本地
bin/SHA256SUMS 为准；其他保留平台继续标注其原身份，不冒充本批新构建。

v1.0.28 — 写超时只看进展、控制帧块边界插队、尾部回窗到期即发

本版发布 Node 两个 Linux GNU 架构。Node 包不包含 SDK 或 Android App。
配套 SDK 为同一提交构建的 0.4.24（见文末「配套 SDK」）。wire format、帧、TLV、认证
向量均未改，新旧 SDK / Node 任意组合互通；下面三项在节点和 SDK 里各管自己的发送方向，
两端一起升级才能两个方向都受益。

起因：2026-10-08 对 SlagClient 1.4.48 + SDK 0.4.22 的 macOS 日志与源码分析报告（F1–F7）——
一次载体写超时带走 66 条流、49 次下行读失败；七项代码断言逐条核实成立。其中 F3 / F4 / F5
在 dbk-proto-simnet / dbk-mux，节点与 SDK 同源；F1 / F2 / F6 / F7 只在客户端。

主要变化

• 载体写超时只看进展（dbk-proto-simnet）：连续 10 秒一个字节都写不出去，或一批写入
  （含 flush）超过 60 秒，才判定载体已死。此前 10 秒罩住整批 write_all + flush，一批
  （≤128 KiB 加一帧）写不完即结束整条会话——平均低于约 13–19 KiB/s 的慢但在推进的链路也被
  判死、带走会话上全部流。超时只结束会话，记住已写偏移，绝不重发同一帧。
• 控制帧在 16 KiB 块边界插队（同上）：已编码满 16 KiB 即写出，写完才取下一个事件（控制
  优先）。此前一批先全部编好再写，批写到一半到来的 WindowUpdate / Pong / Reset 要等整批写完。
• 尾部回窗到期即发（dbk-mux）：200 ms 尾部回窗改为固定到期时刻，持续的 Ping / 命令 /
  入站事件不再把它无限推后；到期时控制队列正满，则在队列腾位的当轮补发，不再多等一个 200 ms。
• 指标、配置键、日志格式均无变化。注意 mux{idle_retries} 一类兜底计数在忙碌会话上也会按
  200 ms 节拍增长，含义变为「待办悬而未决满 200 ms」。

⚠️ 升级前必查

• 本版没有新旋钮，install.sh 未改。照旧核对 report_online / enforce_device_limit
  （install.sh 会把 report_online 无条件写回本次生效值）。
• 升级后观察：客户端 session.retired.write_timeout 与 streams_cut 不应再随上传成批增长；
  节点 mux{send_blocked_millis} 分钟增量保持在 0 附近。

验证与边界

• 每项先写复现测试并先红后绿：session_io/tests/write_progress.rs（稳定慢写不判死、进展后停滞
  按最后进展计时、细流量受 60 s 总界约束）、control_overtake.rs（8 帧大批写到一半送 Pong，
  其前新开始的数据帧 ≤2）、dbk-mux tail_window_deadline.rs 与 window_update_deadline.rs
  （后者移植自一份外部安卓修复包，背压补发用例先红后绿）；另对各项做了「改回旧行为」的变异验证。
• dbk-node 全部 112 项测试、dbk-mux 全部测试、dbk-proto-simnet 库内与会话集成测试通过；
  cargo clippy -D warnings 与 cargo fmt 对改动 crate 通过；cargo xtask ci --quick 的 hard
  项中没有落在本次改动代码上的。
• 未做 真机复测与容器冒烟。macOS 内核侧的排队未处理：TCP_NOTSENT_LOWAT 在 XNU 上只控制
  可写通知、不是未发量硬上限（源码仓库 P3020 卡 §7 更正），只影响 macOS / iOS 客户端。

产物身份

两个架构均由 0f4fc58d66ed896b31c2ca6a6327bef0abb4771f 干净构建
（VERSION 内 dirty=false；启动行 dbk-node 0.4.24 commit=0f4fc58…）。

配套 SDK（0.4.24，同一提交）

除上面三项外，客户端另有：TUN 入口在隧道没送完数据、拨号失败等异常结局下让 App 收到 RST 而不是
FIN；节点拨号失败不再把用户访问的网站写进目标负缓存（0.4.22 的回归）；conn.done 诊断追加
rlong / rmax / rpend；派流在两个候选会话里选更轻的一条。
只更新 Node 不会让客户端获得这部分修复。

v1.0.27 — 窗口受限即扩窗（上传段两端不再互等回窗）

本版发布 Node 两个 Linux GNU 架构。Node 包不包含 SDK 或 Android App。
配套 SDK 为同一提交构建的 0.4.22（见文末「配套 SDK」）。wire format、帧、TLV、认证
向量均未改，新旧 SDK / Node 任意组合互通；窗口扩张是接收侧各自的决定，两端一起升级
才能两个方向都受益。

起因：v1.0.26 / 0.4.20 复测（澳洲 + 香港，客户端 1.4.43/1.4.44）——Pong 往返已从 5.7 s
降到 0.6–0.8 s，但上传段节点 mux{send_blocked_millis} 仍每分钟 +300 s，HK 出现客户端
写超时判死带走 61 条流。AU 逐 2 秒 ss -tin：载体 notsent 90–185 KB（lowat 生效）、
snd_wnd 4 MB、零重传——TCP 层是空的，堵在 mux 窗口。两端聚合接收窗口初值 1 MiB，
在 0.5–0.7 s 的回窗往返下每会话只够 1.5–2 MB/s；上传段消费被压着，增长判据永远
「速率没改善」，两端互等回窗。详见源码仓库 doc/plan/p3020-*.md §8。

主要变化

• 窗口受限即扩窗（dbk-mux）：一个周期内对端把聚合信用用尽（剩余不足一帧）且本地
  积压不到窗口的 1/4，视为「瓶颈是回窗往返」，即使消费速率没有改善也扩一次窗（单次仍最多
  一整窗、受共享预算约束）。「上层读得慢」的情况积压必然堆着，不会误触发。节点侧对应
  上传方向的信用；下载方向由配套 SDK 的同一判据负责。
• 配套 SDK 0.4.22 另把客户端聚合接收窗口初值从 1 MiB 提到 4 MiB（节点侧初值不变，
  靠上一条补）。
• 指标、配置键、日志格式均无变化。

⚠️ 升级前必查

• 本版没有新旋钮。照旧核对 report_online / enforce_device_limit（install.sh 会把
  report_online 无条件写回本次生效值）。
• 本版 install.sh 的 sysctl 片段新增 tcp_base_mss / tcp_mtu_probe_floor = 1360 与
  tcp_notsent_lowat = 131072（三台现场节点手工验证过的值）；已手工改过的节点重跑
  install.sh 会被同一文件覆盖为相同值，无需再手工维护。
• 升级后观察上传段 mux{send_blocked_millis} 分钟增量：应从几百秒回到 0 附近。

验证与边界

• dbk-mux：receive.rs 新增单测「信用见底但速率没改善也必须扩窗」，去掉该分支转红；
  actor 单测覆盖「边收边读 → 登记窗口受限」与对照「不读、积压满窗 → 不登记」。
• dbk-mux 全部测试二进制、dbk-sdk / dbk-urltest 相关测试通过；cargo clippy -D warnings
  与 cargo fmt 对改动 crate 通过；cargo xtask ci --quick 与上一批逐条比对无新增 hard 项。
• 未做 真机复测（判据：Speedtest 上传段 + TG/YouTube 同时跑，节点 send_blocked_millis
  分钟增量回到 0 附近、客户端 session.rtt_ms 0.1–0.2 s 量级、不再出现写超时判死）；
  未做容器冒烟。
• 已知待做：写超时判死改为只认「无 ACK 推进」并识别对端零窗口（B）；派流按待发深度选载体（C）。

产物身份

两个架构均由 a24423ba46bed6ddb7a19fc33dbe56acec6e782d 干净构建
（VERSION 内 dirty=false；启动行 dbk-node 0.4.22 commit=a24423b…）。

配套 SDK（0.4.22，同一提交）

客户端聚合接收窗口初值 1 → 4 MiB，加同一条「窗口受限即扩窗」判据——下载方向的 send_blocked
由这一侧消掉；url_test 不再把「TCP 根本没到节点」报成「SimNet 握手失败」（载体拨号 / TLS /
REALITY 失败各自保留自己的 layer，退避 / 关闭另起 simnet-session）。
只更新 Node 不会让客户端获得这部分修复。

v1.0.26 — 控制帧越过出站数据队列（上传满载时 Pong / WindowUpdate / Reset 不再排队）

本版发布 Node 两个 Linux GNU 架构。Node 包不包含 SDK 或 Android App。
配套 SDK 为同一提交构建的 0.4.20（见文末「配套 SDK」）。wire format、帧、TLV、认证
向量均未改，新旧 SDK / Node 任意组合互通；两边各自独立受益，建议同批升级。

起因：v1.0.25 部署后澳洲客户 2026-10-07 复测——测速上行段（↑60 MB/5 s）期间 YouTube
零流量。节点 load 0、载体 RTT 250 ms 平稳、app_limited——节点在等客户端；病根在 mux：
「控制帧优先」只作用于入队，出站 FIFO（1024 × 16 KiB = 16 MiB/会话）被数据占满后，
Pong / WindowUpdate / StreamOpen / Reset 排在 1023 帧数据后面。四条会话分 100 Mbps、
每条 16 MiB 要排 5.4 s；客户端实测 Pong 往返 5.7 s，节点 dial{timeout} 0→49、
send_blocked_millis 两分钟累计 +500 s。详见源码仓库 doc/plan/p3020-*.md。

主要变化

• 出站拆成两条队列：StreamOpen / WindowUpdate / Ping / Pong / Reset 走控制队列，
  writer 先取控制再取数据；StreamFin / GoAway 留在数据队列保持与数据的相对顺序。
  节点侧效果：下行满载时 Pong、WindowUpdate 与 P3018 的快速 Reset 不再被压在 16 MiB
  下行数据后面（此前客户端在下载阶段测到节点 Pong 往返 2.6 s）。
• 数据队列限深：1024 帧 → 64 帧（16 MiB → 1 MiB/会话）。每会话内存少 15 MiB，
  DRR 的流间公平真正落到线上（此前新流第一帧同样要在 16 MiB 后排队）。
• 保活判死与退化判定不再撞时：探测后 15 s 与空闲判死 30 s 同一刻到期时，此前
  select! 随机选边；现在全程零入站按空闲判死计数，退化只在 deadline 之前成立。
• 指标、配置键、日志格式均无变化。

⚠️ 升级前必查

• 本版没有新旋钮。照旧核对 report_online / enforce_device_limit（install.sh 会把
  report_online 无条件写回本次生效值）。
• 升级后观察 mux{send_blocked_millis=…} 在客户端大上传期间的增量：应回到 0 附近。

验证与边界

• dbk-mux 新增 tests/control_priority.rs：生产默认配置下一条流灌满队列后，下一条出站事件
  必须是刚触发的 Pong / 本流的 Reset；变异（控制帧改回数据队列）两条均转红。
• dbk-mux 全部测试二进制、dbk-proto-simnet 全量、dbk-node --lib、dbk-sdk 相关单测通过；
  cargo clippy -D warnings 与 cargo fmt --check 对改动 crate 通过；cargo xtask ci --quick
  除既有欠账外无新增项。
• 未做 真机复测（判据：Speedtest 上传段 + YouTube 同时跑，客户端 rtt 不再抬到秒级、
  「拨号失败」不随上传段抬头；节点 send_blocked_millis 增量回到 0 附近）；未做容器冒烟。
• 已知残留：客户端 macOS 内核发送缓冲（自调 4 MiB）仍有约 1.3 s 排队，需 SDK 侧设
  TCP_NOTSENT_LOWAT，另批处理。

产物身份

两个架构均由 b20ea3b6e8332cb7fedaff89742b62e889d62054 干净构建
（VERSION 内 dirty=false；启动行 dbk-node 0.4.20 commit=b20ea3b…）。

配套 SDK（0.4.20，同一提交）

客户端是这次事故的主因所在：上传满载时 StreamOpen / WindowUpdate / Pong 从客户端出不去，
节点才会拨号超时、下行写阻塞。SDK 0.4.20 同样拆出控制队列并把数据队列限深到 1 MiB，
只更新 Node 不会让客户端获得这部分修复。

v1.0.25 — 出站/载体死活判定、异常结束带原因、UDP 流空闲回收、会话退化判定

本版发布 Node 两个 Linux GNU 架构。Node 包不包含 SDK 或 Android App。
配套 SDK 为同一提交构建的 0.4.19（见文末「配套 SDK」）。wire format、帧、TLV、认证
向量均未改，新旧 SDK / Node 双向互通；但「App 收 RST」「节点重置原因计数」两项要
Node 与 SDK 同时升级才兑现。

起因：澳洲客户 2026-10-07 复测——目标对端停止 ACK 后节点出站 socket 僵 3～4 分钟
（cwnd:1、backoff:8–9、lastack>200s），客户端那条流最后拿到的是正常 FIN；
载体 socket 进 RTO 退避，4 条载体 sendQ 合计堆到 40 MB，上传后下行爬行数分钟。

主要变化

• 出站目标与载体 socket 死活判定：两者都设 keepalive（30 s / 10 s）与
  TCP_USER_TIMEOUT 30 s——对端停止 ACK 后 30 秒内由内核报错，不再等 15 次重传。
  载体另设 TCP_NOTSENT_LOWAT 128 KiB，内核未发队列有界、背压提前到 mux 流窗口；
  载体此前连 nodelay 都没设，本版一并补上。
• relay 停滞与空闲：单次写入连续 30 秒无进展判停滞；双向空闲 300 秒收尾
  （与客户端 tun.tcp_idle_timeout_secs 对齐）。首字节只计数不关流。
• 异常结束不再发 FIN：目标拨号失败、中途中断、停滞、空闲回收一律以带错误码的
  Error 0x0B 重置流（拨号失败 ConnectError，其余 StreamClosed）。新 SDK 据此给
  App 回 RST 并按原因计数；旧 SDK 照旧当 Reset 处理，行为不劣于现状（现状是 FIN）。
• UDP 流生命周期：每流空闲 60 秒（端口 53 为 10 秒）超时回收；目标发来的零长度
  数据报只刷新活动时间——此前会把整条流拆掉。
• 会话退化判定：保活探测改为固定间隔（服务端 60 秒）、只由对应 Pong 收口；探测后
  75 秒无 Pong 主动结束会话。此前任何入站帧都算应答，「活着但爬行」的载体永远判不死。
• 指标（随 60 秒快照）：node.relay{direction,outcome} 上下行都记（此前只记下行，
  新增 stalled）、node.relay.dial{ok|failed|timeout|refused|options_failed}、
  node.relay.first_byte{ok|none}、node.udp{flow_open|dial_failed|refused|flow_idle|flow_error|flow_closed}、
  node.carrier.socket{applied|partial|failed}，以及 mux 流控读数 mux{...}
  （此前每次重建会话一份、没人读）。
• VLESS 出站同样应用目标 socket 选项。

⚠️ 升级前必查

• 两个新旋钮缺省即生效，写 0 可关：[limits] carrier_user_timeout_secs = 30、
  [limits] carrier_notsent_lowat = 131072。TCP_NOTSENT_LOWAT 是三个参考实现
  （mihomo / Xray / sing-tun）都没做的一项，建议先在一台节点灰度；弱网若出现载体
  写超时（10 秒）误杀，先把 carrier_notsent_lowat 调大或设 0，不要动写超时。
• 照旧核对 report_online / enforce_device_limit（install.sh 会把 report_online
  无条件写回本次生效值）。
• 节点日志里 node.carrier.socket{outcome=partial} 持续非零说明内核不支持某项选项
  （非 Linux 才会出现），生产 Linux 节点应恒为 applied。

验证与边界

• cargo clippy --all-targets -- -D warnings（12 crate 含测试）与 cargo fmt --check 通过。
• dbk-node 全部集成测试（新增 relay_outcome.rs 8 条：拨号失败 / 目标 RST / 正常 EOF /
  首字节 none / 空闲 / 停滞 / UDP 空闲与零长包 / 经 run_relay 透传）、settings +2 条；
  dbk-mux / dbk-proto-simnet / dbk-core / dbk-transport-tcp 全量；tests/interop
  22 个测试二进制（含 Xray 互通、node_binary_e2e、simnet_bulk）全绿。
• 变异验证：把「异常不发 FIN」改回去，target_reset_mid_stream_resets_with_aborted_and_skips_fin
  转红。
• 未做 澳洲/SG 真机复测（判据：上传流对端停止 ACK 后 ≤ 30 秒客户端该流收到异常结束；
  SG 节点载体 notsent 不超过 128 KiB + 一个批次）；未做容器冒烟。

产物身份

两个架构均由 a181e4a95addfa0165f72b5e8dea40434df5d029 干净构建
（VERSION 内 dirty=false；启动行 dbk-node 0.4.19 commit=a181e4a…）。

配套 SDK（0.4.19，同一提交）

客户端把节点的异常结束兑现成对 App 的 RST（smoltcp abort / 系统栈 SO_LINGER=0），
stats_json 新增 tun.relay_reset_*、tun.first_byte_*、udp 段、dns 段、
session.rtt_ms、session.retired.degraded；保活探测 15 秒无 Pong 主动换会话；
DNS 转发按 (name, type) 缓存、同题合并、每台隧道上游一条长期流复用。
这部分只在 SDK 里，更新 Node 不会让客户端获得这些修复。