Sometimes your Mac shows it’s connected through mobile data (personal hotspot or USB tethering), but websites fail—or they work in Safari and not in Chrome/Firefox (or the other way around). This is usually a browser-specific setting colliding with how mobile networks handle DNS, proxies, and privacy features.
Work through the steps below in order; they’re designed to isolate whether the problem is the network, the browser profile, or a privacy/security feature.
1. Confirm it’s actually browser-specific (quick A/B test)
Before changing anything, test the same site in all three browsers using a clean state.
- Try one simple site: https://example.com (rules out heavy scripts).
- Try one “real” site that’s failing (sign-in, banking, news, etc.).
- If possible, open a Private Window (Safari) / Incognito (Chrome) / Private Window (Firefox) and test again.
If it fails in only one browser, skip ahead to the section for that browser. If it fails in all browsers, focus on DNS/proxy/VPN steps first.
2. On mobile data, disable browser-secure DNS (DoH) temporarily
Secure DNS (DNS over HTTPS) can be great, but some mobile networks and hotspots behave oddly with it—especially when a carrier is doing DNS interception, filtering, or traffic shaping. The result can look like “internet works but websites don’t.”
- Chrome: Settings → Privacy and security → Security → Use Secure DNS → toggle off (or switch provider).
- Firefox: Settings → Privacy & Security → DNS over HTTPS → set to Off.
- Safari: Safari doesn’t expose a simple DoH toggle in the browser the same way; it relies more on system networking. If Safari works but Chrome/Firefox don’t, this step is a strong clue.
Retest the failing site after changing only this one setting.
3. Check for a proxy that only one browser is using
It’s common to end up with a proxy in one browser (or via a profile/extension) even when macOS has no proxy set. On mobile data, a proxy mis-match can break HTTPS sites or cause endless loading.
- macOS system proxy: System Settings → Network → (your tethering/hotspot connection) → Details → Proxies → ensure nothing unexpected is enabled.
- Firefox-specific: Settings → General → Network Settings → Settings… → try Use system proxy settings (or temporarily No proxy for testing).
- Chrome: Uses the system proxy by default—so if Chrome fails but Safari works, look harder at extensions/VPN/security tools.
If changing proxy settings fixes it, undo any “auto proxy configuration URL” you don’t recognize.
4. Turn off “limit cross-site tracking” features briefly to test sign-in loops
Mobile data networks sometimes add extra redirects (carrier portals, anti-fraud checks, bot protection). When combined with strict tracking/cookie rules, some sites fail only in one browser—often as a blank page, stuck spinner, or repeated sign-in prompt.
- Safari: Settings (Safari) → Privacy → temporarily toggle off Prevent cross-site tracking and retest. Turn it back on after testing.
- Firefox: Enhanced Tracking Protection → set to Standard for a quick test.
- Chrome: Privacy and security → Third-party cookies → allow temporarily for the specific site (or test in Incognito with extensions disabled).
If this fixes only one site (especially sign-in/checkout), keep your privacy settings but add a site-specific exception rather than leaving protections off globally.
5. Disable extensions (Chrome) and content blockers (Safari) just for testing
On mobile data, some sites deliver different scripts/CDNs than on home Wi‑Fi. That can trigger ad blockers, privacy extensions, or “security” extensions to block essential resources.
- Chrome: Visit chrome://extensions → toggle off all extensions → retest. If it works, re-enable one-by-one.
- Safari: Safari → Settings → Extensions → turn off content blockers temporarily, or disable only for the failing website if your blocker supports it.
- Firefox: Add-ons and themes → Extensions → disable temporarily.
A common pattern: Safari works (because no blocker is installed), while Chrome fails due to one extension.
6. Reset the browser’s network state (cache, site data, and “HSTS” issues)
If a site previously loaded a strict security rule (HSTS) or cached a redirect that doesn’t work well on mobile data, one browser can get “stuck” while others keep working.
- Chrome: Settings → Privacy and security → Delete browsing data → clear Cached images and files (you usually don’t need to wipe passwords). Also try removing site data for just that site in Site settings.
- Safari: Safari → Settings → Privacy → Manage Website Data → search the site → Remove.
- Firefox: Settings → Privacy & Security → Cookies and Site Data → Manage Data → remove the site.
If you’re seeing certificate warnings only in one browser, don’t click through. Treat that as a red flag and continue to the next steps.
7. VPN, iCloud Private Relay, and “security” apps: test with them off
Mobile data + VPN + certain DNS settings can create a triple-stack that breaks MTU/fragmentation or blocks specific CDNs. Also, one browser may route differently depending on system settings.
- Temporarily disconnect any VPN and retest.
- If you use iCloud Private Relay, try turning it off briefly (System Settings → Apple ID → iCloud → Private Relay).
- If you have a “web protection” or “network filtering” security tool installed, pause it briefly to test.
If turning one of these off fixes it, you’ve found the layer to reconfigure (split tunneling, DNS choice, or filtering rules).
Final thoughts
When mobile data is connected but browsing fails on Mac, the deciding factor is often a browser-only feature like Secure DNS, tracking protection, or an extension—especially if Safari and Chrome/Firefox behave differently.
If none of the steps change anything across all browsers, the issue is more likely the hotspot/carrier path (DNS, filtering, or a captive portal), so testing another phone/network is the fastest way to confirm.