A common issue with UltraDNS Web Forwarding is that redirects work over HTTP but fail over HTTPS.
This behavior is expected when HTTPS forwarding is not fully configured and is not related to DNS or propagation.
This article explains why this occurs and how to resolve it.
Symptoms
- http://example.com redirects correctly
- https://example.com fails to connect or returns an error
- Entering the domain without specifying a protocol does not redirect as expected
- Changing redirect type (301 or 302) does not resolve the issue
Root Cause
UltraDNS Web Forwarding operates at the HTTP and HTTPS application layer, not at the DNS layer.
Most modern browsers attempt an HTTPS connection first.
If HTTPS is not properly configured on the forwarding record:
- The browser attempts to connect using HTTPS
- No SSL or TLS certificate is available for the forwarding service
- The connection fails before the redirect is processed
As a result, HTTP requests succeed while HTTPS requests fail before reaching the redirect logic.
Key Behavior
- Redirects occur only after a successful protocol connection
- HTTP forwarding does not require a certificate
- HTTPS forwarding requires a valid SSL or TLS certificate
- Redirect type does not affect protocol behavior
Resolution
To ensure redirects work for all users, including those using HTTPS by default, HTTPS Web Forwarding must be configured with a certificate.
Step 1: Obtain or Upload a Certificate
Upload a valid SSL or TLS certificate in the UltraDNS portal, or use a managed certificate if available.
Step 2: Enable HTTPS Forwarding
Edit the existing Web Forwarding record and:
- Enable HTTPS Forward
- Select the uploaded or managed certificate
- Confirm the redirect target
Step 3: Save Configuration
After saving, the forwarding service will accept HTTPS connections, terminate TLS, and apply the configured redirect.
Expected Result
- https://example.com connects successfully
- The redirect executes as expected
- Accessing the domain without specifying a protocol works correctly
Important Notes
- This is not a DNS issue
- No DNS propagation delay is involved
- The behavior depends entirely on HTTPS configuration