Caddy配置怎么写?Caddy反向代理配置教程,Caddy配置文件详解
- 虚拟主机
- 2026-08-29
- 6
Caddy 是当前 Web 服务器中配置效率与安全性的最优解
Caddy 的核心价值在于“自动 HTTPS”与“极简配置”,它无需像 Nginx 那样手动管理证书、编写复杂的 rewrite 规则,仅需几行指令即可完成反向代理、静态站点托管和负载均衡,对于中小型项目、个人站点以及追求快速上线的团队,Caddy 能显著降低运维成本,同时其默认开启的 HTTP/2、HTTP/3 和自动安全头,让站点在“零调优”情况下就能达到优秀的安全基线,如果你正在从 Nginx 或 Apache 迁移,Caddy 的配置语法学习成本极低,且生态插件丰富,完全可以作为生产环境的长期选择。
Caddy 配置基础:全局与站点块
Caddy 使用 Caddyfile 作为默认配置文件,格式清晰,无需分号和大括号嵌套(除非有多行指令),一个最小配置只需要一行:
example.com { root /var/www/html file_server }
- 全局选项(如 email、admin、servers)应放置在最顶部,作用于所有站点。
- 站点块用 域名 { ... } 定义,每个块内可包含路由、反向代理、重写等指令。
- 通配符与占位符: 表示匹配所有路径,{path}、{host} 等占位符可动态拼接后端地址。
专业建议:始终设置 email 全局选项,Caddy 会使用该邮箱自动申请和续期 Let’s Encrypt 证书,否则证书到期前会发出警告邮件。
反向代理配置:从入门到生产级
反向代理是 Caddy 最常用的功能,语法比 Nginx 简洁得多,基础形式:
api.example.com { reverse_proxy 127.0.0.1:8080 }
如果你需要修改请求头、负载均衡或自定义传输协议,可以展开配置:

关键细节:
- header_up 修改发往后端的请求头,header_down 修改返回给客户端的响应头。
- lb_policy 支持 round_robin、least_conn、ip_hash 等策略,适合多节点服务。
- 默认情况下 Caddy 会自动添加 X-Forwarded-For 和 X-Forwarded-Proto,后端框架需要信任代理才能获取真实 IP。
经验案例(西西云):我们曾为一位游戏加速器客户配置 UDP 流量转发,Caddy 原生支持 TCP/UDP 代理,但 UDP 场景下需要显式声明 transport,当时客户的客户端需要与后端保持长连接,我们利用 Caddy 的 reverse_proxy 加 transport http 的 keepalive 参数,将空闲超时调整到 75 秒,同时在后端启用 connection_pool 大小限制,避免了因连接数过多导致的端口耗尽,西西云的云服务器配合 Caddy 的按需证书功能,使得客户域名在迁移过程中零停机切换。
自动 HTTPS 与证书管理:零干预的体验
Caddy 最独特的优势是 On-Demand TLS 和 自动续期,你不需要像 Nginx 那样配置 ssl_certificate 路径,只要域名解析到服务器,Caddy 首次启动时就会自动申请证书。
- 默认行为:每个站点块配置的域名都会自动获得 HTTPS,无需额外声明。
- 内部证书:若使用 IP 或本地域名,Caddy 会生成自签名证书,方便内网测试。
- 手动证书:如果需要使用自己的证书,可以用 tls /path/cert.pem /path/key.pem

覆盖自动证书,但大多数场景不建议。
易错点:当服务器有多个域名时,需注意 email 全局选项中的邮箱要一致,否则证书管理后台很难追踪,Caddy 的 acme_ca 指令可以切换到其他 CA(如 ZeroSSL),默认使用 Let’s Encrypt,两者都免费且支持通配符。
静态站点托管与文件服务
Caddy 处理静态文件非常高效,且内置 file_server 指令,如果你要托管一个单页应用(SPA),需要处理历史路由回退:
example.com { root /srv/mysite try_files {path} /index.html file_server }
- try_files 类似于 Nginx 的 try_files 指令,但它会在匹配文件后回退到 /index.html。
- 对于有版本号的文件,可以使用 hash 指令设置强缓存,/assets/ 路径下缓存一年,而 HTML 页面不缓存:
example.com { root /srv/mysite @static path /assets/ header @static Cache-Control "public, max-age=31536000" file_server }
中间件与插件:优雅扩展功能
Caddy 的中间件设计非常清晰,通过 route、handle 和 handle_path 可以精确控制匹配顺序,常用功能包括:
- 请求日志:log { output file /var/log/caddy/access.log }
- 压缩:encode zstd gzip
- 访问控制:@blocked not remote_ip 192.168.1.0/24 配合 respond @blocked 403
- 重定向:redir /old /new 301
如果你需要限流、JWT 验证或更复杂的路由,可以使用 Caddy 官方插件站下载编译。但注意:插件需要重新编译二进制文件,切勿直接覆盖原始 Caddy 二进制
,建议使用 xcaddy 构建。
性能调优与生产环境建议
虽然 Caddy 默认性能已很好,但对高并发场景仍需优化:
- 调整全局服务器池:servers { max_header_size 16384 } 防止超大请求头。
- 启用 HTTP/3:servers { protocols h1 h2 h3 } 并确保 UDP 端口 443 开放。
- 连接超时:reverse_proxy 块中 transport http { dial_timeout 5s read_timeout 30s }。
- 日志轮转:Caddy 内置日志轮转,但建议在系统层面使用 logrotate 管理 /var/log/caddy/。
独立见解:大部分性能问题源于后端而非 Caddy,我们曾遇到一个客户在 Caddy 后面挂了 Node.js 服务,Caddy 本身处理 2 万 QPS 毫无压力,但 Node 端未开启 keep-alive 导致大量 TIME_WAIT,最终在 transport http 中设置 keepalive 15s 并增加后端实例数才彻底解决,因此调优时先监控后端,再谈 Caddy 参数。
FAQ 常见问题
问题 1:Caddy 与 Nginx 的配置难度差异有多大?
Caddy 的配置文件长度通常不到 Nginx 的 1/3,比如反向代理加 gzip 压缩,Nginx 需要 15 行以上,Caddy 只需 3 行,Caddy 还自动管理证书,省去 certbot renew 定时任务,如果是新项目,优先选择 Caddy 能明显提高开发和部署效率。
问题 2:Caddy 适合处理日均百万级 UV 的站点吗?
可以,Caddy 基于 Go 编写,其并发模型在处理大量静态文件和反向代理时表现稳定,只需按照本文的性能调优部分配置,并为后端预留足够资源,如果仍不放心,可以在 Caddy 前再加一层 CDN(如西西云 CDN),既能缓解源站压力,还能启用 WAF 防护。
