Intermittent TLS / Edge Routing Failure on Wildcard Subdomains (*.daneh.co)

Help
1

Hello Vercel Support,

We are experiencing an ongoing production issue affecting wildcard subdomains under *.daneh.co.

The issue is intermittent from a normal user perspective, but our investigation strongly indicates that it correlates with specific Vercel edge IPs serving the wildcard domain.

Affected URLs

Examples:

  • https://admin.daneh.co/login

  • https://elly-caramel.daneh.co/menu

  • https://elly-caramel.daneh.co/reserve

These routes are valid and work correctly when requests reach a healthy edge node.

Issue behavior

Some requests succeed normally with HTTP 200, while others time out before an HTTP response is returned.

The failure occurs during the TLS handshake, before our Next.js proxy/routing code executes.

This means the failure does not appear to originate from application routing, middleware/proxy logic, authentication, or caching.

Fresh reproduction — August 11, 2026

Testing:

https://elly-caramel.daneh.co/menu

Multiple normal requests resulted in:

  • HTTP status: 000

  • Connection timeout

  • No HTTP response returned

The same behavior occurs on:

https://elly-caramel.daneh.co/reserve

Per-IP isolation

We isolated the wildcard hostname against the IPs returned by Vercel DNS using curl --resolve.

Results:

  • 64.29.17.1 → HTTP 200 — healthy

  • 64.29.17.65 → TLS timeout

  • 216.198.79.1 → TLS timeout

  • 216.198.79.65 → TLS timeout

This behavior is reproducible independently of the application route.

We also forced:

admin.daneh.co

onto the failing IPs.

Results:

  • admin.daneh.co → 64.29.17.65 → timeout

  • admin.daneh.co → 216.198.79.65 → timeout

Therefore, this is not isolated to a particular tenant or route. The admin subdomain is affected by the same edge-node behavior when routed to one of the failing IPs.

TLS trace

On a failing IP, for example 216.198.79.65:

  1. TCP connection succeeds.

  2. TLS ClientHello is sent.

  3. ServerHello is received.

  4. TLS EncryptedExtensions begins.

  5. The connection then hangs.

  6. The request eventually times out.

No HTTP request reaches our application.

This is important because our Next.js proxy.ts cannot execute until TLS termination has completed.

DNS configuration

Our current Vercel DNS configuration includes:

  • www.daneh.co → dedicated CNAME to Vercel

  • daneh.co → dedicated Vercel apex record

  • *.daneh.co → wildcard ALIAS to Vercel

The wildcard currently points to:

cce884488e47e9b5.vercel-dns-017.com

admin.daneh.co does not have a separate DNS record and therefore uses the same wildcard resolution path as tenant subdomains such as elly-caramel.daneh.co.

Application-side investigation

We reviewed our current Next.js 16 proxy.ts implementation in full.

We confirmed:

  • Hostname extraction is correct.

  • Tenant subdomain parsing is correct.

  • Admin routing is explicitly handled before tenant routing.

  • /menu and /reserve routing is deterministic.

  • The proxy is synchronous and stateless.

  • No race condition or shared mutable state exists.

  • No recent routing change correlates with the start of this incident.

  • The middleware → proxy.ts migration occurred significantly before this issue began.

Most importantly, failing connections never complete TLS, so this code does not execute during the failure.

Successful request evidence

A successful request to:

https://admin.daneh.co/login

returned:

  • HTTP/2 200

  • x-vercel-cache: HIT

  • x-matched-path: /admin-portal/login

  • Example x-vercel-id:
    bom1::87hrh-1786422801319-66bdcff43308

This confirms the same application and routing work correctly when the request lands on a healthy edge path.

Working fallback

We previously implemented a fallback using the dedicated www domain:

  • https://www.daneh.co/elly-caramel/menu

  • https://www.daneh.co/elly-caramel/reserve

These routes continue to work reliably.

That further suggests the problem is specific to serving the wildcard *.daneh.co domain rather than the application itself.

Incident duration

We originally identified this issue around August 3, 2026.

Fresh testing on August 11, 2026 confirms that the issue is still present.

Therefore, this appears to be an unresolved production infrastructure issue rather than a temporary incident.

Request to Vercel

Could you please escalate this to the appropriate networking / edge infrastructure team and investigate:

  1. Why TLS termination succeeds on 64.29.17.1 but consistently hangs on the other wildcard-serving IPs listed above.

  2. Whether these IPs belong to different Vercel edge/anycast nodes or infrastructure pools.

  3. Whether there is a certificate propagation, TLS termination, SNI, wildcard-domain, or edge-network issue affecting *.daneh.co.

  4. Whether the wildcard domain can be moved/re-provisioned to a healthy edge configuration.

  5. Whether there are known incidents affecting this DNS target:

cce884488e47e9b5.vercel-dns-017.com

This is affecting production availability for both our admin portal and public customer-facing menu/reservation pages.

Please let us know if you need additional timestamps, packet-level traces, DNS output, curl -v logs, or further x-vercel-id samples.

Thank you.

2

Hi Hooman,

Your curl --resolve test is the strongest signal here. Since curl --resolve still sends SNI for the hostname, a consistent TLS hang on only some resolved IPs is much more useful evidence than a normal browser timeout.

I’d add one more compact set of outputs so this is easier for Vercel staff to compare healthy vs failing edge paths:

curl -v --http2 --connect-timeout 10 \
  --resolve elly-caramel.daneh.co:443:64.29.17.1 \
  https://elly-caramel.daneh.co/menu -o /dev/null

curl -v --http2 --connect-timeout 10 \
  --resolve elly-caramel.daneh.co:443:64.29.17.65 \
  https://elly-caramel.daneh.co/menu -o /dev/null

openssl s_client -connect 64.29.17.65:443 \
  -servername elly-caramel.daneh.co -brief -showcerts

I’d run the same pair for admin.daneh.co too, then include:

- timestamp with timezone
- client network / ISP / region
- hostname tested
- IP forced with --resolve
- whether ServerHello completes or hangs
- any successful x-vercel-id from the same hostname

One thing I’d still double-check is whether the wildcard domain is using Vercel nameservers at the registrar. Vercel’s domain troubleshooting docs say wildcard domains require the nameservers method so Vercel can handle DNS-01 certificate challenges automatically:

If dig NS daneh.co +short already shows Vercel nameservers and the Vercel dashboard shows the wildcard domain as valid, then I’d agree this does not look like something proxy.ts, middleware, caching, or app routing can fix. At that point the per-IP TLS traces plus timestamps are probably the right escalation packet.