Project: bazatela (Hobby), team miktots-projects. Affected domains: https://bazatela.ru/ and https://www.bazatela.ru/
Working alias: https://bazatela.vercel.app/
Both custom domains are assigned to the same production deployment as the alias. Vercel reports valid DNS configuration; TLS hostname checks pass. HTTP redirects to HTTPS with status 308.
Reproduction from the affected connection on 28 October 2026:
- The static asset /build/assets/app-BbOtkhi2.css is 127883 bytes.
- bazatela.ru: HTTP 200, then transfer stalls after about 3-10 KB and times out.
- www.bazatela.ru: same partial-body failure.
- bazatela.vercel.app: all 127883 bytes received in about 0.28 seconds.
- ETag is identical: "2504404131a083fdcd686f5c191421a8". X-Vercel-Cache: HIT on all three hosts.
- Custom-domain x-vercel-id starts with arn1; alias starts with fra1.
- Small robots.txt (24 bytes) and a 2048-byte Range request for the CSS complete successfully on the custom domain.
- Pinning both hostnames to the SAME IP 216.198.79.1 still reproduces the difference. Other tested IPs: 64.29.17.1, 76.76.21.21 and 64.29.17.131. HTTP/1.1 and HTTP/2 both reproduce it.
- From a Vercel build host in Washington DC, both domains deliver the complete HTML and the custom domain also delivers complete CSS and JS.
Selected request IDs from the static CSS control: bazatela.ru: arn1::b62m6-1793198566843-f2b8d1d45c96 www.bazatela.ru: arn1::kdbrm-1793198566988-185ff84a6d5a bazatela.vercel.app: fra1::sn4hc-1793198566855-3d37379c0f06
This static-asset reproduction does not execute PHP or query our PostgreSQL database. The application function region is already fra1; changing it is not expected to change the client-facing CDN route.
Similar reports acknowledged by Vercel staff: https://community.vercel.com/t/custom-domain-unreachable-from-some-russian-isps-while-vercel-app-works/48756 https://community.vercel.com/t/custom-domain-response-bodies-stall-in-russia-while-vercel-app-works-on-the-same-ips/49387
Please investigate the custom-domain delivery path through arn1 and advise a supported remediation or routing change for this project. Please link these measurements to the existing network-team investigation if applicable. We have not established whether the failure originates at the edge or on a downstream network and are not attributing it to a specific provider.