云原生Nginx防CC需三层联动：Ingress层精准限流、NetworkPolicy源头隔离、运行时安全闭环响应，并与云WAF分层协同防护。
在云原生环境中，Nginx 防 CC 攻击不能只靠单点限流配置，必须与容器平台的安全能力深度协同——既要在 Ingress 层做精准流量压制，又要借力 Kubernetes 的网络策略、Pod 安全策略和运行时防护，形成“网关拦截 + 网络隔离 + 运行时收敛”的三层联动防线。
用 Ingress Controller 统一纳管限流策略，避免配置碎片化
在 Kubernetes 中，Nginx Ingress Controller 是实际承载限流逻辑的组件。直接修改每个 Pod 的 nginx.conf 不可行，应通过声明式方式统一管控：
- 在 http 块级定义全局限流区域（如
limit_req_zone $binary_remote_addr zone=cc_ip:10m rate=5r/s），确保内存共享跨 Pod 实例生效 - 通过 Ingress 注解或 VirtualServer CRD（如 NGINX App Protect）将策略绑定到具体服务，例如：
nginx.ingress.kubernetes.io/limit-rps: "5"或nginx.org/client-max-body-size: "10m" - 对高风险路径（如
/login、/api/order）单独配置更严策略，用location级注解或自定义 CRD 实现细粒度控制
联动 NetworkPolicy，阻断异常流量源头
单纯限流无法解决伪造 IP 或代理池攻击，需结合 Kubernetes 网络策略从源头收敛：
- 为 Nginx Ingress Controller 的 Deployment 设置 专用 ServiceAccount，并启用
pod-security.admission.alpha.kubernetes.io/audit: restricted等 Pod 安全标准 - 部署 NetworkPolicy 限制仅允许来自可信 CIDR（如 CDN 回源段、WAF 出口 IP 段）或特定命名空间（如
ingress）的流量进入 Ingress Pod - 配合
ip-reputation类 Operator（如 Cilium 的 L7 策略或第三方威胁情报同步器），自动将高频恶意 IP 注入 NetworkPolicy 的ipBlock列表
集成运行时安全工具，实现攻击行为闭环响应
CC 攻击常伴随异常请求头、非常规 User-Agent 或高频路径访问，可借助 eBPF 或 sidecar 工具增强识别与响应：
- 在 Ingress Pod 中注入 OpenTelemetry Collector 或 Cilium Hubble，采集
$limit_req_status、$request_uri、$http_user_agent等字段，实时上报至 SIEM 或告警系统 - 当某 IP 在 1 分钟内被限流超 100 次，触发自动化脚本调用 Kubernetes API，将其加入 ConfigMap 驱动的黑名单，再由 Nginx reload 配置或通过 ModSecurity 规则动态拦截
- 对已确认的攻击源，联动 Pod Security Admission 或 Gatekeeper，禁止其关联的 ServiceAccount 创建新 Pod，防止横向扩散
与云托管 WAF 协同，分层承担防护职责
不建议把所有压力压给 Nginx，应按流量路径分工：
- 云厂商 WAF（如阿里云 WAF 3.0、腾讯云 Web 应用防火墙）负责 首层清洗：基于 TLS SNI、HTTP/2 优先级、JS 挑战等识别真实客户端，过滤掉 70%+ 的低级 CC 流量
- Nginx Ingress Controller 负责 二层精细化控制：对已过 WAF 的流量，按业务维度（host/path/verb）执行速率、连接数、请求体大小三重限制，并返回
429 Too Many Requests或跳转验证码页面 - 后端应用 Pod 启用 资源配额（ResourceQuota）和 LimitRange，防止单个服务因突发流量耗尽节点资源，形成最后一道熔断屏障
