服务器带宽跑满但用户下载慢，问题几乎不在“带宽不够”，而在单连接限速、链路丢包或回源路径上。换句话说，你的服务器出流量明明很大，但这部分流量和你用户感知到的速度之间，隔着一层又一层容易忽略的瓶颈，下面这份排查顺序,是我在实际维护下载站时反复验证过的路径。
服务器带宽跑满但下载速度上不去：先定义“跑满”是谁说的
很多人一看到后台流量图跑到带宽上限，就认定服务器没问题，但“跑满”这个词在下载站场景里,其实很模糊。
首先你要搞清楚是哪条链路跑满了，服务器出方向跑满，和CDN节点到用户之间跑满，是两回事，如果你套了CDN，用户从CDN节点取文件，你的源站带宽即使跑满，用户也感受不到除非CDN回源成了瓶颈。
其次要看清是什么流量跑满了，正常下载流量之外，盗链、爬虫、CC攻击、甚至你自己的备份任务,都可能把出带宽吃光。
用三个命令确认流量组成
确认的第一步,直接在服务器上观察实时流量和连接状态：
iftop -i eth0：按连接排序，看哪些IP在吃流量,是不是单个IP占掉了大部分出口。nload：看总入站和出站的实时曲线，确认“跑满”是持续的还是瞬时尖峰。ss -s和ss -sp：看当前连接数和协议栈状态，如果TCP的重传队列长期堆积,说明链路质量有问题。
如果iftop显示大部分流量都被少数几个IP占走，先别急着怪带宽，那是盗链或攻击问题，如果流量分布很散，每个用户分到的带宽都很有限,那才是链路或限速问题。
下载站带宽跑满但用户慢的排查顺序：从网卡到客户端逐层拆
行业共识认为，下载站这类纯静态资源场景，链路质量对用户体验的影响远大于带宽数值，慢和满的矛盾，几乎总能落到某一层限制上，排查顺序建议从服务器网络栈出发,一层层往外走。
第一层：测单线程和多线程，锁定单连接限制
这是整个排查里最快的一步，能直接区分“服务器限速”和“链路瓶颈”。
在服务器本机下载一个测试文件：
curl -o /dev/null http://127.0.0.1/test.bin
wget -O /dev/null http://127.0.0.1/test.bin如果本机单线程也快不起来，那问题出在服务器自身：磁盘、web服务配置或防火墙，如果本机单线程很快,再用外网机器测试：
- 单线程下载测试：
curl -o /dev/null http://你的域名/test.bin - 多线程下载测试：
aria2c -x 8 -s 8 http://你的域名/test.bin
对比一下结果：
- 单线程很慢，多线程能跑满：说明单连接被限制，要么是web服务端限速,要么是TCP窗口或丢包在作祟。
- 单线程和多线程都慢：说明瓶颈在链路的更上游,比如跨运营商互联或CDN节点质量。
- 单线程本地快、外网慢：重点检查防火墙、流量整形设备、以及机房出口的QoS策略。
第二层：查web服务配置里的隐形限速
很多下载站用的是nginx，nginx默认不限制下载速度，但不少控制面板、宝塔或安全软件会在全局配置里塞入limit_rate或limit_rate_after。
打开nginx.conf和所有include进来的配置：
grep -rn "limit_rate" /usr/local/nginx/conf/找到类似这样的配置就说明有限速：
limit_rate 512k;
limit_rate_after 10m;前者把下载速度锁死在512KB/s，后者表示前10MB不限速，之后开始限速，这也是为什么很多用户说“下载前几秒很快，后面突然掉速”就是limit_rate_after在起作用。
如果是apache，麻烦一点，它允许在.htaccess里做XSendFile相关的限速,也得一并检查。
第三层：看磁盘IO和文件读取路径
磁盘读取速度常常被忽略，机械硬盘在面对大量并发下载时，磁头寻道会拖慢整体读取效率，单个文件的顺序读没问题，但如果下载请求的偏移量各不相同（比如断点续传和浏览器多线程请求）,磁盘就要频繁随机读。
在服务器上跑一下：
iostat -x 1看%util和rMB/s，如果%util持续接近100%，磁盘就是瓶颈，解决办法是换成SSD或给文件加OS缓存，如果文件存放在NFS、NAS挂载卷或者远程存储上,回源读取的延迟也会直接算进下载用时里。
第四层：用mtr沿链路找丢包和延迟
丢包是下载慢的隐藏大杀器，TCP对付丢包的方式很粗暴：缩小拥塞窗口，重传数据，丢包率只需要到达一定比例，下载速度就会断崖式下跌,而这跟带宽大小无关。
用mtr查用户到服务器之间的每一跳：
mtr -rwz -c 100 你的服务器IP观察每一跳的Loss%列，如果中间某两个节点丢包在5%以上，或者延迟突然升高到300ms以上，那这段链路就是拖后腿的位置，多数情况下，这种问题出在跨运营商接口或高峰期拥堵的国际出口上，你在服务器端无法彻底解决,只能考虑换BGP线路或上CDN做节点调度。
大带宽下载站用户下载速度慢的几个隐藏原因
排查顺序走完，通常情况下能找到问题，但有几类情况比较隐蔽,容易迂回浪费时间。
盗链和爬虫吃掉了大部分出口带宽
下载站的前端页面、资源直链一旦被大量外部站点盗链，服务器会迎来海量无收益请求，这些流量同样计入出带宽，但用户完全感知不到这部分“满”。
业内专家指出，相当一部分下载站出现带宽跑满但用户慢的情况，都是盗链或搜索引擎爬虫高频抓取导致的,处理方法很直接：
- 在nginx里判断
Referer,对非白名单来源返回403。 - 日志里按
$http_user_agent统计请求量,过滤异常UA。 - 对单个IP做连接数限制：
limit_conn_zone和limit_req_zone都能建立基础防线。
TCP协议栈参数和默认窗口限制
如果带宽是1000Mbps，但单线程下载只有2MB/s，通常是TCP窗口和RTT乘积的问题，服务器默认的tcp_rmem和tcp_wmem可能在低延迟环境下够用，一旦用户和服务器之间延迟较高,窗口很快就封顶了。
检查内核参数：
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem典型输出是：
net.ipv4.tcp_rmem = 4096 87380 6291456
如果第三列只有几MB，单个连接的吞吐上限就不高，尤其在跨地域下载时表现更明显,适当调大：
sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'
sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'但要注意，窗口调大只能治标，丢包率一旦超过一定阈值，调什么参数都拉不回来,唯一的出路是降低链路丢包。
CDN场景下的回源带宽短板
你看到的“大带宽跑满”可能是CDN节点到用户这一段跑满了，你自己的源站其实很空闲，反过来也一样：源站出带宽被打满，但CDN节点的下载速度取决于节点到用户之间的质量,和源站带宽关系不大。
如果用了CDN，重点查回源监控，很多CDN控制台的回源带宽和命中率两个指标放在一起看，命中率低意味着每次请求都穿透到源站，回源带宽一旦打满,所有节点的下载速度都会受影响。
下载站带宽跑满但用户慢的Q&A
下载站带宽跑满但用户下载慢，第一件事该做什么？
先做多线程对比测试：curl单线程和aria2c -x 8多线程各跑一次，如果多线程明显更快，优先检查nginx的limit_rate配置和TCP窗口参数；如果多线程依然慢，用mtr查链路丢包,重点看跨网络节点。
服务器带宽跑满下载速度上不去，是不是必须换更大带宽？
不一定是，带宽跑满意味着服务器侧的出口容量已被完全占用，此时加大带宽能缓解总容量问题，但如果瓶颈是单连接限速、磁盘IO或链路丢包，换更大的带宽反而会让异常流量占掉的份额更多，正常用户的速度依然提不起来，先排查限速和丢包,再决定是否扩容。
单线程快但几十个并发用户一起慢，重点查哪些指标？
重点看三个地方：磁盘IO的iostat %util、nginx的错误日志里有没有大量upstream timed out、以及连接数是否打满了worker_connections，多数情况下，并发慢是连接数上限或磁盘随机读能力不足导致的，而非出口带宽不够，顺带检查一下sysctl net.core.somaxconn和nginx的accept_mutex配置,避免高并发下连接排队。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/665234.html
