-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HMR does not work when using local reverse proxy via Docker/Caddy #6814
Comments
…st, not the ping host The problem with checking the ping host is that the ping host can pass, even if the socket host fails, leading to infinite reloads. Infinite reloads are a bad way to deal with this failure. This makes the failure less bad. For examples, see: vitejs#6814 vitejs#3093
i also have the HMR not work problem when use nginx proxy. My vite HMR websocket can connect, but page not refresh. |
As far as I can tell, the settings within
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 |
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. |
I tried the configuration above & got a
|
For me, it's working this one -> #7545 (comment) |
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:
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 |
…st, not the ping host The problem with checking the ping host is that the ping host can pass, even if the socket host fails, leading to infinite reloads. Infinite reloads are a bad way to deal with this failure. This makes the failure less bad. For examples, see: vitejs#6814 vitejs#3093
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:
Reproduction
https://github.com/JoinFreeWorld/StudentPortal/tree/jason/vite_attempt
System Info
Used Package Manager
npm
Logs
`client.ts:28 WebSocket connection to 'wss://app.notmyrealdomain.local/' failed: `
Validations
The text was updated successfully, but these errors were encountered: