[BUG] `next.config` rewrites result in request URL being rewrite destination

[arvinpoddar]

Describe the bug

When I have a rewrite rule in my next.config.ts with a destination to an API route, the request URL received by the API route is that of the destination. This is different behavior from the same app deployed on Vercel (or running the app locally), where the request URL received by the API route corresponds to the originally requested URL from the client.

Video demonstration:

demo.mp4

Steps to reproduce

Reproduction repo (this was used for the video above, and can be directly deployed to both Cloudflare and Vercel): https://github.com/arvinpoddar/cloudflare-rewrites-repro

Reproduction steps:

1. In your next.config.ts, create a rewrite rule that rewrites /about to /api/hello.
2. Create a /api/hello/route.ts, and console.log the incoming request URL.
3. Navigate to /about in your browser
4. When locally running the app, or when the app is deployed to Vercel, the logged request's URL path will be /about, which is the originally requested path.
5. When the same app is deployed to Cloudflare, the logged request's URL path will be /api/hello, which is the destination of the rewrite.

Expected behavior

I would expect the request URL to be that of the original client request, rather than the destination of the rewrite. This would be consistent with the app's behavior locally and on Vercel.

@opennextjs/cloudflare version

~1.0.0-beta.0 || ^1.0.0

Wrangler version

^4.13.2

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:23 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6020
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 21.6.1
  npm: 10.2.4
  Yarn: 1.22.22
  pnpm: 10.7.0
Relevant Packages:
  next: 15.3.1 // Latest available version is detected (15.3.1).
  eslint-config-next: 15.3.1
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.3
Next.js Config:
  output: N/A

Additional context

No response

[vicb]

@conico974 should I transfer this issue to the aws repo?

[conico974]

Yeah the issue should be fixed there

[jcbsfilho]

I'm also experiencing this issue and would be happy to help investigate or contribute to a solution.
Have any of you identified a possible direction for resolving this, or is there an ongoing discussion or idea on how it might be approached?