nextjs - 💡(How to fix) Fix Request not instanceof NextRequest in proxy [4 comments, 3 participants]

nextjs2025-11-24 18:42:13

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.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

vercel/next.js#86481•Fetched 2026-04-08 02:10:43

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

subscribed ×5commented ×4issue_type_added ×1labeled ×1

Code Example

export default function proxy(request: NextRequest): any {
  console.log('-- Proxy --');
  
  // When running in the proxy, request is of type `Request`, not `NextRequest`
  console.log(`Is request instanceof Request: ${request instanceof Request}`); // true
  console.log(
    `Is request instanceof NextRequest: ${request instanceof NextRequest}`
  ); // false
  console.log(
    `Is request instanceof NextRequestHint: ${request instanceof NextRequestHint}`
  ); // false
  console.log(
    `Constructor name of request: ${request.constructor.name}`
  ); // NextRequestHint
}

---

-- Proxy --
Is request instanceof Request: true
Is request instanceof NextRequest: false
Is request instanceof NextRequestHint: false
Constructor name of request: NextRequestHint

---

export default function middleware(request: NextRequest): any {
  console.log('-- Middleware --');

  // When running in the proxy, request is of type `Request`, not `NextRequest`
  console.log(`Is request instanceof Request: ${request instanceof Request}`); // true
  console.log(
    `Is request instanceof NextRequest: ${request instanceof NextRequest}`
  ); // true
  console.log(
    `Is request instanceof NextRequestHint: ${request instanceof NextRequestHint}`
  ); // true
  console.log(
    `Constructor name of request: ${request.constructor.name}`
  ); // NextRequestHint
}

---

-- Middleware --
Is request instanceof Request: true
Is request instanceof NextRequest: true
Is request instanceof NextRequestHint: true
Constructor name of request: NextRequestHint

---

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Aug 11 21:16:34 PDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T6020
  Available memory (MB): 65536
  Available CPU cores: 12
Binaries:
  Node: 22.19.0
  npm: 11.6.0
  Yarn: 1.22.22
  pnpm: 9.0.0
Relevant Packages:
  next: 16.0.1
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.2
Next.js Config:
  output: N/A

RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/frederikprijck/nextjs-proxy-request

To Reproduce

Clone the repo: git clone [email protected]:frederikprijck/nextjs-proxy-request.git
Run pnpm install
Run pnpm dev
Open http://localhost:3000/ to see the proxy logs
Open http://localhost:3001/ to see the middleware logs

When inspecting the logs, you will see that in the proxy, the request is of type Request, while in the middleware, it is of type NextRequest.

Current vs. Expected behavior

I was looking at middleware to proxy migration and noticed some behavior that I was not sure if it was intentional, so I wanted to raise this to get your feedback on the behavior, or to bring it to your attention if this would be unexpected behavior.

In a proxy.ts file, we notice request is not an instanceof NextRequest:

export default function proxy(request: NextRequest): any {
  console.log('-- Proxy --');
  
  // When running in the proxy, request is of type `Request`, not `NextRequest`
  console.log(`Is request instanceof Request: ${request instanceof Request}`); // true
  console.log(
    `Is request instanceof NextRequest: ${request instanceof NextRequest}`
  ); // false
  console.log(
    `Is request instanceof NextRequestHint: ${request instanceof NextRequestHint}`
  ); // false
  console.log(
    `Constructor name of request: ${request.constructor.name}`
  ); // NextRequestHint
}

This gives me the following output:

-- Proxy --
Is request instanceof Request: true
Is request instanceof NextRequest: false
Is request instanceof NextRequestHint: false
Constructor name of request: NextRequestHint

If I compare this with middleware.ts:

export default function middleware(request: NextRequest): any {
  console.log('-- Middleware --');

  // When running in the proxy, request is of type `Request`, not `NextRequest`
  console.log(`Is request instanceof Request: ${request instanceof Request}`); // true
  console.log(
    `Is request instanceof NextRequest: ${request instanceof NextRequest}`
  ); // true
  console.log(
    `Is request instanceof NextRequestHint: ${request instanceof NextRequestHint}`
  ); // true
  console.log(
    `Constructor name of request: ${request.constructor.name}`
  ); // NextRequestHint
}

This gives me the following output:

-- Middleware --
Is request instanceof Request: true
Is request instanceof NextRequest: true
Is request instanceof NextRequestHint: true
Constructor name of request: NextRequestHint

As shown above, request is truly an instanceof NextRequest and NextRequestHint when using middleware.ts, but not when using proxy.ts.

However, typing request as Request loses access to things such as cookies, nextUrl etc which are actualy defined on the request instance, but only exist on NextRequest (or NextRequestHint).

I see many documentation indeed typing request as NextRequest in proxy.ts, but as NextRequest is not an interface, but a class, I wonder if that's actualy correct? It looks like it does contain the expected properties and methods as defined on NextRequest, but it doesn't look like a true NextRequest.

As mentioned, mostly curious to understand if this is expected behavior or not.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Aug 11 21:16:34 PDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T6020
  Available memory (MB): 65536
  Available CPU cores: 12
Binaries:
  Node: 22.19.0
  npm: 11.6.0
  Yarn: 1.22.22
  pnpm: 9.0.0
Relevant Packages:
  next: 16.0.1
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.2
Next.js Config:
  output: N/A

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

Middleware

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

next dev (local)

Additional context

No response

extent analysis

TL;DR

The issue can be addressed by using the NextRequest type for the request object in the proxy.ts file, despite it not being a direct instance of NextRequest, as it seems to contain the expected properties and methods.

Guidance

Verify that the request object in proxy.ts has the same properties and methods as NextRequest by logging or debugging its contents.
Consider using type guards or assertions to ensure the request object conforms to the NextRequest interface, even if it's not a direct instance.
Review the Next.js documentation and source code to understand how the request object is created and passed to middleware and proxy functions.
If possible, test the proxy.ts file with different request scenarios to ensure it behaves as expected with the NextRequest type.

Example

export default function proxy(request: NextRequest): any {
  console.log('-- Proxy --');
  
  // Use type guard to assert request conforms to NextRequest
  if ('cookies' in request && 'nextUrl' in request) {
    console.log('Request has expected NextRequest properties');
  } else {
    console.log('Request does not have expected NextRequest properties');
  }
}

Notes

The issue seems to be related to the differences in how the request object is created and passed to middleware and proxy functions in Next.js. The NextRequest type is a class, not an interface, which might be causing the confusion. However, as long as the request object has the expected properties and methods, using the NextRequest type should be sufficient.

Recommendation

Apply workaround by using type guards or assertions to ensure the request object conforms to the NextRequest interface, as shown in the example above. This should allow access to the expected properties and methods without causing type errors.

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?

#model save/load #optimization #mixed precision #training loop #device allocation

Still need to ship something?

×6

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

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

nextjs - 💡(How to fix) Fix Request not instanceof NextRequest in proxy [4 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Code Example

Link to the code that reproduces this issue

To Reproduce

Current vs. Expected behavior

Provide environment information

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

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

Additional context

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

TRENDING

nextjs - 💡(How to fix) Fix Request not instanceof NextRequest in proxy [4 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Code Example

Link to the code that reproduces this issue

To Reproduce

Current vs. Expected behavior

Provide environment information

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

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

Additional context

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

RELATED_DISCOVERY

TRENDING