反向代理本质上是一台位于客户端和后端服务之间的中间服务器，客户端请求先到达代理服务器，再由代理转发给真正的后端应用。它的价值在于隐藏后端架构、统一管理HTTPS证书、做负载均衡和访问控制。过去手动在一台裸机上安装配置Nginx，环境容易和系统耦合，迁移起来很痛苦。借助Docker，整个反向代理环境可以打包成容器，配置文件独立存放，随时删除重建，迁移到新服务器只需要拷贝一个目录。
准备工作与整体架构设计
开始之前，需要准备一台有公网IP的服务器，安装好Docker和docker-compose。Docker的安装非常简单，官方提供了一键脚本，执行完用 docker -v 验证版本即可。架构上我们采用两个独立的Docker网络：前端网络承载Nginx代理容器，后端网络承载应用容器，Nginx同时接入两个网络，充当桥梁的角色。这样做的好处是应用容器完全不需要暴露任何端口到宿主机，攻击面大大缩小。
目录结构建议这样组织，配置和数据分离，方便备份和迁移：
nginx-proxy/ ├── docker-compose.yml ├── conf.d/ │ └── default.conf ├── certs/ │ ├── fullchain.pem │ └── privkey.pem └── logs/
先创建一个自定义网络供后续使用，然后编写docker-compose文件。注意这里Nginx容器映射了80和443两个端口到宿主机，而应用容器不映射任何端口：
version: "3.8"
services:
nginx:
image: nginx:1.25-alpine
container_name: nginx-proxy
restart: always
ports:
- "80:80"
- "443:443"
volumes:
- ./conf.d:/etc/nginx/conf.d
- ./certs:/etc/nginx/certs
- ./logs:/var/log/nginx
networks:
- proxy-net
- app-net
webapp:
image: your-app:latest
container_name: webapp
restart: always
networks:
- app-net
networks:
proxy-net:
driver: bridge
app-net:
driver: bridge这里有个容易忽略的细节：Docker的自定义bridge网络内置了DNS服务，容器之间可以直接用容器名互相访问，这是后续写代理地址的关键。如果你用的是默认bridge网络，容器名解析是不生效的，必须通过IP访问，而容器重启后IP会变化，所以务必使用自定义网络。
编写Nginx反向代理配置
Nginx的核心配置在conf.d目录下。一个典型的反向代理配置包含监听、域名匹配、证书引用和转发规则四部分。下面是一个把 api.ipipp.com 转发到内部webapp容器8080端口的完整示例：
server {
listen 80;
server_name api.ipipp.com;
# http 强制跳转 https
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name api.ipipp.com;
ssl_certificate /etc/nginx/certs/fullchain.pem;
ssl_certificate_key /etc/nginx/certs/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
location / {
proxy_pass http://webapp:8080;
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;
}
}重点解释一下 proxy_pass 后面的地址。因为webapp容器和Nginx都接入了app-net网络，所以直接写容器名加内部端口即可，不需要也不应该写宿主机IP。很多教程让新手写宿主机地址再让应用暴露端口，这是典型的反模式，既浪费了一次网络转发的性能，又把应用端口暴露到了公网。
proxy_set_header 这几行也不是可有可无的。如果不设置Host头，后端应用收到的请求Host会是容器名，很多基于域名的路由或资源链接生成会出错；X-Real-IP和X-Forwarded-For用于把真实客户端IP传递给后端，否则后端日志里记录的全是Nginx容器的内网IP，做统计和风控时会抓瞎。改完配置用 docker exec nginx-proxy nginx -t 检查语法，然后 docker exec nginx-proxy nginx -s reload 热加载，整个过程不需要重启容器，线上服务零中断。
负载均衡与多实例配置
当业务量上来，单个后端实例撑不住时，反向代理的负载均衡能力就派上用场了。在Nginx配置中用upstream块定义一组后端服务器，再把 proxy_pass 指向这个upstream名字：
upstream backend_pool {
least_conn; # 最少连接数策略
server webapp1:8080 weight=2;
server webapp2:8080;
server webapp3:8080 backup; # 备用节点，主节点挂了才启用
}
server {
listen 443 ssl;
server_name api.ipipp.com;
ssl_certificate /etc/nginx/certs/fullchain.pem;
ssl_certificate_key /etc/nginx/certs/privkey.pem;
location / {
proxy_pass http://backend_pool;
proxy_connect_timeout 5s;
proxy_read_timeout 30s;
}
}Docker场景下做负载均衡有一个天然的坑：如果用 docker-compose scale 或副本模式启动多个同名容器，容器名解析只会返回其中一个IP，负载均衡实际上失效了。解决办法是在Nginx的upstream里显式列出各实例的容器名，让docker-compose通过别名把每个实例都注册进网络。或者在compose文件里为服务配置多个别名，逐个写进upstream，保证每个实例都能被DNS正确解析到。
健康检查方面，可以给server指令加上 max_fails=3 fail_timeout=10s 参数，让Nginx自动摘除连续失败的节点。不过开源版Nginx的被动健康检查比较粗糙，节点恢复后不会主动探测，配合backup节点使用效果更好。如果预算允许，Nginx Plus或者干脆换用支持主动健康检查的OpenResty也是不错的路线。
常见问题排查与性能优化建议
第一个高频问题是502 Bad Gateway。出现这个错误，九成是Nginx连不上后端。排查思路按顺序来：先用 docker exec nginx-proxy ping webapp 确认网络通不通，再检查 proxy_pass 的端口是不是容器内部监听的端口而不是映射端口，最后看后端应用日志确认服务是否真的启动完成。特别提醒，应用刚启动时可能还没监听端口，Nginx会报connection refused，给后端容器加个健康检查配合 depends_on 的condition可以缓解。
第二个常见问题是上传大文件返回413错误。这是因为Nginx默认限制请求体为1MB，代理场景下需要在server或location块里加 client_max_body_size 50m;。另外WebSocket代理也需要额外配置Upgrade头，否则握手会失败：
location /ws/ {
proxy_pass http://webapp:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 3600s; # 长连接防止被掐断
}性能层面有几个值得做的优化：开启 gzip 压缩文本资源，能减少一半以上的传输量；配置 proxy_cache 把静态资源缓存到代理层，减轻后端压力；调整容器的日志切割策略，避免 logs 目录无限膨胀把磁盘写满。还有一点容易被忽视，宿主机防火墙和云服务商的安全组只需要放行80和443端口，所有其他服务的访问都收口到Nginx这一层，配合IP黑白名单或basic auth，安全等级会提升一大截。整套方案搭建熟练之后，从零开始不到十分钟就能跑起来，这也是Docker化反向代理最大的魅力所在。