Domain based i18n 500 page error redirects to default locale

Help
1

Recently, one of our sites is having some weird behavior. Without any changes to the 500.js file, the following error occurs when a page throws a 500 error.

Error: Cannot find module '/var/task/.next/server/pages/500.js'

This results in the .com site to redirect to the default locale (.nl) where it is able to show the proper 500 page. An example of a URL that behaves like this https://www.diamondsbyme.com/rings/classic-white-gold-emeralds-half-eternity-stackable-ring-tanisha/

When you visit this page, an external fetch throws an error, resulting in the page to error out. I expect it to show the 500 error message on the .com domain.

When I tried debugging it with sub route localization, it just works. https://dbm-com.vercel.app/en/rings/classic-white-gold-emeralds-half-eternity-stackable-ring-tanisha/

I’m using next@14.2.15 with pages router and trailingSlash option in the next config is on and localeDetection is off. We use a middleware to internally route the example URL to /product/[...slug] . The site is proxied through Cloudflare to cache JSON files and monitor bots.

Anybody have some troubleshooting steps?

2

Hey! I am Joe, nice to meet you

The error suggests that Next.js cannot find the 500.js file. Can you check the build output in .next/server/pages/ to ensure that the 500.js page is generated properly? Also, the redirection to .nl when an error occurs may point to an issue with the locale or how the domain routing is set up.
Let’s also ensure that your domain locale settings are correct in the Next.js config, and there are no unintended effects with locale fallback.

Are your Cloudflare logs for any requests to the .com domain resulting in 301/302 redirects, particularly around the 500 error pages?

3 Likes
3

HI Joe,

Thanks for replying.

The 500.js file does exist in the build output on the given path, as well as a JSON and HTML file in each locale folder. That is for a local build. The output folder in Vercel only has a 500 file for each locale folder.

image
image526×1240 57.8 KB

And this the i18n config.

  i18n: {
    locales:  ['en-gb', 'nl', 'nl-be', 'en', 'fr', 'de'],
    defaultLocale: 'nl',
    localeDetection: false,
    domains: [
      {
        domain: 'www.diamondsbyme.nl',
        defaultLocale: 'nl',
      },
      {
        domain: 'www.diamondsbyme.be',
        defaultLocale: 'nl-be',
      },
      {
        domain: 'www.diamondsbyme.de',
        defaultLocale: 'de',
      },
      {
        domain: 'www.diamondsbyme.fr',
        defaultLocale: 'fr',
      },
      {
        domain: 'www.diamondsbyme.com',
        defaultLocale: 'en',
      },
      {
        domain: 'www.diamondsbyme.co.uk',
        defaultLocale: 'en-gb',
      },
    ],
  }

Our Cloudflare logs have no 302 or 301 redirects that are linked to the 500 error page.

There is a chunk for _next/static/chunks/pages/500-[HASH].js which in my mind should be referenced in when rendering the error page instead.

4

Hi @gijsbotje
Apologies for the delayed response.

Given that the 500.js file is present in the Vercel output but still causing a missing module error, there could be possibly a routing or locale-specific issue affecting error page handling?

Since you’re using middleware to handle the /product/[...slug] routing, can you try logging its behavior during error scenarios? I wonder if the middleware is affecting locale-specific paths for the 500 page.

Also I assume, 500.js for en is served without any disturbance caused from custom routing rules.

Can you also check if any caching rules or edge functions on Cloudflare could be interfering with locale handling?

I totally understand how tiresome troubleshooting might be but it will all be totally worth it once we found the root cause!
Also, given that Vercel Team is so helpful, I believe they will be able to help us get to the root of this and make it work as expected!

Let me know if you have made some progress here!

1 Like
5

We are using the pages router and using i18n config. Our middleware does not use the locale to reroute or redirect requests.
Logging the errors locally works just fine.

The 500.js chunk is served properly: https://www.diamondsbyme.com/_next/static/chunks/pages/500-fb35dc0774e07ed3.js

We do not use Cloudflare workers or edge functions. We only cache the JSON files in Cloudflare.

I have a feeling it might be connected to my other issue: Domain routing i18n adds default locale to link href's

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.