(Regression) Since v15.2.2-canary.3 The websocket HMR cannot connect when using a custom domain with ssl locally

[Enrico2]

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/github/vercel/next.js/tree/canary/examples/reproduction-template

To Reproduce

This is how I'm set up, I'm not sure if this is the minimal reproduction.

1. Point a custom domain to your home IP.
2. Port forward 13000 external -> 3000 internal
3. Run next dev with --experimental-https --experimental-https-key [privkey pem file] --experimental-https-cert [fullchain pem]
4. open yourdomain.com:13000
5. Look at the developer console:

WebSocket connection to 'wss://enricode.com:13000/_next/webpack-hmr' failed: 
(anonymous) @ use-websocket.ts:16
react-stack-bottom-frame @ react-dom-client.development.js:24035
runWithFiberInDEV @ react-dom-client.development.js:1510
commitHookEffectListMount @ react-dom-client.development.js:10514
commitHookPassiveMountEffects @ react-dom-client.development.js:10635
commitPassiveMountOnFiber @ react-dom-client.development.js:12441
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12557
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12557
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12557
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12557
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12557
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12557
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12434
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12444
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12434
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12434
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12557
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12434
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12434
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12557
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12557
recursivelyTraversePassiveMountEffects @ react-dom-client.development.js:12415
commitPassiveMountOnFiber @ react-dom-client.development.js:12453
flushPassiveEffects @ react-dom-client.development.js:15795
flushPendingEffects @ react-dom-client.development.js:15760
performSyncWorkOnRoot @ react-dom-client.development.js:16286
flushSyncWorkAcrossRoots_impl @ react-dom-client.development.js:16137
flushSpawnedWork @ react-dom-client.development.js:15664
commitRoot @ react-dom-client.development.js:15390
commitRootWhenReady @ react-dom-client.development.js:14643
performWorkOnRoot @ react-dom-client.development.js:14566
performWorkOnRootViaSchedulerTask @ react-dom-client.development.js:16274
performWorkUntilDeadline @ scheduler.development.js:45

Current vs. Expected behavior

The expected behavior is to not see an error. The current behavior is that HMR does not work.
This does not happen in 15.2.1, it does in 15.2.2 and 15.2.3.

Provide environment information

Mac OS, 15.3.1 
Mac Mini M4
Node 22.11.0
Latest Chrome

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

Not sure

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

next dev (local)

Additional context

v15.2.2-canary.2 is good
v15.2.2-canary.3 is bad

My first suspect would be #76960 given the reference to HMR.

[hathai25]

I'm hitting the same issue. The only difference is that I'm encounter using subdomains localhost

[jdfm]

I believe we're running into this as well. In our case we had set up a reverse-proxy that we run in tandem to a NextJS app. We listen on a custom domain we have set up locally, and have our reverse-proxy forward requests to the target endpoint that NextJS reports the dev server to be running. It was working fine for us up to v15.2.1 at least. We've also confirmed that this is still broken in v15.2.2 and v15.2.3.

Here's the error we see in our reverse-proxy app:

reverse-proxy:dev: Proxy Error: Error: Parse Error: Expected HTTP/
reverse-proxy:dev:     at Socket.socketOnData (node:_http_client:540:22)
reverse-proxy:dev:     at Socket.emit (node:events:519:28)
reverse-proxy:dev:     at addChunk (node:internal/streams/readable:559:12)
reverse-proxy:dev:     at readableAddChunkPushByteMode (node:internal/streams/readable:510:3)
reverse-proxy:dev:     at Readable.push (node:internal/streams/readable:390:5)
reverse-proxy:dev:     at TCP.onStreamRead (node:internal/stream_base_commons:191:23) {
reverse-proxy:dev:   bytesParsed: 0,
reverse-proxy:dev:   code: 'HPE_INVALID_CONSTANT',
reverse-proxy:dev:   reason: 'Expected HTTP/',
reverse-proxy:dev:   rawPacket: <Buffer 55 6e 61 75 74 68 6f 72 69 7a 65 64>
reverse-proxy:dev: }
reverse-proxy:dev: Unauthorized

The Unauthorized at the end is the output of doing console.log(Buffer.from('556e617574686f72697a6564', 'hex').toString('utf8')) which is the contents of the rawPacket field in the logs.

When we logged the request headers we noticed that it was failing on the following type of request:

reverse-proxy:dev: {
reverse-proxy:dev:   host: 'our.local.domain.com',
reverse-proxy:dev:   connection: 'Upgrade',
reverse-proxy:dev:   pragma: 'no-cache',
reverse-proxy:dev:   'cache-control': 'no-cache',
reverse-proxy:dev:   'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36',
reverse-proxy:dev:   upgrade: 'websocket',
reverse-proxy:dev:   origin: 'https://our.local.domain.com',
reverse-proxy:dev:   'sec-websocket-version': '13',
reverse-proxy:dev:   'accept-encoding': 'gzip, deflate, br, zstd',
reverse-proxy:dev:   'accept-language': 'en-US,en;q=0.9',
reverse-proxy:dev:   cookie: '<cookies-associated-to-our.local.domain.com>',
reverse-proxy:dev:   'sec-websocket-key': '<some-token-looking-thing>',
reverse-proxy:dev:   'sec-websocket-extensions': 'permessage-deflate; client_max_window_bits',
reverse-proxy:dev:   'x-forwarded-for': '::ffff:127.0.0.1',
reverse-proxy:dev:   'x-forwarded-port': '443',
reverse-proxy:dev:   'x-forwarded-proto': 'wss'
reverse-proxy:dev: }

All other requests that hit the reverse-proxy until that point had succeeded.

[pablorm296]

Hi there! We're running on the same issue when using a local proxy server with HTTPS. We use the aforementioned local proxy server to test auth-related functionality.

Here's the proxy server code:

const fs = require("fs");
const https = require("https");
const httpProxy = require("http-proxy");

// Read the certificate and private key files
const options = {
    cert: fs.readFileSync("certs/fullchain.pem"),
    key: fs.readFileSync("certs/privkey.pem"),
};

// Create a proxy server
const proxy = httpProxy.createProxyServer({
    secure: false, // Add this line to accept self-signed certificates
});

proxy.on("error", (err, req, res) => {
    // Are we in socket or HTTP mode?
    if (res.writeHead) {
        // HTTP mode
        res.writeHead(500, { "Content-Type": "text/plain" });
        res.end(`Something went wrong. And we are reporting a custom error message.`);
    } else {
        // Print information about the request that caused an error
        console.error(`Error for ${req.url}: ${err}`);
    }
});

// Create an HTTPS server
https
    .createServer(options, (req, res) => {
        // Proxy the traffic to localhost:3000
        proxy.web(req, res, { target: "http://localhost:3000" });
    })
    .listen(443, () => {
        console.log("HTTPS server listening on port 443");
    })
    // Add a request logs
    .on("request", (req, res) => {
        // Log the request method and URL with the response status code
        console.log(`${req.method} ${req.url} ${res.statusCode}`);
    })
    // Handle WebSocket connections
    .on("upgrade", function (req, socket, head) {
        proxy.ws(req, socket, head, { target: "http://localhost:3000" });
    });

Here's the error, very similar to the one shared by @jdfm

Error for /_next/webpack-hmr: Error: Parse Error: Expected HTTP/
Error: Parse Error: Expected HTTP/
    at Socket.socketOnData (node:_http_client:535:22)
    at Socket.emit (node:events:514:28)
    at addChunk (node:internal/streams/readable:376:12)
    at readableAddChunk (node:internal/streams/readable:349:9)
    at Readable.push (node:internal/streams/readable:286:10)
    at TCP.onStreamRead (node:internal/stream_base_commons:190:23) {
  bytesParsed: 0,
  code: 'HPE_INVALID_CONSTANT',
  reason: 'Expected HTTP/',
  rawPacket: <Buffer 55 6e 61 75 74 68 6f 72 69 7a 65 64>
}

[jdfm]

So, I was able to resolve my issue.

When I took a look at the changelog for https://github.com/vercel/next.js/releases/tag/v15.2.2-canary.3 I noticed the following line:

Add handling of origin in dev mode: #76880

Once I took a look at those changes I noticed https://github.com/vercel/next.js/pull/76880/files#diff-e31f611b3023a06db1bad10060bde3e34d53e3c41cc2f86c9e0d38e6938d8b53 and saw that the "Unauthorized" response was being returned here, so I thought to try and enable this allowedDevOrigins setting, and sure enough my reverse proxy started working again.

@Enrico2 @hathai25 @pablorm296 you all want to try this setting and report back if that solved your issue?

I had tried to use this setting originally before reporting my issue, but, mistakenly added the https:// bit in the entries, which prevented it from working properly.

This setting was still in the experimental category in v15.2.2, and was moved into the top level config in v15.2.3, please keep this in mind as you're testing things out. Also note that in v15.2.2-canary.3 the check against the origins might not support wildcards. Check the linked code to determine what your config should look like if you're testing against the canary version.

[hathai25]

@jdfm thanks! I believe as they stated in the docs, the wildcard options is available:

allowedDevOrigins: ['local-origin.dev', '*.local-origin.dev']

However it didn't work for me. I have to put each origin manually like this:

allowedDevOrigins: ['local-origin.dev', 'abc.local-origin.dev']

Also saw this PR already added in v15.2.3, but I don't think it's working

[Enrico2]

@jdfm nice! thanks, that worked for me. Also thanks on the tip to not include https:// -- I made the same mistake :D

[jdfm]

[...] I believe as they stated in the docs, the wildcard options is available

This is true for the latest version of NextJS (v15.2.3) but, in the linked code I posted above, it was performing a check based on equality, not on a regex or some other "expression"-like matching mechanism. Hence why wildcards wouldn't be working in some cases, it depends on the version you're using.

[hathai25]

This is true for the latest version of NextJS (v15.2.3) [...]

I'm on Next v15.2.3 actually, just checked their code. I think they actually has some logic to check for wildcard here but it's werid I still encounter this error.