Hello Vercel team and community,
I would like to report a reproducible connectivity issue affecting a custom domain hosted on Vercel.
I have performed extensive testing and isolated a significant difference between the custom domain and its corresponding .vercel.app deployment.
The issue affects static files as well as normal page navigation, so it does not appear to be caused by application-level JavaScript or React rendering.
I am using the Hobby plan.
For privacy reasons, I have anonymized the hostnames and request identifiers in this public report. I can provide the actual domain names, complete request IDs, and additional diagnostics privately to Vercel staff.
1. Environment
- Hosting platform: Vercel
- Framework: Next.js
- DNS provider: Cloudflare
- Cloudflare proxy: Disabled (DNS only)
- Custom domain:
[custom-domain] - Deployment hostname:
[project].vercel.app - Client: macOS and Safari on iPhone
- Affected connection: Cellular network, including an iPhone hotspot
- Comparison connection: Home broadband Wi-Fi
The production deployment is accessible through its Vercel hostname. The custom domain has valid DNS configuration and HTTPS connectivity.
2. Problem description
The behavior depends on the network and hostname.
Home broadband connection:
- The custom domain generally loads successfully.
- The website works normally.
Cellular connection:
- The custom domain frequently fails to load.
- Safari may remain on a blank page while continuously loading.
- The
.vercel.appdeployment generally loads successfully over the same connection.
Similar symptoms were also observed when using a Mac connected through an iPhone hotspot.
Tests with a VPN did not provide a consistent solution.
3. Critical finding: identical destination IP, different results
To eliminate differences caused by DNS resolution, I used curl --resolve to direct both hostnames to the same Vercel IPv4 address, while preserving the correct hostname and TLS SNI for each request.
Both requests targeted the same static PNG file, with an expected size of 6,021 bytes.
HTTP/1.1 was explicitly selected for this comparison.
Results:
| Parameter | Custom domain | Vercel hostname |
|---|---|---|
| Destination IP | Same IP | Same IP |
| HTTP status | 200 OK | 200 OK |
| Expected body size | 6,021 bytes | 6,021 bytes |
| Downloaded bytes | 0 | 6,021 |
| Outcome | Timeout after 15 seconds | Success |
The custom-domain request successfully completed the TCP and TLS stages and received HTTP headers, including Content-Length: 6021.
However, the response body never arrived.
The .vercel.app hostname successfully returned the complete file from the same destination IP.
This is the most important reproducible finding.
4. HTTP Range testing
I also performed HTTP Range requests against the affected custom domain's static PNG file.
| Requested body size | HTTP status | Outcome |
|---|---|---|
| 512 bytes | 206 | Success |
| 1,024 bytes | 206 | Success |
| 2,048 bytes | 206 | Timeout, 0 body bytes |
| 4,096 bytes | 206 | Timeout, 0 body bytes |
| 6,021 bytes | 206 | Timeout, 0 body bytes |
In the failing requests, HTTP response headers arrived, but the response body stalled.
This may be relevant to TCP segment handling, path MTU, traffic filtering, or other network-level behavior. However, I cannot determine the root cause from these results alone.
The issue also occurs with HTTP/1.1, so it is not exclusively an HTTP/2 problem.
5. Different Vercel edge identifiers
Another comparison using the same destination IP produced the following results.
Custom domain:
- HTTP/1.1 200 OK
- Content-Length: 6021
- X-Vercel-Id prefix:
arn1 - Result: Timeout, 0 of 6,021 bytes received
Vercel deployment hostname:
- HTTP/1.1 200 OK
- Content-Length: 6021
- X-Vercel-Id prefix:
fra1 - Result: Request completed successfully
The differing X-Vercel-Id prefixes may be relevant to the investigation.
I understand that these values alone do not prove that a specific Vercel edge location is malfunctioning.
6. Additional comparison with another Vercel project
I also tested a separate website hosted on Vercel, using another custom domain and Cloudflare DNS.
That website opens normally in Safari over the same cellular connection.
During one test, an HTTP/2 request to the second custom domain successfully downloaded 21,299 bytes, while the affected custom domain timed out when connecting to the same destination IP.
Some forced HTTP/1.1 requests to the control website also stalled, indicating that network protocol selection may influence the results.
This comparison suggests that the problem is not simply a complete inability to reach Vercel over the cellular network.
7. Troubleshooting already performed
I have checked the following:
- Cloudflare DNS configuration
- Cloudflare proxy status (DNS only)
- Vercel domain and deployment configuration
- TCP connectivity
- HTTPS/TLS negotiation
- HTTP/1.1 and HTTP/2 behavior
- IPv4 connectivity
- Static asset delivery
- HTTP Range requests
- Different response sizes
- VPN and non-VPN connections
- Different network connections
- Multiple Vercel destination IP addresses
- Forced hostname resolution using
curl --resolve - Vercel request identifiers and edge prefixes
A particularly important observation is that the problem reproduces on a small static asset served from the Vercel cache.
This makes an application-level rendering problem unlikely.
8. Similar reports
I found other reports in the Vercel Community describing similar behavior:
These reports also describe custom-domain connectivity problems where .vercel.app hostnames perform significantly better, sometimes even when using the same destination IP.
I understand that Vercel's networking team has already been informed about related reports.
9. Questions for the Vercel networking team
Could you please help investigate the following?
-
Are there known issues affecting HTTPS response-body delivery for custom domains on Vercel's shared edge infrastructure?
-
Could differences in edge ingress, hostname-based routing, TLS/SNI handling, or CDN processing explain the observed behavior?
-
Is the difference between
arn1andfra1relevant to this issue? -
Could these results be linked to the existing networking investigation mentioned in similar community reports?
-
Is there a supported workaround, such as a different ingress route or domain configuration, that could improve reliability without migrating the application away from Vercel?
-
What additional diagnostics would help your networking engineers identify the cause?
I would be happy to provide the exact affected hostnames, complete X-Vercel-Id values, test timestamps, and additional logs privately if a secure communication method is available.
My goal is not to assign blame prematurely, but to identify why a valid custom domain fails to deliver response bodies while the corresponding Vercel hostname succeeds under comparable conditions.
The website is intended for public access, and reliable connectivity through mobile networks is important.
I would very much appreciate it if this report could be reviewed by the Vercel networking/CDN team or linked to the existing investigation.
Thank you for your time and assistance.