Caddy配置怎么写？Caddy反向代理配置教程，Caddy配置文件详解

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
}

如果你需要修改请求头、负载均衡或自定义传输协议,可以展开配置：

api.example.com {
    reverse_proxy {
        to localhost:8080 localhost:8081
        header_up X-Real-IP {remote_host}
        header_down X-Server-Name caddy
        lb_policy round_robin
    }
}

关键细节：

• 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 防护。