HTTP 401, 403, 404, 502 and 504: diagnose the response
A request shows 403 in the browser while logs mention an upstream timeout. Identify which layer produced the response before using the status to narrow the cause. A lookup explanation is a starting point, not a substitute for request evidence.
Open tool: HTTP status codes1. Record the response context
In the browser network panel or actual HTTP client, record method, path, time, status, headers and a body summary. Use a request ID, when present, to correlate gateway and application logs. Remove cookies, Authorization and personal data before sharing.
Method: GET
Path: /api/profile
Status: 401
Request ID: demo-request-42
Body: {"error":"missing_credentials"}2. Investigate 401 and 403 separately
401 indicates a lack of valid authentication credentials. Check whether credentials were sent, whether they expired and what authentication challenge the server returned. JWT decoding helps inspect time claims but does not establish valid authentication.
403 means the server understood the request but refuses it. Inspect resource permissions, tenant boundaries and applicable policy. Do not assume every 403 is a bad password or that swapping tokens proves the issue is fixed.
3. A 404 can have more than one cause
Check path case, API version, the method’s route and resource ID. Proxy rewrites can deliver a different path upstream. Some services use 404 to conceal whether a resource exists, so also inspect authorization policy and logs.
4. Correlate gateway and upstream timing for 502 and 504
502 concerns an invalid upstream response received by a gateway; 504 concerns a missing timely upstream response. Compare the same request across edge, gateway and application logs to inspect connections, response validity and processing time.
Increasing a timeout can hide a slow query. Inspect upstream health, capacity and latency before deciding whether timeout settings or application work need changing.
5. Recheck the business result and retry deliberately
200 indicates HTTP-level success; still inspect the application status in the body. A timeout does not prove a write failed. Operations such as payments or record creation may already have run, so check the result or use the API’s idempotency mechanism before retrying.
Look up 401, 403, 404, 502 and 504, then inspect a demo response body with the JSON tool. curl conversion changes command quoting only; validate the real request in your own runtime.