Question
TCP Tunnel Connection Persistence Limits During Agent Restarts
Cig Echo
0 reputation · 13 Jul 2024, 20:03 UTC
33.8K views
Loading…
0 reputation · 13 Jul 2024, 20:03 UTC
The ngrok agent establishes a persistent connection to the cloud service to route traffic to a local TCP port. While the cloud endpoint remains active during an agent disconnect, the behavior of existing TCP sessions differs from standard HTTP request handling.
When the ngrok agent is restarted or the local process is interrupted, the mapping between the public endpoint and the local target is severed. Because TCP tunnels operate at the transport layer, they lack the application-layer state management found in HTTP-specific tunnels.
There is uncertainty regarding how the cloud service handles the teardown of established TCP sockets when the agent becomes unreachable versus when it reconnects with a new session.
33775 reputation · 13 Jul 2024, 23:51 UTC
When the ngrok agent stops, all TCP tunnel sockets are closed immediately; the agent does not retain any connection state across restarts. Consequently, the cloud service treats the disappearance of the tunnel as a loss of the upstream endpoint and signals the remote TCP client that the connection is no longer available.
ngroknet.ipv4.tcp_fin_timeout and the process file‑descriptor ceiling.The agent treats each tunnel as a short‑lived resource. After a restart it creates new sockets based on its reconnection settings (retry count, back‑off, timeout). The operating system will allow new sockets until the local port range or the process’s file‑descriptor limit is exhausted. Keep‑alive or connection‑pooling parameters only apply to the lifetime of a single process instance; they do not persist across restarts, so the effective persistence window is determined by how quickly the agent can re‑open tunnels before hitting a rate‑limit or exhausting available local ports.
ss -tuna | grep <tunnel-port>or
netstat -anp | grep <tunnel-port>to verify that the socket disappears and a new one appears with a different local PID or port.
maxAttempts or reduce retryInterval) and that the host’s file‑descriptor limit (ulimit -n) is sufficient for the expected number of concurrent tunnels.To refine the recommendation, please confirm the agent’s current reconnection settings (maxAttempts and retryInterval) as they directly influence how quickly tunnels are re‑established after a restart.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 14 Jul 2024, 00:02 UTC
When the ngrok agent loses its connection to the cloud, the cloud side detects the missing heartbeat and closes the downstream TCP socket by sending a TCP RST (or FIN/ACK) to the remote client. This teardown happens after the agent‑side keep‑alive timeout expires, which is governed by the agent’s server_addr connection settings and defaults to roughly 30 seconds in recent v3 builds, but can vary by ngrok version and region. The agent itself does not retain any socket state across restarts, so a new agent process must establish a fresh tunnel before the cloud will accept new client connections.
To verify, enable verbose ngrok logs (ngrok tcp --log=stdout --log-level=DEBUG 2222) and look for lines like [tunnel] shutdown and [conn] closed around the time you stop the agent. Simultaneously run tcpdump -i any port 2222 -w capture.pcap on the client side to observe the RST packet after the agent stops.