Read an HTTP error before changing your server
Use the status, response headers and request path to identify which layer actually failed.
An HTTP error is evidence, not a diagnosis. Preserve the request and response before restarting services or changing configuration.
Start with three facts
Record the status code, the requested URL and the time including timezone. Then capture the response headers. A proxy, CDN and origin can each produce a different page for the same numeric status.
Separate client errors from server errors
A 4xx response usually means the request cannot be accepted as sent. Check authentication, path, method and request size. A 5xx response means a server in the chain could not complete a valid request; identify whether the response came from the edge, gateway or application.
Compare one known-good request
Use the browser network panel or a command-line client to compare method, headers and body. Change one difference at a time. Replaying a request is more reliable than guessing from a screenshot.
Follow the request through the stack
Match the timestamp and request ID across the edge, reverse proxy and application logs. If IDs are not propagated, add that before the next incident; it is a smaller improvement than adopting a new monitoring platform.
Keep the rollback obvious
Before changing a timeout, upload limit or proxy rule, record its current value. If the change does not alter the same request, revert it immediately.