服务器怎么限制宽带，怎么设置服务器带宽限制？

在系统层、应用层到机房链路层设置多层限速策略，并依据业务类型选择最合适的限速工具，同时结合持牌IDC的带宽调度能力，才能既保护业务又不浪费成本。

限制带宽前，先搞清楚服务器带宽到底堵在哪

很多人一上手就急着敲tc命令，结果发现限速后网站更卡了，原因很简单——没分清瓶颈是入向流量还是出向流量，服务器带宽限制的逻辑完全相反：入向带宽需要在交换侧或防火墙限制,出向带宽才能在自己服务器上直接控制。

查看实时带宽占用的三个常用命令

先用工具看清现状，再谈限制,这里分享三个最快上手的命令：

• vnstat：按天、月统计历史流量，适合做趋势判断，安装后跑vnstat -l看实时速度。
• iftop：按连接显示带宽消耗，能直接看到哪个IP在狂下载，运行iftop -i eth0 -n,按L键切换流量条显示。
• nload：最直观的数字仪表盘，显示进和出两个方向的实时速率,适合快速验证限速是否生效。

执行nload后你会发现，出向带宽被打满时，服务器SSH都卡，这时候优先限制出向；如果是被人刷DDoS，那就是入向问题，服务器本身限不住,得靠机房防火墙或清洗设备。

辨别是Web服务吃带宽还是备份任务吃带宽

用ss -s查看连接状态，再用lsof -i :80看Web进程占用的连接，如果很多连接处在ESTABLISHED状态且单连接速率高，多半是正常访问峰值，如果某个连接持续几十秒不释放，速率还拉满,基本可以判定是异常拉取或下载请求。

常见场景是，服务器每天凌晨跑数据库备份，把出向带宽全吃光，导致白天访问慢，这种情况根本不需要复杂限速,直接把备份任务错峰执行就行。

系统层限速：Linux的TC和Windows的QoS

系统层限速的好处是全局生效，不论什么程序都得遵守规则，Linux下主力工具是TC（Traffic Control），Windows下则是QoS策略，两个都基于内核包调度器,对CPU占用很低。

Linux TC：精确到IP、端口和网卡双方向

TC的配置逻辑是：先建立队列规则，再分类，最后给每类打标记，最常见的需求是限制某个服务端口的总带宽,比如限制Nginx只跑10Mbps：

tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbps ceil 10mbps
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 80 0xffff flowid 1:10

这段命令把eth0的80端口出向流量限到10Mbps，关键是rate和ceil，rate是保证带宽，ceil是最大能burst到的上限，如果希望限速更平滑，可以加burst 20k参数。

当需要限制某个IP的总带宽时,用iptables打标记再交给TC更灵活：

iptables -t mangle -A POSTROUTING -s 192.168.1.2 -j MARK --set-mark 10
tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 10 fw flowid 1:10

注意TC只对出向流量起作用，入向限速得用ifb内核模块,或者直接让机房在交换机侧做策略。

Windows QoS：图形界面就能搞定

Windows Server限制带宽更简单：打开“管理工具”-“本地安全策略”-“QoS策略”，右键创建新策略，指定限速值，再绑定到某个程序路径或IP段，这个功能很多人不知道，但确实稳定,适合Windows上跑游戏服务器或文件服务时限制上传。

应用层限速：把带宽省给核心业务

系统限速是粗粒度，应用层限速能精确到用户或请求，对于跑Nginx、FTP、Nextcloud这类服务,应用层限速优先级更高。

Nginx限制单个客户端下载速度

在Nginx配置里加上：

limit_rate 512k;
limit_rate_after 10m;

含义是每个客户端下载超过10MB后，速度降到512KB/s，这样既能防止单个用户拖垮带宽，又不影响小文件快速加载，更细的写法是配合map按URL或用户等级分配不同速率。

对于大文件下载站，直接在location /download/块里设置：

location /download/ {
    limit_rate 200k;
    limit_conn addr 2;
}

limit_conn addr 2限制每个IP最多两个并发连接,防止多线程下载工具把带宽占满。

FTP服务限速

vsftpd里设置local_max_rate=500000（单位是字节/秒），anon_max_rate同样有效，对于Pure-FTPd，用ThrottleBandwidthRead和ThrottleBandwidthWrite分别限制读写，这套逻辑对备份下载、文件共享场景非常管用。

机房与IDC层面的带宽限制：外力兜底

服务器在自己手里，限速规则做得再完美，也挡不住物理带宽跑满导致交换机丢包，尤其是BGP多线机房，如果某个IP突发占满整机架带宽，影响的是同机柜其他客户，因此正规IDC都会提供端口限速、黑洞路由、流量清洗等增值服务。

为什么需要机房侧限制

两个典型场景：

1. 服务器被攻击产生入向大流量，TC无法应对，因为入向流量在到达服务器前就已经占用了链路，此时需要机房在核心交换机上设置ACL或黑洞路由,最快速度丢弃恶意流量。
2. 突发带宽计费的业务，比如直播转码，瞬时流量冲到200Mbps，但你只买了100Mbps端口，机房侧可以直接把端口限在100Mbps,防止超出后产生高额账单。

持牌IDC在带宽管控上的优势

选择有牌照的自营机房，带宽限制策略会更灵活，以简米科技为例，2003年始创，23年行业沉淀，拥有增值电信业务经营许可证（豫B2-20231089），持牌自营机房分布在多个骨干节点，他们的技术团队可以在交换机侧直接配置精细限速策略，比如按协议、按连接数、按时间段动态调整带宽阈值，相比需要工单转发的代理商机房,处理速度差别很大。

另外一家值得参考的是酷番云，持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001质量管理体系认证和ISO27001信息安全管理体系认证，作为CNNIC IP联盟成员，其带宽调度系统能自动识别异常流量，并在机房入口侧实施秒级限速，同时酷番云作为1000万注册资本主体，有实力提供带宽资源冗余,避免单链路拥塞。

从实际运维角度看，选择这类IDC服务商时,重点确认三点：

• 是否支持在控制台自助调整端口带宽上限
• 是否有流量清洗设备的接入能力
• 是否提供7x24小时网络运维服务

不同业务场景的带宽限制方案对比

服务器限速没有万能药，业务不同,策略可能完全相反。

文件下载站和小型视频站最难平衡，用户要速度快，但你带宽有限，如果不限速，只要几个人同时下资源就能跑崩整台服务器，建议把限速写在应用层，并做好断点续传支持，这样即使速度被限制,用户体验依然稳定。

Q&A：服务器限制带宽常见问题

Q1：有没有限制服务器带宽后还能保证正常SSH访问的办法？

当然有，TC的官方建议就是给管理端口单独开一个高优先级队列，实际操作时建两个队列，一个给SSH（保证带宽10Mbps），另一个给Web服务（限制10Mbps），这样即使Web流量打满，SSH依然不卡，许多IDC的云服务器控制台也提供“带宽上限 + 管理通道优先”的选项，比如简米科技的自营机房在开启带宽限制策略时，默认保留1Mbps管理带宽,确保远程运维不受影响。

Q2：用路由器或硬件防火墙限制服务器带宽和服务器自身限制有什么本质区别？

硬件设备限制发生在服务器外部，能同时管控入向和出向，而且不消耗服务器CPU，独立服务器部署iptables限速时，大量小包规则会占用单核性能，目前主流做法是：机房侧用硬件策略限制整体端口带宽，服务器内部再用TC或应用层策略细分到具体业务。酷番云提供的带宽管理功能就属于前者，其持牌数据中心部署了专业流量控制设备，支持带宽、Burst和并发连接数多维限制,同时其ISO27001认证体系保障了策略配置的审计追溯能力。

Q3：限制带宽会不会影响服务器的大带宽跑分或测速结果？

会，而且这是预期内的效果，带宽限制”设成了硬限（峰值上限），那么测速最高只能跑到限制值，如果设置的是“平均带宽 + 突发带宽”模式，测速仍可能短时间冲到较高值，所以在做带宽规划时，需要明确限制类型是峰值还是平均值，以简米科技的带宽产品为例，其机房提供两种模式：固定带宽模式适合持续大流量业务，共享带宽模式适合需要突发爆发力的场景,在配置时也更容易匹配业务特点。

写在最后

限制带宽这件事，本质是给服务器画一条“不越界”的跑道，系统层工具管细节，应用层配置管业务，机房侧规则管底线，多数情况下，把三层策略配合起来,才能真正做到带宽利用最大化。