[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live)

[Help](/c/help/9)

# Fix 401 Basic Auth Error on Vercel Preview Custom Domains

101 views · 0 likes · 3 posts


D Kilo (@dkilodesigns-3444) · 2026-01-08

Short summary (what's happening)
I have a preview deployment that should be public on [REDACTED_CUSTOM_DOMAIN], but the domain always returns HTTP 401 with WWW-Authenticate: Basic realm="Protected". App-level Basic Auth and middleware challenges have been disabled for preview, but the 401 persists. The response appears to come from Vercel's edge (header server: Vercel).

Current: Visiting https://[REDACTED_CUSTOM_DOMAIN] returns HTTP/2 401 with header WWW-Authenticate: Basic realm="Protected". This happens for plain GET, requests with x-vercel-protection-bypass (header and query param), and requests that include a _vercel_jwt cookie set via an interactive browser flow.
Expected: After removing app-level Basic Auth for preview and assigning the domain to the staging branch, requests to the custom domain should return the app (HTTP 200) or allow the bypass header/cookie to authenticate automated clients (LHCI, curl).

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
export function middleware(req: NextRequest) {
  // Basic Auth enforcement removed for preview
  return NextResponse.next()
}
export const config = { matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'] }

Preview host (internal): [REDACTED_PREVIEW_HOST] (READY)
Custom domain: [REDACTED_CUSTOM_DOMAIN] (recently removed + re-added and assigned to the staging branch)
Framework: Next.js 16 (webpack build in Vercel), rootDirectory: web/web
App-level settings: DISABLE_BASIC_AUTH=true set for Preview; app middleware modified to bypass Basic Auth in preview.
Bypass token: VERCEL_AUTOMATION_BYPASS_SECRET configured in project (value redacted)


Pauline P. Narvas (@pawlean) · 2026-01-08

Hey, @dkilodesigns-3444! Welcome!

Since you have `VERCEL_AUTOMATION_BYPASS_SECRET` configured, make sure you are using it properly:

* **Header**: `x-vercel-protection-bypass: <your-secret>`
* **Query param**: `?x-vercel-protection-bypass=<your-secret>`

From an app level, double-check that:

* `DISABLE_BASIC_AUTH=true` is set specifically for the **Preview** environment
* The environment variable is properly deployed to your preview deployment
* Your middleware is actually being bypassed (add some console logs to verify)

Feel free to also share the domain with us :slight_smile:

**Helpful resources:**

* [Vercel Protection Bypass Documentation](https://vercel.com/docs/security/deployment-protection#bypassing-deployment-protection)
* [Custom Domains Documentation](https://vercel.com/docs/projects/domains)


D Kilo (@dkilodesigns-3444) · 2026-01-10


Hi **[Pauline](https://community.vercel.com/u/pawlean)**


Thanks for the guidance. Per your suggestion I tested the \`VERCEL_AUTOMATION_BYPASS_SECRET\` flow against our preview domain \`staging.floai.studio\`. I have redacted secrets in the outputs below (replaced with \`\[REDACTED\]\`).

What I tested

\- Plain GET to root: returns 401 from Vercel edge with \`WWW-Authenticate: Basic realm="Protected"\`.

\- Header bypass: sent \`x-vercel-protection-bypass: \[REDACTED\]\` — still 401.

\- Query bypass: appended \`?x-vercel-protection-bypass=\[REDACTED\]\` — still 401.

\- Set-bypass-cookie URL: \`?x-vercel-set-bypass-cookie=true&x-vercel-protection-bypass=\[REDACTED\]\` — still 401; curl did not observe Set-Cookie.

\- \`/.well-known/vercel-user-meta\` — returns 204 (accessible), and responds to the bypass header.

Raw (redacted) outputs

\- Plain root

\`\`\`

HTTP/2 401

cache-control: public, max-age=0, must-revalidate

content-type: text/plain;charset=UTF-8

date: Sat, 10 Jan 2026 02:22:02 GMT

server: Vercel

strict-transport-security: max-age=63072000

www-authenticate: Basic realm="Protected"

x-vercel-id: cle1::gqfj9-1768011721322-46731c330208

Authentication required

\`\`\`
- Header bypass (secret redacted)

\`\`\`

HTTP/2 401

cache-control: public, max-age=0, must-revalidate

content-type: text/plain;charset=UTF-8

date: Sat, 10 Jan 2026 02:22:03 GMT

server: Vercel

strict-transport-security: max-age=63072000

www-authenticate: Basic realm="Protected"

x-vercel-id: cle1::t4zhq-1768011723086-042bac934166

Authentication required

\`\`\`

\- Query bypass (secret redacted)

\`\`\`

HTTP/2 401

cache-control: public, max-age=0, must-revalidate

content-type: text/plain;charset=UTF-8

date: Sat, 10 Jan 2026 02:22:04 GMT

server: Vercel

strict-transport-security: max-age=63072000

www-authenticate: Basic realm="Protected"

x-vercel-id: cle1::pzjlq-1768011723979-613fe7ff3820

Authentication required

\`\`\`
- Set-bypass-cookie attempt (secret redacted)

\`\`\`

HTTP/2 401

cache-control: public, max-age=0, must-revalidate

content-type: text/plain;charset=UTF-8

date: Sat, 10 Jan 2026 02:22:05 GMT

server: Vercel

strict-transport-security: max-age=63072000

www-authenticate: Basic realm="Protected"

x-vercel-id: cle1::zqhbw-1768011725559-fdf2aea9441d



Authentication required

\`\`\`

\- \`/.well-known/vercel-user-meta\` (plain)

\`\`\`

HTTP/2 204

cache-control: public, max-age=0, must-revalidate

date: Sat, 10 Jan 2026 02:22:25 GMT

server: Vercel

strict-transport-security: max-age=63072000

x-vercel-id: cle1::krgbx-1768011745894-2c4d5f42e1df

\`\`\`

\- \`/.well-known/vercel-user-meta\` (with bypass header)

\`\`\`

HTTP/2 204

cache-control: public, max-age=0, must-revalidate

date: Sat, 10 Jan 2026 02:22:28 GMT

server: Vercel

strict-transport-security: max-age=63072000

x-vercel-id: cle1::qc6gt-1768011748799-144e2ffa76a5

\`\`\`

Observations / questions

\- The root path continues to return 401 from Vercel edge even when sending the bypass header/query or requesting the set-bypass-cookie URL via curl.

\- The set-bypass-cookie flow did not return a Set-Cookie header to curl; this suggests the cookie-based bypass may require a browser context or interactive redirect to be issued.

\- \`/.well-known/vercel-user-meta\` is reachable and responds to the bypass header (204), so the edge SSO metadata endpoint appears active.

Thank you — happy to run any additional tests you recommend and provide timestamps/headers as needed.