Why Does SSH Disconnect? Broken Pipe and Keepalive Guide
An SSH session that drops after a few minutes may be caused by a mobile network change, NAT timeout, server policy or a connection that carries no traffic for too long.
What does the disconnect message tell you?
The client can no longer write to the peer; the underlying network path may have failed earlier.
The remote system or an intermediate network device may have reset the TCP connection.
No response arrived within the expected time because of the route, firewall or unavailable server.
The server may have ended the session because of policy, maintenance, resource limits or a normal logout.
Common reasons an SSH session drops
When a phone moves between Wi-Fi and mobile data, the address associated with its TCP connection can change. The operating system may also restrict background network activity after the screen turns off. Routers, firewalls and corporate NAT devices can delete idle flows from their tables.
On the server, ClientAliveInterval, idle-shell policy, account limits or maintenance can end the session. Determine whether the failure happens after a consistent interval, only during a network change or while large amounts of output are moving.
ServerAliveInterval vs TCPKeepAlive
| Setting | How it works | Purpose |
|---|---|---|
| ServerAliveInterval | Requests a response through the encrypted SSH channel | Detects an unresponsive peer and may keep an idle NAT flow active |
| ServerAliveCountMax | Limits unanswered server-alive messages | Controls when the connection is considered failed |
| TCPKeepAlive | Uses operating-system TCP keepalive messages | Can detect a dead path but is separate from the SSH-level mechanism |
ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3 user@serverStep-by-step diagnosis
- 1Measure the interval
A repeatable failure after the same number of minutes points toward an idle policy or NAT timeout.
- 2Check network changes
Test the relationship with Wi-Fi signal, VPN reconnects, mobile-data switching and device sleep.
- 3Collect verbose client output
With OpenSSH, use -v and if needed -vv or -vvv to see when the session closes.
- 4Inspect server logs
Look for sshd shutdown, account policy, resource limits or a server restart at the same time.
- 5Test a measured keepalive
Use a reasonable interval and compare whether the problem is specifically an idle-flow timeout.
Considerations for phones and laptops
The operating system may suspend the app or network when the screen is off.
An active SSH TCP session normally cannot move seamlessly to a different public address.
Rebuilding a VPN tunnel can invalidate the existing SSH flow.
Use a server-side session manager such as tmux or screen when work must survive a client disconnect.
Do not overuse keepalive settings
Very short intervals add unnecessary traffic and battery use. Keepalives do not repair poor Wi-Fi, a stopped SSH service or a restarted server; they only test the connection more regularly.
Before changing a server-wide policy, consider its effect on other users and automation. A client-specific setting is a controlled way to test one user’s idle-session problem.
For a job that must run for hours, use a reconnectable server session or service instead of relying only on an open mobile connection.
Put the guide into practice.
Review the related Varkuna product or open its detailed user guide.