Why Vercel Apps Fail to Load on Certain Mobile Carriers

Web apps hosted on Vercel can become completely unreachable on specific mobile carriers—hanging indefinitely during the HTTPS handshake—while loading fine on other networks. Ping tests to Vercel's Anycast IP show clean, low-latency connectivity, ruling out basic routing issues, which points to a higher-layer cause: carrier-side Deep Packet Inspection (DPI) firewalls inspecting the TLS Server Name Indication (SNI) string and silently dropping handshake packets when they detect shared vercel.app domains or common Vercel IP ranges.

Developers often mistakenly blame their own code, security headers, or analytics scripts, but the real culprit sits at the network infrastructure level. The recommended fix is to move off the shared *.vercel.app subdomain onto a custom domain, then place that domain behind a reverse proxy like Cloudflare with DNS records set to "Proxied" mode, so user devices handshake with Cloudflare's localized edge nodes instead of connecting directly to Vercel and hitting the carrier's broken filter.

A critical caveat: the Cloudflare SSL/TLS mode must be set to "Full (Strict)"—leaving it on the default "Flexible" setting causes Cloudflare to talk to Vercel over plain HTTP, which Vercel rejects by forcing an HTTPS redirect, trapping users in an infinite ERR_TOO_MANY_REDIRECTS loop. The episode is a reminder that unpredictable carrier-side network changes, especially in emerging markets, can break otherwise solid production deployments, and that domain and proxy architecture deserve careful review before shipping.