Your website loads instantly on office Wi-Fi, yet switching the same phone to 4G or 5G produces a timeout, security warning, or blank page. This frustrating pattern usually means the website is reachable through one network path but not another. The cause could be a stale mobile carrier DNS response, a broken IPv6 record, an overzealous Cloudflare rule, an SSL mismatch, or a routing failure between the carrier and your host.
Do not immediately change nameservers, delete DNS records, or disable your firewall. Those broad actions can introduce downtime or expose the server without identifying the original fault. Instead, determine whether the website not working on mobile data is an isolated device problem or a reproducible network issue, then follow these eight checks in order.
First, establish the scope of the mobile network website error
Start with a simple test matrix. Try the site on one phone over Wi-Fi and cellular data, then repeat the test on a second device. If possible, use a different mobile carrier. Record the exact error, affected hostname, time, carrier, and whether the failure occurs on 4G, 5G, or both.
- One browser fails: Suspect browser cache, extensions, private DNS, VPN, or stored redirects.
- One phone fails: Focus on device settings, cached DNS, security software, or the mobile plan.
- Multiple devices on one carrier fail: Investigate mobile carrier DNS problems, routing, IPv6, or carrier address ranges blocked by your security layer.
- Multiple carriers fail while Wi-Fi works: Prioritize public DNS records, IPv6 connectivity, CDN rules, SSL, and origin-server access.
1. Test another browser, device, and clean connection
Open the site in a private browsing window and then in another browser. Temporarily disconnect any VPN, content filter, custom private DNS service, or iCloud Private Relay-style privacy feature used by the device. These services can change DNS resolution or route traffic through a different region.
Next, restart the phone or briefly enable airplane mode to establish a fresh cellular session. Avoid clearing every setting at once because that destroys useful evidence. If only one browser fails, clear that browser’s cached site data and HSTS-related state where supported. If every browser on the device fails but another phone on the same carrier succeeds, the website itself is unlikely to be the primary problem.
2. Compare DNS resolution across Wi-Fi and mobile networks
DNS resolver differences are a common reason a website works on Wi-Fi only. A home router may use Cloudflare or Google DNS, while a carrier may use its own resolver, encrypted DNS, or a DNS64 service designed for IPv6-centric networks.
From a computer on Wi-Fi, run “nslookup example.com” or “dig example.com A” and “dig example.com AAAA.” To query specific public resolvers, use “dig @1.1.1.1 example.com” and “dig @8.8.8.8 example.com.” Replace example.com with both the root domain and the exact hostname that fails, such as www.example.com.
Compare the returned addresses, CNAME chain, status, and TTL. An NXDOMAIN response means the resolver believes the hostname does not exist. SERVFAIL often indicates DNSSEC, authoritative-server, or delegation trouble. Different valid answers may be expected with a CDN, but an old server address from only one resolver suggests caching or inconsistent authoritative DNS. You can also compare global results with the Google Admin Toolbox Dig.
Why it may not be a DNS propagation issue
Propagation is often blamed whenever a site fails selectively, but it only fits when records or nameservers changed recently and resolvers still hold an older response within its TTL. If all major resolvers return the same correct records, waiting another 48 hours is unlikely to help. Routing, IPv6, firewall, and TLS failures can look like DNS problems even after resolution succeeds.
3. Inspect A, AAAA, and CNAME records carefully
The A record maps a hostname to IPv4, while the AAAA record maps it to IPv6. A CNAME points one hostname to another name. Confirm that every published address belongs to the active server or CDN and that the full CNAME target resolves successfully.
A forgotten AAAA record is especially important when a website is accessible on Wi-Fi but not 4G. Some Wi-Fi networks prefer IPv4, while modern cellular networks often prefer IPv6. The phone may therefore choose a broken IPv6 destination that desktop users rarely reach. Check the root domain, www hostname, and any redirect destination separately.
Do not delete records simply because they look unfamiliar. CDN and managed hosting configurations may require them. Document the current values, confirm the intended configuration with the provider, lower the TTL before a planned change when practical, and alter only the incorrect record.
4. Test IPv4 versus IPv6 connectivity
IPv4 versus IPv6 troubleshooting can quickly expose a split-path failure. From a system with both protocols available, run “curl -4 -I https://example.com” and “curl -6 -I https://example.com.” The -I option requests response headers instead of downloading the full page.
- IPv4 succeeds and IPv6 times out: The AAAA address, IPv6 route, server listener, or IPv6 firewall is probably faulty.
- IPv6 succeeds and IPv4 fails: Check the A record, IPv4 firewall, NAT, and hosting route.
- Both connect but return different status codes: Traffic may be reaching different CDN edges, virtual hosts, or redirect rules.
- Both fail: Continue with CDN, TLS, origin, and routing checks.
A website not working on 5G may also involve IPv6-only carrier infrastructure using DNS64 and NAT64. Publishing a broken AAAA record is worse than having no AAAA record because clients trust the advertised native IPv6 path. The proper fix is to restore working IPv6 or remove the record only after confirming that IPv6 service is not intended.
5. Review Cloudflare proxy, firewall, and security rules
Cloudflare DNS troubleshooting should cover more than the DNS screen. Verify whether each record is proxied or DNS-only, whether the origin IP is correct, and whether recent configuration changes coincide with the failure. Then review Security Events for requests from affected mobile carrier address ranges.
A Cloudflare firewall blocking mobile users may be reacting to shared carrier-grade NAT addresses, IPv6 ranges, geographic rules, bot scores, user-agent conditions, or rate limits. Thousands of subscribers can appear behind a limited pool of carrier addresses, so an aggressive IP-based rule may block legitimate visitors. Managed challenges can also behave differently in embedded or privacy-focused mobile browsers.
Inspect custom WAF rules, IP access rules, country restrictions, bot protections, rate-limiting rules, and redirects. Look for a matching event before changing anything. Prefer a narrow exception for the verified rule or path rather than disabling the WAF or switching off the proxy globally. Cloudflare’s official DNS troubleshooting documentation provides additional checks for authoritative DNS and proxied records.
6. Check SSL/TLS certificates and redirect behavior
Use “curl -Iv https://example.com” to view the connection, certificate handshake, and response headers. Check the root domain and www version independently. The certificate must cover the hostname requested by the user, remain valid, and include a complete chain accepted by mobile operating systems.
Follow redirects with “curl -IL https://example.com.” Look for loops between HTTP and HTTPS, www and non-www, or CDN and origin hostnames. A redirect to an internal hostname, an unprotected subdomain, or an obsolete domain can produce a website connection timeout on mobile even when the first request succeeds.
If Cloudflare is involved, use an appropriate SSL mode and install a valid certificate at the origin. Do not weaken HTTPS or select an insecure mode merely to hide an origin certificate problem.
7. Investigate hosting, routing, and carrier DNS problems
If DNS and TLS look correct, examine server and hosting logs at the exact test time. No request in the origin or CDN logs suggests that traffic is failing before it arrives. A logged 403 points to access control; a 429 indicates rate limiting; and 5xx responses suggest an application, proxy, or origin failure.
Confirm that the server listens on the published IPv4 and IPv6 addresses and permits inbound web traffic on ports 80 and 443. Review host firewalls, fail2ban-style tools, WordPress security plugins, load balancers, and upstream denial-of-service controls. WordPress website network troubleshooting should begin at the network edge rather than with random plugin changes, especially when the site works consistently over Wi-Fi.
When only one carrier is affected, collect traceroute or provider-supported path diagnostics from the failing network, along with DNS responses and timestamps. Carrier DNS filtering, stale negative caching, peering faults, and routing leaks require evidence. Send that evidence to both the mobile carrier and hosting provider so each can inspect its side of the path.
8. Apply one targeted fix, then retest
Change only the component supported by your findings: correct one DNS record, repair the IPv6 listener, narrow a firewall rule, replace the certificate chain, or ask the host to resolve a route. Then repeat the original test matrix over Wi-Fi, 4G, and 5G.
Test the root and www hostnames, compare IPv4 and IPv6, and check more than one carrier when possible. Keep notes about old and new values, timestamps, TTLs, and results. If the fix fails, roll it back instead of stacking speculative changes that make diagnosis harder.
Decision tree: device, DNS, CDN, server, or carrier?
- Does another browser on the same phone work? If yes, fix browser cache, privacy settings, VPN, or extensions. If no, continue.
- Does another phone on the same carrier work? If yes, investigate the original device. If no, test another carrier.
- Do multiple carriers fail? If yes, compare public DNS answers, A and AAAA records, TLS, CDN events, and origin logs.
- Does only one carrier fail? Compare that carrier’s DNS result and route with public resolvers. Check whether its IP ranges trigger CDN or firewall rules.
- Does curl -4 work while curl -6 fails? Repair the IPv6 record, route, listener, or firewall.
- Does DNS return the wrong address or SERVFAIL? Correct the authoritative record, delegation, DNSSEC configuration, or CNAME chain.
- Does the CDN show a block or challenge? Adjust the specific security or rate-limit rule after verifying the request.
- Does traffic reach the server? If logs show an error, fix the virtual host, application, redirect, or access rule. If no request arrives, escalate routing evidence to the CDN, host, or carrier.
Frequently asked questions
Why is my website not opening on cellular data but works on Wi-Fi?
The two connections may use different DNS resolvers, IP versions, routes, and public addresses. Cellular networks commonly favor IPv6 and share carrier-grade NAT addresses. A broken AAAA record, blocked carrier range, stale carrier DNS answer, or route failure can therefore affect cellular visitors without affecting Wi-Fi users.
How long should a DNS propagation issue take to resolve?
Resolvers normally retain an old answer until its TTL expires, although negative caching and provider behavior can affect timing. Check the authoritative record and query several resolvers rather than relying on a fixed waiting period. If every resolver returns the expected answer, continued waiting will not repair a firewall, IPv6, TLS, or routing problem.
Should I change my phone’s DNS to fix the site?
Changing DNS can be a useful temporary test. If the site works with a public resolver but fails with the carrier resolver, you have evidence of a resolver-specific issue. It is not a complete website fix because other visitors still using the carrier DNS may remain affected.
Should I disable Cloudflare or my firewall?
No, not as a first response. Disabling protection can expose the origin, change routing, invalidate test results, and create new security risks. Review event logs and make the narrowest reversible change supported by evidence.
Can a WordPress plugin cause a Wi-Fi versus mobile data problem?
A security or caching plugin can block shared mobile IP addresses, redirect mobile user agents, or enforce rate limits. However, pure DNS, IPv6, and carrier routing failures occur before WordPress receives the request. Check network and CDN evidence before deactivating plugins.
Resolve the path, not just the symptom
When a website works on Wi-Fi but not mobile data, the fastest solution comes from comparing paths rather than guessing. Isolate the affected device or carrier, verify DNS, test IPv4 and IPv6, inspect CDN and TLS behavior, and confirm whether requests reach the server. A measured, targeted fix restores mobile access without creating a second outage.