Caddy近年来在Web服务器领域的热度持续上升，它最大的卖点是全自动的HTTPS证书申请与续期，配置文件简洁到几行就能跑起一个生产站点。但不少团队在选型时仍心存疑虑：一个用Go写的Web服务器，放在Google Cloud的虚拟机上，性能到底能不能扛住生产流量？为了回答这个问题，本文会在Google Cloud Compute Engine上实际部署Caddy，用压测数据说话，并给出针对性的优化建议。
Caddy的架构原理与性能特征
要理解Caddy的性能表现，先得明白它的底层设计。Caddy完全使用Go语言编写，运行时依赖Go的goroutine调度器而非传统的进程或线程模型。每个进来的连接由一个轻量级的goroutine处理，goroutine的初始栈只有几KB，创建和销毁的开销远低于操作系统线程。这意味着Caddy在高并发连接场景下的扩展性相当好，几万个并发连接对它来说压力不大。
在TLS处理上，Caddy有自己的看家本领。它内置的证书管理模块会自动通过ACME协议向Let's Encrypt申请证书，并在内存中维护一个证书缓存池。TLS握手过程中，Caddy支持会话票据复用和OCSP Stapling，能有效降低重复握手的CPU消耗。这一点在压测中的体现非常直接：当测试场景从纯HTTP切换到HTTPS时，Caddy的性能衰减幅度明显小于Nginx。
当然，Go运行时也带来一些代价。GC停顿虽然已经优化到亚毫秒级，但在内存分配频繁的场景下仍会占用少量CPU；Go编译的二进制体积较大，启动时的内存基线也比Nginx高。这些特征决定了Caddy并非在所有场景下都占优，下面用实际数据验证。
测试环境与压测方案
测试环境选用Google Cloud Compute Engine的e2-standard-4机型，4个vCPU、16GB内存，区域为asia-east1（台湾），操作系统为Debian 12。压测机使用同区域的e2-highcpu-8实例，两者内网互通，排除公网带宽的干扰。参与对比的版本为Caddy 2.7和Nginx 1.24，均通过官方仓库安装，保持默认编译选项。
压测工具选择wrk，测试分三个场景：一是静态文件响应，返回一个8KB的HTML片段；二是反向代理场景，后端为一个简单的Go HTTP服务，返回固定JSON；三是HTTPS场景，启用TLS 1.3并强制HTTP/2。每个场景持续压测60秒，取三次结果的平均值，同时记录CPU和内存占用。
需要说明的是，所有测试前都执行了系统层面的基础调优：文件描述符上限调到65535，TCP连接复用开启，Caddy和Nginx的工作进程数与vCPU数量对齐。这样做是为了让两者站在同一起跑线上，避免默认配置差异掩盖服务器本身的能力。
压测结果与数据分析
先看静态文件场景。Nginx凭借sendfile和精简的事件驱动模型，跑出了约每秒42000次请求的成绩，p99延迟为6.2毫秒。Caddy的吞吐约为每秒35000次，p99延迟7.8毫秒，差距在百分之十五左右。这个结果符合预期，Nginx的C语言实现在纯吞吐型场景仍有优势，但Caddy的表现也完全够用，CPU占用约为Nginx的1.1倍。
反向代理场景下差距进一步缩小。Nginx每秒约28000次请求，Caddy约26500次，两者p99延迟都在10毫秒以内。Caddy的反向代理模块基于Go标准库的HTTP Transport实现，连接池管理和健康检查开箱即用，配置一个负载均衡集群只需要几行Caddyfile代码，开发体验上比Nginx的upstream语法直观不少。
最有意思的是HTTPS场景。强制TLS 1.3加HTTP/2后，Nginx的吞吐下降到每秒21000次左右，而Caddy保持在每秒24000次，实现了反超。原因是Caddy对会话复用的处理更激进，且Go的TLS栈经过多年打磨，握手路径高度优化。如果业务流量以HTTPS为主，Caddy不仅不慢，反而是更优的选择。资源占用方面，Caddy稳态内存约90MB，Nginx约为35MB，绝对值都不算高，在16GB内存的机器上无足轻重。
Google Cloud环境下的优化建议
第一项优化是开启HTTP/3。Caddy对QUIC的支持是原生内置的，不需要额外编译，只要在Caddyfile的全局选项中启用即可：
caddy run --config Caddyfile
{
servers {
protocols h1 h2 h3
}
}
example.ipipp.com {
root * /var/www
file_server
}注意在Google Cloud的防火墙规则中放行UDP 443端口，否则QUIC握手无法建立，浏览器会静默回退到TCP。启用HTTP/3后，弱网环境下的首字节时间改善明显，尤其是移动端用户。
第二项是善用Google Cloud的负载均衡器与Caddy的组合。如果流量已经经过Cloud Load Balancing，TLS在负载均衡层就终止了，此时Caddy只需处理HTTP。这种架构下可以把Caddy的自动HTTPS关闭，改为监听内网HTTP端口，省去证书管理的CPU开销。反之，如果希望简化架构、直接让虚拟机暴露公网，Caddy的自动证书能力就能省掉大量运维工作，两者按团队实际情况取舍。
第三项是调整内核参数。Go程序默认能用满系统的文件描述符，但Linux默认的1024上限会先卡住瓶颈，务必修改/etc/security/limits.conf并设置ulimit -n 65535。另外可以开启TCP快速回收和BBR拥塞控制，在跨区域访问场景下能降低百分之十以上的延迟：
# 开启BBR拥塞控制 echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf sysctl -p
最后提一句缓存。Caddy本身的file_server不带磁盘缓存语义，静态资源建议在前端挂Cloud CDN，或者用Caddy的header指令输出合理的Cache-Control，让浏览器和中间层承担缓存职责，Caddy只专注于请求分发，这才是发挥它优势的正确姿势。
总结
综合测试数据来看，Caddy在Google Cloud上的性能表现完全达到了生产级水准。纯静态文件场景落后Nginx约百分之十五，反向代理场景基本持平，而HTTPS场景凭借优秀的TLS栈实现反超。加上零配置的证书管理、简洁的Caddyfile语法和活跃的插件生态，Caddy特别适合中小规模站点、API网关以及需要快速交付HTTPS服务的场景。如果追求极致的静态吞吐且运维团队对Nginx足够熟悉，Nginx依然是稳妥之选；但在绝大多数业务中，两者的性能差距远没有大到影响决策的程度，开发效率和运维成本反而更值得关注。
CaddyGoogle Cloud性能评测修改时间：2026-09-08 16:55:27