排查部分家用设备与Ubuntu服务器间SFTP/SCP/RSYNC传输速率仅约500KB/s问题的方案咨询

这种时好时坏的传输速率问题确实挺棘手的，结合你描述的场景——直连慢、VPN快，部分家用机正常、部分异常，我建议从以下几个方向逐步排查：

一、先排查SSH协议层的配置问题 #

毕竟SFTP/SCP/RSYNC都是基于SSH的，很多时候速率瓶颈出在SSH的参数或加密算法上：

• 先换不同的SSH加密算法测试，比如在客户端执行：

  scp -c aes128-gcm@openssh.com local_test_file user@your_server_ip:/tmp
  

  多试几种轻量型算法（比如chacha20-poly1305@openssh.com），对比速率变化——有些加密算法对CPU消耗极高，可能在服务器或家用机的硬件上拖慢了传输。
• 检查服务器端的/etc/ssh/sshd_config配置：
  • 看看Compression是不是设为了yes，如果公网本身带宽足够，开启压缩反而会因为CPU消耗拖慢速率，改成no试试；
  • 检查有没有设置TCPWindowSize、MaxStartups这类参数，是否限制了连接的吞吐量；
• 家用机端可以修改~/.ssh/config，添加：

  ServerAliveInterval 30
  TCPKeepAlive yes
  

  防止长时间无数据传输时，被中间防火墙切断连接或降速。

二、底层网络路径的排查（重点，因为VPN连接速率正常） #

既然走VPN能提速，大概率是公网路由路径或NAT转发的问题：

• 对比直连和VPN连接的路由差异：
  用mtr your_server_ip（比traceroute更直观，能看丢包率）分别测试直连和VPN下的路由，看直连路径中有没有丢包率高、延迟波动大的节点；
• 测试纯TCP的带宽，排除SSH的影响：
  两边都安装iperf3，服务器端执行iperf3 -s，家用机执行iperf3 -c your_server_ip -t 60，如果纯TCP速率也只有500KB/s，说明是底层网络的问题；如果iperf3速率能到10MB/s左右，那问题就回到SSH层；
• 检查MTU值是否匹配：
  执行ping -M do -s 1472 your_server_ip，如果ping不通，说明MTU值过大导致分片丢包。可以把家用机和服务器的MTU临时改成1400（比如sudo ip link set dev eth0 mtu 1400），再测试传输速率。

三、服务器端的系统资源与防火墙排查 #

虽然IT说没限速，但还是要确认服务器本身的状态：

• 传输时实时监控服务器资源：
  用htop或top看CPU、内存、磁盘IO的使用率——如果SSH进程占满了CPU核心，说明加密算法太耗资源；如果磁盘IO很高，可能是服务器磁盘读写瓶颈；
• 检查服务器的防火墙与流量控制规则：
  执行iptables -L -v查看有没有针对家用IP段的速率限制规则；用tc qdisc show检查是否有流量控制配置，排除IT可能遗漏的限流规则；
• 查看系统日志：
  检查/var/log/auth.log和/var/log/syslog，看传输过程中有没有SSH连接相关的错误、警告信息，比如连接被频繁重置的记录。

四、家用客户端的环境排查 #

因为部分家用机正常，部分异常，要对比客户端的差异：

• 对比正常与异常家用机的网络环境：比如是不是同一个运营商，有没有开启路由器的QoS限速、端口转发或DMZ模式；
• 换个网络测试：在异常的家用机上切换到手机热点，看速率是否恢复，排除家庭网络本身的问题；
• 换个SSH客户端：比如用FileZilla的SFTP功能代替命令行的scp/rsync，有时候不同客户端的SSH实现细节会影响速率。

五、抓包分析（终极排查手段） #

如果前面的方法都没找到根因，就抓包看TCP交互细节：

• 在服务器端执行：

  sudo tcpdump -i any port 22 -w sftp_slow_capture.pcap
  

  然后家用机发起慢传输，传输一段时间后停止抓包，用Wireshark打开分析，重点看有没有TCP重传、窗口拥塞、MSS不匹配的情况；
• 同时抓一份VPN连接时的包，对比两者的TCP参数（比如窗口大小、MSS、ACK频率），找到差异点，就能定位问题所在。

这些步骤应该能帮你逐步缩小问题范围，找到根因。另外，既然IT团队已经能在家用笔记本上复现问题，让他们配合在服务器端做一些排查，效率会更高。

备注：内容来源于stack exchange，提问作者Jake