WAF、CDN和SSL处理不同问题：应用请求防护、内容分发与加密连接。购买其中一项，并不自动完成另外两项，也不替代程序的权限校验、更新和备份。协同部署应从实际访问链路出发。
把链路画清楚
确认访客经过哪个代理、缓存在哪里、请求怎样到达源站，以及各层怎样建立安全连接。若攻击者仍能直接访问源站，部分代理防护可能被绕过；若回源不验证证书，也不能只因浏览器显示HTTPS就认为整条路径符合预期。
不同响应采用不同缓存规则
公开且版本稳定的图片、样式和脚本通常适合缓存。登录、后台与用户有关的响应，需要按实际身份与业务设置，不能随意共享缓存。内容发布后验证失效方式，避免客户继续看到旧价格或不同用户收到别人的数据。
WAF规则如何验证
先测试网站实际使用的表单、搜索、上传和回调。过于宽泛的规则可能把正常资料或请求误判；放开规则又必须核实风险。变更有记录和回退，不为解决一项误报关闭全部防护。认证与对象权限仍由应用在服务端执行。
HTTPS与访问日志怎样核对
主站、API、代理和源站的域名与证书按实际链路验证，续期后检查线上加载状态。记录请求来源时，只信任可信代理提供的来源信息，避免任意请求头影响安全判断。各层日志以追踪标识和一致时间关联，便于分辨问题发生在哪里。
联合验收的重点
- 手机与电脑的正常页面和咨询流程可用。
- 用户数据不进入公共缓存。
- 源站绕过路径符合防护设计。
- 证书续期、缓存刷新和规则回退可验证。
- 故障与告警有明确负责人。