我之前遇到过几乎一模一样的问题！当时折腾了好几天才找到几个关键排查方向，分享给你试试：

1. 检查Nginx对请求头的解析严格性 #

Nginx 1.18相比1.16对请求头的格式检查更严格，比如默认会拒绝带下划线的自定义请求头，或者对Host头的格式要求更严。AWS LB可能会传递一些特殊头，或者你的Ingress配置里转发的头不符合新的规范。

解决尝试：在你的Ingress资源里添加Nginx配置片段，放宽头解析限制：

annotations:
  nginx.ingress.kubernetes.io/server-snippet: |
    underscores_in_headers on;
    ignore_invalid_headers off;

添加后重新部署Ingress，再测试访问。

2. 核对AWS LB与Ingress的协议/端口匹配 #

升级后可能出现协议不兼容的问题：比如AWS LB用HTTPS监听，但Ingress后端配置成了HTTP；或者反之，导致X-Forwarded-Proto等转发头不正确，Nginx 1.18对这类不匹配的情况更敏感。

解决尝试：

• 检查Ingress的注解，确保nginx.ingress.kubernetes.io/backend-protocol设置正确（比如后端Pod用HTTP就设为HTTP，HTTPS就设为HTTPS）
• 确认nginx.ingress.kubernetes.io/ssl-redirect的配置和LB的监听协议一致
• 查看Pod内Nginx的access.log和error.log，400错误通常会在日志里给出具体原因（比如“invalid host in request header”）

3. 排查请求头/请求体大小限制 #

Nginx 1.18的默认请求头大小限制可能比1.16更小，如果AWS LB传递的请求头较多（比如多个X-Forwarded-*头），可能超过了默认阈值，触发400错误。

解决尝试：在Ingress的server snippet里增大头缓存大小：

annotations:
  nginx.ingress.kubernetes.io/server-snippet: |
    client_header_buffer_size 64k;
    large_client_header_buffers 4 64k;

同时查看Nginx的error.log，如果有“request header or cookie too large”的日志，就说明是这个问题。

4. 检查Ingress Controller版本兼容性 #

如果你的Nginx Ingress Controller版本比较老，可能和新的Nginx 1.18镜像不兼容，或者升级Ubuntu后网络层面的参数（比如TCP连接超时、keepalive设置）出现了冲突。

解决尝试：

• 升级Nginx Ingress Controller到最新的稳定版本
• 检查Ingress里是否有过时的注解，替换为当前版本支持的参数
• 查看Ingress Controller的日志，看转发请求时是否有报错信息

最后提醒：一定要优先看日志！Pod内的Nginx error.log和Ingress Controller的日志会直接告诉你400错误的根源，比盲目试配置高效太多。我当时就是在日志里发现是自定义头带了下划线，开了underscores_in_headers on就解决了问题。

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