Page is giving 301 redirect when it shouldnt (Cached?)

We’re having an issue with a 301 redirect being served when it shouldn’t.

x-nf-request-id: ac325fd6-48cf-4c4a-ad76-b4a8482384d5-48863841

The version of the URL with .html works fine, but without the .html it is redirecting even though we have removed the relevant rules from the _redirects file.

Is there some sort of caching of 301 redirects, and if so, can we invalidate that cache?

On our branch deploys the same url works fine, (for example x-nf-request-id: 0f82060a-04c9-4b72-b761-7cac1f72f4c1-25462232)
which is why we think it might be some sort of caching issue.

Hey there!

As discussed in the mistargeted Helpdesk ticket, we’ll need you to reconsider using Cloudflare in front of Netlify because this is a known anti-pattern with our atomic deploys and caching configuration.

We weren’t using cloudflare at the time. I put cloudflare in after the fact to workaround the issue, so that we could redirect the non html url to the html url and bypass the errant 301 netlify was serving.

Appreciate that. However, we’ll not be able to debug with it in place. Proxying to us and having an active split test (as examples) are two of the ‘these can’t be in place’ things before our wider team will investigate a cache inconsistency.

That said, I tried purging your site’s cache earlier but this is ineffective when it’s cached elsewhere. Additionally, requests which we serve are all from the same deploy, 5f95a919f3e8830007fc868e.

I just turned off cloudflare proxying and the errant 301 redirect still was happening.

x-nf-request-id: 1a77f0e9-7dcc-4c90-962c-f0160fb933ab-102405

Unfortunately debugging things is going to be a bit awkward to test because the site in question is for a board game where you get a “secret” URL at a certain point when you win the game, so

  1. we don’t want the URL showing up in google results, so I’m hesitant to put in the actual URL in this conversation.

  2. The URL is printed on a physical card in the board game and we were getting dozens of users complaining about the redirect so we had to put in a hacky workaround with cloudflare even though, as you said, cloudflare ideally shouldn’t be used with netlify.

My hands are kind of tied because our workaround is working now and we can’t afford any downtime lest our customer support folks get hammered with angry users.

The problem persists though: without cloudflare redirecting to the url with ‘.html’ at the end, netlify is serving an incorrect 301 redirect to which shouldn’t be there. Neither the netlify.toml nor the _redirects file have such a redirect defined. They used to have such a redirect but it was removed on Saturday.

Something on netlify’s end has cached that 301 redirect which shouldn’t be there.


Doesn’t look like we’re able to ascertain the deploy ID from at request as it was non-organic (i.e. cURL UA, rather than a legitimate traffic source). We’d need a request-id from an organic browse to the site.

Therefore, I can’t check what rules are being applied :frowning:

I don’t want to leave you stuck in the mud… so, as a bit of a workaround/frig, have you considered a new redirect rule that’ll force the page to not redirect, with a rule like:

/the-url 200!

I have a similar issue. I deployed a redirect during temporary maintenance. The redirect was only up for a few hours but continues to be active.

I tried the redirect rule as suggested, but I get a Netlify 404 page.
from = “/the-url”
to = “
status = 200!

Here are some of the request ids for what I need cleared:
x-nf-request-id: cb52f33d-0f9e-4bb0-8db1-b4a649cf6fcd-1228529
x-nf-request-id: 8cf0e1c0-9c57-4997-b46e-d08101664c82-355205
x-nf-request-id: f9522112-19af-4fc5-bdc6-2b8b5f0dea7e-1325633

Ideally, we would like to be able to clear these out ourselves or dump any ‘cache’ or clear such items out ourselves.


Hi there,

Not seeing the redirect happening any more. Looks like this may have been aggressive browser caching?

Happy to look in further, especially if you have the real URLs to hand, your expectations and what’s happening.

I added the following line to package.json: "homepage": ".",, that seems to have resolved the issue.

Case against browser caching

  • redirect existed very briefly during a small maintenance window on Saturday
  • clearing browser cache does not resolve the issue
  • affects users who were not using the app while the redirect was active
  • redirect can reoccur, when previously had been working as expected

Here are some of the routes:, expectation is the page to load, with no 301 redirect, expectation is to make a proxy request to the api, with no 301 redirect

There are other affected routes, but I do not have more information on them at this time.

Interesting. There’s nothing astray and our CDN is serving the same deploy across all PoPs (both example routes above are 200-ing and all to the same, current deploy ID ending ddca).

Unfortunately, because of the proxy, I’m not able to grab the deploy IDs used back when this was occurring. But, for your last x-nf-request-id, f9522112-19af-4fc5-bdc6-2b8b5f0dea7e-1325633, this in fact was 200ing.