Skip to content

500 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.

Before proceeding with the troubleshooting steps, it is a good idea to determine whether the issue is LiteSpeed-specific, or whether it happens with Apache, too.

Does it Occur with Apache?

If your server is running on an Apache control panel, such as cPanel or Plesk, there is an easy way to determine whether an issue is caused by your LiteSpeed server:

  1. Temporarily switch to Apache
  2. Repeat the steps that originally led to the issue.

Are you able to reproduce the error under Apache?


If the error could not be triggered under Apache, then the problem is likely to be a LiteSpeed server issue. Please open a ticket from your client area or email and provide as many details as possible, so that we may assist you.


If Apache experiences the same problems, then the issue is not a LiteSpeed Web Server issue.

Switch back to LiteSpeed Web Server, and keep reading! Even though it is not a server problem, we have provided the following troubleshooting documentation that we hope will help you to find the solution.


Overwhelmed? Don't have the time or interest to deal with these steps? We can help. Engage our team through Hourly Support, and we'll do the troubleshooting for you!

Determine the Scope

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 revert 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
  error_log = errors_log
If you only want to apply the above for a single domain for quick testing, you can add the following PHP override to the domain's .htaccess to enable the logging. Simply comment out or remove the lines after testing.
php_flag display_startup_errors on
php_flag display_errors on
php_value error_log errors_log
php_value error_reporting 32767

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, and a few examples, which may help you during the troubleshooting process.

Permission or Ownership Changes

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.

phpinfo.php owned by root instead of 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 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] 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] End of script output before headers: info.php

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

Faulty .htaccess

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.

Example 1

For example,

  RewriteRule ^(.*)$1 [P]
Will cause a 500 error. But change it to
  RewriteRule (.*)$1 [R=301,L]
and that will fix the issue.

Example 2

<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

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.

Example 3

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/"

Example 4

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"

Example 5

Syntax wrong for the following:

  Options All –Indexes

It should be:

  Options -Indexes

Example 6

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.

Different level of Rewrite rules misplaced to the wrong level

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>
    DocumentRoot /var/www/example/
    <Directory /var/www/example/>
        Allow From All
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule . /index.php [L]

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.

Incorrect Rewrite Rules misplace in differernt directories

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]

Bad PHP Code

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:


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

PHP Short open tag used when not being enabled in php.ini

When PHP parses a file, it looks for the opening and closing tags<?php and ?>, which tell PHP to start and stop interpreting the code between them. Parsing in this manner allows PHP to be embedded in all sorts of different documents, as everything outside of a pair of opening and closing tags is ignored by the PHP parser.

PHP also allows for the short open tag <?. However, it is only available if it has been enabled using short_open_tag=on in php.ini. If it has not been enabled in php.ini, a short open tag on a page will return a 500 error.

PHP Code with wrong php configuration settings

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;

CloudLinux LVE Limit Reached

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.

PHP Upgrade

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

Unsupported Version of PHP

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

PHP Scripts Time out

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.

Syntax or Coding Errors in Your CGI/Perl Script

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

Out of Memory in php.ini

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.

Too Many PHP Processes

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

Apache Running as SuEXEC while LSWS not on cPanel

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

  2016-03-10 15:39:45.601 [NOTICE] [] [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] [] [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.

Run Out of Swap Space

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.

Missing PHP Packages

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.

Missing Opcode Cache Module

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.

PHP Module Code Conflicting

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)

Disable/Enable Some Magento Modules

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/*

Some mod_security Rules May Cause a 500 Error

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

2018-05-12 04:13:16.673307 [NOTICE] [] mod_security rule [Id '2000145'] triggered! [Sat May 12 04:13:16 2018] [error] [client] 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.

Hacked Site

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

Perl script missing "Content-Type" header may return 500

Run a simple Hello World perl script at but it return 500 error.

  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";.

the right script should be:


  print "Content-Type: text/html\n\n";

  print "Hello, World!\n";

You can check the example here.

OWASP ModSecurity rule set may trigger 500 when using Imunify360 together

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.

Use Debug Logging

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.

Last update: February 9, 2024