How to force absolute dev URLs when Vite HTML is re-served by a backend?

[functasti]

Hi,

In a Go backend dev setup, I’m fetching index.html from the Vite dev server and then serving it from a different origin (e.g. http://localhost:8080).

By default, the HTML returned by Vite includes root-relative paths like:

<script type="module" src="/@vite/client"></script>
<script type="module" src="/src/main.jsx"></script>

When this HTML is re-served from another origin, those paths resolve incorrectly.

Is there a supported way to make the dev server emit fully-qualified URLs (e.g. http://localhost:5173/@vite/client) in the injected HTML?

I’ve tried setting server.origin, but the returned HTML still contains root-relative paths.

Is this possible ?

Thanks!

[travisbreaks]

server.origin only affects asset URLs generated by plugins, not the core HTML transforms Vite injects (the /@vite/client script, /src/ imports).

Two approaches that actually work:

Reverse proxy (recommended)

Instead of fetching and re-serving the HTML, proxy Vite-related requests through your Go backend:

go
viteProxy := httputil.NewSingleHostReverseProxy(&url.URL{
Scheme: "http",
Host: "localhost:5173",
})

mux.Handle("/@vite/", viteProxy)
mux.Handle("/src/", viteProxy)
mux.Handle("/node_modules/", viteProxy)


The browser requests resolve against your backend origin, the proxy forwards them to Vite. No URL rewriting needed. This also handles WebSocket HMR connections, which also need to reach the Vite server.

String replace (quick and dirty)

If you need to keep the fetch-and-reserve pattern:

go
html = strings.ReplaceAll(html, "/@vite/client", "http://localhost:5173/@vite/client")
html = strings.ReplaceAll(html, "/src/, "http://localhost:5173/src/)


Not elegant, but predictable. You control exactly what gets rewritten.

The proxy approach is better long-term. It covers HMR, source maps, and any future Vite-injected paths you haven't anticipated.

[functasti]

Thanks for the response.

I need to inject my own state into the HTML, so I’m currently doing string replacement. It works fine, but my concern is indeed whether I’m actually covering all paths- specifically, whether I might be missing some dynamically generated requests created by Vite’s client-side code.

I also have a related question: after the HTML loads, are there certain updates (aside from directly editing the HTML itself) that would cause Vite’s HMR infrastructure to trigger a full page reload instead of a hot update?

[SX110903]

puedes configurar el base y el server.origin en vite.config para que genere las urls absolutas apuntando al servidor de vite:

// vite.config.ts
export default defineConfig({
  server: {
    origin: "http://localhost:5173",
  }
})

con eso el html que devuelve vite ya incluye la url completa en vez del path relativo, asi cuando tu backend de go sirve el html los scripts apuntan al sitio correcto. basicamente le dices a vite desde donde se van a cargar sus assets

[travisbreaks]

To answer your follow-up about HMR: yes, several things trigger a full reload instead of a hot update.

1. HTML file edits. You already know this one. Any change to an .html file causes a full reload since HTML isn't hot-replaceable.

2. Config file changes. Edits to vite.config.ts, tsconfig.json, .env files, or postcss.config.js restart the server entirely (not just a page reload).

3. Modules without HMR boundaries. If a changed module doesn't call import.meta.hot.accept() (or isn't wrapped by a framework plugin that does), the update "bubbles" up the import chain. If it reaches a module with no HMR handler, Vite falls back to a full reload. In practice: React/Vue/Svelte components are handled by their respective plugins, but utility modules, constants files, or anything imported by main.ts at the root will trigger full reloads.

4. CSS imported in JS without a framework plugin. Vite handles .css imports natively with HMR, but if your CSS pipeline involves PostCSS plugins that error or if the CSS is imported via a non-standard pattern, it can cause a reload.

5. Syntax errors during transform. If a file update produces a transform error (TypeScript error, JSX syntax issue), the HMR update fails. Once you fix the error, Vite sometimes can't recover gracefully and triggers a reload.

For your reverse-proxy setup specifically: HMR WebSocket connections also need to reach the Vite server. If you're proxying, make sure WebSocket upgrade requests to /__vite_hmr (or the configured server.hmr.path) are forwarded. If the WebSocket can't connect, the client falls back to full-page polling, which looks like repeated reloads.

// Make sure your Go proxy handles WebSocket upgrades for HMR
mux.Handle("/__vite_hmr", viteProxy)  // or use a wildcard

[chandrika1993]

server.origin is unfortunately not enough for this setup.

It helps with asset URLs generated by plugins, but it does not rewrite Vite’s core HTML injections such as:

<script type="module" src="/@vite/client"></script>
<script type="module" src="/src/main.jsx"></script>

So if you fetch index.html from Vite and then re-serve it from your Go backend on another origin, those root-relative paths still resolve against the backend origin and break.

Best solution: reverse proxy Vite through the backend

Instead of fetch-and-re-serve, proxy Vite dev requests through the Go server so the browser stays on one origin while Vite still serves its own dev resources.

At minimum proxy:

• /@vite/
• /src/
• /node_modules/
• HMR websocket path (/__vite_hmr or your configured server.hmr.path)

Example:

viteProxy := httputil.NewSingleHostReverseProxy(&url.URL{
	Scheme: "http",
	Host:   "localhost:5173",
})

mux.Handle("/@vite/", viteProxy)
mux.Handle("/src/", viteProxy)
mux.Handle("/node_modules/", viteProxy)
mux.Handle("/__vite_hmr", viteProxy)

Why proxying is the safest approach

It automatically keeps working for:

• Vite client injection
• module requests
• source maps
• HMR transport
• future injected paths

No manual HTML rewriting needed.

If you still need backend HTML injection

A safe pattern is:

1. Get Vite HTML
2. Inject only backend state / template data
3. Let proxied Vite paths continue serving modules

For example:

<script>
  window.__BOOTSTRAP__ = {...}
</script>

but do not try to own Vite’s module URLs manually unless necessary.

Fallback if proxying is not possible

Explicit string replacement works, but it is brittle:

html = strings.ReplaceAll(html, `"/@vite/client"`, `"http://localhost:5173/@vite/client"`)
html = strings.ReplaceAll(html, `"/src/`, `"http://localhost:5173/src/`)

This can break later if Vite changes injected paths.

About HMR / reload behavior

Even with proxying, some changes still trigger full reload instead of hot updates:

• .html changes
• vite.config.*
• .env*
• tsconfig.json
• modules without an HMR boundary

So occasional full reloads are expected.

Bottom line

For this architecture, reverse proxying Vite through the backend is currently the cleanest and most future-proof solution.