接入两种防护，不等于把流量依次经过两个产品就完成了配置。网站接入WAF后与高防服务的协同配置，关键是明确谁负责识别应用层风险、谁负责承接流量冲击，并确保所有访问都经过预定入口。
先划清职责：一个看请求，一个保入口
WAF通常工作在应用层，可依据请求特征、规则和访问行为拦截常见攻击，也能限制异常请求。它更适合处理“请求到达网站后是否符合规则”这类问题，但不能替代大流量承载能力。
DDoS高防主要负责在流量到达源站前承接并过滤异常流量，重点是降低入口被流量冲击打满的风险。它并不必然理解网站的登录、查询等业务逻辑，因此不能取代WAF的应用层规则。
两者的边界会受供应商架构影响：有的高防服务可与WAF组合在同一入口，有的需要分别配置转发。不要只凭产品名称推定流量顺序，应以服务商提供的接入拓扑、支持协议和源站保护方式为准。
按流量路径配置，而不是只看产品清单
常见链路与入口选择
一种常见安排是让域名先解析到高防入口，再由高防转发至WAF，最后到源站；也可能由集成平台在同一入口完成两类处理。若使用CDN，它还可能承担静态内容分发和缓存，实际先后关系取决于产品能力及域名解析设计。
配置前画出完整链路：访客、DNS解析、CDN（如有）、高防、WAF、源站。逐段确认目标地址、端口、加密方式、客户端地址传递方式和健康检查要求。若链路中某个入口可被直接访问，攻击者可能绕过前置防护，防护效果就会打折。
新手可执行的接入步骤
- 盘点现状：记录需要保护的域名、源站地址、对外端口、证书位置及当前DNS记录。先从测试域名或低风险业务验证，不要直接改动所有生产入口。
- 确认产品链路：向服务商核对高防与WAF是否支持串接、转发方向、源站协议，以及客户端地址会通过哪种可信字段传递。若信息不明确，先不要配置依赖该信息的访问控制规则。
- 接入并验证加密：按确定的拓扑填写回源地址和端口，检查TLS证书覆盖域名且链路两端的加密设置一致。通过测试域名确认页面、登录和关键业务操作可正常完成。
- 收紧源站访问：确认防护入口稳定后，在源站防火墙或安全组中，仅允许服务商公布并确认的回源地址访问相应端口，形成回源白名单。保留必要的运维入口，并先验证白名单范围，避免误封管理访问。
- 逐步切换DNS：按计划调整解析，检查不同网络下的解析结果和页面可用性。留意旧解析缓存带来的过渡流量；若需回滚，提前记录原有记录和恢复步骤。
- 观察并调规则：查看WAF拦截日志、高防流量与源站连接情况。先使用观察或较宽松策略识别误报，再逐条收紧规则；不要为解决误拦截而长期关闭整类防护。
最容易漏掉的三处配置
- 源站仍可被直连：只改DNS不能阻止他人使用已知源站地址访问。应通过防火墙限制入口，并从授权网络验证直连是否被拒绝。
- 客户端地址判断错误：经过代理后，源站看到的连接地址可能是代理地址。只有在上游可信且配置正确时，才应读取转发的客户端地址；否则可能导致日志失真或访问规则被绕过。
- 健康检查与回源策略不一致：健康检查所用的域名、端口或路径若与实际服务不符，可能造成错误告警或流量无法转发。应依据服务商要求设置，并用真实业务页面核验。
用业务验收结果判断是否接好
验收不只看控制台显示“已启用”。至少核对：正常访问和关键操作是否成功、源站是否只接受预期回源、拦截日志是否能对应到规则、告警是否有人接收，以及异常时由谁调整策略。容量与清洗能力需结合服务方案、业务峰值和突发情况确认，不宜脱离合同和实际架构套用固定数值。
还要约定变更与回滚：记录DNS原值、入口配置和规则版本；每次调整后观察错误率、响应延迟及业务成功情况。如果高防已接入但源站负载仍异常，应分别检查回源量、WAF规则和源站资源，不要把所有故障都归因于同一层。这样的网站接入WAF后与高防服务的协同配置，才形成可验证、可维护的防护链路。
常见问题
一定要先接高防，再接WAF吗？
不一定。顺序取决于产品是否支持串接及其转发设计，按服务商确认的流量拓扑配置，并确保源站没有绕过防护的公开入口。
接入后能不能关闭源站原有防火墙？
通常不建议。源站仍应保留必要的网络访问限制和管理入口控制，并明确允许哪些回源地址访问业务端口。
WAF误拦截时该怎么处理？
先查对应日志、规则和受影响请求，再对具体规则作有限调整并复测。避免直接关闭全部规则，也要确认调整不会放开不必要的访问。
怎样确认访问确实经过防护？
结合DNS解析、服务商入口日志和源站访问记录核对路径，并从授权环境测试源站直连是否被限制。仅凭网页能打开，无法证明防护链路完整。