localhost:5173/login: how the dev server answers app routes

What does the dev server do with /login?

A route like /login is not a file, so no static middleware answers it. Further down the chain, the HTML fallback middleware rewrites the request URL to /index.html, and the index.html middleware serves that file with the Vite client injected. Status 200, content type text/html, and the same document for every unknown path. Which component renders is decided afterwards by your router in the browser.

$ curl -s -o /dev/null -w "%{http_code} %{content_type}\n" http://localhost:5173/login
200 text/html

$ curl -s http://localhost:5173/login | grep -o "id=app>index"
id=app>index   # the contents of index.html

When does a path return an .html file instead of index.html?

Before falling back, the middleware checks for a matching HTML file in the project root, and the check depends on how the URL ends. A path ending in .html is served if the file exists. A path without extension is tried with .html appended. A path ending in a slash is tried with index.html appended. Only when none of these exists does the request fall back to the root index.html. The slash matters: /docs and /docs/ are different requests.

/about        -> about.html
/about.html   -> about.html
/docs/        -> docs/index.html
/docs         -> index.html   (no docs.html, so the SPA fallback wins)
/missing.html -> index.html   (file does not exist)

Why does the fallback not apply to every request?

The middleware only acts on GET and HEAD requests, never on the default favicon request /favicon.ico, and only if the Accept header is absent, empty, contains */* or contains text/html. A request that asks for application/json or image/png only, or a POST, passes through untouched and ends in the 404 handler. A browser address-bar navigation sends text/html, so it always qualifies.

$ curl -s -o /dev/null -w "%{http_code}\n" -H "Accept: text/html" http://localhost:5173/login
200
$ curl -s -o /dev/null -w "%{http_code}\n" -H "Accept: application/json" http://localhost:5173/login
404
$ curl -s -o /dev/null -w "%{http_code}\n" -X POST http://localhost:5173/login
404

Why does fetch("/api/users") return HTML with status 200?

A request without a special Accept header counts as */*, and */* qualifies for the fallback. If no proxy rule matches /api, the dev server therefore answers your API call with index.html and status 200 — response.ok is true, and response.json() then fails on the first "<". That is the usual reason for "Unexpected token <" in a project that has no backend running or no server.proxy entry. The same applies to a mistyped script path: an unknown .js URL requested with */* gets the HTML document, not a 404.

$ curl -s -o /dev/null -w "%{http_code} %{content_type}\n" -H "Accept: */*" http://localhost:5173/api/users
200 text/html
$ curl -s -o /dev/null -w "%{http_code} %{content_type}\n" -H "Accept: */*" http://localhost:5173/nofile.js
200 text/html

What changes with appType "mpa" or "custom"?

appType decides which middlewares exist. With "spa" (the default) Vite includes the HTML middlewares and the SPA fallback. With "mpa" it includes the HTML middlewares, but the fallback to index.html is switched off: /about and /docs/ still resolve to their files, while /login answers 404 with an empty body. With "custom" no HTML middleware is registered at all, and an unmatched path ends in the plain "Cannot GET /login" page — your own server is expected to answer HTML requests.

# appType: 'mpa'
$ curl -si http://localhost:5173/login
HTTP/1.1 404 Not Found
Content-Length: 0

# appType: 'custom'
$ curl -s http://localhost:5173/login
<pre>Cannot GET /login</pre>

A proxy rule is checked before the fallback

In the middleware chain, server.proxy sits ahead of the HTML fallback. A request whose path matches a proxy rule is forwarded to the backend and never reaches the fallback, so /api/users returns the backend’s answer once a rule for /api exists. Without a match, the fallback behaviour above applies. If a route that should be proxied still returns HTML, the rule did not match — see the proxy debugging page.

export default {
  server: {
    proxy: {
      '/api': 'http://localhost:3000'
    }
  }
}

With a base path, /login is a 404 and /app/login is the route

When base is set, for example to "/app/", the dev server only serves paths below it. Without the prefix, /login returns a 404 with a note about the public base URL; /app/login falls back to index.html as usual. A router configured with a different base than Vite produces exactly this split between the address bar and the server.

$ curl -s -o /dev/null -w "%{http_code}\n" http://localhost:5173/login
404
$ curl -s -o /dev/null -w "%{http_code}\n" http://localhost:5173/app/login
200

• How the Vite dev server handles requests to and from localhost:5173Three settings cover three different requests: server.proxy forwards a request from 5173 to your backend, server.cors decides which origins may read a response from 5173, and server.allowedHosts decides which hostnames may reach 5173 at all.
• localhost:5173 loads but the page stays blankA blank page on localhost:5173 is a dev-server problem only if the document request itself fails — a 404 with an empty body means Vite found no index.html in the project root — while a 200 with an empty page means a script failed in the browser, which Vite does not show in the terminal by default.
• 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.
• localhost:5173 — the port itselfWhat the address means, common dev ports, and the autocomplete fix.