My New .me Domain Broke, But Only on My Wi-Fi

I'd recently bought a new domain, a .me one, to replace the .vercel.app link that was scattered across all my technical profiles, my GitHub README, LinkedIn, everywhere. My portfolio had been sitting on Vercel for 7 to 8 months at that point, working fine the whole time. Pointing the new domain at it had gone smoothly a few days earlier, no issues at all.

So today, while I was in the middle of updating my GitHub README to swap the old link for the new one, I tried opening the .me domain myself just to double check it, and it flat out refused to load. "This site can't be reached." Nothing.

My first instinct was that something had broken on the registrar's side, so I logged into the site I'd bought the domain from and checked everything there. All fine. Then I checked Vercel's deployment logs for the project. Also fine, no errors, nothing flagged. I was genuinely confused at this point, because as far as I could tell, nothing had changed.

Out of curiosity more than expectation, I opened the same domain on my phone. It loaded instantly, no issues. That's when I started suspecting it might be something local rather than something wrong with the site itself.

To rule out a browser problem (I use Brave on my PC and Chrome on my phone), I asked my roommate to try it on his laptop and his phone, both on Chrome. Neither loaded it. So it wasn't a Brave-specific issue either.

At that point I sat down and actually compared notes properly. My laptop: on our PG's Wi-Fi, broken. My roommate's laptop: same PG Wi-Fi, also broken. My roommate's phone: also connected to the same PG Wi-Fi, also broken. My own phone: on mobile data, completely fine.

That was the detail that actually mattered. It wasn't a device thing, wasn't a browser thing. Every device on our PG's Wi-Fi network couldn't reach the domain. The one device that wasn't on that network was the only one that worked. Same domain, same DNS record, same everything, except which network was asking.

What I assumed first, and why it was wrong

My first real theory, once I'd ruled out the registrar and Vercel, was that this was a propagation issue. Vercel, like most CDNs, serves traffic through anycast, the same domain can point to different IP ranges over time as they expand their infrastructure, and I noticed the IPs my domain was currently resolving to looked newer than ones I remembered seeing before. When a CDN announces a new IP block, that announcement has to spread out across thousands of independently run networks via BGP, the protocol that decides how traffic actually finds its way between those networks, and that spread isn't instant or even. Some networks pick it up in seconds, some take longer.

It seemed like a reasonable explanation. New IP range, my ISP just hadn't caught up yet, give it time. I was fairly settled on that being the answer until I actually ran a traceroute and the evidence didn't match it at all.

The four layers

Once the PG Wi-Fi pattern was staring me in the face, I stopped guessing and decided to go through this properly, one layer at a time. Whenever something is "down," there's really four separate things that could be broken: DNS (does the name resolve at all), reachability (can a packet actually get to that IP), the TLS handshake (does the server respond correctly once reached), and content (is what comes back actually right). Each one fails differently, so I wanted to know exactly which one I was dealing with before assuming anything.

Layer 1: DNS.

I queried my domain against two independent resolvers, Google's (8.8.8.8) and Cloudflare's (1.1.1.1), instead of just trusting whatever my laptop's default resolver told me this.

OUTPUT

Both resolvers came back with the exact same IP. That ruled out a stale or poisoned local DNS cache being the culprit, since two completely unrelated resolvers agreeing means the record itself is globally consistent. DNS was fine.

Layer 2: Reachability.

Next I ran curl -v on the domain:

OUTPUT

It showed the usual resolving step, then just sat there at "Trying 216.198.79.1:443..." No connection, no error, nothing, until it eventually timed out. That hang was the first real signal: curl had the right IP in hand and still couldn't get a TCP connection through to it, which meant whatever was broken was happening after DNS but before anything HTTP-related even started.

Layer 3: Isolating it further.

I didn't want to trust curl alone here, since curl still involves some of its own logic on top of the raw connection. So I ran a plain TCP probe straight at the resolved IP, skipping HTTP and TLS completely:

OUTPUT

That failed too, in exactly the same way, just hanging with no response. This stripped away every possible explanation except pure network reachability. It wasn't curl, it wasn't TLS, it wasn't the app. It was the connection itself, at the most basic level.

Layer 4: Checking if the server was actually the problem.

Before assuming this was purely a "my network" issue, I wanted to rule out Vercel actually being down for that IP range. So I used curl --resolve to manually pin my domain to the older IP address it used to sit on, before whatever range shift had happened:

OUTPUT (KEY LINES)

That worked, and worked correctly, serving the actual site. That told me something important: the server itself was completely healthy. This wasn't Vercel being unreachable in general, it was specifically about reaching the new IP range, from this one network.

Layer 5: Comparing across vantage points.

This is the step that actually explained the confusing part. No single device can tell you whether the problem is your own path or the server itself; both look identical from inside one network, it just doesn't work. The only way to actually tell them apart is to ask the same question from multiple places and see where the answers diverge.

That divergence was the proof. It wasn't the server. It was something specific to that one network path.

What the traceroute actually showed

A propagation gap has a specific signature: the trace goes out, reaches some hop, and then just goes quiet. No reply, nothing, because that part of the network genuinely doesn't know the route yet. That's not what I saw.

OUTPUT

Too many hops: pmtu 1492 · Resume: pmtu 1492 — highlighted rows are hops that repeat an address seen earlier in the same trace.

The trace never even left ACT's own network. It got a few hops in, and then started repeating the exact same addresses over and over. Hop 17 was the same address as hop 12. Hop 18 matched hop 13. Then hop 21 matched hop 11, and the loop kept resurfacing those same three addresses through hops 22, 23, and 27, until it hit the maximum hop limit and gave up.

That's a completely different failure from a propagation gap. Think of it like a letter being routed through postal sorting offices. A propagation gap is an office that's never heard of the destination and the letter just dies there, silently. A routing loop is two offices that each think the other one is the right next step, so the letter just bounces between them, getting more and more worn out, until it's declared undeliverable. From the outside both look identical, the site just doesn't load, but they're mechanically nothing alike, and only a hop-by-hop trace (the mechanics of which are covered well here: article) shows you which one you're actually dealing with.

The addresses involved in the loop were all in the 100.64.0.0/10 range, which is CGNAT space, reserved specifically for internal ISP infrastructure and invisible to anything outside that ISP. Seeing that told me exactly where the problem lived: entirely inside ACT's own network, before my traffic even got handed off to the rest of the internet. This wasn't a global BGP thing at all. It was one misconfigured internal route, on ACT's own routers, that only affected traffic headed toward Vercel's new IP block. Every other route on the same connection worked completely normally the whole time.

Why the hotspot wasn't a fix

Switching to my phone's hotspot made the site load instantly, and it's tempting to just call that the fix and move on. But it didn't actually repair anything. It just routed my traffic through a completely different ISP with its own completely separate routing table, one that didn't have the same broken route. The loop on ACT's network was presumably still sitting there the whole time, unaffected by anything I did.

That distinction matters. A propagation gap genuinely does resolve itself over time as networks converge and catch up. A routing loop doesn't. It just sits there until someone on the ISP's side actually goes in and fixes the misconfigured routers. Waiting it out isn't a strategy for this one.

The method, distilled

Looking back, the sequence that actually got me from "site is down" to "my ISP has a routing loop, here's the exact hop" is the reusable part:

1. Query DNS from multiple independent public resolvers → rule out DNS or cache issues.
2. curl -v <hostname> → separates "resolved but didn't connect" from "never resolved."
3. Raw TCP probe on the resolved IP (nc -zv) → isolates pure reachability, no DNS or TLS involved.
4. curl --resolve host:port:ip pinned to an older, known-good IP → proves the server itself is healthy.
5. Compare across independent vantage points → the only way to tell "my path is broken" from "the server is actually down."
6. tracepath / traceroute / mtr → reveals where in the path it breaks, turning "it doesn't work" into a specific, reportable fact.

That last one is the step that turns a vague complaint into something an ISP's NOC team can actually act on. "Your internet is slow" gets you nowhere. A traceroute showing the exact repeating hop sequence, tied to one specific destination prefix, is a bug report.