云端流量清洗与边缘防火墙的协同部署，重点不在于重复叠加规则，而在于明确每一层看到的流量是什么、负责拦截什么，以及流量如何抵达源站。常见链路是客户端先经过云端清洗，再到边缘防火墙，最后进入源站；如果还有负载均衡或反向代理，也必须纳入链路图。
最容易遗漏的是回源路径：主入口经过防护，不代表备用域名、管理入口或故障切换线路也经过同样的检查。上线前应逐段核对入口、规则和日志，而不是只验证首页能否打开。
先划清两层防护的职责
云端清洗通常负责在网络边缘识别并缓解大流量攻击，降低抵达业务网络的异常流量；边缘防火墙则依据地址、端口、协议或应用层规则，进一步限制进入业务边界的请求。两者的能力会因服务配置而异，不能假定某一层已替另一层完成全部检查。
部署时应形成清楚的决策顺序：清洗层先处理明显异常流量，边缘防火墙再执行业务入口规则，源站仅接受预期的上游连接。规则应有明确责任人，避免两层同时维护含义相同却参数不同的封禁策略。
重点检查三类策略冲突
来源地址识别不一致
流量经过代理或清洗节点后，边缘防火墙看到的连接来源可能是上游节点，而非最终访客。若直接用客户端地址配置边缘放行规则，可能把正常请求挡在外面。可信代理转发的客户端地址信息，应只从已确认的上游读取；不能把客户端可自行提交的请求头当作可信身份。
重复规则造成误拦截
例如，云端规则已允许某类业务请求，边缘防火墙却因更严格的路径或频率条件将其拒绝；也可能出现清洗层放行后，边缘仍按过期名单封禁。应比较规则的匹配条件、执行顺序和过期时间，并用实际请求日志确认究竟是哪一层作出决定。
协议与加密处理不匹配
如果加密连接在上游终止，再以另一段连接回源，边缘防火墙检查到的协议和证书状态可能与客户端一侧不同。需明确 TLS 在哪里终止、回源是否继续加密，以及证书校验由哪一端负责，避免规则建立在并不存在的连接特征上。
用可执行步骤补齐回源链路
画出所有入口：包括正式域名、备用域名、运维入口、负载均衡地址和灾备切换路径。逐项标明经过的清洗服务、边缘防火墙及代理。
检查源站入站策略：仅允许已确认的上游回源地址或受控网络进入业务端口；如有健康检查，单独确认它的来源、端口和探测路径。不要因排障临时开放所有来源后忘记收回。
核对旁路可能：检查源站是否存在可直接访问的公网地址、旧解析记录或未纳入防护的备用主机。对外服务应通过受控入口抵达，确有直连需求时应限制访问范围并记录用途。
分阶段验证：先用测试请求观察清洗层与边缘日志，再验证回源响应、健康检查和备用切换。记录请求时间、路径及可用的关联标识，确认放行或拒绝发生在哪一层。
变更后复查：规则调整后再次测试正常流量与预期拦截场景，并检查缓存绕过、源站白名单和故障回退条件是否仍一致。回退方案应恢复已知有效的规则，而不是关闭整层防护。
用日志和变更顺序减少故障
出现访问失败时，按流量经过顺序检查：先看清洗层是否拦截，再看边缘防火墙命中记录，最后查负载均衡与源站日志。若边缘日志没有对应请求，问题可能发生在它之前；若边缘已放行而源站无记录，则要继续检查回源地址、路由和上游健康状态。
上线规则宜先小范围验证，再逐步扩大；紧急封禁则记录匹配条件、影响范围和撤销方式。云端流量清洗与边缘防火墙的协同部署只有与完整回源检查结合，才能减少策略互相抵消和源站旁路。
常见问题
云端清洗放行后，边缘防火墙还需要过滤吗？
需要。清洗层与边缘防火墙的职责可能不同，边缘仍可按业务入口要求限制端口、路径或来源。
能否只允许清洗服务的回源地址访问源站？
若业务链路确实全部经由该服务，且地址范围、健康检查和备用路径都已核实，这通常有助于减少直连风险；仍须按服务变更及时维护规则。
规则冲突时应该先关闭哪一层？
不宜直接关闭整层。先依据日志定位拒绝点，再调整冲突条件，并通过正常请求和拦截测试验证。
怎样确认没有遗漏回源链路？
逐一核对主备入口、源站地址、健康检查和故障切换路径，并从日志确认每条路径都经过预期的防护节点。