Nginx 本身不是防火墙，但可通过集成 ngx_waf、Naxsi 或 ModSecurity 等模块实现应用层 WAF 功能；需按业务风险选型、正确配置规则路径/模式/日志，并结合业务定制限流、文件校验、IP 白名单等策略，配合定期验证与运维闭环。
Nginx 本身不是防火墙，但通过集成专用防火墙模块（如 ngx_waf、ModSecurity 或 Naxsi），可以在应用层实现精准、可编程的攻击识别与拦截，显著提升安全水位。关键在于选对模块、配好规则、接进流程，而不是简单开启就万事大吉。
选一个适合业务风险的 WAF 模块
不同模块定位不同，别为轻量服务硬上重型方案：
- ngx_waf：纯 C 编写，零依赖，性能极高，适合高并发 API 或静态资源服务；规则以文件形式组织（IP、URL、参数、UA、POST 各有独立规则集），支持动态模式（DYNAMIC）和拦截模式（STRICT）
-
Naxsi：轻量开源，基于“学习→日志→白名单”流程，适合快速上线且不想维护复杂规则的中小业务；默认只记录不拦截，需根据
naxsi_rules.log中的 rule ID（如 1001、1302）逐步放行合法流量 - ModSecurity + OWASP CRS：工业级标准，规则库成熟，覆盖 SQLi/XSS/RFI/恶意爬虫等全场景；但需额外编译 Nginx，配置较重，适合金融、政务等中高风险系统
让规则真正生效的三个配置要点
光装模块不行，以下三项漏一不可：
-
waf_rules_path 必须指向真实存在的规则目录（如
/opt/ngx_waf/assets/rules），且 Nginx 用户（通常是www-data或nginx）要有读取权限 -
waf_mode 推荐先设为
DYNAMIC（记录+拦截），观察 3–5 天日志，确认无误后再切到STRICT；避免直接上线导致业务误杀 -
waf_log 必须启用并指定路径（如
/var/log/nginx/waf.log），配合 logrotate 定期轮转；这是调规则、查攻击、做溯源的唯一依据
结合业务场景定制关键规则
通用规则只能防已知套路，业务逻辑才是攻击者突破口：
- 对登录接口
/api/login启用 IP+账号双维度限流：用ngx_waf的limit_req扩展或 Lua 脚本实现“5 分钟内同一 IP 失败超 6 次即封 15 分钟” - 上传路径
/upload强制校验Content-Type和文件后缀，拒绝application/x-php、.phtml等危险组合 - 管理后台
/admin在 WAF 层叠加 IP 白名单（waf_white_ip_path），即使 Nginx access 控制被绕过，WAF 仍会拦截 - 富文本提交场景下，对
/api/article/save放行常见 HTML 标签（<strong>、<img>），但严格禁止<script>、onerror=、javascript:等 XSS 高危载荷
必须配套的验证与运维动作
再好的 WAF，脱离闭环就形同虚设：
- 每次更新规则后，用
nginx -t检查语法，再nginx -s reload平滑生效；严禁直接改完就丢着不管 - 每周扫描
waf.log，重点关注高频触发规则的 IP 和 URL，判断是真实攻击还是业务误报 - 每季度同步一次规则库：ngx_waf 规则可手动更新 assets/rules 下文件；OWASP CRS 建议用
git pull获取最新版 - 把 WAF 日志接入 SIEM（如 ELK 或 Splunk），设置告警：单 IP 1 小时内触发 >50 条规则，自动通知值班人
