Technology · PRACTICAL GUIDE
curl error 92 says an HTTP/2 stream closed badly? Preserve the reset code before forcing HTTP/1.1
Exit 92 names an HTTP/2 framing-layer failure, not one universal cause. Capture the exact reset, classify whether the request is safe to repeat, isolate client, intermediary and origin behavior, then verify the response before adopting a fallback.
Exit 92 names an HTTP/2 framing-layer failure, not one universal cause. Capture the exact reset, classify whether the request is safe to repeat, isolate client, intermediary and origin behavior, then verify the response before adopting a fallback.
The safe path is evidence first: preserve the exact error and request, decide whether repeating it can cause side effects, compare protocols without changing other variables, then verify the complete result.
Freeze one reproducible request and the exact error
Record curl -V, the method, URL, exit status, stream number and named HTTP/2 error such as PROTOCOL_ERROR, INTERNAL_ERROR or CANCEL. Keep the original command in a private log, but redact authorization, cookies, request bodies and tokens before sharing diagnostics.
Use a safe test account or read-only endpoint when possible. A successful browser request does not disprove the failure: protocol negotiation, headers, proxy route, connection reuse and implementation can differ. Preserve timestamps and the failing network path.
Classify retry safety before running the request again
GET and HEAD are normally designed to be repeatable, but still verify application behavior. POST, PUT, PATCH and DELETE may have been processed before the stream error became visible. Check server logs, idempotency keys, job IDs or transaction state before retrying them.
RFC 9113 provides specific retry guarantees for streams above a GOAWAY last-stream identifier and for REFUSED_STREAM. A generic CANCEL, INTERNAL_ERROR or PROTOCOL_ERROR is not the same guarantee. Do not let an automatic retry create duplicate charges, uploads or mutations.
Capture a redacted trace and locate the boundary
Start with curl --verbose for protocol and header context. On current curl, a targeted trace such as --trace-config ids,time,http/2,ssl can separate transfers and expose HTTP/2 and TLS events. Trace output can contain credentials and body data, so store it privately and redact before sharing.
Compare client time with proxy, CDN, gateway and origin logs. Determine whether the reset came from the immediate peer, a downstream hop or the client after malformed or incomplete input. Error 92 alone does not identify the responsible machine.
Compare HTTP/2 and HTTP/1.1 without changing everything else
Repeat the same safe request with explicit --http2 and --http1.1 controls, using the same URL, payload, credentials, proxy and region. If HTTP/1.1 succeeds while HTTP/2 fails, you have narrowed the fault to an HTTP/2-dependent path; you have not proved whether curl, an intermediary or the origin is wrong.
Do not simultaneously increase buffers, split the payload, switch networks and change protocol. One-variable comparisons plus current client and dependency versions are useful evidence. A newer curl or nghttp2 result can identify a version boundary but still requires output verification.
Verify completeness, then choose a bounded mitigation
Validate status, headers, byte count or digest and the application-level result. For downloads, write to a new temporary filename and publish it only after verification. For APIs, confirm that the body parses and represents a complete response rather than accepting a truncated prefix.
Use HTTP/1.1 as a temporary, scoped mitigation only if the same request is safe, the complete result verifies, and the affected service and deadline are documented. Keep HTTP/2 investigation open. Stop and escalate when non-idempotent processing is unknown, output is incomplete, or different edges disagree.
