NFrp0.6.6发布又修一堆东西
从 v0.5.4 到 v0.6.6：23 天 17 轮 137+ 项修复与真实 e2e 暴露的问题
先说结论 说实话 v0.5.4 那篇发布文里我说把安全债还完了 现在看 这句话只说对了一半
从 2026-10-04 到 2026-10-26 日历跨度 23 天 实际投入约 15 个工作日 走了 17 轮修复 版本从 v0.5.4 推到 v0.6.6 安全审计线累计 137+ 项修复 全部带回归测试 质量门从第十三轮的 766 个测试涨到现在的 887 个 0 失败 同时保持 clippy -D warnings 0 告警 fmt 干净 cargo audit 0 漏洞
但真正让我觉得这 23 天有价值的 不是这些数字 而是最后两天暴露出来的 3 个 bug 它们都有一个共同点 自测发现不了 只有真实 e2e 才会暴露
一、这 23 天不是均匀分布的
先交代节奏 23 天不是 23 个满负荷工作日 中间有间隔 也有单日一轮接一轮的高强度段
| 阶段 | 日期 | 跨度 | 强度 |
|---|---|---|---|
| 第一~三轮（v0.5.2 → v0.5.4） | 10-04 ~ 10-05 | 2 天 | 高强度连续 |
| 第四~六轮（v0.5.5 → v0.5.7） | 10-13 ~ 10-15 | 3 天 | 中间空了 8 天 |
| 第七~十轮（v0.5.8 → v0.5.10） | 10-17 ~ 10-18 | 2 天 | 单日 3 轮（七、八、九） |
| 第十一、十二轮（v0.6.0 → v0.6.1） | 10-18 ~ 10-20 | 3 天 | 中间空 2 天 |
| 第十三、十四、十五轮 | 10-20 ~ 10-24 | 5 天 | 中间空 4 天 |
| 第十六、十七轮（→ v0.6.6） | 10-25 ~ 10-26 | 2 天 | 高强度连续 |
最密集的是 10-17 单日三轮 工作量最大也最有价值的是 10-25 和 10-26 这两天 后面单独说
二、安全审计线：137+ 项 不是扫一遍就完
第一到第十二轮是安全审计线 它不是一次全仓扫描 而是反复换视角 换工具 换攻击面
| 轮次 | 版本 | 主题 | 数量 |
|---|---|---|---|
| 一~三 | v0.5.2~0.5.4 | 基础审计：认证、ACL、端口管控 | 前几轮累积 |
| 四 | v0.5.5 | 全仓审计 参考 Shannon 方法论 每个发现必须打出真实利用 | 11 项 |
| 五 | v0.5.6 | 外部审计 39 条 | 39 项（4 高 / 16 中 / 19 低） |
| 六 | v0.5.7 | 历史上从未被审计过的面 | 8 项（3 高 / 4 中 / 1 低） |
| 七 | v0.5.8 | HTTP 响应侧、VNet 转发键、空闲池、日志放大 | 13 项（2 高 / 7 中 / 4 低） |
| 八 | v0.5.8 | xtcp 牵线、面板鉴权矩阵（421 条探针）、TLS 插件 | 5 项（1 高 / 4 低） |
| 九 | v0.5.9 | ACL 覆盖面、KCP 会话表、资源耗尽、并发竞态 | 9 项 |
| 十 | v0.5.10 | 复扫 + Miri / ASan / TSan 新维度 | — |
| 十一 | v0.6.0 | 跨平台测试缺陷 + 按官方 frp 重构测试结构 | 4 项（无产品缺陷） |
| 十二 | v0.6.1 | Shannon AI 渗透测试器审计 | 核对 13 条 3 条真新发现 |
累计 137+ 项安全修复 全部带回归测试 这里我特别想说一句 第四轮定下的规则帮了大忙 每个发现必须打出真实利用 打不出来就不算数 这条规则把看起来像漏洞和真的能打区分开了
三、特性对齐线：从能用走向与官方 0.71 对得上
第十三到第十七轮转向特性对齐 说白了不是补功能清单 而是把行为 配置 数据面都往官方 frp 0.71 上靠
- 第十三轮 负载均衡 / KCP / 健康检查与官方 frp 对齐
- 第十四轮 测试 flake 消除 + 渗透低危项
- 第十五轮 补齐未实现项 同时发现 OIDC ES256 的致命 bug JWS 签名该用 64 字节 raw
r‖s误用了 DER 这种 bug 不靠真实 IdP e2e 很难发现 - 第十六轮 官方 0.71 兼容收尾：NatHole / xtcp、SSH 隧道网关、HTTP 插件、pprof、Windows VirtualNet
- 第十七轮 本地复现报告驱动的 5 项 + 依赖漏洞清零
四、最后两天：3 个只有真实 e2e 才会暴露的 bug
10-25 和 10-26 这两天工作量最大 也最有价值 核心是把配置字段全部对齐官方 0.71
useEncryption/useCompression与官方 frpc 实测 8/8 互通 明文 / 仅加密 / 仅压缩 / 加密+压缩 官方与 NFRP 各 4 组proxyURL（HTTP CONNECT + SOCKS5）、dnsServer、natHoleStunServer、assetsDir、webServer.tls.*、pprofEnable
过程中修掉 3 个真实 bug 都是自测发现不了 只有真实 e2e 才暴露的
- NewProxy 漏传开关 客户端加密 服务端明文透传 配置看着对 链路行为不对
- 压缩器尾部不冲刷 结尾少一截 约 20% 失败率 不是必现 所以特别容易被本地跑一遍没问题放过
- 握手 leftover 被当明文写出 数据错乱 这是最隐蔽的一个 最后靠
local.log里的 “Exception occurred during processing of request” 才定位到
第十七轮还收了 5 项 /api/status 非法 JSON、重复 Authorization、日志注入、dot-segment 绕过 同时 cargo audit 4 条 RUSTSEC 公告清零 关键点是 russh 0.65 才把 rsa 从硬依赖改成 feature 依赖树这才干净下来
五、质量门：测试数不是 KPI 但它是底线
| 时间点 | 测试数 |
|---|---|
| 第十三轮 | 766 |
| 第十四轮 | 785 |
| 第十五轮 | 814（+3 Windows 真机） |
| 第十六轮 | 867 |
| 第十七轮（现在） | 887 0 失败 |
同时保持 clippy -D warnings 0 告警 fmt 干净 cargo audit 0 漏洞
六、需要说明的部分：做过的和没验的
做过的
- 三平台产物 + Android（aarch64 / x86_64） arm64 经 qemu 真跑校验
- 真实 e2e：官方 frpc 0.71 与 NFRP 双向互通
- 每轮都有实测复现 → 修复 → 回归测试的闭环
没做或没验的 我也列清楚
- SSH 网关 tcpmux / stcp 数据面 e2e 没跑完 只到注册 / 状态 / 清理
- Windows Wintun 真机数据面需要管理员权限 未复验
- TSan / Linux TUN Miri / 真实 IdP OIDC e2e 未跑
- NatHole 只覆盖 EasyNAT mode 0 HardNAT / 端口预测 / TTL 未实测
- CI 的 cross aarch64 镜像问题已改 但未验证是否真修好
另外这 23 天里我自己也制造了问题 D 盘堆了 61 GB 构建缓存 已清 10-26 打包 Android 时因环境变量缺失拿到了旧二进制 已发现并重新打包核对
七、总结
从 v0.5.4 到 v0.6.6 不是几次简单发版 更像一次补课 安全审计把历史欠账翻出来 官方兼容性把真实数据面拽回来 最后两天那 3 个 e2e bug 提醒我 配置对齐不等于行为对齐 单测通过不等于链路正确
这篇总结不打算把没验写成应该没问题 23 天 17 轮 137+ 项修复 887 个测试 0 失败 这些是成绩 没跑完的 e2e 没复验的真机数据面 这些是下一步 两样都写出来 才算一份诚实的复盘
评论
每日可发 3 条评论