Site Times Out on Your Phone? How to Diagnose an ISP Block
The deployment succeeded. Vercel showed the build green, no errors in the logs, the previous version of the site had been loading fine minutes earlier. Then the URL just... didn't load. Not an error page, not a 500, not…
The deployment succeeded. Vercel showed the build green, no errors in the logs, the previous version of the site had been loading fine minutes earlier. Then the URL just... didn't load. Not an error page, not a 500, not a broken layout — the browser sat there until Chrome gave up with ERR_CONNECTION_TIMED_OUT. The kind of failure that looks exactly like the server is down, except the server wasn't down.
The First Wrong Assumption
The obvious first suspects were the obvious first suspects: had the latest deploy broken something, was Vercel having an outage, had a DNS record gotten misconfigured. None of those held up. Vercel's dashboard showed the deployment as healthy. The build logs showed no errors. And — the detail that eventually mattered — a different device on a different network loaded the site instantly, no delay, no timeout, nothing.
Same site. Same URL. Same moment in time. One connection times out, another loads clean. That rules out the server, the deployment, and the DNS record all at once — if any of those were actually broken, every connection would fail the same way, not just some of them.
Isolating the Variable
With the server ruled out, the only thing left that differed between "works" and "doesn't work" was the network path itself. A quick test made that concrete: switch on a VPN, reload the same URL on the same phone. It loaded immediately.
That's a specific, informative result. A VPN doesn't touch the website, the DNS record, or the hosting provider — it changes the network route the request takes to get there. If turning on a VPN is the only variable that flips a timeout into a successful load, the problem lives somewhere in that network path, not on the server end at all.
Naming the Actual Cause
The pattern matches a known behavior: some ISPs block or throttle access to shared hosting subdomains — .vercel.app, in this case — sometimes because of aggressive spam or phishing block-lists that were built for a different site entirely and happen to catch every project hosted on the same shared domain. The site's own custom domain, if it had one, generally wouldn't be affected the same way; the block was targeting the shared subdomain pattern, not the specific project.
That explanation fit every piece of evidence collected: consistent failure on one specific carrier's network, consistent success on a VPN or a different SIM, zero errors anywhere in the actual hosting infrastructure, and a failure mode (silent timeout, no error page) that's characteristic of a network-level block rather than an application-level one.
Checking With the Source, Not Assuming
A theory that fits the evidence still isn't confirmation. The next step was contacting the ISPs directly through their support channels, describing the exact symptom and asking directly whether .vercel.app domains were being blocked or throttled on their network.
The answers were unhelpful in an informative way. Support responded with generic customer-service scripts, and one explicitly said the query needed to go to "the relevant team" — confirming, indirectly, that front-line support at a consumer ISP doesn't have visibility into low-level routing or block-list decisions.
What Actually Gets Fixed Here
A VPN or a second SIM card solves the symptom on one device, for one person, right now. It isn't a fix — it's a workaround that has to be repeated by every visitor on the affected network, every time, indefinitely. The durable fix for this specific failure mode is moving off the shared subdomain entirely: a custom domain isn't swept up in the same block-lists that target .vercel.app broadly.
Until that migration happens, the honest status of the bug is: diagnosed, root cause identified with reasonable confidence, workaround available, permanent fix scoped but not yet applied.
The Diagnostic Habit That Mattered
The single most useful step in this entire process was testing the same request from two different network paths before concluding anything about the server. A timeout on one device looks identical to a server outage until you can compare it against a second device on a different connection.
Takeaway: when something that should be simple times out with no error and no explanation, don't start with the server. Start by checking whether the same request succeeds from a different network. If it does, you're not debugging your code — you're debugging a network path.
📬 Get the latest AI tool reviews
Expert picks and comparisons, weekly. No spam.