Why does my site work on Wi-Fi but not on mobile data?

Publishing an AAAA record tells every client the site can be reached over IPv6 at that address.

On a dual-stack home network, a client that cannot connect over IPv6 falls back to IPv4 within a fraction of a second, so the fault is invisible.

Many mobile networks are IPv6-only, reaching IPv4 sites through translation — and translation is only used when a site publishes no IPv6 address of its own.

So a published but broken IPv6 address leaves a phone on such a network with no working path at all.

Typical causes are a firewall that allows IPv4 and not IPv6, a server not listening on its IPv6 address, or an AAAA record left behind after a host move.

The phone on mobile data uses the carrier's DNS resolver; the laptop at home uses the router's or the ISP's.

After a DNS change, each resolver keeps the old answer until its cached copy expires, so the two networks can disagree for the length of the old TTL.

If the old address no longer serves the site, one network works and the other fails until its cache expires.

Two records that conflict — two different addresses where there should be one — can make the answer vary between resolvers even without a recent change.

Comparing the answers from several public resolvers shows whether the record has settled.

Mobile carriers put very many subscribers behind a small number of shared public addresses.

A rate limit or firewall rule keyed on the client address can therefore trip on a carrier address long before any single visitor does anything unusual.

Some protection services also score carrier ranges differently, and a rule blocking by country or network can catch them.

The symptom is usually an error page or a challenge rather than a connection failure, which distinguishes it from the IPv6 case.

The firewall or CDN logs will show the blocked requests if this is the cause.

Some mobile operators apply content filtering to subscriber connections by default, and a site can be miscategorised by it.

The result is usually a block page served by the operator rather than by your site.

It affects only customers of that operator, which is how it can be told apart from the other causes.

The remedy is a recategorisation request to the operator, not a change to the site.

Look up whether the domain publishes an AAAA record. If it does, test the site over IPv6 specifically — from an IPv6-only connection or a testing service that uses one.

If there is no AAAA record, compare the A record returned by several public resolvers with the address the site is actually served from.

Note what the phone shows: a connection that never starts suggests addressing; an error or challenge page suggests blocking; a page from the operator suggests filtering.

Test from more than one carrier, since a fault limited to one operator narrows the cause immediately.

Removing a broken AAAA record is a valid emergency fix; making IPv6 work is the real one.