Issue Station
Sign In
Tools hereToolbox

nextjs - ✅(Solved) Fix Next.js 16: rewrite/proxy no longer works in production (500), but works in dev [2 pull requests, 22 comments, 6 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#87071•Fetched 2026-04-08 02:07:51
View on GitHub
Comments
22
Participants
6
Timeline
47
Reactions
0
Author
TheDanniCraftTheDanniCraft
Participants
gltched-usrgltched-usrgrmkrisgrmkrisim-anishrajim-anishrajivan-ltpivan-ltpripuserripuserTheDanniCraftTheDanniCraft
Timeline (top)
commented ×22mentioned ×9subscribed ×9labeled ×3

Error Message

  1. On prod build /js/script.file-downloads.hash.outbound-links.tagged-events.js returns HTTP 500 Internal Server Error

Fix Action

Fixed

PR fix notes

PR #87244: fix(next-server): fix rewrite proxy failure in standalone mode

Description (problem / solution / changelog)

Description

Fixes a regression where rewrites acting as proxies return 500 in standalone production builds due to tracing issues with dynamic requires.

Changes

  • Moved http-proxy require to top-level to ensure correct tracing in output: 'standalone'.
  • Added xfwd: true to support standard forwarded headers.

Fixes

Fixes #87071

Changed files

  • packages/next/src/server/lib/router-utils/proxy-request.ts (modified, +4/-2)

PR #87597: fix(proxy-request): prevent double compression by removing Accept-Encoding header

Description (problem / solution / changelog)

Description

Fixes an issue where rewrites acting as proxies can return 500 Internal Server Error when running Next.js behind a reverse proxy in standalone production builds.

The request is correctly received by Next.js, proxied upstream, and the upstream responds with 200, but the client still receives a 500 response when response compression is enabled.

I already documented this behavior in PR #87244. That PR aims to fix the same 500 error when using rewrites as proxies, but through a different approach.
The issue still reproduced in this setup.

This PR fixes the problem by explicitly removing the Accept-Encoding header on proxied requests, preventing double compression when running behind a reverse proxy.

https://github.com/vercel/next.js/pull/87244#issuecomment-3679683910

Research and Findings

During debugging, the following was observed:

  • The request consistently reaches the Next.js server and executes proxyRequest
  • The upstream responds successfully with status 200
  • The response fully completes inside Next.js
  • When running behind Traefik with compression enabled, clients receive 500
  • Removing Accept-Encoding or forcing identity resolves the issue

This strongly indicates a double compression or content encoding mismatch when multiple reverse proxies are involved.

Changes

  • Remove the Accept-Encoding header for proxied requests to prevent double compression
  • Keep proxy behavior otherwise unchanged

Fixes

Fixes #87071

Changed files

  • packages/next/src/server/lib/router-utils/proxy-request.ts (modified, +9/-0)

Code Example

const rewrites = await config.rewrites();
console.log(rewrites.find(r => r.source === "/js/script.file-downloads.hash.outbound-links.tagged-events.js"));

---

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
  Available memory (MB): 8035
  Available CPU cores: 8
Binaries:
  Node: 22.14.0
  npm: 11.4.2
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 16.0.8
  eslint-config-next: N/A
  react: 19.2.1
  react-dom: 19.2.1
  typescript: 5.9.3
Next.js Config:
  output: standalone
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/TheDanniCraft/clipify

To Reproduce

  1. Start the server in dev mode
  2. the URL /js/script.file-downloads.hash.outbound-links.tagged-events.js is correctly proxied to https://analytics.thedannicraft.de//js/script.file-downloads.hash.outbound-links.tagged-events.js
  3. Build (next build --webpack)
  4. Start (next start)
  5. On prod build /js/script.file-downloads.hash.outbound-links.tagged-events.js returns HTTP 500 Internal Server Error

Current vs. Expected behavior

Expected behavior (worked in next v15 before upgrading to next v16)

The rewrite should behave the same way in production as in development and proxy the file to: https://analytics.thedannicraft.de//js/script.file-downloads.hash.outbound-links.tagged-events.js

Actual behavior:

Dev mode: Works as expected Production build: Returns 500

I also verified the rewrite exists at build time by logging (when next config is parsed):

const rewrites = await config.rewrites();
console.log(rewrites.find(r => r.source === "/js/script.file-downloads.hash.outbound-links.tagged-events.js"));

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Pro
  Available memory (MB): 8035
  Available CPU cores: 8
Binaries:
  Node: 22.14.0
  npm: 11.4.2
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 16.0.8
  eslint-config-next: N/A
  react: 19.2.1
  react-dom: 19.2.1
  typescript: 5.9.3
Next.js Config:
  output: standalone

Which area(s) are affected? (Select all that apply)

Webpack, Output, Pages Router

Which stage(s) are affected? (Select all that apply)

next build (local), next start (local)

Additional context

No response

extent analysis

TL;DR

  • The issue can likely be resolved by adjusting the rewrite configuration in next.config.js to ensure compatibility with Next.js v16.

Guidance

  • Review the next.config.js file to ensure the rewrite rule for /js/script.file-downloads.hash.outbound-links.tagged-events.js is correctly configured for production builds.
  • Verify that the rewrites function in next.config.js returns the expected rewrite rules, including the one for the problematic URL.
  • Check the Next.js v16 documentation for any changes to rewrite configuration that may affect the current setup.
  • Test the rewrite rule in isolation to confirm it works as expected in development mode before applying it to the production build.

Example

  • No specific code example can be provided without the exact next.config.js content, but ensuring the rewrite rule is defined as follows might help:
module.exports = {
  //... other configurations
  async rewrites() {
    return [
      {
        source: '/js/script.file-downloads.hash.outbound-links.tagged-events.js',
        destination: 'https://analytics.thedannicraft.de//js/script.file-downloads.hash.outbound-links.tagged-events.js',
      },
    ];
  },
};

Notes

  • The issue seems to be related to changes in Next.js v16, so any solution should be verified against the documentation for this version.
  • Without the full next.config.js file, it's difficult to provide a precise fix, so reviewing the configuration and documentation is crucial.

Recommendation

  • Apply workaround: Adjust the rewrite configuration in next.config.js to ensure compatibility with Next.js v16, as the issue seems to stem from differences in how rewrites are handled between versions.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#task chaining#parallel task#integration issue#index setup#retrieval issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING