启用 CDN 或反向代理后，源站仍可能因防火墙规则过宽、旧地址未撤销或应用信任伪造请求头而暴露。做好网站源站回源白名单与攻击绕过风险控制，重点不是简单添加几条 IP，而是确认“谁能连入、能访问什么、规则变化后如何验证”。以下六项可按顺序检查，适用于常见的网站代理回源场景。
一、先确认白名单对应的真实回源地址
从 CDN 或反向代理服务的官方配置资料中，核对实际使用的 IPv4、IPv6 出口网段。不要把访客 IP、办公网络 IP 或网站解析得到的代理节点地址误当成回源地址。若同时使用多个代理服务、备用线路或不同区域，逐一确认它们是否会连接源站。
Cloudflare 会公开其网络 IP 范围，AWS CloudFront 的相关地址信息可从 AWS 发布的 IP 地址范围文件中查询。具体应采用哪一组地址，取决于账户配置和回源架构；不要直接照抄旧文档中的列表。将来源、更新时间和负责人记录在规则说明中，便于后续复核。
二、检查协议、端口与目标范围
白名单不仅要限制来源，也应缩小可访问面。网站只通过 HTTPS 回源时，防火墙通常只需允许对应的 HTTPS 监听端口；若确有 HTTP 回源、健康检查或独立管理通道，应分别说明用途，不能为了省事开放所有端口。具体端口以源站服务配置为准。
能按目标 IP、端口和协议细化规则时，就不要只设置“允许代理网段访问整台主机”。管理端口、数据库端口和文件传输服务应采用独立访问策略，不应因为网站需要回源而一并暴露。这是网站源站回源白名单与攻击绕过风险控制中最容易被忽略的边界。
三、确认源站没有其他可直达入口
检查云安全组、主机防火墙、负载均衡器和容器入口，找出所有能通向应用的路径。常见疏漏包括旧公网 IP 仍保留开放规则、备用源站未同步限制，以及 IPv6 只配置了服务却漏做过滤。域名接入代理，不代表源站地址自动变得不可访问。
可在授权的维护窗口，从不属于代理出口的外部网络尝试访问源站公网地址，并查看防火墙日志；同时确认正常代理访问仍可用。不要只凭页面能否打开判断结果：源站可能返回默认站点、TLS 错误或其他响应，需结合访问日志和规则命中记录判断请求实际到达了哪里。
四、不要把客户端可伪造的请求头当作访问凭证
应用常用代理传递的客户端地址头识别访客来源，但这些头本身并不等同于身份认证。若源站允许公网直连，攻击者可能自行提交同名请求头；应用若直接信任，就可能错误记录来源、绕过基于地址的限制。应让应用只信任明确配置的代理层，并在边界处清理或重写来自外部的同名头。
还要确认源站不会因任意 Host 请求头、错误的 TLS 主机名或默认虚拟主机配置而返回敏感站点。白名单控制网络来源，主机名校验、应用鉴权和访问策略解决的是不同问题，不能相互替代。
五、把地址变更纳入维护流程
代理服务的地址范围、接入方式或自身架构可能变化，手工维护的规则容易过期。建议指定责任人和复核周期，并在新增服务、切换回源线路、启用 IPv6 或更换源站时触发检查。若通过自动化更新规则，应先校验数据来源、变更内容和规则数量，再应用到生产环境；同时保留上一版配置，便于异常时回退。
不要为避免短暂故障而长期保留“允许任意来源”的临时规则。确需排障时，记录变更时间、范围和撤销条件，完成验证后及时收紧。
六、验证规则确实生效，并持续观察日志
- 整理回源链路图，标出代理、负载均衡器、源站及所有入口。
- 分别核对代理官方地址范围、源站监听端口和防火墙规则，清理无用途的开放项。
- 从正常代理路径和非代理外部路径进行授权测试，观察访问结果与边界日志。
- 模拟规则更新或回滚，确认配置变更有记录，并验证 IPv4、IPv6 路径的结果。
- 定期检查拒绝日志和异常直连尝试；遇到误拦截时先定位具体来源与端口，不要直接扩大到全网开放。
以上步骤把网络限制、应用信任和变更管理放在一起，才能形成可持续的网站源站回源白名单与攻击绕过风险控制。白名单有效的标准不是“代理能访问”，而是预期链路可用、非预期入口受限，且每次变化都能被复核。
常见问题
只允许 CDN 地址回源，源站就一定安全吗？
不一定。还需检查其他公网入口、应用鉴权、Host 校验和代理共享地址带来的访问边界。
代理地址范围多久复核一次？
可按组织维护制度设定周期，并在服务配置或回源线路变化时立即复核；具体频率取决于服务方更新方式和变更风险。
源站日志里看到访客地址，是否说明白名单正确？
不能单凭日志判断。应同时核对网络层连接来源、代理头处理方式和防火墙命中记录。