Mobile Data Works, Wi-Fi Does Not (or the Reverse)

Same account, same phone: it works fine on Wi-Fi and fails the moment you switch to mobile data — or the other way around, working fine out and about and then failing the second you get home and join Wi-Fi. This kind of "fine on one, broken on the other" pattern already rules out the account and the client itself: there is only one account, the client has not changed, and it works correctly on at least one network, so the problem lives in the specific network environment, not in broken software.

The real cause sits in how differently Wi-Fi and mobile data are managed: one is run by a router and a broadband provider, the other by a cell tower and a mobile carrier, and what each side restricts, and how much, has never followed the same rulebook. This article gives a thirty-second way to pin down which side is at fault, then covers the most common cause on each side separately. The rule still applies: change one condition at a time. Change the network, the node and settings all together, and even once it starts working again, you will not know which change actually did it.

Figure out which side is at fault first

The first step is always confirming the symptom itself: test each network on its own once, to make sure it really is "only one side fails," rather than both being a little off to different degrees, or a single test just catching a random blip.

Once that is clear — say Wi-Fi will not load anything at all while mobile data works fine — add one more step: turn on the phone's hotspot and connect a computer or another device to it. This separates two variables that otherwise get tangled together, "type of network" and "this specific connection": if the hotspot fails too, the problem more likely sits with the device or the account rather than Wi-Fi itself; if the hotspot works fine, that fairly reliably confirms this particular Wi-Fi has a targeted restriction, rather than "Wi-Fi in general" being the problem.

This step matters because "Wi-Fi" is not one single thing: home Wi-Fi, office Wi-Fi and a coffee shop's Wi-Fi are three completely different connections behind the same label, each restricted in its own way. Skip the hotspot cross-check and it is easy to mistake "this one Wi-Fi has a problem" for "Wi-Fi as a network type has a problem," and the next Wi-Fi you try somewhere else can flip the conclusion entirely.

What actually differs between Wi-Fi and mobile data

The two routes differ completely, both in how they are managed and in how much you can personally change, which is exactly why the same client, on the same account, behaves differently on each.

One pattern falls out of this table: when Wi-Fi is the problem, you usually have a lever to pull (the router's settings); when mobile data is the problem, your options are limited, and mostly amount to confirming whether it is the carrier's policy rather than actually being able to change anything. That is also why "one side fails" tends to be something you can fix yourself on the Wi-Fi side, while on the mobile-data side the most realistic outcome is often confirming the cause and working around it rather than truly fixing it.

If Wi-Fi is the one that fails

Start by identifying what kind of Wi-Fi this is: home, office, school, or a fully public venue network. Office and campus networks fail far more often, because whoever manages them typically restricts anything identifiable as an encrypted protocol or unknown traffic, a routine network-management practice rather than something aimed at any specific product. Public venue Wi-Fi commonly needs a portal login before it will pass real traffic; until that login completes, all encrypted traffic gets blocked, which looks exactly like "the VPN will not connect" while having nothing to do with the VPN at all.

Confirm the portal login actually completed first: plenty of public Wi-Fi networks require clicking through a page before anything else works, and until that happens all encrypted traffic gets blocked regardless of the VPN. Completing it usually fixes everything at once. On a home router, check whether an extra security mode or a parental-control feature is switched on, and disable it temporarily to test. Test again before deciding whether to turn it back on. A corporate or campus restriction is usually not something you can unilaterally fix; the most realistic goal is confirming whether it is really being restricted rather than finding a way around it. What to do when an office or campus network blocks a VPN covers this in more depth.

If mobile data is the one that fails

Check whether every app is affected, or only the features that need an encrypted connection: if only encrypted traffic fails to get through while every other app works fine, that points at the tower or the plan handling that kind of traffic differently, not a lack of signal. Full signal bars, pages loading, messages sending and receiving normally, but the VPN either will not connect or drops right after — that combination is the typical shape of this cause.

Try manually switching network mode (between 4G and 5G, for instance) or toggling mobile data off and on; this sometimes gets around a tower's temporary bad state, and this kind of problem is often transient, clearing up once you move into a different tower's coverage. If mobile data alone keeps failing consistently across different times and different locations, that points away from a temporary tower issue and toward something at the plan or carrier-policy level, worth checking the plan's terms for anything about encrypted traffic; this is not something the client can fix, and switching nodes or clients will not help either.

Both connect, but they behave differently

There is another case that is not "one side fails outright" but both connecting while speed and stability clearly differ — smooth on Wi-Fi, frequently choppy on mobile data, or the reverse. This is not "not working"; the cause is usually that the two routes simply have different bandwidth and congestion right now, a different problem from the restrictions covered above, and chasing it with the same troubleshooting only wastes time.

The key distinction is that "does it connect" and "how good is it once connected" are two separate questions. This article is about the first one giving a different answer on each side. A different answer to the second one is normal variation in network quality — home broadband and a phone tower are simply not the same tier of connection, and mobile data in an area with mediocre signal is always going to be less consistent than stable home broadband.

This case is better handled as a speed problem: the six checks in VPN running slow: check these six things first apply just as well here, just test each network separately and compare rather than assuming both sides should be equally fast. If it shows up more clearly while watching video, Video keeps buffering: quality, route or device has a more targeted way to tell them apart.

In summary

When one network works and the other does not, confirm the symptom itself first, cross-check with a third network — a phone hotspot — and then work through the Wi-Fi or mobile-data direction that actually applies. The two routes are managed in completely different ways, and guessing across both at once just wastes time. If both connect and only their behaviour differs, that is a speed problem, not the kind of "not working" this article covers.

The most practical way to run into this less is to let the client adapt to different networks on its own, instead of reconfiguring something every time you change location. FastOrange does not need manual adjustment when switching between Wi-Fi and mobile data. Every registered account gets free trial time daily, enough to test home, office and mobile data — the networks you actually use — ahead of time, so you already know which one holds up best before you are out somewhere relying on it. If one type of network keeps failing over the long run, telling support the specific situation and what you have already tried gets you an answer faster than troubleshooting it yourself again each time.