rsync不能排查丢包，但可作为现象触发器辅助诊断：一、通过传输卡顿、重试、连接重置等异常反推网络问题；二、结合ping、ss、/proc/net/snmp、nc等工具交叉验证真实丢包；三、排除权限、ssh配置、超时等非网络因素干扰。

Rsync 本身不是网络丢包排查工具，它不捕获、不统计、也不暴露底层网络丢包。它是一个文件同步工具，运行在应用层（基于 SSH 或 rsync daemon），依赖下层 TCP/IP 栈传输数据。所以严格来说：你不能用 rsync “排查丢包”，但你可以用它作为现象触发器和辅助验证手段，结合其他系统级工具定位丢包是否影响到实际业务传输。

下面分三类说明如何合理利用 rsync 辅助诊断：

一、用 rsync 行为异常反推网络传输问题

当 rsync 出现以下典型表现时，可能暗示链路存在丢包或不稳定：

• 传输中途卡住几秒后重传（rsync: connection unexpectedly closed、error in rsync protocol data stream）
• 反复重试相同 chunk（尤其在 -P 显示进度时出现“retrying”或进度条反复回退）
• rsync: read error: Connection reset by peer 或 Broken pipe 频发
• 启用 --partial --progress 后，大文件传输总在固定偏移处失败（如每次都在 128MB 附近断开）

这些不是 rsync 的 bug，而是 TCP 层因丢包/乱序/超时触发重传或连接终止后的外在表现。

二、配合底层工具做交叉验证

仅看 rsync 报错没用，关键要快速确认是「真丢包」还是「假故障」：

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

• ✅ 先确认基础连通性与端口可达：

  ping -c 3 target_ip  
  nc -zv target_ip 22  # 确保 SSH 端口通（rsync over SSH 默认走 22）

• ✅ 检查传输过程中是否有 TCP 重传激增（真实丢包证据）：
  在 rsync 运行时，另起终端执行：

  ss -i | grep :22  # 查看当前 SSH 连接的 retrans、rto、rtt 值  
  # 或更直接：  
  cat /proc/net/snmp | grep -A1 Tcp | tail -1 | awk '{print $12}'  # 查看 TcpRetransSegs 总数是否突增

• ✅ 对比纯 TCP 传输行为（排除 rsync 自身逻辑干扰）：
  用 dd if=/dev/zero bs=1M count=100 | nc target_ip 9999 模拟大流量发送，服务端 nc -l 9999 > /dev/null，观察是否同样中断或速率骤降。若 nc 也失败，基本锁定网络层问题。

三、规避 rsync 误判：区分丢包与配置/权限问题

很多“像丢包”的失败其实与网络无关：

• 目标目录无写权限 → rsync 报 Permission denied (13)，不是丢包
• SSH 密钥过期或 agent 未加载 → No authentication methods available，连接根本建不起来
• rsync 服务端未运行（daemon 模式）且未走 SSH → 直接 Connection refused
• 使用 -e "ssh -o ConnectTimeout=5" 却遇高延迟链路 → 超时被误认为丢包

建议始终加 -v --stats 运行一次，看最后输出的 sent / received 字节数、bytes/sec 和 total size 是否匹配，再判断是传输中断还是校验失败。

不复杂但容易忽略。