ALB 502 Bad Gateway on Plesk: A Real-World Incident Investigation Guide

Introduction

Application Load Balancer errors are confusing because a simple 502 Bad Gateway can originate from AWS ALB, Security Groups, Network ACLs, Plesk, Nginx, Apache, PHP-FPM, WordPress, Fail2Ban, iptables or ModSecurity.

This guide explains a practical investigation flow for identifying where the failure actually happens, without exposing any client name, domain, IP address or production infrastructure details.

Environment

High-Level Architecture

Internet
  ↓
AWS Application Load Balancer
  ↓
EC2 Ubuntu Server with Plesk
  ↓
Nginx
  ↓
Apache
  ↓
PHP-FPM
  ↓
WordPress

The Problem

Users started seeing a public website error:

502 Bad Gateway

However, the Plesk panel was still accessible through an SSH tunnel:

https://localhost:8443

This immediately raised an important question: was the issue really with Plesk, or somewhere between AWS ALB and the server?

Step 1: Verify Core Services

First, check whether Nginx, Apache and PHP-FPM are running.

sudo systemctl status nginx
sudo systemctl status apache2
sudo systemctl list-units --type=service | grep fpm

In Plesk environments, PHP-FPM may appear as a Plesk-specific service, for example:

plesk-php84-fpm.service

Restart the web stack if needed:

sudo systemctl restart plesk-php84-fpm
sudo systemctl restart apache2
sudo systemctl restart nginx

Step 2: Repair Plesk Web Configuration

If Plesk updates were stuck or web configuration appears inconsistent, run:

sudo plesk repair web -y

This checks and repairs Apache configuration, Nginx configuration, SSL assignments, PHP handlers and domain-level web configuration.

Step 3: Check Server Logs

Check domain-level logs:

sudo tail -100 /var/www/vhosts/system/example.com/logs/error_log
sudo tail -100 /var/www/vhosts/system/example.com/logs/proxy_error_log

Also check the global Nginx error log:

sudo tail -100 /var/log/nginx/error.log

Step 4: Test the Public Website

Run a header test against the public website:

curl -Ik https://www.example.com

If the output shows:

HTTP/2 502
server: awselb/2.0

Then the error is generated by AWS ALB, not directly by Plesk or WordPress.

Step 5: Bypass the Load Balancer

Test the backend server directly using the private IP and Host header.

curl -Ik http://PRIVATE-IP -H "Host: www.example.com"

curl -Ik https://PRIVATE-IP -H "Host: www.example.com" --insecure

If the backend responds with 200 OK, it proves that Nginx, Apache, PHP-FPM and WordPress are working behind the load balancer.

HTTP/2 200
server: nginx
x-powered-by: PHP
x-powered-by: PleskLin

Step 6: Check Whether ALB Requests Reach Plesk

Watch the domain access logs while refreshing the public website.

sudo tail -f /var/www/vhosts/system/example.com/logs/proxy_access_ssl_log

If the public website still shows 502 but no new log entry appears, it means the request is not reaching Plesk. The issue is likely at ALB, Target Group, Security Group, ENI, NACL or firewall level.

Step 7: Create a Static Health Check File

Do not use the WordPress homepage as the ALB health check. It may redirect, load plugins, hit the database or trigger security rules.

echo "ok" | sudo tee /var/www/vhosts/example.com/example.com/health.html

Test it:

curl -I http://PRIVATE-IP/health.html -H "Host: www.example.com"

curl -I https://PRIVATE-IP/health.html -H "Host: www.example.com" --insecure

Expected result:

HTTP/1.1 200 OK

Recommended ALB Health Check

Use a static health file instead of WordPress homepage.

Protocol: HTTP
Port: 80
Path: /health.html
Success Codes: 200

Step 8: AWS Target Group Investigation

In AWS, check:

Step 9: Understand 502 vs 503

Step 10: Check Fail2Ban and iptables

If the target becomes healthy and then unhealthy again after a few minutes, investigate dynamic blocking tools such as Fail2Ban and iptables.

sudo systemctl status fail2ban
sudo fail2ban-client status
sudo iptables -L -n --line-numbers
sudo iptables -L -n | grep DROP

Fail2Ban is not part of WordPress. It is a Linux/Plesk security service that monitors logs and creates firewall rules through iptables.

Internet
  ↓
AWS ALB
  ↓
Ubuntu Server
  ↓
Fail2Ban / iptables
  ↓
Nginx
  ↓
Apache
  ↓
PHP-FPM
  ↓
WordPress

Step 11: Why Increased Traffic Can Trigger the Issue

Increased traffic alone does not normally break ALB. However, it can increase bot traffic, crawler activity, failed login attempts and security events.

More Traffic
  ↓
More Bots / Crawlers / Failed Login Attempts
  ↓
Fail2Ban or ModSecurity reacts
  ↓
iptables DROP rules may be added
  ↓
ALB health checks fail
  ↓
Target becomes unhealthy
  ↓
502 or 503 appears

Root Cause Analysis Framework

Important AWS Checks

• Target health reason: Check whether it says timeout, response code mismatch or failed health checks.
• Target port: Confirm whether target is registered on port 80 or 443.
• Protocol mismatch: Do not send HTTP traffic to HTTPS port or HTTPS traffic to HTTP port.
• Security Group: EC2 must allow inbound traffic from the ALB Security Group.
• ENI: Confirm the correct network interface and private IP are attached to the instance.

Recommended Stable Architecture

For most WordPress/Plesk websites behind ALB, the safest setup is:

Client HTTPS 443
  ↓
AWS ALB HTTPS Listener with ACM Certificate
  ↓
Target Group HTTP 80
  ↓
Plesk Nginx/Apache
  ↓
WordPress

This avoids backend TLS handshake issues between ALB and Plesk.

Final Checklist

Conclusion

A 502 Bad Gateway does not always mean WordPress or Plesk is down. In this investigation, the backend was proven healthy through direct private IP testing, while public traffic failed at the AWS ALB layer.

The correct troubleshooting approach is to isolate every layer: public domain, ALB, target group, security groups, ENI, firewall rules, Nginx, Apache, PHP-FPM and WordPress.

The biggest lesson: always create a static health check endpoint and monitor Fail2Ban/iptables when using Plesk behind AWS ALB.