Guide · 11 November 2026

My site opens on Wi-Fi but not on mobile data. Why?

Because the two are usually different networks: the Wi-Fi is a home line from one provider, the mobile data is the phone operator's network, and each has its own DNS servers, filters and addresses. A default mobile filter, many phones sharing one address that your rate limit blocks, an untested IPv6 path or a geo rule can each break the site on one connection only. Ask which provider and which connection, then check the causes below.

Is the visitor really on two different providers?

Often yes, and that alone can explain it: blocks and filters live inside each provider's network. In Norway, Telenor's Nettvern filter is switched on automatically for all private mobile and broadband customers and works while you browse on Telenor's network; the stronger Nettvern+ has to be switched on by the customer and also stops more newly created scam sites. A visitor whose phone is on Telenor and whose home Wi-Fi is with another company goes through Telenor's filters on one connection and not on the other.

Sources: Telenor, Nettvern, checked 11 November 2026 · Telenor, "Hvorfor har Telenor to sikkerhetsfiltre?", 29 April 2025

National block lists work the same way: they are applied by the providers that take part. In Poland, Orange, Plus, Play and T-Mobile agreed in March 2020 to apply the CERT Polska warning list of phishing and fraud domains by replacing the DNS answer (the step that turns your domain into a server address) with the address of a warning page; entries stay on the list for six months. A domain holder who thinks the entry is wrong can file an objection with the President of UKE, the Office of Electronic Communications. In Germany, the members of the CUII block the domains it names in their DNS.

Sources: CERT Polska, Lista Ostrzeżeń, checked 11 November 2026 · heise online, 16 July 2025

Do mobile networks filter sites by default?

Some do, and the United Kingdom is a documented case. Three says all new Three devices have age-restricted content blocked by default, so 18+ content cannot be opened on its network until the customer proves their age. Under the UK mobile operators' code of practice, each operator offers a filter for under-18s and sets it according to a framework prepared by the British Board of Film Classification (BBFC). A site that lands in that filter by mistake can open fine on home Wi-Fi and fail on mobile data.

The route for a wrong block is documented. Three asks for sites that are blocked when they should not be to be reported to content@three.co.uk, and says it will contact you within 3 working days. The BBFC says to contact the mobile operator first; if that does not resolve it, the site can appeal to the BBFC, which reviews websites that say a network is over-blocking them.

Sources: Three, Blocking and unblocking 18+ content · Mobile UK, Codes of practice · BBFC, Mobile phones and filters; all checked 11 November 2026

Could your own rate limit or bot rule be blocking phones?

Yes: this cause is on your side, not the provider's. Many mobile networks, and some home networks, use carrier-grade NAT, which means one public IPv4 address is shared by many subscribers at once. A rule that counts or blocks by IP address then treats all of them as one visitor. The IETF's analysis of address sharing warns that one user who fails several logins can lock out other users on that address. Cloudflare measured the effect in 2025: addresses behind carrier-grade NAT were rate limited three times more often than other addresses, even though their bot scores pointed to human visitors.

Cloudflare's rate limiting rules offer a counting option, "IP with NAT support", that tells visitors behind one address apart with a cookie. Visitors who block or clear cookies still share one counter.

Sources: IETF RFC 6888, April 2013 · IETF RFC 6269, June 2011 · Cloudflare blog, 29 October 2025 · Cloudflare docs, rate limiting parameters, checked 11 November 2026

iPhone users add one more twist. With iCloud Private Relay, the site sees a relay address that may be shared by several users in the same area, and Apple asks site owners to treat these addresses like large carrier-grade NAT addresses. Private Relay can be turned off for one Wi-Fi or one cellular network, so the same phone can reach you from a relay address on one connection and from the operator's address on the other.

Sources: Apple Developer, Prepare your network or web server for iCloud Private Relay · Apple Support, Manage iCloud Private Relay; both checked 11 November 2026

Does IPv6 make a difference on mobile?

It can, because some mobile networks give phones only IPv6 addresses and translate to IPv4 only when needed. The IETF's 464XLAT design describes exactly this for IPv6-only networks, with the customer-side translator running on the phone itself. Telekom's help glossary says it uses 464XLAT on its IPv6-only mobile access point. A phone on such a network may reach your site over IPv6 while a home line reaches it over IPv4. If your domain publishes an IPv6 address (an AAAA record), test the IPv6 path on its own: the server, the firewall, allowlists and any geo rule.

Sources: IETF RFC 6877, April 2013 · Telekom hilft, Glossar: 464XLAT, checked 11 November 2026

Is your own geo rule placing mobile visitors in the wrong place?

It may. Behind carrier-grade NAT, a subscriber is located wherever the provider's shared addresses appear to be, which is very often a different city from the subscriber. Apple says Private Relay keeps the visitor's region and, by default, coarse city. A rule that is strict about city or region can therefore let a visitor in at home and turn the same visitor away on mobile data.

Sources: IETF RFC 6269, section 7 · Apple Developer, checked 11 November 2026

How do you tell these causes apart?

1. Get the names. Ask which provider the phone is on, which provider the home line is with, and whether a family or security filter is on in the mobile account.
2. Get what they saw. A provider's notice or warning page points to a filter or block list. A challenge or "access denied" page from your CDN usually points to your own rules, or to a legal block (see HTTP 451). A connection error or a browser security error points to DNS or the network: in our own measurements in Germany in November 2026, a visitor sent to a notice server over https usually saw a browser security error, not the notice.
3. Look at your own logs. If requests from that time arrived and got a 403, 429 or a challenge, the cause is your rate limit, bot rule or geo rule. If nothing arrived, the visitor was stopped before your server, by DNS or the network.
4. Test IPv6 separately if you publish an AAAA record.

A datacenter uptime monitor sees none of the provider-side causes; see why datacenter monitors miss ISP blocks.

What linkspect shows for home and mobile

linkspect opens your URL through real customers' connections and answers home broadband and mobile separately for each provider: in Germany Telekom, Vodafone and O2 on both; in Poland Orange, Play, Netia and T-Mobile on home broadband and Play and Plus on mobile; in Norway Telenor and Ice on mobile only. When your own anti-bot or geo rule turns our test away, the answer reports that your site refused us, not a block. A DNS block on a mobile network is marked "likely" at most, because we only see the answer the customer's phone got (verdict reference). Get early access or read the API quickstart.