How to Fix a Website That Loads on Wi-Fi but Not on Mobile Data

Your website loads perfectly on Wi-Fi. You turn Wi-Fi off, the same phone switches to mobile data, and the same address times out, shows a security warning, or lands on the wrong site. Nothing about the website changed in those ten seconds. The two networks take different routes, ask different DNS resolvers, and may use different internet protocol versions. Find the difference before you change anything.

First, prove which side is broken

Try the site on a second phone on the same mobile network. If it works there, the problem lives on the first phone. Try the same phone on another carrier's network, if you can. If it works there, the problem lives with the first carrier. Try another well known site on mobile data. If nothing loads, the connection itself is at fault, and toggling airplane mode on and off, or restarting the phone, is the honest next step. Write down the exact error, the carrier, and the time. Note the public IP on each network with the What's My IP tool.

Read the exact error before you change anything

A timeout, or "This site can't be reached", means the phone could not connect at all, which points to DNS, routing, or a block. A DNS error means the name was never turned into an address on that network. A certificate warning means the phone did connect, but the security check failed, which is a different fault. An old-looking page usually means a stale cached answer is still being served. Do not fix the first guess: changing nameservers or turning a firewall off can create downtime while the fault stays hidden.

Check 1: Is it just stale DNS on the carrier?

This is the most common cause soon after a DNS change or a move to a new host. Wi-Fi and mobile data use different DNS resolvers. Your home router may use a resolver that picked up the new record quickly, while your carrier's resolver still holds the old one. DNS does not push changes out. Each resolver keeps a cached copy until the record's TTL, its time to live, runs out. A TTL of 300 seconds means about five minutes. A TTL of 3600 seconds means about an hour.

Test it with the DNS Propagation Checker, which asks resolvers in several places the same question at the same moment. If most show the new address and a few still show the old one, you are looking at normal cache expiry. Wait out the old TTL and recheck. If every resolver shows the new address but your phone still fails, the stale answer is closer to home: the carrier's resolver, the phone's own cache, or a private DNS setting. Airplane mode on and off often clears the phone's cached answer.

Check 2: Is IPv6 sending mobile visitors somewhere broken?

Mobile networks use IPv6 far more than most home Wi-Fi networks. A site has an IPv4 address in an A record and, if it supports IPv6, an IPv6 address in an AAAA record. If the AAAA record points to an old server, a server that no longer answers, or one never set up for IPv6, a phone on mobile data may try IPv6 first and fail, while a laptop on Wi-Fi uses IPv4 and never notices. Check both records for the exact hostname that fails, including the www version. Confirm an AAAA record points to the current server and that the server listens on IPv6. A stray AAAA record from a previous host is a fix only after you confirm it is stray.

Check 3: Is the certificate, or the www version, the difference?

A certificate warning only on mobile data is still a certificate problem. It often means the certificate covers one version of the address but not the other. A certificate for example.com does not automatically cover www.example.com unless both names are listed on it. Test both versions, with and without www, and note which warns. Run the failing hostname through the SSL Checker and check the expiry date, the names covered, and whether the chain is complete. If the certificate has expired or never covered the www name, renew or reissue it with both names covered, then retest on mobile data.

Check 4: Is a firewall or security rule blocking the carrier?

Carriers share a small pool of public addresses among many customers, a setup called carrier-grade NAT. If one phone triggered abuse filters, a firewall can block the shared address for everyone on it. The site then loads fine from home broadband and fails for every phone on that carrier, which looks like a carrier fault but is really a block at your end. Compare the public IP on mobile data with the one on Wi-Fi. Ask your host, or check your security service's firewall events, whether that carrier address or range is blocked, challenged, or rate limited. If a rule is blocking the carrier, narrowing or removing it is the fix. Do not turn the whole firewall off to test this.

Check 5: Is something on the phone changing the route?

Rule out the phone itself before you blame the carrier. A VPN, a content filter, a private DNS setting, or a privacy relay can reroute traffic, change which resolver answers, or place the phone in a different region. Turn the VPN and any private DNS or relay feature off, try the site in a private browsing tab, then try a second browser. If it loads with those features off, turn them back on one at a time until the fault returns. That tells you which feature is responsible. Check too for an old bookmark pointing at an outdated address.

What to do first, in order

Work this list top to bottom. First, reproduce it on a second phone and network, and note the error and carrier. Second, compare DNS answers with the DNS Propagation Checker and wait out the old TTL only if resolvers still disagree. Third, check the AAAA record and confirm IPv6 works on the current server. Fourth, check the certificate for both the www and non-www names. Fifth, check whether a firewall rule is blocking the carrier's shared address. Sixth, turn off the phone's VPN, private DNS, and relay features and retest.

If every check passes and the site still fails on one carrier only, send an evidence based report to the carrier or the host: the error, the times, the carrier, the public IP from each network, and the DNS and certificate results. Find which one it is first, and the fix is small.