My phone had internet. But my Mac didn't. Here's how I fixed it.

I was sitting at my desk during the day, trying to send a quick message on Cliq. It seemed simple enough, but the moment I clicked send, the input box just hung there with the loader spinning endlessly without doing anything.

I picked up my phone to check if the network was down, but the internet was going through perfectly on it. I even checked my Mac’s menu bar — the blue hotspot connection symbol was right there, showing that my laptop knew it was connected to my iPhone, but it still refused to load a single page.

I went through the usual cargo-cult ritual of toggling Wi-Fi off and on, and then flipping Airplane Mode on my phone, but none of it made a difference.

This is where the confusion set in. If the internet is flowing to the gateway (my phone), why is it refusing to pass through to my laptop?

At this point, I decided to switch providers. I was on Airtel, so I switched to MTN. I actually had to do a small N1,500 subscription on the MTN SIM for 2GB or so just to test. I typically avoid MTN subscriptions like the plague because they swallow your data in no time — you do a subscription and it’s gone before you can even blink — but I was desperate.

The switch actually worked for about five minutes, but then the connection went completely dead on me as well.

I restarted my laptop, which managed to restore the connection and was good enough to get me through the rest of that day. But the next day, the exact same thing happened. I restarted the laptop again, thinking it was the magic fix, but this time it didn’t work at all.

Now I was completely stuck. I was trying to record a demo video, but I couldn’t load the page I needed to show. I spent 30 minutes toggling airplane mode, restarting, and switching between MTN and Airtel. I even went as far as buying a N5,000 subscription for 30GB on Glo, desperately hoping a third carrier would finally save me.

Glo worked at first, but then it inevitably stopped working just like the others.

Around that time, I saw a tweet thanking someone for a network speed fix, showing before-and-after results.

thanks for this btw
before and after https://t.co/ccTzHAPa3e pic.twitter.com/6W1QIl4oxj

— giyu_codes (@giyu_codes) May 21, 2026

It clicked. The tweet linked to some diagnostic steps, and I thought, what if I tried the same principle to figure out my problem? This is what kickstarted me actually trying to debug the connection problems instead of just blindly swapping SIMs, buying subscriptions, or restarting my laptop.

As it turns out, the issue wasn’t the carriers, the signal, or the Wi-Fi radio. It was a silent routing bottleneck involving packet fragmentation (MTU), DNS resolution, and virtual networks.

# 1. Force Wi-Fi MTU down to a hotspot-safe value
networksetup -setMTU Wi-Fi 1280

# 2. Use direct DNS instead of the carrier/hotspot path
networksetup -setdnsservers Wi-Fi 8.8.8.8 8.8.4.4

# 3. Stop Tailscale from hijacking normal DNS lookups
tailscale up --accept-dns=false

Figuring out where the path actually breaks

When you connect a Mac to an iPhone hotspot, you’re routing through three distinct hops:

1. Your Mac to your phone (local Wi-Fi)
2. Your phone to the tower (cellular gateway)
3. Your Mac’s network configuration (logical routing)

My phone was browsing fine because it only dealt with hop 2. My laptop, however, had to navigate the logical path in hop 3.

Here is exactly how I diagnosed the break in that path.

Checking if the link to my phone is actually working

I needed to see if the Wi-Fi link to my phone was actually dropping, so I checked the Wi-Fi interface:

ifconfig en0

I was looking for status: active and a local IP address in the hotspot range, usually something like 172.20.10.x on an Apple hotspot.

You can also ask macOS for the Wi-Fi service details:

networksetup -getinfo Wi-Fi

The “Router” value is usually the phone. On an Apple hotspot, that is typically 172.20.10.1.

So I ran a continuous ping to it:

ping -c 20 172.20.10.1

The result was zero packet loss and steady response times of about 3 to 5 milliseconds. This is like calling your estate gatehouse on the intercom — it rings instantly with zero static. The wire from your house to your gate is perfectly fine, meaning the physical link between my laptop and phone was solid.

Seeing if packets can reach the wider internet

Next, I pinged a public IP directly to bypass DNS:

ping -c 20 8.8.8.8

When I ran that, packets immediately started dropping. If pinging the phone is the intercom, pinging 8.8.8.8 is like trying to call someone across town and finding the phone lines are dead. It proved my local link (house to gate) was perfect, but the main road leading out of the estate was completely blocked.

Why your carrier silently drops larger packets

Standard Ethernet and Wi-Fi networks expect a Maximum Transmission Unit (MTU) of 1500 bytes — the largest packet size an interface will try to send.

But cellular carriers handle things differently. Think of standard Wi-Fi networks as accepting envelopes up to a strict size limit (1500 bytes). Cellular carriers, however, are like paranoid security couriers — they insist on sealing your envelopes inside their own thick, plastic security pouches before putting them on the delivery truck.

If your laptop sends an envelope that is already at the maximum 1500-byte limit, wrapping it inside that carrier pouch makes the whole package too large. The sorting machine silently tosses it into the bin because it won’t fit through the scanner slot. This is what creates a “Path MTU Black Hole.”

I tested different packet sizes using the “Don’t Fragment” flag (-D on macOS):

# Test payload of 1472 + 28 bytes header (MTU 1500)
ping -D -s 1472 -c 3 8.8.8.8

# Test payload of 1372 + 28 bytes header (MTU 1400)
ping -D -s 1372 -c 3 8.8.8.8

# Test payload of 1252 + 28 bytes header (MTU 1280)
ping -D -s 1252 -c 3 8.8.8.8

For me, every packet larger than 1280 bytes failed with Message too long or simply vanished, indicating that the safe minimum for carrier networks was exactly 1280 bytes.

To temporarily lock the Wi-Fi interface MTU to this safe value, you can run:

networksetup -setMTU Wi-Fi 1280

The moment I ran this, packet loss to 8.8.8.8 dropped from around 9% down to exactly 0%.

Bypassing your mobile provider’s slow DNS

When connected to a cellular hotspot, macOS defaults to routing DNS queries through your phone (172.20.10.1), which then asks your mobile carrier’s slow, congested servers.

Before changing anything, I checked the DNS state:

scutil --dns

I tested the default gateway speed against Google’s public DNS:

# Testing default carrier DNS
time dig apple.com @172.20.10.1

# Testing Google DNS
time dig apple.com @8.8.8.8

The query to my phone took over a second (or simply timed out), while the query to Google DNS resolved in about 34ms. To bypass that sluggish carrier lookup, I hardcoded Google’s public DNS servers for my Wi-Fi interface:

networksetup -setdnsservers Wi-Fi 8.8.8.8 8.8.4.4

Getting virtual networks out of the way

I use Tailscale to connect to my VPS, which means I have virtual interfaces (utun) running on my laptop.

Mesh networks and VPNs often try to hijack your system DNS to resolve private nodes. On a shaky hotspot connection, these loopback lookups introduce extra overhead that easily hangs your entire browser.

You can quickly check for the usual suspects:

ps aux | grep -iE 'tailscale|vpn|wireguard|cloudflare|warp|windscribe'

You can keep your mesh network active while preventing it from overriding your direct system DNS by running:

tailscale up --accept-dns=false

This keeps your private VPS routes open while allowing your normal web traffic to use the fast, direct Google DNS.

Solving the annoying macOS reset quirk

While applying these commands worked instantly, I quickly ran into a major catch.

Whenever you switch hotspots, cycle Airplane Mode, or toggle your Wi-Fi, macOS silently resets your Wi-Fi MTU back to the default 1500. The moment I swapped between Airtel and MTN, the disconnects returned because macOS had wiped my custom settings behind my back.

I didn’t want to spend my days manually running shell commands or checking networksetup every time I reconnected — relying on my own memory is just too much friction. If you switch SIMs or hotspots, you can check the MTU again by running:

networksetup -getMTU Wi-Fi

If it has gone back to 1500, you’ll need to set it back to 1280:

networksetup -setMTU Wi-Fi 1280

Automating the fix so I never have to run it manually

Relying on manual commands wasn’t a real solution, because the connection issues would return the moment macOS silently rebuilt the network state.

Here is the problem: macOS is like an overzealous house-cleaner who resets your customised standing-desk height back to the “standard” setting the moment you step out of the room or turn off the lights (disconnecting Wi-Fi). The moment I swapped between Airtel and MTN, macOS wiped my custom settings behind my back.

To solve this once and for all, I set up a Launch Agent. It’s like hiring a helper whose only job is to sit in the room, watch the cleaner, and immediately adjust the desk back to your height the millisecond they touch it. It keeps a small script running in the background to ensure my Wi-Fi MTU stays locked at 1280.

Save this as ~/.local/bin/enforce-hotspot-mtu.sh:

#!/bin/bash
current_mtu=$(networksetup -getMTU Wi-Fi | awk '{print $NF}')

if [ "$current_mtu" -ne 1280 ]; then
    networksetup -setMTU Wi-Fi 1280
fi

Make it executable:

chmod +x ~/.local/bin/enforce-hotspot-mtu.sh

Then create a Launch Agent at ~/Library/LaunchAgents/com.user.hotspotmtu.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.hotspotmtu</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/user/.local/bin/enforce-hotspot-mtu.sh</string>
    </array>
    <key>WatchPaths</key>
    <array>
        <string>/Library/Preferences/SystemConfiguration</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Load it:

launchctl load ~/Library/LaunchAgents/com.user.hotspotmtu.plist

That keeps the fix from depending on whether I remember to run a command after switching networks.

Checking my work

After applying the changes, I used these checks to make sure the connection was actually working:

networksetup -getMTU Wi-Fi
networksetup -getdnsservers Wi-Fi
ping -c 10 -i 0.5 172.20.10.1
ping -c 10 -i 0.5 8.8.8.8
curl -sS --max-time 10 https://www.gstatic.com/generate_204 -o /dev/null -w 'HTTP Status: %{http_code} Total Time: %{time_total}s\n'

The goal is:

• MTU shows 1280.
• DNS shows 8.8.8.8 and 8.8.4.4.
• The phone gateway has 0% packet loss.
• The internet ping has 0% packet loss.
• The generate_204 check returns quickly.

Leaving an escape hatch

If you need to undo the manual settings, use:

networksetup -setMTU Wi-Fi 1500
networksetup -setdnsservers Wi-Fi Empty

If you do not want the Launch Agent and only want a quick manual shortcut, you can add this alias instead:

echo "alias fix-hotspot='networksetup -setMTU Wi-Fi 1280 && networksetup -setdnsservers Wi-Fi 8.8.8.8 8.8.4.4 && tailscale up --accept-dns=false'" >> ~/.zshrc
source ~/.zshrc

Now, whenever your hotspot begins to crawl or drop, simply open your terminal and type fix-hotspot to resolve it instantly. You’re welcome.

If your hotspot is now connected but still feels slow, check out the second part of this network series: How I sped up internet on my Mac to compare MTU, DNS, packet loss, and loaded latency before making more changes.

Cheers 🥂