Custom domain intermittently unreachable from some user networks

I am experiencing an accessibility issue with my custom domain:
Custom domain: свадьбаильианны.рф
Unicode form: свадьбаильианны.рф
Project: ilya-anna-wedding
Current setup:

dig @ns1.vercel-dns.com xn--80aaacdn4aa0awa1b7jfe.xn--p1ai A +short
216.198.79.1

The problem is that some users cannot establish an HTTPS connection to the Vercel IP assigned to the domain.
From an Android phone / Termux:

curl -I -v --connect-timeout 15 \
  --resolve "xn--80aaacdn4aa0awa1b7jfe.xn--p1ai:443:216.198.79.1" \
  "https://xn--80aaacdn4aa0awa1b7jfe.xn--p1ai/"
* Trying 216.198.79.1:443...
* Connection timed out after 15002 milliseconds
curl: (28) Connection timed out after 15002 milliseconds

At the same time, from a PC on the same home Wi-Fi, the same IP works correctly:

curl.exe -I -v https://xn--80aaacdn4aa0awa1b7jfe.xn--p1ai/
* Trying 216.198.79.1:443...
* Established connection to xn--80aaacdn4aa0awa1b7jfe.xn--p1ai (216.198.79.1 port 443)
< HTTP/1.1 308 Permanent Redirect
< Location: https://www.xn--80aaacdn4aa0awa1b7jfe.xn--p1ai/
< Server: Vercel

Multiple visitors have reported that the site does not open for them, so this appears to affect more than one user/device.
Could you please investigate possible routing, connectivity, or edge reachability issues for 216.198.79.1:443, especially from residential/mobile networks? DNS resolution, TLS configuration, and the Vercel redirect configuration appear correct; the failure occurs before the TCP/TLS connection is established.
Please let me know whether you need traceroute/MTR output, affected ISP/country details, or any additional diagnostics.
Thank you.
to let others see and understand the problem!

Hi Marat,

The --resolve ...:443:216.198.79.1 test is a useful clue. Since that request times out while connecting directly to the Vercel IP, that specific failure is not DNS propagation, IDN/punycode conversion, or certificate selection. It is failing before TLS/HTTP.

The part I’d narrow down next is whether this is truly network/ISP routing or something device-specific, because you mentioned the Android phone fails while a PC on the same Wi-Fi works.

From one affected device and one working device, I’d compare:

curl -4 -Iv --connect-timeout 15 https://xn--80aaacdn4aa0awa1b7jfe.xn--p1ai/
curl -4 -Iv --connect-timeout 15 https://www.xn--80aaacdn4aa0awa1b7jfe.xn--p1ai/

openssl s_client -connect xn--80aaacdn4aa0awa1b7jfe.xn--p1ai:443 -servername xn--80aaacdn4aa0awa1b7jfe.xn--p1ai -brief
traceroute 216.198.79.1
# or, if available:
mtr -4 216.198.79.1

On the Android device, I’d also test once with Wi-Fi and once with mobile data, and temporarily disable VPN, Private DNS, ad blockers, or browser/network filtering if any are enabled. If the same phone works on mobile data but not Wi-Fi, that points to the local ISP/router path. If it fails on multiple unrelated networks, that makes a regional reachability/routing issue more likely.

For Vercel to investigate the edge path, the most useful details would be:

Domain:
Punycode domain:
Affected country/ISP:
Affected device/network type:
Timestamp + timezone:
curl -4 -Iv output:
traceroute or MTR output:
Whether the same test works from another network:

I would not include any private account IDs or project secrets. Since the failing request times out before HTTP, it may not show up in normal project request logs at all.