urllib3 File descriptor leak with HTTPS proxies via CONNECT

The Fix

pip install urllib3==1.25

Based on closed urllib3/urllib3 issue #548 · PR/commit linked

Production note: Watch p95/p99 latency and retry volume; timeouts can turn into retry storms and duplicate side-effects.

Open PR/Commit

@@ -588,14 +588,13 @@ def urlopen(self, method, url, body=None, headers=None, retries=None,
                 conn = None
 
-            stacktrace = sys.exc_info()[2]
             if isinstance(e, SocketError) and self.proxy:
                 e = ProxyError('Cannot connect to proxy.', e)

fix.md

Option A — Upgrade to fixed release\npip install urllib3==1.25\nWhen NOT to use: This fix should not be applied if the application relies on stack traces for error handling.\n\nOption C — Workaround\nabove is working for now but I'd like to find the root cause, or at least a workaround that doesn't break stack traces. Any idea where to start looking? Thanks\nWhen NOT to use: This fix should not be applied if the application relies on stack traces for error handling.\n\n

Why This Fix Works in Production

Trigger: File descriptor leak with HTTPS proxies via CONNECT
Mechanism: File descriptor leak occurs due to a circular reference preventing socket cleanup during HTTPS requests through an HTTP proxy
Why the fix works: Fixes a file descriptor leak caused by a stack frame reference during HTTPS requests through an HTTP proxy. (first fixed release: 1.25).

Production impact:

If left unfixed, this can cause silent data inconsistencies that propagate (bad cache entries, incorrect downstream decisions).

Why This Breaks in Prod

File descriptor leak occurs due to a circular reference preventing socket cleanup during HTTPS requests through an HTTP proxy
Production symptom (often without a traceback): File descriptor leak with HTTPS proxies via CONNECT

Proof / Evidence

GitHub issue: #548
Fix PR: https://github.com/urllib3/urllib3/pull/549
First fixed release: 1.25
Reproduced locally: No (not executed)
Last verified: 2026-02-09
Confidence: 0.85
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.72

Discussion

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

Jump to Sources Open on GitHub

“@ianpreston Great find, thank you! Honestly I'm not very experienced with finding memory leaks in Python”

@shazow · 2015-02-10 · source

“I'm going to admit to a degree of confusion here”

@Lukasa · 2015-02-10 · source

“Can someone see if objgraph agrees with @ianpreston's understanding above?”

@sigmavirus24 · 2015-02-11 · source

“@Lukasa My understanding is that each frame of the traceback object returned by sys.exc_info holds references to the locals of that stack frame”

@ianpreston · 2015-02-11 · source

Failure Signature (Search String)

File descriptor leak with HTTPS proxies via CONNECT
It looks like when making HTTPS requests through an HTTP proxy, there is a file descriptor leak if an error occurs (e.g. socket timeout or 404 error) during

Copy-friendly signature

signature.txt

Failure Signature
-----------------
File descriptor leak with HTTPS proxies via CONNECT
It looks like when making HTTPS requests through an HTTP proxy, there is a file descriptor leak if an error occurs (e.g. socket timeout or 404 error) during httplib.HTTPConnection._tunnel. Tested in versions 1.9, 1.9.1, 1.10.

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
File descriptor leak with HTTPS proxies via CONNECT
It looks like when making HTTPS requests through an HTTP proxy, there is a file descriptor leak if an error occurs (e.g. socket timeout or 404 error) during httplib.HTTPConnection._tunnel. Tested in versions 1.9, 1.9.1, 1.10.

What Broke

Multiple connections remain in CLOSE_WAIT state after socket timeouts or errors, leading to resource exhaustion.

Why It Broke

File descriptor leak occurs due to a circular reference preventing socket cleanup during HTTPS requests through an HTTP proxy

Fix Options (Details)

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

pip install urllib3==1.25

When NOT to use: This fix should not be applied if the application relies on stack traces for error handling.

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

Option C — Workaround Temporary workaround

above is working for now but I'd like to find the root cause, or at least a workaround that doesn't break stack traces. Any idea where to start looking? Thanks

When NOT to use: This fix should not be applied if the application relies on stack traces for error handling.

Use only if you cannot change versions today. Treat this as a stopgap and remove once upgraded.

Fix reference: https://github.com/urllib3/urllib3/pull/549

First fixed release: 1.25

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

When NOT to Use This Fix

This fix should not be applied if the application relies on stack traces for error handling.

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.
Track RSS + object counts after deployments; alert on monotonic growth and GC pressure.
Add a long-running test that repeats the failing call path and asserts stable memory.

Version Compatibility Table

Version	Status
1.25	Fixed

Related Issues

No related fixes found.

Cluster: urllib3:data-consistency urllib3 hub urllib3 best practices All hubs All clusters

Related clusters: Configuration error SSL handshake Other

Sources

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

urllib3 File descriptor leak with HTTPS proxies via CONNECT (Fix)