Fixing the 500 Internal Server Error: Why .htaccess Rules Crash FastCGI & PHP-FPM

Few things cause a developer or site owner instant stress like clicking “Save” on a file and watching their entire website vanish behind a generic 500 Internal Server Error.

If this happened to you right after adding custom PHP directives (like php_value or php_flag) to your .htaccess file, don’t panic. Your files and database are completely safe. The issue comes down to a fundamental conflict between old Apache configurations and how modern web servers execute PHP.

In this guide, we’ll explain why this error happens, how to bring your site back online in seconds, and where to put your PHP directives instead.

Why .htaccess Directives Cause a 500 Error

Historically, web servers ran PHP directly as an Apache module (mod_php). Under mod_php, Apache understood custom PHP commands placed directly inside your .htaccess file, such as:

# Works on old mod_php servers, but crashes modern PHP-FPM
php_value max_execution_time 300
php_value session.gc_divisor 1000

However, modern hosting environments have almost universally moved to PHP-FPM (FastCGI Process Manager) or LiteSpeed (via ea-php or lsapi) for better speed, memory management, and security.

The Conflict Causing .htaccess to Produce 500 Internal Server Error

Under PHP-FPM/FastCGI, Apache handles web traffic, but hands off PHP processing to a separate execution engine. When Apache parses a .htaccess file containing raw php_value lines without knowing what they mean, it doesn’t just ignore them; it considers it a critical syntax error and halts everything with a 500 Internal Server Error.

How to Get Your Site Back Online Immediately

Before making permanent fixes, let’s restore your website so your visitors aren’t seeing an error page.

1. Connect to your server using your preferred FTP client (if you need help setting up access, check out our guide on how to connect to your server via Core FTP LE).
2. Navigate to your root WordPress directory (or the subfolder where your blog is installed).
3. Open your .htaccess file and locate the custom PHP directives you added.
4. Delete or comment out those lines (add a # in front of each line).
5. Save and upload .htaccess back to the server.

Your website should load normally again immediately.

Where to Put PHP Directives on Modern Servers

Now that your site is online, you still need a way to apply your custom PHP configurations (such as setting memory limits or adjusting execution times). Here are the two safe alternatives for PHP-FPM and FastCGI setups.

Option 1: Use a .user.ini File (Recommended)

Servers running PHP-FPM do not read PHP directives from .htaccess, but they do read a hidden file called .user.ini (dot-user-dot-ini).

1. In your root WordPress directory, create a new file named .user.ini.
2. Instead of using Apache syntax (php_value name value), use standard INI syntax (name = value):

; Custom PHP Directives for FastCGI / PHP-FPM
display_errors = Off
max_execution_time = 300
memory_limit = -1
upload_max_filesize = 100M
post_max_size = 100M
session.gc_divisor = 1000

3. Save and upload .user.ini to your site’s document root.

Note on Caching: PHP-FPM checks .user.ini periodically (usually every 5 minutes / 300 seconds), so changes may take a few minutes to reflect.

Option 2: Define Values via wp-config.php

If your server host locks down .user.ini files, or if you need an instant override that doesn’t wait for a 5-minute cache timer, you can define settings directly inside your WordPress configuration file.

1. Open wp-config.php via FTP.
2. Scroll to the line that reads /* That's all, stop editing! Happy publishing. */.
3. Right above that line, add your @ini_set commands:

// Force PHP runtime settings safely within WordPress
@ini_set('max_execution_time', '300');
@ini_set('session.gc_divisor', '1000');
@ini_set('session.gc_probability', '1');

4. Save and re-upload wp-config.php.

Summary of How to Fix .htaccess 500 Internal Server Error

• mod_php vs. FastCGI: Modern PHP-FPM servers do not recognize php_value in .htaccess and will crash with a 500 error if they encounter them naked.
• The Quick Fix: Revert your .htaccess edits to bring your site back online.
• The Long-term Fix: Move custom directives into a .user.ini file using standard key = value syntax, or use @ini_set() inside wp-config.php.

Once you have your custom PHP settings properly configured via .user.ini or wp-config.php, you can safely clear out annoying server warnings, such as resolving the session.gc_divisor error log warning in WordPress, without risking an Apache crash!