从 Windows 10 命令提示符到 Mac Big Sur 的 SCP 文件传输看起来没有传输任何内容，但实际上在连接丢失之前传输了 16KB（见下图）。16KB 以下的文件可以正常工作。超过 16KB 的文件（例如这个）总是传输 16384 字节，然后连接丢失。有什么想法吗？
我在 scp 客户端调用中添加了 -vvv。如下所示。（它对我来说似乎没什么用——错误：10054。）我还从 Mac 端捕获了 sshd 调试输出。我把它这里（链接）. 我也不知道该如何理解这一点。
scp -vvv
...
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
debug3: failed to open file:H:/dev/tty error:3
debug1: read_passphrase: can't open /dev/tty: No such file or directory
Password:
debug3: send packet: type 61
debug3: receive packet: type 60
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug3: send packet: type 61
debug3: receive packet: type 52
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 10.240.0.25 ([10.240.0.25]:22).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending command: scp -v -t ~/BrokerTEST.zip
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
Sending file modes: C0666 1599823 Broker.zip
debug2: channel 0: rcvd ext data 31
Sink: C0666 1599823 Broker.zip
debug2: channel 0: written 31 to efd 6
Broker.zip 0% 0 0.0KB/s --:-- ETA
debug3: ERROR:10054, io:0000023350337930
Connection reset by 10.240.0.25 port 22
lost connection
经过进一步测试，我能够使用相同命令成功将同一文件传输到另一台 Mac。因此，我开始怀疑 Mac 端的问题，但是...
经过进一步测试，很可能是 Windows 机器和 Mac 之间的路由问题。给我带来麻烦的 Mac 位于我工作地点的服务器机房中。另一台 Mac 和我的 Windows 机器位于我家中的 Meraki 路由器后面，该路由器为我配置了 VPN 以连接到办公室。我能够成功地将文件从工作地点的另一个 Windows VM 传输到工作地点的 Mac 上。因此，问题似乎不是 Mac，而是我家和工作地点之间的路由问题。
有趣的是，我能够从我们俄亥俄州站点的虚拟机中重现该问题，几乎。唯一的区别是从那里传输（到我威斯康星州办公室的同一台 Mac）并不总是在 16,384 字节处被截断。截断的字节数并不一致。正如我上面所说，每当我从家里的 Windows 机器测试到 Mac 时，传输总是准确地在 16,384 字节处截断，每次，我测试的每个文件都是如此。从俄亥俄州 VM 开始，一次传输在 246KB 处被截断，另一次在 147KB 处被截断，还有一次在 115KB 处被截断。除此之外，我看到了所有相同的症状。我不确定站点之间的 VPN 是如何设置的，但它似乎存在类似的问题。
感谢您提供的任何帮助！
-马特