I am experiencing the same issue from Oman.

Custom domain:

https://drcoman.om

Working Vercel deployment: https://drc-eta.vercel.app

Confirmed behaviour:

• drcoman.om times out on Oman fixed broadband
• It also times out on Oman mobile data
• It works immediately through a VPN outside Oman
• The drc-eta.vercel.app deployment works normally without VPN
• Vercel shows Valid Configuration
• The apex A record assigned by Vercel is 216.198.79.1
• There is no conflicting AAAA record

This appears to confirm that 216.198.79.1 is also unreachable from my Oman connections.

Please escalate this to the Vercel Edge Network or networking team.

same problem here: Vercel deployment works, but custom domain doesn't work inside Oman.

facing same problem

We have now isolated the problem to one of Vercel’s Anycast IPs.

www.drcoman.om resolves through:

c756d5c7552a3292.vercel-dns-017.com

Current IP results:

• 64.29.17.1 — reachable from Oman
• 216.198.79.1 — unreachable from the same connection

Test against the working IP:

1
curl.exe -I --connect-timeout 15 --resolve www.drcoman.om:443:64.29.17.1 https://www.drcoman.om

Result:

1
HTTP/1.1 307 Temporary Redirect
2
Server: Vercel
3
Location: /en

Test against the failing IP:

1
curl.exe -I --connect-timeout 15 --resolve www.drcoman.om:443:216.198.79.1 https://www.drcoman.om

Result:

1
curl: (28) Connection timed out after 15008 milliseconds

The site works through a VPN and sometimes through Firefox, but Chrome and curl frequently time out when routed to 216.198.79.1.

Vercel support chat confirmed that this appears to be a regional routing/peering issue requiring infrastructure-team investigation. Because the project is on the Hobby plan, the support-case form redirected us back to the Community.

Please escalate the existing topic to the networking/infrastructure team for investigation of Anycast reachability from Oman.

Adding another confirmed, independently-diagnosed data point — this looks like a broader pattern, not an isolated case.

My setup:

• Domain: phoenixftoman.com
• Vercel project: phoenix-globnet-site
• Location: Muscat, Oman
• ISP: OmanTel (AS28885)

What I found, using the official vercel-connect-debug script against my project's assigned edge IPs:

So 7 of 8 assigned addresses work fine — only 216.198.79.195 is blocked from my specific network. My custom domain's originally-assigned A record, 216.198.79.1, also times out from this same connection (a different address in the same /24, same symptom).

Full diagnostic output: https://pastebin.com/JAvTJ7nm

This appears to be the same underlying issue reported across several other threads, each affecting a different specific IP within the same new ranges:

• Custom domain unreachable from Oman — regional routing issue with 216.198.79.0/24 — Oman, OmanTel AS28885
• TLS timeouts to Vercel edge IPs from Oman (AS204170) — Oman, different ISP (Awasr)
• Site unreachable from Oman — 3 of 8 assigned edge IPs are blackholed — Oman
• New edge ranges 216.198.79.0/24 + 64.29.17.0/24 unreachable from Morocco (AS36925) — Morocco, same ranges

Given how many independent reports this now has, across multiple ISPs and at least two countries, this looks like a genuine Vercel Anycast/edge routing issue specific to the newer 216.198.79.0/24 and 64.29.17.0/24 ranges — not something any of us can fix on our end. Each affected user seems to have a different specific IP blocked within these ranges, which suggests inconsistent regional routing/peering to parts of this new pool rather than a single blanket block.

Current workaround: I've set up GoDaddy domain forwarding to my .vercel.app URL, which works since it happens to resolve to a working address. Would like to move back to a direct custom domain setup once this is resolved.

I also raised this via Vercel support chat — the agent confirmed it as a real routing issue and attempted to escalate to a support case, but case creation for "Domains > DNS Configuration" is gated behind a paid plan, so posting the full evidence here instead, where the other confirmed reports live.

Happy to run further diagnostics or provide additional traceroutes if that helps the infrastructure team narrow this down.

Thank you all for reporting. We're investigating now