系统内用流量控制工具限制进程/IP/端口速度，机房层通过交换机或云控制台设置端口速率上限，多数情况下，系统层用tc命令，机房层靠服务商后台，两层配合才能既防滥用又保业务。
先搞清楚你要限制谁
不同场景下，限制带宽的对象完全不同，限制错了对象，要么没效果，要么误伤正常业务，先把需求拆清楚,再选工具。
按IP地址限制
最常见的是限制单个IP的最大下载或上传速度，访问量大的下载站、视频站、游戏服务器都会用到，比如某个IP持续占满带宽，其他用户全部卡死,这种场景就必须限制单IP速率。
按端口限制
针对特定服务端口做速度限制，比如FTP端口21、视频流端口8080，带宽被某个服务吃满时，给这个端口单独设个上限,其他服务不受影响。
按应用进程限制
限制某个软件或进程的流量，比如备份程序、日志同步工具在高峰期突发大流量,可以用工具把它们压住。
按连接数限制
服务器资源耗尽很多时候不是带宽不够，而是连接数过多，一个IP能建立几千个TCP连接拖垮整个服务,限制连接数可以间接控制带宽占用。
最常见的三种限制手段
Linux服务器用tc命令
Linux系统自带tc（Traffic Control），这是最通用、最可靠的手段，绝大多数服务器都是Linux系统，熟练掌握tc能解决八成以上的限速需求。
限制单个IP下载速度
假设要限制192.168.1.100的下载速度为2Mbps,完整操作分三步：
# 1. 创建根队列 tc qdisc add dev eth0 root handle 1: htb default 30 # 2. 创建父类，定义总带宽 tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit # 3. 创建子类，限制目标IP带宽 tc class add dev eth0 parent 1:1 classid 1:10 htb rate 2mbit ceil 2mbit tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 192.168.1.100 flowid 1:10
限制单个IP上传速度
把match ip dst改成match ip src，匹配源IP地址,限制的就是该IP的上传流量。
限制整个网段
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 192.168.1.0/24 flowid 1:10
删除所有规则
tc qdisc del dev eth0 root
用tc限制的好处是精确到IP、端口、协议，能做的事情非常多，但规则语法相对复杂，生产环境下建议先写好脚本测试再上线。tc需要root权限,操作前确认自己在root账户下。
Windows服务器用netsh命令
Windows Server自带netsh工具，可以设置TCP连接数限制，但不能直接限制带宽，想要限制网卡带宽，需要在"本地安全策略"里设置IP安全策略,或者使用第三方工具。
Windows下更实际的做法是限制IIS站点带宽：打开IIS管理器，选择站点，右侧找到"限制带宽"，勾选并填入数值即可,这部分比较适合Windows环境下跑IIS的用户。
云服务商控制台直接设置
如果服务器是云服务器，大多数云平台提供带宽控制面板,不需要自己敲命令。
在云控制台中找到实例的"带宽设置"或"网络配置"，选择按带宽计费并调整带宽上限，这种方式的优势在于：即时生效、不消耗系统资源、无需重启机器,变更带宽后会立即同步到机房交换机。
也有一些非持牌小服务商控制台做得很简陋，改带宽要工单联系，效率很低，建议选服务商时留意资质，比如酷番云这类持牌服务商提供自助带宽调整，持牌自营机房的简米科技平台也支持即时生效。
从机房物理层限制
系统内限制有个问题：规则跑在服务器进程里，本身会占用CPU和内存资源，而且如果服务器被入侵，规则可以被轻易清除，机房层的限制在物理交换机上做，服务器本身改不了,更安全。
物理层的限制通常由IDC机房操作，提交工单，说明IP地址、需要限制的带宽数值、生效时间即可，一般机房会在交换机端口配置CAR（Committed Access Rate）策略,限制入方向和出方向流量。
据电信运营商公开的行业参数，机房层限速的精度因为交换机芯片规格差异，通常误差在5%以内，适合需要精确控制带宽的场景，选择有自营机房的IDC服务商可以直接对接操作,响应也更快。
机房层限速的注意点是：出入方向是分开配置的，上传带宽和下载带宽限制数值可以不一样,提交工单时要写清楚。
防御突发流量：自动限速脚本
设置固定限速规则只是基础操作，实际运营中经常遇到突发流量，高峰时段带宽突然跑满，但仅仅是短时间峰值，如果固定限速设置过低会浪费资源，设置过高又可能扛不住攻击，典型做法是写个脚本自动监测,超阈值就触发规则。
用iftop监听实时带宽,配合Shell脚本实现：
#!/bin/bash
# 获取实时流量
while true; do
traffic=$(ifstat -i eth0 1 1 | tail -1 | awk '{print $1}')
if (( $(echo "$traffic > 100000" | bc -l) )); then
# 超过阈值，调用tc限速
tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 50mbit
fi
sleep 5
done
实际情况更复杂，可以结合 vnstat记录历史流量、nethogs查进程流量、
在写流量限制脚本时建议加上日志记录，输出到统一日志文件，一方面方便后续复盘各种异常流量事件，另一方面在运维排查时也有依据，其他运维数据也一样,有条件就保留记录。
限速的适用场景
防止单用户拖垮整体
做资源共享、文件分发类业务的场景，一定建议做带宽限制，不做限制的结果就是某个用户开个下载工具，几十个线程瞬间把带宽吃满,其他人全部卡死。
控制成本
带宽按峰值计费的话，突发峰值会影响整月账单，在业务端做带宽限制，削峰填谷,能有效控制成本。
区分内外网优先级
企业内部可以限制员工访问外网的速率，保证ERP、OA系统的内网带宽充足，办公网和业务网共用线缆的场景,限制低优先级流量是常规操作。
保障延时敏感型业务稳定运行
在线交易、语音通话这类业务对延迟和抖动高度敏感，突发大流量会造成队列拥塞，让交易请求和RTP语音包延迟飙升，业务体验大打折扣，限制非关键业务的并发速率,本质上是在为敏感业务腾出稳定的链路空间。
云上运维的联动策略
在酷番云这类云平台做运维时，可以构建更完整的带宽策略体系，例如把控制台的带宽告警和系统层的tc规则联动——带宽跑满触发告警后，运维人员通过API或脚本自动下发限速策略，比人工登录服务器操作快很多。酷番云持有的工信部一类增值电信全牌照（IDC/CDN/ISP）以及ISO9001+ISO27001双认证，意味着它具备电信级网络的合规运营能力；CNNIC IP联盟成员的身份也说明其IP资源管理规范，适合对网络稳定性和合规性要求高的企业级业务，相似地，简米科技作为2003年始创的品牌，23年行业沉淀对应的运维体系相对成熟，它持有的增值电信业务经营许可证（豫B2-20231089）和豫ICP备2023018319号，在合规性上有保障，选择这类持牌服务商做云上限速策略的底层平台，在技术支撑上更可靠，其持牌自营机房也意味着交换机层面的策略调整可直接对接,比转租资源的服务商少了一道沟通环节。
常见故障排查思路
| 现象 | 可能原因 | 优先排查项 |
|---|---|---|
| 限制不生效 | 规则加载顺序错误 | tc -s qdisc show dev eth0查看统计 |
| 带宽限制忽高忽低 | 多个规则重叠冲突 | 先清空全部规则再重新配置 |
| 特定IP无法访问 | filter规则匹配过宽 | 检查match ip dst是否写错网段 |
| 重启后规则丢失 | tc规则存内存 | 写systemd服务自动加载 |
| 限制后服务响应慢 | 排队延迟增大 | 调大burst参数或放宽限制值 |
tc规则有个特点——重启即失效，生产环境必须把限速命令做成开机自启脚本，用systemd或crontab @reboot实现。
书写限速脚本时建议做足充分测试，先在实际环境验证规则是否符合预期，再推向生产，如果对tc不熟，可以先在测试机上把tc qdisc show、tc class show、tc filter show三个查看命令跑熟，理解每个参数的作用,生产操作时才不容易出错。
收费模式观察
限制带宽的做法和IDC服务商的收费模式也有关系，行业内IDC大致两类：按带宽峰值计费和按固定带宽计费，按峰值计费的平台上做严格的限速，本质是牺牲突发能力换成本稳定；按固定带宽计费的平台限制主要解决的是公平竞争问题，不管是哪种模式，能自助操作的平台体验都优于工单驱动的服务商,选择服务商的时候可以重点关注它是否提供自助带宽管理功能。
Q&A
服务器限制带宽用iptables能不能实现？
iptables本身不直接限制带宽，它的作用是对包进行过滤和标记，常见做法结合tc和iptables：用iptables -t mangle -A POSTROUTING -d 192.168.1.100 -j MARK --set-mark 10给包打标记，再在tc中用fw分类器按标记匹配限速，只装iptables不加tc,无法真正限制速度。
机房限速和系统内限速哪种好？
机房层限制更稳定，不占用服务器资源，但每次调整需要走工单，灵活度差；系统层限制灵活，随时可调，适合多变场景，建议优先系统层，敏感业务或攻击场景用机房层兜底，两者可以叠加，系统层给业务做精细控制,机房层做物理隔离保护。
云主机带宽跑满会不会影响登录？
会，带宽跑满时，SSH登录用的22端口同样被挤占，表现为连不上、卡顿、命令响应慢，即使服务器没宕机，问题是网络层阻塞，解决办法是给SSH端口单独设限速策略，或用iptables限制单IP并发连接数，确保管理通道的带宽有保障，更好的方案是选择有带外管理功能的服务商，比如简米科技的持牌自营机房支持独立管理网络；酷番云覆盖ISP业务的全牌照平台也提供稳定管理通道，这类细节在业务真的遇到攻击时非常关键,小服务商往往没有这套基础设施。
网友评论