Plesk 500 Internal Server Error: How to Fix It

A 500 Internal Server Error in Plesk typically means something has gone wrong at the application or server configuration level — not with Plesk itself. The error appears in the browser when a PHP script crashes, a .htaccess rule is invalid, or file permissions are incorrect. Before making any changes, always check the error logs first — guessing at causes wastes time and risks introducing new problems. This guide covers every common cause and how to diagnose and fix each one systematically.

Where to Find the Error Logs

Error logs are the first thing to check before touching any configuration. In Plesk, navigate to Websites & Domains, select the affected domain, then click Logs. This opens a real-time log viewer showing the most recent entries for that domain.

You can also access the domain error log directly via SSH at /var/www/vhosts/domain.com/logs/error_log. For PHP-specific errors, check the PHP error log — its location depends on your PHP settings, but it is commonly found in the same logs directory or defined under PHP Settings for the domain in Plesk.

Look for lines containing PHP Fatal error, Permission denied, or Syntax error — these will point you directly to the cause. Note the timestamp of the first occurrence, as it may coincide with a recent change such as a plugin update or PHP version switch.

Cause 1: Corrupt or Invalid .htaccess File

A malformed .htaccess file is the most common cause of a 500 error, particularly on WordPress sites. A single invalid directive will cause Apache to reject all requests for that directory.

To test whether .htaccess is the culprit:

1. Open Plesk File Manager and navigate to the domain’s httpdocs folder.
2. Right-click the .htaccess file and rename it to .htaccess.bak.
3. Refresh the site in your browser.
4. If the 500 error clears, the .htaccess file was the problem.
5. For WordPress sites, regenerate a clean .htaccess by going to Settings > Permalinks in the WordPress admin and clicking Save Changes — no other changes are needed.
6. For non-WordPress sites, review the original .htaccess rules manually, checking for syntax errors, unclosed conditions, or rules referencing modules that are not enabled.

If you need to inspect the .htaccess content via SSH, use cat /var/www/vhosts/domain.com/httpdocs/.htaccess to view it without opening an editor.

Cause 2: PHP Script Error or Fatal Error

If the error log shows lines beginning with PHP Fatal error, the issue is within the application code itself. On WordPress sites, this is frequently caused by an incompatible plugin or theme — particularly after a PHP version upgrade or a plugin update that introduced a bug.

1. Check the error log for the specific file and line number mentioned in the fatal error message.
2. If a plugin or theme file is named, deactivate it via the WordPress database or by renaming the plugin folder in File Manager.
3. If the error references a missing PHP extension (for example, Call to undefined function), check which extensions are enabled under Websites & Domains > PHP Settings for the domain and enable the required extension.
4. If the error indicates a memory issue, see Cause 5 below.

Cause 3: Incorrect File or Directory Permissions

Incorrect permissions prevent the web server user from reading application files, resulting in a 500 error. The correct permissions for most web applications are 644 for files and 755 for directories.

To fix permissions in Plesk, open File Manager, right-click the relevant file or folder, and select Change Permissions. Alternatively, correct permissions across the entire document root via SSH:

1. Connect to the server via SSH.
2. Run the following to set all files to 644: find /var/www/vhosts/domain.com/httpdocs -type f -exec chmod 644 {} \;
3. Run the following to set all directories to 755: find /var/www/vhosts/domain.com/httpdocs -type d -exec chmod 755 {} \;
4. Refresh the site to test.

Be careful not to apply 755 to files that should be protected, such as configuration files containing database credentials. Review any files that were manually uploaded and may have inherited incorrect permissions from an FTP client.

Cause 4: PHP Version Incompatibility

If a PHP version change was made recently in Plesk, an existing plugin, theme, or application may not be compatible with the newer version. This is a common trigger after upgrading from PHP 7.4 to PHP 8.x, as significant deprecations were introduced.

1. In Plesk, go to Websites & Domains and click PHP Settings for the affected domain.
2. Change the PHP version back to the previous one that was in use.
3. Save the settings and refresh the site.
4. If the error clears, the application is not yet compatible with the newer PHP version. Either update the application to a compatible version or keep the domain on the older PHP version until compatibility is confirmed.

Cause 5: Exhausted PHP Memory Limit

When the error log shows Allowed memory size of X bytes exhausted, the PHP process has run out of allocated memory before the script could complete. This is common on resource-heavy WordPress sites with multiple active plugins.

1. Go to Websites & Domains > PHP Settings for the domain in Plesk.
2. Locate the memory_limit directive and increase it — 256M is a sensible starting point for most WordPress installations.
3. If the error occurs on form submission or file upload, also review post_max_size and max_execution_time, both of which can cause a 500 error if the request exceeds their limits.
4. Save and test.

Cause 6: ModSecurity Rule Blocking the Request

If Plesk’s Web Application Firewall (ModSecurity) is enabled, an overly aggressive rule may block a legitimate request and return a 500 error rather than a 403. This is particularly common after updating the ModSecurity ruleset.

1. Go to Plesk > Tools & Settings > Web Application Firewall to confirm ModSecurity is active.
2. Check the ModSecurity audit log at /var/www/vhosts/domain.com/logs/modsec_audit.log for entries matching the timestamp of the error.
3. To test, temporarily disable ModSecurity for the affected domain via Websites & Domains > Web Application Firewall and set the mode to Off.
4. If the error resolves, review the audit log to identify the specific rule ID that triggered, then whitelist that rule rather than leaving ModSecurity disabled permanently.

If the Error Only Affects One URL

When the 500 error only appears on a specific page or URL rather than the whole site, the problem is almost certainly a URL-specific rewrite rule or routing issue. Check the .htaccess file for RewriteRule entries that match that path, and look for incorrect flags or regex syntax. On WordPress sites, a plugin that registers custom rewrite rules for that URL — such as a form plugin, landing page builder, or custom post type — is often responsible. Deactivating plugins one at a time while testing the affected URL will identify the culprit.

Escalation: Checking Apache and Nginx Error Logs

If none of the above steps resolve the issue, the problem may be at the server level rather than the domain level. Check the server-wide Apache error log, which is located at /var/log/httpd/error_log on CentOS/RHEL-based systems or /var/log/apache2/error.log on Debian/Ubuntu-based systems. These logs capture errors that do not appear in the per-domain logs.

Plesk also provides server health information under Tools & Settings > Server Health Monitor, which can indicate whether the server is under excessive load, has run out of memory, or has disk space issues — all of which can produce 500 errors at scale. If the error is intermittent rather than consistent, high server load or a misconfigured PHP-FPM pool is the most likely cause, and reviewing the PHP-FPM log under /var/log/plesk-php will provide further detail.

Related articles: Plesk Troubleshooting Guide