HMR does not work when using local reverse proxy via Docker/Caddy

[rossPatton]

Describe the bug

I am using a custom https domain for local development, behind a caddyfile reverse proxy via Docker compose.

I navigate to https://app.mysite.local and it renders fine

However, the vite HMR websocket can't connect. So it reloads the page. Infinitely.

I know this isn't the first time this bug has been reported - I have read many, many of the related bug reports and nothing works. This is the only thing that keeps us from adopting vite. Every other bundler I have used can handle this (I assumed was common?) use case.

My config is below:

import tailwindcss from "@tailwindcss/jit";
import reactRefresh from "@vitejs/plugin-react-refresh";
import presetEnv from "postcss-preset-env";
import { defineConfig } from "vite";
import { VitePWA } from "vite-plugin-pwa";

export default defineConfig({
  server: {
    host: "0.0.0.0",
    origin: "https://app.domain.local",
    hmr: {
      host: "app.domain.local",
      port: 443,
      protocol: "wss",
    },
    port: 1234,
  },
  plugins: [
    reactRefresh(),
    VitePWA(),
  ],
  css: {
    postcss: {
      plugins: [
        tailwindcss,
        presetEnv({ stage: 1 }),
      ],
    },
  },
});

Reproduction

https://github.com/JoinFreeWorld/StudentPortal/tree/jason/vite_attempt

System Info

System:
    OS: macOS 12.0.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 2.99 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.0.0 - ~/.nvm/versions/node/v16.0.0/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v16.0.0/bin/yarn
    npm: 7.10.0 - ~/.nvm/versions/node/v16.0.0/bin/npm
  Browsers:
    Chrome: 98.0.4758.80
    Firefox: 96.0.1
    Safari: 15.1

Used Package Manager

npm

Logs

`client.ts:28 WebSocket connection to 'wss://app.notmyrealdomain.local/' failed: `

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[lzr900515]

i also have the HMR not work problem when use nginx proxy. My vite HMR websocket can connect, but page not refresh.
here is my discussions address: #6839

[routerino]

As far as I can tell, the port directive is being completely ignored. When using with svelte-kit and caddy reverse proxy:

settings within svelte.config.js:

	server: {
		hmr: {
			host: 'hs-ui.gurucomputing.com.au',
			protocol: 'wss',
			port: '443'
		}
	},

can't see any reason why the client will continue to try to connect on port 8080. The host is obviously being picked up, why not the port? Also tried with clientPort to no effect.

[MikeT117]

Seems to be a bug introduced in 2.9.0, you can lock to 2.8.6 as a temporary workaround.

[deathmaz]

Seems to be a bug introduced in 2.9.0, you can lock to 2.8.6 as a temporary workaround.

the bug was reported long before 2.9.0 was released.

The following works for me after update to 2.9.0:

  server: {
    host: '0.0.0.0',
    port: 80,
    strictPort: true,
    hmr: {
      clientPort: 443,
    },
  },

[MikeT117]

Seems to be a bug introduced in 2.9.0, you can lock to 2.8.6 as a temporary workaround.

the bug was reported long before 2.9.0 was released.

The following works for me after update to 2.9.0:

  server: {
    host: '0.0.0.0',
    port: 80,
    strictPort: true,
    hmr: {
      clientPort: 443,
    },
  },

I'd seen the previous reports but was unaffected, with 2.9.0 it started to affect me, your config due to binding to port 80 would require me to run with admin privileges, however it did lead to the discovery that adding 'strictPort' and setting to true fixed the original problem with no further changes necessary, so while the following produces the error in 2.9.0 (and works in 2.8.6):

server: {
  https: true,
  hmr: {
    host: "app.domain.com",
    port: 443,
    protocol: "wss",
  },
},

This does not produce the error ion 2.9.0:

server: {
  https: true,
  strictPort: true,
  hmr: {
    host: "app.domain.com",
    port: 443,
    protocol: "wss",
  },
},

The docs state strictPort: true will exit if the port is already in use rather than trying the next available port, I'm not entirely sure why adding that would fix this specific issue for me.

[btakita]

I tried the configuration above & got a Error: listen EACCES: permission denied 127.0.0.1:443

  vite v2.9.1 dev server running at:

  > Local: https://localhost:4003/
  > Network: use `--host` to expose

  ready in 369ms.

  > Inspect: https://localhost:4003/__inspect/

WebSocket server error:
Error: listen EACCES: permission denied 127.0.0.1:443
    at Server.setupListenHandle [as _listen2] (node:net:1355:21)
    at listenInCluster (node:net:1420:12)
    at GetAddrInfoReqWrap.doListen [as callback] (node:net:1559:7)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:74:8)
  > Routes:
     https://localhost:4003/
     https://localhost:4003/404/
     https://localhost:4003/companies/
     https://localhost:4003/rebalance/
     https://localhost:4003/companies/:company_locator/
     https://localhost:4003/rebalance/portfolios/
     https://localhost:4003/rebalance/portfolios/:portfolio_name/
     https://localhost:4003/rebalance/portfolios/new/
  > Server modules: https://localhost:4003/_m/*

[moisesbites]

For me, it's working this one -> #7545 (comment)

[rossPatton]

so every now and then I follow up on this and check to see if the issue has been addressed

i saw that in 2.9.0 this was supposedly addressed, but I have yet to be able to figure out a config that does the trick

vite documentation is still pretty lacking it seems for handling anything but the most basic case

has anyone found a configuration that:

• supports having a local caddy dockerfile reverse proxy (so http://localhost:3000 proxies to https://app.domain.local)
• does not endlessly force refresh the page because the websocket needs to reconnect

I've been able to get it so that if I go directly to https://app.domain.local:3000 things work, but that is not what I want to happen