Project: daneh/boost-dashtboard (Hobby plan)

Affected domain: *.daneh.co (wildcard, correctly attached to the project per vercel domains inspect)

Example hostname: eat-test-cafe-wave1.daneh.co

Symptom

Real browsers get ERR_TIMED_OUT on tenant subdomains under our wildcard domain (root, /menu, /reserve - every path). Roughly 75% of connection attempts fail; the rest succeed. The apex domain (daneh.co) and www.daneh.co are 100% healthy on every attempt. This is currently blocking our production release.

I see a few similar-looking recent threads here (custom domain timing out while .vercel.app works) but wanted to post our specific evidence since our failure signature is slightly different - not a TCP-level failure, but a TLS handshake that starts and then hangs.

Root cause (isolated per-IP)

DNS for *.daneh.co round-robins across 4 edge IPs:

• 64.29.17.1
• • 64.29.17.65
  • • 216.198.79.1
    • • 216.198.79.65
    • Testing each individually with curl --resolve:
  • • 64.29.17.1: Healthy - HTTP 200/307 in ~0.8s, valid x-vercel-id header.
    • • 64.29.17.65: TLS handshake hangs after ServerHello, times out.
      • • 216.198.79.1: TLS handshake hangs after ServerHello, times out.
        • • 216.198.79.65: TLS handshake hangs after ServerHello, times out.
        • Confirmed independently with openssl s_client (not just curl)

      • Healthy IP

      • $ openssl s_client -connect 64.29.17.1:443 -servername eat-test-cafe-wave1.daneh.co -brief
      • CONNECTION ESTABLISHED
      • Protocol version: TLSv1.3
      • Peer certificate: CN=*.daneh.co
      • Verification: OK
      • DONE

    • Failing IP

    • $ openssl s_client -connect 64.29.17.65:443 -servername eat-test-cafe-wave1.daneh.co -brief
    • Connecting to 64.29.17.65
    • (hangs indefinitely, no further output)

• Ruled out

• Not tenant-specific: tested 7 distinct hostnames (including one that maps to no real tenant at all) - identical per-IP pass/fail pattern every time, meaning the failure happens before any app code or DNS-based routing logic runs.
• • Not a Preview-vs-Production issue: our Preview deployment (*.vercel.app) resolves to 64.29.17.67 / 216.198.79.67 - same address families as the wildcard pool, different specific IPs - and is 100% healthy.
  • • Not app/middleware: this codebase has no middleware.ts at all, and TLS terminates at the edge before any HTTP request reaches our app.
    • • Not DNS config: nameservers verified (ns1/ns2.vercel-dns.com), *.daneh.co correctly attached to the project, deployment status Ready.

    • Ask

  • Could someone from the Vercel team take a look at the edge nodes behind 64.29.17.65, 216.198.79.1, and 216.198.79.65 for *.daneh.co specifically? I tried opening a formal support case but Domains -> DNS Configuration and CDN -> Edge Network both require a paid plan on Hobby, so posting here instead. Happy to provide a full HAR file or run any additional diagnostics.