rsync卡在“sending incremental file list”是因TCP连接建立阶段受带宽不足或限速影响，而非文件传输阶段；--bwlimit对此阶段无效，真正影响的是socket缓冲区、RTT及中间设备丢包。
同步带宽不足时，rsync 传输会卡在“sending incremental file list”之后长时间无响应，不是网络断了，也不是权限问题，就是带宽被占满或限速策略生效了。
为什么 rsync 会卡在 sending incremental file list
这个阶段 rsync 正在扫描源端文件元数据并生成差异列表，本身不传文件内容，但需要和远端建立完整 TCP 连接并完成认证、模块协商、路径校验。如果同步链路的可用带宽低于 rsync 默认的 socket 缓冲区预期（尤其在高延迟 + 低带宽组合下），TCP 窗口可能迟迟无法打开，导致握手阻塞。
-
rsync不会主动报“timeout”，也不会提示“bandwidth exhausted”，只表现为静默等待 - 常见于使用
--bwlimit但值设得过低，或中间网关（如防火墙、SD-WAN 设备）对长连接实施了隐式限速 - SSH 层叠加加密开销后，实际吞吐可能比物理带宽低 30%～50%，需按有效带宽估算
rsync --bwlimit 的真实作用范围
--bwlimit 限制的是数据发送速率，但仅作用于「文件内容传输阶段」，对 metadata 扫描、checksum 计算、socket 建立等前置步骤完全无效。也就是说，它压根不影响 “sending incremental file list” 这一行的耗时。
- 设
--bwlimit=100（KB/s）后，仍可能卡在该提示上 —— 因为此时还没开始传数据 - 真正影响该阶段的是 TCP
sendbuf/recvbuf大小、RTT、以及中间设备是否丢包重传 - 若必须限速，建议优先在 SSH 层控制：
rsync -e "ssh -o 'SendBuf=128000'" ...，而非依赖--bwlimit
验证同步链路有效带宽的实操方法
别信测速网站，要测端到端、带加密、带 rsync 协议头的真实通路：
- 用
dd if=/dev/zero bs=1M count=100 | ssh user@host "cat > /dev/null"测纯 SSH 吞吐 - 加
time rsync -n --stats /path/to/small/dir/ user@host:/tmp/（-n表示 dry-run），看 “sent” 和 “received” 行的耗时 —— 这反映 metadata 交换效率 - 抓包确认是否出现大量 TCP Retransmission：运行
tcpdump -i any host target_ip and port 22 -w rsync.pcap，然后复现卡顿，用 Wireshark 查看 retransmit ratio
同步带宽不是标称值，是端到端链路在当前协议栈、加密强度、路由路径下的瞬时有效值。一个被忽略的细节：某些云厂商的 NAT 网关会对单连接限速，且不透传 TCP Window Update，这时调大 ssh -o TCPKeepAlive=yes 反而加重卡顿。
