Vercel Community

[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live)

[Help](/c/help/9)

# Vercel TLS handshake stall on specific Anycast VIPs from South Korea

32 views · 0 likes · 2 posts


Mumujin1986 3918 (@mumujin1986-3918) · 2026-03-10

## 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)

```bash
$ 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)

```bash
$ 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

```bash
$ 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.

```bash
$ 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

- [Custom domain intermittently serves wrong edge IPs (#27952)](https://community.vercel.com/t/custom-domain-intermittently-serves-wrong-edge-ips/27952) — reports `64.29.17.65` / `216.198.79.1` (same netblocks) causing `ERR_CONNECTION_CLOSED`
- [Network Connectivity Issue – South Korea (#5746)](https://community.vercel.com/t/network-connectivity-issue-slow-or-unreachable-requests-to-vercel/5746) — Korean ISP connectivity issue, resolved 2025-02-14 (different root cause)

## 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.


Pauline P. Narvas (@pawlean) · 2026-03-10

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](https://community.vercel.com/t/resolving-ip-blocking-issues/171)