v1.1.14

我们自己的第一个构建。代码基线是上游 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，本版是我们在其之上的第一个构建。