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:

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

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

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:

1
Domain:
2
Punycode domain:
3
Affected country/ISP:
4
Affected device/network type:
5
Timestamp + timezone:
6
curl -4 -Iv output:
7
traceroute or MTR output:
8
Whether the same test works from another network:
9

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.