vercel.app intermittently unreachable for SKT (Korea) users — code/DNS ruled out - Help

Production site (theowners.vercel.app and custom domain www.소유주들.com) intermittently unreachable for a specific user in South Korea (SKT mobile carrier + home WiFi both affected). Getting "This page couldn't load" (network-level connection failure) in browser, on the installed PWA, across multiple browsers.

This is the 2nd occurrence — same symptom happened ~1 month ago, lasted about a day, resolved with no identified cause.

What we've ruled out

Server health: continuous curl checks from our side (US-based) — 100% consistent 200 OK, zero failures throughout the incident
DNS resolution: checked via Google (8.8.8.8), Cloudflare (1.1.1.1), and the user's own Korean ISP resolver — all resolve correctly to valid Vercel IPs
Application code: rolled back production via vercel promote to a deployment predating the incident — the older deployment failed identically on the affected device, ruling out a code cause
Device/network troubleshooting: custom DNS (dns.google), Cloudflare WARP VPN, incognito mode, multiple browsers, switching WiFi/mobile data — symptom persisted through all of these
Not limited to one hostname: also intermittently affects other project alias domains (e.g. theowners-uniconode.vercel.app), not just the primary domain

I already opened a case via the support chat but got routed here since we're on the Hobby plan. Would appreciate if anyone from the Vercel team or community has seen similar SKT/Korea-specific intermittent blocking patterns, or could point me toward checking edge logs for this project (uniconode/theowners) during 2026-07-21 17:00 ~ 2026-07-22 09:00 KST.

Thanks!

Hi Jakeeom0712,

Since an older deployment fails the same way and multiple hostnames are affected, I’d stop treating this as app code or a single custom-domain DNS issue. The next useful step is to capture where the affected user’s connection fails: DNS, TCP, TLS, or HTTP.

When it is failing, I’d ask the affected user to run these from the same network/device if possible:

date -u
dig A theowners.vercel.app +short
dig A www.xn--py1b03vokeo4b.com +short

curl -4Iv --connect-timeout 10 https://theowners.vercel.app/
curl -4Iv --connect-timeout 10 https://www.xn--py1b03vokeo4b.com/

openssl s_client -connect theowners.vercel.app:443 -servername theowners.vercel.app -brief </dev/null
openssl s_client -connect www.xn--py1b03vokeo4b.com:443 -servername www.xn--py1b03vokeo4b.com -brief </dev/null

mtr -4 -T -P 443 -c 20 theowners.vercel.app

I used the punycode form for the Korean domain so the terminal test is unambiguous.

If curl gets any Vercel response, capture the x-vercel-id and UTC timestamp. If it never gets an HTTP response and times out or fails during TLS, then the resolved IP, timestamp, ISP/carrier, and mtr output are the useful evidence.

I would avoid more redeploys or rollbacks for now since you already ruled out the deployment. The cleanest escalation is: “same deployment works from other networks, affected SKT/Korea path resolves DNS correctly but fails before/at TCP/TLS,” plus the command output from the failing network.