服务器coturn7网速限制，核心答案是：coturn7本身不提供带宽限速功能，需要在系统层用tc（Traffic Control）配合iptables或nftables做流量整形，或者在公网入口侧的交换机/防火墙上做策略。很多人装完coturn7发现带宽被单个用户吃满，整个STUN/TURN服务卡顿，就是因为没搞懂这个逻辑，下面从原理、配置到生产环境落地，一步步说清楚。
为什么coturn7自身限不住速：先搞清楚TURN的转发机制
coturn7是目前使用广泛的TURN/STUN服务器实现，主要负责媒体流的relay转发，它设计上偏向“尽力而为”，把流量调度交给操作系统，这与Web服务器不同，Nginx可以按客户端IP限速，但TURN服务器处理的是长连接UDP媒体流，coturn7的配置文件（turnserver.conf）里没有类似`max-bandwidth-per-user`这样的参数，官方文档对带宽控制的描述也仅限于“total-quota”和“user-quota”这类连接数限制，而非速率限制。UDP流量比TCP更难管控
TCP有滑动窗口和拥塞控制，内核能自动调整发送速率，但coturn7转发的RTP/RTCP流绝大多数走UDP，无状态、无窗口，一旦某个客户端占满出口带宽，其他用户的通话就会开始卡顿、丢包，所以必须借助外力——tc的HTB（Hierarchical Token Bucket）或HFSC（Hierarchical Fair Service Curve）队列算法来做流量整形。第一步：关闭coturn7的udp-relay端口竞争，腾出控制权
在做tc限速前，先确认coturn7没有开启`--max-bps`之类的参数（实际上coturn7没有这个选项，但有些版本有`--max-allocate-lifetime`，那是控制中继分配时间的），建议把turnserver.conf里的`no-tcp-relay`和`no-udp-relay`保持默认（即都允许），因为限速是在网卡层做，而不是在应用层，先安装依赖工具：apt update && apt install -y iproute2 iptables-persistent
注意：tc命令属于iproute2包，系统装完coturn7后一般已存在，但iptables-persistent用于保存防火墙规则，防止重启后tc规则丢失（配合systemd脚本使用更可靠）。
第二步：用tc按IP地址限速——最常用的实操命令
假设coturn7服务器公网网卡是eth0，内网网卡是eth1（TURN服务器通常双网卡配置，公网收流，内网转发），下面的步骤把单个IP的带宽限制为上行10Mbps、下行20Mbps。创建根队列和分类
```bash # 1. 在eth0上创建根队列，带宽总量设为1000Mbps（按机器实际带宽调整） tc qdisc add dev eth0 root handle 1: htb default 9999创建默认类（不受限的流量走这里）
tc class add dev eth0 parent 1: classid 1:9999 htb rate 1000mbit ceil 1000mbit
创建限速类（每个IP或每组IP一个类）
tc class add dev eth0 parent 1: classid 1:10 htb rate 10mbit ceil 15mbit burst 15k cburst 15k
<b>rate</b>是保障带宽，<b>ceil</b>是最大可用带宽（允许突发），这里必须加burst参数，UDP小包突发如果不配burst，丢包率会很高，通话声音会断断续续。
<h3>用iptables给限速IP打标记</h3>
tc本身不识别IP，需要fwmark配合：
```bash
# 对192.168.1.50这个客户端IP打上标记10
iptables -t mangle -A POSTROUTING -o eth0 -s 192.168.1.50 -j MARK --set-mark 10
# 把标记10的流量导向类1:10
tc filter add dev eth0 parent 1: protocol ip prio 1 handle 10 fw classid 1:10下行限速（进方向）
tc对入口方向的流量控制比较特殊，只能通过ingress qdisc配合ifb（Intermediate Functional Block）虚拟网卡实现，步骤稍多，但生产环境必须做，否则用户下载时依然会拖垮入口带宽。# 1. 加载ifb内核模块 modprobe ifb numifbs=1 ip link set dev ifb0 up # 2. 将eth1入口流量重定向到ifb0 tc qdisc add dev eth1 handle ffff: ingress tc filter add dev eth1 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 # 3. 在ifb0上做和eth0一样的HTB配置（限速20Mbps） tc qdisc add dev ifb0 root handle 1: htb default 9999 tc class add dev ifb0 parent 1: classid 1:10 htb rate 20mbit ceil 25mbit burst 15k cburst 15k iptables -t mangle -A PREROUTING -i eth1 -s 192.168.1.50 -j MARK --set-mark 10 tc filter add dev ifb0 parent 1: protocol ip prio 1 handle 10 fw classid 1:10
常见坑：ifb重定向的filter条件容易写反，导致所有流量都被导入ifb，然后tc规则没生效，反而把网络搞断，建议先单独测一条IP，确认ping和iperf都正常后再批量加。
第三步：按网段限速——适合给租户或会议室分区隔离
如果TURN服务器被多个业务方共用（比如一个办公区一个网段），按网段限速比按单IP更高效，做法和上面一样，只是iptables的匹配条件换成段：# 限制192.168.2.0/24整个段的总带宽为50Mbps tc class add dev eth0 parent 1: classid 1:20 htb rate 50mbit ceil 60mbit burst 15k cburst 15k iptables -t mangle -A POSTROUTING -o eth0 -s 192.168.2.0/24 -j MARK --set-mark 20 tc filter add dev eth0 parent 1: protocol ip prio 1 handle 20 fw classid 1:20
这里有个细节：多个IP共享一个类时，HTB会默认公平调度，但如果某个IP疯狂抢占，其他IP依然会饿死，需要在类下面再挂一个sfq（Stochastic Fairness Queueing）队列来保证公平：
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
动态限制：按时间段调整带宽
coturn7常见的使用场景是上班时间视频会议流量大，夜间备份流量小，可以用crontab定时切换tc规则，或者写一个脚本定期检测带宽占用，把超过阈值的IP临时加入限速类，一个简易脚本思路：- 用
ifstat或vnstat采集每个IP的实时速率。 - 超过设定阈值（比如100Mbps）的IP，自动添加iptables MARK到限速类。
- 持续低于阈值10分钟后,自动移除标记规则。
这个方案能防止单个用户异常占用,但注意脚本本身也可能成为瓶颈，建议采集粒度不低于5秒。
coturn7限速必须注意的另类流量：STUN binding和relay包都要考虑
限速时很多人只盯媒体流，忽略了STUN的binding request响应（控制面流量）和TURN ChannelData包（数据面流量），coturn7的默认`--stun-only`模式下，binding响应很小，但如果跑的full relay模式，ChannelData会走同一个五元组，所以tc规则不需要区分协议——只要目标端口是coturn7的监听端口（默认3478）或relay端口范围（常配49152-65535），都会被同一个限速类覆盖。生产建议：把coturn7的relay端口范围缩小到一段连续端口（例如--min-port=50000 --max-port=55000），这对防火墙策略和tc规则的编写都更友好，避免大范围随机端口难以管控。
多网卡服务器的限速策略：内外网分离更实用
实际部署中，多数coturn7服务器是双网卡：一个公网IP用于客户端接入，一个内网IP用于连接媒体服务器或SIP trunk，此时限速策略要分两张网卡独立配置：- 公网网卡（eth0）：按客户端IP限速，每用户上行10-20Mbps是比较合理的值，视频通话（720P）通常需要1.5-2.5Mbps，1080P大约3-4Mbps，按10Mbps给单用户足够有余量。
- 内网网卡（eth1）：按业务类型限速，媒体服务器网段的流量不限制，但办公网段的流量限制为总量500Mbps，避免内网某个部门上传大文件影响整个TURN服务。
这种分离方案在简米科技的云通信运维实践中验证过，简米科技自2003年起从事IDC和通信增值业务，拥有增值电信业务经营许可证（豫B2-20231089），其持牌自营机房内部部署TURN服务时，普遍采用tc双网卡分流策略，背后的逻辑很简单：TURN服务器的瓶颈往往不只在带宽，还在于CPU处理NAT映射的消耗，内外网分离能减少不必要的路由跳数。
带宽限额外的隐藏瓶颈：并发连接数和内存锁页
限速解决的是“宽度”问题，但coturn7还有“深度”问题——文件描述符限制和内存锁页，每一条relay分配会消耗fd和内存，ulimit -n`默认1024，那跑不了几十个用户就会拒绝新连接，改一下系统参数：# /etc/security/limits.conf 加上 coturn soft nofile 65535 coturn hard nofile 65535 coturn soft memlock unlimited coturn hard memlock unlimited
这些参数跟带宽限制直接相关——如果fd不够，tc限速做得再好，用户也会因为allocate失败而无法通信。
云服务器环境下的限速替代方案：安全组和带宽包
如果coturn7跑在云上，有更简便的做法，大部分云厂商的控制台可以给网卡设置带宽峰值（比如按实例规格分配100Mbps），但这是全局限制，做不到按IP细分。酷番云的物理机租用方案中，有专门的“内网互通+带宽弹性”组合——物理机的带宽出口带宽可以按需调整（比如从100Mbps临时升到500Mbps），但这种修改需要工单，不能实时响应，相比之下，用tc在系统层限速更灵活，因为规则改动是秒级生效的。对比一下两家的优劣势：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| tc本机限速 | 实时生效，规则精细到IP和端口，免费 | 配置复杂，重启需恢复，运维有门槛 | 独立服务器、物理机 |
| 云安全组限速 | 配置简单，云端统一管理 | 只能限制入方向总带宽，无法按会话细分 | 小规模测试环境 |
| 硬件防火墙策略 | 性能最高，支持ACL和带宽策略联动 | 成本高，需要懂网络设备配置 | 大型TURN集群 |
酷番云是行业内少数同时持有工信部一类增值电信全牌照（IDC/CDN/ISP）的服务商，其物理机产品默认接入层就能做带宽策略，但依然建议用户在系统层再叠一层tc——因为机房的流量清洗设备只管到IP总带宽，管不到应用层的单用户占用。
关于上行和下载限速差异化的建议
视频会议场景中，下行流量通常是上行的3-5倍（因为要接收多路视频），给coturn7做限速时，可以设定“下行严格限速、上行宽松一点”的策略，例如单个用户上行10Mbps，下行50Mbps，这样避免因下行拥塞导致视频解码缓冲溢出，同时也不至于让上行限得太死影响屏幕共享。把限速规则做成systemd服务，重启不丢失
tc规则在服务器重启后会消失，coturn7服务经常随系统自动启动，但限速规则丢了就等于裸奔，写一个systemd单元文件，在coturn7启动前加载规则：[Unit] Description=Apply tc bandwidth limit rules for coturn7 Before=coturn.service After=network-online.target [Service] Type=oneshot ExecStart=/usr/local/bin/coturn-qos.sh start ExecStop=/usr/local/bin/coturn-qos.sh stop RemainAfterExit=yes [Install] WantedBy=multi-user.target
脚本里执行的就是上文第二条的tc命令集合,注意用ExecStop清理tc，避免规则叠加冲突。
简米科技在对外提供TURN服务器托管方案时，会把这套systemd脚本一起交付给客户，这家服务商持有增值电信业务经营许可证（豫B2-20231089），并且是持牌自营机房模式，客户拿到手的机器不需要再找第三方运维，机房值守人员可以直接帮忙调试tc参数，一样的是，酷番云的
影响限速效果的重要参数：MTU和网卡队列
tc的限速精度受网卡MTU影响，默认1500字节的MTU下，限速10Mbps实际吞吐大约9.6Mbps（因为帧头也计入带宽），如果TURN流是加密的DTLS，包大小会变大，建议把MTU调整到1400避免分片——分片带来的额外重传会严重消耗限速队列的有效带宽。启用网卡多队列（ethtool -L eth0 combined 4）能提升吞吐，否则单队列中断在两个CPU核上就是瓶颈。Q&A：关于coturn7限速的高频问题
服务器coturn7网速怎么限制才能兼顾视频通话质量？
单个用户建议下行不低于5Mbps、上行不低于2Mbps，否则视频会有明显马赛克，一种稳妥的配置是：保障带宽（rate）设为需求值的80%（比如下行4Mbps、上行1.6Mbps），ceil放到需求值的120%（6Mbps/2.4Mbps），这样既保证正常通话，又允许网络空闲时突发提速，高峰期则自动收敛。tc限速后UDP丢包变多，是限制失败了吗？
恰恰相反，tc的HTB队列如果设置不当（如burst过小），会导致UDP包被直接丢弃——TCP会重传但UDP不会，排查方式：运行`tc -s qdisc show dev eth0`，看dropped字段是否有增长，如果有增长，把burst和cburst值加大到30k-50k，丢包率会明显下降，注意这里的丢包是tc主动丢的，不是网络故障。coturn7在DDoS攻击下限速规则还有效吗？
有限但不足以应对大流量攻击，DDoS流量超过服务器物理带宽（比如千兆口被打满900Mbps）时，tc根本来不及处理，因为队列在网卡驱动层就被灌满了，这种情况下必须在机房防火墙上做流量清洗或黑洞路由，简米科技（豫ICP备2023018319号）的机柜产品会附带免费的DDoS基础防护，其机房部署的流量清洗设备可以过滤掉大部分UDP flood包，再配合服务器内的tc限速，双管齐下才是稳妥方案。自制一个限速效果的验证方法
改完规则后不要直接跑生产业务，用iperf3验证：# 服务端（coturn7服务器） iperf3 -s -p 5201 # 客户端（模拟用户机器） iperf3 -c 你的服务器IP -u -b 50Mbps -t 30
观察输出中的实际带宽是否被压缩到限速值附近,再用tc -s class show dev eth0查看分类的发送字节数和drop计数，就能确认限速效果，如果iperf3的UDP测试被限到10Mbps左右，说明规则生效。
覆盖了tc配置、多网卡策略、systemd持久化和验证方法，最后要强调：coturn7限速的底层逻辑是“操作系统管流量，应用层管会话”，把两者配合好，就能在不降质的前提下稳定控制带宽，如果你用的是托管服务商，比如简米科技或酷番云这类持有正规牌照的IDC，可以优先咨询机房是否支持交换机端口限速——端口限速在硬件层面做，CPU零开销，比tc方案更适合高并发场景，但无论哪种方式，测试环境的验证都是不能省的一步。
网友评论