Why do I get 500 - Internal Server Error? Print

  • 1

Problem Description

  • You receive a 500 error.
  • The logs might say Premature end of script headers
  • Logs might say Connection reset by peer: mod_fcgid: error reading data from FastCGI server

Problem Resolution

In most cases additional details about the error will be shown when you follow this guide to reading and interpreting logs using Plesk. If you're not seeing a more specific error around the same time (within 3 seconds) as the 500 error, then continue with these possible options:

1. Problems with .htaccess 

Disallowed Options: The most common version of this is having FollowSymLinks in one or more .htaccess files. Check the logs, as shown above, to learn which .htaccess file has the directive, and comment it out by placing a # at the start of the line that contains FollowSymLinks (or +FollowSymLinks).

SymLinks are disabled in shared hosting environments as they are commonly used as a medium to attack other websites hosted on the server. If you have your own VPS, FollowSymLinks can be enabled.

Redirect Problems: If you have a redirect in .htaccess that forces HTTPS or www (or no-www) but you also have these options enabled in Plesk, the redirects can conflict, creating endless loops and possibly server errors in the process. 

Ensure that you're using the Plesk options under "Hosting Settings" to set your "Preferred domain" and "Permanent SEO-safe 301 redirect from HTTP to HTTPS" and remove the redirect from .htaccess.

2. Problems with cloning, backups, or restores from backup

This is most often caused by a security plugin, like WordFence, attempting to load a particular file (like .user.ini) and failing to do so because the file hasn't yet been copied over or restored from backup. You should use the link above to find the actual log entry that corresponds with the error. it will show you which file is causing the problem so that you can rename it or remove it to get things working again. Here's an example of this in action:

mod_fcgid: stderr: PHP Fatal error: Unknown: Failed opening required '/home/username/domain.com/wordfence-waf.php' (include_path='.:/opt/plesk/php/7.0/share/pear') in Unknown on line 0

In this instance the hidden file called '.user.ini' found in the web root is attempting to load wordfence-waf.php from a non-existent location. Your best bet is to delete the .user.ini file or rename it to simply user.ini.bak to disable it. If you get a different filename/path, you probably just need to correct the path to solve the problem.

3. PHP and File Permissions

Your PHP Settings in Plesk are set to Apache Module mode and the wp-config.php file (or other core file) does not have 'other' read permissions

Please do not change the permissions -- wp-config.php is intended to have limited permissions to ensure optimal security of your website. Instead, change the PHP run mode to either FPM or FastCGI.

4. You receive a 500 error when working with Perl / CGI

If you have just uploaded the file via FTP:

Make sure your FTP app is configured to upload scripts in ASCII mode, not binary. If your FTP program is set to "auto-detect," make sure that the file type (.cgi or .pl) of the script is on the list of ASCII file types.

Perl Path:

Make sure that the path you are using for PERL in your cgi scripts is correct. The correct first line of your perl scripts should be: #!/usr/bin/perl

If you are using: #!/usr/bin/perl -w ; this is good for trouble shooting your code, but should be removed when you upload your files for public viewing. The -w option is to display warnings that your script outputs. If your script has warnings than you will get a 500 error every time, since it's displaying the warnings first, causing the premature end of script headers.

Syntax Errors:

if the code is broken or incomplete then it will return a premature end of script headers (500 error) PLUS another error indicating where in the file the script is failing to run. Find the code it's referring to in order to fix this. You will need a Perl developer if you are not one.


Make sure the permissions and ownership on the cgi-bin folder and everything within it are correct. This is how the ownership should be:

cgi-bin and all directories within -- user: login_username -- group: psacln -- permissions: 755

Executable Files (.cgi, .pl) within cgi-bin -- user: login_username -- group: psacln -- permissions: 740

You can make these changes with the Plesk File Manager as described here.

Or if you have/prefer shell, you can run these commands. Be sure to replace httpdocs with the correct web root folder for the domain:

cd httpdocs/cgi-bin
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
find . -name '*.cgi' -o -name '*.pl' -print0 | xargs -0 chmod 740
chown -r $USERNAME:psacln *

5. Actual server problem

The simple version: try running plesk repair web -- it might fix this for you.

If the logs don't indicate any specific issue and none of the above solve the problem, you will need root access to the server to continue. If you're on shared hosting or have a Platium managed server, ask us to look into this part for you.

The next step is to trace the generic error that you're seeing in the vhost-specific logs to the server-wide web server logs. Check /var/log/httpd/error_log and you will probably see some kind of additional error like this:

[error] mod_fcgid: process /var/www/cgi-bin/cgi_wrapper/cgi_wrapper(20820) exit(communication error), get unexpected signal 11

This indicates some kind of misconfiguration that needs to be tracked down. This particular error was generated when two PHP modules conflicted. The issue was reported to the developer to get it fixed, and the module was commented out.

Was this answer helpful?

← Back