为何GKE环境下向Ingress发送HTTP GET请求始终返回400错误？

• 触发400的本质是GKE Ingress底层依赖的Google Cloud L7负载均衡网关，对带请求体的GET请求做了合规拦截，流量根本没有转发到后端的Service、Pod环节，这和port-forward直连Pod时的正常表现完全自洽。
• 拦截的合规依据：HTTP官方规范明确约定GET方法的语义是仅通过URL参数传递获取资源所需的信息，不允许携带用于请求处理的非空请求体。虽然Node.js的Express框架默认不做这类校验，接收到带body的GET请求也能正常解析响应，但公网L7负载均衡为了规避不规范请求带来的安全风险，会严格执行规则：只要检测到GET请求携带非空请求体，就直接返回400 Bad Request，不会把请求转给后端服务。
• 为什么POST/PUT/DELETE请求完全正常：这几类HTTP方法按照规范本身就支持携带请求体，负载均衡不会对这类请求的body做拦截校验，流量可以正常透传到后端应用，因此不存在异常。
• 注意：GKE默认集成的Ingress实现，和社区常见的Nginx Ingress、Traefik等网关逻辑有区别，后者通常不会对GET携带请求体的行为做强制拦截，这也是你在其他K8s发行版上可能不会碰到同类问题的原因。

你可以用两个操作快速确认上述结论：

1. 修改当前触发400的curl命令，去掉--data-raw参数和对应的Content-Type请求头，重新向https://my-test-host/发不带body的GET请求，会发现请求可以正常通过Ingress到达应用，返回正常响应。
2. 查看GKE Ingress对应的后端Google Cloud Load Balancing的访问日志，可以直接定位到400响应是由负载均衡网关返回的，而非你的Express应用生成的。

• 你当前Ingress使用的extensions/v1beta1是早已废弃的API版本，后续可以替换为networking.k8s.io/v1的稳定版本，补充配置pathType字段优化路径匹配规则，但这类调整和当前的400错误没有关联，不会解决现有问题。
• 无需在Express应用层排查逻辑错误：port-forward直连Pod的场景已经完整验证了应用代码的运行逻辑没有任何问题，所有异常都发生在Ingress网关的前置校验环节。

内容的提问来源于stack exchange，提问作者Thiago G. Alves