How every claim on this site is verified

Which version a claim belongs to

A dev-server answer without a version is half an answer. Every page carries a "checked" date, and that date means: on that day the claim held for the release npm was then serving as latest. On 19 September 2026 that is 8.3.0, published on 10 September 2026. When a page says "the default is X", it is the default of that release, not of Vite in general.

$ npm view vite version
8.3.0

$ npm view vite time.8.3.0
2026-09-10T11:30:26.283Z

# the version a page was checked against, and when

Why the date does more work here than on most sites

Dev-server defaults move between major versions, and Vite has had four majors in under three years — 5.0.0 on 16 November 2023, 6.0.0 on 26 November 2024, 7.0.0 on 24 June 2025, 8.0.0 on 12 March 2026. A config copied from an answer written between two of those dates can be correct, obsolete or dangerous, and nothing in the snippet itself says which.

• The documentation itself dates some of its defaults: server.fs.strict is described as "Default: true (enabled by default since Vite 2.7)" — a release from December 2021, which is why older answers still show it as opt-in.
• server.hmr still exists, but its WebSocket options (protocol, host, port, path, clientPort, timeout, server) are deprecated in favour of server.ws. The docs state the two are synced automatically, so an old config keeps working and gives no signal that it is dated.
• The default for server.cors was tightened to localhost, 127.0.0.1 and ::1. An answer that predates that change will tell you the dev server already accepts your origin, and it will be wrong.

Three sources, always in this order

A claim is only written down after it has survived all three. If a step contradicts the one before it, the contradiction goes on the page instead of being smoothed over.

• The documentation on vite.dev, read on the version selector that matches the release in question — vite.dev keeps separate doc sets for Vite 2 through 7 next to the current one, so "the docs say" has to name which docs.
• The source at the release tag, not on main. A behaviour observed on main may not exist in any published release yet.
• A local reproduction: the error is produced on purpose on a clean project, and the terminal or browser output quoted on the page is the output that run produced. The error strings on these pages are copied, not paraphrased.

What happens when the docs and the source disagree

The source wins, and the page says so. One worked example from this site: /proxy-rewrite/ used to suggest that the DEBUG=vite:proxy line shows the rewritten path. Reading middlewares/proxy.ts at tag v8.3.0 on 17 September 2026 showed the opposite — in the HTTP path the debug call runs before the rewrite, so the line carries the URL as it arrived. In the WebSocket upgrade path the order is reversed. The page was corrected the same day.

// HTTP path: logged first, rewritten after
debug?.(`${req.url} -> ${opts.target || opts.forward}`)
if (opts.rewrite) {
  req.url = opts.rewrite(req.url!)
}

// upgrade path: rewritten first, logged after
if (opts.rewrite) {
  req.url = opts.rewrite(url)
}
debug?.(`${req.url} -> ws ${opts.target}`)

A security note is traced to an advisory, not to an opinion

Where a page calls a setting dangerous, there is a document behind it. The warning against server.allowedHosts: true is not a matter of taste — the Vite documentation points at GHSA-vg6x-rcgg-rjx6, which describes how a DNS rebinding attack reaches a dev server that answers any hostname. That is the reason the page gives, and the advisory ID is on the page so you can read it instead of trusting the sentence.

What is not verified here

The boundary matters as much as the method. These pages make no claims that cannot be checked in a terminal against a named release.

• No benchmarks. Startup and reload timings depend on the project, the disk and the operating system, and a number measured on one machine would not transfer.
• No plugin behaviour. A plugin can change what the dev server does at almost any point; only Vite itself is checked.
• No framework wrappers. Nuxt, SvelteKit, Astro and Remix run Vite but ship their own defaults, and their config file is theirs, not Vite’s.
• Nothing outside the dev server on 5173 — build output, environment variables and plugin authoring are other subjects, and this site does not cover them.

How a page changes after it is published

A page is edited when a new Vite release moves something it describes, when a reader shows that a claim does not reproduce, or when a re-read of the source contradicts it. The checked date is then set to the day of the new check, never left standing from the old one, and the sources list at the foot of the page names what was read. A page with an old date is not wrong — it means nothing has been re-checked since, and the release it names is the one it still speaks for.

Checked against Vite 8.3.0 — 2026-09-19
Sources: vite.dev/config/server-options, github.com/vitejs/vite (tag v8.3.0)

# no date on a claim means the claim is not finished

• Every server option that changes what localhost:5173 doesEverything the dev server on localhost:5173 does is configured under the server key in vite.config.js — twenty options, of which only host, port, strictPort, open and cors have a CLI flag; the rest exist in the config file only.
• Rewriting the path when the Vite proxy forwards a requestrewrite is called with req.url — the full path including the query string — and whatever it returns replaces req.url before the request is forwarded, so it has to come back as a path that still starts with a slash.
• 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.
• localhost:5173 — the port itselfWhat the address means, common dev ports, and the autocomplete fix.