521 Origin Down, on live worker but not on preview

I’m using fetch to do a post request to a http endpoint that use a custom port.

This works fine in the preview, but not on the live worker - it seems the worker doesn’t even connect to the server.

Is there some limits I’m unaware of?

You have a limit 50 sub-requests. Is the fetch endpoint an IP address?

1 Like

It’s a single request, nothing more than:

addEventListener('fetch', event => event.respondWith(
fetch("http://my.domain.com:3001/mypath", {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'X-Scope-OrgID': 'fake',
      },
      body: JSON.stringify(reqBody),
    });
)))

And not an IP.

1 Like

I Changed slightly the script, and is working on my side:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  let reqBody = {hello:'world'}

  await fetch("http://my.domain.com:3001/mypath", {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'X-Scope-OrgID': 'fake',
      },
      body: JSON.stringify(reqBody),
    });
  return new Response('hello world', {status: 200})
}

Yeah, the issue is still not the script, the same issue happens even if i use your exact script.

It works fine in worker preview, but not on the live worker.

I’ve tested the following now:

  • Doing a GET request towards port 80 and port 3001, this works fine on both!
  • Comparing the POST body, URI, headers on debug headers - it’s exactly the same in preview and live.

I’m suddenly not getting 521, but 404, not found…

When I load the script in preview, I can see that it gives 404 first and then when “context reset” comes up, then I get the proper 204 reply in preview.

Unfortunately, I don’t know what more i can debug now and it still doesn’t work on live worker.

It is just like fetch is doing GET instead of POST on the live worker, but not on preview…

Ah, it seems that it’s fetching the URI without the port - I’m getting the 404 from nginx (port 80) and not from the actual service running on port 3001.

I finally found the exact issue and it is a workers bug…

I’ll setup a nginx reverse proxy until it’s resolved…

EDIT: Yep, reverse proxy works just fine…