HTTP error logs record how a failed request was handled at different points in the delivery chain. A browser, CDN, proxy, and origin server may show different status codes because each component records the response it received or returned. Comparing the records by time, request details, and identifiers helps connect those entries to one failure.
Table of Contents
Why can one failed request have different status codes?
A request can pass through several components before it reaches the origin server. The browser records the response visible to the visitor. A CDN or proxy can record the response at its own layer. The origin server records how it handled the request that reached it.
These records describe different points in the same request path. The status code shown by the browser is therefore not always the status code generated by the origin server. An intermediate component may return a response before the request reaches the origin, or it may return its own response after receiving one from upstream.
For this reason, compare the browser result with the CDN, proxy, and origin records instead of treating one status code as the complete history of the request.
What does a 403 status code mean?
A 403 error means that access to the requested resource was denied. The server understood the request but refused to provide the content. This can affect website visitors and website owners, and the cause or next step may differ between those situations. See Reasons for Message 403 for the meaning of this response.
If a browser shows 403 but another log contains a different status, check which component produced each entry. The 403 may describe the final response shown to the visitor, while another record may describe an earlier or upstream response.
Which log fields should I compare?
Use the following fields to decide whether entries belong to the same request:
- Timestamp: Compare the date and time recorded by each component. Account for the fact that the entries may be created at different points in the request flow.
- Request path: Match the requested path, including the relevant URL path for the failed resource.
- Hostname: Confirm that each entry refers to the same host. Similar paths on different hostnames are separate requests.
- Upstream status: Compare the status received from the next component with the status returned to the previous component. This helps show where the response changed.
- Client IP address: Compare the client IP recorded at each layer. A proxy or CDN may record the address of the connecting layer rather than the address shown in another log.
- Request ID: Use the same request ID when it is present in more than one log. This is the strongest direct link between entries from different components.
How do I trace one failed request across the delivery chain?
- Start with the browser result. Record the status code, hostname, request path, and time shown for the failed request.
- Find the matching CDN or proxy entry. Match the hostname and path first, then narrow the results by timestamp, client IP, or request ID.
- Inspect the upstream status. Compare the status received by the CDN or proxy with the status it returned to the browser.
- Check the origin log. Use the same path, hostname, timestamp, client IP information, or request ID to find the request at the origin server.
- Compare the sequence. Record the status at each point: browser, CDN or proxy, and origin. The first point where the status differs identifies the part of the chain that needs closer review.
Web and mail server logs are diagnostic tools for analyzing website errors and other server issues. They can help identify script execution errors and incorrect server responses. See Web server and mail logs.
What if the logs do not show the same client IP?
Do not use the client IP as the only matching field. Compare it with the timestamp, hostname, request path, and request ID. The client IP may be recorded differently at different points in the delivery chain, while the other fields can provide additional ways to identify the request.
What if there is no request at the origin?
If the browser and an intermediate component contain matching entries but the origin has no corresponding entry, compare the upstream status and request ID fields. These fields help establish whether the request reached the origin or whether the response was produced earlier in the chain.
How should I use the result?
Keep a short sequence of the matching entries and note the status returned at each layer. A 403 confirms that access to a resource was denied, but the surrounding log fields show which component recorded that response and how it relates to the other entries. This makes the investigation more precise than reviewing the browser status alone.