An HTTP error indicates that a request did not complete as expected. The code and message provide a starting point, but the time, action and relevant logs help establish the cause. A problem may affect a page, an application, the hosting service or an intermediary.
Before changing your website
- Record the exact code, message, affected page, time and time zone. Keep a screenshot and the request identifier, if one appears.
- Identify what is affected: one page, administration, forms or the whole website. Note the last known change, such as an update, a publication or a redirect adjustment.
- For an ordinary page view, try once in a private window or another browser. This helps compare sessions; it does not fix the cause. Avoid repeated attempts when a block or limit is displayed.
- If the error follows a payment, an order or a form submission, first check whether the action was recorded. A timeout does not necessarily mean it failed; submitting it again can create a duplicate.
If the browser instead reports a domain-resolution problem or a certificate warning, keep that specific message. Do not bypass a security warning to continue.
Errors 400 to 499: check the request and access
- 400, Bad Request: the request is rejected as invalid. Check the address and the action that triggers the message. If it happens only in one session, save your work before clearing data for that site only; this may sign you out.
- 401, Unauthorized: valid authentication is required. Use the website’s usual sign-in route and the account authorized for that area. A protected directory may use different credentials from WordPress or the Client Area. Keep password protection enabled.
- 403, Forbidden: access is refused. Check that you are visiting the intended address with the expected permissions. Access restrictions, security rules, file permissions or a missing home page may need investigation. The code alone does not identify which one applies.
- 404, Not Found: the requested page cannot be found or its existence is not disclosed. Check spelling, capitalization and links after a page has moved. If you manage the site, confirm that the page is published and its route remains valid before changing redirects.
- 406, Not Acceptable: the server cannot provide an acceptable representation for the request. Some applications or security layers also use this code. Record the specific action that triggers it; the code alone does not identify ModSecurity as the cause.
- 413, Content Too Large: the submitted content exceeds an accepted size. Record the file size and displayed limit. An application, server or intermediary may impose that limit. Ask which import method is suitable before increasing settings.
- 429, Too Many Requests: a request-rate limit has been reached. Stop repeated attempts and respect any stated waiting period. Note any recent automated task. Switching IP addresses or disabling a protection is not an appropriate fix.
Errors 500 to 504: investigate request processing
- 500, Internal Server Error: an unexpected condition prevents processing. Note recent changes and check available errors. Code, configuration and resource problems are possibilities to confirm.
- 502, Bad Gateway: an intermediary received an invalid response from an upstream service. Note whether all pages or only a particular function are affected.
- 503, Service Unavailable: the service cannot handle the request at present, including during maintenance or overload. Follow any displayed guidance and report persistent or repeated interruptions.
- 504, Gateway Timeout: an intermediary did not receive the expected response in time. Describe the operation and its approximate duration; avoid restarting a long-running task or transaction without checking its outcome.
If the issue follows a WordPress change, see our troubleshooting guide for problems after a change. Preserve the website’s state and recent data before deciding on a rollback.
The 508 “Resource Limit Reached” message
On hosting that uses CloudLinux, this message may indicate a concurrent entry-process limit. Check the measurements and limits reached at the time of the problem. Other resources can cause slowdowns or different errors; a single code does not describe the account’s overall usage.
The standard 508 “Loop Detected” code, used in a WebDAV context, has a different meaning. Record the full message. Our resource-usage guide explains how to gather useful measurements. One isolated error is not enough to conclude that a plan upgrade is needed.
If your website uses Cloudflare
Keep the exact code, time and displayed Ray ID, if present. Different 52x errors may call for checks of origin connectivity, response time or certificates. A Cloudflare logo alone does not establish where the failure occurred. Keep protections and the encryption level in place during investigation.
Check the information available in cPanel
If the tool is offered for your service, open Metrics > Errors. It displays recent web-server error log entries, up to a limit of 300. Application or intermediary errors may be recorded elsewhere. The absence of a matching entry does not prove that there is no problem.
Also compare the incident time with the history in Resource Usage or CPU and Concurrent Connection Usage, where available. If you cannot find this information, our team can guide you according to your service.
Keep changes targeted
Avoid globally disabling ModSecurity or the web application firewall, opening permissions to 777, or deleting or renaming .htaccess as a trial-and-error fix. That file may contain protections, redirects and rules required by the application. If a rule blocks a legitimate action, request a targeted investigation using the observed error.
Get help from Nuagerie
Open or update a request in your Nuagerie Client Area. Include the affected website and page, exact code, time with time zone, reproduction steps, impact and recent changes. Add a screenshot or a short relevant log excerpt if available. Our team may ask for your IP address privately if it helps locate the request.
Remove passwords, keys, session or reset tokens, customer data and unrelated information from screenshots and links. Do not publish your logs on a publicly accessible page.
These details help our team relate the symptoms to hosting information and identify the checks to pursue with your developer. If your site repeatedly encounters limits or needs application work, tell us about your needs: we can discuss optimization, development and hosting options suited to your usage.
