容器内应用启动成功，并不代表宿主机或外部用户一定能访问到它。Docker bridge 模式下，容器拥有自己的网络命名空间，应用监听的端口默认只在容器网络内可见。要从宿主机或外部网络访问容器，需要通过端口映射把宿主机入口转发到容器端口。理解这一点，是排查“容器明明运行了，浏览器却打不开”的基础。
如果你正在梳理 Docker 基础能力，可结合Docker与容器基础和容器网络建立完整知识框架。
端口映射的基本语法
最常见的写法是 -p 宿主机端口:容器端口。例如 Nginx 容器内部监听 80，希望通过宿主机 8080 访问：
docker run -d --name web -p 8080:80 nginx
curl http://127.0.0.1:8080这里的 80 是容器内应用端口，8080 是宿主机对外入口。访问宿主机 8080 时，Docker 会把流量转发给容器 80。初学者常见错误是把两者写反，或者以为 Dockerfile 中的 EXPOSE 80 会自动对外发布端口。实际上 EXPOSE 更像镜像元数据，提醒使用者应用可能监听哪些端口，不等同于 -p。
绑定地址：只给本机访问还是对外开放
-p 8080:80 通常会绑定到宿主机所有地址，局域网其他机器在网络和防火墙允许时也可能访问。若服务只用于本机调试，应显式绑定 127.0.0.1：
docker run -d --name admin-ui -p 127.0.0.1:8080:80 my-admin-ui:latest这样可以降低误暴露管理后台、调试接口和未加固服务的风险。对生产环境而言，不建议把数据库、缓存、内部管理端口直接发布到公网网卡，更合理的方式是使用反向代理、访问控制、专用网络或编排平台的服务暴露机制。
随机端口和多端口服务
当宿主机端口不固定时，可以只写容器端口，让 Docker 自动选择可用宿主机端口：
docker run -d --name test-web -p 80 nginx
docker port test-web这种方式适合自动化测试和临时环境，但不适合需要固定入口的服务。多端口应用则可以多次使用 -p，例如同时暴露 HTTP 和 gRPC：
docker run -d --name api
-p 8080:8080
-p 9090:9090
my-api:latest建议团队在配置中明确每个端口的用途，避免出现“端口能通但不知道对应哪个协议”的维护问题。
Compose 中 ports 与 expose 的区别
Docker Compose 常用于本地多服务编排。ports 表示发布到宿主机，expose 表示声明容器间可用端口但不发布给宿主机。示例：
services:
web:
image: nginx
ports:
- "8080:80"
api:
image: my-api:latest
expose:
- "8080"
redis:
image: redis:7在这个配置中，web 可以通过宿主机 8080 访问；api 的 8080 主要供同一 Compose 网络中的其他服务访问；redis 没有发布端口，但同网络服务仍可通过服务名 redis 访问。对开发环境来说，这种区分能减少不必要的端口暴露，也让网络边界更清楚。
端口映射失败的高频原因
| 问题现象 | 常见原因 | 处理建议 |
|---|---|---|
| — | — | — |
| 浏览器打不开 | 访问了容器端口而非宿主机端口 | 使用 docker ps 查看 PORTS |
| 端口绑定失败 | 宿主机端口已被占用 | 换端口或停止占用进程 |
| 本机能访问，外部不能访问 | 绑定 127.0.0.1 或防火墙阻断 | 检查绑定地址与安全组 |
| 端口通但业务失败 | 应用依赖、路径或协议不对 | 查看应用日志与健康检查 |
| 容器内监听 127.0.0.1 | 只监听容器本地回环 | 改为监听 0.0.0.0 |
排障步骤：先确认监听，再确认映射
推荐按以下顺序检查，不要一上来就重启 Docker：查看容器是否运行；查看端口映射是否存在；进入容器检查应用监听；在宿主机本地访问映射端口；从外部机器访问宿主机地址，检查防火墙、安全组和绑定地址。
docker ps --format "table {{.Names}}t{{.Ports}}"
docker exec web ss -lntp
curl -v http://127.0.0.1:8080如果容器内应用只监听 127.0.0.1:8080，即使做了端口映射，Docker 转发到容器网络地址时也可能访问失败。多数 Web 服务在容器内应监听 0.0.0.0，让容器网络接口可以接收流量。
从 Docker 过渡到 Kubernetes 的理解方式
Docker 端口映射解决的是单机容器如何被宿主机访问的问题；Kubernetes 中则通常通过 Service、Ingress、Gateway 或负载均衡器暴露服务。两者概念不同，但底层思路类似：都需要明确入口地址、目标端口、后端实例和访问控制。后续学习可延伸到Kubernetes实践与Kubernetes容器专题。
小结：端口映射不是随手加 -p
配置 Docker 端口映射时，最重要的是分清宿主机端口、容器端口和应用监听地址。开发环境可以为了方便发布端口，但团队协作和生产环境应限制绑定地址、记录端口用途、避免暴露内部依赖，并建立标准检查路径。这样既能让容器服务被稳定访问，也能降低网络暴露带来的安全与运维风险。
常见问题
Docker 端口映射中的宿主机端口和容器端口怎么区分？
宿主机端口是外部访问时连接的端口，容器端口是应用在容器内部监听的端口。例如 8080:80 表示访问宿主机 8080 会转发到容器 80。排障时要分别确认应用监听端口、Docker 映射关系和客户端访问地址。
为什么不建议把所有容器端口都暴露出去？
端口暴露会增加攻击面，也会让内部依赖关系变得混乱。只有确实需要被外部访问的服务才应发布端口，数据库、缓存、内部 API 等服务更适合放在内部网络中通过服务名访问，并配合防火墙或安全组限制访问来源。
端口映射和 Kubernetes Service 是一回事吗？
不是。Docker 端口映射主要解决单机容器到宿主机端口的转发问题，Kubernetes Service 解决的是集群内多 Pod 的稳定访问、服务发现和负载均衡问题。两者都和访问入口有关，但抽象层级和适用范围不同。
转载请注明出处：https://www.cloudnative-tech.com/p/7339/
