Nginx downloading PHP files in aaPanel? Fixing “Address already in use” and orphan sockets

If your browser starts downloading index.php instead of rendering the page, the issue is usually a broken integration between Nginx and PHP-FPM.

This guide covers root causes and a recovery sequence for Address already in use, orphan processes, and mixed-content side effects.

1. Symptom: PHP gets downloaded instead of executed

This happens when Nginx cannot forward PHP requests to PHP-FPM. Typical causes:

PHP-FPM is down;
socket is missing or has wrong permissions;
location ~ \.php block is not loaded correctly.

2. Critical error: `Address already in use`

You may see this even after restart:

[emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

This usually means orphaned Nginx workers still hold ports 80/443.

Forced cleanup

killall -9 nginx
netstat -tulpn | grep -E ':80|:443'
systemctl start nginx

3. PHP-FPM shows `active (exited)` in aaPanel

This status often means systemd lost track of the real worker PID.

If socket path (e.g. /tmp/php-cgi-80.sock) is missing or inaccessible, Nginx cannot execute PHP and may return the file as download.

Recommended fixes

chown -R www:www /home/usuario/public_html
/etc/init.d/php-fpm-80 reload

If immutable file blocks ownership changes:

chattr -i .user.ini

4. Modal/AJAX breakage: Mixed Content (HTTPS vs HTTP)

If direct access works but modal/AJAX requests fail, mixed content is likely.

http:// requests from an HTTPS page can be blocked and trigger odd fallback behavior, including file download responses.

Fixes

Enforce HTTPS with 301 redirect.
Use relative JS URLs (/script.php) instead of hardcoded http://.
Add CSP upgrade header.

add_header Content-Security-Policy "upgrade-insecure-requests";

5. Recovery command sequence

# Clean orphan nginx workers and start clean service
killall -9 nginx && systemctl start nginx

# Restart active php-fpm pool
pkill -9 php-fpm && systemctl restart php-fpm-80

# Validate socket and ownership
ls -la /tmp/php-cgi-80.sock

In most incidents, root cause is a combination of:

orphaned processes;
broken PHP-FPM socket state;
wrong filesystem ownership/permissions;
HTTP calls inside HTTPS flows.

After process cleanup, permission alignment, and HTTPS standardization, Nginx and PHP-FPM return to normal behavior.

This post is licensed under CC BY-NC.