httpx Using a Client with a proxy to plain http endpoints

The Fix

Upgrade to version 0.13.0 or later.

Based on closed encode/httpx issue #2488 · PR/commit linked

Production note: Most teams hit this during upgrades or environment changes. Roll out with a canary and smoke critical endpoints (health, OpenAPI/docs) before 100%.

Jump to Verify Open PR/Commit

@@ -2,6 +2,7 @@
 import h2.connection
 import h2.events
+from h2.config import H2Configuration
 from h2.settings import SettingCodes, Settings

repro.py

with httpx.Client(proxies="http://user:[email protected]:8000") as client:
    x = client.get("http://www.google.com")
    y = client.get("http://www.facebook.com")

print(x.status_code, y.status_code)  # 200, 404

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

fix.md

Option A — Upgrade to fixed release\nUpgrade to version 0.13.0 or later.\nWhen NOT to use: This fix is not applicable if using a different proxy implementation that does not support connection pooling correctly.\n\n

Why This Fix Works in Production

Trigger: This happens no matter what the second request URL is. It also doesn't seem to matter how many requests you send after the first. They all return 404.
Mechanism: The connection pooling for HTTP proxies was incorrectly handling requests to different endpoints
Why the fix works: The issue with using a Client with a proxy for multiple plain HTTP endpoints was resolved by modifying the connection handling in the HTTP core library. (first fixed release: 0.13.0).

Production impact:

If left unfixed, the same config can fail only in production (env differences), causing startup failures or partial feature outages.

Why This Breaks in Prod

The connection pooling for HTTP proxies was incorrectly handling requests to different endpoints
Production symptom (often without a traceback): This happens no matter what the second request URL is. It also doesn't seem to matter how many requests you send after the first. They all return 404.

Proof / Evidence

GitHub issue: #2488
Fix PR: https://github.com/encode/httpcore/pull/637
First fixed release: 0.13.0
Reproduced locally: No (not executed)
Last verified: 2026-02-08
Confidence: 0.85
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.74

Discussion

High-signal excerpts from the issue thread (symptoms, repros, edge-cases).

Jump to Sources Open on GitHub

“Okey dokes. Fix over at https://github.com/encode/httpcore/pull/637 If you're able to test against that and confirm on the issue that'd be great. Then once we've got…”

@lovelydinosaur · 2022-12-02 · confirmation · source

“Great! I’ll pull that in later this evening and confirm”

@JB0925 · 2022-12-02 · confirmation · source

“Okay, I think I know what's going on here, but let's work it through. First up, does this reproduce when you're using https URLs, or…”

@lovelydinosaur · 2022-12-02 · source

“Gotcha. Next question then, are you able to reproduce the same issue with requests instead of httpx or not?”

@lovelydinosaur · 2022-12-02 · source

Failure Signature (Search String)

This happens no matter what the second request URL is. It also doesn't seem to matter how many requests you send after the first. They all return 404.
I also cannot reproduce this behavior with the high level API.

Copy-friendly signature

signature.txt

Failure Signature
-----------------
This happens no matter what the second request URL is. It also doesn't seem to matter how many requests you send after the first. They all return 404.
I also cannot reproduce this behavior with the high level API.

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
This happens no matter what the second request URL is. It also doesn't seem to matter how many requests you send after the first. They all return 404.
I also cannot reproduce this behavior with the high level API.

Minimal Reproduction

repro.py

with httpx.Client(proxies="http://user:[email protected]:8000") as client:
    x = client.get("http://www.google.com")
    y = client.get("http://www.facebook.com")

print(x.status_code, y.status_code)  # 200, 404

What Broke

Subsequent requests to different plain HTTP endpoints return 404 errors after the first request succeeds.

Why It Broke

The connection pooling for HTTP proxies was incorrectly handling requests to different endpoints

Fix Options (Details)

Option A — Upgrade to fixed release Safe default (recommended)

Upgrade to version 0.13.0 or later.

When NOT to use: This fix is not applicable if using a different proxy implementation that does not support connection pooling correctly.

Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.

Fix reference: https://github.com/encode/httpcore/pull/637

First fixed release: 0.13.0

Last verified: 2026-02-08. Validate in your environment.

When NOT to Use This Fix

This fix is not applicable if using a different proxy implementation that does not support connection pooling correctly.

Verify Fix

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

Did This Fix Work in Your Case?

Quick signal helps us prioritize which fixes to verify and improve.

Prevention

Add a CI check that diffs key outputs after upgrades (OpenAPI schema snapshots, JSON payload shapes, CLI output).
Upgrade behind a canary and run integration tests against the canary before 100% rollout.
Add a TLS smoke test that performs a real handshake in CI (include CA bundle validation and hostname checks).
Alert on handshake failures by error string and endpoint to catch cert/CA changes quickly.

Version Compatibility Table

Version	Status
0.13.0	Fixed

Related Issues

No related fixes found.

Cluster: httpx:configuration-error All hubs All clusters

Related clusters: Data consistency Other Timeout

Sources

We don’t republish the full GitHub discussion text. Use the links above for context.

httpx Using a Client with a proxy to plain http endpoints returns 200 for the first, and 404 for (Fix)