How the Vite dev server handles requests to and from localhost:5173

Three requests, three settings

• Your app on 5173 calls your backend — that is server.proxy.
• Something on another origin calls 5173 — that is server.cors.
• A request arrives under a hostname the server does not know — that is server.allowedHosts.

Read the error, not the guess

The three produce distinguishable errors, and the common mistake is to reach for CORS on all of them.

• Blocked by CORS policy, in the browser console — the response came back without the header the browser wanted.
• Blocked request. This host is not allowed. — a plain sentence from Vite, before your app ran.
• 404 or an HTML page where JSON was expected — the request was never forwarded; the dev server answered it itself.

The proxy is usually the right answer

Forwarding /api through the dev server makes the request same-origin, and a same-origin request has no CORS problem to solve. That is why the proxy replaces the CORS question instead of answering it — the browser never sees a cross-origin call in the first place.

export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

What cors allows by default

The default is not open and not closed. Vite allows localhost, 127.0.0.1 and [::1] — on any port, over http or https — and rejects everything else. A second dev server on another localhost port is therefore allowed without configuration. A staging hostname is not.

server.cors = {
  origin: /^https?:\/\/(?:(?:[^:]+\.)?localhost|127\.0\.0\.1|\[::1\])(?::\d+)?$/
}

Why the default got stricter

An open dev server lets any page you visit read the files it serves, including your source. Narrowing the default origin closed that. Snippets from before the change set cors to true, which puts it back — if you copy one, you are copying the problem it was tightened against.

allowedHosts is not about origins

It reads the Host header, not the Origin header, and it runs before anything else. A request can be perfectly acceptable under your CORS settings and still be rejected here, because the two look at different parts of the same request. Tunnels and custom local domains hit this first.

Deciding in one pass

• The call goes out to your own backend — proxy it, and stop there.
• The call comes in from a page you control on another origin — widen cors for that origin only.
• The request never gets that far and Vite answers with one sentence — add the hostname to allowedHosts.

• Proxying API requests from the Vite dev serverserver.proxy forwards any request whose path starts with a given prefix to another server, so the browser only ever talks to localhost:5173 and no CORS error appears.
• CORS errors around localhost:5173The Vite dev server only accepts cross-origin requests from localhost, 127.0.0.1 and ::1 by default — anything else has to be allowed explicitly, and setting cors to true opens it to every website.
• Blocked request. This host is not allowed.The Vite dev server only answers to localhost, hostnames ending in .localhost, and IP addresses — every other hostname has to be listed in server.allowedHosts.
• Reaching the Vite dev server from anything other than localhostThe Vite dev server binds to localhost only and rejects unknown hostnames, so a second device, a container or a tunnel needs two separate settings: server.host to bind wider, and server.allowedHosts to accept the name being used.
• localhost:5173 — the port itselfWhat the address means, common dev ports, and the autocomplete fix.