HMR and some /_next/static/ requests fail through a proxy

[PodkopovP]

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/admin-dashboard-ppp3f8

To Reproduce

1. Start the application in development
2. Import some Google Next/Font packages
3. Hit through a proxy (i.e. nginx)

Current vs. Expected behavior

When I hit my Next server through a proxy, my browser should be able to make requests to https://local.test.com/_next/static/media/S6u8w4BMUTPHh30AXC_qNiXg7Q-s.p.01183af7.woff2 for example, and recieve the resource - since 15.2.2, I receieve a 403 Unauthorized error. There are no console errors, and logging in middleware reveals that those errors don't actually even reach the middleware stage.

Using the --hostname flag to replicate my proxy domain, this does work as expected, however this will not work with a multi-tenant system where the proxy domain can be dynamic.

This can be tested quite easily on any Next app by testing using the following request headers in an API agent like Postman:

SUCCESS:

"Origin": "http://localhost:3025"

this is the port it's actually running on, so if I query the page directly without nginx, this is the origin that would be attached

SUCCESS:

"Origin": "http://localhost:1283189273981273981728397123"

just put a random port to see what would happen, and it works

FAILURE:

"Origin": "https://local.hello.com/"

Using a proxy, this is the origin that gets attached, and it fails

I also noticed that since 15.2.2, I have to explicitly set Origin to "" in my Nginx proxy when hitting /_next/webpack-hmr, or else my HMR also fails.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6030
  Available memory (MB): 18432
  Available CPU cores: 11
Binaries:
  Node: 22.9.0
  npm: 10.8.3
  Yarn: 4.1.1
  pnpm: 10.6.2
Relevant Packages:
  next: 15.2.2 // Latest available version is detected (15.2.2).
  eslint-config-next: 15.2.0
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Font (next/font)

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

I tested on 15.2.1, and it does work as expected without making any changes. Everything since, and including, 15.2.2, including canary versions, give said errors.

[PodkopovP]

After some digging, looks like this is the cause: #76880

[cemreinanc]

We're experiencing this issue as well.

We aren't using a proxy; instead, we resolve all *.localhost DNS queries to 127.0.0.1 to test tenant subdomains such as test.localhost, demo.localhost, etc.

Perhaps if allowedDevOrigins could accept wildcard domains, patterns, or regex, it would simplify configuration.

[tangye1234]

I use frpc to make my dev env to the public ssl nginx env, this issue is truely frustrating me.

[max-degterev]

We aren't using a proxy; instead, we resolve all *.localhost DNS queries to 127.0.0.1

this. bet multitenant demo is broken as well now. what was the last working version? will pin until this is maybe resolved

pin 15.2.1, regression was pushed with 15.2.2

[HenkVanMaanen]

can confirm. 15.2.1 works. 15.2.2 doesn't work.

[EgorKrasno]

Seems to still be broken in 15.2.3 for me even with the wildcard fix.

[max-degterev]

yes it's still broken, not sure why we'd want to block cross origin in dev environment at all actually

[cheeselemon]

Faced same issue, just tested 15.2.3.

Adding:

const config: NextConfig = {
  allowedDevOrigins: [
    "whatver.i.want"
  ],` 

at next.config.ts fixed the issue.

It seems still wildcard isn't allowed.

Note that experimental.allowedDevOrigins doesn't work.

[max-degterev]

neither option works, either pin the old version or don't use next/font