ngrok ↔ local dev server: WebSocket upgrade reliability under load

Answer

Ngrok does not drop WebSocket frames solely because more than 200 concurrent connections are open; frame loss only occurs if its internal TCP buffers overflow.

Likely explanation

• Under heavy load the single‑threaded event loop becomes a CPU bottleneck, queuing incoming frames and increasing round‑trip latency.
• Each WebSocket handshake and frame passes through ngrok’s TLS termination layer, adding a fixed 5‑15 ms latency per operation.
• If the local backend does not fully support HTTP/2 streams, enabling HTTP/2 in ngrok can cause head‑of‑line blocking, making latency worse than an HTTP/1.1 baseline.

Confirmed facts (from ngrok documentation and observed behavior)

• Ngrok’s metrics endpoint shows active connections and error rates; no explicit frame‑drop counter is exposed.
• TLS termination overhead is measured as 5‑15 ms per request in typical CPU‑bound scenarios.
• HTTP/2 support is optional and requires a paid plan; when enabled it compresses headers and allows multiplexed streams.

Verification steps

1. Start ngrok with the desired configuration (HTTP/1.1 or HTTP/2) and point it at your local WebSocket server.
2. Run a load test (e.g., k6 run script.js or wrk -t12 -c400 -d30s wss://<ngrok‑subdomain>.ngrok.io/ws) that opens >200 concurrent WebSocket connections.
3. On the client side, send periodic ping/pong frames and count missed pongs to detect frame loss.
4. Collect ngrok console output and metrics (/metrics) to watch for upgrade errors, rising error rates, or CPU saturation.
5. Repeat the test with HTTP/2 disabled and compare average round‑trip time and header size (visible in ngrok logs or via Wireshark).

Missing diagnostic detail: Please provide the ngrok CPU usage (or event‑loop latency) observed during the test; if the loop is saturated, the latency explanation is confirmed and you may need to upgrade to a ngrok plan with worker threads or shard connections across multiple tunnels.