Server Options | Vite

Dep Optimization Options
Unless noted, the options in this section are only applied to dev.
Specify which IP addresses the server should listen on. Set this to 0.0.0.0 or true to listen on all addresses, including LAN and public addresses.
This can be set via the CLI using --host 0.0.0.0 or --host.
There are cases when other servers might respond instead of Vite.
The first case is when localhost is used. Node.js's dns.setDefaultResultOrder changes how DNS-resolved addresses are ordered, and browsers may use a different resolved address than the one Vite is listening to. Vite prints the resolved address when it differs.
The second case is when wildcard hosts (e.g. 0.0.0.0) are used. This is because servers listening on non-wildcard hosts take priority over those listening on wildcard hosts.
Accessing the server on WSL2 from your LAN
When running Vite on WSL2, it is not sufficient to set host: true to access the server from your LAN. See the WSL document for more details.
The hostnames that Vite is allowed to respond to. localhost and domains under .localhost and all IP addresses are allowed by default. When using HTTPS, this check is skipped.
If a string starts with ., it will allow that hostname without the . and all subdomains under the hostname. For example, .example.com will allow example.com, foo.example.com, and foo.bar.example.com. If set to true, the server is allowed to respond to requests for any hosts.
Hosts that you have control over which IP addresses they resolve to are safe to add to the list of allowed hosts.
For example, if you own a domain vite.dev, you can add vite.dev and .vite.dev to the list. If you don't own that domain and you cannot trust the owner of that domain, you should not add it.
Especially, you should never add Top-Level Domains like .com to the list. This is because anyone can purchase a domain like example.com and control the IP address it resolves to.
Setting server.allowedHosts to true allows any website to send requests to your dev server through DNS rebinding attacks, allowing them to download your source code and content. We recommend always using an explicit list of allowed hosts. See GHSA-vg6x-rcgg-rjx6 for more details.
You can set the environment variable __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS to add additional allowed hosts. Use commas to separate multiple hosts (e.g., host1.example.com,host2.example.com).
Specify server port. Note if the port is already being used, Vite will automatically try the next available port so this may not be the actual port the server ends up listening on.
Set to true to exit if port is already in use, instead of automatically trying the next available port.
Enable TLS + HTTP/2. The value is an options object passed to https.createServer().
A valid certificate is needed. For a basic setup, you can add @vitejs/plugin-basic-ssl to the project plugins, which will automatically create and cache a self-signed certificate. But we recommend creating your own certificates.
Automatically open the app in the browser on server start. When the value is a string, it will be used as the URL's pathname. If you want to open the server in a specific browser you like, you can set the env process.env.BROWSER (e.g. firefox). You can also set process.env.BROWSER_ARGS to pass additional arguments (e.g. --incognito).
BROWSER and BROWSER_ARGS are also special environment variables you can set in the .env file to configure it. See the open package for more details.
Configure custom proxy rules for the dev server. Expects an object of { key: options } pairs. Any requests whose request path starts with that key will be proxied to the specified target. If the key starts with ^, it will be interpreted as a RegExp. The configure option can be used to access the proxy instance. If a request matches any of the configured proxy rules, the request won't be transformed by Vite.
Note that if you are using non-relative base, you must prefix each key with that base.
Extends http-proxy-3. Additional options are here.
In some cases, you might also want to configure the underlying dev server (e.g. to add custom middlewares to the internal connect app). In order to do that, you need to write your own plugin and use configureServer function.
Origin check for WebSockets
Vite does not check the origin of WebSocket requests before proxying. The proxy target is expected to check the Origin header or other checks. Note that the rewriteWsOrigin option will rewrite the origin to the target origin and will cause the origin check to be bypassed.
Configure CORS for the dev server. Pass an options object to fine tune the behavior or true to allow any origin.
Setting server.cors to true allows any website to send requests to your dev server and download your source code and content. We recommend always using an explicit list of allowed origins.
Specify server response headers.
Disable or configure HMR behavior.
Set server.hmr.overlay to false to disable the server error overlay.
The WebSocket-related options (protocol, host, port, path, clientPort, timeout, server) are deprecated. Use server.ws instead. These options are automatically synced, so existing configurations will continue to work.
Configure WebSocket connection options. Set to false to disable the WebSocket connection entirely.
When server.ws.server is defined, Vite will process the WebSocket connection requests through the provided server. If not in middleware mode, Vite will attempt to process WebSocket connection requests through the existing server. This can be helpful when using self-signed certificates or when you want to expose Vite over a network on a single port.
Check out vite-setup-catalogue for some examples.
With the default configuration, reverse proxies in front of Vite are expected to support proxying WebSocket. If the Vite HMR client fails to connect WebSocket, the client will fall back to connecting the WebSocket directly to the Vite HMR server bypassing the reverse proxies:
The error that ap