反向代理与modsecurity结合需确保请求在proxy_pass前经深度扫描，保留x-real-ip等原始头信息，location块内启用规则并适配crs，开启审计日志实现全程可追溯。
反向代理本身是流量入口，ModSecurity 是这道门上的智能安检仪。把两者结合，不是简单叠加，而是让所有经由 Nginx 转发的请求，在抵达后端应用前，先被 ModSecurity 深度“扫描”一遍——参数、头、Body、URL、方法、编码方式全在检测范围内。
反向代理配置必须保留原始客户端信息
ModSecurity 依赖真实 IP 和请求上下文做判断，如果代理层丢失了关键字段，规则就可能失效或误判。
- 务必在
location块中设置proxy_set_header X-Real-IP $remote_addr和X-Forwarded-For $proxy_add_x_forwarded_for - 若使用 HTTPS 回源，加上
X-Forwarded-Proto $scheme，避免 CRS 规则因协议识别错误而绕过检测 - 禁用
underscores_in_headers on（默认关闭），防止带下划线的自定义头被 Nginx 丢弃，影响自定义规则匹配
ModSecurity 必须在 proxy_pass 前生效
防护动作要发生在请求转发之前，否则恶意流量已直达后端，WAF 就成了“马后炮”。
- 在
location块内启用规则：添加modsecurity on;或modsecurity_rules 'SecRuleEngine On'; - 不要只在
http或server块全局开启，而不在具体location中启用，否则该路径不触发检测 - 若后端是 API 服务（如 /api/），可单独配置更严格的规则集；静态资源路径（如 /static/）可选择性关闭规则以降低开销
利用 CRS 规则精准拦截常见攻击类型
OWASP Core Rule Set（CRS）是 ModSecurity 的主力规则库，它针对反向代理场景做了大量适配，比如自动识别代理头注入、绕过跳转、伪装 User-Agent 扫描等行为。
- 启用 CRS 后，
REQUEST_URI和ARGS会被自动解析并检测 SQLi/XSS/LFI 等模式，无需手动写正则 - 对代理常用路径如
/wp-login.php、/admin.php、/phpmyadmin/，CRS v3.3+ 已内置高置信度阻断规则 - 配合
SecResponseBodyAccess On，还能对后端返回内容做响应体检测，防范数据泄露类攻击（如敏感信息明文返回）
日志与调试要落到代理链路全程
安全事件必须可追溯，尤其当请求经过多级代理或 CDN 时，日志字段要能还原真实路径和决策依据。
- 在 ModSecurity 配置中开启审计日志：
SecAuditEngine RelevantOnly+SecAuditLog /var/log/nginx/modsec_audit.log - 确保
SecAuditLogParts ABIJDEFHZ包含请求头（H）、响应头（Z）、规则匹配详情（I）等关键段 - 在 Nginx access_log 中加入
$upstream_http_x_modsec_rule_id（需后端透传）或自定义变量记录拦截状态，方便关联分析
