RockCloud-基石云安全-官方博客 - 高防CDN
type: channel
link: https://rockcloud.cc/blog/tag/%E9%AB%98%E9%98%B2CDN/
items: 源站IP泄露后的应急处理与修复步骤：5步止血顺序
items: 高防CDN缓存策略优化以降低源站压力怎么做？5步配置
items: WebSocket长连接DDoS攻击防护方案：四道闸配置
items: 无感接入高防CDN配置流程：6步零中断切换
items: 如何防止源站真实IP暴露：5个泄漏点自查与回源收口
items: BGP Anycast技术在DDoS清洗中的应用怎么验证
items: 高防CDN怎么选？签约前自测这6条判据
items: 慢速CC攻击防护怎么做？连接层四步定位与限流
items: DDoS应急响应怎么做？黑洞前后的处置顺序
items: 高防IP和高防CDN区别在哪？企业接入选型对比

源站IP泄露后的应急处理与修复步骤：5步止血顺序
type: item
date: 2026-08-28T10:35:00+08:00
description: 源站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缓存策略优化以降低源站压力怎么做？5步配置
type: item
date: 2026-08-27T02:04:25+08:00
description: 先把第一步做了：把缓存键（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%。这意味着缓存与回源规则…

WebSocket长连接DDoS攻击防护方案：四道闸配置
type: item
date: 2026-08-23T17:16:33+08:00
description: 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 信誉。合法业务可能有突发，需设置豁免通道。副作用与误伤风险：限流阈值过紧会拦截真实业务流，建议先统计正常业务消息分布再设定阈值，保留动态调整接口。第四道闸：空闲超时与心跳回收，超时值…

无感接入高防CDN配置流程：6步零中断切换
type: item
date: 2026-08-22T10:38:15+08:00
description: 无感接入高防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月更新），上表阈…

如何防止源站真实IP暴露：5个泄漏点自查与回源收口
type: item
date: 2026-08-18T10:35:03+08:00
description: 如何防止源站真实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吗？会。若邮件经源站SM…

BGP Anycast技术在DDoS清洗中的应用怎么验证
type: item
date: 2026-08-15T10:32:19+08:00
description: 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）的表现。收敛时间取决于上游策略与传播，未经验证的数字不应采信。如果摘除时出现长时间中断，或连接频繁重置，…

高防CDN怎么选？签约前自测这6条判据
type: item
date: 2026-08-14T10:37:10+08:00
description: 先回答：高防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，对比接入前后的正常请求拦截日志与业务转化数据；测试白名单与紧急放行的…

慢速CC攻击防护怎么做？连接层四步定位与限流
type: item
date: 2026-08-13T12:24:59+08:00
description: 慢速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 能…

DDoS应急响应怎么做？黑洞前后的处置顺序
type: item
date: 2026-08-12T10:32:04+08:00
description: 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、邮件、证书透明日志、旧子域防止攻击者绕过防护直打源站…

高防IP和高防CDN区别在哪？企业接入选型对比
type: item
date: 2026-08-10T18:20:35+08:00
description: 高防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能同时用吗？可以，而且推荐。…