Client-side navigation error with rewrites and catch-all routes

[klaasman]

Link to the code that reproduces this issue

repository: https://github.com/klaasman/nextjs-rewrite-catchall-conflict

preview deployment: https://nextjs-rewrite-catchall-conflict.vercel.app/

To Reproduce

A routing precedence issue arises when URL rewrites conflict with catch-all routes during client-side navigation, but only when middleware exists AND the catch-all route has fallback: false AND the resource served by the proxied host returns a 2xx response.

To reproduce, either clone the repository and run it, or open the preview deployment at https://nextjs-rewrite-catchall-conflict.vercel.app, or follow the steps below:

1. Create a Next.js project (using pages-router, didn't test with app router)
2. Add a middleware.ts file (can be an empty function).
3. Add a catch-all route file pages/[...segments].tsx where getStaticPaths is configured with fallback: false.
4. Set up next.config.js rewrite rule to proxy incoming requests (using fallback rewrites)
5. Ensure the proxied endpoint (e.g., httpstat.us/200) returns a 2xx status code.
6. Navigate to /200 using client-side navigation (via Link component).

Current vs. Expected behavior

Current behavior:

During client-side navigation, the catch-all route takes precedence over the configured rewrite when the proxied endpoint returns a 2xx response. This results in incorrect routing behavior. (see preview-deployment)

Expected behavior:

The client-side navigation should follow the rewrite rule, correctly routing to the proxied endpoint regardless of the 2xx response. The catch-all route should not interfere with the rewrite when the endpoint returns a successful response.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 22.12.0
  npm: 10.9.0
  Yarn: 1.22.19
  pnpm: 9.14.2
Relevant Packages:
  next: 15.2.0-canary.11 // Latest available version is detected (15.2.0-canary.11).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A

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

Middleware, Pages Router, Navigation

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

next dev (local), next start (local), Vercel (Deployed)

Additional context

No response

[carbonrobot]

I think we are seeing this same behavior, using internal routes (and not proxy).

On client side navigation, the matched path when deployed to Vercel is the catch-all route. During local development, its the correct rewritten route.

Config

{
  source: "/insights/:slug",
  destination: "/article/insights/:slug"
},

Running on Vercel

x-matched-path: /[[...slug]].rsc
x-nextjs-rewritten-path: /article/insights/modernisation-de-risked

Expected (also works locally)

x-matched-path: /article/[[...slug]].rsc
x-nextjs-rewritten-path: /article/insights/modernisation-de-risked

Looking into the server code, this could be related to differences in routing between minimal mode and normal mode in the router, previously mentioned in #54854 and briefly suggested by this code comment.

ref: https://github.com/vercel/next.js/blob/1a41cbfc6e54d4657fe2b1e56bb7bf0684324278/packages/next/src/server/base-server.ts#L1094C1-L1099C12

// x-matched-path is the source of truth, it tells what page
// should be rendered because we don't process rewrites in minimalMode
let { pathname: matchedPath } = new URL(
  req.headers[MATCHED_PATH_HEADER] as string,
  'http://localhost'
)