Hello Vercel Engineering Team,
I am requesting a deeper engineering investigation because this issue is now reproducible across multiple independent devices and networks, and all evidence suggests the problem is occurring beyond my application code or server configuration.
My production architecture is:
- Frontend: Next.js hosted on Vercel
- Custom domain: https://modastitch.com
- Backend API: https://api.modastitch.com (Spring Boot on Hostinger VPS behind Nginx)
- Primary audience: United States customers
Current symptoms:
The homepage may load, but browsers consistently fail to complete requests properly. Product loading, authentication, API requests, and general browsing fail with browser SSL/protocol related errors. The issue reproduces on multiple browsers (Chrome and Opera), Windows, and Android. It also reproduces using completely different internet connections including mobile data, so this is not isolated to a single computer or Wi-Fi network.
Infrastructure verification already completed:
- Hostinger has confirmed there are no remaining proxy, CDN, SSL, forwarding, or edge configurations pointing to old infrastructure.
- Hostinger confirmed the domain is fully disconnected from their shared hosting.
- My backend API at https://api.modastitch.com is fully operational.
- Nginx configuration is valid.
- TLS certificate for api.modastitch.com is valid.
- Backend endpoints return HTTP 200.
- Vercel issued a valid Let’s Encrypt certificate for modastitch.com.
- DNSSEC is disabled.
- There are no proxy services such as Cloudflare in front of the site.
Authoritative DNS currently returns:
modastitch.com → 216.198.79.1
api.modastitch.com → 2.24.30.191
Both ns1.dns-parking.com and ns2.dns-parking.com return 216.198.79.1 as the authoritative A record.
Verification performed:
dig @ns1.dns-parking.com modastitch.com A
dig @ns2.dns-parking.com modastitch.com A
dig +trace modastitch.com
All authoritative responses resolve to 216.198.79.1.
Recursive DNS verification:
Cloudflare DNS (1.1.1.1)
Google DNS (8.8.8.8)
Resolve-DnsName
nslookup
All now return:
modastitch.com → 216.198.79.1
Server-side verification from my VPS:
curl -I https://modastitch.com
returns
HTTP/2 200
Server: Vercel
The TLS handshake succeeds and the correct certificate is served.
The backend API also responds correctly:
curl -I https://api.modastitch.com/api/products
returns
HTTP/2 200
Certificate verification succeeds.
One important inconsistency:
The Vercel Connectivity Debug Script reported an attempt to connect using the previous Hostinger IP (82.180.143.64), while manual DNS queries immediately afterward resolved 216.198.79.1 from both Google DNS and Cloudflare DNS.
This discrepancy appears inconsistent with the current authoritative DNS and may indicate an issue within the debug tool, DNS cache used by the tool, edge routing, or another network component.
I would appreciate if engineering could investigate the following:
- Verify that my production deployment is correctly attached to every Vercel edge location globally, especially US POPs.
- Verify there are no stale edge mappings or cached routing entries still referencing previous infrastructure.
- Verify there are no internal DNS caches or edge caches serving obsolete routing information.
- Verify the TLS handshake path from multiple US edge locations.
- Verify SNI handling for modastitch.com.
- Verify there are no certificate propagation inconsistencies between edge regions.
- Verify the Anycast routing advertisements for my deployment.
- Verify that every Vercel POP serving modastitch.com is using the latest deployment and certificate.
- Verify there are no stale deployment bindings associated with this custom domain.
- Verify there is no platform-side issue affecting browser TLS negotiation while command-line clients succeed.
If possible, please test the following from multiple US edge regions:
I have attached the complete Vercel connectivity debug report along with all DNS and curl outputs collected during troubleshooting.
At this stage, every component under my control has been verified, including DNS, authoritative nameservers, backend infrastructure, TLS certificates, Nginx configuration, and deployment configuration. I would appreciate an engineering-level investigation into Vercel’s routing, edge network, or TLS infrastructure, as the remaining evidence points toward an issue beyond the application itself.
Thank you.