Some HTTP MCP clients log a basic connectivity pre-check, finish TCP/TLS in well under a second, then sit idle for a tight ~25s band before logging success and sending the real request.
When a capture shows the handshake fully ACKed and zero application bytes until the client closes, the stall is almost certainly in client logic: a fixed timer, a probe that never writes, or negotiation that only continues after a timeout.
Useful isolation without owning the server:
- Wall-clock from the "testing connectivity" log to the first client-sent application byte
- Whether an HTTP/2 preface, SETTINGS, or any request leaves during the gap
- Local config beside the server URL for protocol or feature-flag state that could gate the next step
Which client pre-check designs have you seen that wait a fixed multi-second delay after the socket is already live?
Top comments (0)