网站正在遭受攻击，临时接入美国高防IP前要确认哪些条件？

美国高防IP通常指部署在美国网络侧、能够先承接访问流量并进行攻击清洗，再将正常请求转发到源站的公网入口IP。它不是单纯把网站换到一个新地址，也不代表所有攻击类型都能自动解决：防护效果还取决于支持的协议和端口、清洗策略、源站是否隐藏，以及应用本身是否存在漏洞。

网站正在被攻击时可以应急接入，但不能只拿到一个IP就立即修改DNS。至少要先确认域名解析权限、保护IP已启用、业务端口和协议受支持、HTTPS证书处理方式明确、源站不会被绕过访问，并且有可执行的验证和回退方案。缺少其中任一关键条件，直接切换都可能造成网站中断，甚至让攻击继续打到原源站。

先确认是否具备应急切换的硬条件

可以先用下面的结果表做快速判断。表中的“满足”不是指已经购买或申请成功，而是指相关信息、权限和验证路径都已经明确。

如果“防护IP已开通”和“源站可转发”都没有得到确认，不建议直接把生产域名解析到该IP。应急切换的目标是缩短暴露时间，而不是用一次未经验证的DNS变更替换另一个故障点。

按顺序核对接入前环境

1. 确认攻击打到哪里，以及要保护哪些入口

先记录当前攻击对象，不要只记录“网站打不开”。至少要区分以下几类信息：

• 被攻击的是域名、源站IPv4地址，还是IPv6地址；
• 主要受影响的是80、443等网站端口，还是其他业务端口；
• 访问异常表现为带宽跑满、连接数暴增、请求量异常，还是应用报错和数据库负载升高；
• 受影响的是首页、登录、接口、文件下载，还是长连接业务；
• 网站是否同时存在多个A记录、AAAA记录、子域名或固定IP访问入口。

美国高防IP通常更适合作为公网入口，对流量型和连接型攻击进行前置承接。但如果攻击针对的是应用逻辑，例如特定接口被高频调用、登录接口被大量尝试，切换IP只能改变入口，不能代替限流、身份校验和应用层处理。如果攻击者已经掌握源站IP，单纯修改域名解析也不能阻止其继续直接访问源站。

判断方法是把监控和日志中的时间、目标IP、端口、流量峰值、连接数和HTTP状态码保存下来。若攻击目标是旧源站IP，同时源站仍然对公网开放，后续必须把“保护源站”列为切换条件，而不是把DNS修改视为全部处理。

2. 核对域名、解析记录与权限

临时接入通常需要修改域名的DNS记录。实施前应确认：

1. 域名当前由哪个DNS服务提供解析；
2. 操作人员是否拥有修改A、AAAA或CNAME记录的权限；
3. 根域名和www等实际入口是否分别配置；
4. 是否存在仍指向旧源站的AAAA记录；
5. 是否有其他子域名、API域名或静态资源域名仍暴露源站地址；
6. 当前记录的TTL、线路策略和权重设置是什么。

可以先读取现有解析，保存变更前结果：

dig +noall +answer A example.com
dig +noall +answer AAAA example.com
dig +noall +answer CNAME www.example.com

将example.com替换为实际域名。这里的命令只用于查询，不会修改解析。记录中应包含查询时间、TTL、记录值和操作人，便于切换后对比。

需要特别注意IPv6。只把A记录切到防护IP，而AAAA记录仍然指向未保护的旧源站时，支持IPv6的访问者可能继续绕过防护。相反，如果防护入口并未提供对应的IPv6接入能力，也不能在未确认的情况下保留一个失效的AAAA记录。

DNS变更也不会瞬时对所有访问者生效。TTL只是递归解析器缓存时间的参考，实际生效时间还会受到上游缓存和本地缓存影响。因此，切换前应保存旧记录；切换后不要因为某个网络仍返回旧地址，就立即重复修改记录。

3. 确认防护IP真正承接哪些协议和端口

“高防IP”并不自动等于所有端口、所有协议都能转发。应从服务开通信息或技术支持处确认：

• 网站使用的HTTP和HTTPS端口是否已配置；
• 是否支持WebSocket、长连接、分块传输或大文件上传；
• 防护入口转发到源站时使用什么端口；
• 是否要求源站监听固定端口；
• 是否会修改客户端源IP，源站应从哪个请求头或连接信息中获取真实访问来源；
• 是否存在连接超时、请求体大小或长连接时长限制。

如果页面能打开，但登录接口、上传功能或实时刷新失败，常见原因并不是DNS，而是业务所需协议没有纳入转发配置。不要只用首页返回200作为验收依据，还要测试登录、核心接口、静态资源、上传和需要持续连接的功能。

4. 明确HTTPS证书由谁处理

HTTPS切换前必须确定TLS在哪一端终止，通常有两种方式：

• 防护入口终止HTTPS，再以HTTP或HTTPS访问源站；
• 防护入口进行HTTPS透传，由源站完成证书握手。

如果由防护入口终止HTTPS，需要准备匹配域名的证书和私钥，或确认服务侧已有可用证书。如果采用透传，则源站证书、SNI和防护入口到源站的连接方式必须保持一致。不能因为“IP已经可以访问”就认为证书一定没有问题。

在修改DNS前，可以使用指定IP进行一次不改解析的HTTPS测试：

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

其中203.0.113.10只是示例保护IP，不代表实际可用地址。该方式会让请求使用指定IP，同时保留域名作为Host和TLS中的SNI，适合检查证书、状态码和跳转行为。

检查结果时重点看：

• 是否建立TLS连接；
• 证书域名是否匹配；
• 是否出现301、302跳转到旧域名或旧地址；
• 是否返回预期的状态码；
• 是否带有正确的Cookie、安全响应头和缓存策略。

如果使用--resolve后提示证书错误、连接超时或返回默认站点，分别说明证书配置、网络转发或Host/SNI路由仍未准备好。不要用忽略证书错误的方式替代正式验证，因为那会掩盖真实的HTTPS问题。

5. 确认源站不会被绕过

高防IP能否发挥作用，关键不只是流量能否进入防护入口，还要看源站是否仍然直接暴露。

在切换前记录以下信息：

• 源站公网IP和监听端口；
• 当前对源站开放的访问来源；
• 管理后台、接口白名单和第三方回调白名单；
• 是否有DNS、代码、前端脚本或邮件通知中写入源站IP；
• 防护入口访问源站时使用的固定来源范围或连接方式。

切换成功并完成业务验证后，可以根据已确认的防护来源限制源站直接访问。但这属于有影响范围的防火墙或安全组变更，应先保存原有规则，明确哪些端口会受影响，并准备恢复原规则的回退方式。不能凭猜测填写防护来源地址，也不能在没有确认防护入口能正常回源前，先把全部公网访问封死。

如果源站必须继续接受某些管理人员、监控系统或业务回调访问，应将这些例外单独列出。否则“保护源站”的操作可能把正常管理和业务依赖一并拦截。

6. 核对业务依赖和现有白名单

临时切换IP会改变网站的公网入口，以下依赖需要逐项确认：

• 第三方系统是否按域名回调，还是固定调用旧IP；
• 登录、支付、消息通知等接口是否校验来源IP；
• 数据同步或监控系统是否只允许旧源站地址；
• 应用是否把客户端IP写入安全审计、限流或风控规则；
• 后台是否设置了固定来源白名单；
• 前端代码或配置文件中是否存在旧IP。

如果防护入口会在请求头中传递真实客户端IP，应用和日志系统也要知道应该信任哪些来源。不能简单信任任意客户端自行提交的同名请求头，否则可能影响访问控制和审计判断。

用不改DNS的方式进行切换前验收

在条件允许时，先对防护IP做定向测试，比直接修改生产解析更安全。验收顺序可以按“连通性—协议—业务—源站保护”进行。

第一步：检查基础连接

从至少一个实际用户所在网络和一个独立监测网络发起测试，确认防护IP的TCP连接、TLS握手和HTTP响应。可以使用：

curl -I --resolve example.com:80:203.0.113.10 http://example.com/
curl -I --resolve example.com:443:203.0.113.10 https://example.com/

如果HTTP可以访问而HTTPS失败，优先检查证书、SNI和443端口配置。如果两者都超时，检查防护IP状态、端口策略、源站回源和网络访问控制。

第二步：检查核心业务，而不只是首页

依次验证首页、登录页、一个只读接口、一个需要认证的接口，以及实际业务中的上传或实时功能。每项测试都应记录：

• 请求时间；
• 返回状态码；
• 页面或接口响应时间；
• 是否发生异常跳转；
• 是否出现验证码、限流或误拦截；
• 应用日志中是否收到请求。

对于缓存页面，首页返回正常并不能说明动态请求正常。对于需要登录的业务，应使用测试账号，避免在应急验收中修改真实用户数据。

第三步：确认源站回源和真实IP记录

防护入口能返回页面，说明入口至少完成了部分转发，但还要检查源站日志是否收到请求，以及应用记录的客户端IP是否符合预期。若源站日志只记录防护入口地址，可能影响审计、限流和封禁策略；若应用直接信任未验证的来源头，则需要先修正信任边界。

第四步：确认旧源站是否仍可被直接访问

从外部网络访问旧源站IP时，应根据预期结果判断：

• 如果旧源站仍能正常返回完整网站，说明存在绕过风险；
• 如果旧源站只允许防护入口访问，说明源站保护方向基本正确；
• 如果旧源站完全不可达，但防护IP也无法回源，说明封禁可能过早或规则配置错误；
• 如果旧源站返回管理页面、默认站点或错误信息，仍可能泄露入口信息。

不要把“旧IP访问失败”单独当成成功标准。只有防护入口访问正常、源站能稳定回源、核心业务通过，并且旧入口不再暴露，切换才算达到预期。

切换结果怎么解释

正式修改解析前，先把判断分支写清楚，避免攻击压力下反复试错。

若攻击流量已经导致源站带宽或连接资源耗尽，定向测试可能也会失败。此时不能简单将失败归因于防护IP配置错误，应结合切换前保存的监控数据、入口侧日志和源站日志判断请求到底到达了哪一层。

正式切换时保留变更和回退边界

在修改DNS前，至少保存四类内容：

1. 原有A、AAAA、CNAME记录、TTL和线路策略；
2. 防护入口的IP、端口、回源目标和证书处理方式；
3. 变更时间、操作人、审批信息和当时的攻击指标；
4. 切换前首页、登录、核心接口和源站直连测试结果。

正式切换后，按固定顺序复核：

• 权威DNS是否已经返回新的防护IP；
• 多个外部网络是否逐步获得新记录；
• HTTPS证书和跳转是否正常；
• 首页、登录、接口和关键业务是否可用；
• 防护入口是否有正常请求和攻击拦截记录；
• 源站带宽、连接数、CPU、内存和错误率是否下降；
• 旧源站IP是否仍能绕过防护访问。

如果新入口出现大范围业务错误，应先根据错误类型判断是DNS尚未生效、回源失败、证书问题还是应用白名单问题。只有在确认问题无法在入口侧快速修复，且旧入口仍具备可用条件时，才按预先保存的记录回退。回退同样需要记录DNS缓存影响，不能期待所有访问者立即恢复到旧地址。

哪些情况不适合直接应急接入

出现以下任一情况时，更稳妥的做法是先补齐条件，而不是直接把生产域名指向新IP：

• 只拿到了一个IP，没有确认该IP是否已开通保护和回源；
• 没有DNS修改权限，或不清楚域名实际使用的解析服务；
• 未核对AAAA记录，无法排除IPv6绕过；
• 不清楚网站使用的端口、长连接或上传能力是否受支持；
• HTTPS证书和TLS终止位置没有确定；
• 源站IP已被攻击者掌握，但没有任何源站访问限制计划；
• 核心业务依赖旧IP白名单，且没有测试或修改窗口；
• 没有保存旧解析和安全规则，无法在异常时回退；
• 当前攻击明显是应用逻辑或账号层问题，却把更换IP当成唯一处理措施。

美国高防IP适合作为应急流量入口，但能否直接接入，取决于“防护入口可用、域名可控、协议匹配、HTTPS正确、源站可回源且不被绕过、核心业务可验证”这组条件是否同时成立。把这些条件逐项核对并留下切换前后的证据，才能在攻击期间做出可回退、可复核的决定，而不是仅凭一个新IP进行高风险变更。