Intermittent "stream error: INTERNAL_ERROR; received from peer" on non-fingerprinted upstreams (HTTP/2 RST_STREAM leaks mid-stream)

[sweetcornna]

Summary

When a provider upstream is not one of the uTLS-fingerprinted hosts (api.anthropic.com, chatgpt.com) — e.g. a reseller/aggregator gateway, a self-hosted relay, or any OpenAI/Anthropic-compatible endpoint — requests intermittently fail mid-stream and the client receives a raw Go error:

API Error: stream error: stream ID 1; INTERNAL_ERROR; received from peer

This happens occasionally (only when the upstream resets a stream mid-response), so it presents as flaky "stream cut off" behavior.

Root cause

That string is the golang.org/x/net/http2 StreamError with errFromPeer ("received from peer") — i.e. a Go HTTP/2 client received a RST_STREAM(INTERNAL_ERROR) frame from its server. The only Go HTTP/2 client in the request path is CLIProxyAPI's own connection to the upstream.

The uTLS Chrome-fingerprint HTTP/2 round-tripper is gated to a hardcoded allow-list (internal/runtime/executor/helps/utls_client.go):

var utlsProtectedHosts = map[string]struct{}{
    "api.anthropic.com": {},
    "chatgpt.com":       {},
}

Every other host falls through to fallback = http.DefaultTransport, which has ForceAttemptHTTP2 = true and negotiates HTTP/2 whenever the upstream's ALPN offers h2 (most gateways behind nginx/Cloudflare do).

When such an upstream resets a stream mid-response:

• The conductor only retries resets that occur before the first byte (empty_stream … Retryable: true). A mid-stream reset cannot be retried (bytes already forwarded to the client).
• The abrupt RST_STREAM is surfaced through the executor's scanner.Err() path and forwarded verbatim, so the client sees the raw stream error … INTERNAL_ERROR; received from peer.

Impact

Any deployment whose claude/codex/gemini/openai-compat upstream points at a non-anthropic/chatgpt HTTPS endpoint that negotiates HTTP/2 is exposed: a flaky upstream channel leaks raw http2 framing errors to end users instead of failing gracefully.

Proposed fix

Force HTTP/1.1 on the fallback transport (the non-fingerprinted path), mirroring the existing cloneTransportWithHTTP11 used by the antigravity executor. Over HTTP/1.1 the RST_STREAM error class cannot occur; a mid-response upstream drop becomes a plain connection close (clean EOF), which composes cleanly with terminal-marker synthesis (e.g. #3997) for a graceful message_stop/[DONE] instead of a hard error. The uTLS HTTP/2 path for Anthropic/ChatGPT is intentionally left untouched to preserve its Chrome fingerprint.

PR with tests: follows.

Environment

• CLIProxyAPI: dev
• Upstream: third-party OpenAI/Anthropic-compatible aggregator (New API style) over HTTPS, ALPN h2
• Downstream: nginx (TLS termination) → cliproxy over HTTP/1.1; client is Claude Code / OpenAI JS SDK

[luispater]

Thanks for the detailed report.

After reviewing this, we do not plan to change the default fallback transport to force HTTP/1.1 for all non-fingerprinted upstreams.

The reported stream error: stream ID ... INTERNAL_ERROR; received from peer is generated when the upstream side resets an HTTP/2 stream mid-response. That points to upstream/network/proxy instability rather than a CLIProxyAPI protocol translation bug. Forcing HTTP/1.1 globally would avoid this specific HTTP/2 error string, but it would also disable HTTP/2 multiplexing and can reduce network throughput and connection efficiency for many normal upstream deployments.

If a specific upstream or deployment environment is unstable over HTTP/2, the preferred mitigation is to fix or tune that upstream/proxy path, or configure that environment to avoid HTTP/2 at the network/proxy layer where appropriate. We should not make HTTP/1.1 the global fallback default for all custom upstreams.

Closing this as not planned.