启用APISIX gateway.ingress后触发400错误的合规处理方案咨询

开发者阿泽

2026-7-18

问题描述

刚上手APISIX，默认配置运行正常，已成功配置cert-manager。但启用gateway.ingress后，出现「400 Bad Request - Request Header Or Cookie Too Large」错误。

使用的values.yaml配置如下：

gateway:
  ingress:
    enabled: true
    className: "apisix"
    annotations: {
      cert-manager.io/cluster-issuer: letsencrypt
    }
    hosts:
      - host: api.domain.ltd
        paths: [/*]
    tls:
      - secretName: api-domain-ltd-tls
        hosts:
          - api.domain.ltd

调试后发现：apisix-ingress-controller创建的/*路由对应的upstream使用了pass_host: pass，导致请求循环，经过多次重试后触发400错误。手动将pass_host改为node可解决循环问题（此时返回{"error_msg":"404 Route Not Found"}），且该现象可在APISIX Pod中复现。

补充说明：当配置特定路径（如/path）指向其他upstream时，不会出现此问题。

担心放任该问题会引发(D)DoS攻击——攻击者可利用请求循环放大流量（请求次数×重试次数），因此询问针对该场景的推荐处理方式：是更换路径、修补upstream、放任无特定路径时的400错误，还是遗漏了关键配置？

推荐解决方案

修正默认路由的pass_host配置
既然已确认问题根源是pass_host: pass导致的请求回环，最直接的解决方式是通过Ingress注解强制指定pass_host值。修改后的annotations如下：
```
annotations: {
  cert-manager.io/cluster-issuer: letsencrypt,
  k8s.apisix.apache.org/pass-host: "node"
}
```
也可以通过ApisixRoute CRD直接定义路由，明确配置pass_host: node，实现更精细的控制。
避免使用/*作为兜底路径
/*会匹配所有请求，若未关联正确的外部upstream，极易触发回环。建议仅为实际业务路径配置Ingress规则（如/api/*、/v1/*）；若需要兜底路由，可配置一个返回404的静态upstream，或用APISIX的response-rewrite插件直接返回自定义404响应，无需转发请求。
关闭不必要的重试机制
请求回环后的重试会放大流量风险，可通过Ingress注解k8s.apisix.apache.org/retry-attempts: "0"将对应路由的重试次数设为0，避免流量被恶意放大。
配置请求头大小限制
虽然400错误由回环重试触发，但也可通过调整APISIX的client_header_buffer_size和large_client_header_buffers参数，限制请求头大小，同时抵御针对请求头的攻击。

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