PHP pools getting the same port resulting in service failing to start and bad gateway #28

New Issue

MrUnknownDE · 2026-04-05T20:25:18+02:00

MrUnknownDE commented

2026-04-05 20:25:18 +02:00

Originally created by @anatolinicolae on 10/29/2025

CloudPanel version(s) affected

2.5.2

Description

When switching PHP version, in some cases PHP pools end up using the same listen port failing the service start and ending up with a 502 Bad Gateway across sites on the same PHP version.

As an example, switching domain4.com from PHP 8.0 o PHP 8.3 will end up in this scenario with domain3.com and domain4.com getting the same port 18001:

root@web3:~# grep -r "listen = " /etc/php/ 
/etc/php/7.1/fpm/pool.d/default.conf:listen = 127.0.0.1:11000
/etc/php/7.2/fpm/pool.d/default.conf:listen = 127.0.0.1:12000
/etc/php/7.3/fpm/pool.d/default.conf:listen = 127.0.0.1:13000
/etc/php/7.4/fpm/pool.d/default.conf:listen = 127.0.0.1:14000
/etc/php/8.0/fpm/pool.d/default.conf:listen = 127.0.0.1:15000
/etc/php/8.1/fpm/pool.d/default.conf:listen = 127.0.0.1:16000
/etc/php/8.2/fpm/pool.d/default.conf:listen = 127.0.0.1:17000
/etc/php/8.3/fpm/pool.d/default.conf:listen = 127.0.0.1:18000
/etc/php/8.3/fpm/pool.d/domain3.com.conf:listen = 127.0.0.1:18001
/etc/php/8.3/fpm/pool.d/domain4.com.conf:listen = 127.0.0.1:18001
/etc/php/8.4/fpm/pool.d/default.conf:listen = 127.0.0.1:19000
/etc/php/8.4/fpm/pool.d/domain1.com.conf:listen = 127.0.0.1:19001
/etc/php/8.4/fpm/pool.d/domain2.com.conf:listen = 127.0.0.1:19002

root@web3:~# sqlite3 /home/clp/htdocs/app/data/db.sq3 "SELECT s.domain_name, ps.php_version, ps.pool_port FROM site s LEFT JOIN php_settings ps ON s.php_settings_id = ps.id WHERE s.php_settings_id IS NOT NULL;"
domain1.com|8.4|19001
domain2.com|8.4|19002
domain3.com|8.3|18001
domain4.com|8.3|18001

How to reproduce

I think I can consistently run into this case this way:

create a wordpress site
change to php 8.4
create a php site
change to php 8.4
create another wordpress site
change to php 8.4 and it breaks the pool

But not fully sure what's triggering the issue, as I ended up in the same situation in some other way too.

Possible Solution

No response

Additional Context

No response

*Originally created by @anatolinicolae on 10/29/2025* ### CloudPanel version(s) affected 2.5.2 ### Description When switching PHP version, in some cases PHP pools end up using the same listen port failing the service start and ending up with a `502 Bad Gateway` across sites on the same PHP version. As an example, switching domain4.com from PHP 8.0 o PHP 8.3 will end up in this scenario with domain3.com and domain4.com getting the same port `18001`: ``` root@web3:~# grep -r "listen = " /etc/php/ /etc/php/7.1/fpm/pool.d/default.conf:listen = 127.0.0.1:11000 /etc/php/7.2/fpm/pool.d/default.conf:listen = 127.0.0.1:12000 /etc/php/7.3/fpm/pool.d/default.conf:listen = 127.0.0.1:13000 /etc/php/7.4/fpm/pool.d/default.conf:listen = 127.0.0.1:14000 /etc/php/8.0/fpm/pool.d/default.conf:listen = 127.0.0.1:15000 /etc/php/8.1/fpm/pool.d/default.conf:listen = 127.0.0.1:16000 /etc/php/8.2/fpm/pool.d/default.conf:listen = 127.0.0.1:17000 /etc/php/8.3/fpm/pool.d/default.conf:listen = 127.0.0.1:18000 /etc/php/8.3/fpm/pool.d/domain3.com.conf:listen = 127.0.0.1:18001 /etc/php/8.3/fpm/pool.d/domain4.com.conf:listen = 127.0.0.1:18001 /etc/php/8.4/fpm/pool.d/default.conf:listen = 127.0.0.1:19000 /etc/php/8.4/fpm/pool.d/domain1.com.conf:listen = 127.0.0.1:19001 /etc/php/8.4/fpm/pool.d/domain2.com.conf:listen = 127.0.0.1:19002 ``` ``` root@web3:~# sqlite3 /home/clp/htdocs/app/data/db.sq3 "SELECT s.domain_name, ps.php_version, ps.pool_port FROM site s LEFT JOIN php_settings ps ON s.php_settings_id = ps.id WHERE s.php_settings_id IS NOT NULL;" domain1.com|8.4|19001 domain2.com|8.4|19002 domain3.com|8.3|18001 domain4.com|8.3|18001 ``` ### How to reproduce I think I can consistently run into this case this way: 1. create a wordpress site 2. change to php 8.4 3. create a php site 4. change to php 8.4 5. create another wordpress site 6. change to php 8.4 and it breaks the pool But not fully sure what's triggering the issue, as I ended up in the same situation in some other way too. ### Possible Solution _No response_ ### Additional Context _No response_

MrUnknownDE closed this issue

2026-04-05 20:25:18 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/cloudpanel-ce#28