works on wifi but not on data how to diagnose

Not specified by the original author.

TL;DR

When something works on wifi but not cellular, the app is fine and the network path is not. The usual culprits are the carrier's DNS, an IPv6-only path the server mishandles, a VPN or proxy active on data, or the phone blocking the app from using cellular. Test in this order: a different network, DNS, then device settings. You will find it in one of those three.

The query

"works on wifi but not on data" how to diagnose

Use this when

• Users report the app works on wifi but fails on cellular
• The reverse: works on cellular but not on a specific wifi
• Pages load partially or time out on one connection type
• You need to rule out the app before blaming the network

Not for

• General slowness on all connections
• Setting up a wifi router
• Carrier plan, billing, or coverage questions
• VPN product support

Steps

1. Confirm the pattern with a second network

Have the user test on a different wifi network and, if possible, a different carrier's data. If it fails on all cellular but works on all wifi, the pattern is real and it is the data path.

Expected output: confirmation that the connection type is the variable.

2. Check for a VPN, proxy, or private relay on the failing path

Phones often run a VPN or relay on cellular but not on wifi, or the reverse. Have the user disable it temporarily and retest.

Expected output: the VPN is ruled in or out in one test.

3. Test DNS on the failing connection

Carriers run their own DNS, and it misbehaves more often than anyone admits. Have the user switch to a public DNS in the phone's settings, then retest the app.

Expected output: you know if name resolution is the break.

4. Check the app's cellular data permission

Both major phone platforms let users block an app from using cellular data while leaving wifi allowed. This is the most embarrassing cause and the most common one. Check the app's data permission in system settings.

Expected output: permission confirmed on, or the ticket closes in ten seconds.

5. Look at IPv6 and carrier quirks

Some carriers are IPv6-only with translation, and some servers mishandle it. If everything else passes, check whether your service behaves differently over IPv6 and whether other users on the same carrier report it.

Expected output: a carrier-specific issue you can document or escalate with evidence.

Template: what to ask

Quick checks, [Name]:

1. Does it fail on cellular data but work on wifi every time?
2. Is a VPN or private relay turned on?
3. In your phone settings, is [App] allowed to use cellular data?
4. Which carrier are you on?

Variant phrasings

app only works on wifi

Start at step 4. The cellular permission toggle is the top cause.

site wont load on mobile data

Same playbook. Steps 2 and 3 cover most of these.

works on wifi but times out on 5g

Timeouts on data point at DNS or IPv6 translation. Steps 3 and 5.

Why it happens

Wifi and cellular are completely different network paths: different DNS, different IP versions, different middleboxes, different carrier policies. The app sends the same requests, but the network treats them differently. "Works on wifi" tells you the app and server are healthy, which narrows the whole problem to the path in between.

Edge cases

• Corporate or school wifi with a captive portal: the reverse pattern, where wifi is the broken path. Check for a login page intercept.
• Data saver modes: aggressive data savers can block background requests the app needs. Exempt the app and retest.
• eSIM vs physical SIM: provisioning quirks on eSIMs occasionally break data for specific apps. Rare, but worth asking about.
• Roaming: carriers route roaming data through the home network, adding failure points. Ask if they are traveling.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstvn3sc5N5CBtukQpTBz1pQ

Resolved from the public thread: https://vectle.com/posts/pstvn3sc5N5CBtukQpTBz1pQ

Thread query: "works on wifi but not on data" how to diagnose

TL;DR: When something works on wifi but not cellular, the app is fine and the network path is not. The usual culprits are the carrier's DNS, an IPv6-only path the server mishandles, a VPN or proxy active on data, or the phone blocking the app from using cellular. Test in this order: a different network, DNS, then device settings. You will find it in one of those three.

Not specified by the original author.

TL;DR

"The page won't load" is three different problems wearing one sentence: their browser, their network, or your servers. Check your status page first so you never debug a user's laptop during your own outage, then walk the user through cache, DNS, and VPN in that order. The order matters because each step rules out a layer.

The query

"page won't load" support script: cache, DNS, VPN

Use this when

• A page is blank, stuck loading, or times out
• The site loads for you but not the user
• Only one user or office is affected
• The problem started suddenly with no changes
• You are writing the page-load macro

Not for

• Errors that appear after the page loads fine
• Login failures on a working page
• Outages affecting everyone
• Slow pages that do load eventually

Steps

1. Check your status page before touching anything

If your systems are degraded, say so immediately and stop debugging their machine. Nothing burns trust like twenty minutes of cache-clearing during your own incident.

Expected output: outage confirmed or ruled out in under a minute.

2. Get the exact symptom and the exact URL

Blank white page, spinner forever, browser error text, or timeout. Ask them to copy any error text word for word and confirm the URL they used. "It doesn't work" plus a screenshot beats three rounds of guessing.

Expected output: the symptom described precisely, with the URL.

3. Try incognito and a different browser

An incognito window skips cache, cookies, and most extensions in one move. If the page loads there, the problem is their normal browser state, and you go to the cache-clear playbook. If it fails there too, it is network or server.

Expected output: the browser layer confirmed or eliminated.

4. Flush DNS and rule out stale resolution

Have them flush the local DNS cache: on Windows, open Command Prompt and run ipconfig /flushdns; on Mac, restart the browser or reboot. Then retry. Stale DNS sends them to a dead server long after you fixed things.

Expected output: fresh DNS resolution, or the step ruled out.

5. Check VPN, proxy, and corporate filtering

Ask if they are on a VPN or office network, and have them disconnect the VPN or try a phone hotspot. Corporate proxies and VPNs break or block sites constantly, and the fix is on their network side. If the hotspot works, you have your answer.

Expected output: VPN or proxy confirmed as the cause, or ruled out.

Ready-to-use message

Let's narrow this down. First, can you send me a screenshot of
what you see, and confirm the exact page address?

Then try this in order:
1. Open the page in an incognito/private window. If it loads
   there, it's your browser's saved data, and I'll walk you
   through clearing it.
2. If you're on a VPN, disconnect it and retry. Office VPNs
   block sites more often than you'd think.
3. Try your phone's hotspot. If the hotspot works, the issue
   is your office or home network, not our site.

Tell me which step changes things and we'll go from there.

Variant phrasings

website not loading but internet works

Steps 3 through 5. Browser state, then DNS, then the network path.

page stuck on loading spinner

Steps 2 and 3. Pin down whether it is truly stuck or erroring silently, then incognito.

site won't load on office wifi but works at home

Step 5 first. That pattern is the corporate network until proven otherwise.

Why it happens

Loading a page is a chain of about six handoffs: DNS lookup, connection, security check, server response, then the browser assembling the pieces. A failure at any link looks identical to the user, which is a blank page. The script works because it tests each link in order instead of guessing, and the hotspot test is the great divider between "your machine" and "your network."

Edge cases

• Fails in every browser and on hotspot: now it is either your servers or their ISP. Check your status page again and escalate with the evidence trail.
• Only one specific page fails: that page or its data is the problem, not the network. Get the URL and check it yourself.
• Works on wifi but not mobile data, or vice versa: carrier-level filtering or IPv6 quirks. Note the pattern for engineering.
• The user is in a country with heavy filtering: be honest that access may be restricted there, and do not promise workarounds you cannot support.
• Intermittent loading: ask for timestamps of failures. Patterns in time point at server load or scheduled jobs, not the user's setup.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_g8Vl3cbotvXoAu2c7uB8sQ

Resolved from the public thread: https://vectle.com/posts/pst_g8Vl3cbotvXoAu2c7uB8sQ

Thread query: "page won't load" support script: cache, DNS, VPN

TL;DR: "The page won't load" is three different problems wearing one sentence: their browser, their network, or your servers. Check your status page first so you never debug a user's laptop during your own outage, then walk the user through cache, DNS, and VPN in that order. The order matters because each step rules out a layer.

Not specified by the original author.

TL;DR

"It works for me" means the difference is environmental until proven otherwise. Walk the isolation ladder: the customer's browser, their network, their DNS, their region. Test each layer with one question or one tool. Most cases end at browser extensions, corporate proxies, or stale DNS. Escalate only when multiple customers in one region fail together.

The query

site loads for me but not the customer: how to debug

Use this when

• Customers report an unreachable site that works internally
• Writing network triage guides for agents
• Regional or ISP-specific outage reports
• "Down for me" tickets

Not for

• Server outage response (different playbook)
• Application code debugging
• Fixing the customer's ISP
• Load balancer configuration

Steps

1. Define the exact symptom

What does the customer see: timeout, connection refused, certificate error, blank page, or an error page. "Does not load" covers five different problems. Get the exact message or a screenshot.

Expected output: the precise failure mode.

2. Isolate the browser layer

Private window, different browser, cleared cache. Extensions and stale cache cause a large share of these. If it works in a private window, the site is fine and the browser is not.

Expected output: browser layer confirmed or ruled out.

3. Isolate the network layer

Phone on mobile data (different network, different DNS). If it loads there, the issue is the customer's network: corporate proxy, firewall, VPN, or ISP DNS. If it fails there too, keep climbing.

Expected output: network layer confirmed or ruled out.

4. Check DNS and region

Stale DNS on their machine or their ISP's resolver, or a regional CDN edge serving a bad cached copy. Ask when it last worked and whether anything changed. Compare with a global status check from multiple regions.

Expected output: DNS/region cause identified or ruled out.

5. Escalate on pattern, workaround on singles

One customer: give them the workaround for their layer (disable proxy, flush DNS, whitelist the domain). Multiple customers in one region or network: escalate to engineering with the pattern documented.

Expected output: workaround delivered or escalation with evidence.

Template: the debug script

Let us narrow this down, [Name]. A few quick tests:

1. What exactly do you see? (timeout, error message, blank page - a screenshot helps a lot)
2. Try it in a private/incognito window. Does it load there?
3. Try it on your phone with wifi off (mobile data). Does it load there?
4. When did it last work for you? Did anything change since (new VPN, new network, travel)?

Each answer rules out a layer. Send me the results and I will pinpoint it.

Variant phrasings

website down for customer but not me

Steps 1 through 3. Symptom, browser, network.

site unreachable from one location

Step 4. DNS and regional CDN edges.

customer cannot access site

Full ladder. Do not skip layers.

Why it works

Connectivity is a stack, and each layer has a one-minute test. The ladder turns "works for me" from a dead end into a diagnostic: every rung that passes narrows the search. Agents who guess at causes waste tickets; agents who climb the ladder find them.

Edge cases

• Corporate MITM proxies: the certificate error is expected on their network; IT must whitelist or install the cert.
• IPv6-only or IPv4-only mismatches: rare, but "works on phone, not on office wifi" can be this.
• The site blocks their country or IP range: check geo-blocking rules before blaming their network.
• Intermittent: have them note times. Intermittent plus regional usually means a bad CDN edge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstBzyBVkHNjROBX4-IDWrfg

Resolved from the public thread: https://vectle.com/posts/pstBzyBVkHNjROBX4-IDWrfg

Thread query: site loads for me but not the customer: how to debug

TL;DR: "It works for me" means the difference is environmental until proven otherwise. Walk the isolation ladder: the customer's browser, their network, their DNS, their region. Test each layer with one question or one tool. Most cases end at browser extensions, corporate proxies, or stale DNS. Escalate only when multiple customers in one region fail together.