I recently took over DNS management for a corporate domain that should redirect to a longer URL provided by our web host. The destination URL works when entered directly, but visiting the shorter domain results in ERR_CONNECTION_TIMED_OUT in Brave and Edge. A web-based redirect checker reports that the redirect works, and Firefox also follows it successfully.
The domain is managed through eNom, where both the root and www records are configured as URL Redirect entries pointing to the destination using HTTPS. The setup worked previously and stopped unexpectedly. Further testing suggested that Chromium-based browsers were attempting an HTTPS connection to the short domain, while the redirect service did not properly support SSL. Entering the short address with http:// explicitly allowed the redirect to work.
What could cause this browser-specific timeout, and what is the best way to configure the redirect so it works reliably over HTTPS?
4 Answers
Before changing providers, verify what the names actually resolve to from more than one network with nslookup or dig. A timeout usually means the browser cannot establish a connection to the resolved address, while a bad redirect normally produces an HTTP response. Also check for stale local DNS, incorrect IPv6 records, and differences between the root domain and www.
The practical fix is to use a redirect provider that supports HTTPS properly. In this case, setting up the domains with Cloudflare and configuring the forwarding there resolved the issue after DNS caches were flushed and the changes propagated. Make sure both the apex domain and www hostname are covered, and verify that the destination URL itself is correct.
The browser behavior points strongly to an HTTPS problem. Chromium browsers may upgrade or prefer HTTPS, and if the forwarding endpoint cannot complete the TLS handshake for the short domain, the browser can appear to hang instead of showing a normal redirect error. Typing http:// explicitly is a useful diagnostic because it bypasses that failed HTTPS handshake.
DNS resolution and ping responses do not prove that the web service is accepting TCP connections or presenting a valid certificate. Test both the root and www names with curl or browser developer tools, and check them over both HTTP and HTTPS.
A URL Redirect entry in a DNS management panel is not a normal DNS record. It is a forwarding service provided by the registrar, so the registrar's redirect server has to receive the request and return an HTTP 301 or 302 response. If that service is unavailable or does not have a valid TLS certificate for the short domain, browsers can time out before they ever receive the redirect.
That appears to be what happened. The redirect service was not handling HTTPS correctly, even though external redirect checks and Firefox made it look healthy.
This solved it for us. eNom recommended moving the redirect setup to Cloudflare, and the domains began forwarding correctly after the DNS cache was cleared.