在微服务与持续交付场景中，把应用打包成镜像后用容器启动已经成为标准做法。但不少人在本机执行docker run之后，发现关闭终端服务就中断，或者从浏览器访问宿主机IP根本连不上。这背后其实是容器的前台附着机制与网络命名空间隔离在起作用。要让一个容器既能在后台默默运行，又能把内部暴露的端口交给外部网络访问，需要理解Docker的进程托管方式与端口转发规则。
后台运行容器的核心参数与原理
默认情况下，执行docker run nginx会把容器的标准输出接到当前终端，容器进程作为前台任务存在。一旦终端关闭或按下Ctrl+C，Docker引擎会向容器主进程发送SIGTERM，随后服务停止。为了避免这种耦合，应当使用-d（detach）参数，让Docker将容器放入独立的前台守护循环，并返回一个长容器ID。此时容器主进程由Docker daemon直接托管，和用户的shell会话完全脱离。
需要注意的是，后台运行并不等于无需关注日志。因为看不到实时输出，开发者必须借助docker logs 容器名来排查启动错误。另外，若容器内部的主进程意外退出（比如配置文件写错导致Nginx崩溃），即使加了-d参数，容器也会进入Exited状态。因此生产环境通常配合--restart=unless-stopped来自动拉起异常退出的实例。
下面是一个典型的后台启动命令，我们同时给它起一个易读的名字，方便后续操作：
# 后台启动一个Redis容器并命名 docker run -d --name my-redis -p 6379:6379 redis:7-alpine # 查看运行状态 docker ps # 若崩溃可看日志 docker logs my-redis
端口映射的写法与常见错误
Docker的-p参数格式为宿主机IP:宿主机端口:容器端口，其中宿主机IP可以省略，默认绑定到0.0.0.0。很多初学者把顺序记反，写成-p 8080:80时以为是宿主机80转发给容器8080，其实正好相反：它表示宿主机的8080端口收到流量后，转发到容器的80端口。如果容器里跑的是监听80的Web服务，这种写法才正确。
还有一个容易踩的坑是只映射了容器端口却没写宿主机端口，例如-p 80，这会随机分配一个主机高位端口，导致你不知道从哪个端口访问。此外，当宿主机已有程序占用了你想映射的端口，Docker会直接报错退出，此时需要换端口或停止冲突进程。在云服务器上，还要确认安全组是否放行了对应端口，否则映射正确也连不上。
以下示例展示了多端口与指定绑定地址的用法，适用于需要限制外网访问的管理端口：
# 把宿主机127.0.0.1的3306映射到容器3306，仅本机可连 docker run -d --name mysql-local -p 127.0.0.1:3306:3306 mysql:8 # 同时映射Web端口和管理端口 docker run -d --name app -p 8080:80 -p 8443:443 my-app:latest
不同网络模式下的映射差异与排错
除了默认的bridge模式，Docker还提供host、none等网络模式。在host模式下，容器直接共享宿主机的网络栈，此时-p参数失效，容器内的服务端口就是宿主机的端口，好处是少一层NAT转发、性能更高，坏处是端口容易冲突且失去网络隔离。对于需要高性能且端口固定的场景可以用host，但后台服务更推荐bridge加明确映射。
当发现端口映射了却无法访问，排查顺序应该是：先docker ps确认容器状态为Up；再docker port 容器名看实际绑定情况；接着在宿主机用curl 127.0.0.1:映射端口测试回环；最后检查防火墙与安全组。如果是bridge网络，可以进入容器用docker exec -it 容器名 sh之后用netstat -tlnp确认进程是否真的在监听目标端口。
对于复杂项目，可以用docker-compose把后台运行和端口映射写成声明式配置，避免手动敲错参数。下面这段配置等价于前面多个docker run命令的组合：
version: '3'
services:
web:
image: my-app:latest
container_name: app
restart: unless-stopped
ports:
- "8080:80"
- "8443:443"
networks:
- bridge
networks:
bridge:
driver: bridge
通过理解容器生命周期与网络命名空间的关系，合理组合-d、-p以及重启策略，就能让服务在后台稳定运行为外部提供访问。遇到连接问题按网络栈逐层验证，基本都能快速定位。