Fix 502 Bad Gateway After Starting CSF on Nginx

If you run Nginx as a reverse proxy and recently enabled ConfigServer Security & Firewall (CSF), a 502 Bad Gateway usually means Nginx cannot reach your backend (like PHP-FPM or Apache). This guide walks you through the most common causes and fixes, from simple port checks to adjusting CSF’s firewall rules.

What You’ll Need

• Root or sudo access to your server
• SSH terminal (e.g., PuTTY, Terminal)
• Basic familiarity with command-line editing (nano or vi)
• Access to CSF’s configuration file (/etc/csf/csf.conf)

Step-by-Step

1. Confirm the 502 is Nginx-related. Open a browser and visit your site. If you see a generic “502 Bad Gateway” page, Nginx is running but cannot reach the upstream. Check Nginx’s error log: tail -f /var/log/nginx/error.log – look for lines like “connect() failed (111: Connection refused)”.
2. Check if your backend is listening. Run netstat -tulpn | grep :80 (or the port your backend uses, e.g., 8080, 9000). If nothing appears, your backend (PHP-FPM, Apache, Node.js) is not running. Start it: systemctl start php-fpm or systemctl start httpd (exact service name depends on your OS).
3. Verify the backend port is allowed in CSF. CSF by default blocks all ports except those listed in TCP_IN and TCP_OUT. If your backend listens on a non-standard port (e.g., 8080), it is blocked. Edit /etc/csf/csf.conf, find TCP_IN, and add the port (e.g., 8080). Save the file.
4. Restart CSF to apply changes. Run csf -r (or csf -ra to also reload iptables). This flushes and re-applies the firewall rules. Then test your site again.
5. Check if CSF is blocking the loopback interface. Sometimes CSF’s LOOPBACK setting is set to 0, which can block local traffic. In csf.conf, ensure LOOPBACK is 1. If not, set it to 1 and restart CSF.
6. Inspect Nginx’s upstream configuration. If your backend is on a Unix socket (like unix:/var/run/php-fpm/www.sock), ensure the socket file exists and has correct permissions. Run ls -la /var/run/php-fpm/ – if the socket is missing, restart PHP-FPM. Also check that the Nginx user (often www-data) has read/write access to the socket.
7. Test the backend directly. From the command line, run curl -I http://127.0.0.1:8080 (replace with your backend’s IP/port). If you get a response, the backend is fine. If not, the issue is with the backend itself, not the firewall.
8. Check for IP-based restrictions in CSF. CSF can block specific IPs or countries. Run csf -g to see if your IP is blocked. If so, remove it with csf -a (allow) or csf -dr (deny remove).
9. Review Nginx’s proxy_pass directive. Ensure the proxy_pass URL matches the backend’s actual address. For example, if your backend is on port 8080, the directive should be proxy_pass http://127.0.0.1:8080;. A mismatch will cause 502s.
10. Restart Nginx after any config changes. Run nginx -t to test the config, then systemctl restart nginx.

Common Mistakes

• Forgetting to restart CSF after editing csf.conf. Changes only take effect after csf -r.
• Blocking the loopback interface. Setting LOOPBACK to 0 can break internal communication between Nginx and its backend.
• Using the wrong port. If your backend listens on 127.0.0.1:9000, but you open port 9000 in CSF’s TCP_IN, that’s fine, but if you open 9000 and your backend is on 8080, it won’t help.
• Editing the wrong configuration file. Some systems use csf.conf in /etc/csf/, but others may have it elsewhere. Always verify the path.

Tips

• Before making changes, back up your configuration: cp /etc/csf/csf.conf /etc/csf/csf.conf.bak.
• Use csf -v to see the current firewall rules in a human-readable format.
• If you are using a control panel like cPanel or DirectAdmin, they may have their own firewall integration. Check their documentation for CSF-specific settings.
• Consider adding your backend port to both TCP_IN and TCP_OUT if the backend makes outbound connections (e.g., to a database).
• Monitor Nginx’s error log in real time: tail -f /var/log/nginx/error.log while testing changes.

Troubleshooting

If the steps above do not resolve the issue, try the following:

• Check if SELinux or AppArmor is interfering. On CentOS/RHEL, SELinux can block Nginx from connecting to sockets. Temporarily set SELinux to permissive (setenforce 0) and test. If that fixes it, adjust the SELinux policy. On Ubuntu/Debian, check AppArmor status with aa-status.
• Look for other firewall rules. CSF may not be the only firewall. Check iptables directly: iptables -L -n. If you see a DROP rule for your backend port, you may need to add an allow rule manually.
• Test with CSF temporarily disabled. Run csf -x to disable the firewall (not recommended for production, but for testing). If the site works, the issue is definitely CSF. Re-enable with csf -e.
• Check for IP conflicts. If your backend is on a different server, ensure that server’s firewall allows connections from your Nginx server’s IP. Also check that the backend’s IP is reachable from the Nginx server (ping it).
• Review Nginx’s error log for more details. Sometimes the log shows “upstream prematurely closed connection” which indicates a backend crash, not a firewall issue. In that case, focus on the backend’s own logs (e.g., PHP-FPM’s log).

Frequently Asked Questions

Why did CSF start blocking my backend after I enabled it?

CSF’s default policy is to deny all incoming connections except those explicitly allowed. If your backend port was not listed in TCP_IN, it gets blocked.

How do I open a port in CSF?

Edit /etc/csf/csf.conf, find TCP_IN (for incoming) and TCP_OUT (for outgoing), add the port number separated by commas, then run csf -r.

What is the loopback interface and why does it matter?

The loopback interface (127.0.0.1) is used for local communication between processes on the same server. If CSF blocks it, Nginx cannot reach PHP-FPM or other local services.

Can I allow all traffic from a specific IP in CSF?

Yes, use csf -a IP_ADDRESS to add the IP to the allow list. This bypasses all firewall rules for that IP.

What if my backend is on a Unix socket instead of a TCP port?

CSF does not block Unix sockets, so the issue is likely file permissions or the socket not being created. Check that the socket file exists and is writable by the Nginx user.

How do I know which port my backend uses?

Look at your Nginx configuration file (e.g., /etc/nginx/sites-available/default). The proxy_pass directive will show the address and port, or the socket path.

Related

• FiveM Server Hosting for GTA V Enhanced: Key Facts
• Fix Apache AH00558: Could Not Determine Server’s Domain Name
• Google TV Default Launcher vs Lightweight Launcher: What Changes?