Skip to content

Releases: phenix3443/ppanel-node

v1.1.16

Choose a tag to compare

@phenix3443 phenix3443 released this 14 Sep 04:12
005558e

修复

  • xtls/reality 退回 e1986a4d31ca,恢复接受不带 X25519MLKEM768 的 ClientHello。v1.1.15 带进的上游 8cdf7bf9c7f0 会让默认配置的 mihomo 报 REALITY authentication failed、sing-box 无法连接。17KiB 回落缓冲修复保留。

v1.1.15

Choose a tag to compare

@phenix3443 phenix3443 released this 11 Sep 10:15
f58734a

修复 v1.1.14 的自动升级链路,并加入控制台下发目标版本的能力。

为什么紧接着发

v1.1.14 里「控制台下发版本」这条链路根本不通:target_version 只加进了 JSON DTO,而节点拉配置时无条件请求 protobuf(setProtobufResponseAccept),所以它永远读不到——控制台显示已下发、库里也存了,节点却什么都不做,且没有任何日志能看出为什么。

本版包含

接受控制台下发的目标版本:proto 补 target_version = 10(与 ppanel-server 字段号一致),拉配置时读到且与当前不同就切过去。判据是「不等」不是「更新」——新版出问题要能回退,回退和升级走同一条路。

先验证再替换:下载后先跑一次 version,确认能执行且自报版本就是目标版本,通过才动现役二进制并留 .bak。回滚在这个场景不可靠——节点起不来就拉不到配置,也就再也收不到「换回去」的指令。先验证能挡住架构不匹配(armv6 拿到 v7a 包会 SIGILL)和资产损坏。

失败指数退避(1 分钟起、30 分钟封顶),而不是「只试一次」——后者会被一次网络抖动永久钉死,清空期望版本再设回同一个值也不重试。

ppanel-node upgrade 命令:--check / 指定版本 / --restart / --repo。

三个会静默出事的修复

  • ProtectSystem=strict 只放行 /var/log:自升级必然 EROFS,而且 ACME 证书目录也只读——TLS 节点会在证书到期后突然挂掉。cert.go 的证书目录还是大写 /etc/PPanel-node,一并改小写。
  • systemctl restart 重启自己会被 systemd 连同 cgroup 一起杀掉,err 恒为 signal: terminated——重启其实成功却永远报失败。改用 --no-block。
  • Replace 缺 fsync:rename 元数据原子但数据落盘不是,写完 rename 立刻掉电会在目标路径留下 0 字节文件。

install.sh

下载源改指本仓库(原来写死上游,ppnode update 只会装回缺 REALITY 修复的版本);服务名和路径统一小写,并显式清理老的大写 PPanel-node.service——否则升级后两个 unit 会抢同一批端口。

v1.1.14

Choose a tag to compare

@phenix3443 phenix3443 released this 11 Sep 09:07
1987001

我们自己的第一个构建。代码基线是上游 perfect-panel/ppanel-node v1.1.13,叠加下面三项修复。

为什么要自建

节点此前跑的是上游 v1.1.13 的发布产物(sha256 与官方资产逐字节一致)。那个版本发布于 2026-09-07,而 REALITY 的关键修复 09-08 才合进 xtls/reality——发布比修复早一天,再怎么同步上游分支都拿不到。加上 ppanel-node 不依赖官方 xray-core(go.mod 里 replace 成第三方的 wyx2685/xray-core,当前停在 08-28),修复要流下来还得多等两跳。

自建就是为了绕开这条链。

包含

1. 修好 REALITY 因目标站证书链变长而整体失效(#8)

xtls/reality 缓存目标站握手的缓冲原本写死 8192,按 TLS 记录逐条比 5 + 记录长度,一超就放弃——且不留任何日志。目标站证书链一变长,所有客户端都连不上,而服务端只报 handshake did not complete successfully,把因果指向客户端。

2026-09-11 实际踩到:www.microsoft.com 的 Certificate 记录到了 8273 字节,超线 81。上游 XTLS/REALITY#33 在 09-08 把缓冲提到 17*1024(修复 XTLS/Xray-core#6356)。本版把这个模块单独升到 5dabb073f8e8。

2. 启动期预检 dest 的握手长度(#7)

构建 REALITY 入站时先和 dest 握一次手、量服务端方向每条 TLS 记录,超预算就打一条能照着修的日志(不阻断启动)。预检独立算出的 8273 与 reality 自身 show:true 的输出完全一致。

3. 每周检查依赖是否落后上游(#9)

比对 wyx2685/xray-core 和 xtls/reality 的 pin 与上游最新提交,落后超阈值自动开 issue。这次的教训不是选哪个 core,而是落后了 13 天却没有任何东西告诉我们。

还包含(早前合入)

  • fix(vless): flow 传 none 时按空值处理(#6)

版本号

我们自己的序列,不跟随上游 tag。上游停在 v1.1.13,本版是我们在其之上的第一个构建。