Context
An origin can open successfully in a browser while requests through Azure Front Door fail. The browser and the edge service may not use the same hostname, certificate validation path, host header, or network route. A direct browser test is therefore useful evidence, but it is not a complete reproduction of the edge-to-origin request.
Imagine an illustrative application migration that replaces an origin hostname but keeps an older certificate and virtual-host configuration. The public domain still resolves, yet the edge begins returning gateway errors. The investigation should compare the configured origin identity with what the origin actually presents, rather than immediately disabling certificate checks.
Separate the two TLS connections
A reverse proxy has a client-facing connection and an origin-facing connection. A valid certificate on the public domain does not prove that the origin-facing TLS connection is valid. Azure's troubleshooting guidance identifies origin certificate name mismatches and incomplete certificate chains as relevant causes of failures, including 502 responses for an incomplete chain. 1
Draw both connections and label their hostnames. Record the public hostname, configured origin hostname, origin host header, port, and protocol. These values can be related without being identical. The goal is to understand each value's purpose and validate the actual configuration.
Preserve one failing request as evidence
Capture the response time, gateway status, relevant request or tracking identifiers, and the matching Front Door and origin logs. Distinguish an origin connection problem from an origin application that intentionally returns an error. If the origin never receives the request, application code is unlikely to be the first layer to fix.
Compare several failing paths. A health endpoint may use a different route or virtual host from the customer path. A single successful health probe does not demonstrate that every application hostname is configured correctly. Keep the test request free of customer secrets when it will be shared with the infrastructure team.
Verify the certificate the origin actually sends
Use a TLS diagnostic client that can specify the intended server name and show the chain returned by the origin. Confirm the certificate covers the configured hostname, is within its validity period, and includes the required intermediate chain. Inspect what is presented over the exact port used by Front Door.
A browser may rebuild a chain using information it already has, which can hide an incomplete server-side chain. Test from an environment that resembles the relevant network path as closely as practical. Preserve the test command and sanitized result so another engineer can repeat the observation after the certificate is changed.
Review host headers and virtual hosts
The origin application may select a site based on the HTTP Host header. If Front Door sends a value the origin does not recognize, TLS may succeed while the application returns the wrong site, redirects unexpectedly, or rejects the request. Check the web server and application host allowlists alongside the Front Door setting.
For example, an origin configured only for an internal hostname may reject the public hostname forwarded by the proxy. Fix the intended host contract rather than allowing every hostname without review. Test canonical redirects carefully so a proxy request cannot loop between the public and origin names.
Check routing and network admission separately
Confirm the origin is reachable through the intended access controls and that the configured backend path and port are correct. Review any recent firewall, private connectivity, or allowlist changes. A certificate correction cannot solve a blocked network route, and an allowlist change cannot repair a hostname mismatch.
Use the documented controls for restricting origin access to the intended Front Door path. Validate health probes as well as customer requests. Avoid a temporary broad exposure that becomes permanent because the main incident is closed before the cleanup task is assigned.
Make the smallest supported correction
If the chain is incomplete, install the correct chain. If the configured name is wrong, align the supported origin configuration and certificate. If the host header is wrong, update the application contract and test the resulting routing. Preserve certificate verification as part of the acceptance criteria.
Do not treat disabling name checks as a routine permanent solution. It can hide the mismatch while weakening the identity check the TLS connection was meant to provide. If an exceptional diagnostic change is authorized, keep it scoped, time-limited, and clearly recorded, then restore the intended validation once the evidence is collected.
Validate more than the homepage
Test the public route, the origin route under the intended hostname, health probes, redirects, API requests, and any upload or WebSocket paths the product uses. Observe both successful responses and error rates over a suitable interval. Certificate and route changes may take time to propagate through the configured system.
Use a small acceptance matrix listing hostname, path, expected response, and the layer where it was checked. Include certificate renewal in the follow-up: the next renewal should preserve the same complete chain and host coverage. A one-time manual repair is fragile if automation will overwrite it later.
A focused operator exercise: A certificate renewal rehearsal
In a suitable test setup, renew or replace the origin certificate through the same automation used operationally. Verify the configured origin hostname, returned certificate names, complete chain, and application Host handling after the automation finishes. Keep the public-domain certificate test separate so success on one connection does not hide failure on the other.
Run representative requests through Front Door and inspect the matching origin evidence. If a manual certificate repair is overwritten by renewal automation, correct that source before closing the incident. The exercise should demonstrate that the next automated renewal preserves the recovered connection contract, not only that today's manually installed certificate works.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Origin identity | Compare TLS name with the configured origin | Check certificate coverage and chain |
| Host header | Trace the hostname used by the application | Keep routing and TLS expectations aligned |
| Renewal rehearsal | Test the replacement certificate path | Confirm the public request recovers |
Frequently asked questions
Why did my browser work? It may have used a different hostname or reconstructed certificate information differently from the edge service.
Clouvenix can trace both proxy connections and the application host contract, producing a focused correction and a renewal check that helps prevent the same gateway error from returning.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.