To diagnose HTTP errors, start with the browser request, continue with a direct curl test, and then match the request with entries in the web server or mail logs. Even when a browser shows only a generic 4xx or 5xx error page, the response contains useful evidence. This layered approach helps narrow the problem to the request, web server, proxy or CDN, or application.
Table of Contents
What evidence should you collect first?
Record the exact URL, the HTTP status code, the request method, and the time of the test. Keep the response headers and any visible response body. If the request was made from a page, also note the page URL that triggered it.
Use the same URL for each test where possible. Consistent test details make it easier to compare the browser result, the server response, and the matching log entry.
Check the failed request in browser developer tools
- Open the browser’s developer tools and select the network view.
- Reload the page or repeat the action that produces the error.
- Find the request with the 4xx or 5xx response.
- Open the request details and record the status code, request URL, method, response headers, and response body.
- Check whether other requests fail at the same time. Note whether the failed request is for the page itself, a script, a style file, an image, or an API endpoint.
The failed request identifies the resource that returned the error. If the main page succeeds but a script or API request fails, the problem is limited to that separate request rather than the complete page response.
Use the status code to choose the next check
A 403 response 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 possible causes can differ between those situations. See Reasons for Message 403 when the browser or command-line test returns 403.
For other 4xx and 5xx responses, keep the status code with the request details. The code tells you which response to compare with the server records, while the headers and response body may show whether the response came from the web server, an intermediate service, or the application.
Repeat the request with curl
Run the request from a shell where SSH access to the server is available. The curl command-line tool can measure how quickly a server responds without relying on external testing services. This makes it useful for checking whether the response is reproducible outside the browser. See Checking Website Response Time via Console (SSH).
- Run
curl -I https://example.com/pathto request the response headers for the affected URL. - Record the returned HTTP status and headers.
- Compare the result with the status and headers captured in the browser.
- Run the same test again if the result changes between requests, and record the time of each test.
Replace the example address with the exact URL that failed. A matching status in the browser and in curl shows that the response can be reproduced outside the browser. A different result means the two requests need closer comparison, including the URL and request method.
Measure response timing when speed is part of the error
A response can be technically returned while the underlying request remains slow. With SSH access, use curl to gather detailed timing information about the server response. Record the timing output beside the URL, status code, and test time. This gives the log review a precise time window and helps separate a slow response from an immediate error.
Repeat the timing check for the same URL. If the response time changes, keep each result rather than using only the fastest or slowest test.
Match the request with server and mail logs
- Use the recorded test time to select the matching period in the logs.
- Search for the requested path or other request details shown by the browser and
curl. - Compare the logged response with the status code returned to the browser.
- Note any script execution errors or incorrect server responses recorded at the same time.
Web and mail server logs are diagnostic records for website errors and email delivery issues. They can show script execution errors, incorrect server responses, problems with the PHP mail() function, and failed or blocked email sending. Use Web server and mail logs when the browser response alone does not identify the cause.
Connect each finding to the next action
| Finding | What it indicates | Next action |
|---|---|---|
| The browser request fails | A specific resource returned an error. | Record its URL, method, status, headers, and response body. |
The same status appears in curl | The response is reproducible outside the browser. | Use the matching time and request details to inspect server logs. |
| The response is 403 | Access to the requested resource was denied. | Review the 403 causes and the related server evidence. |
| Logs show a script execution error | The application or script is involved in the failed response. | Use the affected request and log time to identify the script path. |
| Logs show an incorrect server response | The web server recorded a response problem. | Compare that entry with the status and headers captured by both tests. |
When to contact support
Contact support with the exact URL, status code, request time, browser evidence, curl output, response timing, and the matching log lines. Include whether the response was 403, another 4xx status, or a 5xx status. This gives support a focused set of details for checking the web server, the request path, and the application evidence together.