端口映射不通主因是配置、环境或理解偏差，需按五步排查：确认容器内服务监听0.0.0.0、验证docker ps端口显示、检查docker port输出、本地curl测试、查iptables dnat规则，并同步处理宿主机防火墙、安全组及网络模式适配。
端口映射不通，八成不是 docker 坏了，而是配置、环境或理解上卡在某个关键环节。它表面是“-p 8080:80”一条命令，背后却牵扯网络命名空间隔离、iptables 规则注入、宿主机防火墙、应用监听地址、甚至 docker 守护进程配置。下面从最常出问题的场景切入，讲清排查路径和真正落地的安全做法。
一、服务跑着但 localhost 访问不了？先过这五关
这是新手最常遇到的“明明映射了却打不开”问题，按顺序快速验证：
-
确认容器内服务真在监听目标端口：进容器执行
netstat -tuln | grep :80（替换成你的容器端口），看是否绑定在0.0.0.0:80或:::80。若只绑定了127.0.0.1:80，外部流量根本进不来； -
检查 docker ps 输出的 PORTS 列是否含预期映射：比如看到
0.0.0.0:8080->80/tcp才算成功；若为空或显示80/tcp（没箭头），说明 -p 没生效或写错位置； -
用 docker port 命令查实映射结果：运行
docker port 80，应返回类似0.0.0.0:8080。如果报错或无输出，映射根本未建立； -
宿主机本地 curl 测试绕过浏览器：执行
curl -v http://localhost:8080。失败时看是 connection refused（端口没通）、timeout（防火墙或网络策略拦截），还是返回内容（服务已通）； -
查 iptables 是否有对应 DNAT 规则：运行
sudo iptables -t nat -L DOCKER -n -v，应能看到类似tcp dpt:8080 to:172.17.0.3:80的转发条目。没有？Docker 可能没权限操作 iptables，或 daemon.json 中禁用了 iptables。
二、防火墙与系统级拦截，别让它们悄悄挡路
Docker 自动加 iptables 规则，但宿主机防火墙（ufw/firewalld）默认不认这些规则，仍会拦截入站请求：
-
Ubuntu/Debian（ufw）：运行
sudo ufw status verbose，确认状态为 active，并执行sudo ufw allow 8080（或开放整个范围如8000:9000/tcp）； -
CentOS/RHEL（firewalld）：执行
sudo firewall-cmd --list-ports查看已开放端口，再用sudo firewall-cmd --add-port=8080/tcp --permanent && sudo firewall-cmd --reload持久化添加； - 云服务器额外注意安全组：阿里云、腾讯云等控制台中，必须手动放行对应端口的入方向 TCP 流量，光配 Docker 没用；
- Windows/macOS Docker Desktop 用户：一般无需手动开防火墙，但需确认 Docker Desktop 设置中 “Use the WSL 2 based engine” 已启用（Windows），且 macOS 上没启用“Stealth Mode”防火墙。
三、安全规范：不只防攻击，更防误配与暴露
生产环境不能只求“能通”，还要控范围、减攻击面、保可维护性：
-
禁止绑定 0.0.0.0（除非必需）：用
-p 127.0.0.1:8080:80仅允许本机访问，适合调试或反向代理前置场景； - 避免使用 -P（大写 P）自动映射：它依赖 EXPOSE，且端口随机分配，不可预测、难审计、易冲突，CI/CD 和监控全乱套；
-
明确指定协议，不省略 /tcp 或 /udp：比如
-p 53:53/udp和-p 53:53/tcp是两回事，混用会导致 DNS 查询失败； - 敏感服务禁用公网直连：数据库（MySQL/PostgreSQL）、Redis、Elasticsearch 等一律不映射到宿主机公网端口，改用 Docker 自定义网络 + link 或 compose 内部通信；
-
端口复用需谨慎：多个容器不能共用同一宿主机端口；若需多实例，用不同端口（
-p 8081:80,-p 8082:80）或上 Nginx 负载均衡。
四、特殊网络模式下的映射失效原因
bridge 是默认模式，但一旦切换，端口映射逻辑就变了：
- host 模式（--network host）：容器直接共享宿主机网络栈，-p 参数完全失效，容器内服务必须监听宿主机真实 IP 或 0.0.0.0；
- none 模式（--network none）：无网络栈，-p 不起作用，需手动配置网络才能通信；
-
自定义 bridge 或 overlay 网络：-p 依然有效，但容器间通信应优先走内部 DNS 名称（如
web访问db），而非依赖宿主机端口转发； - macvlan/ipvlan 模式：容器获得独立 IP，可直接被局域网访问，-p 映射通常不需要，甚至可能干扰原有路由。
