把所有异常流量都交给 API 网关，可能会让入口资源先被耗尽；把所有请求规则都放到网络清洗服务，又容易忽略接口身份、权限和业务语义。明确API网关与网络清洗服务的职责边界，关键是根据流量所在层级和异常特征分工：清洗服务尽量在流量抵达业务网络前处理大规模、通用型攻击，网关则在应用入口管理合法请求的访问与转发。
先按流量特征分层，而不是按产品名称分工
网络清洗服务通常部署在业务入口之前，侧重识别并缓解网络层、传输层以及部分应用层攻击，例如异常连接、流量洪泛和明显的恶意请求模式。其价值在于让不需要到达源站的流量尽早被拦截或过滤。具体能力取决于服务方案、接入方式和配置，不能仅凭“清洗”名称判断覆盖范围。
API 网关位于应用请求路径上，处理更接近接口语义的工作：路由、身份校验、访问控制、API限流、请求与响应策略，以及将请求转发到后端服务。Kong Gateway 和 NGINX 都可用于构建网关层，但功能、配置方式和扩展能力各有差异，选择时应核对实际部署版本及所需插件或模块。
因此，API网关与网络清洗服务的职责边界不宜简单画成“清洗服务负责安全、网关负责业务”。两层都可能具备一定的请求过滤能力，应该明确谁负责发现、谁负责执行、谁负责告警和复盘。
常见职责与适用条件
| 处理环节 | 更适合承担的职责 | 适用判断 |
|---|---|---|
| 网络清洗服务 | 缓解入口带宽、连接或协议层面的异常流量；按约定的策略过滤明显恶意流量。 | 异常流量规模可能影响源站或上游网络，且判定条件不依赖用户身份和业务数据。 |
| API 网关 | 认证与授权、按接口或身份限流、路由、请求规范校验和访问日志记录。 | 规则需要理解具体 API、令牌、调用方或业务操作。 |
| 两层协同 | 共享事件信息和处置状态，避免一层误封后另一层继续放行或反复拦截。 | 攻击横跨多个层级，或正常峰值与异常流量难以仅靠单一特征区分。 |
例如，某个公开 API 突然收到大量连接，若源站连接资源已承压，应先检查清洗服务是否在前置路径上生效；若流量仍可到达网关，但集中访问某一接口或某类身份，则由网关按路由、凭证或调用方设置规则更合适。这里的判断是部署分析方法，不代表任何特定服务能自动识别所有攻击。
用可执行步骤划清边界
- 画出真实流量路径。从客户端开始，标出 DNS、清洗服务、负载均衡器、API 网关和后端的先后顺序，并确认回源流量是否确实经过预期节点。路径不清，后续策略就可能加在错误位置。
- 按特征归类异常。记录连接数、带宽、请求速率、目标接口、身份标识及错误码等可观测信息。无法依赖用户或接口信息判断的通用流量特征，优先交由前置防护评估；需要识别令牌、路由或调用权限的规则，放在网关侧。
- 为每条规则指定唯一责任人。写明规则目的、触发条件、执行层、例外条件和回退方式。清洗侧的阈值应结合正常业务基线、接入容量和服务能力设置，不存在适用于所有系统的固定数值；网关限流也要区分接口成本和调用方类型。
- 先观测，再逐步执行。具备条件时先以告警或记录模式观察误报，再小范围启用拦截。核对正常请求是否被误挡、策略是否在预期节点生效，并准备撤销配置的操作路径。
- 演练协同和复盘。检查清洗告警能否通知网关维护人员，确认网关日志能否关联到上游事件。结束后比较流量路径、拦截记录和业务错误，修正规则与升级流程。
减少重复规则，也保留必要的纵深防护
两层可以有部分能力重叠，但不应未经验证地复制同一阈值。例如，清洗服务可能根据来源或请求模式过滤流量，网关也可能进行 API限流；若两边阈值不一致，正常突发可能被重复限制，攻击发生时又可能因责任不明而无人调整。
更稳妥的做法是把清洗侧策略定位为入口流量保护，把网关侧策略定位为接口与调用方治理。WAF 规则若同时存在，应进一步确认它部署在清洗层、网关层还是独立设备，并记录规则优先级及日志归属。涉及反向代理、源站地址保护或回源白名单时，也要核实网络路径，避免业务流量绕过前置防护。
最终，API网关与网络清洗服务的职责边界应落实为一张流量路径图、一份规则责任表和一套联合处置流程。这样既能让大流量风险尽量止于入口，也能让需要业务上下文的判断留在网关，减少误拦与重复配置。
常见问题
网络清洗服务能取代 API 网关吗？
通常不能。清洗服务侧重入口流量防护，不能据此假设它会承担网关的身份校验、接口路由和调用权限管理。
API 网关能独立应对所有流量攻击吗？
不能一概而论。若流量在到达网关前已影响链路或入口资源，仅靠网关策略可能来不及；应结合网络路径、资源容量和防护能力评估。
两层都设置限流会不会冲突？
有可能。分别写明限流对象、触发依据和责任方，再通过正常流量观察与小范围启用验证，避免同一请求被两套不匹配的规则重复限制。
