节点搭建成功正常用了一段时间，但是某天发现网络速度突然变慢。这是不少自建节点用户遇见的典型问题。配置没有动过、服务没改过，为何速度就掉下来了？其实使用正常几天后变慢这个现象是一个重要的排查线索——它往往指向某个动态变化因素，而非静态配置错误。

今天这篇文章，就从链路质量、带宽瓶颈、系统配置、服务商策略四个维度，系统梳理一套完整的排查思路与解决方案。

初步判断：先搞清楚“慢”在哪里

遇到速度变慢，第一步不是急着改配置，而是先搞清楚三个问题：

1. 是所有时段都慢，还是只有特定时段慢？

如果白天正常、晚高峰变慢，问题大概率出在国际出口带宽拥堵上——这是普通线路的典型特征。如果全天都慢，则可能是服务器端或本地网络的问题。

2. 是所有设备都慢，还是只有特定设备慢？

手机慢但电脑正常？Wi-Fi慢但有线正常？这指向本地网络环境问题。如果所有设备都慢，问题在服务器或运营商链路。

3. 是下载慢、上传慢，还是两者都慢？

用 speedtest-cli 分别测试下载和上传速度。如果只有下载慢，可能是服务商对入站流量做了限制；如果只有上传慢，可能是本地运营商的上行带宽被限制。

搞清楚这三个问题，排查方向就清晰了一大半。

链路质量排查：MTR 定位“堵点”

MTR（My Traceroute） 是排查网络问题的核心工具，它能逐跳显示数据包从你本地到服务器经过的每一个路由节点，以及每一跳的延迟和丢包率。

在本地终端执行：

# Linux/Mac

mtr -r -c 200 你的服务器IP

# Windows（需安装WinMTR）

winmtr 你的服务器IP

如何解读MTR结果？

- 某一跳高丢包、后续跳恢复正常 → 大概率是中间节点设置了ICMP限速，不是真正的网络问题，可以忽略

- 某一跳高丢包且后续所有跳都持续高丢包 → 真正的网络瓶颈就在这里

- 延迟随跳数异常增加 → 该节点存在网络拥塞或路由问题

对于使用CN2 GIA线路的用户，可以重点关注路由中是否出现 59.43 开头的节点——这是CN2 GIA的标志。如果路由中大量出现 202.97 开头的节点，说明流量走的是普通163骨干网而非CN2 GIA，速度自然上不去。

如果MTR结果显示问题出在国内运营商出口节点，比如电信的某个骨干节点丢包严重，那说明问题不在服务器端，而是运营商层面的国际出口拥堵——这种情况个人用户能做的有限，要么等待拥堵缓解，要么换一条线路质量更好的服务器。

带宽测试：确认“量”够不够

链路没问题但速度还是慢？接下来测带宽。

方法一：speedtest-cli（快速测速）

在服务器上执行：

apt-get install speedtest-cli -y   # Ubuntu/Debian

yum install speedtest-cli -y       # CentOS

speedtest-cli

这会测试服务器到最近Speedtest节点的下载和上传速度。如果测速结果远低于你购买的带宽标称值（比如买了100M只测出20M），说明带宽本身存在瓶颈。

方法二：iperf3（精准测吞吐量）

speedtest-cli测的是“公网到公网”的速度，受中间节点影响较大。要精准测试“你本地到服务器”的真实带宽，需要用iperf3：

在服务器端启动服务：

iperf3 -s

在本地执行客户端测试：

iperf3 -c 服务器IP -p 5201 -P 10 -t 60

如果iperf3测出的带宽远低于标称值，且MTR显示链路正常，那么问题可能出在服务商的带宽超售上——同一物理链路上多个用户共享带宽，高峰期你的可用带宽被压缩了。

系统配置排查：TCP参数与拥塞控制

链路和带宽都没问题，但速度还是上不去？系统层面的TCP参数配置往往是那个被忽略的“隐形杀手”。

1. 检查是否开启了BBR拥塞控制算法

BBR是Google开发的TCP拥塞控制算法，在高延迟、高丢包的跨国网络环境下，能显著提升带宽利用率。

sysctl net.ipv4.tcp_congestion_control

如果输出不是 `bbr`，说明没有开启BBR。开启方法：

modprobe tcp_bbr

echo "tcp_bbr" >> /etc/modules-load.d/modules.conf

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf

echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

sysctl -p

2. 检查TCP缓冲区大小

在跨国高延迟环境下，默认的TCP缓冲区可能太小，限制了单线程的吞吐量。

sysctl net.core.rmem_max

sysctl net.core.wmem_max

如果这两个值低于 `16777216`（16MB），建议调大：

echo 'net.core.rmem_max=33554432' >> /etc/sysctl.conf

echo 'net.core.wmem_max=33554432' >> /etc/sysctl.conf

echo 'net.ipv4.tcp_rmem=4096 87380 33554432' >> /etc/sysctl.conf

echo 'net.ipv4.tcp_wmem=4096 65536 33554432' >> /etc/sysctl.conf

sysctl -p

3. 检查是否有大量TIME_WAIT连接

ss -s

如果TIME_WAIT连接数量异常高（成千上万），可能会耗尽端口资源，影响新建连接的速度。可以通过调整内核参数加快回收：

echo 'net.ipv4.tcp_tw_reuse=1' >> /etc/sysctl.conf

echo 'net.ipv4.tcp_fin_timeout=30' >> /etc/sysctl.conf

sysctl -p

服务器负载排查：是不是“自己人”抢了带宽？

速度变慢不一定都是网络问题——服务器上的其他进程可能正在抢占带宽和CPU资源。

查看实时带宽占用：

iftop -i eth0

这会显示当前哪些IP、哪些端口在消耗带宽。如果发现有异常进程在跑大流量（比如被植入的木马、未授权的下载任务），需要立即处理。

查看系统整体负载：

htop

关注CPU和内存占用率。如果CPU长期100%或内存耗尽，网络处理能力自然会下降。

查看网络接口错误统计：

ip -s link show eth0

如果 `RX errors` 或 `TX errors` 数值较大，说明网卡层面存在丢包或硬件问题。

运营商策略排查：是否被限速了？

有些时候，速度变慢既不是线路问题也不是配置问题，而是运营商对特定IP或特定协议做了限速。

特征判断：

- 更换服务器端口后速度恢复 → 运营商对特定端口做了限速

- 使用UDP协议（如WireGuard）比TCP快很多 → 运营商对TCP做了深度包检测和限速

- 重启服务器或更换IP后速度恢复 → 该IP被运营商标记或限速

应对方法：

- 尝试更换连接端口（如从443换成其他高位端口）

- 尝试更换协议（如从Shadowsocks切换到WebSocket+TLS模式，让流量看起来像普通HTTPS）

- 如果以上方法都无效，联系服务商更换IP

一套完整的排查流程

遇到节点速度变慢，按以下顺序排查，大概率能找到问题所在：

“使用正常几天后变慢”这个现象，80%的情况下指向三类原因：晚高峰国际出口拥堵、服务商带宽超售、或系统TCP参数未优化。前两者需要更换线路或服务商才能根本解决，后者通过调整系统配置就能明显改善。

如果你使用的是华纳云的服务器，华纳云香港和美国节点均采用CN2 GIA精品线路，独享带宽、不限流量，从根源上规避了“晚高峰拥堵”和“带宽超售”这两大类最常见的问题。如果仍然遇到速度问题，华纳云技术支持团队也提供7×24小时的工单与在线服务，帮助用户快速定位并解决。如果你的节点正在变慢，不妨按照上面的步骤逐一排查——大部分问题都能在30分钟内找到答案。