宝塔面板反向代理到Docker服务时502错误怎么排查

很多站长会用Docker跑应用，再用宝塔面板的Nginx反向代理绑定域名。页面访问出现502时，问题通常不在一个地方：容器可能没监听正确端口，Nginx可能转发到错误地址，防火墙也可能拦截本机端口。下面按真实排查顺序整理一套流程，适合WordPress测试站、Node.js应用、API服务和管理面板类应用。

一、确认Docker容器本身是否正常

在服务器上执行容器列表检查，确认目标容器状态不是Exited或Restarting。如果容器频繁重启，应先看应用日志，而不是反复改宝塔配置。常见原因包括环境变量缺失、数据库连接失败、端口被占用、镜像启动命令写错。

如果容器状态正常，再确认应用在容器内监听的端口。很多镜像文档写的是容器端口，例如3000、8080、9000，但映射到宿主机时可能变成127.0.0.1:13000或0.0.0.0:8080。宝塔反代要填宿主机可访问的地址。

二、检查反向代理目标地址

宝塔面板中常见写法是http://127.0.0.1:端口。若Docker端口只绑定到127.0.0.1，这种写法通常可行；若容器部署在Docker自定义网络里，并没有映射到宿主机，Nginx就无法通过宿主机端口访问。

一个实际坑点是把https写进代理目标。内部服务多数只提供HTTP，外层证书由Nginx处理即可。若把代理目标写成https://127.0.0.1:3000，而应用没有启用TLS，就可能触发502或握手失败。

三、用本机请求定位问题边界

建议在服务器上直接访问代理目标，例如curl http://127.0.0.1:3000。若本机访问失败，说明问题在应用、端口映射或防火墙；若本机访问成功但域名502，问题才更可能在宝塔站点配置、Nginx规则、SSL或缓存。

对于只允许容器网络访问的服务，可以临时暴露一个本机端口用于验证，确认后再决定是否改成同网络Nginx方案。不要为了省事直接开放公网端口，尤其是数据库、Redis、管理后台这类服务。

四、查看Nginx错误日志

宝塔面板站点日志通常能看到connect failed、upstream prematurely closed connection、no live upstreams等提示。connect failed多半是端口或地址不通；upstream prematurely closed connection可能是应用超时、进程崩溃或响应头异常。

如果应用首次启动慢，可以适当增加proxy_read_timeout，但不要把超时时间调得过大来掩盖应用卡死。真正稳定的做法是给容器加健康检查、限制重启策略，并把日志保留到可追踪的目录。

五、修复后的安全检查

502修复后还要检查HTTPS跳转、真实IP传递、WebSocket支持和后台路径访问。某些应用需要X-Forwarded-Proto、Host、X-Real-IP等请求头，否则登录回调、静态资源地址或WebSocket连接会异常。

如果服务面向公网，建议配合防火墙只开放80和443，把应用端口限制在本机访问。宝塔面板和Docker都能快速完成部署，但安全边界仍要由站长自己确认。

六、把宝塔反向代理502落到日常维护

宝塔反向代理502真正发挥作用，通常不在第一次配置或第一次阅读时，而是在后续维护中反复被验证。站长可以把本文提到的步骤整理成一张小清单，放在项目文档、知识库或团队协作工具里。每次改配置、换工具、升级版本、迁移服务器或调整运营流程前，先对照清单确认当前状态，再记录修改原因和结果。这样做看起来比直接操作慢几分钟，却能在故障发生时节省大量排查时间。

如果是技术类场景，建议额外记录四类信息：服务运行位置、关键配置文件路径、回滚命令、最近一次可用备份。很多服务器问题并不是不会修，而是出问题后找不到当初怎么配置的。若是运营、软件或知识库场景，则要记录素材来源、更新时间、负责人和适用边界。工具界面、平台规则、同步方式都会变化，文档没有更新时间，就很难判断内容是否仍然可靠。