域名已经接入CDN，服务器带宽却仍然跑满；换了一家CDN，源站还是被打。这时，先确认攻击是否绕过了CDN，直接到达服务器IP。

源站IP暴露后，网站业务可以考虑高防CDN配合源站访问限制；如果攻击已堵塞源站上游链路，或业务必须开放TCP/UDP端口，就需要同时评估上游清洗、高防IP或高防服务器。更换IP可以作为整改的一步，但要先堵住泄露路径。

先看攻击落在哪里，再决定买哪种服务

源站是实际运行网站程序、接口或游戏服务的服务器。IP被知道，不等于服务器已经被入侵；真正需要判断的是，这个地址允许哪些连接，以及攻击能消耗哪里的资源。

“黑洞”通常指服务商为保护网络而丢弃某个目标IP的流量，正常访问也可能因此中断。具体触发条件、持续时间和解除方式，应以对应服务商规则为准。

如果业务正在中断，先向现有服务商确认攻击时间、目标IP、入站流量及是否触发黑洞，再讨论迁移。仅凭CPU升高、网站超时或CDN告警，无法确定攻击发生在哪一层。

为什么源站IP暴露后，接入高防CDN仍可能被打？

网站CDN通常位于用户和源站之间：用户访问CDN节点，节点处理请求，必要时再向源站取数据，这一步叫“回源”。

问题在于，攻击者知道源站IP后，可能直接向这个IP发起连接。没有经过CDN的流量，不能默认受到该CDN网站代理服务的保护。

这里要区分两类压力：

• 应用请求压力：大量请求进入登录、搜索、查询等接口，占用程序、数据库或连接池资源。
• 网络与连接压力：大量数据包或连接消耗链路容量、网络设备或服务器资源，可能在应用收到请求之前就造成故障。

AWS在基础设施层攻击说明中指出，UDP反射、SYN洪泛等攻击可能耗尽网络容量或系统资源，缓解需要能够过滤或吸收攻击的容量。这也是为什么“网站返回403”和“源站能够承受大流量攻击”是两件事。

403只是某次HTTP请求被拒绝的结果。如果流量已经占满源站前面的线路，Nginx规则或主机防火墙再拒绝请求，也不能把已经消耗的上游容量变回来。若过滤部署在瓶颈之前，效果又不同，所以采购时要问清楚流量究竟在哪里被丢弃或清洗。

买之前，怎样确认源站还暴露着哪些入口？

盘点域名、地址和业务端口

不要只检查主域名。把自己的公网IPv4、IPv6、子域名和服务整理成一张清单，重点看：

• 旧解析、测试站、后台或备用域名是否仍指向源站。
• 主域名走了CDN，其他A记录或AAAA记录是否仍允许直连。
• 邮件服务是否与网站共用同一公网地址。
• 页面资源、接口配置或对外提供的回调地址中是否写入了源站地址。
• SSH、远程桌面、数据库和管理面板是否需要对整个公网开放。

Cloudflare在源站保护文档中建议检查未代理的DNS记录、邮件部署和历史解析，并在接入代理后考虑轮换源站IP。它说明了一个现实问题：当前解析不再显示源站，并不代表旧地址没有被记录。

如果还没有梳理过这些入口，可以结合我们关于源站IP暴露路径与隐藏思路的文章做资产核对，再逐项验证当前配置。

在安装了ss工具的Linux源站上，可以先执行只读命令：

ss -lntup

按照ss命令手册的选项定义，这条命令用于列出TCP监听端口及相关UDP套接字，以数字形式显示地址和端口，并尝试显示所属进程；部分进程信息需要相应权限。

重点看Local Address:Port：绑定0.0.0.0或[::]的服务值得核对访问范围，但不能仅凭本机监听就断定公网可达，还要看云安全组、防火墙和端口映射。反过来，只检查IPv4也可能遗漏IPv6入口。

验证直连时，要带上正确的域名

浏览器打开“https://源站IP”失败，并不能证明无法绕过CDN。服务器可能根据域名选择站点和证书，直接访问IP容易测到默认站点。

下面的命令适用于安装了curl的Linux或macOS终端。仅测试自己拥有或获准管理的源站；将示例域名和文档示例IP192.0.2.10替换为自己的实际配置，从不在允许回源名单中的外部网络发起一次请求：

curl --noproxy '*' -sS --connect-timeout 5 --max-time 10 \
  --resolve 'www.example.com:443:192.0.2.10' \
  -D - -o /dev/null \
  -w '\nstatus=%{http_code} remote=%{remote_ip}\n' \
  'https://www.example.com/'

根据curl对--resolve的说明，它可以为指定主机和端口提供目标地址。这种测试保留URL里的域名及HTTPS握手所需的服务器名称，同时把连接发向指定源站IP。--noproxy '*'用于绕过本地代理设置，两个超时参数限制等待时间。

重点看remote是否为目标源站地址，再结合响应头与源站日志判断：

如果源站使用Cloudflare Origin CA证书，Cloudflare的Origin CA文档提示，停止代理后浏览器直连可能出现证书不受信任错误。换用其他CDN时，也应单独确认其回源证书校验要求，不要默认会信任原有证书。

这类低频检测用于核对可达性，不是DDoS防护能力测试，也不能用一次成功或失败推导所有地区、所有协议的结果。

哪些情况下，优先考虑高防CDN和源站隔离？

如果业务主要是网站、HTTPS接口，原服务器运行正常，主要问题是恶意请求和入口暴露，可以先评估保留应用服务器，通过高防CDN承接网站入口，再收紧源站访问范围。

这样通常能减少应用迁移工作，但需要同时完成三个环节。

把需要防护的业务真正接进去。

除了首页，还要核对登录接口、图片域名、文件上传、下载和WebSocket等入口。某个接口是否支持、有哪些超时或大小限制，应按服务商实际配置确认。动态请求也不应为了提高缓存命中率而错误缓存用户私有数据。

限制源站接受连接的范围。

向服务商取得实际回源出口地址及更新方式，区分业务回源、健康检查和运维访问。允许CDN回源，不代表要让管理面板和数据库一起对CDN地址开放。

评估回源身份认证。

来源IP白名单能缩小范围，但共享出口IP不一定能区分不同客户的请求。可以询问是否支持适合当前业务的独立回源凭据或双向TLS认证，并确认密钥保护、轮换及失效方式。仅检查Host域名不能证明请求来自你的CDN。

部署访问限制时，应先确保正常回源、运维通道、监控及证书续期仍然可用，再逐步收紧。把一条“拒绝所有其他来源”的规则直接复制到生产环境，可能先把自己的服务切断。

CDN07的高防CDN服务将内容分发与DDoS防护结合，并提供按节点、带宽和安全策略调整方案的方向。对已有海外源站的网站，可以围绕现有架构评估这些配置；具体回源认证方式、出口地址管理及适用端口，需要在接入前逐项确认。

哪些情况下，应把预算放在源站上游或高防服务器？

攻击直接影响源站网络可用性

如果服务商确认源站IP持续承受大流量攻击，线路拥塞或黑洞已经影响回源，那么单独升级网站CDN套餐未必能解决当前故障。

此时应比较：原服务商能否增加上游防护；是否有适合业务的高防IP接入方式；更换地址能否配合完整隔离；迁移到具备相应防护的服务器是否更合适。

更换高防服务器不是唯一选项。原平台若能提供满足需求的上游清洗，可能减少搬迁数据库、切换存储和重配网络的工作。反之，如果原平台无法提供足够的防护或业务所需线路，再考虑迁移更有依据。

采购高防服务器时，要关注攻击流量在哪处理、受保护的IP与端口有哪些、超过约定范围如何处置。更多CPU和内存有助于应用承载，但不能代替链路防护。

CDN07也提供香港高防服务器方案。需要调整源站承载位置的业务，可以把服务器资源、网络线路与防护条件放在同一方案中评估；具体保护范围、业务带宽和超限规则，应落到报价及服务约定里。

业务包含无法由网站CDN直接承接的端口

游戏对战、语音、自定义TCP/UDP协议，不能因为使用了域名就被当作普通网站流量。要检查的是协议、端口、连接持续时间和客户端接入方式。

例如，游戏官网可以走网站CDN，但游戏连接端口可能需要另一种防护。对能够调整客户端的项目，可结合游戏SDK盾与高防IP的区别比较接入成本；如果不能修改客户端，则更应核实服务端方案与现有协议的兼容性。

高防服务器同样不能默认保护任意业务。端口、协议、连接数、清洗策略以及攻击期间的服务承诺，都需要具体确认。

换IP能解决问题吗？怎样避免新地址再次暴露？

换IP的作用是让旧地址不再承载原业务，减少已知地址继续被利用的机会。它不会自动修复域名、邮件或接口配置中的泄露路径，也不能保证新地址永远不被发现。

建议按以下顺序处理：

1. 整理依赖关系。确认哪些程序、第三方回调、数据库白名单和监控依赖旧IP，备份配置并准备回退方案。
2. 准备新地址及访问规则。在新源站正式承接业务前，配置必要的回源和管理访问，核对IPv4与IPv6。
3. 验证CDN到新源站。检查证书、回源域名、登录、上传、接口和长连接，不只看首页能否打开。
4. 分批切换并观察。对照CDN与源站日志，检查异常状态码、请求量及业务成功情况。
5. 处理旧地址和遗漏入口。确认迁移完成后再下线旧入口，避免备用域名长期保留一条绕过路径。

不要为了调试，把新源站IP临时写进公开DNS后再删除；也不要在切换失败时不加评估地把用户流量全部直指未受保护的源站。

如果有入侵迹象，例如出现未知管理员、文件被修改或凭据泄露，还应单独进行安全处置。更换IP与接入高防服务不能代替入侵排查。

询价时，怎样比较方案才不会买错？

不要只问“多少G防御、一个月多少钱”。把自己的业务入口和故障证据一起交给服务商，才能比较同一个问题的解决成本。

对于同时承受网站恶意请求和源站IP攻击的业务，高防CDN与受保护源站可以组合使用，但不必把“双层购买”作为默认答案。先找出缺失的防护环节，再决定增加哪一层。

应用侧仍要保留鉴权、合理限流和漏洞修复。我们在WAF、Bot管理与DDoS防护如何协同中讨论了不同机制的配合：选型时也应分别确认网络攻击、恶意请求和业务滥用由什么策略处理，避免把所有责任都归给一个“高防”标签。

常见问题

源站IP暴露了，接高防CDN还有用吗？

有用，经过CDN的业务仍可获得对应的加速和防护。但已知源站IP形成的直连路径需要另外处理，可能涉及访问限制、回源认证、更换地址或源站上游防护。

只允许CDN节点回源，就能防住所有DDoS吗？

不能。它主要缩小源站接受业务连接的范围。如果过滤发生在主机内部，而攻击已堵塞上游线路，正常回源仍可能失败。还要看过滤位置、上游容量和服务商清洗机制。

服务器IP不能更换，是不是只能迁移？

不一定。可以先询问原服务商是否支持现有地址的上游防护，并检查能否收紧业务和管理入口。若防护能力、协议兼容性或网络条件无法满足要求，再比较迁移成本。

换成高防服务器后，还需要高防CDN吗？

取决于网站是否仍需要内容分发、访问加速或更细的网站入口策略。高防服务器与CDN承担的工作有交集，也有区别；已经满足需求的环节不必重复采购。

源站ping不通，是不是说明已经隐藏成功？

不是。ping测试使用的ICMP与网站HTTPS连接不同。是否允许业务直连，需要按实际域名、端口和协议验证；历史IP是否已泄露，也不是ping能够判断的。

怎么验收整改是否有效？

至少分别验证：正常用户业务是否可用，CDN是否能稳定回源，未授权来源能否绕过访问控制，以及遗留域名和IPv6入口是否收紧。大流量防护能力则需要结合服务约定、清洗机制和双方授权的测试安排，不能靠几次curl请求证明。

源站IP暴露后，下一步怎样做？

• 高防CDN主要处理经过它的业务，直达源站的攻击要另行评估。
• 访问控制能减少绕过入口，但不能代替上游链路防护。
• 更换IP要与泄露排查、回源验证和旧入口下线一起完成。
• 是否迁移高防服务器，取决于网络防护、业务协议及原平台能力。

先整理业务域名、协议端口、目标用户地区、源站位置，以及服务商提供的攻击记录。涉及源站地址和日志时，通过受控的沟通渠道提供，避免公开发布敏感配置。

如果需要比较接入CDN和迁移源站两种路径，可以带着这份清单联系CDN07确认防护方案。我们建议把入口、回源和源站分别列清楚，再确定产品组合与报价，让新增预算对应实际缺失的防护能力。