How to Fix 504 Gateway Timeout on LiteSpeed (WordPress Runbook)

Immediate Diagnostic: Identify and Kill Stalled LSPHP Workers

# Check active LiteSpeed PHP workers and memory consumption
ps aux | grep lsphp

# Kill hung LSPHP processes causing gateway lockup
pkill -9 lsphp

# Inspect real-time LiteSpeed error output
tail -n 50 /usr/local/lsws/logs/stderr.log

# Restart LiteSpeed Web Server immediately
systemctl restart lsws

A 504 Gateway Timeout on LiteSpeed occurs when LiteSpeed Web Server (LSWS) does not receive an HTTP response from the backend PHP process (LSPHP) within the configured timeout window. The commands above terminate deadlocked worker threads and free locked IPC memory buffers.

1. Adjust LiteSpeed External Application Execution Limits

# Open LiteSpeed Server Configuration
nano /usr/local/lsws/conf/httpd_config.conf

# Verify or raise the external application timeout limits inside extProcessor:
# extProcessor lsphp82 {
#   ...
#   connTimeout             300
#   initTimeout             300
#   retryTimeout            0
#   respBuffer              0
# }

# Test LiteSpeed configuration syntax
/usr/local/lsws/bin/lswsctrl test

# Graceful restart LiteSpeed to apply timeout changes
/usr/local/lsws/bin/lswsctrl restart

If you manage LiteSpeed via CyberPanel or direct WebAdmin (port 7080):

• Navigate to Server Configuration > External App > Select your active PHP version (e.g., lsphp82 or lsphp83).
• Set Connection Timeout (secs) to 300.
• Set Initial Request Timeout (secs) to 300.
• Set Max Connections to 100 (or tune according to your available CPU cores).

2. Increase WordPress PHP Limits in .htaccess and .user.ini

# Add exact execution directives to public_html/.htaccess
cat << 'EOF' >> /var/www/html/.htaccess

# LiteSpeed PHP Configuration Rules

  php_value max_execution_time 300
  php_value max_input_time 300
  php_value memory_limit 512M
  php_value post_max_size 64M
  php_value upload_max_filesize 64M

EOF

# For LiteSpeed running lsphp in suEXEC daemon mode, place matching directives in .user.ini:
cat << 'EOF' > /var/www/html/.user.ini
max_execution_time = 300
max_input_time = 300
memory_limit = 512M
EOF

chmod 644 /var/www/html/.htaccess /var/www/html/.user.ini

LiteSpeed reads .htaccess and .user.ini per-directory without restarting the daemon. These values ensure heavy database queries, WooCommerce reporting, or backup exports do not terminate prematurely at 30 or 60 seconds.

3. Diagnostic WP-CLI Commands to Pinpoint Offending Plugins

# Measure execution time of WordPress core loading without plugins
wp core check-update --path=/var/www/html

# Identify active plugins and their status
wp plugin list --status=active --path=/var/www/html

# Test for long-running database queries and transients
wp transient delete --expired --path=/var/www/html
wp db check --path=/var/www/html
wp db optimize --path=/var/www/html

# Safe plugin deactivation test if dashboard is inaccessible
wp plugin deactivate --all --path=/var/www/html

If deactivating all plugins clears the 504 error, re-enable plugins one by one using wp plugin activate <slug> until the timeout re-occurs. Faulty third-party API webhooks and unindexed database queries are the primary causes.

4. Clear Stale LiteSpeed Cache and Swap Buffers

# Purge all LiteSpeed web cache files from disk
rm -rf /tmp/lshttpd/swap/*
rm -rf /tmp/lshttpd/bak/*
rm -rf /var/www/html/wp-content/lscache/*

# If using LSCache WordPress plugin via WP-CLI:
wp lscache-purge all --path=/var/www/html

# Test origin response directly without Cloudflare/CDN proxy
curl -Iv -k --resolve yourdomain.com:443:127.0.0.1 https://yourdomain.com/

Testing your origin directly with curl --resolve confirms whether the 504 is triggered by your local LiteSpeed server or by an upstream reverse proxy timeout.

---

Escalate to SiteSuraksha Engineering

If your 504 Gateway Timeout persists due to corrupted InnoDB database tables, recurring process deadlock, or upstream Cloudflare proxy failures, escalate to SiteSuraksha.

SiteSuraksha provides 24/7 dedicated WordPress FinOps, LiteSpeed optimization, Redis tuning, and root-cause error remediation for mission-critical Indian and global web properties.