现场是这样的。站点接入 Cloudflare 后源站 400 从每天十几条涨到六百条，UA 全是 bingbot，用户访问正常，放行 IP、临时关掉 WAF 都试过，数量没降。
中间走过弯路，把「Content-Length 与实际 body 长度不符，keepalive 复用时串了请求」当成主因，改完现象没变。
原因不止一个，得分开看。回源请求带了异常 Host 头，server_name 不匹配直接 400；请求行里带未编码的中文或空格，被判成 malformed；HTTP/2 降级到 1.1 时 header 体积超过缓冲上限。
先抽出 400 的原始请求行
awk '$9==400{print $0}' access.log | head -5然后用蜘蛛 UA 复现一次请求头
curl -sv https://www.example.com/ -H "User-Agent: Mozilla/5.0 (compatible; bingbot/2.0)" 2>&1 | Select-String "> "调大 header 缓冲并放宽请求行
large_client_header_buffers 4 32k;
client_header_buffer_size 8k;末了核对回源 Host 与 server_name 是否一致
curl -sI https://www.example.com/ -H "Host: www.example.com" | Select-Object -First 1这台环境是别人交接的，不少默认值被动过，只能一项项核。
同事提醒我看一下最近一次发布，时间点确实对得上。
恢复的判定其实很直接。400 回落到每天二十条以内，日志里不再出现 malformed request line，Bing 抓取量同步恢复。
400 是请求本身不合法而不是封禁，先看原始请求行，别急着在 WAF 里加白名单。报错文案容易误导，真正的原因往往在相邻那一层的日志里。