Docker Compose端口映射排查：用port和inspect定位网页访问失败

docker compose ps里容器显示Up，浏览器却连接失败，排查时需要分别回答三个问题：当前容器把端口发布到哪里，客户端实际请求了哪里，应用是否在目标端口提供HTTP服务。只看运行状态，还无法回答这三个问题。

本文给一份可逐项执行的最小示例与读数方法。内容依据Docker官方文档整理，未在本文环境启动容器、拉取镜像或验证HTTP响应；文中的输出结构均标为示意。

一、固定环境和Compose项目

示例限定Linux Docker Engine 28及以上、支持Compose规范的插件、普通bridge网络。先SSH登录目标Docker宿主机；下面的Compose命令与本机HTTP请求都在该宿主机执行，Docker客户端应连接这台主机的Engine。

在新建的独立空目录保存compose.yaml，确认宿主机8080没有被占用。演示项目固定使用port-lab-1019，服务名为web。已有业务项目应沿用原项目名、目录与文件参数，勿将演示命令直接套入现有应用。

yaml 复制代码

services:
  web:
    image: docker.1ms.run/library/nginx:1.30.6-alpine
    ports:
      - "127.0.0.1:8080:80"

bash 复制代码

docker compose -p port-lab-1019 -f compose.yaml config --quiet
docker compose -p port-lab-1019 -f compose.yaml pull
docker compose -p port-lab-1019 -f compose.yaml up -d

这里使用毫秒镜像的Docker Hub入口，完整保留library/nginx仓库路径和已核对的固定标签。镜像获取完成后，端口映射与应用响应仍需分别检查；上游列有标签，不等于本次代理拉取已通过。

二、读取当前容器的发布映射

先看状态与端口，再查询服务web的容器端口80：

bash 复制代码

docker compose -p port-lab-1019 -f compose.yaml ps --all
docker compose -p port-lab-1019 -f compose.yaml port web 80

--all有助于发现已经退出的容器；若服务正在重启或已停止，先结合日志处理运行状态。对于正在运行的示例服务，预期发布地址是宿主机回环的8080，最终以实际命令结果为准。

实际端口栏的形式	应如何理解
`127.0.0.1:8080->80/tcp`	宿主机回环8080转发到容器80；先在宿主机本机访问
`0.0.0.0:8080->80/tcp`	映射绑定宿主机各IPv4地址，仍需核对访问地址与网络策略
仅`80/tcp`	未显示宿主机发布映射，检查是否只有镜像EXPOSE或Compose expose

表中是格式说明 。不要把箭头左侧的宿主机8080，与右侧的容器80交换使用。ports配置负责发布；EXPOSE和expose本身不会替你创建同样的宿主机入口。

需要保存更明确的证据时，用当前项目的容器ID读取映射：

bash 复制代码

lab_cid="$(docker compose -p port-lab-1019 -f compose.yaml ps -q web)"
if [ -n "$lab_cid" ]; then
  docker inspect "$lab_cid" --format '{{json .NetworkSettings.Ports}}'
fi

服务只有一个实例时，lab_cid应为一个容器ID；若为空，回到ps --all查状态。若业务服务有多个副本，应逐个检查容器，不能直接照搬这个单实例变量。

JSON里的80/tcp是容器端口；数组中的HostIp、HostPort是宿主机绑定。下列仅表示字段结构：

json 复制代码

{"80/tcp":[{"HostIp":"127.0.0.1","HostPort":"8080"}]}

三、把源配置与实际映射分开核对

如果配置里写8080，实际却仍是旧端口，继续反复打开浏览器不会改变当前容器。

bash 复制代码

docker compose -p port-lab-1019 -f compose.yaml config

这一步读取准备应用的模型：Compose会解析所选文件、变量和短格式。已有项目使用多份-f文件时，检查和启动必须沿用同样的文件及顺序。完整渲染结果可能包含敏感环境值，排查时仅摘录所需端口字段并脱敏。

源文件、渲染模型、运行中的容器是三个检查对象。发现差异后，先确认项目与服务，再决定是否在维护窗口应用变更；重建可能中断连接。docker compose restart只重启现有服务，不会应用修改后的端口发布配置。

四、在正确的位置请求HTTP

对于本例的回环绑定，在Docker宿主机执行：

bash 复制代码

curl --max-time 5 -i http://127.0.0.1:8080/
docker compose -p port-lab-1019 -f compose.yaml logs --tail=50 web

根据实际响应继续分支：

现象	后续检查
宿主机已返回预期页面，自己电脑失败	核对浏览器位置与绑定范围；远程维护可使用SSH本地转发
请求被拒绝或连接超时	结合发布映射、应用监听、目标地址与网络规则定位，单个错误无法确定根因
收到401、404或500	已有HTTP响应，继续确认是否来自目标服务，并检查认证、路径或应用日志
容器反复重启或已退出	先处理服务日志、启动配置与依赖，再复查端口

自己电脑的127.0.0.1指向自己电脑；服务器里的同一地址指向服务器。选择回环绑定的管理服务，可以从自己电脑通过SSH转发访问，无须为这项维护任务改变宿主机发布范围。

若端口映射吻合、宿主机请求仍不成功，自行开发的应用还应核对容器内的监听地址。普通bridge容器里只监听127.0.0.1的应用，通常无法接收转入容器网络接口的请求；按应用文档配置所需监听接口。容器内监听地址和宿主机发布地址各管一层，须分别记录。

排查结束时保存同一时点的项目参数、port或inspect读数、请求位置和HTTP结果。下次遇到同类问题，就能先比较这份证据，再决定修改哪一处。