1. 先搞清楚高防 IP 到底在防什么1.1 DDoS 攻击为什么是普通 IP 的噩梦先别急着谈高防 IP 和普通 IP 的区别得先把“普通 IP 到底怕什么”讲清楚。很多人以为 DDoS 攻击就是把带宽打满这么简单实际上攻击方式分好几层最常见的是流量型攻击像 UDP Flood、ICMP Flood拿大流量把你的入口带宽直接冲垮其次是连接型攻击典型代表 SYN Flood利用 TCP 三次握手协议的缺陷短时间内发起海量不完整的握手请求把服务器半连接队列占满正常用户就再也连不上还有一种更难缠的应用层攻击比如 HTTP Flood也就是常说的 CC 攻击模拟真实用户请求去刷你的业务接口流量不大却能精准耗尽 CPU 和数据库连接池。普通 IP 在这类攻击面前几乎没有任何还手余地原因不复杂攻击流量最终要流到你的机房和服务器而普通 IP 的防护能力完全取决于本机防火墙和机房带宽上限。一旦攻击流量超过机房出口带宽先扛不住的是机房的路由器交换机然后就会触发上游运营商临时断网业务直接全挂。更难受的是恢复周期不可控攻击往往是一波一波来的每次恢复都要等攻击停止、链路恢复、流量重新调度整个过程折腾下来少则十几分钟多则半天一天。我接过不少客户的电话第一句话就是“服务器 ping 不通了”查到最后都是被流量打进了黑洞状态这种体验做运维的应该都懂。1.2 高防 IP 的“盾牌”到底长什么样高防 IP 并不是一个普通公网 IP它是高防服务商在高防数据中心里分配给用户的一个业务入口 IP。用户把这个 IP 作为对外提供服务的地址服务商在网络骨干层通过 BGP 路由广播把访问流量先引流到高防集群由集群里的清洗设备完成攻击流量识别和过滤再把剩下的干净流量回源到你的真实服务器。这个过程中你的源站 IP 可以部署在任意位置不需要和高防 IP 在同一机房只要网络能通就行。拿生活里的事情打个比方可能更好理解普通 IP 就像一家把门店直接开在马路边的小店什么人都能往里进遇到闹事的直接砸店你自己得扛。高防 IP 则类似一个大型商场门口设有安检闸机所有人流先过安检有问题的拦下来正常的才放进商场而你的店铺开在商场里地址不会直接暴露给顾客顾客只知道商场的大门在哪。高防集群就是那个安检闸机它把脏流量挡在源站之外保证真正到达你服务器的流量都是清洗过的。这里有个需要特别强调的点高防 IP 的防护能力由高防集群承载而不是由你的源站服务器承载。这意味着即便攻击流量达到几百 Gbps源站服务器的带宽和 CPU 也不会受到直接影响因为攻击流量在进入源站之前就被拦在高防节点了。1.3 为什么说“挨打就换 IP”治标不治本我之前遇到不少小团队觉得买高防 IP 是浪费钱服务器被打就换个 IP反正云厂商重新分配一个公网 IP 也就几分钟的事。听起来挺聪明但实际执行起来问题很大。攻击者可以通过很多渠道再次锁定你的新 IP你的域名解析记录里曾经解析到旧 IP攻击者查历史 DNS 记录就能找到你的源站SSL 证书透明度日志会记录证书签发时关联的 IP甚至攻击者用端口扫描工具在整个 IP 段里扫一轮很容易就能发现新开的业务端口。更关键的是频繁更换 IP 对线上业务的影响远不止改一条解析记录那么简单。DNS 缓存刷新需要时间全国各地的用户访问会出现长短不一的中断搜索引擎蜘蛛爬取到新 IP 需要重新建立信任第三方回调、支付接口、推送通道等配置的 IP 白名单全部要改。所以换 IP 只适合临时应急不适合作为长期防御方案。高防 IP 的核心价值并不是“打不垮”而是让源站 IP 长期保持隐藏状态配合回源白名单机制从架构层面把攻击者的攻击路径切断。2. 拆解高防 IP 和普通 IP 的核心区别三个技术维度2.1 引流与清洗流量先过“安检”还是直冲源站第一个维度是流量入口和清洗架构。普通 IP 模式下用户请求直接到达服务器中间没有专门的流量清洗环节。服务器收到的流量是“好”是“坏”全靠本机防火墙和机房安全设备去判断防火墙规则能挡掉一部分明显恶意流量但遇到大流量攻击时防火墙本身也会被流量淹没更别说很多应用层攻击伪装得和正常请求一模一样源站很难在业务层做区分。高防 IP 则完全不一样。用户访问高防 IP 后流量先进入高防集群集群里有一套完整的流量清洗系统这套系统平时就在实时分析所有入向流量。它的工作逻辑大致分四步第一步是流量镜像和采样把经过节点的流量复制一份给检测引擎做实时分析第二步是协议栈校验包括 TCP 握手代理、IP 分片重组、畸形报文识别这一步能过滤掉大量利用协议漏洞的攻击第三步是行为分析统计每个源 IP 的请求频率、会话特征、访问路径识别出异常行为第四步是黑白名单规则命中黑名单的直接丢掉命中白名单的优先放行。这套机制里有一个参数需要特别留意就是清洗阈值。服务商一般会让你设置一个触发清洗的阈值比如正常业务带宽是 50Mbps你可以把清洗阈值设成 200Mbps当流量超过 200Mbps 时自动进入清洗状态。如果阈值设得太低正常业务流量波动都可能触发清洗导致误杀合法用户设得太高呢攻击流量已经打进来了清洗才开始介入体验会受影响。我个人习惯按平时正常峰值的 3 到 5 倍来设置既能快速响应攻击又不会频繁误触发。2.2 链路调度单点扛雷和多点协同的差别第二个维度是网络链路调度能力。普通 IP 的链路结构相对简单通常就是单线或者双线接入机房一旦机房的上行链路出现故障或者某个运营商的互访质量出了问题用户的访问就会明显变差这种问题本地基本无法解决只能等机房和运营商处理。高防 IP 在链路层面完全不同它背后是一组分布在多个机房的高防节点通过 BGP 路由协议对外宣告同一个 IP 段用户的流量会根据网络路由策略自动流入离自己最近或者链路质量最好的节点。这个架构带来了三项普通 IP 不具备的能力。第一项是攻击时的流量分摊当攻击流量过大时可以通过 BGP 路由撤销和通告把流量切换到其他空闲节点让多个清洗节点共同承担攻击压力不会因为某个节点被打爆而导致整个业务瘫痪。第二项是故障自动切换单个高防节点出现硬件故障或网络异常时可以在秒级把流量切换到健康节点用户基本无感知。第三项是就近接入不同地区的用户可以自动访问到地理位置更近的高防节点访问延迟比单纯绕到源站机房更低。不过这里要提醒一句高防 IP 的 SLA 承诺的是“高防服务本身”的可用性不代表你的回源链路一定不会出问题。如果高防节点到源站之间的链路质量不佳或者源站本身带宽不够照样会影响整体访问体验。选型时别只看高防 IP 的防护能力回源链路的稳定性同样重要。2.3 回源机制业务接入方式完全不同第三个维度是回源机制这也是配置上的核心差异。普通 IP 的业务接入方式很简单服务器上起一个服务监听端口域名解析到 IP用户请求到达端口完事。高防 IP 则把这条链路变成了两段第一段是“用户到高防节点”第二段是“高防节点到源站”也就是回源。这一下子就带出了两个需要重点配置的环节。第一个环节是转发规则的配置。如果你的业务是 TCP 或 UDP 协议比如游戏长连接、自定义私有协议需要配置四层端口转发把高防 IP 的某个端口映射到源站 IP 的某个端口。如果业务是 HTTP/HTTPS配置七层反向代理按域名转发到源站可以额外享受 WAF 规则、缓存、回源 HOST 设置等能力。第二个环节是回源白名单配置这个非常关键必须强调再强调。配置完成后要在源站的防火墙或者云安全组里只放行高防节点回源 IP 段的访问其他来源一律拒绝。如果源站端口依然对全网开放攻击者只要想办法扫到源站 IP就可以绕过高防直接打源站高防 IP 等于白买。曾经有客户买了几百 G 防护的高防 IP结果源站被攻击一看原因就是源站 443 端口仍然全网开放攻击者扫到源站 IP 后直接打过去高防 IP 完全没起到作用。回源时还有一个常见问题如果你的业务需要获取客户端真实 IP必须开启 IP 透传。七层转发场景下开启 X-Forwarded-For 头四层转发场景下开启 Proxy Protocol。否则源站日志里看到的全是高防节点的 IP业务侧的封禁、风控、日志分析都会受到影响。2.4 三个维度对比汇总到这里三个核心技术维度的区别就已经很清晰了我把重点整理成一张表方便你保存参考。对比项普通 IP高防 IP流量入口终端用户直连源站高防节点引流清洗后再回源抗 DDoS 能力依赖机房带宽和本机防护通常几十 G 就能打瘫由集群承载单点防护从几十 G 到 T 级链路调度单线/双线为主故障切换能力有限多节点 BGP 调度支持自动切换源站暴露度直接暴露公网可完全隐藏源站配合回源白名单业务接入服务监听端口解析即用需配置转发规则增加回源链路成本模型低包含在服务器带宽费用里较高按保底防护弹性防护计费3. 高防 IP 配置指南从评估到上线的完整流程3.1 配置前先想清楚这几件事开始配置之前先把需求和现状梳理清楚不然容易买错配置或者上线后频繁调整。第一个要确定的是业务类型你的业务是四层 TCP/UDP 为主还是七层 HTTP/HTTPS 为主这决定了配置时选择端口转发还是域名反向代理也影响后续功能选择。第二个要评估的是正常业务带宽和峰值 QPS。这个数值用于设置清洗阈值和选择保底带宽。比如你的业务平时带宽在 20Mbps 左右促销或高峰时能到 50Mbps保底带宽建议至少选 100Mbps不然正常流量波动都可能触发清洗。清洗阈值我建议按正常峰值的 3 到 5 倍设置既能及时识别攻击又不会频繁误伤。第三个要考虑防护峰值。这个数值决定你的抗攻击上限要结合业务被攻击的可能性和攻击规模来评估。常见的计费模式是保底加弹性比如保底 100G、弹性到 300G保底部分按月付费攻击超过保底值时的弹性部分按实际发生量计费。弹性计费单价通常比保底贵不少预算有限的话要好好权衡保底值选多少合适。第四个是源站位置。源站在哪个云厂商、哪个地域高防节点到源站的链路质量如何这些都会影响回源延迟。如果你已经有云主机注意看高防服务商是否支持覆盖你源站所在地域的节点避免出现高防节点在北京、源站在海外的长距离回源这种情况下再强的防护也弥补不了延迟。3.2 接入高防 IP 的六个关键步骤整个接入流程分六步我把每一步的关键操作和注意事项拆开讲。第一步购买高防 IP 实例。购买完成后记录三个关键信息高防 IP 地址、高防节点的回源 IP 段、管理控制台地址。服务商一般会提供一组回源 IP 段这个后面配置白名单要用。第二步配置转发规则。四层场景下设置高防 IP 的监听端口和协议再填写源站 IP 和源站端口开启源 IP 透传。七层场景下添加业务域名回源方式选择源站 IP 或源站域名填写回源端口配置 HTTPS 证书。这里注意如果使用七层转发证书可以放在高防节点上由高防节点负责解密也可以回源到源站由源站处理。建议把证书放在高防节点这样既能隐藏源站证书指纹又能减轻源站加解密压力。第三步配置回源白名单。在源站的云安全组和系统防火墙里只允许高防节点回源 IP 段访问业务端口。以 Linux 系统为例iptables 可以这样写iptables -A INPUT -s 高防回源IP段 -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j DROP这里的核心思路是先允许回源 IP 段访问再拒绝其他所有来源。配置完成后一定要记得从外部网络测试一下业务端口是否已经不通确认白名单真正生效。第四步修改 DNS 解析。把业务域名的 A 记录从源站 IP 改成高防 IP。修改前记得把 TTL 调低比如从默认的 600 秒调到 60 秒这样如果切换后出了问题回滚 DNS 也能在更短的时间内生效。很多人忽略这一步等切换时才发现 TTL 太长DNS 缓存要一两个小时才能全面更新紧急情况下会很被动。第五步流量切换前测试。先用 curl -I 访问域名确认 HTTP 响应头正常再从高防控制台确认能查到访问流量最后回源站查看访问日志确认回源正常。四层端口测试可以用 nc 验证nc -vz 高防IP地址 443如果返回 Connected 说明端口连通性正常。第六步正式切换并持续观察。切换后至少观察 30 分钟到 1 小时重点看源站访问是否正常、高防控制台上是否有异常流量、业务日志里是否有大量连接错误。同时准备好回滚预案一旦发现业务异常立即把 DNS 解析改回源站 IP再排查具体原因。回滚操作最好提前演练一次不要等到出问题时手忙脚乱。3.3 按业务类型给出可抄的配置方案场景一Web 网站七层转发。控制台添加域名 example.com回源方式选择源站 IP 回源回源端口 443回源 HOST 保持和请求域名一致。HTTPS 证书放在高防节点同时开启 WAF 规则和 CC 防护比如设置单 IP 请求频率阈值为每秒 10 次超过直接拦截。Web 站点是最适合用七层高防的业务类型因为不仅能防 DDoS还能顺带解决 CC 攻击和 Web 漏洞利用问题。场景二游戏或 APP 长连接四层转发。配置端口转发规则把高防 IP 的 TCP 端口映射到源站对应端口开启会话保持和源 IP 透传。源 IP 透传在游戏场景里尤其重要游戏后端需要根据玩家真实 IP 做地域匹配、封禁策略和风控判断如果拿到的是高防节点 IP这些功能全都会出错。四层场景还要考虑 UDP 协议防护比如游戏语音或自定义协议走 UDP需要确认高防服务商支持 UDP 清洗。场景三API 服务七层反代。配置域名转发到源站 API 服务开启请求频率限制配合高防 IP 层的 IP 白名单功能。如果调用方有固定的服务端 IP直接配置白名单只允许这些 IP 访问 API如果 API 面向公网开放则依赖频率限制和 WAF 规则。API 服务对延迟敏感要重点关注高防节点到源站的回源延迟测量一下正常情况下的响应时间损耗如果超过 20 到 30 毫秒需要考虑调整节点或者优化回源链路。3.4 配置过程中的高频坑与排查实录我把这些年遇到的高频配置问题整理成了表格现象、原因、排查思路和解决办法都列出来方便你对照处理。现象原因排查思路解决办法业务突然无法访问清洗阈值设置过低正常流量被误判为攻击到高防控制台看是否有“清洗中”状态调高清洗阈值或把正常业务 IP 加入白名单源站日志里全是高防节点 IP没有开启源 IP 透传查看一条真实请求的日志来源 IP七层开启 X-Forwarded-For四层开启 Proxy Protocol高防 IP 没起作用源站被打源站 IP 暴露或没配回源白名单从外网扫描源站业务端口是否开放立刻关闭源站公网访问配置回源 IP 白名单切换后 HTTPS 报错证书没配置或回源协议不一致浏览器查看具体证书错误信息确认证书加载位置保持监听协议和回源协议一致访问延迟明显升高回源线路跨地域或跨运营商从源站 ping 高防节点测试 RTT选择就近高防节点或调整源站地域除表格里的问题外有两条实操心得值得单独说。第一条是上线前最好做一次外部端口扫描把源站除了业务端口以外的所有公网端口都关掉尤其注意 SSH 端口不要对全网开放改成只允许管理 IP 访问或者用密钥登录。第二条是高防 IP 上线初期建议每天看一次高防控制台的攻击记录连续观察一周了解自己业务的实际攻击风险再根据数据调整防护策略而不是凭感觉配置。4. 上线后的效果验证与日常运维4.1 用三种方式验证防护是否真正生效高防 IP 配置完成不代表万事大吉需要验证防护真的生效了。第一种方式是观察源站入向流量。理论上配置完成后源站网卡的入向流量应该明显下降因为攻击流量已经被拦截在高防节点。如果源站入向流量依然经常跑满说明可能有流量绕过高防直连源站或者回源链路出现了拥塞需要立刻排查。第二种方式是看高防控制台的攻击记录。正常情况下控制台会展示每天的清洗流量、攻击次数、被攻击端口和攻击持续时间。建议养成每周看一次攻击报告的习惯了解业务面临的攻击形势。如果发现攻击频率在升高可能需要提前升级防护峰值而不是等到攻击发生时再临时调整。第三种方式是模拟攻击测试。注意这里要特别谨慎测试前先和服务商确认避免对线上业务造成影响测试流量要控制在一个可控范围内不建议直接打大流量。模拟测试的目的是验证清洗策略是否按预期触发、源站是否真的不会受到攻击流量影响而不是测试服务商的上限。我一般建议在低峰期做测试时安排专人在源站盯监控一旦异常马上停止。4.2 监控告警怎么配置才不踩坑高防 IP 上线后监控体系需要覆盖两个层面高防服务本身和源站业务。高防层面要关注节点带宽使用率、保底带宽是否接近上限、清洗事件数量、被攻击端口。源站层面要关注回源健康状态包括 HTTP 状态码成功率、TCP 建连成功率、源站带宽和 CPU 使用率。告警策略建议这样配清洗事件发生立即告警通知运维人员确认是否影响业务保底带宽使用率超过 70% 告警提醒你可能需要升级防护或者检查是否存在异常流量回源健康检查失败立即告警这种情况通常是源站宕机或者网络故障需要快速介入处理。每天定时把攻击报告和高防服务状态发给相关人员形成例行检查机制不要等出问题才打开控制台。这套监控思路尤其适合云主机做源站的场景。云主机的弹性扩容能力虽然强但如果被高防 IP 护住之后源站流量已经相对干净重点监测的就是业务健康本身而不是网络攻击指标。5. 高防 IP 与普通 IP 的选型搭配建议5.1 什么业务必须上高防 IP判断标准其实很简单业务不可用的损失是否远大于高防 IP 的成本。踩在这些场景里的业务建议直接上高防 IP。游戏服务器是最典型的群体玩家对延迟和连接稳定性极度敏感DDoS 一打就掉线掉线就流失付费用户一场攻击造成的损失可能够买好几年高防。电商大促节点也很有必要促销活动往往伴随恶意攻击竞争对手或黑产团伙会利用大促时机发起 DDoS 来扰乱活动。金融支付接口同样要考虑攻击直接影响资金安全和风控合规评估。还有已经有知名度的品牌站和社区站树大招风被攻击的概率和流量价值成正比。5.2 什么场景用普通 IP 就够不是所有业务都需要高防 IP。个人博客、内部系统、学习演示环境这些业务即使被打影响范围也有限用普通 IP 加基础安全组配置就足够了。访问量不大、没有太多公开价值的临时项目也没必要买高防。还有已经用云 WAF 或 CDN 前置防护的 Web 站真实源站 IP 躲在 CDN 后面本身已经有了一层防护普通 IP 作为源站地址一般是够用的前提是你确认源站 IP 没有泄露。这类场景选择普通 IP 加基础防护成本低、管理简单不用为用不上的能力付费。等业务发展起来确实面临真实攻击风险了再迁移到高防 IP 也不迟。5.3 高防 IP 加云主机的典型组网与系统选型最常用的组网方案是高防 IP 前置云主机作为源站。云主机选型时有几个决定体验的细节。公网带宽要留足余量源站出向带宽决定了正常响应的速度和回源效率别在带宽上卡得太死。系统选择上别迷信最新版本选你自己最熟、遇到问题能找到最多社区资料的发行版就好。国内业务一般用 CentOS Stream 或 Rocky Linux、Ubuntu LTS 都很稳妥Debian 资源占用更小选择时注意内核版本对 iptables 和 nftables 的兼容性因为回源白名单经常要写防火墙规则。地域选择要考虑用户分布源站离用户近一点回源延迟就低如果有海外访问需求也可以在海外的云服务商机房部署源站但要先确认高防服务商到源站之间的链路质量测试两地延迟后再做决定。新云主机环境我习惯先做一遍基础加固更新软件源补丁、配置 NTP 时间同步、关闭所有不需要的公网端口、把 SSH 改成密钥登录并限制管理来源 IP、安装入侵防护工具防爆破。高防 IP 挡住大流量攻击云主机本机加固挡住扫描和爆破这两层配合起来才是比较完整的防护体系。最后分享一个经验高防 IP 上线后建议抽时间做一次完整的应急切换演练从 DNS 切换开始模拟攻击、验证清洗、测试回滚全程控制在半小时内完成。做过一次演练之后真正遇到攻击时心里就有底了不会临时到处找控制台按钮。记住高防 IP 不是买完就完事配置规范和应急预案才是决定防护效果的关键。遇到问题时把现象、发生时间、控制台指标、源站日志四样东西同时拿出来排查解决问题的速度会快很多。