开源项目 zeroserve 近日发布，定位是一款零配置 HTTPS 静态/代理服务器。
它最反常的地方，是站点不用解包。整个站点、脚本和 TLS 材料被打成一个 tar 包，服务器原地索引，再按 byte-range 读取。替换 tar 包后发一个 SIGHUP，就能原子热重载站点、脚本和证书材料。
这不是“nginx 被全面替代”的故事。更准确地说，zeroserve 在试一条更窄的路：把配置文件变成每个请求都会运行的一段程序。
我更在意的是这个变化对工程师的影响。负责静态站点、边缘网关、小 API 入口的人，可以把发布单元收得更小；但负责大文件下载、视频片段、批量导出的团队，不该因为一个新项目就急着迁移。
zeroserve 做了什么：把部署单元压成一个 tar 包
zeroserve 的部署模型很直接：站点是一个 tar 包，不是一个展开后的 document root。服务器启动后建立路径到 tar 内字节范围的映射，文件仍留在 tar 包里读。
这个设计有两个好处。
一是发布更像替换一个不可变包。站点文件、脚本、证书材料在同一个包里，减少了“文件换了、配置没换”“证书路径错了”这类碎片化问题。
二是误暴露文件的风险会变小。传统目录服务里，临时文件、备份文件、隐藏文件如果放错位置，可能被一起端出去。tar 包索引模型至少把入口收窄了。
它支持 TLS 1.3、HTTP/2、ECH、基于 SNI 的证书选择，还会把 JA4 客户端指纹暴露给脚本。对边缘入口来说，这些不是装饰。它们关系到多证书站点、客户端识别和请求级策略。
但“零配置”不要理解成“零代码”。复杂行为仍然要写 eBPF C 脚本。zeroserve 省掉的是 nginx.conf 或 Caddyfile 这类配置文件，不是省掉所有工程判断。
| 问题 | nginx/Caddy 常见做法 | zeroserve 做法 | 更适合谁 |
|---|---|---|---|
| 站点发布 | 目录、配置、证书分开管理 | 单 tar 包承载站点、脚本、TLS 材料 | 文档站、小型静态站、边缘节点 |
| 路由与鉴权 | 配置指令、插件、Lua 或外部服务 | 用户态 eBPF 程序统一处理 | 想把入口逻辑收进一个包的小团队 |
| 热重载 | 重载配置，再处理资源一致性 | 替换 tar 包加 SIGHUP 原子切换 | 发布频繁但运维人手少的团队 |
| 复杂逻辑 | 依赖既有生态和模块 | 写 eBPF C 脚本 | 能接受新工具链的基础设施工程师 |
对后端和基础设施工程师来说，最实际的动作不是马上替换 nginx，而是挑一个边界清楚的入口试点：文档站、内部工具、小 JSON API 代理、登录保护、限流。别从大流量下载入口开始。
它和 nginx/Caddy 的差异：用户态 eBPF 是中间件，不是内核魔法
zeroserve 最容易被误读的点，是 eBPF。
这里的 eBPF 不进入 Linux 内核 BPF 子系统，也不需要 CAP_BPF。它运行在普通用户态进程里，由 async-ebpf/uBPF JIT 编译成本机代码。
所以它更像“用 eBPF 指令集做高性能沙箱脚本”，不是 XDP、内核观测、BPF verifier 那套语境。
安全边界也在用户态运行时里。项目使用 JIT、指针隔离、抢占计时器和内存上限来约束脚本。指针隔离限制内存访问范围，抢占计时器避免单个脚本拖死事件循环，默认每个脚本有 256KB 内存上限。
这条路线的吸引力很清楚：一个脚本可以处理路由、鉴权、限流、响应头改写和反向代理。它还能读请求头、改 URI、做 HMAC、解析 JSON、跑 token bucket，甚至用 OIDC 把静态站点挡在 Google 登录之后。
对关注 nginx/Caddy 替代方案的人，这意味着一个选择：如果你现在靠 nginx 配置、Lua、插件和外部鉴权服务拼入口逻辑，zeroserve 可能把链路收短。
对关注 eBPF 沙箱运行时的人，它的意义不在内核能力，而在用户态脚本沙箱。这个方向很有工程味，但也有现实门槛：团队要能写、审、调 eBPF C。不会写脚本的人，拿到的就不是“零配置”，而是另一套学习成本。
目前还看不清的部分，也不能装作已经解决。比如许可证、维护节奏、社区成熟度、调试体验、日志格式、崩溃恢复、多进程编排，这些都需要看项目后续材料和真实部署反馈。生产系统从来不是只跑通请求就算完。
性能要分场景看：小响应强，大响应别硬上
项目给出的基准测试有明确边界。
测试在 Ryzen 7 3700X 上进行，nginx 1.26、Caddy 2.11 和 zeroserve 都绑定单核。wrk 使用 HTTP/1.1 over TLS 长连接，自签证书，结果取三次 10 秒运行的中位数。
这是一组有参考价值的单核对比。它不能外推成“所有生产环境绝对领先”。硬件、连接模型、证书、响应大小、缓冲策略、日志开销、进程模型都会改变结果。
| 场景 | zeroserve | 对照 | 判断 |
|---|---|---|---|
| 174B 小静态文件 | 36,681 req/s | nginx 31,226；Caddy 12,830 | zeroserve 领先 |
| eBPF 动态 JSON 响应 | 46,945 req/s | nginx Lua 41,231 | 调优后领先 |
| 174B 小响应反代 | 26,486 req/s | nginx 21,761；Caddy 7,683 | 小 API 入口有优势 |
| 100KB 大响应反代 | 3,631 req/s | nginx 5,882；Caddy 4,285 | nginx 更快 |
这个表已经把边界说得很明白。
如果你的主要负载是小文件、小 JSON、小响应代理，zeroserve 值得放进试点清单。它的优势来自部署单元更整、每请求脚本更近、单核小响应路径更短。
如果你的网关主要负责搬大响应，nginx 仍是更稳的选择。100KB 大响应反代里，zeroserve 没有赢。大吞吐、缓冲、成熟运维体系，正是 nginx 这类老工具的护城河。
所以迁移动作应该很克制。
负责静态站点和边缘入口的团队，可以先做旁路验证：拿一个低风险站点，把站点 tar 包、TLS 材料和 eBPF 脚本放在一起发布，看热重载、日志、回滚和告警能不能接入现有流程。
负责核心反向代理的团队，更适合观望或只做压测。除非现有痛点正好是配置碎片、插件链路复杂、脚本中间件成本高，否则没必要为了新架构动稳定入口。
接下来最该看的不是跑分还能不能再涨，而是四件事：脚本怎么调试，故障怎么隔离，日志和指标怎么接进现有系统，多实例部署怎么管理。小而利，利在边界；边界不清，就会伤手。