My production site `www.manziloman.com` is **completely unreachable from Oman**, my target market. Vercel’s `vercel-connect-debug` script shows why, and I’d like to know if others see this or whether a staff member can take a look.
## The finding
My domain is assigned 8 edge IPs. **5 work perfectly from Oman. 3 are completely blackholed — and DNS returns only the blackholed ones.**
IP range returned by Vercel’s lookup API for `www.manziloman.com`:
`216.198.79.1, 216.198.79.65, 216.198.79.129, 216.198.79.193, 64.29.17.1, 64.29.17.65, 64.29.17.129, 64.29.17.193`
Same machine, same run, from **AS28885 (OmanTel)**, Muscat:
| IP | ping | HTTPS |
|—|—|—|
| `216.198.79.1` | 100% loss | **TLS handshake timeout** |
| `216.198.79.65` | 100% loss | **TLS handshake timeout** |
| `64.29.17.65` | 100% loss | **TLS handshake timeout** |
| `216.198.79.129` | 0% loss | HTTP 200 |
| `216.198.79.193` | 0% loss | HTTP 200 |
| `64.29.17.1` | 0% loss | HTTP 200 |
| `64.29.17.129` | 0% loss | HTTP 200 |
| `64.29.17.193` | 0% loss | HTTP 200 |
DNS hands out exactly the broken ones:
```
$ dig www.manziloman.com @8.8.8.8
www.manziloman.com. 1800 IN A 64.29.17.65
www.manziloman.com. 1800 IN A 216.198.79.65
```
So every Omani visitor gets a dead IP. Note `216.198.79.65` is dead while `216.198.79.129` is healthy — **same /24, same machine, seconds apart**. This is per-IP, not per-prefix.
Handshake on a broken IP stalls exactly where the Certificate message should arrive:
```
* Connected to 216.198.79.1 (216.198.79.1) port 443
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* Connection timed out after 3003 milliseconds
```
Traceroute to a broken IP never leaves OmanTel:
```
1 192.168.x.x 4.075 ms
2 5.36.240.1.dynamic-dsl-ip.omantel.net.om 6.132 ms
3-30 * * * (no response)
```
Healthy IPs answer ICMP at 0% loss, so this isn’t ICMP filtering — those 3 addresses just don’t route from AS28885.
## A healthy route exists
All 5 working IPs serve from `bom1` (Mumbai) in ~9-13 ms:
```
216.198.79.129 x-vercel-id: bom1::iad1::b54hl-…
216.198.79.193 x-vercel-id: bom1::iad1::cm488-…
64.29.17.1 x-vercel-id: bom1::iad1::mvvxc-…
64.29.17.129 x-vercel-id: bom1::iad1::2g8t6-…
64.29.17.193 x-vercel-id: bom1::iad1::dh2j8-…
```
So a fast path from Oman to Mumbai clearly exists — 5 of 8 anycast addresses take it. The other 3 blackhole at OmanTel’s edge. Over a US VPN those same 3 IPs answer instantly from `sfo1`, so the addresses are live; they’re just not routable from AS28885.
**Legacy IPs also work from Oman:** `curl --resolve www.manziloman.com:443:76.76.21.21` → HTTP 200, valid cert, correct content. Same for `cname.vercel-dns.com` targets (`66.33.60.x`, `76.76.21.x`).
## Ruled out
- **DNS** — resolves correctly; dashboard shows “Valid Configuration”
- **Certificate** — valid: `CN=*.manziloman.com`, SAN `*.manziloman.com, manziloman.com`
- **CAA** — permits `letsencrypt.org`, `pki.goog`, `sectigo.com`
- **App** — HTTP 200 with correct content over the 5 working IPs and on `*.vercel.app`
- **My network** — reproduced on two unrelated Omani ISPs, including mobile data
- Removed and re-added both domains; no change
My domain uses Vercel nameservers, so I can’t influence which IPs are served.
## Questions
1. Has anyone else seen `216.198.79.0/24` / `64.29.17.0/24` blackholed from the Middle East? Any idea why 3 addresses in a /24 wouldn’t route from an ASN while 5 others reach `bom1` in 9 ms?
2. Is there any way on Hobby to stop those 3 IPs being returned for my domain, or to pin it to the 5 that work?
3. As a workaround I’m considering moving DNS off Vercel nameservers and pointing at `76.76.21.21` + `cname.vercel-dns.com` (both verified working from Oman). Is that supported long-term, or will those targets migrate to the new ranges and break again?
I can provide full `vercel-connect-debug` output.