HMR behind a https proxy, docker, docs

[titpetric]

As soon as you put yarn dev or npm run dev behind a https proxy, it's impossible for vite to provide HMR due to a variety of implementation caveats and poor documentation. I could split this bug into several, but it's all HMR and it's confusing set of configuration options and fallbacks.

I'm using the vite (2.7.10) + vue-ts template to create a project.

Example 1:

hmr: false

Adding this option to vite.config.js does nothing, or at least nothing I can detect. The front-end still tries to connect to the vite websocket server for hmr, but on the default :3000 port.

Example 2:

hmr: { clientPort: 443 }

This makes the front-end code connect to the correct address, e.g. wss://domain instead of wss://domain:3000. No idea why it's being rejected. The javascript stack isn't useful (client.ts:28)

const socket = new WebSocket(`${socketProtocol}://${socketHost}`, 'vite-hmr')

client.ts:28 WebSocket connection to 'wss://domain.tld/' failed:
(anonymous) @ client.ts:28

Example 3:

Now, this is the most confusing, we have hmr.port and hmr.server.port. The hmr.server options lead me to believe that a separate server would be started if I provide e.g. hmr: { server: { port: 3001 } }. They don't seem to have any effect, only the main service comes online (:3000). It's all guesswork due to the very brief docs for the hmr json schema.

Digging around the code, a server is started if HTTPS options are provided. I don't need to provide HTTPS options as it's being terminated on my own edge servers, but it should be started in http mode too?

Other:

I think hmr.clientPort works, the client protocol is nicely autodetected to wss, there's just a connectivity issue and I can't figure out what.

I've tried returning an error code (404, 500, 502, 503) for /__vite_ping and thereby avoiding the constant reloading on the client, and it seems to be fully ignored by the front end client:

My suggestion would be to create a RFC, document HMR use cases e.g. vite.config.js for the following:

• running standalone on a local dev environment,
• running behind a https edge,
• running the app on one port e.g. :3000, hmr on a different one (:3001, :random)
• simply configure the client endpoint (e.g. wss://domain.tld)
• what is hmr.path, is it just a client-side change? Is it relevant? How?

I'm sorry if the frustration is coming out of the above text, I've spent a day to get this working without errors without success, and my best bet at resolving this is modifiying files in node_modules. When I'm frustrated, I rant. My suggestion would be to implement HMR, or at least the server/client and config part of it, by introducing a RFC process.

It's critical to document common use cases (e.g. standalone, docker, https), and provide better documentation than what exists for HMR currently, and examples to satisfy the above cases. There are a couple of PRs open, which could mitigate my issue. One of them is #6090 where I could disable this retry/refresh behavior, and just live without HMR. Is it great? No. Would I appreciate this being merged when this day started? YES.

Oh and additionally, if you enable middlewareMode, there's a bug along the lines of wsServer.on doesn't exists. I'm unsure what the point was, but if it was attaching an "upgrade" listener for websockets to the default server, it's probablly not passed correctly or something. I was tempted to modify this into wss.on('upgrade'... but it didn't work, apart from getting rid of the notice, it's been a no-op, like all of my work on this today.

If anybody is running HMR behind a third party https proxy (and not localhost/, along the lines of ngrok.io, or an nginx that's terminating SSL) - I'd be very interested in what you had to do to make it work. Some of my workaround attempts involved a nginx-proxy in front, which would route websocket requests to :3001 - before realizing that hmr.server.port has no effect.

[yonathan06]

I had the same issue, ended up using it with docker and ssl. The issue was that when creating the socket server over ssl it wasn't using the cert/key used by the express app. So using Vite server like this fixed the issue:

createServer({
  root: appDir,
  server: {
    https: {
      key: fs.readFileSync(pathToKey),
      cert: fs.readFileSync(pathToCert),
    },
    middlewareMode: "html"
  }
})

[titpetric]

I rather don't have the ssl keys available in the same environment, also why would it even need them, as the traffic between the edge :443 and the vite HTTP (not HTTPs) server on :3000? I don't think I ever solved it, I scrapped the prototype

[yonathan06]

I'm not sure, I struggled with it for a long time, having nginx at first proxing to a docker image, then removing the nginx and having the ssl listener in the node.js process (only for dev env), only after adding the above code the websocket managed to connect the server, not sure 100% why

[fortezhuo]

@yonathan06,

Thanks. your suggestion to config Vite Server solve HMR issue.

Disclaimer : this approach only for development only that needs https.
Instead using nginx, I create node http proxy with SSL key and cert.

const proxy = require("http-proxy")

proxy
  .createServer({
    xfwd: true,
    ws: true,
    target: {
      host: "0.0.0.0",
      port,
    },
    ssl: {
      key,
      cert,
    },
  })
  .listen(443, (err) => {
    if (err) {
      console.log(err)
    }

    console.log(
      `> Proxy Server ready from http://0.0.0.0:${port} >> https://0.0.0.0`,
    )
  })

• I use concurrently to run proxy server and my app server.
• No need to change vite.config.js

[zeitler]

Same issue. After lots of try's I was able to solve it.
Setup:

/etc/hosts:
127.0.0.1 local.dev.com

nginx in a docker container with ssl: (certificate created with vishnunair/docker-mkcert)
map $http_upgrade $connection_upgrade {
default Upgrade;
'' close;
}

upstream webapp-upstream{
server webapp:5555;
}

upstream wss-upstream{
server webapp:443;
}

server {
server_name local.dev.com;
client_max_body_size 2M;
listen 443 ssl;
ssl_certificate /certificates/local.dev.com.pem;
ssl_certificate_key /certificates/local.dev.com-key.pem;

location /socket.io{
proxy_pass http://wss-upstream;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
}

location /{
include /etc/nginx/proxy-config.conf;
proxy_pass http://webapp-upstream$uri$is_args$args;
}

And vite.config.ts
...
server: {
host: "0.0.0.0",
port: 5555,
proxy: {
'/socket.io': {
target: 'ws://localhost:5555',
ws: true
},
},
hmr: {
path: "/socket.io",
port: 443,
},
},
...
My problem was that I was reverse proxying to 5555 in nginx. But defining in vite.config.ts as 443, makes the ws listen in 443.

Hope it helps you

[mildrenben]

This worked for me!! Thank you so much

[masterkain]

this was working for me behind a local caddy reverse proxy to port 3000 that automatically provides ssl in development:

  server: {
    host: "0.0.0.0",
    port: 3000,
    hmr: {
      port: 443,
      clientPort: 443,
    },
  },

but I upgraded from vite 2.6.13 to 2.9.6 and now I get page reloads with wss connection failures, currently looking for a solution.

[adam-beck]

Any chance you have an example Caddyfile?

[masterkain]

I removed port: 443 and now it's working, hopefully it will help somebody else

[iacchus]

You don't need to change anything in the default vite.config.js just configure the proxy and websockets normally, check your browser inspector in a local install to inpect the Network/Websockets to see what the server does.

You don't need to proxy to /socket.io, remember that /socket.io is just after /, configure your proxy for / only, both the web and websockets, it can be on the same default port.

Fully functional apache reverse proxy

<VirtualHost *:80>
        ServerName my.site.org

        ServerAdmin webmaster@localhost

    RewriteEngine on
    RewriteCond %{SERVER_NAME} =my.site.org
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName my.site.org

        ServerAdmin webmaster@localhost

    <Location />
        # Require all granted #uncomment this
        # Require ip xxx.xxx.xxx.xxx
    </Location>

        # vue-vite is the my docker-compose host, use your local hostname or ip address
        ProxyPass / http://vue-vite:5173/
        ProxyPassReverse / http://vue-vite:5173/

        <Location />
        ProxyPass ws://vue-vite:5173/
        ProxyPassReverse ws://vue-vite:5173/
        </Location>

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

    SSLCertificateFile /etc/letsencrypt/live/my.site.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/my.site.org/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

EDIT: The relevant part, all you need to do is this, to configure the /:

# vue-vite is the my docker-compose host, use your local hostname or ip address

# HERE IS THE WEB:

ProxyPass / http://vue-vite:5173/
ProxyPassReverse / http://vue-vite:5173/

# HERE, THE WEBSOCKETS:

ProxyPass / ws://vue-vite:5173/
ProxyPassReverse / ws://vue-vite:5173/

[s-light]

thanks for your example.

i tried to reproduces this:
quasar.config.js

devServer: {
    // https: true
    port: 5091,
    // strictPort: true,
    // hmr: {
    //     port: 5091,
    //     host: "localhost",
    // },
    vueDevtools: true,
    open: false, // opens browser window automatically
},

my_ssl.conf

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName app.mytest.local:443
    Include /mypath/apache_config/mytest.local-ssl.conf
    
    ProxyPass           / http://127.0.0.1:5091/ retry=0
    ProxyPassReverse    / http://127.0.0.1:5091/
    ProxyPass           / ws://127.0.0.1:5091/ retry=0
    ProxyPassReverse    / ws://127.0.0.1:5091/

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

but i get
Firefox can’t establish a connection to the server at wss://app.mytest.local:5091/.
and reloads...

ok - that is fine - it should not try on wss://app.mytest.local:5091/
but should connect to wss://app.mytest.local/.

Version info

App Env:
Reported at............ 12/10/2022 12:37:19 PM
 » App dir................ /home/.../my_app
 » App URL................ http://localhost:5091/
                           http://192.168.188.75:5091/
 » Dev mode............... spa
 » Pkg quasar............. v2.10.2
 » Pkg @quasar/app-vite... v1.1.3
 » Browser target......... es2019|edge88|firefox78|chrome87|safari13.1

Apache:
Server version: Apache/2.4.54 (Ubuntu)
Server built:   2022-07-21T19:38:00

any ideas what is the source here? or what i have to look for?

[s-light]

after carefully rereading my config and post and some more experimentation i found a working solution:
quasar.config.js

devServer: {
    // https://github.com/vitejs/vite/discussions/6473
    https: false,
    port: 5091,
    strictPort: true,
    hmr: {
        clientPort: 443,
        port: 5091,
        host: "app.mis.local",
    },
    //
    vueDevtools: true,
    open: false, // opens browser window automatically
},

mytest_ssl.conf

# https://github.com/vitejs/vite/discussions/6473
<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName app.mytest.local:443
    Include /home/me/apache_config/mytest.local-ssl.conf
    # Encoded slashes need to be allowed
    AllowEncodedSlashes NoDecode
    # keep the host
    ProxyPreserveHost On
    # redirect to dev server
    ProxyPass           / http://127.0.0.1:5091/ retry=0
    ProxyPassReverse    / http://127.0.0.1:5091/
    ProxyPass           / ws://127.0.0.1:5091/ retry=0
    ProxyPassReverse    / ws://127.0.0.1:5091/

    ProxyRequests Off
    RewriteEngine on
    RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
    RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
    RewriteRule .* ws://127.0.0.1:5091%{REQUEST_URI} [P]



    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

also be sure to enable the ws tunnel plugins:
a2enmod proxy proxy_wstunnel

[nosachamos]

Here is the complete solution (web app on port 3001, nginx handing SSL, HMR on port 3004). I used zeitler's solution / post as a starting point:

In your vite.config:

    server: {
        host: "0.0.0.0",
        port: 3001,
        proxy: {
            '/socket.io': {
                target: 'ws://local.domain.com:3004',
                ws: true
            },
        },
        hmr: {
            path: "/socket.io",
            port: 3004,
            clientPort: 443,
        },
    },

As for nginx, add these configs to your nginx.conf:

http {
    map $http_upgrade $connection_upgrade {
        default Upgrade;
        '' close;
    }

    upstream wss-upstream {
        server host.docker.internal:3004;
    }

    server {
        server_name local.domain.com;

        listen 443 ssl;
        listen [::]:443 ssl;
        proxy_ssl_server_name on;

        ssl_certificate        ./.cert/cert.pem;
        ssl_certificate_key    ./.cert/key.pem;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;

        proxy_redirect          off;
        proxy_set_header        Host              $host;
        proxy_set_header        X-Real-IP         $remote_addr;
        proxy_set_header        X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;
        client_max_body_size    10m;
        client_body_buffer_size 128k;
        proxy_connect_timeout   90;
        proxy_send_timeout      90;
        proxy_read_timeout      90;
        proxy_buffers           32 4k;

        chunked_transfer_encoding on;

        location /socket.io {
            proxy_pass http://wss-upstream;
        }

        location / {
            proxy_pass http://host.docker.internal:3001;
        }
    }
}

You must then make sure that nginx can resolve host.docker.internal to your host's IP address. Easiest way is to add this to your docker compose service config:

services:
    proxy:
        image: nginx:alpine
        ...
        network_mode: host
        extra_hosts:
            - "host.docker.internal:host-gateway"

Or equivalent in docker if you don't use compose.

This is not trivial, took me more than an hour to figure this out - hope it helps someone out there.

[proxmdr]

No need to add extra hosts, you can use docker internal DNS resolve to either link 2 services or have them share a network… just a matter of using service name inside nginx file for desired service to rev.proxy it

[giovannimanzoni]

You save my life !! proxy configuration in vite was the solution. I wanted to refuse to try this configuration as well but incredibly it worked !

[austinkottke]

Life saver - thank you

[rrolla]

Here is traefik example, to get it working nuxt3 with vite and hot module replacement (hmr): https://github.com/nuxt/framework/issues/1796#issuecomment-1365911503

[letsaguiar]

If you're using nginx, you just need to enable websocket support by adding Upgrade and Connection headers to your proxy

location / {
            proxy_pass  http://vite-app:8080;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";

        }~

[CodeWithKyrian]

This did it for me. With this, no need to modify the vite config at all. Thanks for this!

[baterson]

Did for me as well, thanks brother

[AlanBreck]

Worked for me too!

[sbussard-inversemetric]

Hero!

[Zebnastien]

Same problem here: unable to use HMR through https proxy.

Easy step to reproduce:

• From a device with VSCode, start a remote tunnel (https proxy).
• From VSCode on another device, npm run dev your projet. Ports are auto-forwarded.
• Your project shows in browser fine, but about 10 seconds after, you see an "error fetching websocket" on the console.
• HMR does not work.

I tried every vite server / hmr / proxy / host settings without success. The same occurs from a remote docker.
We should not need a dedicated remote proxy in this situation.

[smolinari]

Thanks for at least posting this issue and also researching the possible solutions.

I have a remote dev setup with k8s, where my Vue+Vite app is inside a pod and I also have a special setup to be able to develop with VSCode remotely in it.

With k8s, the ingress system is basically a reverse proxy and I was having issues with Vite's HMR websocket connection. Your tip with hmr: { clientPort: 443 } fixed it for me. Now HMR is working for me as it should.

Again, thanks!

Scott

[zba]

May be good suggestion is to host docker server on http and just make some gateway container which cares about https, usually, you don't have https between microservices (your proxy +your frontend == microservices) to save energy.

[Maks027]

After hours of debugging, I found out that in my case the issue was that the reverse proxy was terminating the connection after 6 seconds (because there was no data exchange within 6 seconds) and this apparently the normal behaviour for Nginx

The documentation for Nginx states that:

By default, the connection will be closed if the proxied server does not transmit any data within 60 seconds.

https://nginx.org/en/docs/http/websocket.html?_ga=2.219808217.1349535884.1636598551-1257987705.1633943387

In the default configuration, 60s is enough for the client to start pinging the server, however, I am using APISIX as reverse proxy which set the default timeout of 6s so it disconnected well before the first ping.

In case that you notice that the websocket connects, but drops shortly after, check the timeout and increase it to 30-40s