如何排查 NGINX 反代注入风险?

排查 NGINX 反代注入风险，我不会先往目标发送验证请求。更稳妥的起点是看配置：如果只凭“用了 HTTP/2”就判断有漏洞，容易把排查范围放得太大；真正需要留意的是代理指令是否形成了特定组合。

我会先确认实际生效的配置里，proxy_http_version 2、proxy_set_body 和指向上游的 proxy_pass 是否出现在同一条相关代理路径上。原文提到的 nginx_config_verify.sh 可以帮助筛出相似模式，但脚本命中只意味着“值得人工复核”，不等于已经证实可被利用。接下来还要核对运行版本、客户端能否到达该入口，以及请求经过哪些代理链路、最终由哪个上游处理。

如果确实需要验证行为差异，我更倾向于把配置带进隔离环境，而不是在生产服务上试探。对漏洞版本和补丁版本发送相同的代理请求，再比较上游记录的帧信息：重点看请求边界、帧字段和载荷是否出现非预期变化。这样的对比比单看客户端响应更有说服力，但实验环境中的结果，也不能直接替代对生产链路的判断。

排查记录最好把“配置匹配”“版本核对”和“隔离验证”分开写。前者提供线索，后者才是在受控条件下观察代理行为；如果某一步证据不足，就明确保留疑问。这样既不会把风险轻描淡写，也能避免把一次脚本命中写成确定的漏洞结论。