How I Finally Solved the Persistent DNS_PROBE_FINISHED_NXDOMAIN Error on My Custom Domain

For three days, my portfolio website completely vanished on my laptop. Instead of my homepage, I was greeted with a frustrating browser error: DNS_PROBE_FINISHED_NXDOMAIN. 

I was using a free domain from DNSExit and mapping it to GitHub Pages for my project (a medical ecommerce store). I tried everything I knew—clearing my recent browser history, flushing my DNS, and even switching networks. Nothing worked. 

But then things got weird: when I turned off my home Wi-Fi and checked the site on my mobile phone using cellular data, the website loaded perfectly! 

I couldn't find the exact cause online right away. Why would a site be completely alive to the rest of the world and my phone, but stubbornly dead on my laptop? After digging deep into network routing and system-level hardware behavior, I finally uncovered the hidden trap. Here is exactly what happened and how I fixed it. 

Finding the Root Cause: The Setup Mismatch

When I first encountered the error, I realized my layout had two initial configuration mismatches between GitHub Pages and my domain registrar: 

1. The Subdomain Conflict: I had originally set my GitHub Pages custom domain field to include the www prefix (www.example.com), which was causing a conflict with how the root apex domain was resolving.
2. Redundant A Records: In my DNSExit dashboard, I had multiple repetitive, duplicate rows instead of a clean profile mapping.

I fixed the source settings by clearing out the duplicates in DNSExit, ensuring I had exactly four clean A Records pointing to GitHub’s official server IPs: 

• 185.199.108.153
• 185.199.109.153
• 185.199.110.153
• 185.199.111.153

Then, I went back to GitHub Pages settings and changed my custom domain box to the clean root domain: example.com (without the www). 

GitHub instantly gave me a green "✓ DNS check successful" badge. I thought I was done. But when I refreshed my laptop's browser... the NXDOMAIN error was still there. 

The Hidden Trap: Why My Laptop Stayed Broken

This is the exact point where most developers get stuck. If GitHub says the DNS check is successful, why is the laptop still failing? 

The answer comes down to a hidden hardware mechanism called TTL (Time to Live) and browser Connection Pooling. 

• The 8-Hour Memory: My domain registrar initially defaulted my domain's TTL to 8 hours. This meant that the very first time my laptop and home Wi-Fi router tried to look up my site and failed, they memorized that failure. Even though I fixed the records on DNSExit, my laptop's network card aggressively refused to check the internet for updates, waiting out its internal 8-hour countdown timer.
• Persistent Sockets: When I disconnected from my home Wi-Fi and plugged my laptop into my phone's mobile hotspot, it still failed. This happens because Chromium browsers (like Edge and Chrome) keep open "persistent sockets" (dead network lanes). Instead of searching the new phone network fresh, the laptop tried to reuse the dead lane it built while on the home Wi-Fi.

How the Problem Was Finally Resolved

To prove this theory, a friend connected his laptop to my home Wi-Fi and got the exact same NXDOMAIN error. But instead of waiting 24 hours for the network logs to reset naturally, he used a manual network bypass that forced his computer to pull live updates instantly. 

By manually changing the laptop’s active network adapter to use public DNS resolvers instead of our local Internet Service Provider's frozen cache, the site sprang to life immediately on both networks. 

If you are stuck in this exact loop and need your laptop to see your live site right now, follow these steps to bypass the frozen cache: 

1. Press Windows Key + R, type ncpa.cpl, and press Enter.
2. Right-click your active Wi-Fi adapter and choose Properties.
3. Double-click Internet Protocol Version 4 (TCP/IPv4).
4. Select "Use the following DNS server addresses" and enter: 

• Preferred DNS Server: 8.8.8.8 (Google Public DNS)
• Alternate DNS Server: 8.8.4.4
  1. Check the box for "Validate settings upon exit" and click OK.
  2. Open your Command Prompt as an administrator, run ipconfig /flushdns, and restart your browser.

What I Learned for Next Time

If you don't want to change your network adapter settings, your laptop will still fix itself completely automatically, but you have to wait 12 to 24 hours for the internal cache clocks to hit zero. 

To save yourself this massive headache on your next project, follow these two golden rules the moment you buy a domain: 

1. Lower your TTL immediately: The very first thing you should do in your domain dashboard is change the TTL dropdown from 8 hours to 5 minutes. If you make a configuration mistake, it will clear in minutes rather than a whole day.
2. The Cellular Test is Truth: Always test your custom domain changes on a mobile phone with Wi-Fi completely turned off. If it opens on cellular data, your code and DNS records are perfect—and any error on your laptop is just a local network ghost!