nginx 本身不是防火墙，但可通过系统防火墙、nginx access 模块和 waf 分层实现精准访问控制：系统防火墙守大门，nginx 做门禁登记，waf 防应用层攻击，并需验证配置、记录日志、定期更新规则。
Nginx 本身不是防火墙，但能通过多层协同实现精准、灵活的访问控制。关键不在于“开个防火墙”，而在于把系统防火墙（如 iptables/ufw）、Nginx 自身访问控制模块、以及可选的 WAF（如 ModSecurity 或 Naxsi）按业务场景分层使用——该拦在入口的别放进来，该验身份的别绕过去，该防攻击的别只靠日志。
用操作系统防火墙守好“大门”
这是第一道防线，负责粗粒度过滤，只放行必要端口和可信来源，避免无效流量触达 Nginx 进程。
- 仅开放 80 和 443 端口，其他端口默认拒绝；若管理后台需 SSH，单独放行 22 端口并限制源 IP
- 对高敏感服务（如 API 后台、运维接口），直接限定允许访问的 IP 段，例如：
sudo ufw allow from 203.0.113.0/24 to any port 80 - 禁用所有入站 ICMP（ping）响应，减少扫描暴露面；生产环境慎用
ufw default deny incoming，确保出站和已建立连接不受影响
用 Nginx 的 access 模块做“门禁登记”
当流量穿过系统防火墙后，Nginx 可基于 IP、路径、请求方法等做二次细粒度控制，适合保护后台目录、调试接口或临时限流。
- 禁止直接访问敏感路径：在 server 块中添加
location /\.git { deny all; }或location ~ ^/wp-(admin|config) { deny all; } - 白名单式后台访问：
location /dashboard { allow 203.0.113.50; allow 203.0.113.51; deny all; } - 限制非 GET/HEAD 请求的来源：配合
if ($request_method !~ ^(GET|HEAD)$) { return 405; }防止误提交或暴力探测
按业务风险加装 Web 应用层防护（WAF）
当需要识别并拦截 SQL 注入、XSS、恶意爬虫、CC 攻击等应用层威胁时，单靠 IP 控制远远不够，此时应引入规则驱动的 WAF。
- 轻量级需求可用 Naxsi：启用
naxsi_core.rules后，根据日志中触发的 rule ID（如 1001=SQL 注入、1302=XSS）动态调整白名单或自定义 deny 规则 - 中高风险业务推荐 ModSecurity + OWASP CRS：启用后默认拦截高危载荷，再通过
SecRuleRemoveById或自定义SecRule放行合法业务参数（如富文本编辑器提交的<script></script>类标签） - 用 Lua 脚本实现动态策略：例如对 /api/v1/login 接口做 5 分钟内最多 10 次失败尝试的计数限流，或根据 User-Agent 拦截已知恶意扫描器
配套必须做的三件事
再好的规则，没有验证、日志和更新机制，就等于没设。
- 每次修改防火墙或 Nginx 配置后，用
nginx -t校验语法，再systemctl reload nginx或ufw reload生效 - 开启详细访问日志 + error 日志，并集中收集（如用 Filebeat + ELK），重点关注 403、405、495、496、503 等状态码及匹配到的 WAF 规则 ID
- 定期审查规则有效性：删除长期未触发的冗余规则，合并重复 IP 段，更新被攻破特征（如新出现的漏洞利用 UA 字符串）
