An SFTP connection timeout is rarely “the server being down.” More often, you are hitting one of six concrete failures, DNS resolution, a bad route, packet loss on the path to port 22, firewall DROP behavior, NAT timeout on an idle session, or a proxy or jump host that cuts the connection off.
That matters because a timeout wastes time, hides the real fault, and sends you tuning SSH settings when the problem sits in the network. In the next sections, you will use ping, traceroute, dig or nslookup, ssh -vvv, and keepalive tests to identify the exact cause and fix it fast.
Why does SFTP time out when the first connection sometimes works?
Treat it like a tree
When an SFTP connection timeout appears only sometimes, do not assume one flaky server. The pattern usually means your path to the server changes, or one layer in the chain drops traffic after the first try.
Start with the simplest split. If you cannot ping the host, OneUptime’s SSH timeout flowchart says to check network connectivity, routing, and DNS first [1]. If ping works but port 22 does not, the problem usually moves to the firewall or security group [1][4].
Why the first try fools you
A first connection can succeed because DNS returns a reachable address, the route is clean, or the firewall allows the initial handshake. The next attempt can fail if the path changes, a proxy resets, or the session sat idle long enough for state to expire.
That is why “it worked once” is weak evidence. You need to test the full chain, not the last error message.
Start with the server name
If you connect by hostname, resolve it yourself first:
dig your-hostnamenslookup your-hostnamessh -vvv user@your-hostname
If DNS points to the wrong IP, SFTP will appear random even though the server itself is fine. A Microsoft Fabric note also reminds you to verify the target port, since SFTP uses port 22 by default [2]. A client like openSFTP surfaces timeout diagnostics clearly, so you can separate client from server issues faster.
Check the path to port 22
If name resolution looks right, test reachability to the SSH service directly. Use traceroute or tracert to see where the path stalls, and then try ssh -vvv user@host to learn whether the hang happens before authentication or after the TCP connection starts.
For example, if ping succeeds but ssh -vvv stops at “Connecting to host port 22,” you are looking at routing, filtering, or a blocked port, not an SFTP credential problem. If the TCP handshake completes but the server identity fails, that points to a host key verification issue instead. If the TCP handshake completes and then the session freezes, you move closer to firewall behavior or idle-session handling. If the session connects but files fail, check permission denied causes.
A quick diagnostic order
- Resolve the name with
digornslookup. - Ping the host.
- Run
tracerouteto the SFTP server. - Test port 22 with
ssh -vvv. - Confirm the SSH service and firewall rules on the server side [1][4].
That sequence gives you evidence instead of guesses, and it leads directly to the next question, whether the network is dropping packets or rejecting them outright.
Is it DNS, routing, or the path to port 22 that is failing?
Before you touch SSH settings, prove that your client can find the host and reach it. OneUptime’s SSH timeout flowchart starts exactly there, if ping fails, check DNS and routing, and if ping works but port 22 does not, move to firewall and service checks [1].
| Check | What it tests | Likely result if failing | Typical next step |
|---|---|---|---|
dig hostname or nslookup hostname |
DNS resolution | Wrong IP, no answer, or multiple changing addresses | Fix the record, confirm the right FQDN, flush stale client DNS |
ping host |
Basic IP reachability | No replies or high loss | Check routing, host availability, or upstream filtering |
traceroute host or mtr host |
Where the path stops | Packets die before the destination network | Compare from another network, then inspect the broken hop |
ssh -vvv user@host |
TCP connect and SSH handshake to port 22 | Hangs at Connecting to ... port 22 or times out |
Test firewall rules, security groups, and the SSH port |
| Connect from a different network | Whether the path itself is the problem | One network works, another times out | Focus on ISP, VPN, proxy, or corporate filtering |
If DNS returns the wrong address, you can chase the server all day and never hit the real endpoint. If ping works but ssh -vvv stalls on port 22, the name is fine and the path to TCP 22 is not.
A concrete example helps. If ping sftp.example.com succeeds from your office, but traceroute sftp.example.com stops at your VPN gateway and ssh -vvv never gets past “Connecting,” the issue sits on the path, not in SFTP credentials. Microsoft also notes that SFTP uses port 22 by default, so a wrong port or blocked SSH port will look like a timeout, not a clean login failure [2][3].
Now You Know Whether The Packet
Now you know whether the packet ever reaches port 22. The next step is to separate a firewall that silently drops traffic from one that rejects it immediately.
Why does one firewall cause a timeout while another gives an immediate error?
Silent drop vs reject
A firewall that drops packets makes you wait. Your client sends SYN packets, gets nothing back, and eventually reports an SSH timeout. A firewall that rejects packets fails fast, often with an immediate reset or connection refused message, because it actively responds instead of staying quiet [1][2].
That difference matters because a timeout does not always mean “the server is slow.” It can mean the firewall never let the traffic through. If you capture traffic with tcpdump, an RST from the server IP points to a server-side reject, while an RST from the firewall IP suggests a stateful firewall timeout or policy [7].
What `ssh -vvv` shows
Run ssh -vvv user@host and watch where it stops. If it hangs at Connecting to ... port 22, you have a reachability problem, not an SFTP login problem. If the reset arrives right after SYN-ACK, LogicMonitor notes that the cause may be a middlebox policy, port block, proxy, or misrouted backend [8].
A practical example makes this obvious. If your office network times out but your phone hotspot returns an error immediately, you are probably seeing different firewall behavior, not a broken SFTP server.
Idle sessions and resets
Some failures only appear after the connection sits idle. LogicMonitor describes resets that show up after about 30 seconds with no response as idle timeout or inactivity disconnects [9]. That is why an upload can work for a few minutes, then die without warning.
This is the same pattern behind the memorable 300 second failure case. A team saw SFTP uploads fail after exactly 5 minutes of idle time. The client was fine, but a NAT gateway expired the TCP flow, and keepalives fixed it once they set ServerAliveInterval to 60 and ClientAliveInterval on the server to 120, while ssh -vvv and traceroute confirmed the path was healthy.
Once you know whether the firewall is dropping, rejecting, or aging out the flow, you can tune SSH keepalives with confidence, which is the next piece of the puzzle.
How do SSH keepalives and NAT timeouts decide whether your session survives?
Keepalives keep the path warm
ServerAliveInterval and ClientAliveInterval do not fix a broken route. They keep idle SSH and SFTP sessions from looking dead to NAT devices, firewalls, and the server itself. OneUptime recommends ServerAliveInterval 60 with ServerAliveCountMax 3 on the client, and ClientAliveInterval 60, ClientAliveCountMax 3, plus TCPKeepAlive yes on the server for intermittent SSH timeouts [10].
A concrete example: if your file transfer pauses while you verify a checksum, a NAT device may forget the flow before you send the next packet. Sending a keepalive every 30 to 60 seconds often keeps that mapping open, and OneUptime specifically recommends ssh -o ServerAliveInterval=30 when idle periods trigger NAT timeout [11].
Know what the server enforces
ClientAliveInterval controls how long the SSH server waits before it probes an idle client, and ClientAliveCountMax controls how many unanswered probes it tolerates before closing the session [12]. That means a long pause on your side can still end in a clean disconnect, even if the network looks healthy.
You should use these settings to preserve good sessions, not to hide instability. If ssh -vvv shows repeated reconnects or tcpdump shows resets from the firewall IP, you still have a network problem [1][7]. A keepalive only helps when the path is otherwise stable but quiet.
Match the fix to the failure
If the session dies after a few minutes of inactivity, raise keepalive frequency a little and test again. If it dies during active transfer, do not blame NAT first, because that points back to routing, firewall policy, or a proxy in the path.
openSFTP lets you configure keepalive behavior, which helps when you control the client profile and want one consistent setting for known flaky paths. But if you need to keep turning keepalives higher just to stay connected, you should treat that as a clue, not a cure, and move on to the final fix strategy.
Diagnose the real cause before you change SSH settings
SFTP timeouts are often blamed on “the server,” but in practice they usually come from one of six concrete failure modes: DNS resolution, packet loss on the route, firewall DROP behavior, idle NAT expiry, SSH keepalive misconfiguration, or proxy or jump-host timeouts. You now have a way to separate them instead of guessing.
If dig or nslookup points to the wrong host, fix DNS. If ping, traceroute, or ssh -vvv stalls before port 22 opens, fix routing or filtering. If the connection works once and dies after idle time, tune ServerAliveInterval, ClientAliveInterval, or your openSFTP keepalive profile, then test the same path again.
Your next step is simple: run ssh -vvv user@host and traceroute host from the exact network where the timeout happens, then note the last line before the failure.
Frequently Asked Questions
What is the fastest way to tell if an SFTP connection timeout is caused by DNS or the network?
Run dig or nslookup first, then test ping and traceroute. If the hostname resolves incorrectly, it is DNS; if it resolves fine but traffic stops on the way, it is a routing or filtering issue.
Why does SFTP time out even when the server is reachable by ping?
Ping only proves basic IP reachability, not that port 22 is open. If ping works but ssh -vvv hangs at connecting, the usual cause is a firewall, security group, or blocked SSH port.
How can I tell whether a firewall is dropping traffic or rejecting it?
A drop usually looks like a timeout because no response comes back. A reject is faster and may return a reset or connection refused error, which means the firewall or host actively denied the session.
Do SSH keepalives fix every SFTP connection timeout?
No, keepalives only help when the path is healthy but idle sessions are expiring in NAT or firewall state tables. If the route is broken or port 22 is blocked, keepalives will not solve the problem.
What should I check first if SFTP disconnects after a few minutes of inactivity?
Check for NAT expiry or idle-session timeout on the firewall, VPN, or proxy in the path. Then test a lower ServerAliveInterval to keep the session warm and confirm whether the disconnect stops.
What is the most common mistake people make when troubleshooting an SFTP connection timeout?
They change SSH settings before proving where the failure is happening. The better approach is to test DNS, routing, port 22, and firewall behavior first, then apply keepalive settings only if the issue is inactivity-related.
Sources
- OneUptime, "SSH timeout flowchart and network-first troubleshooting for connection timeouts" (2026-01) [https://oneuptime.com/blog/post/2026-01-24-fix-ssh-connection-timeout-errors/view]
- Microsoft Learn, "SFTP timeout message can indicate wrong connection type or wrong target port, with SFTP using port 22 by default" (unknown) [https://learn.microsoft.com/en-us/fabric/data-factory/connector-troubleshoot-ftp-sftp-http]
- Microsoft Q&A, "SFTP uses port 22 by default and blocked SSH ports can cause timeouts" (2024-03) [https://learn.microsoft.com/en-us/answers/questions/1604924/cant-connect-using-filezilla-sftp-ssh-but-its-work]
- Microsoft Q&A, "Allow inbound port 22 or the custom SSH port in NSG rules" (2024-03) [https://learn.microsoft.com/en-us/answers/questions/1604924/cant-connect-using-filezilla-sftp-ssh-but-its-work]
- OneUptime, "tcpdump RST interpretation for server, firewall, and IDS/IPS causes" (2026-03) [https://oneuptime.com/blog/post/2026-03-20-tcp-connection-resets-firewalls/view]
- LogicMonitor, "RST immediately after SYN-ACK can indicate middlebox policy, port block, proxy, or misrouted backend" (unknown) [https://www.logicmonitor.com/blog/tracking-down-failed-tcp-connections-and-rst-packets]
- LogicMonitor, "RST about 30 seconds after no response can indicate idle timeout or inactivity disconnect" (unknown) [https://www.logicmonitor.com/blog/tracking-down-failed-tcp-connections-and-rst-packets]
- OneUptime, "Recommended SSH keepalive values for intermittent timeouts" (2026-01) [https://oneuptime.com/blog/post/2026-01-24-fix-ssh-connection-timeout-errors/view]
- OneUptime, "ServerAliveInterval 30 and server-side ClientAlive settings for NAT timeout" (2026-01) [https://oneuptime.com/blog/post/2026-01-24-fix-ssh-connection-timeout-errors/view]
- Tenable, "ClientAliveInterval and ClientAliveCountMax control SSH idle session timeout" (unknown) [https://www.tenable.com/audits/items/Tenable_Best_Practices_Cisco_Firepower_Management_Center_OS.audit:2390ffc276ebe6e8222368cec31dd842]
