The Hotspot Trap: Why Your App Works on Wi-Fi But Breaks on Mobile Data

TL;DR: If your deployed app loads fine on your home network but throws a "Server Not Found" when you switch to a mobile hotspot, your carrier's DNS resolver is likely the culprit — not your code. Diagnosis takes under a minute. Fix takes under five. Switch to Cloudflare (1.1.1.1) or Google (8.8.8.8). This post walks you through it.

The War Story

It was 11:30 PM. The deployment was done. Railway showed green. The environment variables were correct. The build logs were clean.

I opened my browser on my laptop — connected to my home fiber — and the app loaded perfectly. Smooth, fast, exactly as expected.

Then I did what every developer does before calling it a night: I grabbed my phone to do a quick sanity check over mobile data.

Connecting...

Connecting...

Server Not Found.

The next 45 minutes were a spiral. I re-checked the Railway dashboard. I re-read the .env file. I redeployed. I cleared browser cache. I checked if the domain was propagated. Everything pointed to "it should be working."

It was working. Just not for me. Not on that network.

The bug wasn't in my code. It wasn't on my server. It was sitting quietly inside my mobile carrier's DNS resolver — and it had been silently breaking my app for anyone connecting through that network.

What's Actually Happening: The DNS Resolution Path

When you type a URL into your browser, your device has no idea where that server physically lives. Before it can make a single HTTP request, it has to ask a question: "What's the IP address for this domain?"

That question goes to a DNS Recursive Resolver — a server whose job is to translate human-readable domain names into IP addresses. By default, when you connect to a mobile hotspot, your device inherits whatever DNS server your carrier provides.

This is where the trap is set.

Unlike major ISPs or public DNS providers that run high-capacity, standards-compliant resolvers, mobile carriers optimize their DNS infrastructure for cost and control — not developer reliability. This creates three specific failure modes:

1. Wildcard Resolution Failure Modern cloud platforms like Railway, Render, and Vercel use wildcard DNS records (e.g., *.railway.app) to route traffic to your specific deployment. Some carrier DNS servers are simply not configured to handle these nested subdomain patterns correctly. The result is a flat NXDOMAIN — "this domain does not exist" — even though it very much does.

2. Aggressive Caching Beyond TTL Every DNS record carries a TTL (Time To Live) value — an instruction that says "cache this for X seconds, then ask again." Carriers routinely ignore this and cache records far longer than specified. If your app's IP address changed during a recent deployment (which it often does on cloud platforms), your carrier might be routing traffic to a ghost — an old, decommissioned IP.

3. Content Filtering and Pattern Matching Some carriers run DNS-level "security" filters that flag domain patterns associated with developer tooling and cloud platforms as unverified or suspicious. Your perfectly legitimate your-app.up.railway.app gets silently blocked by a filter written to catch something else entirely.

Diagnosing It: Proving DNS Is the Problem

Don't guess. Prove it. Open your terminal and run two commands.

Step 1 — Query your current (carrier) DNS:

bash

nslookup your-app.up.railway.app
```

If you see something like this, your carrier is failing the resolution:
```
** server can't find your-app.up.railway.app: NXDOMAIN

Step 2 — Query a public DNS resolver as the control group:

bash

nslookup your-app.up.railway.app 8.8.8.8
```

If *this* returns a valid IP address:
```
Name:    your-app.up.railway.app
Address: 66.33.22.64

Then the diagnosis is confirmed. The internet knows exactly where your app is. Your carrier doesn't — or won't tell you.

You can also use dig if you prefer its output format:

bash

# Carrier DNS
dig your-app.up.railway.app

# Force Google DNS
dig your-app.up.railway.app @8.8.8.8

The Fix: Switch to a Public DNS Resolver

The solution is straightforward: tell your operating system to stop asking the carrier and start asking a more reliable resolver.

Recommended Public DNS Providers

Cloudflare (1.1.1.1) is the recommended default for developers — it consistently benchmarks as the fastest resolver globally and has a strong privacy stance (no query logging sold to advertisers).

Windows 11 / 10

1. Open Settings → Network & internet → Wi-Fi

2. Click on your hotspot connection name, then click Properties

3. Scroll to DNS server assignment and click Edit

4. Select Manual, then toggle IPv4 to On

5. Enter 1.1.1.1 in Preferred DNS and 1.0.0.1 in Alternate DNS

6. Click Save

After saving, flush your DNS cache to immediately clear stale records:

cmd

ipconfig /flushdns

You should see: "Successfully flushed the DNS Resolver Cache."

macOS (Sequoia / Sonoma / Ventura)

1. Open System Settings → Network → Wi-Fi

2. Click Details... next to your active hotspot connection

3. Select the DNS tab in the left sidebar

4. Click the + button under DNS Servers and add:

   • 1.1.1.1

   • 1.0.0.1

5. Remove any existing carrier DNS entries if present

6. Click OK, then Apply

To flush the DNS cache on macOS:

bash

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (Ubuntu / Debian with NetworkManager)

The most robust approach on Linux is to use nmcli — this ensures the settings persist across reboots and reconnections, unlike editing /etc/resolv.conf directly (which NetworkManager will overwrite).

bash

# Replace "YourHotspotName" with the exact SSID of your hotspot connection
sudo nmcli connection modify "YourHotspotName" ipv4.dns "1.1.1.1 1.0.0.1"

# Prevent NetworkManager from overwriting your DNS with carrier-provided values
sudo nmcli connection modify "YourHotspotName" ipv4.ignore-auto-dns yes

# Apply the changes immediately
sudo nmcli connection up "YourHotspotName"

To verify the change took effect:

bash

nmcli connection show "YourHotspotName" | grep dns

To flush the cache:

bash

sudo systemd-resolve --flush-caches

Android (on the hotspot device itself)

If you want to fix DNS at the source — on the phone creating the hotspot — Android 9+ supports Private DNS:

1. Go to Settings → Network & internet → Advanced → Private DNS

2. Select Private DNS provider hostname

3. Enter: one.one.one.one (Cloudflare) or dns.google (Google)

4. Tap Save

This applies encrypted DNS-over-TLS for all connections on the device, including when it's sharing a hotspot.

Why This Matters Beyond the Hotspot

This issue isn't just a local inconvenience. The same carrier DNS problem affects a percentage of your real users. Anyone on a mobile carrier with aggressive filtering or broken wildcard resolution may be hitting the same silent failure — they just see a broken app and leave without reporting it.

Switching to Cloudflare or Google DNS on your development machine ensures you're testing through the same reliable resolution path your users on good resolvers are using. It makes your development environment a more honest simulation of production.

Closing Thought

The most disorienting bugs are the ones that live outside your codebase. You can't console.log your way to a carrier DNS misconfiguration. You can't fix it with a redeploy.

But once you know the failure mode, the diagnosis takes under a minute and the fix takes under five. That 45-minute spiral at 11:30 PM doesn't have to happen to you.

Change your DNS. Flush your cache. Move on.

Have you run into the hotspot trap before? Drop a comment — I'm curious how many developers have lost hours to this before finding the root cause.