Docker 报端口被占用，改了 Compose 还不行？

端口从 8080 改到 8081，Compose 仍报 port is already allocated，先看最终配置。多个文件合并时，8081 可能只是新增条目，原来的 8080 还在列表里。

用启动时相同的文件和项目名检查

假设项目使用下面的命令组合，检查也要保持相同参数：

docker compose -p app-test -f compose.yaml -f compose.test.yaml config
docker compose -p app-test -f compose.yaml -f compose.test.yaml ps -a

在 config 输出里找报错服务的 ports。同时检查启动脚本的 COMPOSE_FILE 和额外 -f 参数，避免看的是另一份配置。输出会展开变量，可能含密码或连接串，分享前脱敏。

例如基础文件发布 8080:80，测试文件增加 8081:80，普通合并会保留这两个不同条目。左侧是宿主机端口，右侧是容器内部端口；多个容器各用内部 80 并不冲突，同时发布同一宿主机地址与端口才需要处理。

再查其他项目和宿主机进程

docker ps --format 'table {{.Names}}\t{{.Ports}}'
sudo ss -ltnp 'sport = :8080'

这两条用于 Linux，端口换成报错值。先用 Docker 列表找其他项目的发布，再看宿主机监听程序。没有普通监听进程也不能排除 Docker 的端口占用，因为发布还可能通过转发规则实现。UDP 冲突需要按 UDP 检查，不能只看 TCP 的 ss -ltnp。

确认占用者的用途后再修改。不要直接终止未知进程，也不要用删除数据卷处理端口问题；它不会解决映射冲突，却会让应用数据丢失。

两种办法避免继承旧端口

一台 VPS 同时跑开发和测试项目时，可以把基础文件中的 ports 移到各环境文件，让每次启动只合并对应环境的入口。这种方式较容易看清哪个文件负责发布端口。

用 Compose 5.3.1、Docker Engine 29.6.2，在 Docker Desktop 的 ARM64 隔离环境中核对过下面这组映射：基础文件发布 127.0.0.1:18345:8080，第二份文件写 127.0.0.1:18346:8080；容器内是监听 8080、返回固定文字的测试 HTTP 服务。两次可访问对照使用自建桥接入口，只访问本机回环地址。

这组结果只证明该固定版本下的合并模型、Docker 实际映射与本机访问。配置里列出端口不等于入口已可访问；换成 Linux VPS，还要按实际网络、宿主机防火墙和云端规则检查。确认旧入口取消时，也要访问旧地址，不能只看新地址能打开。

Compose 2.24.4 或更新版本还可用 !override 整体替换属性。先执行 docker compose version，再决定是否使用下面的覆盖片段：

services:
  web:
    ports: !override
      - "127.0.0.1:8081:80"

旧版本无法解析时，采用拆分环境文件的方法。回环绑定适合宿主机代理访问；代理本身在另一容器时，应使用共同 Docker 网络中的服务名，见 Nginx 容器 502 排查。

重建后，检查映射并访问应用

保存原配置，在合适窗口重建相关服务。重新查看同参数的 config 与 ps，从预期端口访问一次应用，确认配置、实际映射和访问地址一致。

端口冲突本身不说明 VPS 配置太小。一台机器运行多个网站，可以先按多站点部署的入口安排分配代理和端口；只有内存、磁盘或故障隔离确实不够时，再比较Docker 应用服务器，避免为一个配置错误多买一台机器。

多站点新增机器应按哪些应用要分开、合计内存和公网连接需求来选。统一面板管理可查看 雨云 RCS 的 Docker 与公网配置；准备独立测试环境可比较 Evoxt 的 Linux 实例。新机也必须检查最终 Compose 映射与实际端口占用，换一个 IP，旧端口也不会从合并配置里消失。