proxy.ts does not execute in production when behind Cloudflare Proxy (middleware.ts works)

Link to the code that reproduces this issue

https://github.com/shivaluma/report-bug-next16-proxy
https://github.com/shivaluma/report-bug-next16-proxy/tree/middleware

To Reproduce

To Reproduce

1. Create a new Next.js project (or use any existing Next.js 16.0.3 project):

npx create-next-app@latest

2. At the project root, create a file named middleware.ts:

// middleware.ts
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(req: NextRequest) {
  console.log("MIDDLEWARE RUNNING:", req.nextUrl.pathname);
  return NextResponse.next();
}

export const config = {
  matcher: ["/(.*)"],
};

3. Deploy the project behind Cloudflare Proxy enabled
   (Cloudflare orange-cloud ON → proxied traffic).

4. Visit any route (e.g., /).
   You will see the expected log output:
   MIDDLEWARE RUNNING: /

5. Now rename the file from middleware.ts → proxy.ts, and update the function name:

// proxy.ts
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function proxy(req: NextRequest) {
  console.log("PROXY RUNNING:", req.nextUrl.pathname);
  return NextResponse.next();
}

export const config = {
  matcher: ["/(.*)"],
};

6. Remove the old middleware.ts file.
   Ensure only proxy.ts exists in the project root.

7. Redeploy behind Cloudflare Proxy enabled.

8. Visit any route again.

---

Actual Result

• No logs appear.
• The proxy.ts file does not execute at all.
• Requests behave as if no middleware/proxy file exists.

Expected Result

proxy.ts should execute exactly like middleware.ts, with identical config and behavior, including when Cloudflare Proxy is turned on.

Configuration Usage:
output: "standalone"

Current vs. Expected behavior

Current Behavior

• When using middleware.ts, the middleware executes correctly in:

  • local development (next dev)
  • production
  • production behind Cloudflare Proxy (orange-cloud ON)

• After renaming the file to proxy.ts and changing the function name accordingly:

  • It still works in local development
  • It still works in production without Cloudflare Proxy
  • But it does NOT execute at all when deployed behind Cloudflare Proxy

There are no logs, no rewrites, no NextResponse behavior, and the file appears to be completely ignored when Cloudflare Proxy is enabled.
The only difference between the two scenarios is the file name (middleware.ts → proxy.ts).

---

Expected Behavior

• According to the deprecation message, proxy.ts should function as a drop-in replacement for middleware.ts.

• The same logic, same matcher, same runtime, and same root-level file should behave identically.

• Therefore, proxy.ts should execute in:

  • local development
  • production
  • production behind Cloudflare Proxy just like middleware.ts does.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.1.0: Mon Oct 20 19:34:05 PDT 2025; root:xnu-12377.41.6~2/RELEASE_ARM64_T6041
  Available memory (MB): 24576
  Available CPU cores: 12
Binaries:
  Node: 22.16.0
  npm: 11.4.2
  Yarn: N/A
  pnpm: 10.18.2
Relevant Packages:
  next: 16.0.2-canary.19 // Latest available version is detected (16.0.2-canary.19).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: standalone

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

Runtime

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

Other (Deployed)

Additional context

code with proxy.ts: https://github.com/shivaluma/report-bug-next16-proxy
code with middleware.ts: https://github.com/shivaluma/report-bug-next16-proxy

production application that running the code with proxy.ts: https://next16-proxy.shiro.fit
production application that running the code with middleware.ts: https://next16-middleware.shiro.fit

Visit two website, then open Devtools to see if the cookie "isGuest" successfully set.

Start with the linked reproduction repository and compare the root-level middleware.ts and proxy.ts cases using output: "standalone". Deploy both versions with and without Cloudflare Proxy enabled, then trace where proxy.ts is discovered or invoked. Done means proxy.ts runs behind Cloudflare and produces the expected logs and response behavior like middleware.ts.