边缘缓存把可缓存内容放到靠近访问者的节点，能降低重复请求对服务器的压力；但缓存未命中、缓存刷新和直接访问源站，仍可能把流量送到真实服务器。理解边缘缓存与源站安全的配置关系，关键是区分“哪些请求由边缘节点处理”与“哪些入口仍能绕过边缘”。
这几类业务不能只依赖缓存
动态页面与个性化内容
登录后的账户页、购物车、订单状态等内容通常随用户身份或操作变化。若误将这类响应公开缓存，可能造成内容串用户；若不缓存，恶意或突发请求又会持续打到源站。应先按路径和响应特征划分缓存范围，对个性化页面设置绕过缓存，并在源站侧做身份校验、请求频率限制和异常日志监控。
API、登录与管理入口
API 即使经过边缘节点，仍需在源站验证令牌、权限和参数。登录接口容易遭遇密码尝试，管理后台则不应仅依靠“路径难猜”。可对登录、验证码和高成本查询设置独立限流；管理入口尽量增加 VPN、身份代理或固定办公网络限制。WAF 能过滤一部分常见攻击，但不能替代应用自身的鉴权和输入校验。
缓存命中不稳定或可被大量绕过的站点
搜索、筛选、分页等请求可能因参数组合不同而频繁未命中；用户请求冷门资源、主动刷新或内容刚更新时，也会触发回源。此时边缘缓存主要改善重复访问，不能保证源站免受请求洪峰影响。应检查访问日志中的回源比例和热点路径，再为源站配置容量保护、连接数限制和分层限流。具体阈值要依据正常流量、主机规格和业务峰值逐步确定，不宜套用固定数值。
把源站入口收紧，避免绕过边缘
常见风险是只在域名接入 CDN，却让源站 IP 仍能从公网直接访问。攻击者一旦找到该地址，就可能绕过边缘侧的缓存、WAF 或 DDoS防护。源站应只接受可信边缘节点的回源流量；采用回源白名单时，要按服务商公布的地址范围维护规则，并留意地址更新，避免误封正常回源。
如果服务支持，还可启用回源身份验证，例如由边缘节点提供客户端证书，源站校验证书后才响应。Nginx 等 Web 服务器也可以按来源地址限制访问，但规则应与主机防火墙协同配置，并保留必要的运维通道。改动前先确认健康检查、监控探测和紧急维护是否需要单独放行。
按顺序落地，避免误封或误缓存
- 列出入口。整理公开页面、API、登录后台、文件上传、健康检查等路径，标记哪些内容可公开缓存，哪些必须回源且需鉴权。
- 收紧源站网络。先在测试环境验证回源白名单或证书校验，再逐步启用；从公网测试源站直连是否被拒绝，同时确认边缘回源仍正常。
- 配置边缘规则。为静态资源、动态页面和敏感路径设不同策略。不要只按文件扩展名判断是否可缓存；还要核对响应是否包含用户专属数据。
- 补齐应用防护。在源站保留鉴权、权限检查和输入校验；对登录、搜索、上传等高风险操作设置限流，并记录拒绝原因。
- 持续检查。观察回源流量、错误率、缓存命中情况和源站 CPU、连接数。规则上线后先小范围验证，再扩大覆盖；缓存刷新后也要确认回源量没有异常上升。
常见问题
有边缘缓存，还需要源站 WAF 吗？
需要评估。边缘侧规则能拦截到达边缘的部分请求，源站侧防护则用于处理直连、配置遗漏或回源链路上的风险；两者职责不同。
把源站 IP 隐藏起来就够了吗？
不够。旧 DNS 记录、邮件服务配置或其他公开服务都可能泄露线索。应以网络访问控制为准，而不是把“没人知道地址”当作安全边界。
静态文件也要保护源站吗？
要。首次访问、缓存过期和刷新仍可能回源；同时还应限制源站直连，并确认文件发布流程不会意外开放敏感目录。
总的来说，边缘缓存与源站安全的配置关系不是二选一：缓存负责减少重复回源，源站控制负责守住真实服务入口。先划分可缓存与敏感请求，再限制回源来源并验证规则，才不至于把缓存带来的性能收益误当成完整防护。
