issue: Open Terminal panel attempts direct browser connections to the terminal URL, breaking setups with open-terminal in docker compose sta

快速结论：当 Open WebUI 与 Open Terminal（或同类 Terminal Server）部署在 Docker Compose 同一内网、通过公网域名/反向代理访问 Open WebUI 时，前端会尝试直接用浏览器访问 http://open-terminal:8000 这类仅容器网络可达的地址，从而出现 “Server connection failed” 或 “Failed to load directory” 的报错。优先排查的是：当前版本中 Open Terminal 的连接请求到底由后端代理，还是被前端直接发起。

适用环境：Open WebUI v0.11.3，Docker 安装方式，Windows 11 客户端，Firefox 154.0；Open Terminal 与 Open WebUI 位于同一 Docker Compose 内网，Open WebUI 通过反向代理对外暴露。Issue 未提供 Python、CUDA、显卡、Ollama 版本等证据，故不列出。

最快修复方案：暂无确认的一步修复方案。Issue 中已验证“openwebui 容器到 open-terminal 容器的后端连通性正常”（docker exec open-webui curl -s http://open-terminal:8000/health 返回 {"status":"ok"}），但前端直连问题没有被确认修复，需等待版本更新或按下方步骤进一步排查。

注意事项：把 Open Terminal 地址改成浏览器可达的公网/宿主地址只是绕过前端直连的权宜做法，并非 Issue 中验证过的修复；且可能引入混合内容、鉴权头丢失或反向代理路径不匹配等新问题。Issue 同时指出该问题与 #23048（Tool Server 的前后端连接错位）属同一类回归，因此需要确认是否已有对应修复版本。

问题场景

用户在 Docker Compose 栈中同时运行 Open WebUI 和 Open Terminal，Open Terminal 通过内部主机名（例如 http://open-terminal:8000）对 Open WebUI 后端可达。用户从局域网/公网浏览器访问 Open WebUI，在「设置 → 集成 / Integrations」里配置 Open Terminal 地址并点击 “Verify Connection”，或在聊天窗口打开 Open Terminal 面板时触发报错。文档说明终端请求应由 Open WebUI 后端代理，浏览器不应直接访问终端服务器，但实际抓包显示前端在直接请求 http://open-terminal:8000/ports 和 /api/v1/terminals/<id>/files/cwd 等地址。

报错原文

Server connection failed

Failed to load directory. Check your Terminal connection in Settings → Integrations.

GET http://open-terminal:8000/ports

GET http://10.0.0.111:3000/api/v1/terminals/35c532b8-1416-4b5d-97af-97e1f134302d/files/cwd

GET http://10.0.0.111:3000/api/v1/terminals/

其中 /ports 请求由于混合内容（mixed content）以及该地址在浏览器侧不可解析而失败；/api/v1/terminals/ 的响应仍把内部地址 http://open-terminal:8000 暴露给前端：

[
    {
        "id": "35c532b8-1416-4b5d-97af-97e1f134302d",
        "url": "http://open-terminal:8000",
        "name": "open-term",
        "contexts": {},
        "config": {
            "chat_uploads": "default"
        }
    }
]

原因分析

最可能的原因是 Open Terminal / Terminal Server 的集成在 v0.11.3 中存在前后端职责错位：后端已经保存并能正常连通终端服务，但“Verify Connection”和面板加载目录走了前端直连逻辑，前端按配置中的 url 直接向 http://open-terminal:8000 发起请求。由于该主机名只在 Docker 内网 DNS 中存在，浏览器无法解析；若 Open WebUI 通过 HTTPS 暴露，还会因 HTTPS 页面请求 HTTP 地址被浏览器以 mixed content 拦截。Issue 评论指出这与 #23048 属于同一类回归，并且 #22581、#28148 显示 Open Terminal 的连接处理近期确实存在多起客户端侧回归，因此该判断具有较高可信度，但 Issue 本身没有给出代码层面的最终定位。

环境排查

确认 Open WebUI 版本是否为 v0.11.3，并核对 dev 分支或最新版是否仍存在该问题。
确认 Open Terminal 容器是否与 Open WebUI 容器处于同一 Docker 网络，并能通过内部主机名互通。
确认浏览器控制台/Network 中失败请求的实际 URL，判断是 http://open-terminal:8000/ports 这类直连，还是 /api/v1/terminals/... 这类后端接口。
确认 Open WebUI 对外是否使用 HTTPS；如果是，检查是否存在 mixed content 拦截。
确认「设置 → 集成」是否存在两个 Integration 入口（tools 下的 Integrations 与 services 下），避免在错误页面判断连接未保存。
检查 /api/v1/configs/terminal_servers 返回的配置中 url 字段是否仍为内部主机名，以及该字段是否被原样下发给前端。

解决步骤

先在后端侧确认连通性，排除网络与鉴权问题：docker exec open-webui curl -s http://open-terminal:8000/health，若返回 {"status":"ok"}，说明后端链路正常，问题集中在前端直连逻辑。
打开浏览器开发者工具 Network 面板，点击 “Verify Connection” 或打开 Open Terminal 面板，记录失败请求的完整 URL，确认是否直接指向 open-terminal:8000。
检查 /api/v1/configs/terminal_servers 的响应，确认 TERMINAL_SERVER_CONNECTIONS 中的 url 是否被前端直接使用。
如果确认是前端直连，可优先尝试临时把 Open Terminal 配置为浏览器与后端都能访问的地址（例如宿主 IP 加映射端口，并确保协议与 Open WebUI 页面一致），用于验证功能是否恢复；此方案未在 Issue 中被维护者确认。
同时关注 #23048、#28148、#22581 等关联 Issue，确认是否有版本修复或合并的 PR；若已修复，升级到对应版本后重新配置并验证。
如果升级后仍复现，保留浏览器 Network 记录、受限的 compose 配置和版本信息，在 Issue 中补充，便于维护者定位前端直连逻辑。

验证方法

重新打开 Open Terminal 面板或点击 “Verify Connection” 时，浏览器 Network 中不再出现直连 open-terminal:8000 的请求，只有指向 Open WebUI 自身域名/端口的 /api/v1/terminals/... 后端接口请求；面板能够正常列出目录并执行终端操作，同时 /health 的后端检查仍返回 {"status":"ok"}，即可认为问题已解决。