尧图网站建设 
自托管 OpenHands Agent Canvas 经 nginx 访问报 502 Bad Gateway 怎么排查【免费下载链接】OpenHands OpenHands: AI-Driven Development项目地址: https://gitcode.com/GitHub_Trending/ope/OpenHands在虚拟机上自托管 OpenHands Agent Canvas 并配好 nginx Lets Encrypt 后浏览器打开域名却返回502 Bad Gateway。官方自托管指南docs/SELF_HOSTING.md对这一现象给出了直接判断看到 502说明127.0.0.1:8000上的应用进程已经不在了第一要务是确认启动 Agent Canvas 的npx进程是否还在运行。先弄清楚 502 出现在哪一层自托管的默认部署链路是用户浏览器 → nginx :443 (TLS) → Ingress proxy 127.0.0.1:8000 ├── /* → Static server :3001 ├── /api/*, /sockets → Agent server :18000 └── /api/automation/* → Automation backend :18001npx openhands/agent-canvas --public会一次性拉起静态前端、agent server、automation backend并在127.0.0.1:8000前面挂一个按路径路由的 ingress 代理——nginx 只需要知道这一个 ingress 端口。502 有两种来源排查方向不同nginx 自己返回的 502ingress 进程整体不在监听127.0.0.1:8000所有请求包括页面本身都失败。SELF_HOSTING 文档指出的就是这种情况app 在127.0.0.1:8000挂了。ingress 返回的 502ingress 本身活着首页能打开但它按路径转发到某个后端时连不上代理层会返回 502 且响应体为Bad Gateway: 具体错误。这一点在仓库的代理实现和测试中有明确定义tests/scripts/ingress.test.ts 验证了后端不可用时返回 502 且响应体包含Bad Gatewayscripts/proxy-utils.mjs 中的writeProxyError负责输出Bad Gateway: ${message}。后端进程agent server :18000、automation backend :18001崩溃时容器/主进程不会整体退出只是对应路由返回 502见 docker/entrypoint.sh 中Backend crashes (agent-server, automation) are tolerated — the proxy returns 502 for downed routes的说明。第一步确认 ingress 进程还在不在按文档给出的验证命令检查入口状态curl -I https://canvas.example.com/ # 正常应返回 200 curl -I http://canvas.example.com/ # 正常应返回 301 到 httpscanvas.example.com替换为你自己的域名。如果第一条命令直接报 502说明127.0.0.1:8000上的进程已经退出按 SELF_HOSTING 文档的做法检查启动 Agent Canvas 的npx进程是否还在运行用 tmux 启动的tmux attach -t canvas回连会话看进程是否还活着用 systemd 启动的agent-canvas.service配置见 docs/SELF_HOSTING.md 第 3 节检查服务状态systemctl status agent-canvas确认单元文件里Restarton-failure是否生效、EnvironmentLOCAL_BACKEND_API_KEYyour-key是否还在。确认进程退出后重新启动即可。systemd 方式sudo systemctl enable --now agent-canvastmux 方式需要重新带上密钥环境变量export LOCAL_BACKEND_API_KEYyour-saved-key tmux new-session -d -s canvas npx openhands/agent-canvas --publicyour-saved-key是你当初openssl rand -base64 32生成并妥善保存的那个密钥不是占位符——丢失后只能重新生成并更新所有已注册的 backend 会话。第二步ingress 活着但部分路由仍 502如果页面本身能打开200但界面请求/api/*时拿不到数据、代理返回Bad Gateway说明 502 来自 ingress 到某个后端的转发失败而不是 nginx 这一层。此时逐个确认三个后端是否都在监听服务默认端口对应路由Static server:3001未匹配路由的默认转发Agent server:18000/api/*、/socketsAutomation backend:18001/api/automation/*一个文档明确记载的假故障场景首次启动时uvx需要下载 Python 工具链并从 PyPI 安装openhands-agent-server在慢网络上easily take a few minutes。electron 启动逻辑对/server_info的轮询注释说明得很清楚ingress 返回 502 时意味着upstream agent server isnt bound yet即 agent server 还没绑定端口见 electron/main.mjs。首次部署或刚重启后先给启动过程留出几分钟再判断后端是否真的异常。判断方式响应体是Bad Gateway: 错误信息说明请求已经到达 ingress问题在 ingress 与其目标后端之间错误信息本身如连接被拒绝会随响应体带出可直接对照上表定位是哪个端口没起来。恢复后如何验证按 SELF_HOSTING 文档的验证步骤收尾curl -I https://canvas.example.com/ # → 200显示 API key 输入界面 curl -I http://canvas.example.com/ # → 301 到 https然后在浏览器打开https://canvas.example.com/输入你的LOCAL_BACKEND_API_KEY--public模式下密钥不内置进前端首次加载 UI 时必须手动粘贴能进入 Agent Canvas 主界面即说明整条链路恢复。相关限制与注意事项文档没有承诺 502 一定对应单一根因--public模式下所有/api/*调用都要求携带匹配的X-Session-API-Key头这与 502 无关但排查期间如果 UI 一直弹 API key 输入框先确认密钥没换错。ingress、agent server、automation backend、static server 四个端口都不应暴露在公网防火墙层面只开 22/80/443见 docs/SELF_HOSTING.md 第 2、4 节。如果 502 只在公网访问时出现而 SSH 进机器本地curl 127.0.0.1:8000正常优先检查 nginx 的proxy_pass是否确实指向http://127.0.0.1:8000以及nginx -t systemctl reload nginx是否执行过。agent server 直接跑在宿主机上、对文件系统有完全访问权重启服务前确认 systemd 单元或 tmux 会话中的LOCAL_BACKEND_API_KEY与当前生效值一致否则重启后 UI 会要求重新输入 key。【免费下载链接】OpenHands OpenHands: AI-Driven Development项目地址: https://gitcode.com/GitHub_Trending/ope/OpenHands创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 自托管 OpenHands Agent Canvas 经 nginx 访问报 502 Bad Gateway 怎么排查？
自托管 OpenHands Agent Canvas 经 nginx 访问报 502 Bad Gateway 怎么排查【免费下载链接】OpenHands OpenHands: AI-Driven Development项目地址: https://gitcode.com/GitHub_Trending/ope/OpenHands在虚拟机上自托管 OpenHands Agent Canvas 并配好 nginx Lets Encrypt 后浏览器打开域名却返回502 Bad Gateway。官方自托管指南docs/SELF_HOSTING.md对这一现象给出了直接判断看到 502说明127.0.0.1:8000上的应用进程已经不在了第一要务是确认启动 Agent Canvas 的npx进程是否还在运行。先弄清楚 502 出现在哪一层自托管的默认部署链路是用户浏览器 → nginx :443 (TLS) → Ingress proxy 127.0.0.1:8000 ├── /* → Static server :3001 ├── /api/*, /sockets → Agent server :18000 └── /api/automation/* → Automation backend :18001npx openhands/agent-canvas --public会一次性拉起静态前端、agent server、automation backend并在127.0.0.1:8000前面挂一个按路径路由的 ingress 代理——nginx 只需要知道这一个 ingress 端口。502 有两种来源排查方向不同nginx 自己返回的 502ingress 进程整体不在监听127.0.0.1:8000所有请求包括页面本身都失败。SELF_HOSTING 文档指出的就是这种情况app 在127.0.0.1:8000挂了。ingress 返回的 502ingress 本身活着首页能打开但它按路径转发到某个后端时连不上代理层会返回 502 且响应体为Bad Gateway: 具体错误。这一点在仓库的代理实现和测试中有明确定义tests/scripts/ingress.test.ts 验证了后端不可用时返回 502 且响应体包含Bad Gatewayscripts/proxy-utils.mjs 中的writeProxyError负责输出Bad Gateway: ${message}。后端进程agent server :18000、automation backend :18001崩溃时容器/主进程不会整体退出只是对应路由返回 502见 docker/entrypoint.sh 中Backend crashes (agent-server, automation) are tolerated — the proxy returns 502 for downed routes的说明。第一步确认 ingress 进程还在不在按文档给出的验证命令检查入口状态curl -I https://canvas.example.com/ # 正常应返回 200 curl -I http://canvas.example.com/ # 正常应返回 301 到 httpscanvas.example.com替换为你自己的域名。如果第一条命令直接报 502说明127.0.0.1:8000上的进程已经退出按 SELF_HOSTING 文档的做法检查启动 Agent Canvas 的npx进程是否还在运行用 tmux 启动的tmux attach -t canvas回连会话看进程是否还活着用 systemd 启动的agent-canvas.service配置见 docs/SELF_HOSTING.md 第 3 节检查服务状态systemctl status agent-canvas确认单元文件里Restarton-failure是否生效、EnvironmentLOCAL_BACKEND_API_KEYyour-key是否还在。确认进程退出后重新启动即可。systemd 方式sudo systemctl enable --now agent-canvastmux 方式需要重新带上密钥环境变量export LOCAL_BACKEND_API_KEYyour-saved-key tmux new-session -d -s canvas npx openhands/agent-canvas --publicyour-saved-key是你当初openssl rand -base64 32生成并妥善保存的那个密钥不是占位符——丢失后只能重新生成并更新所有已注册的 backend 会话。第二步ingress 活着但部分路由仍 502如果页面本身能打开200但界面请求/api/*时拿不到数据、代理返回Bad Gateway说明 502 来自 ingress 到某个后端的转发失败而不是 nginx 这一层。此时逐个确认三个后端是否都在监听服务默认端口对应路由Static server:3001未匹配路由的默认转发Agent server:18000/api/*、/socketsAutomation backend:18001/api/automation/*一个文档明确记载的假故障场景首次启动时uvx需要下载 Python 工具链并从 PyPI 安装openhands-agent-server在慢网络上easily take a few minutes。electron 启动逻辑对/server_info的轮询注释说明得很清楚ingress 返回 502 时意味着upstream agent server isnt bound yet即 agent server 还没绑定端口见 electron/main.mjs。首次部署或刚重启后先给启动过程留出几分钟再判断后端是否真的异常。判断方式响应体是Bad Gateway: 错误信息说明请求已经到达 ingress问题在 ingress 与其目标后端之间错误信息本身如连接被拒绝会随响应体带出可直接对照上表定位是哪个端口没起来。恢复后如何验证按 SELF_HOSTING 文档的验证步骤收尾curl -I https://canvas.example.com/ # → 200显示 API key 输入界面 curl -I http://canvas.example.com/ # → 301 到 https然后在浏览器打开https://canvas.example.com/输入你的LOCAL_BACKEND_API_KEY--public模式下密钥不内置进前端首次加载 UI 时必须手动粘贴能进入 Agent Canvas 主界面即说明整条链路恢复。相关限制与注意事项文档没有承诺 502 一定对应单一根因--public模式下所有/api/*调用都要求携带匹配的X-Session-API-Key头这与 502 无关但排查期间如果 UI 一直弹 API key 输入框先确认密钥没换错。ingress、agent server、automation backend、static server 四个端口都不应暴露在公网防火墙层面只开 22/80/443见 docs/SELF_HOSTING.md 第 2、4 节。如果 502 只在公网访问时出现而 SSH 进机器本地curl 127.0.0.1:8000正常优先检查 nginx 的proxy_pass是否确实指向http://127.0.0.1:8000以及nginx -t systemctl reload nginx是否执行过。agent server 直接跑在宿主机上、对文件系统有完全访问权重启服务前确认 systemd 单元或 tmux 会话中的LOCAL_BACKEND_API_KEY与当前生效值一致否则重启后 UI 会要求重新输入 key。【免费下载链接】OpenHands OpenHands: AI-Driven Development项目地址: https://gitcode.com/GitHub_Trending/ope/OpenHands创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考