When a Vercel Custom Domain Works Everywhere Except Some Networks

•10 min read
verceldnsnetworkingdeploymentdebugging

"Sometimes the problem isn't your website. It's the road between the user and the server."

I recently ran into a weird problem with my portfolio. The site is deployed on Vercel, the deployment was healthy, Vercel showed the domain as Valid Configuration and SSL was active. It loaded perfectly from some networks, but from another one the browser would just hang until it finally showed:

This site can't be reached
7xmohamed.com took too long to respond.

At first I assumed it was a DNS problem. It was not. What made it more interesting is that this was not just an Orange Morocco quirk. Once I started digging I found similar reports from different countries and carriers where selective Vercel edge hosts were unreachable. Here is what I actually found and how I confirmed it.

The first clue: the same site worked on another network

My domain is https://7xmohamed.com and it is hosted on Vercel. From an IAM connection in Morocco the site loaded fine, but from Orange Morocco it never completed loading. That detail matters because if the application itself were broken, switching ISPs would not magically fix it. So instead of rebuilding anything, I started checking layer by layer.

Is DNS working?

I started with the obvious check:

nslookup 7xmohamed.com

It returned:

Name:    7xmohamed.com
Address: 216.198.79.1

So the domain was resolving. DNS was not completely broken, at least not in a way that prevented resolution. The next step was to see if I could actually establish an HTTPS connection:

curl.exe -v https://7xmohamed.com

The important part of the output was this:

* Host 7xmohamed.com:443 was resolved.
* IPv4: 216.198.79.1
* Trying 216.198.79.1:443...
* connect to 216.198.79.1 port 443 ... failed: Timed out

That changed the direction of the investigation. The failure was not Domain -> DNS -> FAIL. It was Domain -> DNS -> 216.198.79.1 -> TCP port 443 -> TIMEOUT. DNS was doing its job, but I could not reach the IP it returned.

Then I found the Vercel reports

While searching I found a Vercel Community thread that described the exact same pattern from Morocco. The thread was useful because it did not just say the site was down. The author tested individual Vercel IPs from the affected carrier (AS36925 Meditel / Orange Morocco, Casablanca) and documented the results clearly:

216.198.79.1  -> TCP timeout
216.198.79.65 -> TCP timeout
64.29.17.1    -> TCP timeout
64.29.17.65   -> TCP timeout

But these worked fine from the same network:

76.76.21.21 -> 200 OK
66.33.60.130 -> 200 OK

Traceroute to 216.198.79.1 also died inside the carrier network and never reached Vercel. That is a very different situation from Vercel being down. The platform was reachable, the app was reachable, some Vercel IPs were reachable, but those two ranges were not.

One nuance is important here. The exact IPs that fail vary by region. In Brazil (AS28668) only 216.198.79.1 and 64.29.17.1 were blackholed while .65 in the same ranges worked. In Oman (AS28885) 216.198.79.1 timed out but 216.198.79.129 and .193 worked. So it is better to think of it as selective reachability to hosts inside 216.198.79.0/24 and 64.29.17.0/24, not necessarily the whole range being blocked everywhere.

It is not only Orange Morocco

This is where it got more interesting. The Morocco thread itself references similar reports from Brazil (AS28668), Oman (AS28885 / AS204170), Nigeria, Russia and even Michigan in the US. In each case the custom domain timed out while other Vercel services kept working, which points to reachability to specific edge hosts rather than a broken website.

That is why I would not describe it as Orange Morocco blocks Vercel. That is too broad and not accurate. A more honest description is that some networks currently cannot reach selective hosts inside certain Vercel edge ranges. In Morocco the issue has been reproduced on Orange, Maroc Telecom and inwi, and one report noted that switching the resolver to 8.8.8.8 did not help, which is another sign it was not simple DNS caching. The onset in Morocco was around 2026-07-29 with no intentional DNS or deployment changes on the affected sites.

Why the vercel.app URL can still work

This part is confusing at first. You can have my-project.vercel.app loading perfectly while example.com times out on the same network, and that does not automatically mean your custom domain is misconfigured. Vercel staff explained that .vercel.app URLs and custom domains can resolve to different IPs, so a routing or filtering issue that affects one set of IPs can break the custom domain while the deployment URL keeps working.

In practice it looks like this: my-project.vercel.app hits a working Vercel IP and succeeds, while example.com resolves to a 216.198.79.x address that is not reachable from that carrier. Both can be true at the same time, and Vercel now recommends using www with a CNAME as the primary domain precisely because the CNAME path lets them steer traffic away from a fixed IP dependency.

A different explanation to keep in mind

One comment in the Orange thread stood out because it described a completely different cause with similar symptoms. A user on Orange Poland had their domain flagged by the ISP security system as malware. Changing DNS records did nothing until they contacted the ISP CERT team and the domain was unblocked.

So there are at least two situations that can look the same from the browser. The first is an IP connectivity problem where your domain correctly resolves to something like 216.198.79.65, TCP to port 443 times out, but another Vercel IP like 76.76.21.21 is reachable. That points to routing or filtering to a specific edge host. The second is domain level ISP filtering where the ISP has flagged the domain itself, in which case changing the IP will not help. The distinction matters because the fix is different.

How I confirmed which problem I had

I checked my own domain first:

nslookup 7xmohamed.com

It returned 216.198.79.1, and curl.exe -v https://7xmohamed.com timed out trying to connect to that same IP. My subdomain achkhasni.7xmohamed.com was resolving to 216.198.79.65 and 64.29.17.65, and both timed out as well. That matched the reported affected ranges.

The revealing test was to bypass DNS and force curl to a known working Vercel IP:

curl.exe --resolve 7xmohamed.com:443:76.76.21.21 https://7xmohamed.com

That connection worked. The --resolve flag tells curl to use 76.76.21.21 for 7xmohamed.com:443 instead of the address returned by DNS, so I could directly compare the two paths. Normal DNS to 216.198.79.1 resulted in a timeout, while the forced IP 76.76.21.21 completed the HTTPS request. That was strong evidence the issue was the specific Vercel IP being used, not my application.

The workaround

Vercel community members had already found a practical workaround using the general purpose IP. For the apex domain you set an A record to 76.76.21.21, and for www you keep a CNAME to the value shown in your Vercel dashboard:

Type:   A
Host:   @
Value:  76.76.21.21

Type:   CNAME
Host:   www
Value:  cname.vercel-dns.com
# use the exact value from your dashboard, for example
# cname.vercel-dns-0.com or xxxx.vercel-dns-017.com

Multiple users in Morocco confirmed this restored connectivity within minutes of propagation. I applied the same change to 7xmohamed.com and it started working from Orange shortly after.

A quick warning though. The dashboard is the source of truth, and newer projects are assigned an IP from the pool such as 216.198.79.1 (see vercel.com/kb/guide/a-record-and-caa-with-vercel). If you override it with 76.76.21.21, the dashboard may show Invalid Configuration even though the site becomes reachable. Treat this as a temporary workaround rather than a long term recommendation. It is also region specific. In Nigeria in 2024 the opposite happened and 76.76.21.21 itself was the blocked address. An alternative that avoids hardcoding an A record is Cloudflare CNAME flattening, where you point the apex to cname.vercel-dns.com and let Cloudflare resolve it server side to a working IP.

What about subdomains?

Subdomains need the same attention. A typical Vercel subdomain uses a CNAME, but if that CNAME eventually resolves to a problematic edge host you will see the same timeout. In my case achkhasni.7xmohamed.com was going through 37b1e8206c3d04d6.vercel-dns-017.com which resolved to 216.198.79.65 and 64.29.17.65, both unreachable from the affected network.

I temporarily changed that subdomain to an A record:

Type:   A
Host:   achkhasni
Value:  76.76.21.21

After propagation it worked as well. Another user reported success with:

@     A       76.76.21.21
*     A       76.76.21.21
www   CNAME   cname.vercel-dns.com

That made both the apex and wildcard subdomains work for them. I would still not add a wildcard * record to every project by default. Only change what you need. Wildcard SSL on Vercel requires nameserver delegation to ns1.vercel-dns.com and ns2.vercel-dns.com, so a * A record will not correctly provision wildcard certificates. Use it only as a temporary fix for the specific host that is affected.

How to troubleshoot this yourself

If your Vercel custom domain works on one network but not another, do not start by rewriting your app. Start with DNS and then test connectivity directly:

nslookup example.com
curl.exe -v https://example.com

If DNS returns something in 216.198.79.x or 64.29.17.x, test that IP and a known working one side by side:

curl.exe --resolve example.com:443:216.198.79.1 https://example.com
curl.exe --resolve example.com:443:76.76.21.21 https://example.com

If the first times out and the second succeeds, you have a strong signal that the problem is network reachability to that edge host, not your code. You can also compare resolvers to rule out caching:

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

If both return the same IP but HTTPS still times out, switching DNS providers will not fix the underlying connectivity.

Do not confuse DNS with connectivity

This was the biggest lesson from this issue. When the browser says This site can't be reached, it does not automatically mean DNS is broken. There are multiple steps and the failure can happen at any of them:

                DNS
                 |
                 v
          What's the IP?
                 |
                 v
          216.198.79.1
                 |
                 v
        Can I reach that IP?
                 |
                 v
           TCP port 443
                 |
                 v
         TLS handshake
                 |
                 v
          HTTP request
                 |
                 v
          Your application

In my case the connection never got past TCP port 443. That means React, Next.js, SSL, deployment and HTTP config were not even reached yet. This is why curl -v is so useful. It shows exactly where the connection stops.

What Vercel says

Vercel staff acknowledged the reports and said it looked like some ISPs may have blocked or broken routing to parts of the edge network. They also noted that the fact .vercel.app kept working while custom domains failed made that explanation more likely, since the two can use different IPs. They pointed users to the general purpose IP as a temporary workaround.

The original Morocco report asked Vercel to check peering to 216.198.79.0/24 and 64.29.17.0/24 from Moroccan carriers and to confirm whether staying on the legacy records was supported during the investigation. The thread was later closed and linked to a larger discussion, and docs now advise using www with a CNAME as the primary and redirecting the apex.

This is based on my own tests from two Moroccan ISPs and public community reports as of 2026-08-30, not an official statement from the carriers.

So what is actually broken?

If I had to draw it, the picture looked like this:

                    Vercel
                      |
          +-----------+-----------+
          |                       |
   Legacy/general-purpose     New edge ranges
       76.76.21.21          216.198.79.0/24
                              64.29.17.0/24
          |                       |
          |                       |
       reachable              selectively unreachable
          |                 from some networks
          |
          v
       Website

The keyword is some. It is not necessarily Vercel is down, it is not necessarily Orange is blocking Vercel, and it is not necessarily your DNS is wrong. In some cases the path between a specific ISP and specific Vercel edge hosts is simply broken or filtered, and we have seen evidence of that across several countries.

The solution is global, not just Morocco

This is not a Morocco only issue. The same pattern has been reported from Brazil, Oman, Nigeria, Russia and the US, with the same ranges and the same symptom of custom domain timeout while vercel.app works. The workaround is therefore global and applies to anyone who confirms the pattern, regardless of country.

If your domain resolves to a host in 216.198.79.0/24 or 64.29.17.0/24 and TCP to port 443 times out from the affected network, while 76.76.21.21 is reachable, the current user reported workaround is:

@       A       76.76.21.21
www     CNAME   cname.vercel-dns.com  # use the exact value from your Vercel dashboard

For any specific affected subdomain you can also try:

Type:   A
Host:   your-subdomain
Value:  76.76.21.21

This works whether you are in Morocco, Brazil, Oman or elsewhere. If the general purpose IP is also blocked on your carrier, try a different working Vercel edge IP confirmed via curl --resolve or consider Cloudflare CNAME flattening so the apex resolves server side instead of hardcoding an IP.

After any DNS change, wait for propagation and test again. Keep in mind DNS caching. A public resolver like 1.1.1.1 may show the new record while your local resolver still shows the old one, so compare:

nslookup example.com 1.1.1.1
nslookup example.com

That difference is normal right after a change. Test from the affected network as well as from mobile data or a VPN to confirm the fix is visible where it matters.

One last thing

The 76.76.21.21 setup should be treated as a workaround, not as proof that the newer Vercel edge is permanently broken. The root cause appears to be outside the application and related to reachability to those edge hosts from certain networks. So if your deployment is healthy, the dashboard says Valid Configuration, SSL is fine, DNS resolves, but only some networks time out, do not spend hours rebuilding your app. Test the network path first. Sometimes the problem is not your website. It is the road between the user and the server.

Sources & References

Further Reading

Why Developers Keep Choosing Worse Technology

Why Typing Faster With AI is Destroying Your Architecture

AI Will Replace Developers is One of The Worst Takes on The Internet

When AI Decided Blackmail Was the Optimal Solution

How to Design Your First Real Program