Custom domain loses TLS after every production alias change

Summary

After each production deployment that re-points our custom domain, our-domain.com and www.our-domain.com stop serving TLS entirely for roughly 15-20 minutes. The edge accepts the TCP connection, then resets without sending a certificate. Plain HTTP on port 80 keeps working correctly the whole time, and the deployment's vercel.app URL is unaffected. This has now happened twice, both times immediately following a production alias change.

Environment: Team ID team_MtK7DZ6ep8LOJMR7BKxQUjxA; Project ID prj_c0s3rmIcErD18ED4EfFZXDXYb1bb; Domains our-domain.com (308 redirect to www) and www.our-domain.com; DNS is external, using GoDaddy nameservers; Framework Next.js (App Router), Node 24.x.

Symptom: curl against https://www.our-domain.com/login returns curl error 35, Recv failure, Connection was reset. openssl s_client against our domain on port 443 shows no peer certificate available, SSL handshake has read 0 bytes and written 1560 bytes. Meanwhile, in the same minute, curl against our vercel.app URL returns 200, and curl against the plain http version of our domain returns a 308 redirect to the https www URL. TCP to port 443 connects successfully (TcpTestSucceeded true). The failure is specifically that the edge sends 0 bytes and resets after the ClientHello.

Why this looks like a platform issue: Certificates exist and are valid, none expired, all set to auto-renew. The domains are attached and verified (verified true, misconfigured false, no conflicts). The deployment is healthy: deployment ID dpl_uDN9XFaBds7EoeFK37K4dWbbRnWo, readyState READY, readySubstate PROMOTED, aliasError null. A sibling domain on the same edge IPs, sibling-domain.com and a subdomain of it (same team, same anycast IPs, also external GoDaddy DNS), serves TLS perfectly throughout the outage. Forcing our SNI to every Vercel edge IP we could resolve reproduced the reset on all of them, so it looks SNI or domain specific rather than an unhealthy edge node. We reproduced this from two independent networks, ruling out local filtering. New certificate issuance succeeds (POST to the certs API returns 200), so the certificate simply is not being served by the edge.

Timeline: Incident 1 on 2026-07-20, the domain had been live and serving TLS after initial setup on 2026-07-19, then went down with the signature above. Re-issuing certs and re-verifying had no immediate effect. Detaching and re-adding both domains eventually set configVerifiedAt and TLS recovered roughly 15-20 minutes later. Incident 2 on 2026-07-21 (current), at 12:33:07Z we merged a PR to main, triggering the first git-driven production deploy (same deployment ID as above, aliasAssigned 1784637218431). TLS began resetting again immediately after the alias was assigned. This time configVerifiedAt was already set and unchanged, and no configuration was modified by us. Still down as of 12:41Z. The common factor across both incidents is a production alias change, not any config edit on our side.

Questions: Why does the edge fail to serve an existing, valid certificate for this domain after a production alias change, while a sibling domain on the same IPs is unaffected? Is this expected behavior for domains whose DNS points at vercel-dns-016.com targets, or is the cert-to-edge binding getting stuck? Is there anything about this domain's record (external GoDaddy nameservers) that makes it susceptible, and would moving DNS to Vercel nameservers avoid it? Is there a supported way to deploy without incurring this TLS gap?

A roughly 15-20 minute HTTPS outage on every production deploy is not viable, we are about to onboard pilot customers. Happy to provide additional logs, run diagnostics on request, or leave the domain in its failed state for inspection if that helps.

Note: I went through Vercel's in-app support assistant first, which analyzed the domain and certificate configuration, agreed this doesn't look like a configuration issue on our end, and pointed me here to Community since direct support cases for Domains and SSL aren't available on the Hobby plan. Domain names above have been replaced with placeholders for privacy; happy to share the real ones with a Vercel team member via DM if needed to investigate.

Leaderboard Winner

Hi Ddrake,

Your evidence points past the usual DNS/certificate checklist. The key part is that HTTP keeps reaching Vercel, the .vercel.app deployment works, certificates exist, and the failure is SNI-specific: TCP connects on 443, then the edge resets before serving any certificate for only that hostname.

I would not assume moving nameservers to Vercel is the durable fix unless Vercel specifically confirms it. For normal non-wildcard domains, the important part is that the domain resolves to Vercel and the HTTP-01 challenge can reach Vercel. What you are describing sounds different: certificate issuance succeeds, but the cert is not being served immediately after the production alias changes.

I’d keep the domain in the failed state if it happens again and capture the before/after in one compact set:

date -u
dig A your-domain.com +short
dig CNAME www.your-domain.com +short
curl -I http://www.your-domain.com/
openssl s_client -connect www.your-domain.com:443 -servername www.your-domain.com -brief
curl -I https://your-vercel-app-url.vercel.app/
vercel alias ls --limit 100
vercel certs ls

The most useful escalation details are probably:

UTC time of alias assignment:
Deployment ID:
Custom domain:
Failing x-vercel-id from HTTP, if available:
openssl output showing no peer certificate:
Alias list showing the domain assigned to the ready deployment:
Sibling domain on same team/IPs working at the same time:

I’d avoid detaching/re-adding the domain again unless you need to restore service, because that changes the state Vercel would need to inspect. As a temporary operational workaround for customer onboarding, you may want to deploy behind a separate staging domain first, verify it, and only promote/alias during a planned window until the cert-to-edge binding issue is understood.

Thank you — this was useful and your read of it matches what I'm seeing.

I captured the escalation set you suggested. Two details that I think sharpen it:

The domain is correctly aliased to a healthy, ready deployment, and TLS still fails. Both domain and the apex are aliased to a deployment that is READY / PROMOTED with aliasError: null, and a valid certificate covering both names exists (autoRenew: true, expires in ~3 months). The edge still resets with no peer certificate available / SSL handshake has read 0 bytes and written 1560 bytes.
The failing HTTPS request never reaches a deployment. curl -I http:/// returns the 308 with server: Vercel but no x-vercel-id header, whereas the working *.vercel.app URL returns x-vercel-id: pdx1::iad1::.... So the reset is happening at the TLS-termination layer, before routing.

I also tried your instinct about not trusting the DNS move: I repointed from the vercel-dns-016 target to the rank-2 cname.vercel-dns.com target. After propagation the hostname resolved to an entirely different IP range and still reset — so the failure follows the hostname across two separate edge fleets, while a sibling domain on the same team/IPs serves TLS fine throughout. That rules out an unhealthy edge node.

One more finding that I think is the important one: I set up your suggested staging domain — a brand-new subdomain, staging.paintbidpros.com, on its own git branch, which has never undergone a production alias change. Vercel issued it a valid certificate and its deployment went READY, and it STILL returns "no peer certificate available" at the edge (23+ minutes after the cert was issued), while its own *.vercel.app preview serves TLS fine. So the failure is not tied to alias changes at all — it affects every hostname under this registered domain, including a fresh subdomain. The staging domain as a workaround therefore doesn't help here; only the *.vercel.app preview URL is usable, since those get TLS from Vercel's wildcard cert.

Per your advice I'm leaving everything in the failed state and not detaching/re-adding again (confirmed no effect).

Update: I've now opened a Pro support case for this (Severity 1). Thank you again — your diagnostic checklist is exactly what let me put together a clean escalation, and the two-edge-fleet / fresh-subdomain evidence came straight from following your steps.

Leaderboard Winner

Hi Ddrake,

That update is even stronger. The fresh staging.paintbidpros.com test changes the shape of the issue: it no longer looks like only a production alias-change delay. If a brand-new hostname under the same registered domain gets a cert issued but still resets before serving any peer certificate, I’d frame this as a domain/zone-level TLS/SNI serving problem.

I’d make that the center of the Pro case:

Registered domain affected: paintbidpros.com
Affected hostnames: apex, www, staging
All affected hostnames: cert issued / deployment ready / HTTPS reset before peer cert
Unaffected control: *.vercel.app deployment URL serves TLS
Unaffected sibling: separate registered domain on same team/IPs serves TLS
Failure follows hostname across different Vercel DNS targets / edge IP ranges

The HTTP 308 path is useful to show the domain reaches Vercel, but the strongest evidence is still the openssl s_client result with no peer certificate. That proves the request is failing before app routing or deployment code can be involved.

I’d also remove or redact the team/project IDs from the public post now that you have a private support case, and share the real domains, cert IDs, deployment IDs, and timestamps only in that case.

While waiting, I would not keep reissuing certs or moving DNS unless support asks for it. Since the fresh staging subdomain under the same registered domain fails too, using a different registered domain or the *.vercel.app URL is probably the only safe temporary workaround.

Summary