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.

https://vercel.com/docs/projects/domains/troubleshooting

You can also use v0 to narrow down the possibilities.

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

Hi Yuze,

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

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

but works without it:

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

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.