Edge routing bug: subdomain returns 307 to auth despite Valid Configuration

Help
1

Reporting an edge-routing bug where a newly-attached subdomain to my production Next.js 16 project intercepts requests at the edge PoP before they reach my deployment. Same production works correctly via other attached domains on the same project.

Setup:

  • Project: aamp_dashboard on Hobby plan (team: Guram’s projects)
  • Framework: Next.js 16 (App Router with src/app layout)
  • Subdomain added today: i.ankh.fit
  • DNS points at per-project target: 1818c1df62ef78e2.vercel-dns-017.com (verified via dig, propagated)
  • Vercel UI shows “Valid Configuration” · Let’s Encrypt cert provisioned
  • Attached to: Production environment (main branch)

Symptoms:

Direct deployment URL — works correctly:

$ curl -sI 'https://aampdashboard-6nwid8881-ankh-fit.vercel.app/i/test'
HTTP/2 302
location: https://ankh.fit/get?ref=test
x-matched-path: /i/[handle]
x-vercel-id: cdg1::lhr1::hmxkn-1784035521931-f266a737e321

Sibling subdomain dashboard.ankh.fit (same project, same production) — works correctly:

$ curl -sI 'https://dashboard.ankh.fit/i/test'
HTTP/2 302
location: https://ankh.fit/get?ref=test
x-matched-path: /i/[handle]
x-vercel-id: cdg1::lhr1::85dfn-1784035628564-76f37cba23b3

New subdomain i.ankh.fit — broken:

$ curl -sI 'https://i.ankh.fit/test'
HTTP/2 307
location: /auth/signin
x-vercel-id: cdg1::vltpm-1784041685734-fd199abbfe51

Key diagnostic:

Working responses have a 2-hop x-vercel-id pattern (cdg1::lhr1::... — Paris edge forwards to London deployment) and correctly set x-matched-path. Broken responses have a 1-hop x-vercel-id (cdg1:: only) with no x-matched-path — the request terminates at the cdg1 (Paris) PoP without reaching the deployment. Something in the edge routing table for i.ankh.fit at that PoP is stuck / misconfigured.

What I’ve tried (none resolved):

  1. Removed and re-added the domain in Vercel Domains twice
  2. Clicked Refresh multiple times
  3. Updated CNAME at Hover from generic cname.vercel-dns.com to the per-project target 1818c1df62ef78e2.vercel-dns-017.com per Vercel’s DNS recommendation
  4. Waited 15+ min for DNS propagation (fully propagated per dig)
  5. Pushed multiple empty commits to force fresh production builds
  6. Verified my proxy.ts middleware exempts /i/* correctly (works via other domains on same production)

Impact:

Blocking a UTM attribution redirect handler I need live before a launch-adjacent working session. Workaround in place using dashboard.ankh.fit/i/{handle}, but i.ankh.fit/{handle} is the intended production URL for influencer traffic.

Ask:

Anyone on the Vercel infra side able to force-invalidate the edge routing for i.ankh.fit at cdg1 (and other affected PoPs)? Happy to run additional diagnostics · thanks.

2

Hi Guram,

One thing I’d rule out before treating this as edge routing: the compared URLs are not the same path.

Working examples:

https://aampdashboard-6nwid8881-ankh-fit.vercel.app/i/test
https://dashboard.ankh.fit/i/test

Broken example:

https://i.ankh.fit/test

If your app only handles or exempts /i/*, then i.ankh.fit/test may be hitting your normal auth logic for /:handle or another protected route and returning /auth/signin. A 307 to /auth/signin sounds more like app proxy/auth behavior than Vercel’s domain routing layer.

I’d test these side by side:

curl -sI https://i.ankh.fit/i/test
curl -sI https://i.ankh.fit/test

If /i/test works on i.ankh.fit, then the domain alias is probably fine and you need a host-based rewrite for the short subdomain, something like:

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

export function proxy(req: NextRequest) {
  const url = req.nextUrl.clone()
  const host = req.headers.get("host")

  if (host === "i.ankh.fit" && !url.pathname.startsWith("/auth")) {
    url.pathname = `/i${url.pathname}`
    return NextResponse.rewrite(url)
  }

  return NextResponse.next()
}

The important part is that this rewrite needs to run before the auth guard that redirects to /auth/signin.

If https://i.ankh.fit/i/test also fails while the deployment URL and dashboard.ankh.fit/i/test work, then your edge-routing theory is much stronger. But I’d first rule out the /i/test vs /test path mismatch.