How to Fix Common HTTP Errors in WordPress on a Linux VPS (Step-by-Step Guide)
If you run a WordPress site on a Linux VPS, you've almost certainly run into a vague "HTTP error" at some point. You try to upload an image, save a post, or load a page — and instead of working, you get a generic error message with no explanation.
The frustrating thing about WordPress HTTP errors is that they can be caused by dozens of different things: PHP settings, file permissions, memory limits, plugin conflicts, server modules… the list goes on.
In this guide, I'll walk you through the 6 most common causes of HTTP errors in WordPress, show you how to diagnose each one, and give you exact commands to fix them on a Linux VPS. We'll cover everything from quick PHP config tweaks to debugging misbehaving plugins.
Let's dive in.
Before You Start: A Quick Diagnostic Tip
Before trying every fix in this guide, check your server error logs first. This will save you a ton of time.
Most HTTP errors are logged somewhere on your server. On a typical Linux VPS:
- Apache error log:
/var/log/apache2/error.logor/var/log/httpd/error_log - Nginx error log:
/var/log/nginx/error.log - PHP-FPM error log:
/var/log/php-fpm/www-error.logor similar (depends on your PHP version)
Check the end of the log right after triggering the error:
tail -50 /var/log/nginx/error.log
The error message there will usually point you straight to the cause. If you're not sure what it means, just keep reading — we've got the most common fixes below.
Fix 1: HTTP Error When Uploading Images (PHP Upload Limits)
The Problem: You try to upload an image or file in WordPress, and you get an "HTTP error" or "the uploaded file exceeds the upload_max_filesize directive" message.
This is by far the most common WordPress HTTP error, and 9 times out of 10 it's caused by PHP's upload limits being too low.
Step 1: Find Your php.ini File
First, locate your PHP configuration file. Run this command:
php -i | grep "php.ini"
You'll see output like this:
Configuration File (php.ini) Path => /etc/php/8.1/cli
Loaded Configuration File => /etc/php/8.1/cli/php.ini
The exact path varies depending on your Linux distribution and PHP version. Note: if you're using PHP-FPM with a web server, the web-facing php.ini is often in a different location (e.g., /etc/php/8.1/fpm/php.ini) than the CLI one. If in doubt, create a phpinfo.php file in your WordPress directory to check.
Step 2: Edit php.ini and Raise the Limits
Open the php.ini file in your favorite editor (vim, nano, whatever you prefer):
nano /etc/php/8.1/fpm/php.ini
Find and update these settings:
upload_max_filesize = 64M
post_max_size = 128M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M
Quick explanation of each:
upload_max_filesize— maximum size of a single uploaded filepost_max_size— maximum size of all POST data combined (must be bigger than upload_max_filesize)max_execution_time— how long PHP can run before being killed (raise this for big uploads)max_input_time— how long PHP can spend parsing input datamemory_limit— maximum memory a PHP script can use
Save and exit (in nano: Ctrl+O, Enter, Ctrl+X).
Step 3: Restart PHP and Your Web Server
For the changes to take effect, you need to restart PHP-FPM and your web server:
# If using PHP-FPM + Nginx:
systemctl restart php8.1-fpm
systemctl restart nginx
# If using Apache with mod_php:
systemctl restart apache2 # or httpd on CentOS/RHEL
Alternative: .htaccess Method (Apache Only)
If you're on Apache and don't want to edit php.ini (or don't have root access), you can add these lines to your .htaccess file in the WordPress root directory:
php_value upload_max_filesize 64M
php_value post_max_size 128M
php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Alternative: Nginx Method
If you're using Nginx, you also need to set client_max_body_size in your server block to match. Otherwise Nginx will reject large uploads before they even reach PHP:
server {
listen 80;
server_name your-domain.com www.your-domain.com;
root /var/www/html/wordpress;
index index.php;
# Increase max upload size
client_max_body_size 128m;
client_body_timeout 300s;
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires max;
log_not_found off;
}
}
Save the config and reload Nginx:
nginx -t && systemctl reload nginx
⚠️ Important: Make sure
fastcgi_passmatches your actual PHP-FPM socket path (e.g.,/var/run/php/php8.1-fpm.sock) or TCP address (e.g.,127.0.0.1:9000). Check your PHP version — the socket path varies.
Fix 2: HTTP Errors Caused by Incorrect File Permissions
The Problem: Random HTTP errors, 403 Forbidden errors, or WordPress can't write files (uploads, plugins, themes, updates).
File permission issues are one of the most common causes of mysterious WordPress problems. If your files are owned by root or have the wrong permissions, PHP can't read or write to them properly.
The Fix: Set Correct Ownership and Permissions
First, figure out which user your web server runs as. On most Debian/Ubuntu systems it's www-data; on CentOS/RHEL it's usually apache or nginx.
# Find the web server user (Apache/Nginx)
ps aux | grep -E '(apache|nginx|httpd)' | head -5
Then fix all WordPress file ownership and permissions:
# Replace www-data with your actual web server user
# Replace /var/www/html/wordpress with your WordPress path
# Fix ownership
chown -R www-data:www-data /var/www/html/wordpress/
# Fix directory permissions (755 = readable/executable by all, writable by owner)
find /var/www/html/wordpress/ -type d -exec chmod 755 {} \;
# Fix file permissions (644 = readable by all, writable by owner)
find /var/www/html/wordpress/ -type f -exec chmod 644 {} \;
Why these specific permissions?
- Directories need to be executable (the
xbit) so you can enter them - Files should NOT be executable for security reasons
644and755are the WordPress-recommended standard
Fix 3: HTTP Errors Caused by Insufficient PHP Memory
The Problem: You get "HTTP error" or "Fatal error: Allowed memory size of X bytes exhausted" when doing things like updating plugins, importing content, or loading the admin area.
WordPress (plus plugins + themes) can be memory-hungry. The default PHP memory limit of 64MB or 128MB is often not enough, especially if you have a lot of plugins.
The Fix: Increase the WordPress Memory Limit
Add this line to your wp-config.php file, right before the "/* That's all, stop editing! */" line:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');
WP_MEMORY_LIMIT— memory limit for the front-end of your siteWP_MAX_MEMORY_LIMIT— memory limit for the admin area (can be higher)
Note: This only works if your server's PHP memory_limit in php.ini is at least as high. If php.ini sets a 128MB limit, WordPress can't magically override it to 256MB. Go back to Fix 1 and raise memory_limit in php.ini as well.
Fix 4: HTTP Errors Caused by Misconfigured PHP (cgi.fix_pathinfo, timezone, etc.)
The Problem: Strange HTTP 500 errors, blank pages, or PHP scripts not executing correctly. Sometimes you'll see "No input file specified." errors (especially with Nginx + PHP-FPM).
A few PHP settings that are commonly misconfigured and cause weird issues:
4a. Fix cgi.fix_pathinfo (Security + Compatibility)
When cgi.fix_pathinfo is set to 1 (the default), PHP tries to "fix" the path info in URLs, which can cause security issues and compatibility problems with Nginx.
Edit your php.ini:
nano /etc/php/8.1/fpm/php.ini
Find the cgi.fix_pathinfo line, uncomment it (remove the ; at the beginning), and set it to 0:
cgi.fix_pathinfo = 0
Restart PHP-FPM:
systemctl restart php8.1-fpm
4b. Set the Correct Timezone
If PHP's timezone doesn't match your server or WordPress settings, it can cause weird issues with scheduling, post dates, and cron jobs.
In php.ini, find and set:
date.timezone = America/New_York
Replace America/New_York with your actual timezone. You can find the full list of supported timezones on the PHP website.
Common values:
- US East Coast:
America/New_York - US West Coast:
America/Los_Angeles - UK:
Europe/London - China:
Asia/Shanghai - Singapore:
Asia/Singapore - Hong Kong:
Asia/Hong_Kong
4c. Other PHP Settings Worth Checking
display_errors = Off— should be off on production sites (log errors instead of displaying them)log_errors = On— make sure error logging is enabledupload_tmp_dir— make sure the temp upload directory exists and is writable
Restart PHP after making any changes:
systemctl restart php8.1-fpm
Fix 5: HTTP Errors Caused by Apache mod_security False Positives
The Problem: You get random 403 Forbidden errors, or specific WordPress actions fail (like saving certain posts, uploading files with specific names, or using certain plugins).
ModSecurity is an open-source web application firewall (WAF) that runs on Apache. It's great for security, but its rules can sometimes flag legitimate WordPress requests as attacks and block them — resulting in an HTTP error.
How to Test if mod_security is the Culprit
Add this to the .htaccess file in your WordPress root:
SecFilterEngine Off
SecFilterScanPOST Off
Then try the action that was failing. If it works now, mod_security was causing the problem.
⚠️ Important: Don't leave mod_security disabled permanently! That's like taking the lock off your front door because you keep forgetting your key. Instead:
- Identify exactly which rule is being triggered (check the mod_security audit log);
- Whitelist only that specific rule for that specific endpoint;
- Keep mod_security enabled for everything else.
If you're not sure how to do that, ask your hosting provider for help — it's a common request.
Fix 6: HTTP Errors Caused by Plugin or Theme Conflicts
The Problem: HTTP errors that started right after you installed, updated, or activated a plugin or theme.
WordPress's plugin ecosystem is amazing, but it's also the source of most problems. A poorly coded plugin, a theme conflict, or an outdated extension can cause all kinds of weird errors.
Step 1: Disable All Plugins
The fastest way to test if a plugin is causing the issue is to disable them all at once. There are two easy ways to do this:
Method A: Rename the plugins folder (via SSH)
# Replace the path with your actual WordPress path
mv /var/www/html/wordpress/wp-content/plugins /var/www/html/wordpress/wp-content/plugins.bak
This instantly disables all plugins. If the error goes away, you know it's a plugin issue. Rename the folder back, then disable plugins one by one until you find the culprit.
Method B: Use phpMyAdmin or WP-CLI
If you have phpMyAdmin or database access, you can disable all plugins by running this SQL query:
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';
Or if you have WP-CLI installed:
wp plugin deactivate --all
Step 2: Switch to a Default Theme
If disabling plugins doesn't fix it, try switching to a default WordPress theme like Twenty Twenty-Four. Theme conflicts are less common than plugin conflicts, but they do happen.
Via WP-CLI:
wp theme activate twentytwentyfour
Or rename your current theme's folder via SSH — WordPress will automatically fall back to a default theme.
Step 3: Re-enable One by One
Once the error is gone, re-enable plugins/themes one at a time, testing after each one. When the error comes back, you've found the culprit.
Then you can:
- Update the problematic plugin/theme to the latest version
- Find an alternative plugin that does the same thing
- Contact the developer for support
- Hire someone to fix the conflict
Bonus: 5 Quick Checks When You've Tried Everything
If you've gone through all 6 fixes above and still have the error, try these quick checks:
1. Check Disk Space
If your server is out of disk space, nothing works properly — uploads fail, PHP sessions break, and you get vague HTTP errors.
df -h
If the Use% column shows 95%+, you need to free up space or upgrade your disk.
2. Check Inode Usage
Even if you have free disk space, running out of inodes (file system entries) causes the same symptoms.
df -i
3. Check if mod_security or a WAF is blocking requests
We covered this in Fix 5, but it's worth double-checking — especially if errors only happen with certain actions or specific content.
4. Test with a Different Browser / Incognito Window
Sometimes it's a browser issue — cache, cookies, extensions. Rule that out first before digging into server config.
5. Enable WordPress Debug Mode
Add these lines to wp-config.php to get more detailed error messages instead of just "HTTP error":
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Errors will be logged to wp-content/debug.log instead of shown on screen, which is safe for production sites.
Summary: WordPress HTTP Error Troubleshooting Flowchart
Here's the order I recommend debugging in:
- Check error logs (web server + PHP) — 80% of the time this tells you exactly what's wrong
- Check PHP upload limits — if the error happens during uploads
- Check file permissions — 403 errors or "can't write" issues
- Increase memory limit — if it happens during heavy operations
- Disable all plugins — if it's a random/weird error
- Check mod_security / WAF — 403 errors with no obvious cause
- Check disk space and inodes — when all else fails
Most WordPress HTTP errors can be fixed in under 15 minutes if you know where to look.
💻 Looking for a WordPress-optimized VPS?
sixcvm offers high-performance KVM VPS perfect for running WordPress, with:
- ⚡ NVMe SSD storage — fast disk I/O for quick page loads and smooth uploads;
- 🐘 PHP 8.x optimized — latest PHP versions with OPcache and proper defaults;
- 🌐 Optimized network routes — low latency for visitors from all over the world;
- 🛡️ Free DDoS protection — 20Gbps baseline included;
- 👨💻 24/7 technical support — if you run into issues, we'll help you fix them;
- 💰 3-day money-back guarantee — try it risk-free.
