HTTPS proxy corrupts responses under high-concurrency module loading (Vite dev mode)

[awkannan]

Summary

The exe.dev HTTPS proxy corrupts or drops responses when a Vite dev server serves a large number of unbundled ES modules concurrently. The browser receives HTML error pages instead of JavaScript, causing NS_ERROR_CORRUPTED_CONTENT in Firefox and a blank page. This worked correctly on sprites.dev with the same project and configuration.

Environment

• VM: my.exe.xyz
• Proxy target: Caddy on port 8080, reverse-proxying to Vite dev server on port 5173
• Frontend: ~1,300 source files (React/TypeScript)
• A smaller frontend (~250 files) served the same way works fine

Steps to reproduce

1. Run a Vite dev server on a project with ~1,000+ source files
2. Put a reverse proxy (e.g., Caddy) in front on a port in the 3000–9999 range
3. Access via https://<vm>.exe.xyz:<port>/
4. Observe blank page

What happens

When the browser loads the page, it fires ~1,300 concurrent <script type="module"> requests (this is how Vite dev mode works — each source file is an individual ES module). A significant number of responses come back corrupted or as HTML error pages instead of JavaScript.

Firefox console shows:

GET https://my.exe.xyz/src/hooks/useFeatures.ts
NS_ERROR_CORRUPTED_CONTENT

GET https://my.exe.xyz/src/types/subfeature-lock.ts
NS_ERROR_CORRUPTED_CONTENT

Loading module from "https://my.exe.xyz/src/types/subfeature-lock.ts"
was blocked because of a disallowed MIME type ("text/html").

The text/html MIME type suggests the proxy is returning an HTML error page for some requests instead of forwarding the upstream JavaScript response.

Expected behavior

All module requests should be proxied faithfully to the upstream server, regardless of how many concurrent requests the browser makes. This is what the sprites.dev proxy did — the same project with the same Vite dev setup worked correctly there.

Workaround

Running vite build and serving the bundled output (a handful of static files instead of ~1,300 unbundled modules) works fine through the exe.dev proxy.

[awkannan]

Closing this - I think the issue was with my personal Caddy config.
I added

    servers {
        protocols h1 h2c
    }

to my Caddyfile to enable http/2 cleartext in my reverse proxy - then exe.dev's proxy was able to use HTTP/2 end to end, and vite dev mode worked.

[awkannan]

Reopening - the fix doesn't work consistently. A hard refresh typically causes some 503s to occur on module load, but you can get lucky on a non-hard refresh and the app will load.

On a normal refresh, it seems the browser cache may reduce the number of requests hitting the proxy.

This is with HTTP/2 enabled end-to-end, so there may be some issues with concurrency limits or backpressure handling