源站IP泄露后的应急处理与修复步骤：5步止血顺序
源站IP泄露后的应急处理与修复步骤，先用第0步判定真假泄露，再按“收口→定级→换IP→固定暴露面→验证”五步止血：先确认是不是真泄露，再立即用访问控制收口（比换IP快），然后评估是否降级限流，满足判据才换IP，最后用回源鉴权固定暴露面并验证外部已无法直连。本文只讲事故中的动作顺序、生效快慢与验证信号，不盘点泄漏点——事前自查可参考站内如何防止源站真实IP暴露。2026年6月，CISA发布BOD 26-04实施指南，要求组织收敛公网暴露面并将防护与访问控制前移至网络边缘，以缩短应急处置窗口。同年8月，Google Cloud Media CDN更新源站架构指南，明确多级缓存与Origin Shield可聚合回源请求、防止惊群效应。这两份官方文档共同支撑一个原则：源站IP泄露后，边缘侧的动作永远比源站侧更快生效。第0步判定：是源站IP真泄露，还是回源配置把流量引回了源站先别急着换IP。大量“疑似泄露”其实是回源配置问题——CDN回源时把流量引回了源站，让日志里看起来像被直连。误判的代价是白白中断一次业务。用四个信号区分：源站访问日志中的客户端IP是否全部落在CDN回源IP段内？如果是，大概率是回源路径问题，不是泄露。连接是否带回源标识头（如自定义Header）？缺标识的请求才是外部直连。目标端口和Host字段是否与CDN配置一致？不一致说明有独立探测。DNS历史解析、证书透明日志里是否出现过源站地址？出现过才算证据确凿的泄露。如果四个信号都指向“没有外部IP出现”，那问题在回源配置，换个IP只会让业务白断一次。第1步收口访问控制：只放行回源IP段，比换IP先生效无论是否真泄露，第一步不是换IP，而是先在源站安全组/防火墙做白名单收口。规则类变更不需要业务重新解析，生效快、回滚也快，先锁定来源能立刻缩窄暴露面。按这个顺序收口：先限来源：只放行CDN回源IP段和运维跳板机IP。再限端口：只保留80/443等业务必需端口，其余全部关闭。最后处理其他出网服务：邮件、监控、对象存储回调等，逐一收敛。关键区别在于：在源站防火墙逐条补规则，和让边缘完成连接终止与访问判定，后者更快生效且更隐蔽。CISA在BOD 26-04中强调的“把访问控制前移到边缘”，正是为了缩短这个窗口。配合回源白名单，源站只接受边缘回源IP段的连接，其余来源在源站入口即被拒绝；把连接终止与访问判定前移到边缘后，这类请求还没到源站就已被处理。第2步定级：区分“还能扛”和“已经打满”，决定是否降级与限流收口之后，马上评估源站当前承受的压力，决定要不要主动降级。看五个观测项：观测项判断依据对应动作带宽/PPS是否接近出口上限启用边缘清洗或限流连接数/连接池占用是否耗尽限制新连接或排队CPU/后端队列是否持续高位降级非核心路径错误率/延迟分位是否明显劣化优先保障核心接口行为特征慢速攻击、低频滥用走七层行为清洗，不能只看带宽必须把四层带宽压制和七层行为清洗分开验收。慢速攻击和低频接口滥用不触发带宽阈值，却能悄悄耗尽连接池和CPU。如果只盯着带宽，可能误判为“还能扛”，实际已濒临打满。若需要明确降级与限流的动作细节，可参考 DDoS应急响应。第3步换IP：什么情况下才换、换之前必须先做完哪几件事满足以下任一判据才换IP：收口后仍被直连，说明白名单没能覆盖所有暴露路径；源站地址已出现在公开渠道（如证书透明日志、被动DNS、历史解析记录）；存在无法用白名单解决的暴露面（如第三方回调必须直接访问源站）。换IP之前，必须先做完四件事：确认新地址不在任何历史解析记录里，避免换了个“旧IP”。同步更新CDN回源配置和源站白名单，让新IP立即生效。可参考无感接入高防CDN配置流程。准备回滚方案：保留旧IP一段时间，出问题能切回。评估业务中断窗口：换IP涉及DNS解析和连接重建，有些长连接业务会中断。恢复时长取决于云厂商和业务架构，不同场景差异很大，这里不给统一承诺。但在源站IP泄露后的应急处理与修复步骤里，换IP是最后手段，不是第一动作。第4步固定暴露面：回源鉴权与分层回源怎么配合换完IP，必须把暴露面固定在边缘，否则泄露会反复发生。回源鉴权：源站对不带自定义Header或证书校验的连接直接拒绝。这样即使地址被知道，没有凭据也进不来。分层回源（Origin Shield）：在边缘汇聚区域回源请求，避免突发流量穿透源站产生惊群效应。Google Cloud Media CDN的架构指南指出，多级缓存能聚合回源流量，同时把回源来源收敛成可白名单化的固定集合。两者是互补关系：回源鉴权解决“进不来”，分层回源解决“扛得住”。只做鉴权，流量照样能穿透到源站；只做分层，地址被知道后仍可能被直连。配合使用，相当于给源站上了双保险。第5步验证泄露已切断：直连测试、日志比对与持续观测项“配置成功”不等于“外部已探测不到”，这是两个独立验收点。验证清单：绕过CDN直接请求源站地址，应被拒绝或超时。源站日志中非回源IP段的请求数应归零。带缺失鉴权头的请求应被源站拒绝。DNS历史解析、证书透明日志、被动DNS中不再出现源站地址。保留一段跨越业务高峰的观测期，持续看日志与解析记录，直到非回源IP段请求连续为零且被动DNS无新记录，而不是配置完就收工。如果第1、2项没过，说明泄露没切断；第3项没过，说明鉴权没生效；第4项没过，说明地址还在公开渠道扩散，需要扩展收敛范围。换完IP仍被直连的复盘顺序：还有哪些服务在替源站说话换完IP后仍被直连，别急着怀疑CDN配置，先按顺序排查这些“替源站说话”的出网面：邮件与告警发信：很多服务器会用源站IP直接发信，IP出现在邮件头里。独立子域与旧解析记录：历史DNS记录没清干净，或被子域泄露。回源以外的管理端口：SSH、数据库端口直接暴露在公网。对象存储与第三方回调：回调URL里可能带源站IP。监控探针与SDK出网：监控系统主动探测源站，暴露地址。镜像仓库与容器构建流量：CI/CD过程中源站IP出现在日志里。每一项都要收敛：邮件走第三方发送服务、子域与旧记录清理、管理端口走堡垒机、回调走边缘函数、探针改走代理。详细的事前排查方法可参考站内如何防止源站真实IP暴露。边缘承载与源站保护的分工：RockCloud 在这几步的落位方式在“收口访问控制”和“固定暴露面”两步，RockCloud高防CDN的落位方式很直接：回源IP段白名单：把源站安全组只放行边缘节点回源IP段，外部请求在边缘就被拦下。回源鉴权：给回源请求加自定义Header，源站只认带凭据的请求，地址泄露也进不来。源站保护：所有回源流量先经过边缘清洗，源站只对CDN可见。这样做的差别在于：源站防火墙逐条补规则，要手工维护、容易漏；边缘做连接终止和访问判定，规则统一、生效快。换IP后，边缘承载业务流量，源站保持隐蔽，这是职责的自然分工。需要评估回源收口与回源鉴权如何落到现有架构，可联系RockCloud技术支持一起过一遍配置。可打印的源站IP泄露处置清单步骤动作负责人角色生效特征验证信号回滚方式第0步判定真泄露还是回源配置问题值班运维日志与配置比对清晰外部IP未出现无第1步源站安全组白名单收口安全工程师非回源IP请求被拒日志中非回源IP归零删除白名单规则第2步定级并决定降级限流SRE连接池与CPU回落错误率下降关闭限流第3步按判据换IP并同步配置运维+安全新IP生效、DNS更新直连被拒切回旧IP第4步回源鉴权与分层回源运维缺鉴权头请求被拒鉴权日志无异常关闭鉴权第5步验证与持续观测值班+安全直连超时、日志干净被动DNS无新记录重新开放观测这份源站IP泄露后的应急处理与修复步骤清单可以直接打印，事故中照做。也建议把清单固化为值班SOP，并在下一次演练中验证一次直连拦截与日志归零。常见问题源站IP泄露了要不要先停机？大多数情况不需要先停机。先做访问控制收口，把非回源IP段全部拒绝，业务可以继续跑。只有当攻击已打满源站资源、收口无法生效，或者源站服务本身被攻破时才考虑停机。停机是最后手段，会直接造成业务中断。回源白名单配了还是被直连怎么排查？先检查安全组是否真的只放行了白名单IP，很多情况是规则没删干净。再看是不是有旁路绕过，比如其他服务（邮件、监控）直接出网暴露了源站IP。还要确认CDN回源IP段是否准确，有些厂商的IP段会变动。最后看日志，确认直连请求的来源IP和端口，判断是外部扫描还是内部服务泄露。更换源站IP的正确顺序是什么？先更新CDN回源配置，再改源站白名单，最后才切换DNS。顺序不能乱：如果先切DNS，旧IP还没被CDN接管，流量会直接打到源站。换完IP后，要等DNS缓存过期，再用直连测试和日志比对验证。整个过程要保留旧IP一段时间，作为回滚方案。只做回源鉴权不换IP够不够？不够。回源鉴权能挡住不带凭据的直连，但攻击者如果拿到鉴权头（比如通过日志泄露），照样能进。换IP是切断源头，回源鉴权是加固防线，两者要配合。如果地址已经在公开渠道扩散，必须先换IP再配鉴权。怎么确认源站IP是不是真的泄露了？看三个地方：一是CDN源站日志，如果出现非回源IP段的请求，大概率真泄露；二是证书透明日志，搜一下域名是否出现过源站IP；三是被动DNS，用在线工具查历史解析记录。如果都没有，那可能是回源配置问题，别急着换IP。接入高防CDN后源站IP是否就不可能再被发现？不是绝对的。高防CDN能大幅增加探测难度，但如果源站还有其他出网路径（邮件、监控、第三方回调），IP照样会暴露。回源白名单和鉴权能限制直接访问，但无法保证100%隐藏。所以还要持续监控解析记录和日志，定期做暴露面检查。
高防CDN缓存策略优化以降低源站压力怎么做？5步配置
先把第一步做了：把缓存键（Cache Key）里的随机查询串去掉，让同一种资源只对应一个缓存对象。高防CDN缓存策略优化以降低源站压力，五步走：缓存键归一化 → 开启请求折叠 → 分层回源 → 路径分治 → 回源收口。下面每一步都有可执行动作和验证指标。先算一笔账：缓存命中率每差10个百分点，源站要多接多少并发假设你的站点总请求量是10万QPS，缓存命中率90%时，回源QPS是1万；命中率掉到80%，回源QPS变成2万——源站并发负载直接翻倍。这个换算关系（回源并发 = 总请求量 × 未命中率）是整个优化策略的出发点。缓存命中的意义不只是省带宽，更是把并发压力留在边缘。（演算示例，非实测数据）为什么挂了CDN源站还是被打满：三类未命中请求的来源源站仍被压垮，通常有三条路：源站真实IP泄露：攻击者全网扫描后绕过CDN直连源站，这是CDN安全体系中最普遍的漏洞（AWS DDoS 弹性架构最佳实践白皮书，2025年10月更新）。缓存穿透：攻击者构造海量带随机参数或畸形路径的请求，每个请求都未命中缓存，全部回源。自身规则缺失：静态与动态路径没有合理区分，导致所有请求全量回源。针对第一类，建议先参照如何防止源站真实IP暴露完成源站IP收口，这是所有缓存优化的前提。第1步：缓存键归一化，让随机查询串不再制造独立缓存对象默认情况下，CDN会把完整URL（含查询串）作为缓存键，导致每个带不同参数的请求都生成一个独立缓存对象，命中率被稀释到接近零。动作：在CDN控制台的缓存键设置里，按白名单保留业务真实需要的参数（如分页、语言、版本），忽略营销与追踪类参数；同时统一大小写与末尾斜杠。带随机参数的请求要防止缓存穿透，靠的也主要是这一步。第2步：开启请求折叠，把同一资源的并发回源收敛成一次请求折叠（Request Collapsing）机制：当同一边缘节点上多个并发请求同时未命中同一个缓存键时，这些请求会在该节点排队，等待首个回源结果返回后共享，而不是各自穿透回源。动作：在CDN配置中开启请求折叠，同时设置合理的回源超时，并启用stale-while-revalidate类策略（过期后先返回旧内容，后台异步更新）。AWS 在《Best Practices for DDoS Resiliency》中关于 CloudFront 的章节指出，请求折叠与层级缓存配合严格回源白名单，可有效防止CC攻击穿透并降低源站并发负载。第3步：分层回源（Origin Shield），减少多节点各自回源的放大效应没有分层时，N个边缘节点对同一资源各回源一次，源站看到的是N倍请求。开启分层回源（Origin Shield）后，所有边缘节点先回源到中间层，由中间层统一收敛后再回源站。动作：选择离源站机房近、且与回源链路方向一致的节点作为Origin Shield层。它与请求折叠是叠加关系：请求折叠解决同一时刻的并发合并，Origin Shield解决跨节点的重复回源。第4步：静态、半静态、纯动态三类路径分治，动态接口用什么替代缓存不同路径的缓存策略应分开配置：路径类型示例缓存策略静态图片、CSS、JS长TTL（如1年），配合内容哈希版本号半静态商品详情、列表页短TTL（如60秒），过期后后台异步刷新纯动态登录、下单、个人中心不缓存，改用频控、验证挑战、连接层限流兜底动态接口能不能走CDN缓存？能缓存的是可容忍秒级陈旧的读接口，比如配置拉取；写接口与个性化响应绝不能缓存。第5步：未命中请求的兜底——回源限流与回源白名单收口缓存策略只能压缩未命中量，不能消灭它，因此必须给源站设回源并发/QPS上限，并在源站安全组只放行CDN回源网段，关闭公网直连入口。源站侧的限流阈值与连接数控制可参考Nginx防CC攻击限流配置最佳实践。到这一步，高防CDN缓存策略优化以降低源站压力的五个动作才算闭环——缓存压缩未命中量，白名单堵住绕过路径。这一收口动作与无感接入高防CDN配置流程配合，才能真正堵住直连源站的路径。严格回源白名单是形成防护闭环的必要条件。配完怎么验：命中率、回源QPS、回源带宽三个指标怎么看高防CDN缓存策略优化以降低源站压力是否生效，只看三个指标：指标怎么看字节命中率 vs 请求命中率字节命中率高但请求命中率低，说明大文件命中好但小请求穿透多回源QPS曲线流量峰值时曲线被削平，说明边缘吸收了并发回源带宽与总带宽比值比值显著下降，说明资源在边缘被复用用带随机参数的构造请求做穿透自测，确认缓存键归一化生效。看趋势与相对变化，不追求绝对数值。缓存策略解决不了的部分：拟真Bot与秒级攻击窗口Radware 2026全球威胁报告显示，网络层DDoS攻击同比增长168.2%，多数Web DDoS攻击在5分钟内结束，部分甚至低于60秒；恶意Bot流量同比增长91.8%。这意味着缓存与回源规则必须在攻击发生前预置，人工临时调整赶不上攻击节奏。拟真Bot与低频分布式请求会攻击动态接口，这需要WAF与行为识别配合，缓存优化不能替代流量清洗。RockCloud 在边缘缓存与回源收敛环节的落位方式当你理解了缓存键、请求折叠、分层回源与回源白名单后，RockCloud高防CDN可以在链路上这样落位：边缘缓存与Anycast就近吸收承担“把并发挡在边缘”这一段；源站保护与回源白名单承担“堵住直连源站”这一段；智能WAF与Anycast全球网络承担“缓存管不到的动态接口与秒级攻击窗口”这一段。它与你自己的缓存规则设计是分层协作关系，不替代你的策略。常见问题接了CDN源站还是被打满怎么办？先按高防CDN缓存策略优化以降低源站压力的排查顺序走：先查源站IP是否泄露，再看缓存命中率。若命中率低，优先做缓存键归一化与请求折叠；若命中率正常但回源QPS仍高，检查是否被绕过CDN直连，收紧源站白名单。CDN缓存命中率低是什么原因？常见原因有缓存键未归一化（随机参数导致穿透）、缓存规则未区分路径（动态内容强制缓存但实际不可用）、TTL设置过短导致频繁回源。按本文第1步和第4步优化即可。带随机参数的请求怎么防止缓存穿透？开启缓存键归一化，按白名单保留必要参数（如页码、版本），忽略营销追踪参数。同时可配合请求折叠，让未命中的并发合并为一次回源。回源请求合并怎么配置？在CDN控制台开启请求折叠（Request Collapsing），并启用分层回源（Origin Shield）。前者合并同一时刻的并发回源，后者合并跨节点的重复回源，两者叠加效果最佳。CDN回源带宽太高怎么降？先提高缓存命中率（重点优化缓存键和TTL），再开启分层回源（Origin Shield）与请求折叠，减少重复回源。同时确认源站只接受CDN回源，避免被直连消耗带宽。缓存TTL设多长合适？静态资源可设1年并带版本号；半静态内容建议60秒左右并配合后台刷新；动态内容不设缓存。TTL过长会导致内容更新滞后，过短则增加回源压力。建议你先按“配完怎么验”一节给出的命中率、回源QPS、回源带宽三个指标做一次基线自测，并构造一次带随机参数的请求验证缓存穿透是否存在；若确认回源并发无法收敛或源站入口尚未收口，可联系 RockCloud 技术支持一起梳理缓存规则与回源白名单。
WebSocket长连接DDoS攻击防护方案的落点是四道闸：握手鉴权、单IP并发连接配额、消息频率与帧大小限制、空闲心跳超时回收。之所以要另起一套方案，是因为传统逐请求型WAF在HTTP 101 Upgrade之后失去检测点。典型症状是：游戏对局房间或行情推送的连接数在几分钟内翻倍，而带宽与QPS保持低位，内存与文件描述符（FD）不断爬升。实时业务的全面WebSocket化，正在把一种新型的连接耗尽型攻击推到台前。OWASP 在 2026 年的 WebSocket 安全指引中，将握手阶段校验、单 IP 并发连接配额与单连接消息速率限制列为明确要求；Cloudflare 的网络设置文档也确认了边缘节点对 WebSocket 长连接的原生支持与空闲超时机制。这些标准与官方表述，共同指向一套四道闸的防御框架。先分流：连接数暴涨但带宽和QPS都不高，到底是攻击还是自己的问题攻击形态有三类：一是握手洪泛，攻击者用极低成本反复完成握手，把连接池占满，连接曲线只增不减，但单连接几乎无业务流量；二是单连接高频小包帧洪泛，一条合法连接内持续发送大量小型数据帧，推高内存与CPU占用；三是伪造跨站握手（CSWSH，Cross-Site WebSocket Hijacking），利用浏览器同源策略盲区，把受害者会话引导到攻击者控制的端点。若连接建立后长期低速占用而不断开，形态更接近慢速CC攻击防护所述场景。与之相对，不少“攻击”其实是自己的问题：代码里连接未正确关闭导致泄漏、客户端在弱网下反复重连形成风暴。区分的关键是看连接曲线形态——攻击性增长通常是阶梯式或突发式上涨，且不会自然回落；连接泄漏往往是缓慢爬坡，重连风暴则呈现周期性波动。为什么逐请求型WAF在HTTP Upgrade之后就不再介入：检测断点在哪WebSocket 的握手过程是客户端先发一个普通的 HTTP Upgrade 请求，服务端响应 HTTP 101 Switching Protocols 之后，连接就切换为双向持久数据传输。关键点在于，从 101 响应发出后，这条 TCP 连接内流动的不再是“请求-响应”对，而是连续的、不分包的文本或二进制数据帧。逐请求型 WAF 只能逐请求检测，无法对长连接内部的持续数据帧做持续过滤。这导致传统 CC 防护在 WebSocket 场景下几乎失效，攻击者只需一次握手即可长期占用资源。WebSocket 攻击与 HTTP CC 攻击的本质区别在于计量单位：HTTP CC 按请求数，WebSocket 按连接数和消息数；成本结构也不同，握手成本远低于完整请求，且更耗内存和 FD 而非带宽。这正是WebSocket长连接DDoS攻击防护方案必须另起炉灶的原因。第一道闸：握手阶段的Origin与凭证校验，把拒绝动作放在建连之前连接一旦建立，回收的成本远高于拒绝的成本。OWASP 指引强调，握手阶段必须强制校验 Origin 与凭证。具体校验清单包括三点：一是校验 Origin 头，只放行白名单内的来源，防止跨站伪造握手；二是认证令牌在握手阶段核验，而非等首帧到达——因为恶意连接可能在首帧之前就产生资源占用；三是拒绝时直接返回握手失败，而非先升级再断开。副作用与误伤风险：移动端原生客户端、服务端间通信往往不携带 Origin 头，强制校验会导致合法连接被拒。建议对带 Origin 的请求校验来源，无 Origin 的兜底校验凭证，并把白名单做成配置项。第二道闸：按IP或用户设并发连接配额，配额怎么估、NAT用户会不会误伤单 IP 并发连接配额是四道闸里最容易配错的一环。配太少，NAT 后的真实用户被误杀；配太多，又起不到隔离攻击者的作用。合理做法是先用业务基线估算：统计正常用户平均连接数，乘以安全系数作为配额起点。实现上在边缘或应用层按 IP 维度限制，但更推荐叠加用户维度。Nginx 的 limit_conn 指令作用于连接维度，需配合 Upgrade 和 Connection 头透传。Nginx 侧的限流写法可参考Nginx防CC攻击限流配置最佳实践。副作用与误伤风险：企业出口和移动网络普遍存在 NAT，纯 IP 配额容易误伤，配额值必须根据自身流量分布压测校准。第三道闸：消息频率与单帧大小限制，为什么要按消息数而不是按请求数计量OWASP 指引把单连接消息速率限制列为 DoS 防御的明确要求。正确做法是把计量单位切换到消息数、字节数和帧大小。建议分维度限制：每连接每秒消息数上限、单帧最大字节数、单连接累计流量上限。超限处置可梯度进行：先丢帧降速，再关闭连接并计入 IP 信誉。合法业务可能有突发，需设置豁免通道。副作用与误伤风险：限流阈值过紧会拦截真实业务流，建议先统计正常业务消息分布再设定阈值，保留动态调整接口。第四道闸：空闲超时与心跳回收，超时值设多短会误断真实客户端空闲超时是防止连接泄漏与僵尸连接堆积的兜底闸。Cloudflare 的 WebSocket 文档中提到，其边缘网络默认设定 100 秒无活动即切断连接——该值作为常见默认参考，不是行业标准，更不是你的业务标准。关键是把应用层心跳间隔设得短于链路上最短的空闲超时窗口。一条连接从客户端到源站可能经过 CDN、负载均衡、NAT 网关，每段都可能有自己的空闲切断机制，最短窗口决定真实保活期限。建议心跳间隔设为链路最短超时的一半以下，如 30 秒起步（该值为经验起点，需按自身链路各段实际空闲超时与断线率压测校准，非通用建议），同时客户端支持指数退避重连。WebSocket长连接DDoS攻击防护方案四道闸对照表与不合格信号速查下表汇总了WebSocket长连接DDoS攻击防护方案的四道闸：道闸作用层拦截时机关键判据误伤风险验证方式握手鉴权应用/边缘建连之前Origin 白名单、凭证核验移动端无 Origin 被拒用伪造 Origin 握手测试拒绝单IP并发配额边缘/应用连接建立时单IP连接数超阈值NAT 用户被误杀模拟 N 个不同 IP 同时建连消息频率限制应用/边缘连接持续期每连接每秒消息数、帧大小突发合法业务被限压测高频帧洪泛空闲超时回收边缘/源站连接空闲时超时无活动即断真实客户端被误断设置短超时测试断线率对照此表自查，若缺任何一道闸都可能被攻击者利用。不合格信号速查：连接数只涨不落、内存与 FD 同步逼近上限、断开率长期为零、单 IP 连接占比畸高。为什么连接终止与频控应前移到边缘：RockCloud的落位方式现代 CDN 与边缘反向代理原生支持 WebSocket 透传与连接汇聚，在 Anycast 节点完成协议终结与连接清洗，可显著收敛回源连接数，是抵挡连接耗尽型攻击的天然屏障。把连接终止和频控放在边缘，攻击者的握手请求在到达源站前就被处理，源站只保留超时回收与业务校验兜底。RockCloud 高防 CDN 与游戏盾在握手层承载长连接，按 IP 下发并发连接配额与消息速率策略，配合源站白名单与回源收口，防止攻击者绕过边缘直连 WebSocket 端口。边缘防护并非万能，无法完全阻断真实客户端发起的长连接滥用，也不能零误伤。若担心源站 IP 暴露，可参考如何防止源站真实IP暴露中的收口方案。上线前后的验证清单：压测方法与要盯的三个指标WebSocket长连接DDoS攻击防护方案配置完成后，必须做三类压测：握手洪泛、单连接帧洪泛、半僵尸连接。每类压测验证对应道闸是否按预期拒绝。灰度阶段先只告警不阻断，观察误断率再逐步收紧。三个必盯指标：①并发连接数与回源连接数比值，边缘生效时回源数应远小于客户端数；②进程 FD 与内存占用曲线应平稳；③真实用户异常断线率与重连成功率，过高说明配置过紧需回调。常见问题websocket连接数被占满怎么办？先看连接曲线：只增不减且带宽低，大概率是攻击，立即启用配额与超时回收；若缓慢爬坡，可能是连接泄漏，需检查代码中的关闭逻辑。websocket攻击和http cc攻击有什么区别？核心在计量单位：HTTP CC 按请求数，WebSocket 按连接数和消息数。握手成本远低于完整请求，且主要耗内存和 FD 而非带宽。websocket握手要不要校验origin？要。OWASP 明确要求校验 Origin 防止 CSWSH。移动端和服务端间可能不带 Origin，需兜底校验凭证。拒绝时直接返回握手失败。websocket心跳超时设置多少合适？没有标准值，需看链路最短空闲超时。以 Cloudflare 默认 100 秒为参考，建议心跳间隔设为链路最短超时的一半以下，如 30 秒起步（该值为经验起点，需按自身链路各段实际空闲超时与断线率压测校准，非通用建议）。高防CDN支持websocket吗？支持。现代高防 CDN 原生支持 WebSocket 透传与连接汇聚，可在边缘终结连接、清洗攻击并收敛回源连接数。具体并发上限和超时参数需咨询服务商。nginx websocket 单IP并发连接限制怎么配？使用 limit_conn 指令限制单 IP 连接数，需配合 Upgrade 和 Connection 头透传。配额值应基于业务基线估算，避免误伤 NAT 用户。长连接服务内存暴涨是被攻击了吗？不一定，也可能是连接泄漏或重连风暴。观察连接数是否只增不减、FD 是否同步爬升。若连接数稳定但内存涨，可能是帧洪泛，需结合四道闸排查。
无感接入高防CDN配置流程：6步零中断切换
无感接入高防CDN配置流程是否成功，只看三个条件：切换期间业务零断线、HTTPS证书不中断、回源错误率不抬升。满足这三点，才算真正无感。要做到并不难，关键是先把源站和回源层准备妥当，最后才动DNS——顺序错了，再好的高防也救不了现场的502和SSL报错。这里先把结论摆出来：无感接入高防CDN配置流程按以下6步执行，每一步都有明确的验证信号和失败回退路径，全程可灰度、可回滚，不存在必须停机切换的窗口：接入前盘点解析记录与非HTTP端口业务；源站预放行回源IP并校准回源HOST/SNI；对齐证书与回源协议，防止TLS握手失败和重定向死循环；调低DNS TTL，按5%~10%权重灰度切流并观测指标；配置真实IP透传，避免风控和限流失效；全量稳定后收口源站白名单，隐藏源站。需要提前完成接入，是因为攻击者不会等你切流。Cloudflare 2026 H1报告显示，2026年Q2超1Tbps攻击环比激增519%，且90.6%的网络层攻击持续不到10分钟，部分仅35秒。临时切流根本来不及。第1步：接入前盘点解析记录、非HTTP端口与子域名清单动手改解析之前，先清点清楚现有DNS资产，避免漏切导致部分流量掉线或源站IP残留暴露。需要整理三类记录：全部A/AAAA/CNAME记录：主域名、www、静态资源子域、API子域等，逐条列出；需要走CDN与不走CDN的子域名：例如纯API服务可能不需要CDN加速，但需要高防防护的域名必须纳入；非HTTP(S)端口的业务：如邮件SMTP、SSH、游戏TCP长连接等，这些流量不走CDN，需要单独规划防护或保持直连。TCP长连接类业务的防护形态差异，见高防IP和高防CDN区别。建议制作一张资产表格，记录域名、记录类型、当前解析值、是否走CDN、备注（如业务负责人）。这是后续灰度切流的基础。若还没确定服务商，选型维度可参考高防CDN怎么选。第2步：源站先放行回源IP并校准回源HOST，避免切流后立刻502切流后最常见的故障就是502 Bad Gateway或504 Gateway Time-out，根源往往出在源站侧，而不是CDN。根据阿里云官方文档（2026年7月更新），核心根因有两个：源站防火墙或主机安全软件把CDN聚合回源IP误判为攻击，直接拦截或限速；回源HOST与源站Web虚拟主机（站点配置中绑定的域名）不匹配，导致源站无法识别请求。所以，务必先放行，后切流：从CDN服务商获取回源IP网段（或回源节点IP列表）；在源站防火墙、安全组、主机安全软件（如云锁、安全狗）中把这些IP加入白名单；在CDN控制台配置回源HOST为源站实际绑定的域名；用本地hosts解析或指定回源域名，提前发起测试请求，确认源站能正常响应。验证方法：修改本机hosts，将业务域名解析到CDN CNAME，然后访问测试页面，观察状态码和响应时间。也可用 curl -H "Host: 业务域名" http://源站IP/ 直接验证源站是否按该Host命中正确站点。若出现502，按这个顺序排查：先看源站防火墙是否拦截、再看回源HOST是否正确。第3步：证书签发与回源协议对齐，别让HTTPS变成重定向死循环接入高防CDN后，HTTPS链路被拆成两段：客户端到CDN，以及CDN到源站。两段都要确认证书和协议一致。常见坑位：源站不支持HTTPS或缺少SNI扩展导致TLS握手失败；或源站80端口强制301跳转443，而CDN回源走80端口形成无限重定向循环。正确做法是让回源协议与源站实际能力对齐：源站支持HTTPS则回源协议设为HTTPS并校验源站证书；仅支持HTTP则回源协议设为HTTP并关闭强制跳转。验证清单：用curl -I测试CDN边缘节点访问确认返回200而非301/302，用openssl s_client检查TLS握手与SNI，并检查浏览器控制台有无混合内容警告。第4步：降TTL按权重灰度解析，高防CDN灰度切换看哪些指标这是无感接入高防CDN配置流程中风险最集中的一步。只有在DNS TTL足够低的情况下，灰度切换和回退才可能做到分钟级生效。操作步骤：提前24-48小时将现有A/AAAA记录的TTL调低至300秒或更低（有些CDN支持TTL=60秒）；在DNS服务商配置权重解析，将5%~10%的解析切到CDN CNAME；观察拨测数据和源站日志，确认无5xx、TLS错误、回源超时；逐步递增权重（如20%、50%、100%），每档观察10-20分钟，确认指标平稳后再继续。观察指标包括：指标阈值说明5xx占比不超过基线+0.5%502/504高发阶段TLS握手失败率0或接近0证书或SNI问题回源耗时P95与切换前持平源站负载是否异常缓存命中率稳定或上升静态资源加速效果灰度比例与TTL取值来自阿里云官方文档（2026年7月更新），上表阈值为自定告警线，请按你自己切换前7天的监控基线校准。此阶段若发现异常，按「回退」章节处理即可，低TTL保证你能快速恢复。第5步：真实IP透传，解决接入CDN后获取不到用户真实IP接入CDN后，源站看到的TCP连接来源IP会变成CDN边缘节点的IP，而不是用户真实IP。如果不做透传，后端的风控、限流、审计日志都会失效。以Nginx为例，配置 ngx_http_realip_module 模块：set_real_ip_from <你的CDN回源IP网段>; # 必须以服务商实际公布网段为准 real_ip_header X-Forwarded-For; real_ip_recursive on; # 开启后自上游链从右向左跳过已声明的可信地址，取到最后一个不可信地址，即真实客户端IP注意：set_real_ip_from 必须指定为CDN回源IP网段，否则任何人都可以伪造X-Forwarded-For头。配置后，$remote_addr 将变为客户端真实IP。接着要同步调整：访问日志格式（记录真实IP）；限流模块（如 limit_req 按真实IP限速）；WAF或风控系统（从X-Forwarded-For取值）；应用层代码若直接读 REMOTE_ADDR 也需改为读取代理头。验证方法：查看源站日志，确认IP段不再是CDN回源IP，而是分散的用户IP。如果你担心防CC攻击限流失效，可以参考Nginx防CC攻击限流配置最佳实践进行加固。此外，RockCloud WAF在真实IP透传后依然有效，因为WAF通常基于HTTP请求头进行检测，只要源站正确透传X-Forwarded-For，WAF就能继续识别并拦截恶意请求。第6步：全量切换后收口源站白名单，完成源站隐藏全量切换稳定运行几天后，才可以进行最后一步：源站白名单收口。这一步的目的，是防止攻击者绕过CDN，直接通过源站IP发起攻击。操作要点：在源站防火墙/安全组中仅允许CDN回源IP和必要管理IP访问业务端口；同时清理历史解析记录并检查邮件头、源码、证书透明日志等泄露源站IP的渠道。注意：收口一定要放在最后。在灰度期间收口，一旦切流出现意外需要回退，源站被防火墙拦截会导致业务彻底不可用。如果你对源站隐藏的具体方法不熟悉，可参考如何防止源站真实IP暴露一文。切换失败怎么回退：回退顺序与耗时预估即使做足了准备，现场也可能出现意外。回退的关键是低TTL，它决定了恢复速度能有多快。回退顺序：立即将DNS权重切回原解析（如果还没全量，只恢复灰度部分）；如果已全量，则修改DNS记录，将域名解析回源站IP（TTL已调低，生效快）；保留低TTL窗口：在回退完成后，观察一段时间，确认业务恢复，再酌情调高TTL；若涉及源站白名单收口，先移除白名单限制，确保源站不拦截回源IP。触发回退的信号：信号可能原因5xx比例突增回源IP被拦、回源HOST错误、源站过载TLS握手失败大量出现证书不匹配、SNI问题回源耗时持续超时源站防火墙限速、源站网络异常回退速度以TTL为上限，实际以源站与CDN两侧日志中流量回落为准。这也是无感接入高防CDN配置流程的收尾保障。RockCloud 在回源收敛与源站保护环节的落位在整个流程中，RockCloud 高防CDN主要承接回源收敛、源站白名单和灰度观测这三个环节。回源收敛：源站入站策略只需对齐 RockCloud 高防CDN 的回源来源，与第2步的白名单动作一一对应；源站隐藏：通过CDN代理，源站IP不再直接暴露，配合收口操作进一步降低被绕过攻击的风险；灰度观测：RockCloud 日志服务可用于灰度期间的状态码与回源异常比对。常见问题接入高防CDN会不会导致网站断线？按上述流程严格操作，不会断线。关键在于先源站准备，再灰度切流，并保持低TTL。CNAME接入高防CDN多久生效？生效速度取决于TTL与递归DNS缓存行为。判断生效看源站日志中旧解析流量是否归零。网站接入CDN需要改哪些DNS记录？通常只需将A/AAAA记录改为CNAME指向CDN别名。无需更改NS或MX，保留原记录备份以便回退。接入高防CDN后HTTPS证书怎么配置？配置两层证书：客户端到CDN用CDN证书，CDN到源站用源站证书。确保证书有效、SNI正常，回源协议与源站一致。接入CDN后回源502怎么排查？按顺序检查三步：一、源站防火墙是否拦截回源IP；二、回源HOST是否配置正确；三、源站是否过载或超时。多数情况是前两点引发，放行后立即恢复。高防CDN怎么做灰度切换和回退？灰度切换通过DNS权重解析实现，先切5%~10%，观察无异常再递增。回退则直接调整权重或恢复原A记录。接入CDN后获取不到用户真实IP怎么办？在源站Nginx配置 ngx_http_realip_module，设置 set_real_ip_from 为CDN回源网段，并指定 real_ip_header X-Forwarded-For。配置后重启Nginx即可。
如何防止源站真实IP暴露：5个泄漏点自查与回源收口
如何防止源站真实IP暴露，判断标准只有两条：泄漏路径是否切断、访问入口是否锁定。接入高防CDN只是第一步，若源站未做访问控制，攻击者可通过探测绕过边缘直打源站，防护等于空挂。AWS 官方架构实践指出，未对源站配置严格访问控制（仅放行CDN回源IP）时，攻击者可探测真实源站IP并发起绕过边缘的攻击。下面按泄漏点自查与收口动作的顺序，给出可照做的清单。泄漏点一：历史DNS解析记录与遗留A记录接入CDN前的解析历史、被动DNS数据留存，都会让新防护形同虚设。攻击者通过查询历史解析记录，就可能获取接入前的源站IP。自查方法：核对当前全部解析记录，清理指向源站的遗留A记录，确认没有仍解析到源站的备用域名。判断标准：所有公网解析均指向CDN或高防节点，源站IP不出现在任何解析结果中。泄漏点二：邮件发信、告警通知等由源站直接出网的服务源站直接对外发起连接的服务（发信、Webhook、主动回调、更新拉取）会在报文与日志中暴露出网IP。例如，网站发邮件若经源站SMTP直发，收件方可从邮件头看到源站IP。自查方法：检查发信链路是否经独立中继，对比出网IP与源站IP是否一致。若一致，需将发信迁移至第三方邮件服务或独立中继IP。泄漏点三：未接入边缘的子域名、后台入口与测试环境很多站点只把主域名接入CDN，子域名、后台、监控、对象存储回源域名、测试环境仍直连源站，甚至与主站同IP或同IP段，等于直接暴露主站源站。自查方法：列全子域名与泛解析记录，标记未接入边缘的服务，检查CNAME指向。若子域名解析到源站IP，攻击者即可定位并绕过边缘。泄漏点四：非HTTP端口与四层直连探测，为什么只改DNS不够攻击者可通过四层直连探测（如TCP端口扫描，或通过端口与服务响应特征）定位真实源站，并利用协议层攻击（如SYN Flood、ACK Flood）与应用层CC攻击混合发起，消耗源站状态表与计算资源。CISA 与 FBI 联合指引强调，防御必须在前置边缘节点进行状态校验与过滤，例如 SYN Flood防御。只改DNS不解决端口直连问题，因此自查非必要开放端口与服务指纹，关闭源站公网非必要端口。泄漏点五：回源配置自身泄漏——回源HOST、跳转与错误页回源HOST设置不当、301/302跳转带出源站地址、默认错误页或调试页面回显后端信息，都会让IP从边缘背后漏出。自查方法：对比边缘响应与直连响应的头部和页面内容，检查回源HOST是否与公网域名一致，清理错误页中的后端IP或主机名。收口动作一：源站只放行CDN回源IP的白名单与安全组写法落实如何防止源站真实IP暴露，最核心的一步是源站只放行CDN回源IP。配置顺序：先按回源IP段配置安全组或网络ACL，再收缩到必要端口（80/443等），最后处理默认拒绝策略。注意：回源IP段会变更，需建立同步机制（如定期拉取官方IP列表）。回源IP段的发布方式与变更频率各厂商不同，具体以所用边缘服务的官方IP列表为准。副作用：健康检查、内网办公、运维通道需单独放行。验证方法：从任意非回源节点对源站IP的80/443直连，预期结果为超时或连接被拒；同时保留一条运维白名单以免自锁。收口动作二：回源鉴权与回源收敛，压缩源站暴露面网络层白名单之上，再加一层来源校验（如回源鉴权、专用回源标识），可防止伪造源IP绕过白名单。回源收敛（如CDN的Origin Shield或回源收敛层）可减少直接触达源站的节点数量，降低被探测概率。这属于架构闭环，而非单点开关。换IP不是终点：换IP后仍被攻击的复盘顺序换了源站IP仍被攻击，这一步仍属于如何防止源站真实IP暴露的闭环环节。可能原因：新IP进入过公开解析或出网链路；白名单未真正生效；仍有未接入边缘的资产；攻击并非绕过源站而是边缘侧被打。复盘顺序：先确认新IP是否暴露过，再用非回源IP直连验证白名单是否拒绝，再遍历子域名与出网服务，最后区分攻击类型，参照 DDoS应急响应。RockCloud 在源站保护与回源收敛环节对应哪几条RockCloud 高防CDN 的回源IP段白名单对应自查清单“访问控制”行，源站保护对应“回源配置”行，Anycast 全球节点回源收敛对应暴露面压缩。建议先按上表跑完自查，再对照回源IP段维护与源站访问控制的落地方式复核一次。源站IP暴露自查清单（可直接照做）下表把如何防止源站真实IP暴露的全部动作压缩成一页可勾选清单。检查项操作通过判据解析记录核对全部A记录/CNAME无记录指向源站IP邮件发信检查邮件头出网IP出网IP与源站IP不同子域名列全子域名并检查解析所有子域名均走CDN或源站隔离端口与服务扫描公网端口仅开放80/443等必要端口回源配置对比边缘与直连响应无源站IP或主机名泄漏访问控制非回源IP直连测试连接被拒绝常见问题网站发邮件会泄漏服务器真实IP吗？会。若邮件经源站SMTP直发，收件方可从邮件头看到源站IP。应将发信迁移至独立中继或第三方邮件服务，确保出网IP与源站分离。子域名没接CDN会不会暴露主站源站？会。若子域名与主站同IP或同IP段，攻击者可通过子域名解析定位源站。应将所有子域名接入CDN或使用独立IP隔离。源站只允许CDN回源IP访问要怎么配置？在云安全组或网络ACL中，仅放行CDN回源IP段，默认拒绝其他来源。需同步回源IP段变更，并单独放行健康检查与运维IP。换了源站IP又被攻击是什么原因？可能新IP已通过解析、邮件或子域名暴露；或白名单未生效；或存在未接入边缘的资产。按复盘顺序逐项排查。源站IP泄漏了必须换IP吗？不一定。若白名单配置生效，攻击者无法直连源站，可暂不换IP。若已有明文记录或出网暴露，建议更换并同步更新白名单。
BGP Anycast技术在DDoS清洗中的应用，本质是把入方向流量按路由就近分散到多地边缘节点承载，避免回源链路与单一清洗中心成为瓶颈，它并不等于清洗能力本身。但服务商宣称的Anycast能力是否属实，需要通过三个可自测链路来验证：入方向路由宣告、边缘本地丢弃、节点摘除与收敛时延。本文基于Cloudflare 2026年5月更新的参考架构与CISA官方告警，给出具体验证动作和判据。先说结论：Anycast在DDoS清洗链路里只解决三件事BGP Anycast技术在DDoS清洗中的应用，核心是把攻击流量分散到多地边缘节点就近承载，避免回源链路和单一清洗中心成为瓶颈；它本身并不等于清洗能力。 2026年5月Cloudflare参考架构明确，利用BGP Anycast路由广播可将入站流量分散到全球边缘节点，结合XDP/eBPF架构在边缘单点实现秒级自动化无状态清洗。该实现属于Cloudflare Magic Transit参考架构（2026-05更新）中的厂商自有方案，不代表所有服务商的边缘清洗都具备同等实现，验收时仍需按下文三步自测。对于超大流量攻击，分散承载点比堆单点容量更关键。路径A vs 路径B：集中式引流清洗与Anycast就近吸收的流量走向差异传统集中式清洗方案（路径A）把攻击流量牵引到少数清洗中心，过滤后再回注源站，流量需要绕行到特定地域，延迟较高。而Anycast方案（路径B）由多地边缘节点同时宣告同一前缀，流量自动就近吸收，攻击包在边缘被丢弃，干净流量直接回源，减少了绕行跳数。这回答了“anycast和单播清洗有什么区别”：单播清洗是“引流到中心”，Anycast清洗是“就近吸收”。从延迟看，anycast清洗和引流到清洗中心哪个延迟低？ 通常Anycast更低，因为流量无需绕行到集中清洗中心，但实际取决于边缘节点覆盖与路由策略。下表对比了两者的关键差异，若攻击已经发生，可参照DDoS应急响应的处置顺序；同时可参考高防IP和高防CDN区别进一步判断选型：对比项集中式引流清洗Anycast就近吸收流量走向牵引到少数中心，再回注分散到多地边缘，就近处理延迟影响绕行跳数多，延迟高就近承载，延迟低链路瓶颈回注链路易拥塞边缘链路分散，瓶颈概率低适用场景合规要求严格的场景超大流量、全球业务为什么超大流量下先卡住的是链路而不是清洗设备根据CISA告警，无连接UDP协议（如DNS、NTP、SSDP、CLDAP）缺乏源地址验证，容易被伪造源IP用于反射放大攻击，产生数十倍至数百倍的流量放大。这类攻击先打满的是入口与回注链路带宽，而非清洗设备处理能力。因此，分散承载点比堆单点容量更有效——这也是BGP Anycast技术在2026年高防选型中被前置的核心原因。验证第一步：确认入方向路由确实由多地节点宣告验证BGP Anycast技术在DDoS清洗中的应用是否属实，第一步是确认入方向路由由多地节点宣告。你可以使用RIPE Atlas探针，或在各地云主机执行 mtr -rwzc 20 目标IP 与 traceroute -A 目标IP，记录倒数第二跳的AS号与城市；再通过bgp.he.net的prefix页、RIPEstat的routing-status或Route Views/RIS查询同一前缀的上游AS数量与AS-Path。观测指标：不同地区倒数第二跳AS/城市是否不同，同一前缀的上游AS数量是否大于1。不合格信号：所有地区最后都收敛到同一出口城市，说明可能只是单点+GRE回注。前缀仅由单一上游宣告，缺乏多地宣告。服务商只提供GRE隧道回注方案，却宣称Anycast。多地ping同一个IP延迟差很大正常吗？ 如果是真Anycast，不同地区的延迟有差异正常，因为流量就近接入不同边缘节点；但如果所有地区延迟接近且都很大，则可能流量被集中引流到了同一中心。验证第二步：攻击流量在边缘本地丢弃还是回传清洗中心第二步是观察攻击流量是否在边缘本地丢弃。你可以在受控压测中对比多地探测点的RTT与丢包分布，要求服务商提供边缘节点侧的丢包与命中统计，并检查干净流量是否出现路径变长。不合格信号：攻击一起所有地区延迟同步抬升，说明流量被回传到中心处理；清洗生效后路径明显变长，说明可能发生了绕行。验证第三步：BGP Anycast路由收敛要多久、会不会导致TCP连接中断第三步是验证节点摘除与路由收敛时延，这关系到“bgp anycast路由收敛要多久”和“anycast节点会不会导致tcp连接中断”。方法：在压测中主动请求摘除某地节点，记录多地探测点重新可达的时间窗，观察TCP长连接、TLS会话是否重连，以及有状态业务（登录态、上传、WebSocket）的表现。收敛时间取决于上游策略与传播，未经验证的数字不应采信。如果摘除时出现长时间中断，或连接频繁重置，可能说明节点间会话保持不佳。三步验证对照表与不合格信号速查下表把BGP Anycast技术在DDoS清洗中的应用的三步验证动作汇总，可直接用于验收清单：验证步骤验证动作需要材料合格信号不合格信号1. 路由宣告多地traceroute、查询RIR前缀宣告清单多地可见不同节点宣告所有地区收敛同一出口2. 边缘本地丢弃压测对比RTT与丢包边缘节点丢包统计攻击时仅部分区域受影响所有地区延迟同步抬升3. 收敛时延摘除节点测试摘除演练记录快速恢复，连接基本保持长时间中断或连接重置若攻击已经发生，可参照DDoS应急响应的处置顺序，也可参考高防IP和高防CDN区别补充选型依据。Anycast解决不了的部分：应用层判定、会话保持与源站暴露BGP Anycast技术只能影响流量落点与承载，无法识别拟真Bot、API业务逻辑滥用与慢速连接耗尽，也不能自动消除历史DNS记录、邮件出口或未回收IP造成的源站暴露。因此需要配套应用层防护与会话一致性设计。你可以参考高防CDN怎么选中的选型思路，结合BGP高防与单线高防区别与选型，确认是否需要额外防护。RockCloud在边缘承载与源站保护环节的落位方式在验证方法讲清后，再看RockCloud的Anycast全球网络与高防CDN如何落位：其Anycast全球网络对应第一步的多地宣告，高防CDN边缘过滤对应第二步的本地丢弃，WAF与CC防御对应Anycast覆盖不到的应用层判定。签约时，你可以向服务商索取前缀宣告来源、多地探测报告、摘除演练记录等验证材料。常见问题怎么判断一个IP是不是Anycast？用多地traceroute，如果不同地区看到的最后几跳AS和地理IP不同，通常是Anycast；如果所有地区都收敛到同一AS与地理位置，则可能是单播。Anycast节点会不会导致TCP连接中断？如果节点切换时会话未同步，可能导致TCP重置。但成熟的Anycast方案会尽力保持会话一致性，摘除节点时观察连接是否重连即可验证。多地ping同一个IP延迟差很大正常吗？正常。真Anycast节点多地分布，就近接入导致延迟差异；但如果延迟都很大且接近，则可能流量被集中引流。Anycast清洗和引流到清洗中心哪个延迟低？通常Anycast更低，因为它就近吸收流量，减少绕行。但实际取决于节点覆盖和路由策略，需实际测试。是否需要同时保留清洗中心方案？是否需要同时保留清洗中心，取决于业务地域分布、合规要求与现有接入方式。Anycast影响的是流量落点与承载，清洗效果仍取决于边缘过滤能力，因此不能仅凭是否Anycast做取舍。
先回答：高防CDN怎么选，六条判据比标称峰值更该先看高防CDN怎么选？先看六条判据：清洗触发时延、节点分布与单节点承载、七层规则粒度、回源与源站保护、误杀率与放行通道、超峰处置权归属；标称防御峰值只是入门门槛。之所以把响应速度排在峰值之前，是因为Radware 2026年Q1威胁分析报告显示，网络层DDoS攻击同比激增168.2%，绝大多数超大流量攻击的持续时间已被压缩至5分钟以内，部分甚至低于60秒。这意味着，从异常出现到清洗生效的响应链路，比报价单上那个唬人的防御峰值更关键。在谈具体判据前，先建立一个共识：高防CDN和普通CDN有什么区别？普通CDN解决的是内容分发与加速，节点靠近用户、缓存命中率高即可；高防CDN必须在流量进入节点时完成清洗与过滤，检测、调度、处置的自动化程度直接决定业务在攻击窗口内的存活率。下面六条判据，都围绕这一核心差异展开。报价单上写了什么、没写什么：标称防御峰值之外的四个空白项典型的高防CDN报价单，通常写清峰值带宽、节点数量、QPS上限，这三项最能直观对比，但也最容易形成误导。真正决定攻击发生时业务是否可用的，往往是报价单上缺失的四个空白项：报价单常见项目通常标示方式容易缺失的信息为什么重要防御峰值标称Tbps/Gbps检测周期与清洗生效时间攻击已压缩至分钟级，慢半拍等于没防节点数量“全球XX个节点”单节点可承载量与调度逻辑总容量不等于可用容量，流量可能挤在单一节点QPS/并发上限标称数值规则自定义边界复合攻击需要按接口、参数、指纹自由下规则服务等级7×24人工响应超峰处置方式与触发条件超出套餐后是扩容、限速还是封禁，直接影响成本与可用性要求销售在报价单右侧四列上逐项书面补齐，补不齐的项即为风险项。判据一：从异常出现到清洗生效要多久这是当前环境下高防CDN怎么选的第一优先级判据。Radware 2026年Q1威胁分析报告点名的正是“DDoS时间压缩”现象：攻击不再持续数小时等你发现，而是在几分钟甚至几十秒内完成冲击。旧有的人工告警、登录控制台看流量图、再手动切换DNS的处置链路，在这样短的攻击窗口内完全失效，必须依赖DDoS应急响应机制中的自动化处置。验证方法：要求厂商书面说明检测采样周期与清洗触发时延，而不是口头承诺“秒级”；在POC期配置测试域名，故意触发流量异常，对比攻击起始时间戳与规则生效时间戳。确认清洗是自动化触发还是需要提交工单。不合格信号：只承诺“7×24人工响应”；无法说明检测采样周期；需要客户先提交工单才启动清洗。判据二：节点分布与单节点承载Cloudflare的2026年上半年报告显示，超过1Tbps的超大流量DDoS攻击环比暴增519%，DNS放大与CLDAP反射成为主力向量。面对这种量级，总容量不等于可用容量——如果你的业务流量被调度到一个承载能力不足的节点，即便厂商全网总带宽再大也无济于事。验证方法：核对目标业务区域内的实际接入节点，而非“全球几百个节点”的总数；请厂商说明单节点带宽与就近调度逻辑。用不同地区的拨测工具确认解析落点是否真的就近。这里顺带回答两个采购环节最常被问到的问题：高防CDN能防1T以上的攻击吗？取决于单节点承载与Anycast分摊能力，而非总带宽数字；高防CDN节点数量重要还是单节点带宽重要？节点数量保证覆盖面，单节点带宽保证突发冲击下的存活，两者缺一不可。另外了解下高防IP和高防CDN区别与BGP高防与单线高防区别与选型，有助于综合评估。判据三：七层规则粒度与自定义能力在1Tbps脉冲流量背后，往往是四层洪泛与七层应用攻击的复合。四层清洗之外，你需要确认厂商是否支持按URL路径、请求参数、Header与客户端指纹组合下规则，是否支持速率限制、人机校验分级，以及规则变更的灰度与回滚机制。验证方法：POC期让厂商工程师为一个真实业务接口现场配置一条规则，观察生效时间、命中日志的详细程度，以及误配后能否快速回滚。不合格信号：只能使用厂商预置的固定规则模板，不允许按业务特征自定义。判据四：回源链路与源站保护是否闭环接入高防CDN后源站仍可能暴露：历史DNS解析记录、子域名探测、邮件头信息、直连IP扫描，都是攻击者找到源站的常见路径。选型时必须确认厂商是否提供完整的源站保护闭环。验证方法：检查是否支持回源IP白名单、回源加密与源站直连拦截；自行用外部扫描工具确认源站是否仍可被直接访问。不合格信号：只能隐藏域名，不提供源站IP白名单或回源加密；无法解释历史解析记录的处理方式。判据五：误杀率与放行通道任何高防CDN都存在误杀可能，宣称零误杀本身就是危险信号。问题关键不是会不会误杀，而是误杀后的发现与恢复速度。误杀发生后怎么办，POC期就该测清楚。验证方法：灰度切一部分真实业务流量到高防CDN，对比接入前后的正常请求拦截日志与业务转化数据；测试白名单与紧急放行的生效时延，确认操作权限是否在运维侧而非仅限厂商。不合格信号：无法提供灰度切流方案；放行操作需要走工单且超过分钟级。判据六：超峰、封禁与恢复的处置权归谁当流量瞬时超出所购套餐峰值时，不同厂商的处理方式差异很大：有的自动弹性扩容，有的限速保底，有的直接临时封禁。这也是“一个月多少钱”这一问题的真实答案所在——差价往往藏在超峰条款里。验证方法：在合同或SLA中明确要求写明：触发超峰的条件、通知方式与时限、临时处置动作（扩容/限速/封禁）、恢复流程，以及超峰流量的计费口径。不合格信号：销售口头承诺“超峰不会断”，但合同里找不到对应条款。六条判据对照表与不合格信号速查把高防CDN怎么选拆成可执行动作，就是下面这张速查表。判据自测方法需要厂商提供的书面口径不合格信号清洗触发时延测试域名触发异常，对比时间戳检测采样周期与清洗触发时延人工响应、工单触发节点分布与承载核对区域节点，跨区拨测解析落点单节点带宽与调度逻辑只谈全网总节点数七层规则粒度现场配置真实接口规则规则自定义边界与回滚机制仅限预置模板回源与源站保护外部扫描源站直连状态回源白名单与加密方案仅隐藏域名、无IP白名单误杀与放行灰度切流对比，测试放行时延误杀告警与放行操作权限宣称零误杀、放行走工单超峰处置权核对合同与SLA条款超峰触发条件与计费口径口头承诺、合同无条款对照示例：RockCloud 高防CDN在这六条判据上的落位方式以上六条判据是通用的选型方法论，适用于评估任何厂商。作为对照，可以看RockCloud高防CDN如何在六条判据上落位：清洗触发时延与节点分布：采用边缘清洗与自动化处置机制，减少人工介入环节；基于Anycast的全球节点分布，通过就近调度分摊超大流量冲击。具体生效时延与单节点承载能力建议在POC期实测确认。七层规则粒度：智能WAF支持接口级规则配置，可按业务特征组合过滤条件，POC期可要求为你的真实接口现场配置验证。回源与源站保护：提供源站保护与回源控制能力，具体白名单与加密机制可在接入前与技术支持确认。误杀与放行及超峰处置：支持灰度切流与规则调试，误杀处理路径建议在试用期用真实业务流量验证；技术支持可配合讨论定制安全规则，超峰计费与处置条款以合同为准，请在签约前逐条核对。以上能力落位均为方向性说明，不构成对具体峰值、节点数、生效秒数的承诺，请务必用文中方法在自己业务上实测。签约前必须问服务商的问题清单高防CDN怎么选，最终要落到能不能问出这些答案。把下面这份清单直接复制到你的POC测试单里，逐条问、逐条记录：检测采样周期和清洗触发时延分别是多少？能否提供书面说明？清洗是自动化触发还是需要提交工单？支持哪些触发方式？我业务所在区域的接入节点有哪些？单节点带宽是多少？七层防护支持哪些自定义规则维度？能否按URL、参数、Header、指纹组合？源站保护支持哪些机制？回源IP白名单、回源加密、直连拦截都有吗？误杀告警和紧急放行的通道是什么？操作权限在谁手里？超过套餐峰值时的处置动作是什么？扩容、限速还是封禁？攻击期间的日志与报表留存多久？是否支持导出？防御峰值该怎么测？建议用低于套餐峰值的流量做阶梯测试，观察清洗触发阈值与生效时间，而非追求真实攻击量级——安全测试本身也可能被误判为攻击。清洗多久生效？直接在测试环境压测并对比时间戳即可，不同厂商的检测周期差异远大于后端的清洗效率差异。常见问题高防CDN和普通CDN有什么区别？普通CDN解决内容分发距离问题，节点靠近用户、缓存命中即可；高防CDN在分发之外增加流量清洗能力，检测与过滤DDoS攻击，并具备源站保护、回源控制等安全机制。选型时需重点核对清洗检测链路与规则自定义能力，更系统的机制可参考DDoS防御与流量清洗体系。高防CDN多少钱一个月？包月和按量怎么选？月费数字只是表象，真实成本取决于超峰处置条款：包月套餐超峰后是限速还是弹性扩容，按量计费的单价是否含清洗费用，这些才是成本差异的关键。建议把超峰场景的预估费用也纳入对比。高防CDN能防1T以上的攻击吗？取决于单节点承载能力与Anycast分摊逻辑，而非全网总带宽。1Tbps以上的流量若集中落在单一节点，任何厂商都可能被打穿。签约前要求厂商说明单节点承载与调度策略，并结合自身业务区域实测。高防CDN清洗多久生效？攻击时长已普遍压缩至5分钟甚至60秒内（依据见前文），清洗必须在秒级完成才有效。POC期通过测试域名触发异常，对比攻击起始时间戳与规则生效时间戳即可测得实际生效时延。拒绝人工工单触发的方案。高防CDN误杀正常用户怎么办？选型时优先确认三项能力：白名单机制、紧急放行通道、误杀告警。POC期用灰度切流对比正常请求的拦截比例，验证从发现误杀到恢复放行的实际耗时。任何方案都存在误杀可能，关键是恢复速度。高防CDN接入后源站还会暴露吗？可能。历史DNS解析记录、子域名、邮件头信息都是源站暴露路径。接入后应启用回源IP白名单、回源加密与源站直连拦截，并定期用外部扫描自测源站是否仍可被直接访问。
慢速CC攻击防护怎么做？连接层四步定位与限流
慢速CC攻击防护怎么做？核心是把限流维度从 QPS 切换到连接维度，并按连接建立、请求接收、连接保持、异常回收四个环节收紧，必要时前移到边缘做连接完整性校验。2026年4月，MDPI 2026年4月研究证实，Slowloris 已从 Web 扩展到 SSH/FTP 等协议，形成 Slowloris E-DoS 攻击，低速率流量极易穿透常规带宽高防的检测。先分清三种情况：慢速攻击、普通CC，还是自己的连接池泄漏遇到服务器连接数被打满、但带宽和 QPS 都不高时，先别急着调参，第一步要做的是把故障归因搞清楚。慢速攻击、普通 CC 和自身连接池泄漏，三者表现相似但处置方式完全不同。特征维度慢速攻击普通CC攻击连接池泄漏带宽占用低，几乎不占带宽高，带宽明显抬升低或正常QPS / 新建连接速率低，QPS 不高高，QPS 与新建连接同时抬升正常或略高单连接存活时长异常长，请求头/体长期未完成短，请求快速完成长，但来源于内网或固定上游连接来源分散，多为外部 IP分散或集中，高频请求集中于内网或固定上游触发时机无明显发版关联随时可能多在发版后出现慢速攻击和CC攻击的区别在于：普通 CC 靠高频请求耗尽应用资源，而慢速攻击靠极低速率维持大量未完成请求，连接数高但 QPS 极低。如果连接数满且带宽不高，大概率是慢速攻击或连接池泄漏。如果连接来源集中在内网或固定上游，且出现在发版时间点附近，就要先自查连接池泄漏，避免盲目收紧超时误杀了正常业务。慢速CC为什么能绕过带宽型高防：低速率、少连接、不触发流量阈值很多人疑惑：明明接了带宽型高防，为什么还被打挂？因为慢速CC攻击不靠流量突增，它用极低的带宽维持大量半开连接，占满源站连接池并消耗 CPU/内存，而基于流量突增或静态阈值的清洗设备根本感知不到。与之呼应的是，Radware 2026年上半年报告显示，Web 应用层攻击同比暴增 128% 至 187.1%，攻击者借助自动化脚本模拟正常业务逻辑，让依赖静态 QPS 阈值的防御频繁失效。针对这类攻击，Layer 7 DDoS 攻击防护需要从连接维度入手。第一步：看连接状态分布与请求头接收耗时（可直接执行的判定命令与指标）以 Linux 系统为例，slowloris攻击怎么检测？可以用 ss 命令快速查看连接状态分布：ss -ant | awk '{print $1}' | sort | uniq -c | sort -nr如果发现大量 ESTABLISHED 状态的连接长时间存在，且这些连接的请求头/请求体接收耗时异常长，就需要进一步按源 IP 聚合并发连接：ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20Nginx 日志中并无直接的请求头接收耗时变量，实践中可用 $request_time 减去 $upstream_response_time 估算“客户端侧耗时”，并配合 log_format 增加 $connection_requests、$connection 观察单连接复用与存活情况。注意，所有阈值必须以自身业务基线为准，不要盲目套用网上数字。第二步：收紧连接建立与请求接收阶段的超时（参数含义与副作用）nginx怎么防slowloris慢速攻击？最直接的办法是收紧与请求接收相关的超时参数。Nginx 中主要涉及以下参数：参数作用副作用client_header_timeout请求头接收超时，超时后返回 408 并断开连接对弱网环境下接收慢的客户端可能误伤client_body_timeout请求体接收超时，防止慢速 body 攻击大文件上传可能超时失败send_timeout发送响应超时，防止慢速读取响应对慢速下载或流媒体可能误伤keepalive_timeout连接保持超时，限制空闲连接存活时长长轮询、SSE 等长连接业务可能被断开keepalive_requests单连接最大请求数，防止连接被无限复用对连接复用要求高的场景可能频繁重建连接这些参数只提高攻击成本，不能完全免疫慢速攻击。第三步：单IP并发与连接配额，为什么按连接数限而不是按QPS限慢速攻击的资源占用与请求数不成正比，所以限流维度要从“每秒请求数”切换到“单源并发连接数 + 未完成请求数 + 连接持有时长”。要限制单 IP 并发连接，使用 Nginx 的 ngx_http_limit_conn_module 模块：limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20;同时要规划好 worker 连接容量。Nginx 的 worker_connections 决定了每个 worker 能同时处理的连接数，如果太小，正常流量也会被拒；如果太大，又可能被慢速攻击耗尽内存。需要根据自身业务连接数基线来调整。在 NAT 出口等共享场景，按 IP 限并发可能误伤整个出口，可结合 User-Agent、TLS 指纹等动态维度精确定位。正如 Akamai 与 Radware 2026年研判指出，依赖静态阈值的策略在自动化攻击面前十分脆弱，限流策略也需要有动态维度。第四步：异常连接回收与观测告警项怎么配配置了超时和并发限制，还需要有回收机制和观测手段。对于长期未完成请求的连接，可以主动回收，比如用 Nginx 的 lingering_close 选项控制半关闭连接的处理。半开、半关闭状态的堆积也要限制，避免攻击者利用 TCP 状态消耗系统资源，相关机制可参考 SYN Flood防御。慢客户端与恶意慢连接的区别在于前者能完成请求，后者只占坑不传数据；对前者可放宽超时，对后者应尽早断开。建议长期观测这些指标：连接状态分布、单 IP 并发峰值、请求头接收耗时 P99、worker 连接使用率、CPU/内存与连接数的相关性。告警应基于基线偏移，而不是固定值——比如连接数比平时高出 30% 且请求头接收耗时显著增加，就触发告警。这样能避免误报，也能尽早发现慢速攻击苗头。不止 HTTP：SSH/FTP 等管理面服务的同类风险与暴露面收敛慢速CC攻击防护不能只盯着 80/443 端口。前述 MDPI 2026 年 4 月研究把 Slowloris 机制验证于 SSH 和 FTP 协议，形成了 Slowloris E-DoS 攻击：攻击者在身份验证阶段维持大量半开连接，拖垮服务器 CPU 与内存。非 HTTP 协议通常需要按端口做专用防护，因此优先采用端口收敛与白名单，而非把管理端口直接置于公网。具体可以这样做：配置认证阶段超时（比如 sshd 的 LoginGraceTime，建议调低）和未认证连接数上限（MaxStartups），防止半开连接堆积。管理端口不对公网直开，通过跳板机或零信任接入。按源 IP 收敛访问白名单，只允许办公网或堡垒机 IP。注意，这是研究性验证，并不是说 SSH/FTP 已经被大规模攻击，但风险是真实存在的，提前收敛暴露面总归没错。边缘侧能做什么：请求完整性校验与连接配额前移源站参数调优的天花板在于“连接终结在源站”。要真正降低压力，得把请求完整性校验、慢连接识别、并发配额和连接收敛前移到边缘。高防CDN能防慢速CC攻击吗？只有当边缘在七层连接层做请求完整性校验、慢连接识别和并发配额时，才能真正挡住慢速攻击；单纯网络层清洗或静态QPS限频对其基本无效。比如 RockCloud 高防CDN、智能WAF 和源站保护服务，就通过源站隐藏和回源连接收敛，让源站只面对完整请求，这样慢速攻击就被挡在边缘侧。对于 SSH/FTP 等非 HTTP 服务，应通过端口收敛和专用防护，而不是直接暴露到公网。选型时可参考高防IP和高防CDN区别权衡架构取舍。慢速CC攻击防护自查清单下面的清单可以直接拿去照着做，确保每个环节都覆盖了：[ ] 用 ss 命令查看连接状态并聚合并发连接。[ ] 日志记录请求头/体耗时，与基线对比。[ ] 分级设置超时参数，测试后放量。[ ] 用 limit_conn 限制单IP并发连接数。[ ] 开启连接回收机制并增加基线偏移告警。[ ] 收敛 SSH/FTP 管理端口，通过白名单接入。[ ] 评估是否将连接校验和配额前移到边缘。建议先按第一步命令跑出连接状态与耗时基线，再决定是否把连接层校验与并发配额前移。若源站已收紧超时仍被打满，可对照清单评估边缘方案或联系 RockCloud 技术支持结合自身连接特征调优。常见问题慢速攻击和CC攻击有什么区别？普通人眼里的 CC 攻击，大多指高频请求耗尽应用资源，QPS 很高；慢速攻击则是“细水长流”，单看流量不大，但靠大量未完成请求把连接池和系统资源拖垮。区别主要体现在带宽占用、QPS 和连接存活时长上。服务器连接数满了但带宽不高是什么原因？常见原因有两种：慢速攻击或自身连接池泄漏。慢速攻击的特征是连接数高、带宽低、单连接存活长；连接池泄漏则通常与发版相关，且连接来源集中在内网。可以先按文中第一步的命令排查，再结合发版时间点判断，不要盲目调参，免得误伤正常业务。只调Nginx超时够吗？不够。超时参数只是提高了攻击成本，但攻击者的慢速连接可以卡在超时时间内，持续消耗资源。要彻底解决问题，需要配合连接数限制、回收机制，甚至把防护前移到边缘，做连接完整性校验。高防CDN能防慢速CC攻击吗？看情况。普通带宽型高防只对流量突增敏感，对慢速攻击基本无效。但如果在七层连接层做了请求完整性校验、慢连接识别和并发配额，就能有效拦截。选型时要问清服务商是否支持连接维度校验，而不是只看防御带宽。SSH端口被大量半开连接占满怎么办？立即调整 sshd 配置：调低 LoginGraceTime（比如 20 秒），设置 MaxStartups 限制未认证连接数，并开启白名单只允许可信 IP 接入。如果公网必须开放，建议通过跳板机或 VPN 接入，从根上缩小暴露面。收紧超时会不会影响大文件上传和SSE？会。client_body_timeout 收紧后大文件上传可能超时；keepalive_timeout 收紧会断开长轮询和 SSE 连接。解决方法是按 location 分级配置：对普通 API 收紧，对上传接口放宽 body 超时，对 SSE 相关路径单独设置 keepalive 策略，做到精准限制不误伤。
DDoS应急响应怎么做？黑洞前后的处置顺序
DDoS应急响应怎么做？答案不是先找应急电话，而是按时间轴执行一套预置好的处置顺序：T+0 确认攻击类型、T+1 分流与切换、黑洞期取舍、恢复后复盘。这四步缺一不可，且每一步的先后顺序直接影响业务恢复速度。据 Radware 2026 Q1 攻击趋势数据，网络层DDoS攻击同比增168.2%，超90%的峰值攻击在5分钟内结束，部分甚至低于60秒。这意味着，传统“告警→登录→看图→决策→切换”的人工链路在时间上根本不成立，DDoS应急响应的重点必须从“更快的人”转向“更早预置的自动触发条件与回退路径”。T+0：先确认是DDoS攻击还是自身故障（1分钟内看完的三个判据）被攻击时，第一反应不是登录后台，而是对照以下三个判据快速判断是否真的遭遇DDoS：判据观察点指向DDoS的典型特征流量与业务背离入向带宽/包速率 vs 业务QPS带宽飙升但QPS平稳或下降连接状态分布半连接数、超时比例、5xx比例半连接激增、大量SYN_RECV、5xx占比升高受影响范围是否单一源站IP或单一域名仅个别IP/域名异常，其它正常这三个判据必须提前做成监控看板与告警项，而不是攻击时临时去查。同时注意区分：网络层DDoS（如SYN Flood、UDP放大）表现为带宽与包速率异常，而应用层CC（HTTP Flood、慢速攻击）常表现为QPS异常但带宽正常——这正是“怎么判断是DDoS攻击还是CC攻击”的直观分野。此外，若攻击源呈现大量分散肉鸡特征，可参考僵尸网络攻击防护调整识别与拦截策略。为什么“人工看图再决策”必须从流程里删掉：攻击时长压缩带来的流程变化前述攻击时长压缩的数据意味着——等运维登录后台再看图，攻击往往已经结束或正在换向量。所以，DDoS应急响应流程中“人工看图再决策”这一步必须删除，取而代之的是：预置自动触发条件（如带宽/包速率/连接数阈值），让清洗或切换动作自动启动；预置回退路径（如自动切换至备用线路或高防IP），无需人工干预即可恢复；把人工角色从“决策者”变为“事后审核者”，只在攻击结束后检查日志与报告。这里的逻辑是：攻击时长被压缩后，人工响应在时间预算上不成立，真正要预置的是“自动触发条件”与“回退路径”，而不是应急电话。T+1：分流与切换的执行顺序（限流降级、接入清洗、DNS切换谁先谁后）确认攻击后，不是立刻改DNS，而是按下面顺序执行，每一步都有前置依赖：步骤动作前置条件说明1限流降级已确认攻击向量先保住核心接口可用性，限流非核心请求，关闭高开销查询2接入清洗/高防已确认攻击方向将流量导向高防CDN或边缘清洗节点，由边缘吸收大流量3DNS切换TTL已调低、健康检查已配置最后才做DNS切换，避免缓存与直连IP导致切换无效为什么“先改DNS”常常无效？因为DNS解析有TTL缓存，客户端和递归服务器可能仍指向原IP，且攻击者若能直连源站IP（通过历史DNS、邮件记录等），改DNS也无济于事。另外，对于DNS Flood、CLDAP放大这类大流量向量，必须在边缘吸收，而不能让源站硬扛。Cloudflare 在其 2026 上半年 DDoS 威胁报告中统计，DNS 基础攻击占网络层攻击流量的 34.3%，CLDAP 放大攻击环比增长 580%（该数据为 Cloudflare 网络侧观测口径，非本站实测）。因此这类向量必须在边缘吸收。在此环节，高防IP和高防CDN区别值得提前了解，以便在切换时选择正确的承接方式。被运营商黑洞期间：能做的事、不能做的事与换IP的取舍黑洞路由的本质是上游为保护共享链路，将攻击目标IP的所有流量全部丢弃。这意味着，在黑洞期间，你的源站对公网不可见，任何访问都会超时，排障手段也基本失效。注意：黑洞解除时长与判定阈值由各运营商/云厂商策略决定，没有统一数字，需向服务方确认，不要轻信网上流传的“24小时自动恢复”等说法。黑洞期间，建议做这几件事：保留证据：立即保存日志、抓包、流量统计，这是事后追溯攻击源与法律取证的依据；准备备用接入：检查备用IP、备用线路或高防资源是否就绪；检查暴露面：排查源站IP是否被泄露（历史DNS记录、邮件头、证书透明日志等）；通知业务方：说明当前状态与预计恢复时间，避免误报。同时，有两件事不建议做：盲目换IP：若攻击针对业务而非特定IP（例如基于域名或业务指纹），换IP后新IP很快会被再次打，且换IP可能导致CDN配置、证书、内外网引用全部失效，回退成本极高；临时加带宽：对超大流量（如T级攻击）加带宽无意义，且成本高昂，不如等待清洗或切换。恢复之后必须做的四件事：暴露面收敛、日志留存、阈值复核、自动触发条件演练攻击结束后，不是万事大吉，必须完成以下四件事，否则下次攻击可能更严重：事项具体动作目的暴露面收敛排查源站IP是否可被直连，检查历史DNS、邮件、证书透明日志、旧子域防止攻击者绕过防护直打源站日志留存按法规与内部合规要求保存日志，记录攻击时间、流量特征、应对动作为取证与复盘提供依据阈值复核检查告警阈值是否覆盖短脉冲攻击（如5分钟内的大流量尖峰）避免下次攻击未被自动触发自动触发条件演练定期模拟攻击，验证自动切换与回退路径是否真的可用确保流程不是纸上谈兵针对“服务器被攻击怎么保留证据”，建议至少保存：抓包文件（pcap）、访问日志（含请求头与来源IP）、流量统计（带宽/包速率/连接数）、系统日志（auth/security）。这些证据应异地备份，且记录时间戳与取证操作人。关于“被攻击后要不要换IP”，结论是：只有在源站IP已经泄露、且攻击明确针对该IP时才考虑更换；其余情况不建议换IP。更稳妥的做法是隐藏源站IP，利用高防CDN或反向代理作为唯一入口。RockCloud 在分流承载与源站保护环节的落位方式在DDoS应急响应流程中，RockCloud 可作为一个可选执行项，在分流承载与源站保护环节发挥作用：高防CDN与边缘清洗节点：承接T+1切换动作，将攻击流量导向边缘清洗，避免源站直接暴露；智能WAF：针对应用层CC攻击，通过业务逻辑分析识别恶意请求，配合清洗节点形成纵深防护；源站保护：通过回源白名单与隐藏源站IP，降低黑洞期被反复定位的风险；Anycast与CN2线路：在回源与访问链路上提供多路径与低延迟保障，减少因单点故障导致的不可用时间。具体接入方式需结合你的业务架构评估，若需了解边缘清洗与源站保护如何适配，可联系 RockCloud 技术支持沟通。值班可打印的DDoS应急响应检查清单将上述流程压缩为一页表，便于值班直接执行：阶段动作完成标记T+0①查看带宽/包速率/QPS背离 ②检查连接状态分布 ③确认受影响范围□T+1①限流降级 ②接入清洗/高防 ③DNS切换（确认TTL/健康检查）□黑洞期①保留日志抓包 ②准备备用接入 ③检查暴露面 ④通知业务方□恢复后①收敛暴露面 ②留存日志 ③复核阈值 ④演练自动触发与回退□提前填好：联系人、账号权限、切换开关位置、回退步骤。这张表应放在工位显眼处，并定期更新。此外，建议定期阅读 DDoS防御 与 网站DDoS防护 相关内容，保持对攻击手法的敏感度。常见问题网站被DDoS攻击了怎么办？首先按时间轴执行：1分钟内确认攻击类型（看流量与业务是否背离），然后限流降级、接入清洗或高防，最后再改DNS。若被黑洞，保留日志并检查暴露面，待恢复后复核阈值。切勿盲目换IP或加带宽。IP被黑洞了多久能恢复？黑洞的触发阈值与解除策略由各运营商/云厂商自行制定，公开渠道没有统一时长，必须以你所用服务方的工单或控制台说明为准。建议预留备用IP或高防资源以缩短不可用时间。怎么判断是DDoS攻击还是CC攻击？看流量与业务指标是否背离：若带宽或包速率暴增但QPS平稳，多为网络层DDoS；若QPS异常高但带宽正常，且请求带有明显业务特征（如大量低频请求），多为应用层CC。再结合连接状态（半连接、5xx比例）可进一步确认。DDoS攻击一般持续多久？据 Radware 2026 Q1数据，超90%的峰值攻击在5分钟内结束，部分低于60秒，表现为短脉冲。但也不排除持续数小时甚至数天的攻击，尤其是针对性攻击。因此，应急响应必须依赖自动触发，而非人工干预。被攻击后要不要换IP？不建议盲换。只有在源站IP已经泄露、且攻击明确针对该IP时才考虑更换，但必须同步更新所有依赖该IP的配置（CDN、邮件、证书等）。更稳妥的做法是隐藏源站IP，利用高防CDN作为唯一入口，降低被再次定位的风险。
高防IP和高防CDN区别在哪？企业接入选型对比
高防IP和高防CDN区别的核心不在“防多少G”，而在流量被接走的协议层：高防IP是四层端口转发，协议无关但不理解业务语义；高防CDN是七层域名接入，自带缓存和WAF但只覆盖HTTP(S)。这一边界在今天比以往更关键——Radware 2026年Q1报告显示，Web应用层DDoS攻击同比激增187.1%，网络层攻击增长168.2%。当攻击增量主要落在应用层时，单看带宽数字已不足以定选型。先分清一件事：高防IP和高防CDN不在同一层很多团队把“高防”当成一个整体，其实两类产品接管流量的位置完全不同。高防IP工作在四层（传输层），通过端口转发把流量引向清洗节点，再回源到你的真实服务器；高防CDN工作在七层（应用层），通过域名解析将流量导向边缘节点，识别HTTP(S)语义后再决定缓存回源还是触发防护。这个区别直接决定了它们各自能防什么、不能防什么，也是判断“高防IP和高防CDN区别”的起点。高防IP怎么工作：四层端口转发、协议无关与计费逻辑高防IP的接入方式是把业务IP换成高防IP，然后按端口配置转发规则。它支持TCP和UDP等任意四层协议，对上层业务无感知，因此不管是HTTP网站、游戏客户端还是自定义二进制协议，都能被接走。就当前主流云厂商的公开产品形态看，常见计费模式是按防御带宽或转发规则数量计费，具体档位以各厂商控制台标价为准。适合流量形态相对稳定、以四层大流量攻击为主的业务。但它的局限也很明显：因为不解析HTTP内容，它无法识别CC攻击中那些看起来像正常用户的请求，也无法缓存静态资源。所以如果业务主要跑在HTTP(S)上，单靠高防IP扛应用层攻击会非常吃力。更细的档位与计费对照可参考高防IP选型。高防CDN怎么工作：七层域名接入、缓存下沉与WAF联动高防CDN通过CNAME把域名解析到边缘节点，流量到达后由节点终结TLS并识别HTTP语义。它能缓存静态资源分摊源站压力，也能与WAF、Bot识别联动，拦截慢速CC和拟真Bot——这正是2026年应用层攻击暴增后企业最需要的能力。具体规则层面的处置思路见应用层攻击防护。但它的覆盖范围仅限于HTTP(S)，非网站业务（如游戏的自有协议、TCP长连接）无法直接套用。这也是“非网站业务能用高防CDN吗”这个问题的答案：不能，除非业务愿意把通信协议改成HTTP(S)。六维度对比表：高防IP和高防CDN区别一览下表把高防IP和高防CDN区别按六个维度一次对齐，便于扫读决策。维度高防IP高防CDN接入方式更换业务IP，按端口配置转发CNAME解析到边缘节点支持协议TCP、UDP及任意四层协议仅HTTP(S)防护层级四层网络层七层应用层（含CC/WAF）缓存加速无，仅转发有，静态资源缓存源站隐藏通过回源白名单+更换IP通过节点代理+回源白名单计费模型按防御带宽或转发规则按流量或请求数，含增值安全需要强调的是，源站隐藏对两类产品都不是自动生效的机制。无论接入高防IP还是高防CDN，你都需要主动更换源站IP、配置回源白名单并关闭公网直连，才能真正收敛暴露面。忽略这一步，即使切换了入口，攻击者仍可能通过旧DNS记录找到源站。计费模型的差异同样影响成本。高防IP按防御带宽计费，在遭遇短脉冲或大流量攻击时，带宽峰值会直接推高成本；高防CDN按流量或请求数计费，静态资源的缓存命中率越高，回源流量越少，单次请求成本越可控。因此，成本评估要结合业务流量结构，而非只看单价。为什么只比“能防多少G”已经不够：2026年选型判据的变化2026年的攻击态势已经变了。NETSCOUT在2026年7月宣布将其全球Arbor Cloud清洗能力倍增至33 Tbps，覆盖16个清洗中心，以应对30+ Tbps级超大容量攻击。这一扩容说明，四层承载能力已被推向全球分布式流量清洗池量级，任何单一机房的高防都难以独立扛住这种规模的流量。与此同时，Radware的2026年Q1报告显示应用层攻击同比大增187.1%，短脉冲、多向量复合攻击成为常态。因此，选型判据应从“防御带宽多少G”转变为“四层承载能力 + 七层语义识别能力”是否都具备。这也意味着，高防IP和高防CDN区别的判断标准，已从单一带宽数字转向四层承载与七层识别的组合。按业务类型给结论：网站与API、游戏、非HTTP自有协议怎么选网站与API：优先高防CDN，叠加WAF和Bot防护，利用缓存降低源站压力。游戏与实时对战：四层高防IP承载UDP和自有协议，登录、充值等HTTP接口可额外接入高防CDN。游戏场景的接入细节可参考游戏DDoS防护。非HTTP自有协议：只能走四层高防IP，无法用高防CDN。游戏服务器选高防IP还是高防CDN，判断依据是协议：核心对战流量走四层，HTTP接口走七层。混合接入：高防IP和高防CDN能同时用吗高防IP和高防CDN能同时用吗？可以，而且推荐。按协议拆分入口：域名类流量走高防CDN，端口类流量走四层高防IP。源站统一只放行回源地址，关闭公网直连，并避免历史解析记录泄露真实IP。这样既吸收了四层的超大容量清洗能力，又补上了七层的语义识别和缓存加速。RockCloud（基石云）正是按这种思路提供分层防护的。接入后源站IP还会暴露吗？会暴露的风险点在于历史DNS记录和主动外连。只要收敛暴露面，配合回源白名单，暴露概率会大幅降低。对于追求高性价比的团队，可以先把静态资源和高频HTTP请求交给高防CDN，把低频四层协议留给高防IP。两类产品哪个更便宜没有通用答案，关键看HTTP(S)流量占比与攻击峰值形态：静态可缓存比例越高，七层入口的单位成本越低。选型自查清单把高防IP和高防CDN区别落到自己的业务上，可以用下面这份清单逐条核对。业务协议构成：是纯HTTP(S)还是包含UDP/自定义协议？是否有大量静态资源可缓存？是否面临慢速CC或拟真Bot风险？源站是否已收敛暴露面（关闭公网直连、清理历史解析）？四层承载能力是否具备T级清洗池支撑？七层语义识别（WAF、Bot管理）是否到位？计费模型是否匹配流量形态？先按上述清单盘点协议构成与源站暴露面，再决定接入形态。如果最终走的是四层与七层拆分入口的组合，RockCloud（基石云）提供高防CDN、DDoS与CC防御、智能WAF、游戏盾与源站保护，可按业务协议分流并统一收敛源站暴露面。常见问题高防IP和高防CDN能同时用吗能。推荐按协议拆分：域名类流量走高防CDN，非HTTP端口走四层高防IP。两者互补，可同时提供四层承载与七层语义识别能力。高防IP和高防CDN哪个便宜取决于业务流量结构。纯HTTP(S)业务用CDN可能更划算（缓存降低回源流量）；非HTTP或大流量四层业务用高防IP通常更直接。建议按流量形态对比计费模型，而不是只看单价。计费维度不同（带宽/规则数 vs 流量/请求数），需按峰值形态而非月均折算。非网站业务能用高防CDN吗不能。高防CDN只支持HTTP(S)协议，非网站业务如自定义TCP/UDP协议无法直接接入，只能使用四层高防IP。高防IP需要改DNS还是改端口高防IP一般不需要改DNS，只需更换业务IP为高防IP，并按端口配置转发规则。域名解析保持不变（除非同时使用CDN）。若原有域名A记录直接指向源站IP，需将解析改指高防IP并同步更换源站IP，否则历史解析记录仍可被用于绕过。若域名同时接CDN，需注意解析记录与转发规则不要指向同一入口造成回环。高防CDN能防CC攻击吗能。高防CDN在七层识别HTTP语义，可联动WAF和Bot管理，检测并拦截慢速CC与拟真Bot。但需注意，高防IP单独无法有效防CC。游戏服务器该选高防IP还是高防CDN游戏核心对战（UDP/自有协议）应选高防IP，登录、充值等HTTP接口可额外接入高防CDN，实现混合防护。高防CDN接入后源站IP还会暴露吗可能暴露，风险点在于历史DNS记录和源站主动外连。通过更换源站IP、仅放行回源白名单、清理历史解析，可显著降低暴露概率。邮件发信、第三方回调、证书透明日志是常见泄露路径。