引子

个人有几个自用的服务器，经常会碰到一些恶意请求过来攻击服务器的，原先总是觉得自己从服务器层做好安全防护就够了，如改ssh端口，密钥登陆，开防火墙禁用端口等，但是后来发现对于服务器部署的web类应用来说，这些都是不够的，还需要一层安全防护，保障不要通过web应用打穿服务器，常见的做法是使用WAF（Web应用防火墙）来做进一步的安全防护。

雷池我认为是对个人免费使用的waf来说是非常强大且功能也够用的免费waf，它有比较好的ui以及使用起来比较简单，当然如果你是企业，也可以选择付费版本来获得更好的服务。

雷池产品的公司，竟然被阿里收购了，我也是今天要写这篇文章的时候去查了一下，才发现阿里几年前就收购北京长亭未来科技有限公司。

雷池 WAF 与 Caddy 配合使用

我自己日常使用反向代理类用caddy居多，能自动解决https的问题，配置也非常简单方便，对于没有账号管控的网页也能有个简单的安全验证。

为什么需要雷池

Caddy 做反向代理很方便，自动 HTTPS、配置简单。但安全方面只能做基础加固：TLS 加密、简单的访问控制、安全响应头。

真正的 Web 攻击——SQL 注入、XSS、命令注入、路径遍历、SSRF 这些——Caddy 识别不了。也没有人机验证、防爬策略、安全审计。

雷池是专门的 WAF，核心就是干这个的。

架构怎么搭

方案一：Caddy 在前

用户 → Caddy → 雷池 → 后端

适合已经用 Caddy 很久了，只想加一层 WAF 试试水。改动小，Caddy 继续做入口。

方案二：雷池在前（推荐）

用户 → 雷池 → Caddy → 后端

雷池做边界网关，挡在公网前面。所有流量先过 WAF 检测，干净的再进内网。新环境或者认真做安全，选这个。

雷池在前时，Caddy 怎么配

雷池接管 80/443 和证书，Caddy 只在内网跑 HTTP。所以caddy侧就会涉及到代理非443端口和禁用https的问题。

改监听端口

原来是：

example.com {
    reverse_proxy 127.0.0.1:8080
}

建议内网服务绑定的ip地址尽量不要写0.0.0.0，避免无意识直接暴露端口到公网。

改成：

:8081 {
    auto_https off
    reverse_proxy 127.0.0.1:8080
}

雷池那边把后端地址设成 http://127.0.0.1:8081。

真实 IP 怎么拿

雷池转发请求时会自动带上这些头：

  • X-Forwarded-For — 客户端 IP
  • X-Forwarded-Proto — 原始协议
  • X-Real-IP — 真实 IP

Caddy v2 默认会保留这些头，应用层直接读就行。

两种情况需要手动处理：

  1. 日志里要看真实 IP：改 Caddy 日志格式，用 {http.request.header.X-Forwarded-For} 替代默认的 remote_ip

  2. 业务代码要做 IP 判断：别用 REMOTE_ADDR，那是雷池的 IP。读 X-Forwarded-For 或 X-Real-IP

端口规划建议

服务端口说明
雷池80/443公网入口
Caddy8081 或 127.0.0.1:8080内网 HTTP

雷池占 80/443，Caddy 用 8081 或其他非标准端口，最好只监听 127.0.0.1。

协议支持

WebSocket

没问题。Upgrade: websocket 会透传，雷池可以在握手阶段做限流和人机验证。注意长连接的超时配置。

不要让 Caddy 继续做 HTTPS

两种方式都不推荐：

双 TLS：雷池终止 TLS，再和 Caddy 建立 HTTPS。配置麻烦，意义不大。

TLS 透传：雷池不解密，直接转发。这样 WAF 就废了，看不出 HTTP 内容。

就按推荐方案来：雷池搞 TLS，Caddy 跑 HTTP。

总结

项目做法
入口雷池监听 80/443
证书雷池管理
Caddy内网 HTTP 端口，auto_https off
真实 IP读 X-Forwarded-For，别用 REMOTE_ADDR