The 500 error is a generic web server response to an internal failure; It doesn't say that the problem is with WordPress, PHP-FPM, Apache/Nginx configuration or server resources. If you just refresh or change the .htaccess file without looking at the log, the sign may move but the cause remains. Record the time and URL of the error and follow the same request in the log.
Quick answer: First take a backup, verify the status code, read the error log of the web server and PHP at the same timestamp, and then start from low-risk changes such as disabling the newly changed component. In Nginx, the file .htaccess is not read; Rebuilding it is not the solution for Nginx.
Is the error on all pages or just one path?
| Template | Practical suspects |
|---|---|
| All sites and wp-admin | PHP global fatal, configuration or Sources |
| Only one entry or endpoint | Same path code, invalid data or query |
| only after login | admin plugin, session, role or AJAX |
| occasional under load | worker, memory, timeout or database |
read appropriate log
In Nginx, the error log shows what the upstream responded or why the connection was terminated. In Apache, rewrite, permission and PHP errors are seen. The exact path depends on the distribution and virtual host; Find it in the settings of the same server. For the systemd service, the time range can be read without changing the service:
journalctl -u php8.3-fpm --since "10 minutes ago"
journalctl -u nginx --since "10 minutes ago"The unit name of the PHP version on your server may be different. Do not publish the log publicly; token, internal path or user data may be inside. Also for Apache, find the unit and log file from the actual configuration.
Solutions from low-risk to advanced
- Revert the last change: Temporarily disable the new plugin or snippet. If the deployment is done, the rollback of the same release is more reliable than the scattered restoration of the files.
- Find fatal PHP: keep debug enabled only for logging and error display disabled. Base the file name and the first line of exception.
- Apache and htaccess: Keep the current version, then rename
.htaccessto test. Security, redirect and cache rules must be returned later. - License and ownership: Files must be readable by the appropriate user of the web server.
chmod 777not a generic solution; First, determine the deployment ownership model. - Resources: Check disk space, inode, RAM and process limits. Full disk can disrupt session, cache and log.
- PHP-FPM: Adapt worker exit, max children and timeout to actual load. Blindly increasing the worker without accounting for RAM may cause OOM.
500 is different from 502 and 504
500 usually means that the application or web server has completed the request with an internal failure. 502 mostly refers to an invalid response or upstream connection disconnection, and 504 means that the proxy did not receive a response within the specified time limit. A CDN may display a similar page; header and log origin are decisive.
follow the request path layer by layer
In the simple architecture, the request goes from the browser to the web server and then to PHP-FPM. In other architectures, there are also CDN, WAF, load balancer or reverse proxy. Response times, headers, and a request identifier—if the infrastructure generates one—help correlate errors between layers. If the CDN shows the number 500, but the origin registered 200 for the same request, the cache or edge path should be checked; If origin also has 500, move focus to application and upstream.
For origin test, don't bypass access control and TLS and don't make private IP or management port public. A controlled internal request or monitoring tool is more secure than temporarily opening the firewall.
Isolate configuration errors with syntax testing
After changing Nginx, test the configuration structure before reloading. The successful syntax does not mean that the route logic is correct, but it prevents the service from being interrupted due to a typo:
nginx -tExecution of reload and the location of the settings file depends on how the service is installed and managed. In Apache, use the config test tool according to the distribution. Do not replace the anonymous configuration piece without backing up the file and knowing the virtual host is active.
If the error only occurs under load
A normal request may be fine, but high concurrency will exhaust the PHP-FPM queue, database connection, or RAM. Put the number of requests, query duration, busy workers and OOM events in a timeline. Increasing pm.max_children without calculating the consumption of each process can increase the memory pressure. Also, increasing the timeout will only make a faulty query fail later.
Checking resources non-disruptively
df -h
df -i
free -h
uptimeThese commands only read the status. Do not solve filesystem fullness by blindly deleting the log or database file. First, identify the consumer, correct the retention and delete only the data whose retention and backup policy is clear.
Errors that spoil the diagnosis
- Simultaneous change of PHP, plugin, template and web server.
- Increasing all timeouts without finding slow query.
- Delete logs before keeping error sample.
- Copy Nginx configuration without running
nginx -t. - Sequential restart that removes crash evidence.
When to intervene Is it necessary to specialize?
If the stack trace reaches a plugin, first execute the recovery method after plugin update; Critical Error guide is more suitable for WordPress general message.
If 500 is random, only occurs under load, you have multiple CDN and proxy layers, or the log reaches segmentation fault, OOM, and database, the issue is not just a WordPress setting. WordPress technical review Can specify the relationship between request, PHP-FPM, web server and MySQL and implement changes with rollback.
FAQ
Is it safe to delete.htaccess?
No. Security and redirect rules may be in it. backup the file and rename it for testing; It has no effect on Nginx.
Why does the error disappear after refresh?
Maybe one of the workers is broken or the resource is temporarily low. This behavior is not fixable and should be tracked with a timestamp in the log.
Is CDN causing 500?
Sometimes CDN displays origin error. Check the response and the origin log separately to determine where the status is generated.