行业资讯 · 发布时间：
防护服务已经接入，攻击流量却仍能直达源站，常见原因不是服务失效，而是源站还有未纳入保护的入口。准备这份攻击防护服务接入前源站暴露面自查清单时，应先把公网可达的地址、端口和管理入口列清，再决定哪些需要关闭、限制或保留。这样能减少防护绕行，也避免为未清理的暴露面额外增加带宽、规则和运维成本。
先确认有哪些入口能从公网到达
从 DNS 和云平台资源清单两边核对，不要只检查正在使用的主域名。查询 A、AAAA、CNAME 记录，逐项确认它们指向的负载均衡器、反向代理或源站；再检查云主机公网地址、弹性 IP、独立 API 域名，以及历史系统留下的测试域名。DNS 记录删除后仍可能有缓存，变更时应按域名服务商设置的 TTL 观察解析更新。
特别留意 IPv4 与 IPv6 是否配置一致：只把 IPv4 流量切到防护平台，而 IPv6 仍直连源站，就可能留下绕行通道。对每个地址标记负责人、用途、是否必须公网访问；用途不明的记录先核实依赖关系，再下线，避免误伤仍在使用的服务。
清理不该面向公网的端口与环境
收紧管理入口
检查安全组、防火墙及主机监听端口。SSH 常见端口为 22，远程桌面常见端口为 3389；数据库、缓存服务和运维面板也不应仅因“暂时方便”而对所有公网地址开放。管理需求优先通过 VPN、堡垒机或可信来源地址限制满足。确需保留的管理入口，应与面向用户的业务入口分开管理，并确认防护服务是否覆盖这些协议。
处理测试和旧版本
查找 staging、dev、preview 等测试环境，以及旧版网站、备用 API 和迁移期间保留的主机。它们常因配置较宽松、未接入防护而成为直接入口。先确认是否仍有真实调用，再关闭公网解析或限制来源；删除前保留必要配置和负责人记录。不要把“没有公开链接”当作访问控制。
验证回源路径，避免服务绕行和额外开销
反向代理类防护通常由边缘节点接收用户请求，再连接源站。若源站仍接受任意公网来源，攻击者或自动化扫描仍可能直接访问源站 IP，造成防护效果打折，并继续消耗源站带宽和计算资源。应向服务商确认其回源地址范围及变更通知方式，再通过安全组或主机防火墙设置回源白名单；不要凭经验猜测地址段，也不要误封健康检查或必要的运维来源。
网络层转发类方案与反向代理的接入路径、协议覆盖和源站配置要求可能不同，不能套用同一条白名单规则。先确认实际流量如何进入服务、哪些端口由服务承接，以及源站是否需要保留其他公网业务。随后从外部网络分别测试业务域名、源站地址和管理入口，确认用户请求经防护路径到达，直连源站则按预期被拒绝或限制。
按顺序完成自查，变更后留存证据
- 盘点：导出 DNS 记录、云公网地址、安全组规则和监听端口，标注用途与责任人。
- 分类：区分用户业务、管理入口、测试环境和未知资产；对未知项先核实，不直接删除。
- 收口：下线废弃域名与地址，限制非业务端口来源，并处理 IPv6 直连路径。
- 接入并验证：按服务商文档配置回源，再从外部测试业务访问、源站直连和健康检查。
- 复核成本：观察源站出入流量、实例负载及防护平台计量项；比较接入前后的变化，排查是否仍有旁路流量或重复转发。
留存变更时间、规则差异和测试结果，后续新增域名、主机或端口时按同一流程复查。完整的攻击防护服务接入前源站暴露面自查清单，重点不是把所有公网入口一概关闭，而是让每个入口都有明确用途、访问范围和责任人。
常见问题
接入防护后，源站公网 IP 一定要删除吗？
不一定。若业务架构仍依赖该地址，可以保留，但应限制来源并验证不能绕过防护直接提供业务访问。
只修改 DNS 是否足够？
通常不够。旧解析、其他子域名、IPv6 地址或历史公网地址仍可能暴露源站，应结合云资源和网络规则一起核查。
回源白名单会不会影响健康检查？
有可能。配置前确认健康检查的来源和端口，并在变更后检查监控状态；来源范围以服务商当前文档为准。
哪些暴露面最值得优先处理？
先处理可直连业务的源站地址、对公网开放的管理入口，以及无人维护的测试环境；它们更容易造成绕过、攻击面扩大或不必要的资源消耗。
按资产、入口和回源路径逐项核实，能让攻击防护服务接入前源站暴露面自查清单真正落到可验证的配置上，而不是停留在域名切换。
