Proxy sent {} unexpected byte(s) after CONNECT response head

Error message

Proxy sent {} unexpected byte(s) after CONNECT response headers

What it means

After reading the CONNECT response headers with BufReader::read_line, the code checks reader.buffer() for read-ahead bytes. A well-behaved proxy sends nothing after the header-terminating blank line until TLS begins; leftover bytes would corrupt the subsequent TLS handshake, so the tunnel is aborted with this error.

Source

Thrown at crates/codegen/xai-grok-shell/src/agent/proxy.rs:189

    }

    // Consume remaining response headers (until empty line).
    loop {
        let mut line = String::new();
        reader.read_line(&mut line).await?;
        if line.trim().is_empty() {
            break;
        }
    }

    // 5. Assert the BufReader's internal buffer is empty before reuniting.
    // BufReader::read_line may have read ahead into its buffer. If extra
    // bytes were consumed beyond the HTTP headers (e.g., from a proxy that
    // eagerly forwards data or coalesced TCP segments), dropping them would
    // corrupt the subsequent TLS handshake.
    let remaining = reader.buffer();
    if !remaining.is_empty() {
        anyhow::bail!(
            "Proxy sent {} unexpected byte(s) after CONNECT response headers",
            remaining.len()
        );
    }

    // 6. Reunite the split halves back into a TcpStream.
    let stream = reader.into_inner().reunite(writer_half)?;
    Ok(stream)
}

async fn tls_wrap(
    stream: TcpStream,
    server_name: &str,
) -> anyhow::Result<tokio_rustls::client::TlsStream<TcpStream>> {
    let connector = tokio_rustls::TlsConnector::from(xai_grok_extra_ca::rustls_client_config());
    let dns_name = rustls::pki_types::ServerName::try_from(server_name.to_string())
        .map_err(|e| anyhow::anyhow!("Invalid TLS server name '{server_name}': {e}"))?;

View on GitHub (pinned to bc7f02eddd)

Solutions

Bypass the problematic proxy/middlebox for this host (NO_PROXY or direct connection).
Upgrade or fix the proxy software — this behavior violates the CONNECT tunneling contract (RFC 7231).
Check for TLS-inspection/security appliances intercepting the tunnel and add an exemption.
As a workaround, use a different proxy or the non-proxy connection path.

Example fix

// before
HTTPS_PROXY=http://legacy-proxy:3128 grok agent ...
// after
NO_PROXY=relay.example.com grok agent ...  # bypass buggy proxy

Defensive patterns

Strategy: fallback

Try / catch

match connect_via_proxy(target, &proxy).await {
    Err(e) if e.to_string().contains("unexpected byte(s) after CONNECT") => {
        eprintln!("proxy misbehaves (read-ahead data); bypassing proxy");
        connect_direct(target).await // fall back to no-proxy path
    }
    other => other,
}

Prevention

Bypass known-buggy proxies/middleboxes with NO_PROXY for relay hosts
Exempt relay traffic from TLS-inspection/security appliances that inject data
Upgrade proxy software that pipelines or pre-sends data after CONNECT responses
Provide a direct-connection fallback when proxy tunneling fails

When it happens

Trigger: The proxy (or a middlebox) eagerly forwarded application data or coalesced TCP segments so that bytes beyond the CONNECT response headers were already consumed into the BufReader when the header parse finished.

Common situations: Non-standard or buggy intermediary proxies; TLS-terminating middleboxes that inject data; security appliances that pre-send a banner; misconfigured proxy software that pipelines responses.

Related errors

AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/94b0df379e2ea3de. Report an issue: GitHub.