搞了十多年基础设施见过太多人光是装个环境就被劝退本地开发好好的一到新机器就缺依赖、版本冲突、配置漂移折腾一晚上连个nginx欢迎页都看不到。今天想聊的这个组合Docker加上nginx反向代理算是我最常推荐给新手的入门实战。它够小、够直观、覆盖的知识点又刚好是日常运维和开发的高频场景。这篇文章不讲虚的从装环境开始一路到用nginx挂上反向代理、挂载多项目目录、用Compose编排全部带实操命令和配置照着抄完你就不是只会docker ps的人了。这篇文章适合谁刚接触容器、想搞明白Docker到底怎么用的人或者被服务器环境折磨过的后端和前端。准备好了就往下走我尽量把每个步骤背后的为什么也讲清楚这样你遇到问题能自己推断原因而不是到处找人问。1. 为什么非要用Docker跑nginx反向代理1.1 反向代理到底是什么东西先说反向代理。你可以把它理解成公司前台所有找人的电话先打到前台前台根据你要找谁再把电话转接到对应工位。外面的人根本不知道你要找的人坐在哪个工位、工位号码是多少只认准前台这一条线就行。放在技术场景里前台就是nginx工位就是后端服务。客户端访问nginxnginx根据请求路径、域名或者端口规则把请求转发给后端的某个服务再把响应原路拿回来。这么做的好处很实际隐藏后端服务外部只暴露80/443端口减少攻击面。多个服务共用一个入口按路径分流比如/api走后端A/web走后端B。天然支持负载均衡nginx把请求分摊到多个后端实例。统一处理HTTPS证书、日志、限流后端不用各搞一套。明白了这个再来看nginx的配置文件就不会晕。所有server块本质上是给前台定接线规则location则是精确到分机号的转发策略。1.2 Docker解决了什么烦心事传统装nginx的方式在Ubuntu上是apt install nginx在CentOS上是yum install nginx听起来简单实际会遇到系统源版本老、依赖冲突、配置文件散落各处、卸载不干净这些事。更麻烦的是你想跑一个nginx负载均衡可能需要在同一台机器上装多个版本做测试手动操作起来非常痛苦。Docker的思路是换赛道把nginx和它的依赖、配置全部封装进一个叫镜像的包里用docker run一条命令启动一个容器来运行它。容器和你本机环境天然隔离不会污染宿主机换版本只是换个镜像标签的事回滚也就一行命令。我自己的体感是用Docker跑nginx从下载到能访问欢迎页不夸张地说五分钟以内搞定。而且nginx的官方镜像很小就一百多兆属于Docker生态里最适合入门的那一种。它没有复杂的数据存储要求配置即文件挂载出来改完就生效整个过程能让你集中精力理解Docker的核心模型镜像、容器、数据卷、端口映射而不是被各种编译参数绊住脚。2. Docker环境安装全攻略2.1 Windows和macOSDocker Desktop安装要点Windows用户直接去官网下载Docker Desktop安装包现在新版默认用WSL2后端安装后需要保证Windows功能里启用了适用于Linux的Windows子系统和虚拟机平台。装完打开终端跑docker version能同时看到client和server版本号就说明正常。一个常见坑是WSL2内核版本太旧会提示WSL kernel version too low到微软官网装一下最新WSL更新包就好。macOS用户如果电脑是M系列芯片Docker Desktop会默认走arm架构镜像如果拉取的镜像没有arm版本运行时会自动做模拟兼容性一般没问题但性能会有折损。这种情况可以在Docker Desktop设置里勾选Rosetta模拟或者拉镜像时加--platform linux/amd64强制指定平台。Docker Desktop本质是跑了一个轻量虚拟机来承载Docker引擎所以占内存是比较狠的默认2GB起步如果你电脑配置一般建议在Settings里把内存调低一点否则同时开IDE和浏览器会卡到怀疑人生。2.2 Linux服务器Docker Engine安装服务器上装的就纯粹一些直接装Docker Engine。以Ubuntu为例官方推荐通过apt仓库安装sudo apt update sudo apt install ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin重点提醒一句不要图省事直接apt install docker.io那个包虽然也能用但版本常年落后很多新特性用不了。装完启动sudo systemctl enable --now docker sudo docker run hello-world能打印出Hello from Docker!就说明引擎跑起来了。如果你的用户不想每次敲命令都加sudo把用户加入docker组sudo usermod -aG docker $USER退出重进终端生效。这个操作在本地开发机上很省事但在生产服务器上要谨慎docker组权限约等于root谁在组里谁就能挂载宿主机目录安全风险要自己权衡。2.3 镜像下载慢的提速配置装完Docker第一件想干的事应该是拉镜像但国内直连Docker Hub的速度简直让人崩溃几兆的文件能拉到超时。解决办法是配置镜像加速器。Linux上编辑/etc/docker/daemon.jsonWindows/macOS在Docker Desktop的Docker Engine配置界面里改{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com, https://docker.nju.edu.cn ] }改完重启Docker。这里有个原则加速地址宁可多配几个因为公共源偶尔会挂多几个备选能提高成功率。配置后拉镜像的速度会明显改善实测小镜像基本秒级完成。如果你是在海外服务器上这一步直接跳过直连就很快。3. 跑起第一个nginx容器3.1 拉取官方镜像和容器生命周期管理先拉镜像docker pull nginx默认拉的是nginx:latest指向当前最新稳定版。生产环境我更推荐用带具体版本的标签比如nginx:stable-alpineAlpine版的镜像体积更小攻击面也更少适合跑正式服务。容器的最基本操作命令就这几条# 启动一个名为nginx-test的容器把宿主机的8080端口映射到容器的80端口 docker run -d --name nginx-test -p 8080:80 nginx # 查看正在运行的容器 docker ps # 查看容器日志 docker logs nginx-test # 进入容器内部 docker exec -it nginx-test bash # 停止容器 docker stop nginx-test # 启动已停止的容器 docker start nginx-test # 删除容器 docker rm nginx-test我当初上手时理解-p参数费了点劲。它的格式是宿主机端口:容器内端口容器里应用监听的是80但你不想占用宿主机80端口就映射成8080。外部访问http://服务器IP:8080时流量先进宿主机的8080端口再被Docker转发到容器的80。这个机制就是NAT端口映射理解了它后面所有端口不通的问题都能猜到一半原因。3.2 验证欢迎页和容器内文件结构浏览器打开http://localhost:8080能看到nginx的欢迎页说明容器已经正常工作了。这时候很多人会好奇nginx到底运行在哪儿配置文件又在哪儿建议进容器看一下docker exec -it nginx-test bash ls /usr/share/nginx/html cat /etc/nginx/nginx.conf容器内是个精简版Linux环境nginx就装在/usr/share/nginx/html下的网页文件和/etc/nginx下的配置。你会发现容器里的目录结构和你直接在Linux上装的一模一样这就是Docker的好处镜像把整个运行环境都打包好了不管在谁家的机器上跑里面都一样。3.3 用数据卷挂载配置文件和网站目录默认容器里的欢迎页没啥看头而且你要是改它容器一删就全没了。真实使用场景里你一定希望配置和静态文件放在宿主机上随时能改。这就要用到数据卷挂载用-v参数把宿主机目录映射进容器docker run -d --name nginx-site \ -p 8080:80 \ -v /home/user/nginx/html:/usr/share/nginx/html:ro \ -v /home/user/nginx/conf.d:/etc/nginx/conf.d:ro \ -v /home/user/nginx/logs:/var/log/nginx \ nginx参数含义拆开来说第一个-v把宿主机的html目录挂到容器内的nginx网页目录:ro表示只读防止容器内部意外修改文件第二个-v把宿主机上的conf.d目录挂进容器的配置文件目录所有sites-enabled风格的站点配置都可以放这里第三个-v把日志目录挂出来方便用tail在宿主机查日志。这个操作理解起来的关键是挂载之后宿主机和容器共享这一份数据你在宿主机上改文件容器内立刻能看到对应变化。但nginx读配置是启动时加载的所以光改文件还不生效需要进去reload这个后面专门讲。4. 手写一份可用的nginx反向代理配置4.1 看懂nginx配置文件的基本结构nginx的配置文件层级关系其实很清晰从上到下是events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; upstream backend { server 192.168.1.10:3000 weight1; server 192.168.1.11:3000 weight2; } server { listen 80; server_name example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } }events块管并发连接模型一般默认就好http块是所有HTTP服务相关配置的根upstream定义一个后端服务器组可以做负载均衡server块代表一个虚拟主机类似Nginx里一座大楼的接待台location块是具体的路径转发规则。新手最需要搞清楚的是location和proxy_pass的配合。proxy_pass http://backend;就是把匹配到的请求转发给backend这一组后端服务器。如果后端只有一台机器也可以直接写proxy_pass http://192.168.1.10:3000;不用upstream。还有一个细节很容易踩坑proxy_pass结尾的斜杠有无会导致转发URI的拼接方式完全不同。比如location /api/配上proxy_pass http://backend/;请求/api/users会转发成/users也就是把location前缀剥掉了而proxy_pass http://backend;没有斜杠转发的是完整URI/api/users。这个行为一定要在本地分别试一遍否则你以为路径对了后端返回404时完全不知道问题出在哪。4.2 完整反向代理配置实例假设现在有个Node.js服务跑在3000端口有个Python服务跑在8000端口你想统一走nginx入口。一份可以直接用的配置长这样server { listen 80; server_name myapp.example.com; # 根路径转发到Node.js服务 location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # /python路径转发到Python服务 location /python/ { proxy_pass http://127.0.0.1:8000/; proxy_set_header Host $host; } }注意proxy_set_header Host $host这一行它的作用是让后端服务看到的是客户端请求的域名而不是nginx的地址。很多后端框架生成跳转链接时会根据Host头拼URL如果不把原始Host传过去跳转地址就会变成nginx的内网IP用户访问就出错。X-Real-IP和X-Forwarded-For则是把客户端真实IP往后端传后端做日志、风控、限流都会依赖这个信息。配置写好后把文件放到之前挂载的conf.d目录里名字自取比如myapp.conf。然后进容器加载新配置docker exec nginx-site nginx -t docker exec nginx-site nginx -s reload第一条nginx -t是检查配置文件语法有错会在终端直接报行号第二条是平滑重载配置这个过程不会有请求丢失非常优雅。我习惯每次改完配置先跑-t确认无误再reload能避免把整个nginx搞挂。4.3 挂载多个项目目录的扩展配置热搜词里docker安装nginx并挂载多个项目目录是这个方向的典型需求。核心思路很简单一个nginx可以同时承载很多个server块每个server代表一个站点或者一组转发规则配置各自放在conf.d下的独立文件里互不干扰。比如你有一个静态博客和一个API服务# blog.conf server { listen 80; server_name blog.example.com; root /usr/share/nginx/html; index index.html; }# api.conf server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; } }只要这两个解析到了同一台Nginx服务器Docker容器启动时挂载conf.d目录两个用户方向互不影响。实际多人共用一台服务器时这种做法非常常见每个项目一份配置文件谁出了问题就排查谁的。4.4 负载均衡和HTTPS卸载的快速扩展如果后端有多个实例直接用upstream做轮询或加权分配upstream backend_servers { server 192.168.1.10:3000 weight3; server 192.168.1.11:3000 weight1; server 192.168.1.12:3000 down; } server { listen 80; location / { proxy_pass http://backend_servers; proxy_next_upstream error timeout http_502; } }weight控制流量比例down标记某台后端下线用于维护proxy_next_upstream表示当前后端返回502时自动切换下一个这个在生产环境能救命避免单点故障影响所有用户。HTTPS配置只需加一个监听443的server块证书用-v挂载到容器内部然后ssl_certificate和ssl_certificate_key指向挂载路径。这个扩展很自然因为有了这种复制配置、改几行的能力后面加新项目基本就是十分钟内的事。5. 用Docker Compose把整套服务编排起来5.1 一条条run命令为什么不够用了当项目涉及多个容器联调比如nginx、后端API、MySQL、Redis还按部就班地敲docker run就不是优雅而是灾难了。每次重启环境要敲几十条命令参数还容易记混。Docker Compose的定位是用一个YAML文件声明整套服务一条命令拉起、一条命令关掉可重复、可版本化。以最常见的nginx反代一个API服务加一个MySQL为例项目根目录建一个docker-compose.yml5.2 Compose文件怎么写到能直接跑version: 3.8 services: api: build: ./api ports: - 3000:3000 environment: - DB_HOSTmysql - DB_PORT3306 depends_on: - mysql nginx: image: nginx:stable-alpine ports: - 80:80 - 443:443 volumes: - ./nginx/conf.d:/etc/nginx/conf.d:ro - ./nginx/html:/usr/share/nginx/html:ro - ./nginx/logs:/var/log/nginx depends_on: - api mysql: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORDrootpass - MYSQL_DATABASEappdb volumes: - mysql_data:/var/lib/mysql volumes: mysql_data:先说明几个重要点。depends_on只保证依赖服务先启动不保证依赖服务已经就绪比如API容器启动了但MySQL可能还在初始化中连接会失败。生产环境稳妥做法是在应用代码里做重试或者用健康检查来控制真正启动的时机。services下面的名字特别好用。Compose会自动创建一个网络同一个Compose文件里所有服务可以直接用服务名互相访问比如nginx里配置的proxy_pass http://api:3000这个api指的就是上面Compose里名为api的服务Docker内置DNS会解析到对应容器IP完全不用像之前那样手动填127.0.0.1或者查IP。MySQL数据卷命名为mysql_dataCompose自动管理它的生命周期容器删了数据还在下次up -d数据自动挂回来这个对数据库容器来说非常重要否则删除容器等于删除数据库。启动命令极其简单docker compose up -d docker compose ps docker compose logs -f nginx docker compose downdown会把容器和默认网络都清掉但数据卷默认保留所以数据库不会丢。想连数据卷一起清掉才用down -v这条命令要慎重删了数据找不回来。5.3 配置改完不用重建容器的更新技巧改完nginx配置后直接执行docker compose exec nginx nginx -t docker compose exec nginx nginx -s reload没必要重启容器因为配置是通过数据卷挂载进去的容器里进程还在跑reload一下就能生效。这个习惯能让你在频繁调配置时少很多无谓的等待也避免了容器重建带来的短暂中断。6. 新手最容易踩的六个坑6.1 docker pull 镜像特别慢甚至超时配置了镜像加速器还是慢的话先确认配置有没有生效docker info | grep -A 5 Registry Mirrors如果还是慢考虑网络本身和节点因素公共加速源也有高峰期多配几个源可以显著提升成功率。拉取大镜像时比如MySQL、PostgreSQL我建议尽量选Alpine变体体积能小一半以上下载时间自然会缩短。6.2 改了配置文件nginx内容没变化这个问题八成是挂载路径不对。容器里nginx读取的是/etc/nginx/nginx.conf它默认会用include把/etc/nginx/conf.d/*.conf加载进来所以你宿主机上的配置要放在挂载对应位置而不是随手放哪都行。验证方式进容器里看文件内容docker exec nginx-site cat /etc/nginx/conf.d/myapp.conf如果根本看不到这个文件说明你的-v挂载路径和容器内路径对不上。还有另一种情况是挂载对了但nginx没reload改完配置记得nginx -t加nginx -s reload。6.3 端口绑定失败提示address already in use启动容器时报这么一段错误的时候先查端口占用sudo netstat -tlnp | grep 8080然后选择换个端口或者停掉占用进程。常见情况是你的nginx应用本身占着80端口Docker再映射80就冲突了本地开发常见的解法是换映射端口比如-p 8080:80。Windows/macOS上尤其要留意Docker Desktop自身可能会占部分端口段换一个冷门端口更省心。6.4 反向代理502 Bad Gateway502的意思是nginx成功转发但后端没收到有效响应。排查顺序我一直用这套后端容器真的在跑吗docker ps后端应用真的监听了预期的端口吗进容器curl 127.0.0.1:3000从nginx容器能访问到后端吗docker exec nginx curl http://api:3000如果后端是宿主机上的进程检查nginx容器能否通过网关IP访问宿主机容器间网络问题优先级最高的解法是让nginx和后端在同一个自定义网络里用服务名互访。这也是Compose里默认就做好的事手工docker run的时候需要你主动docker network create再--network指定否则默认bridge网络下大家IP都不固定抄来抄去很容易出错。6.5 容器一启动就退出这个现象一般是前台进程退出了。Docker容器必须有一个前台运行的进程如果这个进程结束容器就会退出。nginx官方镜像的启动命令是前台跑nginx -g daemon off;如果你挂载了自定义的entrypoint或者CMD把它覆盖掉了容器就可能秒退。这时候第一时间看日志docker logs 容器名或者直接docker start 容器名再配合docker logs -f观察。日志里如果报nginx配置错误大概率是你的配置文件语法有问题本地执行nginx -t能帮你提前发现。6.6 容器误删之后配置全没了这是没养成挂载习惯的必然后果删了容器没有挂载的配置和数据也跟着没了。解法是提前规划好数据卷配置文件、静态文件、日志目录全部分别-v挂载到宿主机数据卷里的内容才能长期保存。数据库类的服务更应该用具名数据卷或者直接挂载宿主机的目录这样就算容器重建数据也稳如泰山。7. 实操总结与一点个人心得从零开始到能用nginx反向代理多个服务核心的知识点其实就四个镜像和容器的关系、端口映射、数据卷挂载、nginx配置声明式语法。这四个点就像四个积木拼在一起就能应对绝大多数个人项目和中小团队的基础架构场景。我做这一行这么久最深的体会是Docker把环境一致性这个能力真正下放给了开发者。以前我机器上明明是好的这句话现在越来越多地被Dockerfile和Compose文件替代任何人在任何机器上拉起来跑结果都一样。你只要肯花一晚上把上面这些命令和配置亲手敲一遍后面几乎不会再被环境问题逼到熬夜。最后再分享一个小习惯不管做什么容器先想清楚数据放哪、配置放哪、日志放哪再把对应目录挂载出去而不是图省事全部塞进容器里。这个习惯养成之后你的容器就可以随意删除重建而服务状态永远都在。