# HTTP 525 errors via Cloudflare Worker

**URL:** <https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725>\
**Category:** General\
**Created:** [June 21, 2022, 6:37pm UTC](https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725 "2022-06-21T18:37:27Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![ian1](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/ian1/32/3620_2.png) [@ian1](https://community.fly.io/u/ian1)\
**Post date:** [June 21, 2022, 6:37pm UTC](https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725/1 "2022-06-21T18:37:27Z")

</div>

Hello,

We’re using a Cloudflare Worker to send requests to a `fly.dev` url. During periods of higher QPS (50-500), I am getting random intermittent 525s (as reported by `response.status` in the cf worker) up to ~1% of the time.

Removing `force_https` from `fly.toml` and hitting `http://x.fly.dev` seems to resolve the issue (all requests return 200s), but is not ideal. Perhaps we could handle TLS termination in-app, although I’d prefer not to do that either…

This is related to [Cloudflare 525 error randomly occurs](https://community.fly.io/t/cloudflare-525-error-randomly-occurs/1798) and [525 errors are back](https://community.fly.io/t/525-errors-are-back/962), but I’d highlight a couple things:

- This is not a health check or an “orange cloud” DNS proxy. It is a `fetch` request via Cloudflare Worker.
- I am using the `fly.dev` URL directly.
- It happens intermittently, not all the time, and only under relatively high QPS

Any ideas for how I can further troubleshoot this issue? Or any potential fixes/workarounds?

---

<div class="post-metadata">

**Author:** ![greg](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/greg/32/2119_2.png) [@greg](https://community.fly.io/u/greg)\
**Post date:** [June 21, 2022, 6:56pm UTC](https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725/2 "2022-06-21T18:56:32Z")

</div>

Hmm. Certainly appears to be TLS related, given removing https fixes it, and the 525 code directly relates to that too. Unlike e.g a 500 or 504 etc.

My first thought, given those numbers, would be it could be related to _this_:

> [@max concurrency can not be greater than 300](https://community.fly.io/t/max-concurrency-can-not-be-greater-than-300/5710/6):
>
> This is expected behavior — there’s concurrency limits on TLS handshakes (max concurrent handshakes per IP). You’ll need to spread your test across several IPs to make it look more like organic traffic to get meaningful numbers.

Since I know Workers re-use a single instance, unlike e.g Lambda where is only one instance handling each request. And so it would follow the requests are coming from the same IP. Not quite sure how to avoid that _other_ than handle TLS in-app to avoid any Fly-proxy restriction.

---

<div class="post-metadata">

**Author:** ![amos](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/amos/32/2036_2.png) [@amos](https://community.fly.io/u/amos)\
**Post date:** [June 21, 2022, 10:20pm UTC](https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725/3 "2022-06-21T22:20:15Z")

</div>

That would mean every fetch call from a worker does a separate TLS handshake? There’s no connection re-use / H2 multiplexing going on?

I’ll try to think of something we can do (that isn’t just raising the global limit).

---

<div class="post-metadata">

**Author:** ![greg](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/greg/32/2119_2.png) [@greg](https://community.fly.io/u/greg)\
**Post date:** [June 21, 2022, 10:55pm UTC](https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725/4 "2022-06-21T22:55:54Z")

</div>

I would have thought Cloudflare would re-use connections too. According to _this_ they do:

> Because Cloudflare reuses connections, the TLS handshake time is mostly mitigated, so there’s very little performance advantage to using HTTP rather than HTTPS to origin.

[https://community.cloudflare.com/t/2019-9-19-workers-runtime-release-notes-concurrent-subrequest-limit/115546/29](https://community.cloudflare.com/t/2019-9-19-workers-runtime-release-notes-concurrent-subrequest-limit/115546/29)

So perhaps their 525 is unrelated. It just seemed a good place to start looking.

---

<div class="post-metadata">

**Author:** ![amos](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/amos/32/2036_2.png) [@amos](https://community.fly.io/u/amos)\
**Post date:** [June 22, 2022, 8:31am UTC](https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725/5 "2022-06-22T08:31:37Z")

</div>

Would you happen to have some sample worker code I can set up myself to reproduce the issue? It might help speed up finding the root of the issue.

---

<div class="post-metadata">

**Author:** ![ignoramous](https://avatars.discourse-cdn.com/v4/letter/i/a9adbd/32.png) [@ignoramous](https://community.fly.io/u/ignoramous)\
**Post date:** [June 22, 2022, 11:30am UTC](https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725/6 "2022-06-22T11:30:27Z")

</div>

```auto
mkdir ./fly-workers
cd ./fly-workers
# install npm (via nvm, if you prefer) if required
# install the wrangler-cli
npm i wrangler
npx wrangler init
# open ./src/index.js, then

```

```javascript
async function origin(r) {
  console.debug("serving", r.url, "by", r.headers.get("CF-Connecting-IP"));
  return fetch(`https://fly.io/docs`);
}

export default {
  async fetch(request, env, ctx) {
    return origin(request);
  }
}

```

```auto
# generate auth token
npx wrangler login
# ensure `workers_dev = true` in wrangler.toml exists or add it; then:
npx wrangler publish

```

[docs](https://developers.cloudflare.com/workers/get-started/guide/), [examples](https://developers.cloudflare.com/workers/examples/).

---

<div class="post-metadata">

**Author:** ![vazexqi](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/vazexqi/32/13748_2.png) [@vazexqi](https://community.fly.io/u/vazexqi)\
**Post date:** [August 16, 2023, 8:10pm UTC](https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725/7 "2023-08-16T20:10:57Z")

</div>

@ian1 - Sorry for resurrecting this thread but this sounds exactly like the situation we are seeing as well. We too are making calls to the [fly.dev](http://fly.dev) instances from a Cloudflare Worker and seeing 525s randomly.

Did you ever find a solution for this?

---

<div class="post-metadata">

**Author:** ![ian1](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/ian1/32/3620_2.png) [@ian1](https://community.fly.io/u/ian1)\
**Post date:** [August 16, 2023, 8:23pm UTC](https://community.fly.io/t/http-525-errors-via-cloudflare-worker/5725/8 "2023-08-16T20:23:04Z")

</div>

Unfortunately not. We were forced to switched to `http` instead of `https`, which is not ideal.
