Guides / Network

My Website Worked on Wi-Fi. Then I Tried Mobile Data.

The same domain can take different paths over Wi-Fi and cellular networks. DNS, IPv4, IPv6, carrier routing, CDNs and caching can make one connection work while another fails.

PUBLISHED · UPDATED · 10 MIN

My website was online. Laptop: works. Phone on Wi-Fi: works. Another browser: works. Monitoring: green.

Excellent.

I disabled Wi-Fi and let the phone switch to mobile data.

The website stopped loading.

This is a very efficient way to learn that “the internet” is not one network.

It is a collection of networks that have agreed, with varying levels of enthusiasm, to carry traffic for each other.

A website has a journey

Browser
↓
DNS
↓
Wi-Fi ISP / mobile carrier
↓
internet routing
↓
CDN edge
↓
origin
↓
application

Switching from Wi-Fi to cellular can change several of those layers at once.

Home Wi-Fi may use one resolver, one IPv4 path and one CDN edge. Mobile data may use another resolver, prefer IPv6, pass through carrier-grade NAT and reach a different edge location.

Same phone. Same browser. Same domain. Different internet.

DNS is an early suspect

IPv4 commonly uses A records and IPv6 uses AAAA records. Different networks may use different DNS resolvers with different caches, update timing, filtering and geographic answers.

You can change a record and see the new destination immediately on Wi-Fi while mobile data continues remembering the old world.

DNS caching has a remarkable talent for making developers doubt reality.

IPv6 creates a beautiful “mobile data only” failure

Many cellular networks use IPv6 heavily, while home networks vary.

Imagine:

A record    = correct
AAAA record = wrong

Your Wi-Fi path uses IPv4 and works. The mobile network prefers IPv6 and confidently sends the browser toward the wrong destination.

The HTML did not change. The network path did.

This is why checking both A and AAAA records matters.

“Google works” does not prove your site is reachable

Two networks can both have internet access and still take very different paths to one destination. One route may have loss, filtering, congestion or a broken interconnection while another route is healthy.

“Google works” proves that Google is reachable.

Google is probably pleased to hear it.

Carrier-grade NAT changes what an IP means

IPv4 addresses are limited, so mobile carriers often put many customers behind shared public addresses using Carrier-Grade NAT, or CGNAT.

Normal browsing usually works, but IP-based rate limits, peer-to-peer connections, abuse detection and location guesses can behave differently. A protection system may see many normal users behind one public IP and conclude that this address has become extremely productive.

CDNs can send different users to different places

A CDN is designed to route users toward nearby edge infrastructure. Two people visiting the same hostname may therefore reach different locations.

Usually that is excellent. It also means “it works from my computer” does not prove every regional path is healthy.

The same principle applies to deployment platforms: an internal deployment URL being healthy does not prove the custom production domain serves the correct build. Test the real hostname.

HTTPS adds another checkpoint

After DNS and routing, TLS checks certificates, hostnames, trust chains and protocol negotiation. An incomplete chain, an older trust store or an unusual intermediary can produce a secure-connection failure before your JavaScript is ever invited.

Sometimes “broken” really means painfully slow

Wi-Fi may offer low latency, high bandwidth and stable signal. Cellular connections may add higher latency, signal changes, packet loss and bandwidth variation.

A page that performs dozens of small requests can feel fine on Wi-Fi while every round trip becomes visible on mobile. Performance is not only bundle size; request count and connection overhead matter too.

A better comparison routine

You do not need the entire matrix after editing one sentence. But after DNS, certificate, CDN, Worker, proxy or custom-domain changes, the network path itself is part of the feature.

Simple diagnostics

nslookup example.com
dig example.com
curl -4 -I https://example.com
curl -6 -I https://example.com
curl -IL https://example.com

These commands do not repair the site. They tell you which layer deserves suspicion, which is often half the work.

Do not change five things at once

Network failures make people impatient. You change DNS, a proxy rule, SSL mode, a Worker route and caching. The site starts working.

Great.

Which change fixed it?

Nobody knows.

Now you have a working website and five unexplained configuration changes.

Networking rewards boring debugging: change one variable, record the result, then continue. Boring is reproducible.

The final lesson

A site working on your Wi-Fi proves exactly one thing: it worked through that path at that moment.

Mobile data may use different DNS, a different IP family, different routing and another CDN edge.

The web hides all of that machinery beautifully when it works.

Then you disable Wi-Fi.

And the internet offers a second opinion.