A 1 Gbps link does not guarantee fast SFTP transfer speed. One encrypted SFTP stream can stall on CPU, small-file overhead, MTU issues, or a disk that cannot keep up, while a 4-worker parallel transfer (like openSFTP uses by default) can turn the same line into something much closer to its real capacity.

That matters now because you often pay for bandwidth you never use. Unlike FileZilla or Cyberduck which default to single-stream transfers, openSFTP runs 4 parallel workers out of the box, and the slowdown usually gets blamed on “the network” when the real bottleneck sits elsewhere. This guide shows you how to diagnose slow SFTP transfer speed, pick the right cipher and network settings, and know when parallel workers or server-side tuning will give you the biggest win.

Is the bottleneck really SFTP, or is it everything around it?

Start with latency

A slow SFTP transfer speed often has less to do with the protocol itself and more to do with round trips. Btrade notes that even 80 to 150 ms of latency can crush throughput on long-haul links, and at 150 ms RTT, a 1 Gbps connection needs nearly 19 MB in flight to stay full [1][2]. If your TCP window stays smaller than that, you can fall to 5 to 20 percent of line rate [1].

That is why you should test the link first. If a plain bandwidth test hits expected speeds and packet loss stays low, the circuit is probably fine, and TCP behavior under latency is the real limiter [2].

Check the whole path

SFTP performance also depends on what sits behind the server. If connections fail entirely, start with the connection refused guide instead. Files.com points out that higher latency slows transfers, and the whitepaper it cites treats performance as a mix of file size, file count, latency, and client behavior, not one fixed protocol limit [3][5][6].

In practice, that means you should look at:

  • RTT between client and server
  • TCP window size
  • MTU SFTP path issues, especially fragmentation or black-holed packets
  • CPU load on the SFTP server
  • Disk I/O on the source or destination

A concrete example helps. If your laptop shows 110 MB/s in a local copy but SFTP only manages a fraction of that to a remote host, the bottleneck may be latency or the server disk, not your internet plan. That matters because the next section shows why file shape can change the result even when the network stays the same.

Why does one big file move fast while 10,000 small files crawl?

Per-file overhead adds up

SFTP speed optimization gets messy fast when you stop moving one large file and start moving thousands of tiny ones. Each file needs its own open, metadata checks, directory updates, and close, so the transfer spends more time on control work than on moving bytes.

Files.com notes that SFTP performance depends on file size, file count, latency, and client behavior together, not on file size alone [5][6]. AWS even recommends batching small text files into a TAR archive before upload, which tells you the protocol overhead matters enough to change the workflow [7].

A concrete example makes this obvious. A 2 GB video file can stream continuously once the session starts, while 10,000 200 KB files force the client and server to repeat the same handshake and filesystem work over and over. You do not need a lab benchmark to see why the second case crawls.

Latency hurts more here

Latency punishes small files harder because each file leaves less payload behind each round trip. On a long-haul link, bTrade says even 80 to 150 ms RTT can dramatically reduce throughput, and if the TCP window stays too small, utilization can fall to 5 to 20 percent of a 1 Gbps link [1]. That penalty repeats with every file, so the queue never gets a chance to stay full.

This is why a directory of logs or CSVs often feels painfully slow over SFTP even when a single archive flies. If you can compress or bundle files first, you cut the number of protocol turns and give the connection a bigger payload per transfer [7][8]. Once you understand that shape of the workload, the next question is whether cipher choice can move the needle on its own.

Can cipher choice alone make SFTP noticeably faster?

When cipher cost matters

Cipher choice can matter, but only when encryption becomes the bottleneck. On modern CPUs with hardware acceleration, AES usually wins, and one 2025 comparison says AES-256-GCM can beat ChaCha20-Poly1305 by up to 3x on recent chips [9]. On weaker CPUs, the picture flips, and ChaCha often comes out ahead [11].

You can verify this instead of guessing. Run openssl speed -evp aes-128-gcm, openssl speed -evp aes-256-gcm, and openssl speed -evp chacha20-poly1305 on the server or client you actually use, then compare the results to your real transfer rate [10]. Those microbenchmarks only measure cipher cost, though, not handshake or filesystem overhead [12].

What the benchmark misses

That gap matters. A cipher can look “faster” in isolation and still barely change your slow SFTP transfer speed if the real limit sits in disk I/O, TCP behavior, or the server’s single-threaded SFTP path.

A practical benchmark makes this clear. A single SFTP stream over a 1 Gbps link can look fine for one large archive but collapse on small-file workloads, because file count and round trips dominate. In one older LinkedIn test on weak hardware, [email protected] reached 1.3459 MB/s, slightly ahead of aes128-ctr at 1.20482 MB/s, while aes128-gcm and aes256-gcm landed close behind on that box [13][14].

The lesson is not that one cipher always wins, it is that your CPU and platform decide the answer.

So Yes, Cipher Choice Can Help

So yes, cipher choice can help, but it rarely fixes everything by itself. That is why the next step is checking whether your network settings and server-side limits are the real choke point, and why four workers can sometimes beat one very fast cipher.

What happens when network tuning is not the real problem and why 4 workers can win

When MTU SFTP and TCP window size tuning do not move the needle, you usually face a different limit: one SFTP stream simply cannot keep the pipe full. Files.com notes that many clients send data in 32 KB chunks and that single-threaded transfers are a common bottleneck, so one connection can stall even on a healthy network [15][16].

Scenario Workers Best use case Expected effect
One large archive on a clean LAN 1 Simple uploads, low latency, fast disk Often fine if the server keeps up
Many small files 4 Logs, CSVs, package trees, backups with lots of metadata Better throughput because workers overlap per-file overhead
Remote link with good bandwidth but high RTT 4 Long-haul SFTP where one stream underfills the TCP window Higher link utilization than one stream
Server disk becomes the limit 4 Source or destination SSD/HDD can read and write in parallel Can help until disk I/O saturates
Weak CPU or busy server 1 to 4 Cases where encryption or process scheduling is the choke point May improve less than expected if CPU is already maxed

The pattern is simple. If one worker tops out below what the link can carry, extra workers add more in-flight data, more file operations, and more chances to hide latency. That is why openSFTP’s 4-worker parallel transfer is practical, not just clever, because it lets you push around a single-stream plateau instead of waiting for one connection to do everything.

Parallelism is not magic, though. If the server disk is slow or the CPU is already saturated, four workers can just hit the same wall harder. In that case, you fix storage first, then use parallel transfers to claim the bandwidth you already paid for.

One Stream Is Rarely the Whole Story

A common SFTP bottleneck is not the network link itself but per-connection overhead, and that is the real lesson here. On a 1 Gbps line, one encrypted SFTP stream can underperform badly on many small files, while a 4-worker parallel approach can materially change throughput.

You now have the right way to read the slowdown. Check latency, TCP window size, MTU issues, CPU cost from the cipher, and disk I/O before you blame SFTP itself. If one large file moves well but a folder of tiny files crawls, you are probably fighting file granularity and single-stream overhead, not raw bandwidth.

Your next step is simple: test one large file, then the same dataset as four parallel SFTP transfers, and compare the results with openssh -v plus a cipher benchmark on the server.

Sources

  1. bTrade, "Latency and TCP window limits can reduce SFTP throughput on long-haul links" (2026-04-01) [https://www.btrade.com/blogs/why-sftp-is-slow-and-tcp-tuning-vs-udp-acceleration]
  2. bTrade, "If bandwidth tests are normal, TCP behavior under latency is likely the bottleneck" (2026-04-01) [https://www.btrade.com/blogs/why-sftp-is-slow-and-tcp-tuning-vs-udp-acceleration]
  3. Files.com, "SFTP performance slows as latency increases" (2026-04-01) [https://www.files.com/blog/maximizing-sftp-performance]
  4. Files.com, "Parallel transfers can improve SFTP throughput in FileZilla" (2026-04-01) [https://www.files.com/blog/maximizing-sftp-performance]
  5. CAL, "SFTP vs. FTPS benchmarks varied file size, file count, latency, and client behavior" (2026-04-01) [https://images.g2crowd.com/uploads/attachment/file/1581105/CAL-SFTP-vs-FTPS-Benchmarks---A-Technical-Performance-Comparison.pdf]
  6. CAL, "SFTP vs. FTPS performance depends on multiple interacting factors" (2026-04-01) [https://images.g2crowd.com/uploads/attachment/file/1581105/CAL-SFTP-vs-FTPS-Benchmarks---A-Technical-Performance-Comparison.pdf]
  7. AWS Transfer Family, "Batch small text files into a TAR archive before SFTP transfer" (2026-04-01) [https://repost.aws/knowledge-center/transfer-family-server-performance]
  8. AWS Transfer Family, "Compress files with gzip before uploading over SFTP" (2026-04-01) [https://repost.aws/knowledge-center/transfer-family-server-performance]
  9. Ash's Blog, "AES-256-GCM can outperform ChaCha20-Poly1305 on modern CPUs with hardware acceleration" (2025-11-01) [https://ashvardanian.com/posts/chacha-vs-aes-2025/]
  10. New Softwares, "OpenSSL speed commands for AES-GCM and ChaCha20-Poly1305 benchmarking" (2026-04-01) [https://www.newsoftwares.net/blog/stream-vs-block-where-cha20-poly1305-beats-aes-gcm/]
  11. New Softwares, "AES-GCM tends to lead on AES-NI hardware, while ChaCha often leads on weaker CPUs" (2026-04-01) [https://www.newsoftwares.net/blog/stream-vs-block-where-cha20-poly1305-beats-aes-gcm/]
  12. New Softwares, "Cipher microbenchmarks measure cipher cost only, not handshake or application overhead" (2026-04-01) [https://www.newsoftwares.net/blog/stream-vs-block-where-cha20-poly1305-beats-aes-gcm/]
  13. LinkedIn, "Benchmarking SSH ciphers for transfer speed on an old Buffalo router" (2026-04-01) [https://www.linkedin.com/pulse/bench-marking-ssh-ciphers-transfer-speed-phil-cryer-eakxc]
  14. LinkedIn, "Same benchmark results for aes128-gcm and aes256-gcm on the Buffalo router" (2026-04-01) [https://www.linkedin.com/pulse/bench-marking-ssh-ciphers-transfer-speed-phil-cryer-eakxc]
  15. Files.com, "Many SFTP clients send data in 32 KB chunks" (2026-04-01) [https://www.files.com/blog/maximizing-sftp-performance]
  16. Files.com, "Single-threaded transfers are a major SFTP bottleneck" (2026-04-01) [https://www.files.com/blog/maximizing-sftp-performance]

Frequently Asked Questions

How do I tell if my slow SFTP transfer is caused by the network or the server?

Start by comparing an SFTP transfer with a plain bandwidth or latency test on the same path. If the link looks healthy but SFTP still lags, the likely culprits are CPU, disk I/O, TCP windowing, or file overhead on the server.

Does changing the SFTP cipher usually make a big difference?

Sometimes, but only when encryption is the bottleneck. On modern CPUs AES-based ciphers often perform best, while older or weaker CPUs may benefit more from ChaCha20.

Why are lots of small files much slower than one large file over SFTP?

Each file adds its own open, close, and metadata operations, so the overhead can outweigh the actual data transfer. Bundling small files into an archive or using fewer, larger batches often gives a noticeable speedup.

When should I use parallel SFTP workers instead of one connection?

Use parallel workers when one stream cannot fill the available bandwidth, especially over high-latency links or when transferring many small files. If the server disk or CPU is already saturated, parallelism may help less than expected.

What is the first practical step for SFTP speed optimization?

Test one large file, then test the same data with multiple workers and a cipher benchmark on the client or server. That quickly shows whether your main limit is latency, cipher cost, or storage performance.