A 502 at a reverse proxy calls for checking the boundary between the proxy and the application. First find out whether the application answers directly on its intended local address. Then compare that result with the proxy's configured upstream and the public request.
Establish a known local response
On the relevant server or permitted internal path, request the application's health or representative route. Record the address, port, status and time. If the process does not answer there, investigate startup, listening configuration and the service account before changing public routing.
If the local response succeeds, verify the proxy targets that same destination using the correct protocol and path. A working service on one port does not help a proxy still pointing at an older release's port.
Preserve the proxy evidence
For IIS Application Request Routing, Microsoft documents distinct 502 substatus and underlying error information. Record these details along with a request timestamp. Other proxies have their own diagnostics; use the documentation for the actual product instead of interpreting every 502 as the same fault.
- Check the configured upstream address and scheme.
- Compare proxy and application logs for the same request.
- Verify the intended process is running and reachable from the proxy.
- Investigate repeated connection termination or unexpectedly long application work.
- Inspect any TLS or hostname requirements between proxy and upstream.
Change the demonstrated cause
Increasing a timeout without understanding the request can hide a slow or blocked operation. Confirm whether the duration is expected, whether the application completes and which layer terminates the request. Make a targeted correction, then retest the public route and a real business action.
For support, provide a compact comparison: local check result, public check result, sanitised proxy error and release time. This separates a process problem from a forwarding problem and reduces unnecessary changes to DNS or the website files.