How to Speed Up SFTP Over Long Distance
Tune SFTP request depth and buffers, test compression carefully, and fix storage or network limits that slow secure file transfers over distance.
If SFTP is fast within the office but slow to a remote server, start with one large file while watching CPU, disk, and network use on both sides. An idle link with idle disks suggests a different problem from a transfer that saturates an encryption core or destination drive.
This guide uses OpenSSH to show how request depth, transfer buffers, compression, and session reuse affect long-distance transfers. Change one setting at a time and compare total completion time. Other clients may expose equivalent controls under different names.
What SFTP is—and what it is not
SFTP is a file-transfer program that performs its operations over an encrypted SSH transport. OpenSSH documents public-key authentication, compression, recursive copy, resume, request depth, and transfer-buffer controls in the official sftp manual.
SFTP is not “secure FTP.” Classic FTP uses a control connection plus a separate data connection for file data. RFC 959 documents that architecture and the connection-management problem created when stream mode closes the data connection at end of file. SFTP instead uses SSH’s encrypted connection and channel flow control. RFC 4254 defines SSH channel windows and maximum packet sizes that govern how much channel data can move before the sender must wait for an adjustment.
That distinction matters: FTP and SFTP can both slow down over distance, but the settings and failure modes are different.
The five limits to measure before tuning
| Limit | What to record | Typical signal |
|---|---|---|
| Network path | RTT, packet loss, jitter, available bandwidth | Rate changes by route or time of day |
| SFTP request pipeline | Outstanding requests and buffer size | Link is underused while CPU and disks are idle |
| Encryption CPU | Client and server CPU during transfer | One core is saturated before the link is full |
| Storage | Source read and destination write rate, IOPS | Large files work but small-file creation stalls |
| Server policy | Bandwidth, session, request, or storage quotas | Client tuning stops changing the result |
Run one large-file test and one representative folder test. A single large file isolates the streaming path; a folder exposes metadata, directory traversal, create/open/close work, and per-file coordination. See why thousands of small files transfer slowly for the file-count model.
If the current job uses rsync over SSH rather than an interactive SFTP client, use the separate rsync over WAN tuning guide; rsync’s file list, quick check, and delta-transfer decisions require a different diagnostic sequence.
1. Increase outstanding requests carefully
OpenSSH sftp allows -R num_requests or -X nrequests=value to control concurrent read or write requests. Its documented default is 64 outstanding requests, and the manual notes that increasing the value may improve transfer speed while increasing memory use.
Test a small progression rather than jumping to an extreme:
sftp -R 64 user@example.com
sftp -R 128 user@example.com
sftp -R 256 user@example.comUse the same file, route, client, and server for every run. Stop increasing the value when throughput flattens, memory grows unacceptably, or the server becomes less stable. More requests do not create bandwidth; they only reduce waiting when request latency is the limiting factor.
2. Test a larger transfer buffer
OpenSSH documents a default SFTP buffer of 32 KB. The -B buffer_size option or -X buffer=value changes the maximum buffer used for a read or write operation. Larger buffers mean fewer round trips for the same payload, at the cost of additional memory.
For example:
sftp -B 65536 user@example.com
sftp -B 131072 user@example.comDo not present one buffer as universally optimal. Client version, server limits, SSH channel windows, memory, and path behavior all affect the outcome. Combine a buffer change with the default request count first; then test request depth separately so the result is attributable.
3. Treat compression as a workload test
OpenSSH enables SFTP compression with -C, which passes SSH’s compression setting through to the session. The OpenSSH client configuration manual says compression is off by default and applies to all traffic over the SSH connection.
Compression may help logs, source code, CSV, or uncompressed text when bandwidth is scarce and CPU is available. It usually provides little benefit for already-compressed JPEG, MP4, ZIP, and similar data, while still consuming CPU. Test both modes:
sftp user@example.com
sftp -C user@example.comKeep compression off if it lowers throughput or raises CPU without reducing the bytes sent enough to matter.
4. Reuse sessions and batch related work
Repeated authentication and session setup add fixed cost. For scheduled jobs, OpenSSH supports -b batchfile so a series of SFTP commands can run in one non-interactive session with suitable non-interactive authentication.
For a directory with many small files, the remaining filesystem and per-file work can still dominate even inside one session. Creating an archive can convert the folder into a continuous stream, but it also adds archive creation, temporary storage, extraction, and archive-level resume. For recurring workflows, compare that manual process with a transfer engine that packs small files while preserving file boundaries.
5. Check CPU, storage, and server limits
If request and buffer changes do not help, the bottleneck may not be SFTP’s request pipeline.
- CPU: Encryption and integrity processing happen at both ends. Record per-core utilization, not only total CPU.
- Storage: Small-file creation can exhaust destination IOPS while network utilization stays low.
- Network loss: Both SSH and SFTP normally ride on TCP, so loss and retransmission can reduce the sending rate.
- Rate limits: Confirm the SFTP server, account, gateway, and upstream link do not impose a cap.
- Extra hops: A jump host adds another path and another system that can become the limit.
Do not weaken host-key verification, choose obsolete cryptography, or disable integrity controls to chase a benchmark number. Performance tuning should preserve the security property that made SFTP the right choice.
A repeatable SFTP benchmark plan
- Prepare one large file and one real folder with the same files used in every run.
- Record client and server versions, hardware, storage, route, RTT, loss, and current SFTP options.
- Measure end-to-end wall time, not only a peak progress-bar rate.
- Run the default configuration at least three times and use the median.
- Change request depth, retest, and restore the best stable value.
- Change buffer size, retest, and restore the best stable value.
- Test compression on and off with the actual file types.
- Interrupt a non-production transfer and verify resume behavior and final integrity.
For the payload-time lower bound, use the 1TB transfer-time calculator. For route design and protocol selection, read the high-speed long-distance file transfer guide.
When SFTP tuning is enough—and when to compare alternatives
Keep SFTP when it meets the required completion time, integrates with existing automation, and fits the security and access model. It remains a widely available, scriptable choice.
Compare the current releases using the same files, route, storage, and security settings. Record transfer-phase throughput separately from the time until the recipient has a verified copy. The WarpSend vs FTP benchmark method explains how to run that comparison; an FTP result does not establish performance against SFTP or Aspera.
WarpSend does not replace an SFTP server requirement or implement SFTP. It is an alternative workflow for teams that can install supported endpoints and want direct transfer, browser share links, or managed folder sync. Review WarpDirect, then start a free WarpSend transfer with the same representative file set you used for the SFTP baseline.
Frequently asked questions
Why is SFTP slow over a long-distance connection?
SFTP can be limited by round-trip latency, packet loss, conservative request and buffer settings, SSH encryption CPU cost, and source or destination storage. A fast access link does not remove those limits. Measure the same file set while recording RTT, loss, CPU, storage throughput, and end-to-end completion time.
Which OpenSSH SFTP settings can improve transfer speed?
OpenSSH exposes the number of outstanding requests with -R or -X nrequests and the per-request buffer with -B or -X buffer. Larger values can reduce waiting on a high-latency path, but use more memory and may not help when CPU, storage, loss, or a server-side limit is the bottleneck. Change one setting at a time and retest.
Should I enable SFTP compression?
Test it rather than assuming. Compression can help compressible text on a bandwidth-limited route, but it adds CPU work and usually offers little for JPEG, MP4, ZIP, and other already-compressed formats. OpenSSH leaves compression off by default.
Is SFTP the same as FTPS?
No. SFTP performs file operations over an encrypted SSH transport. FTPS is FTP protected with TLS and retains FTP’s control and data-connection architecture. Clients, ports, authentication, firewall behavior, and performance tuning differ.