怎么部署waf可以不和openresty端口冲突

作者
36 次阅读

本文最后更新于 2026年5月18日。

部署 WAF（Web 应用防火墙）时，如果不想与现有的 OpenResty 端口（通常是 80 或 443）发生冲突，核心逻辑只有两条路：要么让 WAF 运行在 OpenResty 内部，要么让 WAF 站在 OpenResty 的前面/后面。

以下是三种最主流的部署方案，按推荐程度排序：

1. 嵌入式部署：直接集成在 OpenResty 中（最推荐）

这是最优雅的方式。既然你已经在使用 OpenResty，其实没必要再起一个独立的中间件。你可以利用 OpenResty 的 Lua 特性，将 WAF 作为一个模块加载。

  • 原理： WAF 代码（如 UnixHot/WAF 或 ModSecurity Lua版）直接运行在 OpenResty 的 access_by_lua 阶段。

  • 优点：

    • 零端口冲突：它就是 OpenResty 的一部分，共用同样的进程和端口。

    • 高性能：不需要经过额外的网络转发。

  • 实施建议： 使用像 Janusec 或经典的 ngx_lua_waf。你只需要在 nginx.conf 的 http 或 server 块中引入 Lua 脚本即可。

2. 反向代理模式：错开端口，逻辑转发

如果你使用的是一个独立的 WAF 软件（比如长亭雷池、宝塔 WAF 等），你可以采用“接力”的方式。

  • 拓扑结构： 用户请求 -> WAF (80/443) -> OpenResty (8080/8443)

  • 操作步骤：

    1. 修改 OpenResty 端口：将 OpenResty 的 listen 端口改为非标准端口，例如 8080。

    2. 启动 WAF：让 WAF 监听 80 和 443。

    3. 配置上游：在 WAF 的后端服务器（Upstream）配置中，指向 127.0.0.1:8080。

  • 优点： 业务逻辑解耦，WAF 可以保护整个服务器。

  • 缺点： OpenResty 获取到的真实 IP 可能会变成 127.0.0.1（需要配置 X-Forwarded-For 传递真实 IP）。

3. 旁路部署 / 透明代理（适用于流量监控）

如果你只是想审计流量，而不希望 WAF 参与端口监听，可以采用旁路模式。

  • 原理： 通过流量镜像（Mirror）将数据包拷贝一份给 WAF。

  • 优点： 即使 WAF 挂了，也不会影响业务。

  • 缺点： 无法实时拦截攻击，只能事后告警。

总结建议

需求场景 推荐方案
追求高性能、最省资源 方案 1（嵌入式）：直接在 OpenResty 里装 Lua WAF。
已有独立 WAF 软件 方案 2（反向代理）：WAF 守大门（80），OpenResty 退居二线（8080）。
不想改动现有配置 方案 1：因为嵌入式部署只需要在配置文件里加几行 include。

避坑小贴士：

如果你选择方案 2，记得在 OpenResty 的配置中加上：

Nginx

set_real_ip_from  127.0.0.1;
real_ip_header    X-Forwarded-For;

这样你的 OpenResty 才能在 WAF 后面看到用户的真实 IP，而不是 WAF 的回源 IP。