Vercel TLS handshake stall on specific Anycast VIPs from South Korea

Help
, ,
1

Summary

From South Korea, connections to *.vercel.app hostnames intermittently fail with ERR_TIMED_OUT. The failures are strongly correlated with DNS resolution landing on two specific Vercel Anycast VIPs (216.198.79.67 and 64.29.17.67), which accept TCP connections on port 443 but stall after the client sends TLS ClientHello — no ServerHello is ever received.

Environment

  • Location: South Korea (at least one vantage point)
  • Date/Time: 2026-03-10 02:37 UTC (11:37 KST)
  • Access Networks: Multiple networks tested (both wired and mobile LTE)
  • Browsers: Chrome, Edge, Firefox, Safari (all affected when DNS resolves to failing VIPs)

Reproduction

Any *.vercel.app hostname can be used to reproduce. The issue is VIP-specific, not project-specific.

Failing VIPs (consistent TLS stall)

$ curl -sv --resolve "example-project.vercel.app:443:216.198.79.67" \
    https://example-project.vercel.app --connect-timeout 5
* Connected to example-project.vercel.app (216.198.79.67) port 443
* (OUT), TLS handshake, Client hello (1):
} [332 bytes data]
* SSL connection timeout

$ curl -sv --resolve "example-project.vercel.app:443:64.29.17.67" \
    https://example-project.vercel.app --connect-timeout 5
* Connected to example-project.vercel.app (64.29.17.67) port 443
* (OUT), TLS handshake, Client hello (1):
} [332 bytes data]
* SSL connection timeout

Working VIPs (consistent TLS success)

$ curl -sv --resolve "example-project.vercel.app:443:216.198.79.3" \
    https://example-project.vercel.app --connect-timeout 5
* Connected to example-project.vercel.app (216.198.79.3) port 443
* (OUT), TLS handshake, Client hello (1):
* (IN), TLS handshake, Server hello (2):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256

Full VIP Test Matrix (2026-03-10 11:37 KST)

VIP TCP Connect TLS Handshake Latency
216.198.79.3 OK OK 0.070s
216.198.79.67 OK Stall (no ServerHello) —
216.198.79.131 OK OK 0.112s
216.198.79.195 OK OK 0.074s
64.29.17.3 OK OK 0.073s
64.29.17.67 OK Stall (no ServerHello) —
64.29.17.131 OK OK 0.099s
64.29.17.195 OK OK 0.078s

OpenSSL Verification

$ openssl s_client -connect 216.198.79.3:443 -servername [any-vercel-app-hostname]
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_128_GCM_SHA256
Negotiated TLS1.3 group: X25519MLKEM768
Peer certificate: CN=*.vercel.app

$ openssl s_client -connect 216.198.79.67:443 -servername [any-vercel-app-hostname]
Connecting to 216.198.79.67
(stalls indefinitely — no ServerHello received)

ICMP (for reference only)

  • 216.198.79.67 — no ICMP response
  • 216.198.79.3 — responds, 12-13ms RTT

DNS Rotation

DNS for *.vercel.app hostnames returns varying VIP pairs across queries. When resolution lands on 216.198.79.67 / 64.29.17.67, connections stall at TLS. When resolution lands on other observed VIPs, connections succeed normally.

$ dig [any-project].vercel.app +short  # returns different pairs each query
# Observed VIPs during testing:
216.198.79.67 / 64.29.17.67     # → TLS stall
216.198.79.131 / 64.29.17.131   # → works
216.198.79.3 / 64.29.17.3       # → works
216.198.79.195 / 64.29.17.195   # → works

Impact

  • User-visible: Intermittent ERR_TIMED_OUT in browsers, depending on which VIP DNS returns.
  • Scope: Multiple unrelated *.vercel.app projects are affected. The issue is at the VIP/edge level, not application-specific (both static and Next.js serverless projects exhibit the same behavior).
  • Duration: Reproducible for at least 2+ hours during testing. Recurrent incidents reported over past weeks.
  • Networks: Reproduces on multiple networks in South Korea (wired and mobile LTE).

Observed Behavior

From at least one South Korea vantage:

  1. TCP three-way handshake completes successfully to 216.198.79.67
  2. Client transmits TLS ClientHello (332 bytes)
  3. No TLS ServerHello is received
  4. Connection stalls until timeout

The same client, SNI, and TLS configuration succeed against sibling VIPs (216.198.79.3, .131, .195 and 64.29.17.3, .131, .195). This points to a VIP/path-specific front-door issue rather than a client-side or application-level problem.

Note: Custom domain CNAME targets (cname.vercel-dns.com) resolve to 76.76.21.x / 66.33.60.x (VERCEL-01/02), which are not affected. Only the *.vercel.app VIP pool (VERCEL-05/12) contains the failing addresses.

Netblock Information

  • 216.198.79.67 — VERCEL-05 (216.198.79.0/24), Vercel, Inc
  • 64.29.17.67 — VERCEL-12 (64.29.17.0/24), Vercel, Inc

Related Community Reports

Requested Action

Please investigate the Anycast edge or routing configuration for VIPs 216.198.79.67 and 64.29.17.67, specifically for traffic originating from South Korea. These VIPs may need to be investigated at the Anycast edge, mitigation, or upstream routing layer.

6

Whilst we share this with the team, can you confirm that using a VPN works?

Sharing this post in case it’s helpful!

https://community.vercel.com/t/resolving-ip-blocking-issues/171