error_log 是识别非法请求头最直接权威的依据，因其记录nginx协议解析阶段真实拒绝原因；它比access_log更关键，因畸形请求常在解析阶段即被拦截而不记入access_log。
Nginx 的 error_log 是识别非法请求头格式最直接、最权威的依据，它不依赖猜测或间接推断，而是记录 nginx 在协议解析阶段实际拒绝请求的真实原因。
它比 access_log 更关键——因为很多畸形请求根本不会进入 access_log（nginx 在解析阶段就拦截并返回 400，压根不记录到 access_log），只有 error_log 才会留下“为什么拦”的原始线索。
error_log 中能明确暴露非法请求头的典型提示
-
client sent too large header：请求头总长超出large_client_header_buffers限制，常见于超长 Cookie 或伪造的冗余 Header -
invalid host name或no Host header：Host 头缺失、含非法字符（如空格、下划线、控制符）或不符合 DNS 命名规范 -
client intended to send too large chunked body：分块传输中头部声明与实际不符，常被用于绕过 WAF 的畸形构造 -
request line is too large：URI 过长或含未编码空格、中文、CRLF 等 RFC 7230 明确禁止的字符 -
invalid request或client sent invalid request：泛型提示，需结合前后几行日志（如具体哪一行、哪个字段出错）交叉定位
如何让 error_log 发挥最大价值
- 日志级别设为
warn或error即可满足排查需求，debug级别会产生海量无关信息，反而掩盖重点 - 确保
error_log路径可写，且配置在http或server块中，避免被全局默认覆盖 - 配合
grep -A 2 -B 1 "400"或awk '/400|invalid|too large/ {print NR-1 ": " $0; getline; print NR ": " $0; getline; print NR+1 ": " $0}' /var/log/nginx/error.log快速提取上下文 - 对高频出现的同一类错误（如连续多个
no Host header），可反向验证客户端是否为低质量爬虫或测试工具，而非攻击行为
注意一个常见误区
看到 access_log 中有大量 400 并不等于就是攻击——真正需要警惕的是 error_log 中同一 IP 在短时间集中触发多种不同类型的解析错误（例如：先发畸形 Host，再发超长 URI，再发非法 HTTP 方法），这种组合模式基本可判定为自动化扫描或协议层探测。
不复杂但容易忽略
