From our side the custom domain is fully set up: both DNS records have propagated, ownership is verified, the TLS certificate has been issued and is valid, and an HTTPS request to the domain from outside your network reaches your service and gets an HTTP 200 back. Routing and certificate issuance are already complete, so there is nothing to retrigger.

When TCP connects and then the TLS handshake hangs with no reset, but only from certain networks, the usual cause is filtering on the network path between the client and our edge. Some ISPs, including some Russian ones, drop traffic to specific edge IPs or to specific SNI hostnames. Your service domain and your custom domain can resolve to different edge IPs, which is why one can work while the other hangs from the same machine.

To tell which kind of filtering it is, try curl --resolve to force the custom domain onto a different edge IP, and openssl s_client -servername with the generated domain against the same IP. If only the custom hostname hangs, that is SNI filtering. If another IP works, that is IP filtering. We can't lift ISP-side filtering or assign specific edge IPs, and redeploying or changing region does not change the edge IP. The lasting fix is to put a proxy or CDN in front of the domain whose IPs your users can reach.