Hi Godjerin,

This looks less like an app/DNS configuration issue and more like reachability to a subset of Vercel edge IPs from AS204170/Awasr.

I’d capture TCP 443 and TLS evidence for one failing IP and one working IP from the same Oman connection. Traceroute is useful, but curl/openssl with SNI will be more actionable:

1
date -u
2

3
curl -4Iv --connect-timeout 10 --resolve your-domain.com:443:216.198.79.65 https://your-domain.com/
4
curl -4Iv --connect-timeout 10 --resolve your-domain.com:443:216.198.79.129 https://your-domain.com/
5

6
openssl s_client -connect 216.198.79.65:443 -servername your-domain.com -brief </dev/null
7
openssl s_client -connect 216.198.79.129:443 -servername your-domain.com -brief </dev/null
8

9
mtr -4 -T -P 443 -c 20 216.198.79.65
10
mtr -4 -T -P 443 -c 20 216.198.79.129
11

Replace your-domain.com with the affected custom domain. The --resolve part is important because it keeps the same hostname/SNI while forcing the request to a specific Vercel IP.

If the same hostname succeeds on 216.198.79.129 but times out or resets on 216.198.79.65 from the same network, that is strong evidence for a routing/reachability issue to specific Vercel edge paths, not a broken deployment.

I would not change DNS to random “working” Vercel IPs unless the Vercel domain card explicitly tells you to use them. Use the alternate IPs as diagnostics only.

The most useful details to add are the affected domain, exact UTC timestamp, ISP/AS, failing IP, working IP, and the curl -Iv / mtr -T -P 443 outputs.