httpx `trust_env` has diverging defaults between `Client`

The Fix

Upgrade to version 0.17.0 or later.

Based on closed encode/httpx issue #1430 · 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

@@ -43,7 +43,7 @@ class UnsetType:
     cert: CertTypes = None,
     verify: VerifyTypes = True,
-    trust_env: bool = None,
+    trust_env: bool = True,
     http2: bool = False,

repro.py

import httpx

transport = httpx.HTTPTransport()

# This is NOT equivalent:
transport = httpx.HTTPTransport(ssl_context=httpx.create_ssl_context())
# Users might do this^, and expect eg SSLKEYLOGFILE to be enabled, but it won't...

# They'd need to pass an explicit `trust_env=True`...
transport = httpx.HTTPTransport(ssl_context=httpx.create_ssl_context(trust_env=True))

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.17.0 or later.\nWhen NOT to use: This fix should not be applied if the application relies on `trust_env=None` for specific behavior.\n\n

Why This Fix Works in Production

Trigger: `trust_env` has diverging defaults between `Client` and `create_ssl_context`
Mechanism: The `create_ssl_context` helper function now uses `trust_env=True` in line with `httpx.Client`, instead of erroneously having a tri-state value, with a `None` default.
Why the fix works: The `create_ssl_context` helper function now uses `trust_env=True` in line with `httpx.Client`, instead of erroneously having a tri-state value, with a `None` default. (first fixed release: 0.17.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

Production symptom (often without a traceback): `trust_env` has diverging defaults between `Client` and `create_ssl_context`

Proof / Evidence

GitHub issue: #1430
Fix PR: https://github.com/encode/httpx/pull/1447
First fixed release: 0.17.0
Reproduced locally: No (not executed)
Last verified: 2026-02-09
Confidence: 0.75
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.63

Discussion

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

Jump to Sources Open on GitHub

“Right now there's a slight discrepancy for the default value of trust_env for httpx.Client() / httpx.AsyncClient() and httpx.create_ssl_context(). * Clients use trust_env=True as a default. * create_ssl_context uses trust_env=None as a defa”

Issue thread · issue description · source

Failure Signature (Search String)

`trust_env` has diverging defaults between `Client` and `create_ssl_context`
Right now there's a slight discrepancy for the default value of `trust_env` for `httpx.Client()` / `httpx.AsyncClient()` and `httpx.create_ssl_context()`.

Copy-friendly signature

signature.txt

Failure Signature
-----------------
`trust_env` has diverging defaults between `Client`  and `create_ssl_context`
Right now there's a slight discrepancy for the default value of `trust_env` for `httpx.Client()` / `httpx.AsyncClient()` and `httpx.create_ssl_context()`.

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
`trust_env` has diverging defaults between `Client`  and `create_ssl_context`
Right now there's a slight discrepancy for the default value of `trust_env` for `httpx.Client()` / `httpx.AsyncClient()` and `httpx.create_ssl_context()`.

Minimal Reproduction

repro.py

import httpx

transport = httpx.HTTPTransport()

# This is NOT equivalent:
transport = httpx.HTTPTransport(ssl_context=httpx.create_ssl_context())
# Users might do this^, and expect eg SSLKEYLOGFILE to be enabled, but it won't...

# They'd need to pass an explicit `trust_env=True`...
transport = httpx.HTTPTransport(ssl_context=httpx.create_ssl_context(trust_env=True))

What Broke

Users may experience unexpected behavior with SSLKEYLOGFILE support disabled when using `create_ssl_context`.

Fix Options (Details)

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

Upgrade to version 0.17.0 or later.

When NOT to use: This fix should not be applied if the application relies on `trust_env=None` for specific behavior.

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

Fix reference: https://github.com/encode/httpx/pull/1447

First fixed release: 0.17.0

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 `trust_env=None` for specific behavior.

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.17.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 `trust_env` has diverging defaults between `Client` and `create_ssl_context` (Fix)