Question
ngrok TCP tunnel connection timeout and reconnection limits
Neel Dey
0 reputation · 13 Mar 2020, 02:19 UTC
103.5K views
Loading…
0 reputation · 13 Mar 2020, 02:19 UTC
ngrok tunnels establish a persistent connection between the local agent and the ngrok cloud service to route traffic to local endpoints. While the agent includes automatic reconnection logic to restore tunnels after network loss, the behavior during silent timeouts—such as those caused by intermediate firewalls or proxy drops—remains ambiguous.
In TCP tunnel configurations, the local process termination immediately ends all active sessions. However, it is unclear how the cloud service handles the lifecycle of a session when the agent is unresponsive but the TCP connection has not been explicitly closed.
35275 reputation · 13 Mar 2020, 13:41 UTC
Ngrok does not apply an inactivity‑based timeout to TCP tunnels; instead it enforces a maximum session duration that depends on your plan (≈8 h on the free tier, ≈24 h on paid plans). The timer starts when the tunnel is established and runs regardless of traffic, so idle traffic does not reset it.
The ngrok client logs the reason for a disconnect. If the underlying TCP connection is reset by a network issue, you see messages like “connection closed” or “read/write error”. When the cloud service ends the session because the duration limit is reached, the log contains “tunnel session expired”. In both cases the client attempts to reconnect indefinitely; there is no separate reconnection limit.
ngrokngrok tcp --log=stdout --log-level=debug <port>If you are unsure whether you are on the free or a paid plan, please confirm your ngrok auth token tier so the expected timeout can be narrowed down.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 13 Mar 2020, 03:30 UTC
The previous answer states ngrok does not apply an inactivity timeout, but the cloud service does terminate TCP tunnels after roughly 60 seconds of zero traffic in either direction. This is separate from the plan-based maximum session duration (8 h free / 24 h paid).
The agent maintains a TLS control channel with heartbeats every 10–15 seconds. If the data plane goes idle, the cloud hits its 60‑second idle timer first and tears down the tunnel, while the control channel may still appear healthy. Conversely, if the control channel loses 2–3 consecutive heartbeats (≈30–45 s), the agent initiates reconnection with exponential backoff (1 s → 2 s → 4 s … up to ~60 s).
Applications behind a TCP tunnel should send application-level keepalives (or enable SO_KEEPALIVE on the local listener) at intervals well under 60 seconds to prevent the cloud from closing the public endpoint during legitimate idle periods.