My site worked everywhere except on my own internet

The problem

Every now and then I opened zakariyazouazou.com at home and the page just kept loading. After a while the browser gave up and showed a connection error.

The confusing part:

• With a VPN turned on, the site loaded instantly.
• On my phone's mobile data, the site loaded instantly.
• On my home internet, it hung and failed.

Nothing in my code had changed. But if it happened to me, it could happen to any visitor on the same provider, and to them my portfolio would simply look like it doesn't exist.

The details

"Works on VPN, fails without it" is a strong hint that the problem is on the network path, not in the app. So instead of reading code, I looked at DNS and tested each server address directly.

First, where does the domain point?

dig +short zakariyazouazou.com
# 216.198.79.1

dig +short www.zakariyazouazou.com
# 050f1e20cccdf36a.vercel-dns-017.com.
# 64.29.17.65
# 216.198.79.65

The apex domain (zakariyazouazou.com) has a fixed A record. The www subdomain is a CNAME to Vercel, which hands out different IPs depending on who asks.

Then I tested each IP on its own with curl --resolve, which forces the request to a specific server:

curl --resolve www.zakariyazouazou.com:443:216.198.79.1  https://www.zakariyazouazou.com  # 200, 0.2s
curl --resolve www.zakariyazouazou.com:443:216.198.79.65 https://www.zakariyazouazou.com  # timeout
curl --resolve www.zakariyazouazou.com:443:64.29.17.65   https://www.zakariyazouazou.com  # timeout

And the last piece:

curl -sI https://zakariyazouazou.com | grep -i location
# location: https://www.zakariyazouazou.com/

So this is what a visitor on my ISP went through:

1. The browser opens zakariyazouazou.com → reaches a working IP.
2. Vercel answers with a 308 redirect to www.
3. The browser looks up www → gets an IP my ISP can't reach.
4. It waits... and fails.

The address that worked was redirecting visitors to the address that didn't.

The challenges

• It was intermittent. The www CNAME doesn't always return the same IP, so sometimes it worked and sometimes it didn't.
• It only happened on some networks. A VPN or mobile data takes a different route or gets a different IP, so everything looked fine there. Easy to dismiss as "my internet is bad today".
• Nothing pointed at the real cause. No error in Vercel, no error in the logs. The request never reached the server at all.
• I couldn't fix the ISP. Whatever blocks those IPs is between my provider and Vercel, outside my control.

The solution

If I can't fix the unreachable IPs, I can stop sending people to them. The fix was to make the apex domain the main one, because its IP works.

1. In Vercel → Settings → Domains:

• zakariyazouazou.com → Connect to an environment: Production (serve the site directly, no redirect).
• www.zakariyazouazou.com → Redirect to zakariyazouazou.com with a 308 Permanent Redirect.

2. In the code, everything that still said www had to follow:

// app/lib/site.ts — used for canonical URLs, sitemap and Open Graph
export const SITE_URL = 'https://zakariyazouazou.com';

// next.config.mjs — other domains redirect to the main one
const MAIN = "https://zakariyazouazou.com";

Without this, Google would still be told that www is the "real" page, and my other domains would still send visitors to the unreachable address.

3. In Google Search Console, I resubmitted the sitemap at the new address and requested indexing for the homepage, so Google moves to the apex version quickly.

After the change:

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://zakariyazouazou.com
# 200 0.17s   (no redirect, from the same home internet)

Lessons learned

• "Works on VPN" means look at the network, not the code. DNS and IP routing come before any line of your app runs.
• curl --resolve is the best tool for this. It tests each server IP separately and quickly shows which one is the problem.
• A redirect is only as good as its destination. A working domain that redirects to a broken one is a broken domain.
• Keep one source of truth for your public URL. Because SITE_URL lived in one file, switching the canonical domain was a one-line change.
• Test your site from the networks your visitors use, not only from your own setup. Mobile data, a home ISP and a VPN can give three different answers.