vitejs
Feature Request: Support fallback to long polling when WebSocket is unavailable for HMR
Problem
I'm using Vite for frontend development in a special sandbox environment. There's a reverse proxy between the sandbox and users that doesn't support WebSocket connections. Since Vite's HMR relies solely on WebSocket without any fallback mechanism, users cannot see code changes in real-time when WebSocket is unavailable.
Use Case
This feature would be particularly useful for:
Development environments behind reverse proxies that don't support WebSocket Corporate networks with restrictive firewall policies Sandboxed or containerized development environments with limited protocol support Cloud-based IDEs or development platforms Alternatives Considered Currently, the only workaround is manual page refresh, which significantly degrades the development experience.
Additional Context
Similar tools like webpack-dev-server offer fallback options (sockjs) for HMR when WebSocket is unavailable. Having this capability in Vite would make it more robust in various network environments.
Suggested solution
Add support for falling back to long polling (or other HTTP-based alternatives) when WebSocket connections fail or are unavailable. This would ensure HMR functionality works in environments where WebSocket is blocked or unsupported.
Alternative
No response
Additional context
No response
Validations
- [x] Follow our Code of Conduct
- [x] Read the Contributing Guidelines.
- [x] Read the docs.
- [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
Thanks for raising this issue it highlights an important limitation in environments where WebSocket connections are unavailable.
If this is considered in scope, I’d be happy to take this on. Please let me know if it’s okay to assign the issue to me or if you’d prefer a draft PR.
@denghongcai please assign the issue to me if you are possible. I am willing to implement the feature asap.
@hsparks-codes Hi! I don't have the permission to assign issues to contributors. Would you like to go ahead and submit a PR for this? Feel free to reference this issue in your pull request.
@denghongcai don't bother. He's one of the many spam recently creating AI slop PRs ☹️
About the feature request, it sounds reasonable, but it's more to maintain for us and to also ensure it doesn't degrade the experience for existing users (e.g. we don't want to load many code if websockets is already supported). We may want to see if many other users would want this feature too before deciding.
At the meantime, maybe you can try a Vite plugin that overrides /@vite/client and inject/replace code through a transform hook to provide the different mechanism.
Don't blame if you don't assign me the issue @bluwy
On Sun, Dec 7, 2025 at 8:24 PM Bjorn Lu @.***> wrote:
bluwy left a comment (vitejs/vite#21155) https://github.com/vitejs/vite/issues/21155#issuecomment-3624083029
@denghongcai https://github.com/denghongcai don't bother. He's one of the many spam recently creating AI slop PRs ☹️
About the feature request, it sounds reasonable, but it's more to maintain for us and to also ensure it doesn't degrade the experience for existing users (e.g. we don't want to load many code if websockets is already supported). We may want to see if many other users would want this feature too before deciding.
At the meantime, maybe you can try a Vite plugin that overrides @.***/client and inject/replace code through a transform hook to provide the different mechanism.
— Reply to this email directly, view it on GitHub https://github.com/vitejs/vite/issues/21155#issuecomment-3624083029, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHYRGSLPYXGRAQUCLFRTTW34ATHLXAVCNFSM6AAAAACNESEIASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMRUGA4DGMBSHE . You are receiving this because you were mentioned.Message ID: @.***>