端口级限速管“准”，全局限速管“稳”，单业务被刷、要保体验，优先端口级；整条链路有被打穿的风险、要保活命，必须全局限速，真实生产环境里，这两件事从来不是二选一，而是分层叠加、互相兜底。
很多运维同学在这件事上纠结，本质是把“限速”当成了一个开关，实际上它更像个水龙头的组合：厨房龙头、卫生间龙头，各自有阀门，总水管上还有一个总闸，攻击来了，你先关哪个,取决于水是从哪儿漫出来的。
端口级限速与全局限速，限的根本不是同一样东西
端口级限速：给每条通道单独装阀门
端口级限速的观测维度是端口号、协议、源IP、连接数这类“细分标签”，你可以让80/443端口单独吃10Mbps，让游戏服的7000到7100端口每个只给2Mbps,让某个API端口每秒最多接受200个新建连接。
它的性格很鲜明：精准、误伤面小、颗粒度细，代价是配置量大，规则要跟着业务变化维护,而且攻击者只要换个端口就能绕开你精心设置的阈值。
在Linux上，这类限速通常靠tc的HTB队列加u32过滤器实现,一条典型的命令长这样：
tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:10 htb rate 10mbit burst 64k tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \ match ip sport 80 0xffff flowid 1:10
这套东西跑起来之后，80端口的出口就被钉死在10Mbps,其他端口不受影响。
全局限速：给整台机器或整条链路设总闸
全局限速看的是总量：网卡总出口带宽、总并发连接数、总PPS，Nginx里的limit_conn、iptables的hashlimit、云厂商控制台上的带宽峰值,都是这个思路。
它的价值在于兜底，不管攻击从哪个端口进来、用什么协议、打多少种花样，总量一到线就刹住，缺点也很直接：刹住的是所有人，正常用户跟着一起变慢,业务体感会明显下降。
端口级限速和全局限速有什么区别
| 对比维度 | 端口级限速 | 全局限速 |
|---|---|---|
| 管控粒度 | 单端口、单协议、单IP | 整机、整链路 |
| 误伤范围 | 小，只影响命中规则的流量 | 大，所有流量一起受限 |
| 配置与维护成本 | 高，规则随业务变动 | 低，一次配好长期有效 |
| 主要防御对象 | CC攻击、单接口刷量、慢速连接 | 大流量DDoS、带宽打满、连接耗尽 |
| 常见落地工具 | tc、iptables按端口规则、应用层限流 | 云带宽峰值、Nginx limit_conn、hashlimit |
| 典型短板 | 换端口即绕过 | 一刀切，正常业务受牵连 |
一张表看下来就很清楚了：一个像狙击枪,一个像防洪闸。
网站被DDoS攻击时该选端口限速还是全局限速
这个问题在应急群里被问得最多，答案取决于攻击长什么样,而不是取决于你手头有什么工具。
三种典型攻击形态的取舍
- 小流量精准CC，只打登录接口或搜索接口。 上端口级甚至URL级限速，全局限速在这里毫无意义，攻击流量可能只占你总带宽的百分之几,但足以把数据库连接池拖死。
- UDP反射、SYN Flood这类大流量洪水。 全局限速只能算第二道防线，真正的解法是在上游做流量清洗，业内专家指出，超过一定量级的流量攻击，单机层面的任何限速都只是延缓崩溃时间,无法真正止损。
- 慢速攻击、连接耗尽型。 这时候要限的不是带宽而是连接数，用
limit_conn按IP或按端口限制并发,属于全局维度的资源配额。
一个可执行的判断顺序
- 先看监控：是带宽曲线顶到天花板，还是CPU/连接数先崩。
- 带宽顶满 → 全局限速 + 上游清洗,同时按端口排查异常源。
- 连接数暴涨但带宽不高 → 端口级连接数限速,配合应用层限流。
- 单接口QPS异常 → 应用层按接口限速,别动全局。
顺序错了，就会出现“全局限速一开，正常用户全掉线，攻击者反而没受影响”的尴尬局面。
业务形态决定优先级，别照抄别人的配置
游戏、直播、大文件下载这类“吃带宽”的业务
带宽就是生命线，端口级限速要做得非常细，比如游戏服按房间端口限速，直播按推流/拉流端口分层限速，全局限速的阈值要留出较大余量,否则一次正常的流量高峰就会触发误杀。
API、支付回调这类“吃连接数”的业务
带宽压力通常不大，怕的是连接被占满，这时候全局连接数配额比带宽限速更关键，端口级则用来隔离核心接口和边缘接口,防止边缘接口的异常拖垮核心链路。
钱和误伤：两个绕不开的变量
服务器限速配置多少钱，成本到底花在哪
纯软件层的限速，也就是tc、Nginx、iptables这些，基本零授权成本，花的其实是人力规则设计、压测验证、后期维护。
真正花钱的是三块：
- 带宽计费方式。 按峰值计费和按95计费，账单能差出一截,限速策略直接影响峰值曲线。
- 高防资源。 高防IP通常按保底带宽加弹性清洗计费，保底买多少,取决于你全局限速的阈值设在哪。
- 硬件或云实例规格。 连接数限得死，小规格机器也能扛；限得松,就得往上加配置。
据主流云厂商公开报价页面，同一区域内百兆独享带宽的月费往往是按量计费在高负载场景下的数倍，所以把限速做在计费之前,本身就是省钱动作。
误杀率怎么压下来
- 白名单先行：办公出口IP、合作方回调IP、监控探针,全部提前放行。
- 阈值分时段：白天和夜间的正常基线完全不同,写死一个数值必然误伤。
- 灰度上线：新规则先在旁路或单台机器上跑,观察一段时间再全量。
- 保留快速回滚通道：一条
tc qdisc del dev eth0 root要能随时执行。
落地实操：从配置到验证
北京高防服务器端口限速怎么配置
机房环境和高防清洗设备联动时,配置顺序有讲究：
- 先在高防控制台确认回源端口和清洗阈值,避免和本机限速互相干扰。
- 本机用tc对业务端口做出口限速，保留管理端口（如22）不限速,防止自己被锁在门外。
- 用
iftop -P或nload观察单端口实际流量,确认限速生效。 - 用
ss -s核对连接数是否落在预期区间。 - 压测验证：用
ab或wrk打目标端口,观察是否在阈值附近被平滑限住。
全局限速在Nginx和iptables上的写法
Nginx侧主要限并发和速率：
limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20; limit_req_zone $binary_remote_addr zone=req:10m rate=10r/s; limit_req zone=req burst=20 nodelay;
iptables侧限制单IP新建连接速率：
iptables -A INPUT -p tcp --dport 80 -m hashlimit \ --hashlimit-above 30/sec --hashlimit-burst 60 \ --hashlimit-mode srcip --hashlimit-name http_limit -j DROP
写完规则记得iptables-save落盘,否则重启就回到解放前。
验证环节别省
限速最怕“以为生效了”，三个必查项：端口实际吞吐是否被压住、正常请求的成功率有没有下降、限速日志里命中的IP是不是集中在少数几个源，行业共识认为,限速策略上线后的头几个小时是最容易出问题的窗口期。
分层组合：一套能跑起来的推荐模型
别追求单一方案打天下,按下面四层从外到内叠起来：
- 上游清洗层：云清洗或高防,负责承接大流量洪水。
- 全局兜底层：网卡出口带宽 + 总连接数配额,保证机器不被彻底打死。
- 端口细限层：核心业务端口单独限速,隔离故障域。
- 应用限流层：按接口、按用户维度限流,保护后端数据库。
四层各管一段，任何一层失控，下一层还能接住，这比单纯争论端口级和全局级谁更好,实用得多。
关于端口级限速与全局限速的常见疑问
Q：只配全局限速，能不能防住某个端口被打？
防不住精准攻击，全局限速是总量控制，攻击者只要把流量控制在阈值以内、集中打一个端口，总闸根本不会动作，但那个端口的业务已经瘫了，反过来，只配端口级限速,遇到分布式大流量攻击同样顶不住。
Q：端口级限速会不会把正常用户也限了？
会，但概率和范围可控，关键在于阈值要基于真实业务基线设定，而不是拍脑袋，用分时段阈值加IP白名单，配合灰度观察,误伤面能压到很低。
Q：云服务器已经买了带宽包，还需要自己做限速吗？
需要，带宽包限制的是链路出口，不限制单端口吞吐、连接数和请求速率，一个被刷的接口照样能把实例的CPU和连接池打满，而带宽曲线看起来还很正常，限速是业务层的事，带宽包是链路层的事,两者不重叠。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787102.html
