Why Vercel custom domains return ERR_CONNECTION_CLOSED on trailing dot FQDN

Help
, ,
1

Domain

deckclip.app (production custom domain on Vercel)

Problem

Visiting https://deckclip.app./ (FQDN with a trailing dot) fails in Chrome with ERR_CONNECTION_CLOSED — the connection drops before any HTTP response. https://deckclip.app (no trailing dot) works normally.

Current vs Expected Behavior

  • Current: TLS does not complete when the client uses the trailing-dot form; browser shows connection closed.
  • Expected: Edge should treat deckclip.app. the same as deckclip.app for TLS SNI / host matching (normalize by stripping a trailing dot), similar to large public sites, then serve or redirect as usual.

Why Configuration Doesn’t Fix It

This fails at TLS, so vercel.json redirects never run.

Steps to Reproduce

Browser: Open https://deckclip.app./ → ERR_CONNECTION_CLOSED.

CLI (openssl):

# Trailing dot in SNI — fails / no cert
echo | openssl s_client -connect deckclip.app:443 -servername 'deckclip.app.'

# No trailing dot — succeeds
echo | openssl s_client -connect deckclip.app:443 -servername 'deckclip.app'

Project Details

Static site on Vercel (Next.js static export). Framework details are secondary; the issue reproduces purely at TLS/SNI against the custom domain.

Request

Can Vercel normalize trailing-dot FQDN hostnames at the edge for SNI and routing?

Thanks.

2

The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points.

You can also use v0 to narrow down the possibilities.

7

ah, then I’m not the only one who reported this

8

Hi Yuze,

Your openssl test is a good way to narrow it down. Since this fails when the trailing dot is included in SNI:

echo | openssl s_client -connect deckclip.app:443 -servername 'deckclip.app.'

but works without it:

echo | openssl s_client -connect deckclip.app:443 -servername 'deckclip.app'

then this is happening before your Next.js app or vercel.json redirects can run. So I don’t think there’s an app-level redirect/header fix for the HTTPS case.

A trailing dot is valid in DNS as an absolute/FQDN form, but TLS certificate/SNI matching is a separate layer. If Vercel’s edge does not normalize deckclip.app. to deckclip.app before selecting the certificate, the handshake can fail before any HTTP request exists.

The practical workaround is to avoid generating or linking to the trailing-dot form anywhere in your app/canonical URLs. For users manually typing https://deckclip.app``./, there probably is not a project-side fix unless Vercel changes edge/SNI normalization behavior.

The useful evidence to keep in the thread is exactly what you already have: same domain, same IP path, only the SNI value changes, and the trailing-dot SNI fails before HTTP.