Choosing the next port for a service means telling host ports from internal ports. A host binding skews the calculation of the next available one.
You want to add a service and assign it a free port. Without an audit, you hit a conflict at startup, or worse, an already-exposed port you thought was closed.
Host port and internal port are not the same
A container listens on an internal port, inside its own network namespace. That port collides with nothing as long as it is not published to the host. Several containers can listen on the same internal port without interfering.
The host port is different: it is the one the container reserves on the machine interface. Two services cannot claim the same host port on the same interface. That is where conflicts are born.
Why a host binding skews the calculation
To find the next free service port, you look at the host ports already bound, not the internal ports. A service exposed directly on the host occupies a host port that will not show up if you only inspect the containers' internal ports.
So you audit on the host side: what actually listens on the machine interfaces. It is the union of container bindings and native services. The next free port is chosen in that space, not in the internal-port space.
The principle: the conflict lives on the host. Count the occupied host ports to find the next one, without confusing external exposure with internal listening.