fix: support X-Forwarded-* headers in proxy environments (#10928)

[UNILORN]

☕️ Reasoning

This PR restores X-Forwarded-Host and X-Forwarded-Proto header handling that was present in next-auth@4.24.13 but was lost during the migration to the current main branch architecture.

Problem

When running behind reverse proxies or load balancers (e.g., nginx, Vercel, Cloudflare), OAuth provider callback URLs are generated with internal hostnames instead of the public domain. This causes OAuth authentication to fail with "redirect_uri mismatch" errors.

In next-auth@4.24.13 , the toInternalRequest() function used detectOrigin() to extract the origin from X-Forwarded-* headers. This logic was removed in the refactoring to the current architecture, where toInternalRequest() directly uses new URL(req.url) without considering proxy headers.

Behavior

The fix only activates when one of the following conditions is met

• AUTH_URL is not set
• AUTH_TRUST_HOST=true is set
• Running on Vercel (VERCEL=1)
• Running on Cloudflare Pages (CF_PAGES=1)
• Development mode (NODE_ENV=development)

References

• Based on the implementation from next-auth@4.24.13: /packages/next-auth/src/utils/detect-origin.ts and /packages/next-auth/src/core/index.ts
• Documentation: https://authjs.dev/getting-started/deployment#auth_trust_host

🧢 Checklist

• Documentation
• Tests
• Ready to be merged

🎫 Affected issues

Fixes: #10928

📌 Resources

• Security guidelines
• Contributing guidelines
• Code of conduct
• Contributing to Open Source

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
auth-docs	Ready	Preview	Comment	Nov 15, 2025 11:50am

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
next-auth-docs	Ignored	Preview		Nov 15, 2025 11:50am

[vercel]

@UNILORN is attempting to deploy a commit to the authjs Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Broken Link Checker

1 broken links found. Links organised below by source page, or page where they were found.

1) /getting-started/migrate-to-better-auth

Target Link	Link Text
/docs	"documentation"

[UNILORN]

I have identified a workaround on the application side. Given this, the changes in this PR may not be required, so I am marking it as a draft for the time being.

[xzhayon]

I have identified a workaround on the application side. Given this, the changes in this PR may not be required, so I am marking it as a draft for the time being.

@UNILORN

Can you explain the workaround? Meanwhile, I've applied your patch and managed to make the redirect work.

[UNILORN]

@xzhayon

While testing on the application side, we observed the following behavior:

req.headers.get("x-forwarded-host") // 'example.com'
req.headers.get("x-forwarded-proto") // 'https'
req.headers.get("host") // 'example.com'
req.url // 'https://my-app-pod-1234:3000/api/auth/...'

After implementing a wrapper for the request in route.ts—as well as for the headers passed to NextAuth()—so that the correct x-forwarded-host value is used, the behavior became correct.

function wrapWithForwardedHost(req: NextRequest): NextRequest {
  const headersList = headers();
  const forwardedHost = headersList.get('x-forwarded-host');
  const forwardedProto = headersList.get('x-forwarded-proto');

  if (!forwardedHost || !forwardedProto) {
    return req;
  }

  const newHeaders = new Headers(req.headers);
  newHeaders.set('x-forwarded-host', forwardedHost);
  newHeaders.set('x-forwarded-proto', forwardedProto);

  const originalUrl = new URL(req.url);
  const protocol = forwardedProto.endsWith(':') ? forwardedProto : `${forwardedProto}:`;
  const correctedUrl = `${protocol}//${forwardedHost}${originalUrl.pathname}${originalUrl.search}`;

  return new Request(correctedUrl, {
    method: req.method,
    headers: newHeaders,
    body: req.body,
    // @ts-expect-error duplex is required for streaming request bodies
    duplex: 'half',
  }) as unknown as NextRequest;
}

export function GET(req: NextRequest) {
  return handlers.GET(wrapWithForwardedHost(req));
}

export function POST(req: NextRequest) {
  return handlers.POST(wrapWithForwardedHost(req));
}

The changes I pushed earlier include this logic implemented on the Auth.js side.

Could you please review this update and let me know if there are any issues?

I apologize for putting the PR back into draft status after you had already reviewed it, but I would appreciate it if you could review it once again.

[kirinse]

@xzhayon

While testing on the application side, we observed the following behavior:

req.headers.get("x-forwarded-host") // 'example.com'
req.headers.get("x-forwarded-proto") // 'https'
req.headers.get("host") // 'example.com'
req.url // 'https://my-app-pod-1234:3000/api/auth/...'

After implementing a wrapper for the request in route.ts—as well as for the headers passed to NextAuth()—so that the correct x-forwarded-host value is used, the behavior became correct.

function wrapWithForwardedHost(req: NextRequest): NextRequest {
  const headersList = headers();
  const forwardedHost = headersList.get('x-forwarded-host');
  const forwardedProto = headersList.get('x-forwarded-proto');

  if (!forwardedHost || !forwardedProto) {
    return req;
  }

  const newHeaders = new Headers(req.headers);
  newHeaders.set('x-forwarded-host', forwardedHost);
  newHeaders.set('x-forwarded-proto', forwardedProto);

  const originalUrl = new URL(req.url);
  const protocol = forwardedProto.endsWith(':') ? forwardedProto : `${forwardedProto}:`;
  const correctedUrl = `${protocol}//${forwardedHost}${originalUrl.pathname}${originalUrl.search}`;

  return new Request(correctedUrl, {
    method: req.method,
    headers: newHeaders,
    body: req.body,
    // @ts-expect-error duplex is required for streaming request bodies
    duplex: 'half',
  }) as unknown as NextRequest;
}

export function GET(req: NextRequest) {
  return handlers.GET(wrapWithForwardedHost(req));
}

export function POST(req: NextRequest) {
  return handlers.POST(wrapWithForwardedHost(req));
}

The changes I pushed earlier include this logic implemented on the Auth.js side.

Could you please review this update and let me know if there are any issues?

I apologize for putting the PR back into draft status after you had already reviewed it, but I would appreciate it if you could review it once again.

Hi, I applied your code to /app/auth/[...nextauth]/route.ts, observed dev tools, got this

ClientFetchError: Failed to execute 'json' on 'Response': Unexpected end of JSON input. Read more at https://errors.authjs.dev#autherror
    at fetchData (client.js:39:22)
    at async getSession (react.js:103:21)
    at async SessionProvider.useEffect [as _getSession] (react.js:251:43)

[UNILORN]

@kirinse
My apologies. I checked it again on my side, and I was able to reproduce the issue. I’ll apply a fix.

[shrey-metiz]

Any Updates regarding fixing this issue? I'm also facing same issue

[SogoKato]

@UNILORN @ThangHuuVu

What is the status of the review for this PR?
I am facing the same issue, so I reviewed the fix in this PR. Below is the method I used to verify the fix works. I hope it will be helpful.

1. Clone the repository

2. Create apps/dev/nextjs/.env.production

3. Add output: "standalone", to apps/dev/nextjs/next.config.js

4. Add !apps/dev/nextjs to .dockerignore

5. Create a Dockerfile with the following content:

   FROM nikolaik/python-nodejs:python3.13-nodejs22-slim AS builder
   RUN apt update && apt install -y build-essential
   WORKDIR /app
   
   COPY apps/dev/nextjs/package.json apps/dev/nextjs/
   COPY packages/ packages/
   COPY patches/ patches/
   COPY package.json pnpm-lock.yaml pnpm-workspace.yaml turbo.json ./
   RUN \
     corepack enable pnpm && \
     pnpm install && \
     pnpm build
   
   COPY apps/dev/nextjs/ apps/dev/nextjs/
   
   RUN \
     pnpm build:app
   
   FROM node:22-slim AS runner
   WORKDIR /app
   
   ENV NODE_ENV=production
   
   RUN addgroup --system --gid 1001 nodejs
   RUN adduser --system --uid 1001 nextjs
   
   COPY --from=builder --chown=nextjs:nodejs /app/apps/dev/nextjs/.next/   standalone ./
   COPY --from=builder --chown=nextjs:nodejs /app/apps/dev/nextjs/.next/   static ./apps/dev/nextjs/.next/static
   
   USER nextjs
   
   EXPOSE 3000
   
   ENV HOSTNAME="0.0.0.0"
   ENV PORT=3000
   
   CMD ["node", "apps/dev/nextjs/server.js"]

6. Create a compose.yaml with the following content:

   services:
     nginx:
       image: nginx:1.29.4
       ports:
         - 443:443
       volumes:
         - ./nginx/certs:/etc/nginx/certs
         - ./nginx/conf.d:/etc/nginx/conf.d
     app:
       build: .
       env_file:
         - apps/dev/nextjs/.env.production

7. Create a self-signed certificate:

   brew install mkcert
   brew install nss # if you use Firefox
   mkdir -p nginx/certs
   mkcert -install
   mkcert -cert-file nginx/certs/cert.pem -key-file nginx/certs/key.pem localhost

8. Create nginx/conf.d/default.conf with the following content:

   server {
       listen 443 ssl;
       server_name localhost;
   
       ssl_certificate /etc/nginx/certs/cert.pem;
       ssl_certificate_key /etc/nginx/certs/key.pem;
   
       location / {
           proxy_set_header Host $host;
           proxy_set_header X-Forwarded-Host $host;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_pass http://app:3000;
       }
   }
   

9. Run docker compose build and docker compose up

I verified that the fix works by testing both main and fix/10928 branches separately.