Understanding 500 Internal Server Error

The 500 status code, or “Internal Server Error,” means that the server cannot process the request for an unknown reason. Sometimes this code will appear when more specific 5xx errors are more appropriate.

The most common causes for this error are server misconfiguration (e.g. a malformed .htaccess file), missing packages (e.g. trying to execute a PHP file without PHP installed properly), permission or ownership changes, improperly configured php.ini, a PHP upgrade, etc. Anything that the server doesn't know how to handle can trigger a 500 error in a website. The impact of the error can vary based on the event that triggered it.

500 error is not a LiteSpeed Web Server specific error. If you use a control panel like cPanel, you can try the same steps with Apache. Most likely, Apache will return the same 500 error as LSWS. You will need to find root cause of the problem. If it does not happen to Apache server but only on LSWS, you can log a ticket with us for further investigation.

To troubleshoot a 500 error, first check whether the error affects just one site or every site in the server. Depending on the impact of the error, you can debug further. If only one domain is affected, it can be pin-pointed to a specific script error or permission issue. If multiple domains show a 500 error, it could be due to some server wide setting change or update.

You can check the server error_log, stderr.log or PHP error log (normally located where the PHP script is running) to see if there is any hint of the error. During the troubleshooting, you may want to ensure PHP error reporting is on in php.ini. Please reverse the settings back when you're done with debuging.

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT  ->   error_reporting = E_ALL
display_errors = Off -> display_errors = On
display_startup_errors = Off -> display_startup_errors = On

Please be aware that not all 500 errors appear in the logs and it is common not to see any hint in log files This makes troubleshooting more difficult.

Here are some of the common reasons/examples, which may help you during the troubleshooting process.

Permission or ownership changes may cause 500 error.

For example, to enable the LiteMage extension in your Magento installation through SSH, you will need to run a a non-root user. However, if you run the command incorrectly as the root user, the Magento front end may return 500 instantly. The fix is to reverse file ownership and permissions back to the original user.

Sometimes we need to check phpinfo page during the troubleshooting. When ssh login as root to server, go to document root and create phpinfo.php, the phpinfo.php file will be owned by root:root instead of user:user.

Sometimes it may return 500 error when accessing domain.com/phpinfo.php if some restriction set there but not always.

The server error may show the following: [Thu Jun 07 21:04:36.450359 2018] [:error] [pid 3807521:tid 139749549020928] [client 77.82.94.132:9254] SoftException in Application.cpp:382: UID of script “/home/vivi/public_html/phpBB2/info.php” is smaller than min_uid [Thu Jun 07 21:04:36.450651 2018] [core:error] [pid 3807521:tid 139749549020928] [client 77.82.94.132:9254] End of script output before headers: info.php

Changing the info.php to be owned by user:user will generally fix the issue.

There is a huge range of things .htaccess can do and it isn't difficult to use, however, if you do not enter the syntax correctly it can result in a Server 500 Error.

For example,

RewriteRule ^(.*) http://www.example.com/$1 [P]

Will cause a 500 error. But change it to

RewriteRule (.*) http://www.example.com/$1 [R=301,L]

and that will fix the issue.

<Directory>…</Directory > can not be used in .htacess and it will cause 500 error for Apache, While LSWS will ignore the unsupported directive instead of giving 500 error.

For example, the following should not be used in .htaccess.

<Directory /home/user1/public_html/wp-admin/>
  Deny from all
</Directory>

instead, you can create .htaccess under /wp-admin/ and place diretive there.

Deny from all

To confirm whether a misconfiguration in .htaccess is the cause of the 500 Internal Server error, either remove or rename the .htaccess file temporarily and then try to reload the page.

The following “Alias” directive in .htaccess will cause 500 on Apache (LSWS will ignore it without returning 500) since “Alias” directive is not allowed in .htaccess.

Alias "/" "/home/$USER1/public_html/"

Syntax is wrong for the followintg directive:

Header always set Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

which will lead to “Too many arguments to directive” error in error_log:

[Tue Sep 11 19:59:40.864917 2018] [core:alert] [pid 15738] [client 66.666.76.139:64740] /home/example/public_html/.htaccess: Too many arguments to directive

The correct syntax is the following and it should fix the 500 error for Apache:

Header always set Strict-Transport-Security: "max-age=63072000; includeSubDomains; preload"

Syntax wrong for the following:

Options All –Indexes

It should be:

Options -Indexes

php_value and php_flag are for mod_php handler. Most of the time php-fpm or lsphp will be used and mod_php has been deprecated most of the time. When you use php_value or php_flag, Apache will return 500 error. However, lsphp supports php override in .htaccess without any problem and there is no 500 error when running LSWS.

Per virtual host rewrite rules (rewrite rules in Apache virtual host configuration) and per directory rewrite rules (rewrite rules in .htaccess) are different. When placing the same rules to the wrong place, it may cause 500 error.

For example, the following works in .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule . /index.php [L]

Putting the same thing in Apache VirtualHost config doesn’t work at all:

<VirtualHost *:80>
  ServerName example.com
  DocumentRoot /var/www/example/
  <Directory /var/www/example/>
      Allow From All
  </Directory>
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule . /index.php [L]
</VirtualHost>

Apache doesn’t tell you why it doesn’t work. It just doesn’t work. You most likely will get an Error 500 status with a message in the logs that looks like this:

Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace.

The following rewrite rules in subfolder is incorrect and it will cause 500 for LiteSpeed. /home/user1/public_html/subfolder1] vi .htaccess

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ subfolder1/index.php/$1 [L]

The correct rule should be: /home/user1/public_html/subfolder1] vi .htaccess

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]

An improperly configured php.ini may lead to 500 error.

For example, set the following in php.ini:

open_basedir = "/path/to/folder"

If the /path/to/folder directory does not exist, it will cause a 500 error.

Bad PHP code will bring a website to 500 immediately.

For example, the right syntax should be:

 $this->getResponse()->setRedirect(Mage::getBaseUrl()) ;

If the “$” is removed somehow:

  this->getResponse()->setRedirect(Mage::getBaseUrl()) ;

It will bring the website to 500 immediately. This is only one example. Many times, wrong PHP syntax will lead to a 500 error.

Another example is:

<?php
phpinfo():
?>

A typing error : in phpinfo page , which should be ;, will lead to 500 error.

Sometimes, a 500 error may be not easy to locate. If you move .htaccess to .htaccess.bak and move php.ini to php.ini.bak, and the 500 error still happens, it might mean there is something wrong in the PHP code. That can be hard to find.

We experienced a case with WHMCS. Someone placed an incorrect setting in configuration.php:

$display_errors = E_All;

E_All is an incorrect value for the PHP $display_errors setting. Rather, it is meant for the $error_reporting setting. $display_errors should be either true/false, or on/off. We changed it to true, and that fixed the 500 error.

$display_errors = true;

On Plesk, if a PHP handler is not set, it will prompt a 500 error.

When using CloudLinux, If the site is limited by memory or process limits, then the user may receive 500 errors because the server cannot execute the script. Learn more.

For example, you might see some error like the following:

2019-01-11 00:14:23.330946 [ERROR] [APVH_xsrvnecw_Sulsphp56:]: Failed to start one instance. Resource limit reached!

The above indicates an Error by Cloudlinux. Increasing the LVE for that user may fix the issue.

Sometimes if PHP upgrades with a bug, it may cause a 500 error.

Unsupported PHP version used by the site/theme/plugin/module may lead to a 500 error.

If your PHP script makes external network connections, the connections may time out. If too many connections are attempted and time out, this will cause a “500 Internal Server Error.” To prevent these time outs and errors, make sure that PHP scripts are coded with some timeout rules. Typically, it's difficult to catch a timeout error when connecting to a database or remote resources, as they effectively freeze the script.

If it is a web page ending in .cgi or .pl that is producing the error, check your script for errors.

In this example, we checked stderr:

tail /var/log/httpd/stderr.log

2016-03-01 12:07:03.573 [STDERR] Tue Mar  1 12:07:03 2016 (12700): Fatal Error Unable to allocate shared memory segment of 134217728 bytes: shmat: Cannot allocate memory (12)

We further checked the phpinfo page and found the memory limit was set to “128M” only. Opcode cache solution is “128M” by itself, and so there is no memory left for anything else. This leads to a 500 error.

Increase the PHP memory limit from “128M” to 1024M” to fix the issue.

If there are too many processes in the server queue, it could exceed resources and lead to a 500 error.

In a cPanel/WHM environment, Apache runs as SuEXEC, however LSWS doesn’t.

2016-03-10 15:39:45.601 [NOTICE] [173.245.52.237:51548] [STDERR] PHP Warning: require_once(/home/demowebsites/public_html/goodmail/wp-config.php): failed to open stream: Permission denied in /home/demowebsites/public_html/goodmail/wp-load.php on line 37 
2016-03-10 15:39:45.601 [NOTICE] [173.245.52.237:51548] [STDERR] PHP Fatal error: require_once(): Failed opening required '/home/demowebsites/public_html/goodmail/wp-config.php' (include_path='.:/opt/cpanel/ea-php70/root/usr/share/pear') in /home/demowebsites/public_html/goodmail/wp-load.php on line 37

It is necessary to keep LSWS set the same as Apache. Enable LSWS PHP SuEXEC to fix the issue.

Checking error.log shows:

Failed to obtain or reinitialize VMemBuf. possibly running out of swap space

500 error is returned. Relocating the LSWS swap directory to a partition with enough space will fix the issue.

Installing PrestaShop returns a 500 error in Chrome. Check the error log and it shows php70-json package is missing. Install the missing packages and the 500 error is gone.

A WordPress site returns a 500 error when using go2pay, but there is no hint in the server error_log, stderr.log or PHP error_log. Upgrading the PHP version and adding the opcode cache module fixes the issue. Some applications or plugins may need opcode cache to run.

Magento returns a 500 error and shows a module conflict.

a:5:{i:0;s:54:"Mage registry key "umm_top_menu_exists" already exists";i:1;s:4439:"#0 /home/yourhome/public_html/app/Mage.php(223): Mage::throwException('Mage registry k...')
#1 /home/yourhome/public_html/app/design/frontend/ultimo/default/template/infortis/ultramegamenu/mainmenu.phtml(54): Mage::register('umm_top_menu_ex...', true)
#2 /home/yourhome/public_html/app/code/core/Mage/Core/Block/Template.php(241): include('/home/furnishyo...')
#3 /home/yourhome/public_html/app/code/core/Mage/Core/Block/Template.php(272): Mage_Core_Block_Template->fetchView('frontend/ultimo...')
#4 /home/yourhome/public_html/app/code/core/Mage/Core/Block/Template.php(286): Mage_Core_Block_Template->renderView()
#5 /home/yourhome/public_html/app/code/core/Mage/Core/Block/Abstract.php(923): Mage_Core_Block_Template->_toHtml()
#6 /home/yourhome/public_html/app/code/core/Mage/Core/Block/Text/List.php(43): Mage_Core_Block_Abstract->toHtml()
#7 /home/yourhome/public_html/app/code/core/Mage/Core/Block/Abstract.php(923): Mage_Core_Block_Text_List->_toHtml()
#8 /home/yourhome/public_html/app/code/core/Mage/Core/Block/Abstract.php(641): Mage_Core_Block_Abstract->toHtml()
#9 /home/yourhome/public_html/app/code/core/Mage/Core/Block/Abstract.php(585): Mage_Core_Block_Abstract->_getChildHtml('topMenu', true)

When disabling extendare_EWCore.xml by changing from “True” to “false, it shows a 500 error. Remove Magento cache files and fix the problem:

rm -rf var/cache/*

Adding Javascript to a WordPress plugin causes a 500 error. Enable LSWS debug logging and find:

 
2018-05-12 04:13:16.673307 [NOTICE] [47.22.54.182:54823#APVH_latampolitics.carinsurancegeorgia.org] mod_security rule [Id '2000145'] triggered! [Sat May 12 04:13:16 2018] [error] [client 47.22.54.182] ModSecurity: Access denied with code 500, [Rule: 'REQUEST_URI|REQUEST_BODY' '<space:(script|about|applet|activex|chrome) >.(script|about|applet|activex|chrome)space: >'] [id "2000145"] [rev "1"] [msg "xss"] [severity "CRITICAL"]

A mod_security rule lead to the 500 error. Disable that mod_security rule to fix the issue.

If your site is being hacked, it may trigger a 500 error.

Run a simple “Hello World” perl script at http://exmaple.com/cgi-bin/test.pl but it return 500 error.

vi test.pl

  #!/usr/bin/perl
  print "Hello, World!\n";

A Perl CGI script must output the header, HTML code and also must begin with a special first line. In this case, header “Content-type” is missing and it is not a CGI script. Please also be aware that there is a blank line after print “Content-Type: text/html\n\n”;.

the right script should be:

<code>
  #!/usr/bin/perl
  
  print "Content-Type: text/html\n\n";
  
  print "Hello, World!\n";

You can check the example here.

If you use LSWS ealier than 5.4.1 build 7, you may see 500 error when both OWASP and Imunify360 used at the same time. LSWS 5.4.1 and above version should have fixed this issue and LiteSpeed user can use both rule sets at the same time.

OWASP rule set may conflict with the Imunify360 default rule set on a server running LiteSpeed Web Server. Please choose only one mod_security rule set.

For OWASP rulesets, in crs-setup.conf:

SecAction "id:900990, phase:1, nolog, pass, t:none, setvar:tx.crs_setup_version=302"

in /etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-901-INITIALIZATION.conf

SecRule &TX:crs_setup_version "@eq 0" "id:901001, phase:1, auditlog, log, deny, status:500, severity:CRITICAL, msg:'ModSecurity Core Rule Set is deployed without configuration! Please copy the crs-setup.conf.example template to crs-setup.conf, and include the crs-setup.conf file in your webserver configuration before including the CRS rules. See the INSTALL file in the CRS directory for detailed instructions.'"

crs-setup.conf has to be loaded first then the rest of rules including REQUEST-901-INITIALIZATION.conf.

Imunify360 could break the loading order of the above rule set and lead to “500” errors.

Debug logging is helpful when looking for the cause of 500 errors. To begin capturing debug logs, please see How to Toggle Debug Logging.

You can investigate these logs further, or you can forward them to our Support Team for assistance.