| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Next 16 defaults `next dev` to Turbopack, which serves its HMR websocket at /_next/hmr rather than the legacy webpack /_next/webpack-hmr. The template only upgraded the webpack path, so the Turbopack connection fell through to `location /` without upgrade headers and failed. Since Next 16.3 that failure aborts client hydration, leaving dev pages non-interactive. Match both paths with one regex block so HMR works under either bundler. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
LGTM 👍
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Problem
Next 16 defaults next dev to Turbopack, which serves its HMR websocket at /_next/hmr instead of the legacy webpack /_next/webpack-hmr. The nextjs proxy template only has an upgrade block for the webpack path, so the Turbopack connection falls through to location / (no Upgrade/Connection headers) and fails the WebSocket handshake.
Since Next 16.3 that failed connection is established during client bootstrap/hydration, and its failure aborts hydration — leaving dev pages non-interactive (e.g. login forms don't respond). It only affects local dev behind this proxy; production (next start) has no HMR and is unaffected.
Fix
Match both HMR paths with a single regex location, so it works under either bundler without duplicating the proxy directives:
A regex location outranks the location / prefix, so both paths still match here. ${NGINX_PROXY_PASS} has no URI part, so it's valid in a regex location.
Verification
Built the nextjs image with this change and ran a Next 16.3 (Turbopack) app behind it. The /_next/hmr websocket now completes the upgrade (HTTP 101), stays open, and receives Turbopack HMR messages (isrManifest, turbopack-connected). Login / interactivity restored. The legacy /_next/webpack-hmr path continues to upgrade for next dev --webpack.