Fixing Apache 502 Bad Gateway on AWS EC2

The Root Cause

On AWS EC2, an Apache 502 Bad Gateway error typically signifies that Apache, acting as a reverse proxy, received an invalid response from an upstream application server (e.g., PHP-FPM, Node.js, Tomcat). This usually occurs because the backend application server is down, unresponsive, or its configuration prevents Apache from establishing a proper connection, leading to a proxy failure.

Quick Fix (CLI)

This quick fix assumes Apache is proxying requests to PHP-FPM, a common scenario. Adjust service names and commands based on your specific backend application (e.g., tomcat for Tomcat, node-app for Node.js).

# 1. Check the status of the backend application service (e.g., PHP-FPM)
# If using Amazon Linux/CentOS/RHEL:
sudo systemctl status php-fpm 
# If using Ubuntu/Debian:
# sudo systemctl status php7.x-fpm # Replace x with your PHP version

# If the service is not 'active (running)' or shows errors, restart it
sudo systemctl restart php-fpm

# 2. Check Apache's status
# If using Amazon Linux/CentOS/RHEL:
sudo systemctl status httpd
# If using Ubuntu/Debian:
# sudo systemctl status apache2

# If Apache is also in a bad state or the backend restart didn't resolve the issue, restart Apache
sudo systemctl restart httpd

# 3. Review Apache error logs for more specific details about the 502 error
# If using Amazon Linux/CentOS/RHEL:
sudo tail -f /var/log/httpd/error_log
# If using Ubuntu/Debian:
# sudo tail -f /var/log/apache2/error.log

Configuration Check

Verify Apache’s proxy configuration and the upstream application’s listening address/socket.

File to edit:
`/etc/httpd/conf.d/vhost.conf` (or `httpd.conf`, `/etc/apache2/sites-available/your_site.conf`)

Lines to check/change (example for PHP-FPM via FCGI):

# Ensure necessary Proxy modules are loaded in your Apache configuration (e.g., httpd.conf or /etc/httpd/conf.modules.d/)
# LoadModule proxy_module modules/mod_proxy.so
# LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
# LoadModule proxy_http_module modules/mod_proxy_http.so # If proxying to another HTTP server

# Example ProxyPassMatch directive for PHP-FPM via Unix socket (most common for performance)
# Ensure the socket path matches your PHP-FPM configuration
<IfModule mod_proxy_fcgi.c>
    # The path after 'unix:' must match the 'listen' directive in php-fpm's www.conf
    ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php-fpm/www.sock|fcgi://localhost:9000/var/www/html/
</IfModule>

# If using a TCP port instead of a socket (less common for local PHP-FPM, but typical for other app servers):
# ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/var/www/html/

# For a generic HTTP proxy to another service (e.g., Node.js, Tomcat):
# <Location /app/>
#     ProxyPass http://127.0.0.1:3000/
#     ProxyPassReverse http://127.0.0.1:3000/
# </Location>


# Also, check your backend application's configuration:
File: `/etc/php-fpm.d/www.conf` (or `php-fpm.conf`)
Line: `listen = /run/php-fpm/www.sock` (or `listen = 127.0.0.1:9000`)
Ensure this 'listen' directive exactly matches the socket path or IP/port in your Apache ProxyPassMatch configuration.

Verification

After applying any changes or restarts, verify the fix.

# 1. Check the status of both services again to ensure they are active and running
sudo systemctl status php-fpm
sudo systemctl status httpd

# 2. Test Apache configuration syntax if you made changes
# If using Amazon Linux/CentOS/RHEL:
sudo httpd -t
# If using Ubuntu/Debian:
# sudo apachectl configtest

# 3. Restart Apache if configuration was changed and tested successfully
sudo systemctl restart httpd

# 4. Test the application endpoint using curl from the EC2 instance
# Replace with the actual path to a PHP script or application endpoint
curl -I http://localhost/your_application_path/index.php

# Expected successful output should include an HTTP/1.1 200 OK or a 3xx redirect, not a 502 error.