Hi Vercel Support,
I'd like to report a network reachability problem affecting the Vercel edge IP range 216.198.79.0/24 from China Mobile (中国移动), the largest mobile carrier in mainland China.
Summary
- Domain:
userhali.shop, project:hali-shop - Its DNS target
56e1a1301d9b5ac6.vercel-dns-017.comreturns two IPv4 addresses on every query: one from64.29.17.0/24(reachable) and one from216.198.79.0/24(unreachable from China Mobile). - Because of that rotation, roughly half of China Mobile visitors are handed a blocked edge IP and fail to load the site, while China Telecom / China Unicom users are largely unaffected. This produces a "works in some regions, fails in others" pattern.
Blocking signature (measured from a China Mobile host, Guangdong, AS9808)
| Behaviour | 216.198.79.1 | 64.29.17.1 (control) |
|---|---|---|
| TCP three-way handshake | completes normally | completes normally |
| Send 1 byte of application payload | connection reset (ECONNRESET / errno 104) within ~50 ms | connection stays open |
| Send a real TLS ClientHello | reset | normal TLSv1.3 handshake |
| Port 80 with payload | reset | HTTP 308 → HTTPS |
| Same payload with an unrelated SNI | still reset | — |
| Connect but send nothing | connection held open | connection held open |
The reset is injected after a successful handshake, on the first application-layer byte, and is independent of SNI / Host / TLS content — raw non-TLS bytes are reset too. This behaves like IP-prefix-level filtering on the China side, not like a response from your edge. Ports 22 / 8080 / 8443 simply time out. 20 sequential HTTPS attempts to 216.198.79.1 → 20 failures; 20 attempts to 64.29.17.1 → 20 successes.
Control: the same network reaches other Vercel ranges fine
From the same China Mobile host, all of these complete TLS and return HTTP 200: 64.29.17.1, 64.29.17.65, 216.150.1.193 (supabase.com), 76.76.21.21, 76.76.21.22, 64.239.123.1, 64.239.123.65, 64.239.109.193 (vercel.com). Only 216.198.79.0/24 is filtered — so this is not a local connectivity issue and not a Vercel-wide outage.
Scale measurements (itdog.cn, 300+ probes across mainland China, all forced to a single IP)
Forcing every probe to 216.198.79.1:
| Carrier | Nodes | Failed | Failure rate |
|---|---|---|---|
| China Telecom | 88 | 5 | 5.7% |
| China Unicom | 82 | 1 | 1.2% |
| China Mobile | 89 | 89 | 100.0% (36× instant reset + 53× silent timeout) |
| Overseas probes | 43 | 0 | 0.0% |
A re-run focused on China Mobile: 92 / 92 nodes failed across 63 cities, zero successes, while 43 overseas probes (Hong Kong, Macau, Taipei, Tokyo, Singapore, Frankfurt, San Jose, São Paulo …) all returned HTTP 200.
→ Your edge is healthy worldwide; the failure lies entirely on the China-network path toward that prefix.
Impact
userhali.shop is a production store. China Mobile is the largest carrier in mainland China, so a large fraction of our mainland traffic is intermittently unable to reach the site at all.
Request
- Could you confirm whether
216.198.79.0/24is affected by upstream filtering toward mainland China? - If so, is it possible to stop advertising
216.198.79.0/24to clients resolving within China, or otherwise publish alternative edge IPv4 addresses for this project so DNS always returns a reachable address? - As a workaround we plan to replace the rotating CNAME target with explicit A records pinned to the reachable edge IPs (
64.29.17.1/64.29.17.65) foruserhali.shop,www.userhali.shopandshop.userhali.shop. Please confirm this will not affect domain verification or certificate issuance / renewal. We have verified that both IPs serve our project correctly (correct SNI/Host routing, valid per-domain certificates, and the expected308redirects forwwwandshop).
Thank you — happy to provide raw probe logs, openssl s_client output, or packet captures if useful.
