机器人调度平台部署怎么搭，才不会每次上线都排查502到半夜？
最近帮一个做机器人调度平台二次开发的客户做上线支持——他们工程师连续三个晚上排查 502 到半夜，每次都怀疑是网络问题，最后发现 80% 都是这三道关的事。这就是这一篇要讲的事。
调度平台最难的一次排障，不是在算法层，是在部署那一晚。
"本地能跑，服务器 502"的经典难题
代码在本地完全跑通，部署到客户服务器，第一次访问页面：白屏 + 502 Bad Gateway。
开发团队集体加班两小时，从"后端进程在不在"开始排查，最后定位到一个完全没料到的原因。
行业里典型的"三道关"
带过几次部署后，我们发现机器人/AI 类系统的"网络问题"很少真的是网络问题，而是"配置层"问题。
排查路径大致都逃不开这三道关：
- 🔒 第一关：云厂商安全组
- 🚪 公网能进来的端口必须在云控制台放行
- 🚪 入方向规则、出方向规则都要查
- 🔒 第二关：操作系统防火墙
- 🚪 即使云端放行，OS 自身的防火墙可能再拦一道
- 🚪 Linux 的 iptables、Windows 的高级安全防火墙都得过
- 🔒 第三关：应用层（反向代理）
- 🚪 Nginx、Apache 这类反向代理的配置覆盖、转发路径
- 🚪 一个 location 写错，整条链路就废
那天我们 502 的根因，是 Nginx 配置从老文档复制时漏了一个 location 转发规则——前端请求打过去，反转了 Nginx 自己，没到后端。
部署踩过的几个反常识坑
- 🎯 "配置覆盖"是个常见现象——多个 conf 文件同时生效，互相覆盖
- 🎯 "路径斜杠"是隐形杀手——路径末尾多一个少一个斜杠，转发行为完全不一样
- 🎯 "前端路由模式"要和"部署路径"对齐——这两件事任何一对不齐，刷新就 404
- 🎯 "本地能跑 ≠ 服务器能跑"——本地默认配置通常更宽松，服务器更严格
我们后来养成的几个习惯
- 📋 部署清单：每次上线都按清单走，逐项打钩，不靠记忆
- 🩺 一键诊断脚本：自己写了一个工具，能快速列出"当前生效配置 / 路径状态 / 端口监听"三件事
- 📝 文档同步：每改一次配置，同步更新一份"为什么这么改"的说明，避免几个月后自己看不懂
- 🔍 配置 diff：上线前对比"上次生效配置 vs 本次改动"，避免覆盖和丢失
一个隐藏的"部署环境差异"
最容易被忽视的是"环境差异"——本地开发用宽松配置，生产用严格配置，部署的时候经常直接拿本地的 .env 上生产，结果触发各种"为什么本地能跑生产不行"。
我们的做法大致是：
- 🚪 公共基线配置：跟代码一起进仓库，所有人共用
- 🚪 环境专属配置：本地 / 测试 / 生产各自一份，不互相覆盖
- 🚪 敏感配置不进仓库：本地临时覆盖、密钥类配置走另外渠道
- 🚪 敏感信息脱敏：模板里用占位符，避免真实凭据被无意提交
写在最后
部署这件事，最容易踩的坑不是技术问题，是流程问题。流程没跑通，每次部署都是赌运气。
我们后来给客户做交付培训，第一课就是"部署清单 + 一键诊断"。客户工程师学会这两件事，能解决 80% 的部署问题。剩下 20% 是网络环境本身的坑，那就只能现场排查了。
关于作者：越微智能（Yuewell）专注具身智能与工业 AI 视觉落地，基于自研 VLA 多模态大模型，提供全品牌机器人二次开发（适配宇树/优必选/智元/傅利叶）与工业级视觉算法定制，支持从算法、硬件到产线实机部署的全栈交付。
