流量已经经过前置防护，源站负载却仍然升高？先别急着扩大封禁范围。高流量攻击期间的源站访问控制，关键是让业务入口只接受预期来源，同时保留必要的运维与健康检查通道。以下五个误区，常会让规则看似生效，实际却挡不住绕行流量，甚至误伤正常访问。
误区一：只封攻击地址，不限制源站入口
攻击来源可能快速变化，逐个封禁 IP 往往追不上变化速度；如果源站公网地址仍可被直接访问，流量还可能绕开前置防护。应优先收紧入口，而不是把临时封禁列表当作主要方案。
- 确认哪些服务确实需要公网入站，检查安全组、防火墙及主机本地规则。
- 将业务端口的来源限制为已核实的前置服务出口网段；未使用的管理端口关闭公网访问。
- 从外部网络测试源站直连是否被拒绝，并确认正常业务入口仍可用。
白名单应以服务提供方公开的出口网段为准，记录来源和更新时间；不要凭经验填写地址，也不要把整段公网范围设为允许。
误区二：把客户端地址误当成连接来源
经过反向代理后，源站网络层看到的对端通常是代理节点，而不一定是最终访客。若按访客 IP 配置网络白名单，业务连接可能被拦；若直接信任请求头里的地址，又可能接受伪造信息。
网络层规则按实际连接来源放行。需要识别访客地址时，只在确认请求来自可信代理后读取其传递的客户端地址，并在应用层使用。两种地址用途不同，不能混为一谈。
误区三：只配置 IPv4，忘了 IPv6
若域名同时发布 IPv4 与 IPv6 地址，但只收紧 IPv4，具备 IPv6 连通性的客户端仍可能走另一条入口。排查时同时检查 DNS 记录、云端网络策略和主机规则；没有提供 IPv6 服务的环境，则确认未意外开放对应监听端口。
误区四：攻击时直接“全关”，没有保留管理通道
临时拒绝所有来源可能切断远程排障、监控探测或业务依赖。更稳妥的做法是先确认每类连接的用途，再用最小权限放行：业务入口限于可信出口，管理访问改由 VPN 或受控跳板机进入，健康检查则仅允许已核实的探测来源。
改规则前准备回退方式，并先在一台实例或一条非关键入口验证。规则下发后，分别检查业务响应、运维登录和健康检查结果；确认无误，再逐步扩大覆盖范围。
误区五：规则加上就算完成
访问控制会受地址变更、规则优先级和多层防火墙影响。只看配置页面里的“已启用”，无法证明源站实际不可绕行。把验证纳入处置流程：比对入口日志中的连接来源，检查拒绝日志和主机连接状态，并观察源站连接数、带宽与请求是否符合预期。
规则应有负责人、变更时间和复核计划。前置服务调整出口网段后，及时核对并更新白名单；攻击缓和后也不要直接恢复宽泛开放，先判断哪些临时规则可以撤销。
一份可执行的检查顺序
- 列出源站所有公网地址、监听端口及 IPv4、IPv6 入口。
- 确认每个入口的业务用途和真实连接来源，区分代理、管理、监控与健康检查。
- 先准备回退路径，再配置最小范围的允许规则；其余入站连接按策略拒绝。
- 从授权网络和非授权网络分别测试，并查看防火墙及应用日志。
- 持续观察源站资源与业务可用性，记录规则变更，定期复核出口网段。
归根结底，高流量攻击期间的源站访问控制不是“封得越多越安全”，而是明确允许谁从哪里访问、拒绝其余不必要的入口，并验证规则确实落地。
常见问题
攻击期间能否临时开放源站排障？
可以，但应限于受控运维网络或跳板机的来源，并限定必要端口；排障结束后及时撤销临时规则。
白名单应该填写访客 IP 还是代理出口网段？
源站网络入口通常按直接连接它的代理出口网段放行。访客 IP 用于应用层识别，不能直接替代网络层来源。
怎样确认源站没有被绕过？
分别从业务入口和外部直连测试，并核对源站日志中的连接对端及拒绝记录。测试应在授权范围内进行。
攻击结束后是否恢复原来的开放规则？
不要自动恢复。先复核每条规则的业务用途，只撤销不再需要的临时项，继续保留最小权限入口。
