ClientAliveInterval 单独使用无法解决 SFTP 断连，因其不能应对网络丢包或中间设备清空空闲连接；必须配合 ClientAliveCountMax 2，并启用客户端 ServerAliveInterval 才有效。
为什么 ClientAliveInterval 不能单独解决 SFTP 断连问题
单纯增大 ClientAliveInterval（比如设成 600）只让 SSH 服务端更“耐心”，但无法应对底层网络丢包、重传或中间设备（如 NAT 网关、防火墙）主动踢掉空闲连接的问题。很多企业出口网关默认 300 秒清理无数据流的 TCP 连接，此时即使服务端还在发保活包，客户端收不到 ACK，连接仍会卡死或超时断开。
实操建议：
-
ClientAliveInterval必须配合ClientAliveCountMax 2使用，避免单次丢包就断连 - 客户端侧也应启用
ServerAliveInterval（OpenSSH 客户端参数），比服务端保活更可控 - 若用
sftp命令行工具，推荐加-o ServerAliveInterval=30 -o ServerAliveCountMax=3 - 注意：
ClientAliveInterval是服务端配置，写在/etc/ssh/sshd_config，改完需sudo systemctl reload sshd
MTU 过大导致 SFTP 慢或卡顿的真实表现
当路径 MTU 小于本地接口 MTU（如本地设 1500，中间某段只有 1400），TCP 分片失败或 ICMP “Fragmentation Needed” 包被拦截时，SFTP 上传/下载会明显变慢、卡在某个百分比、甚至 hang 住数分钟才报错 Connection timed out 或 Broken pipe。这不是带宽问题，而是 TCP 重传和黑窗口效应造成的。
判断与调整方法：
- 先用
ping -M do -s 1472 example.com测试路径 MTU（1472 + 28 字节 IP/ICMP 头 = 1500）；逐步减小-s值直到不丢包，得到实际 MTU - 若发现路径 MTU ≤ 1400，可在客户端 SSH 配置中限制 TCP MSS：
sudo ip route change default via 192.168.1.1 dev eth0 advmss 1360（根据实测 MTU 减去 40 字节 TCP/IP 头） - 更稳妥方式是改 SSH 的
TCPKeepAlive no+ 启用ServerAliveInterval，避免 KeepAlive 触发路径 MTU 探测失败
Linux 客户端自动适配 MTU 的临时方案
不用改系统路由，也能让单个 SSH 连接绕过 MTU 问题：通过 ProxyCommand 或 StreamLocalBindUnlink yes 不起作用，真正有效的是强制分片控制。
推荐做法：
- 在
~/.ssh/config中为对应主机添加：Host sftp.example.com HostName sftp.example.com ServerAliveInterval 45 ServerAliveCountMax 2 TCPKeepAlive no IPQoS lowdelay - 如果仍卡顿，追加
UseRoaming no（禁用 OpenSSH 5.4+ 的 Roaming 功能，某些代理环境会因此阻塞） - 不要依赖
mtu-disc或net.ipv4.ip_no_pmtu_disc=1全局关闭 PMTU 发现——这会让所有 TCP 连接退化到 536 字节最小 MTU，反而更慢
SFTP 协议层与 SSH 传输层的性能错位
SFTP 是运行在 SSH 之上的子系统，它的“慢”往往不是协议本身问题，而是 SSH 层的加密协商、密钥交换或重传放大了底层网络缺陷。例如，AES-GCM 加密在老 CPU 上吞吐受限，而 ChaCha20-Poly1305 在 ARM 设备上更快；又或者服务器启用了 UsePrivilegeSeparation sandbox，每次 SFTP 文件操作都触发 seccomp 检查，造成延迟毛刺。
排查要点：
- 用
ssh -vvv user@host观察连接阶段耗时，重点看debug1: kex: algorithm:和debug1: Authentication succeeded之间是否超 2 秒 - 服务端检查
sshd -T | grep -E "(KexAlgorithms|Ciphers)"，避免使用diffie-hellman-group1-sha1等已淘汰且慢的算法 - 若用 OpenSSH 8.9+，确认未启用
PermitTunnel yes或AllowAgentForwarding yes——这些会增加每次 SFTP 请求的权限检查开销
