On a Worker deployed to a Custom Domain, fetch() fails with HTTP 525 to certain origins. In the same request, to the same host, connect(..., {secureTransport: "on"}) completes a TLS handshake and returns a valid HTTP response. But a byte-identical script on *.workers.dev returns 200 just fine.
await fetch("https://github.com/") // throws HTTP 525
await connect({hostname:"github.com",port:443}, {secureTransport:"on"}) // returns 200Now I realise the outbound path for fetch requests on the edge likely lives outside this repo. I'm filing here because it's the only public tracker for the Workers runtime, this definitely occurs somewhere at runtime, and because I'm on a free plan and don't have any other way to report an actual bug.
What I tried
Across several third-party origins I tested, fetch returns 525 if the origin does not support the X25519MLKEM768 key agreement group:
| origin |
X25519MLKEM768 supported |
from workers.dev |
from custom domain |
| pypi.org, aws.amazon.com, www.sanity.io |
yes |
200 |
200 |
| github.com, api.stripe.com, sentry.io |
no |
200 |
525 |
| api.sanity.io, cdn.sanity.io |
no |
200 |
525 |
| raw.githubusercontent.com |
yes |
200 |
525 |
My zone has cache/origin_post_quantum_encryption = supported, which per the docs affects "all outbound connections from the zone […] including fetch() requests made by Workers on your zone". However I did try setting it to off, which didn't solve it either.
Conclusion
I assume there is some bug in the TLS handshake process that you introduced when enabling the post-quantum hardening, causing connections to origins without matching PQ key agreement groups to fail.
I appreciate the push for security, but would prefer to be able to make outbound requests to less secure origins.
Environment
- wrangler 4.123.0
- Compatibility Date: 2026-08-15
- no compat flags
- placement.mode: "off"
- colo FRA
- Zone has TLS set to full, Min TLS 1.0, and no Worker routes.
Failing rays (all FRA):
a2cfb2030d7fdc6aa2cfb204ff19dc6aa2cfb2053f6ddc6aa2cfb2059fcedc6a
On a Worker deployed to a Custom Domain,
fetch()fails with HTTP 525 to certain origins. In the same request, to the same host,connect(..., {secureTransport: "on"})completes a TLS handshake and returns a valid HTTP response. But a byte-identical script on *.workers.dev returns 200 just fine.Now I realise the outbound path for fetch requests on the edge likely lives outside this repo. I'm filing here because it's the only public tracker for the Workers runtime, this definitely occurs somewhere at runtime, and because I'm on a free plan and don't have any other way to report an actual bug.
What I tried
Across several third-party origins I tested, fetch returns 525 if the origin does not support the
X25519MLKEM768key agreement group:My zone has
cache/origin_post_quantum_encryption = supported, which per the docs affects "all outbound connections from the zone […] including fetch() requests made by Workers on your zone". However I did try setting it to off, which didn't solve it either.Conclusion
I assume there is some bug in the TLS handshake process that you introduced when enabling the post-quantum hardening, causing connections to origins without matching PQ key agreement groups to fail.
I appreciate the push for security, but would prefer to be able to make outbound requests to less secure origins.
Environment
Failing rays (all FRA):
a2cfb2030d7fdc6aa2cfb204ff19dc6aa2cfb2053f6ddc6aa2cfb2059fcedc6a