先看防护对象，而不是产品名称：云WAF重点检查HTTP/HTTPS请求是否包含针对网站或接口的攻击，边缘防护则通常负责入口处的流量接收、连接控制和前置过滤。云上WAF与边缘防护产品的分工，核心是把应用层检查和入口层治理安排清楚；有些产品把两类能力放在同一平台，物理位置相同也不代表职责相同。
先分清两道防线各自处理什么
云WAF看请求内容与应用规则
云WAF针对Web请求中的路径、参数、请求头等信息执行规则，可拦截常见注入、跨站脚本等攻击模式，也可按业务需要设置访问规则。比如登录页面收到包含异常参数的请求，WAF可以依据规则阻断或记录。它的优势是能围绕应用行为制定策略；局限是无法替代应用自身的身份验证、代码修复和权限控制。
边缘防护看入口流量与连接行为
边缘防护通常部署在用户访问源站之前，可提供连接接入、异常流量识别、访问频率限制、来源信誉判断或机器人流量管理等能力，具体项目取决于产品范围。它适合先在入口处处理大量重复、明显异常或不应到达源站的请求，减轻后端承压。它不一定理解某个业务参数是否符合应用逻辑，因此不能默认等同于WAF。
还要注意，“边缘”描述的是靠近访问入口的位置，不是固定的一组功能。云WAF也可能运行在边缘节点；同一厂商的边缘安全套件也可能包含WAF规则。比较时应看功能清单、流量路径和日志字段，不要只按产品名称判断。云上WAF与边缘防护产品的分工，最终要落实为谁先判断、谁负责拦截、谁提供事件记录。
用真实业务流程划定边界
以一个提供登录和商品查询功能的网站为例：边缘层可以限制短时间内反复请求登录入口的行为，并在流量进入源站前过滤明显异常连接；WAF再检查请求是否命中注入等Web攻击规则；应用最终验证账号、密码、权限和请求是否合法。三层检查处理的问题不同，不能把入口限流误认为账号安全，也不能把WAF告警当作代码问题已经修复。
若入口产品与WAF都启用频率限制，应明确规则由哪一侧执行、统计范围是否一致、触发后返回什么结果。否则同一用户可能先被边缘规则限制，又被WAF规则拦截，排查时难以判断原因。云上WAF与边缘防护产品的分工还应覆盖误拦截处理：谁审核例外规则，谁能查看完整请求日志，谁负责协助恢复正常访问。
按这个顺序部署和验证
- 画出请求路径：列明用户访问入口、边缘平台、WAF、源站的先后顺序，并确认源站是否还能被绕过入口直接访问。
- 按层设置策略：边缘层先配置连接与频率类控制；WAF从观察或记录模式开始，核对规则命中的路径、参数和请求类型，再逐步启用拦截。
- 准备业务例外：对健康检查、可信自动化访问或特殊接口逐项确认需求，只为必要范围增加例外，不要用大范围放行处理单个误报。
- 验证正常与异常请求：分别测试页面浏览、登录、查询等正常流程，以及授权的安全测试请求；对照两层日志确认命中顺序、响应结果和源站负载变化。
- 保留回退方案：记录规则版本、变更人和回退方法。出现误拦截时先定位规则来源，再调整单条策略，避免未经验证地整体关闭防护。
选择时看能力，不看名称
如果主要问题是Web请求攻击，希望按URL、参数或应用规则细致控制，优先核对WAF的规则管理、日志可读性和例外配置能力。如果瓶颈在入口连接、突发访问或机器人请求，则重点看边缘层的流量识别、限速范围、源站保护方式和告警机制。预算或运维资源有限时，可先选覆盖两类能力的平台，但仍要确认各功能是否启用、日志能否区分来源，以及策略冲突由谁处理。
概括来说，入口层负责尽早筛选和管理流量，WAF负责深入检查Web请求，应用负责业务身份与权限判断。云上WAF与边缘防护产品的分工不是二选一，而是按请求路径设置互补规则，并通过日志和回退流程保持可维护。
常见问题
边缘防护已经拦截异常流量，还需要WAF吗？
通常仍需要。边缘能力不一定检查应用请求内容，WAF可补充针对Web请求和应用规则的检测。
云WAF和边缘防护能由一个产品提供吗？
可以，但应逐项核对实际包含的功能、规则执行位置和日志，不要仅凭产品名称判断。
两层规则重复会不会影响访问？
可能产生重复拦截或难以定位的问题。应区分规则职责，并通过正常业务测试和分层日志验证策略效果。
上线时应先开启哪一层？
先确认完整流量路径，再逐步启用入口控制和WAF规则；新规则可先观察记录，确认误报情况后再拦截。