The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points.

https://vercel.com/docs/domains/troubleshooting

vercel.com

Troubleshooting domains

Learn about common reasons for domain misconfigurations and how to troubleshoot your domain on Vercel.

Thank you. I have already gone through the domain troubleshooting guide and verified the following:

• Both mindandmindset.site and www.mindandmindset.site show Valid Configuration in the Vercel dashboard.
• The SSL certificate is active.
• DNS records match Vercel's recommended configuration.
• DNS resolution works correctly using my ISP's resolver, Google DNS (8.8.8.8), and Cloudflare DNS (1.1.1.1).
• The deployment URL (https://mindandmindset.vercel.app) is accessible from the affected network.
• The issue only affects the custom domain when using Glo Nigeria. The same custom domain works normally on MTN Nigeria.
• Connectivity tests (curl, Test-NetConnection, ping, and tracert) indicate that the custom domain's edge IPs are unreachable from Glo, while the deployment domain remains reachable.

Based on these results, I don't believe this is a domain configuration or DNS issue. It appears to be an ISP-specific connectivity issue to the Vercel edge serving the custom domain.

Has anyone experienced something similar, or could someone from the Vercel team advise whether this should be escalated to the Edge Network team?

Hi Enoch,

Given your tests, I would not focus on app code or the Vercel deployment itself. The .vercel.app URL working from Glo while both the apex and www custom domains fail points more toward the network path to the specific edge IPs used by the custom domain.

I’d capture TCP 443 evidence rather than relying on ping, since ICMP can be filtered:

1
date -u
2

3
dig A mindandmindset.site +short
4
dig CNAME www.mindandmindset.site +short
5
dig A www.mindandmindset.site +short
6

7
curl -4Iv --connect-timeout 10 https://mindandmindset.site/
8
curl -4Iv --connect-timeout 10 https://www.mindandmindset.site/
9
curl -4Iv --connect-timeout 10 https://mindandmindset.vercel.app/
10

11
mtr -4 -T -P 443 -c 20 216.198.79.1
12
mtr -4 -T -P 443 -c 20 216.198.79.65
13

If mindandmindset.vercel.app connects from the same Glo network but mindandmindset.site times out or refuses on the resolved Vercel IP, that is strong evidence that the deployment and DNS config are probably fine, and the problem is specific to reachability from Glo to that custom-domain edge path.

If any curl request reaches Vercel, capture the x-vercel-id header and the UTC timestamp. If it never reaches HTTP, the useful evidence is the resolved IP, ISP name, timestamp, and the TCP mtr output.

I would not change the A/CNAME records to random alternate Vercel IPs unless the Vercel dashboard explicitly tells you to. Alternate IPs are useful for diagnostics, but the supported DNS values should stay aligned with the domain card.

Hi Aman,

I’d check use cache itself first. Even if you did not set export const revalidate = X, use cache has its own cache lifetime behavior. The default profile includes a server-side revalidation window, so it may not behave like “only regenerate when I call revalidateTag.”

That default is described here:

https://nextjs.org/docs/app/api-reference/directives/use-cache

nextjs.org

Directives: use cache | Next.js

Learn how to use the "use cache" directive to cache data in your Next.js application.

For your case, I’d try to separate three possible triggers:

1. use cache default revalidation Add an explicit cacheLife() profile to the cached function/component so you know exactly when it can revalidate, instead of relying on the default.

2. Bot or prefetch traffic A “couple real visitors” can still create many page reads if crawlers, link previews, uptime tools, or next/link prefetching touch many slug pages. If you have an index page linking to hundreds of dynamic routes, try temporarily setting prefetch={false} on those links and see if ISR reads drop.

3. Hidden requests that do not show up where you expect Cached page hits may not look like normal server logs. I’d use Vercel Observability / Runtime Logs and filter by path, user-agent, and rendering/cache mechanism around the ISR spike time. If needed, add very temporary middleware for /[slug] that logs only non-sensitive fields like path, user-agent, referer, and timestamp.

If the timestamps of ISR reads line up with bot/prefetch requests, then the cache is being touched by real HTTP traffic, just not human visitors. If ISR writes continue for slugs with no matching request at all, then I’d share a small sample of affected paths and timestamps, because that would be much stronger evidence of something internal or unexpected.

hi @ryux1 Thanks for the suggestions. I believe this may be a different issue.

My application itself appears to be healthy, the deployment URL (https://mindandmindset.vercel.app) consistently returns HTTP/1.1 200 OK, and the Vercel dashboard shows both custom domains as Valid Configuration with SSL active.

The problem occurs before any HTTP request reaches the application. Using curl -4 -I -v, the deployment URL connects successfully and returns a response, while both https://mindandmindset.site and https://www.mindandmindset.site resolve to their assigned Vercel edge IPs but time out during the TCP connection, before the TLS handshake or any HTTP headers are exchanged.

Because the connection never reaches the application, I don't believe this is related to use cache, ISR, or Next.js rendering. It appears to be a network reachability issue to the specific Vercel edge IPs serving the custom domain.

Based on the diagnostics I've shared (DNS resolution, curl, traceroute, and connectivity tests), does this look like something the networking/Edge team should investigate?

Hi Enoch,

Your latest tests narrow this down correctly. If the connection times out before the TLS handshake, then Next.js, caching and the application itself are not involved yet.

I would run one final comparison from both the affected Glo connection and a working network:

1
curl.exe -4 -I -v --connect-timeout 10 \
2
  --resolve mindandmindset.site:443:<resolved-edge-ip> \
3
  https://mindandmindset.site

Repeat it for each resolved edge IP. This forces the same hostname and SNI against a specific destination, removing DNS selection from the test.

If those IPs fail only from Glo while the same tests succeed from another network, you have a strong network-path or peering case rather than an application or domain configuration issue.

For escalation, I would provide Vercel staff with only:

• UTC timestamp
• source ISP and approximate location
• destination edge IP
• TCP timeout result
• matching successful test from another network

I would share the public source IP privately with staff, not in the thread.

Hi Enoch,

You’re right — sorry, my previous reply was on the wrong track. If curl -4 -v times out before the TLS handshake, then use cache, ISR, routing, and the app code are not involved yet.

Based on what you’ve shared, this looks like a network reachability/path issue rather than a Vercel project or DNS configuration issue. I still wouldn’t frame it as “definitely Vercel-side,” because it could also be Glo routing, filtering, or peering to those specific edge IPs, but your evidence is strong enough to take it out of the normal app/DNS troubleshooting bucket.

For escalation, I’d package it very tightly like this:

1
Affected ISP: Glo Nigeria
2
Approx location: <city/region>
3
Timestamp UTC: <exact time>
4
Domain: mindandmindset.site / www.mindandmindset.site
5
Resolved destination IPs: <IPs>
6
Result from Glo: TCP timeout before TLS handshake
7
Control test 1: mindandmindset.vercel.app returns 200 from same Glo network
8
Control test 2: custom domain works from another ISP/network
9

I’d also include the curl -4 -v, tracert / WinMTR output, and the forced-IP test that Zautomation suggested. Keep your public source IP private and only share it directly with Vercel support/staff if they ask.

The key point is: DNS appears to resolve, SSL is not the failing layer yet, and the request does not appear to reach the application. That makes it a good candidate for network/edge-path investigation.