迁移至AWS Application Load Balancer后自定义请求头间歇性丢失致认证失败

我之前碰到过几乎一模一样的坑！从Classic Load Balancer切换到Application Load Balancer后，自定义请求头X-App-Key间歇性丢失导致认证失败，折腾了好一阵子才找到根源，给你几个实战性的排查和解决方向：

1. 先排查ALB的核心配置：允许自定义请求头的规则 #

虽然你的头是X-App-Key（用的是连字符，符合HTTP规范），但ALB默认有一些严格的请求头校验逻辑：

• 检查ALB的属性配置：在AWS控制台找到你的ALB，进入「Attributes」页面，确认「Allow underscores in headers」选项是否开启（即便你的头用的是连字符，开启这个也能避免其他潜在的头拦截问题）。
• ALB会自动丢弃不符合HTTP/1.1规范的请求头，如果客户端发送的头存在细微格式问题（比如末尾带空格、特殊字符），可能会被ALB间歇性拦截。

2. 检查目标组的转发规则 #

目标组的配置也可能导致头丢失：

• 确认目标组的「Preserve host headers」是否开启，虽然这主要影响Host头，但某些场景下会连带影响自定义头的转发逻辑。
• 查看目标组的「Header rules」，有没有误加了重写、删除X-App-Key的规则——我之前就见过同事误配置头重写，导致部分请求的头被覆盖。
• 注意目标组的类型：「IP模式」和「实例模式」的转发逻辑略有差异，可在低峰期切换测试（确保业务不受影响）。

3. 开启ALB访问日志，直接定位问题 #

这是最有效的排查手段！ALB的访问日志会完整记录每个请求的请求头、响应状态、转发目标等信息：

• 在ALB控制台的「Logs」页面，配置一个S3存储桶存放日志，等待10-15分钟让日志生成。
• 筛选出返回**401（认证失败）**的请求，查看日志中的request_headers字段：
  • 如果日志里没有X-App-Key：说明ALB根本没收到，问题出在客户端或中间网络（比如CDN、防火墙）。
  • 如果日志里有，但后端没收到：说明ALB转发到目标组时丢了头，目标组或ALB的转发配置存在问题。

4. 排查后端应用的头解析逻辑 #

有时候问题不在LB，而在后端：

• 检查你的应用框架是否会自动转换请求头的大小写，比如把X-App-Key转换成x-app-key，而你的认证逻辑只判断大写格式的头？虽然这通常是持续性问题，但如果应用有缓存或线程安全漏洞，也可能导致间歇性失败。
• 查看后端应用的日志，记录收到的请求头，对比ALB日志，确认头是否真的到达后端服务。

5. 验证测试工具的稳定性 #

你用Apache Bench测试，高并发下AB工具本身可能存在偶尔丢头的情况：

• 换用wrk或hey等更可靠的压测工具重新测试，看是否还会出现间歇性失败。
• 写个简单的shell脚本循环调用单个curl请求，看是否会偶尔出现失败，排除压测工具的问题。

内容的提问来源于stack exchange，提问作者fatlog