The Fix
Upgrade to version 0.7.3 or later.
Based on closed encode/httpx issue #897 · 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%.
@@ -22,6 +22,7 @@
from .dispatch.connection import HTTPConnection
from .dispatch.connection_pool import ConnectionPool
+from .dispatch.proxy_http import HTTPProxy, HTTPProxyMode
from .exceptions import (
ConnectTimeout,
import requests
import httpx
import trio
proxies = {
"https": "https://128.199.241.229:44344" ### tested many other proxies
}
req= requests.get('https://ifconfig.me/ip', proxies=proxies)
print('requests', req.text)
async def main():
async with httpx.AsyncClient(proxies=proxies) as client:
response = await client.get('https://ifconfig.me/ip')
print('httpx', response.text)
trio.run(main)
Re-run the minimal reproduction on your broken version, then apply the fix and re-run.
Option A — Upgrade to fixed release\nUpgrade to version 0.7.3 or later.\nWhen NOT to use: This fix should not be used if the proxy does not support the CONNECT method for HTTPS.\n\nOption C — Workaround\nseems to use an HTTP URL, so that the proxy is established over TCP and _then_ the connection is upgraded to TLS. See https://github.com/encode/httpx/pull/259#issuecomment-531449348.\nWhen NOT to use: This fix should not be used if the proxy does not support the CONNECT method for HTTPS.\n\n
Why This Fix Works in Production
- Trigger: requests 128.199.241.229
- Mechanism: NetworkError occurs due to improper handling of HTTPS proxies in the HTTPX library
- Why the fix works: Implemented HTTP proxies and configuration on Client to resolve NetworkError when using HTTPS proxies. (first fixed release: 0.7.3).
- 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
- NetworkError occurs due to improper handling of HTTPS proxies in the HTTPX library
- Surfaces as: requests 128.199.241.229
Proof / Evidence
- GitHub issue: #897
- Fix PR: https://github.com/encode/httpx/pull/259
- First fixed release: 0.7.3
- 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.40
Discussion
High-signal excerpts from the issue thread (symptoms, repros, edge-cases).
“I'm going to temptatively close this as we've already merged some changes regarding proxies in httpcore and here. If this issue persists in master please…”
“Is it possible the proxy does not expect a TLS handshake on that port? I've seen that WRONG_VERSION_NUMBER error when trying to make an HTTPS…”
“Hi! Can you try using http:// in the proxy URL? This might be a limitation of our current implementation — I had already noted this…”
“Ahhh, i did other tests and yeah using http:// inside "https": is the solution : #### Failed (logic) : proxy:http url:https #### Success: proxy:http url:http…”
Failure Signature (Search String)
- requests 128.199.241.229
Error Message
Stack trace
Error Message
-------------
requests 128.199.241.229
Traceback (most recent call last):
File "C:\Users\user\AppData\Roaming\Python\Python38\site-packages\trio\_ssl.py", line 466, in _retry
ret = fn(*args)
File "C:\Users\user\AppData\Local\Programs\Python\Python38\lib\ssl.py", line 944, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1108)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "C:\Users\user\AppData\Roaming\Python\Python38\site-packages\httpx\_utils.py", line 364, in as_network_error
yield
File "C:\Users\user\AppData\Roaming\Python\Python38\site-packages\httpx\_backends\trio.py", line 106, in open_tcp_stream
await stream.do_handshake()
File "C:\Users\user\AppData\Roaming\Python\Python38\site-packages\trio\_ssl.py", line 636, in do_handshake
await self._handshook.ensure(checkpoint=True)
File "C:\Users\user\AppData\Roaming\Python\Python38\site-packages\trio\_ssl.py", line 212, in ensure
await self._afn(*self._args)
File "C:\Users\user\AppData\Roaming\Python\Python38\site-packages\trio\_ssl.py", line 606, in _do_handshake
await self._retry(self._ssl_object.do_handshake, is_handshake=True)
File "C:\Users\user\AppData\Roaming\Python\Python38\site-packages\trio\_ssl.py", line 471, in _retry
raise trio.BrokenResourceError from e
... (truncated) ...
Stack trace
Error Message
-------------
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1108)
Minimal Reproduction
import requests
import httpx
import trio
proxies = {
"https": "https://128.199.241.229:44344" ### tested many other proxies
}
req= requests.get('https://ifconfig.me/ip', proxies=proxies)
print('requests', req.text)
async def main():
async with httpx.AsyncClient(proxies=proxies) as client:
response = await client.get('https://ifconfig.me/ip')
print('httpx', response.text)
trio.run(main)
Environment
- httpx: 128.199.241
What Broke
Users experience failures when attempting to connect through HTTPS proxies, leading to request failures.
Why It Broke
NetworkError occurs due to improper handling of HTTPS proxies in the HTTPX library
Fix Options (Details)
Option A — Upgrade to fixed release Safe default (recommended)
Upgrade to version 0.7.3 or later.
Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.
Option C — Workaround Temporary workaround
seems to use an HTTP URL, so that the proxy is established over TCP and _then_ the connection is upgraded to TLS. See https://github.com/encode/httpx/pull/259#issuecomment-531449348.
Use only if you cannot change versions today. Treat this as a stopgap and remove once upgraded.
Fix reference: https://github.com/encode/httpx/pull/259
First fixed release: 0.7.3
Last verified: 2026-02-09. Validate in your environment.
When NOT to Use This Fix
- This fix should not be used if the proxy does not support the CONNECT method for HTTPS.
Verify Fix
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.7.3 | Fixed |
Related Issues
No related fixes found.
Sources
We don’t republish the full GitHub discussion text. Use the links above for context.