If the IP is reachable (the user's *.vercel.app proves it, since it is the same range and often the same machine) and the certificate is valid, then the only thing that differs between the request that works and the request that fails is the hostname: in the TLS SNI field, and again in the Host header.

Filtering on the hostname rather than the address happens on the path, not at Vercel. That matches the geography in these threads, where SNI-level inspection is well documented, and it explains the strangest symptom in the cluster: several reports say the response stalls after HTTP 200 rather than failing to connect, which is a mid-stream reset rather than a blocked route.

I want to be careful about how far that goes. I have ruled out a Vercel-side IP split and shown the edges are interchangeable. I have not proved what is happening on any affected path, and I cannot from here.

Two commands, if your custom domain is affected

These separate the address from the name. Run both from the network where it fails and paste the output.

1. Is the IP reachable at all? Pin your custom domain's IP, but ask for a vercel.app hostname:

1
curl -sv -o /dev/null --resolve swr.vercel.app:443:<YOUR_CUSTOM_DOMAIN_IP> https://swr.vercel.app/

Succeeds: the address and the route are fine, and the problem is your hostname. Fails: the address itself is unreachable, which is a different problem.

2. Same IP, same route, only the name changes. This isolates SNI:

1
openssl s_client -connect <YOUR_CUSTOM_DOMAIN_IP>:443 -servername swr.vercel.app    </dev/null
2
openssl s_client -connect <YOUR_CUSTOM_DOMAIN_IP>:443 -servername <YOUR_DOMAIN>     </dev/null

One handshake completing and the other resetting, on the same IP in the same session, is the answer. If both complete, the TLS layer is fine and the stall is happening later, which is worth knowing too.

Find your IP with dig +short <YOUR_DOMAIN> or nslookup <YOUR_DOMAIN>.

Why this matters for the threads

If this holds, then asking these users to re-add DNS records, re-issue certificates or change nameservers cannot work, because nothing in their Vercel configuration is involved. The useful answers become different ones: which networks are affected, whether a different hostname on the same project is reachable, and what Vercel can tell an affected user to take to their ISP.

It would also be worth knowing whether Vercel can serve a custom domain from a hostname the user controls on the vercel.app namespace as a temporary route, since the edge clearly already does this.

The threads I think are the same issue

• 47582, 49530, 50512, 47833 (Morocco)
• 49387, 48756, 49339 (Russia)
• 49960, 50277 (Starlink Brazil)
• 49668 (Jio, India)
• 49526, 50885 (network path unspecified)

If your thread is in that list and the two commands above give a different result from what I predict, that is the most useful thing anyone could post here, because it would rule this out.