How can 10G link be slower to WAN than 1G link, on the same machine?

TLDR: Your 1GbE NIC versus 10GbE NIC over SSH performance difference is due to TCP window scaling issues. At 10GbE with your stated 9ms latency, you need ~11MB of TCP window space, but macOS doesn't scale windows aggressively enough for the SSH client at 10GbE. Either use the 1GbE interface for WAN transfers or try FPsync to parallelize rsync transfers into multiple streams that can collectively utilize your bandwidth.

Do you mind sharing the real-world workload you're modeling here?

SSH single-stream over WAN from macOS isn't typically a performance-optimized setup — if this is for a backup, streaming, or data sync workflow, there might be a better tool available. I'm a former OWC consultant and I work with high performance networking and M&E applications.

I’ve seen oddities firsthand supporting high-performance Mac environments in post-production — including a high profile project using DaVinci Resolve and NVMe-backed storage where the goal was to hit 10+ GB/sec sustained transfers from a Mac Pro to one of our storage arrays. We had 100GbE NICs and NVMe on both ends, but macOS was the bottleneck — we couldn’t break 2.8 GB/sec due to CPU limits and the lack of kernel bypass or proper offload support.

That system used OEM Mellanox cards via ATTO drivers, and at the time, the drivers simply couldn’t handle the workload. I was working for OWC then, and my role was bridging between Apple engineering, ATTO, Mellanox, and applying Linux tuning knowledge to try and get a viable solution — but macOS’s networking stack just wasn’t designed for these kinds of high-throughput, low-latency demands, especially over encrypted or WAN traffic.

Your test case is clean, but I’d encourage you to share more about what you're really trying to achieve. Are you moving media between locations? Trying to build a remote ingest or sync workflow? SSH is a convenient test tool, but rarely optimal for high-speed transfers over WAN, especially from macOS. If you can describe the broader goal, there might be more appropriate tools were built for this type of challenge.

-- Edit #1 --

Thanks for clarifying the use case. Based on everything you shared, the real limitation here isn’t just tuning. A single SSH stream over WAN on macOS can’t efficiently fill the pipe, even at 10GbE. You can tweak TCP buffers and sysctl settings a bit, but the best path forward is to parallelize the transfers.

Parallel streams allow you to better utilize the available bandwidth, even if each individual stream hits platform or network limits.

Download and experiment with FPsync, which will allow you to have more efficient multi-part rsync transfers - https://www.fpart.org/fpsync/

It will use something very close to the rsync syntax and will help you realize more out of this connection (if you must continue using the 10GbE adapter).

-- Edit #2 --

You're experiencing TCP window scaling issues. When you switch from 1GbE to 10GbE, the math changes dramatically for how TCP needs to handle your connection.

The bandwidth-delay product (BDP) is how much data needs to be "in flight" to fully use your connection. Its bandwidth multiplied by round-trip time. At 1GbE speeds with typical WAN latency (like 30ms), your connection needs about 3.75MB of buffer space. macOS handles this just fine, which is why you get your full 56MB/s.

At 10GbE with the same latency, you now need ~37.5MB of buffer space (10x). Based on your tcpdump evidence (smaller packet sizes, SACK packets), macOS isn't scaling up the TCP windows for SSH traffic at 10GbE speeds, even though it does this correctly for other protocols.

FPsync works by splitting the transfer into multiple parallel streams. Each stream requires a smaller TCP window, staying below the threshold where macOS starts to struggle. These streams can utilize your bandwidth efficiently without hitting the TCP window scaling issues that plague a single SSH stream.