Intermittent 'No routes matched location' in remix app

I’m seeing intermittent ‘No routes matched location’ issues with a remix app.

Oddly, the site may load properly and then a few minutes later it fails to load assets associated with the page. In my logs I get an error message similar to the following:

May 15, 03:25:01 AM: ac38a4bf WARN No routes matched location "/build/entry.client-CPLICLLE.js"

After a few minutes, the site starts to load correctly again, without redeploying.

My site is at or

I’ve noticed that it may be happening on my domain name and not through the sub-domain. I’m managing my DNS through netlify name servers.

I’ve now noticed that when the site stops working correctly, it is requesting files with a different name:

e.g. When working:
When not working:

Am I looking at a caching issue?

If it helps, here are some x-nf-request-id’s for broken and working requests:




  • 01G34BSKX207RFM8N3TXX3JJZ4

Full source code is also available at GitHub - mward-sudo/scripthungry-netlify if it assists.

Thinking of moving back to Vercel if I can’t get this working, especially as Vercel works proper with stal-while-revalidate caching headers.

Heya @mward-sudo and sorry to be slow to get back to you!

You nailed it in your diagnosis: you had several different versions of your landing page in our CDN’s cache. How did this happen? Your function, which handles the route for / on your site, seesm to return this cache-control header (and did so as far back as the 14th, based on the age of the data in one node that I examined in depth)

Cache-Control: public, max-age=31536000, s-maxage=31536000

…which means that content would have (without my intervention, wherein I just deleted the entry from every CDN node manually), been stuck in cache for the next year as you’ve specified. This is obviously not what you want - so please, don’t do that again! Your function should return no cache-control response header unless you genuinely want it cached for the length specified, regardless of any new deploys you make (a new production deploy will clear all cache…except for functions or other proxy routes that have told us to hold on to em via a cache-control response header) - as long as you haven’t overridden our defaults as you did here).

Could you tell me if that was an intentional decision by you, and if so, what you were attempting to accomplish (and what you expected our system to do, given that directive?) This article explains why you should basically never need to adjust caching settings on our service:

1 Like

Our team is working hard to improve our remix integration, by the way - keep an eye on our blog for a post about remix + edge functions in the very near future!

Team working on it gave me two pieces of most-relevant advice to you:

  1. best way to start a remix project on Netlify today is to start from this template: npx create-remix@latest --template netlify/remix-edge-template

  2. in case you didn’t intentionally set that cache-control header yourself, this thread has some details that may help you adjust it: How to set cache-control for dataRequests per route? · Discussion #2442 · remix-run/remix · GitHub

Thankyou for your reply.

Yes, the cache-control header was deliberate. However, I had the expectation that the cache would be cleared upon deployment - clearly this was an incorrect understanding of the situation. I’ll be more more careful with setting the cache-control headers!

I set the headers as I was experiencing slow loads due to server side fetch requests and wanted to improve the situation. I’ll do some reading, take a look at the Netlify remix template and have a look at how to set things up properly for fast responses.

Very much appreciated.

1 Like

Out of interest, the starter template contains the following configuration in the netlify.toml file:

for = "/build/*"

"Cache-Control" = "public, max-age=31536000, s-maxage=31536000"

What effect does this have in comparison to setting the headers in the remix route files?

Hey there, @mward-sudo :wave:

Can you share the repo of the starter template you are using? This will help us look into the setup and answer your question. Thanks!

I’m using the netlify/remix-edge-template mentioned above.

I changed the netlify.toml before deployment to:

for = "/build/*"

cache-control = '''

I did this to avoid the risk of incorrectly caching and causing the same problem I was having previously. However, if this setting only affects assets, which are uniquely named on each deployment, then it might be better that I use the original value as specified in my previous post.

Hey there, @mward-sudo :wave:

Thanks for your patience here. I want to assure you we haven’t forgotten about you! We have shared this with a team that works directly with this template and will follow up here when we have more information. If anything changed in the past seven days, please let us know.

Hey @mward-sudo,

I believe the headers set by the starter template in netlify.toml work because those only apply to some static files that get generated during the build. Those files are hashed, so caching or not caching them would not make a huge difference.

But, when you added those headers inside your Remix stuff, I believe they also got applied to the serverless functions serving the content, and that’s what caused issues.

Brilliant, that is what I suspected.

Thank you very much for the assistance and information.

Hello! I need help with a similar issue. I deployed a simple app, trying to test the caching headers. For testing purposes I changed the headers to “private” and other values… now nothing works.

Could you help me how to exit this situation?

The error I’m looking at is: Error: No route matches URL “/.netlify/internal/ef-cache/”

The site repo: GitHub - mikocevar/remix-netlify-demo


@mikocevar, please check: /.netlify/internal/ef-cache/?

@hrishikesh Where and how?! Don’t tell im able to do that on your servers?


I see it’s a link, i will check that, I’m answering on mobile. :see_no_evil:

@hrishikesh the problem just went away, without me doing anything. Strange.

The webpage error suddenly changed from 404 to Application error, which was an issue on my side.

I guess there was a problem on Netlify?