HTTP 525 on outbound fetch()

I have a worker which makes an outbound HTTPS call using “fetch()” and it always fails with HTTP 525 if I trigger the worker through the DNS name (not via “”). The two questions I have are:

  • what is the cause?
  • how do I fix this?

I’ve found posts here in the Cloudflare Community as well as StackOverflow with a similar root problem, but the various suggestions have not solved the problem I’m seeing.

Here is a bit of worker code which reproduces the behavior:

export default {
  async fetch(
    request: Request,
    environment: Env,
    event: FetchEvent
  ): Promise<Response> {
    const url = '';
    const body = JSON.stringify({ abc: 'xyz' });
    const outboundRequest = new Request(url, {
      method: 'POST',
      headers: { 'content-type': 'application/json' },
    const response = await fetch(outboundRequest);
    console.log(`response status [${response.status}], response ${JSON.stringify(response)}`);
    return response;

If I publish that worker, curl the worker using the DNS name, and watch the logs, I’ll see things like this:

(log) response status [525], response {}

Here are some scenarios which result in 525:

  • HTTPS with POST
  • HTTPS with GET
  • changing “SSL/TLS encryption mode” from Flexible to Full
  • calling the worker through our DNS name
    GET - Ok @ 10/26/2022, 10:37:10 AM
      (log) response status [525], response {}
  • delete the worker, re-publish the worker

Here are scenarios which are ok (no 525):

  • running that worker locally (wrangler dev) works ok
  • copying that code to a new, different worker (in the same account+zone), works ok
  • changing from HTTPS to HTTP works ok
  • calling the worker through “”
    GET - Ok @ 10/26/2022, 10:36:53 AM
      (log) response status [200], response {}

This feels like either a configuration issue on my end, or possibly due to internal behavior of the Workers platform itself (per some comments in this StackOverflow post:

I opened a support ticket for this as well (if that ticket solves the issue first, I’ll post details here).


here are some of the community posts with similar problems, none of which has any clear resolution:

In the end, this was solved by making changes to DNS records which were in conflict with a worker route. Unfortunately there weren’t any good clues that lead to a solution, meaning there was a decent amount of trial and error. A support ticket connected with someone who pointed out how SSL for SaaS was involved, which helped isolate attention there as well as DNS.