内网 AI 聊天一直转圈？Open WebUI 修复 HTTP 地址兼容问题

2026 年 11 月 8 日，Open WebUI 发布 v0.13.2，修复通过局域网或 Docker 的 HTTP 地址访问时，聊天页一直停在加载状态的问题。对把 AI 聊天服务放在家用服务器、NAS 或团队内网的用户，这次更新直接关系到另一台电脑和手机能否正常打开对话。沿着官方问题记录与源码，我们可以弄清故障发生在哪一步，以及升级后该怎样验证。版本发布说明

原创 AI 概念插画，以纸雕浏览器、加载环和局域网连接表现兼容性修复。

[配图建议：三个浏览器纸雕通过局域网节点连接，断开的加载环由折纸桥接通 + 米白、朱红与墨蓝的编辑纸艺插画。]

一、先对上症状，故障可能出在页面初始化

官方问题 #33919 的报告针对 v0.13.1。用户从其他设备访问类似 http://192.168.1.20:8080 的地址，登录后只能看到侧栏和转圈，既无法开始新对话，也打不开已有对话。浏览器控制台出现 crypto.randomUUID is not a function，同一环境的 v0.13.0 则能打开聊天页。原始问题记录

这组条件值得一起保留。版本、访问地址、协议和控制台报错，比一句“AI 没反应”更能定位问题。服务能显示登录页或部分工作区，只说明这些路径已经通了，进入聊天视图时还会执行另一段初始化逻辑。

修复提交修改了 chatViewStates.ts。创建聊天视图记录时，程序需要生成 instanceId，原来直接调用浏览器的 crypto.randomUUID()，现在改为从项目依赖 uuid 导入的 uuidv4()。聊天视图修复提交

页面进入可用状态之前，一个标识符生成步骤就可能中断流程。据此分析，如果症状与报错对应，排查应先沿前端调用栈确认入口。只有页面能正常提交消息后，模型连接、排队和推理耗时才进入后续检查范围。

v0.13.2 的发布时间为 UTC 11 月 8 日 11:53，即北京时间当晚 19:53。截至本文核查，这项修复仍在最近 24 小时范围内。

[配图建议：登录页、聊天视图初始化、消息提交和模型回答依次排列，在标识符生成处标出故障位置 + 简洁的工程流程图。]

二、localhost 能打开，为什么换个地址就卡住

设想你在服务器本机调试，一切顺利。随后把局域网 IP 发给同事，对方打开同一个服务，却只看到加载动画。这个场景中，应用版本和后端可能相同，浏览器看到的访问来源已经改变。

MDN 将 crypto.randomUUID() 标为需要安全上下文的 API。它用于生成随机的第四版 UUID，浏览器是否提供这个方法，还受当前页面上下文约束。randomUUID 接口文档

安全上下文规则对回环地址有特殊处理。http://localhost 和回环 IP 属于潜在可信来源，常规局域网 IP 的 HTTP 地址则不在这一类。下面是依据浏览器规则整理的常见顶层页面情形，具体环境可继续检查实际属性。安全上下文规则

这里的“本机”以浏览器所在设备为准。手机上的 localhost 指向手机自身。做对照检查时，应使用能实际到达服务的地址，记录每次从哪台设备打开。

内网可达与浏览器 API 可用，是两个需要分别检查的条件。前者可以通过登录页和网络请求观察，后者可以通过页面上下文与 JavaScript 调用确认。部署验收加上真实同事的访问路径，更容易发现开发机测试遗漏的条件。

[配图建议：同一服务连接到本机回环路径和另一设备的局域网路径，各自标明浏览器上下文 + 双路径网络示意图。]

三、修复还覆盖评论和 Markdown，边界要看具体调用

这次同类修改也出现在评论组件和 Markdown 文件编辑器。评论编辑器为临时评论分配标识符，提交成功后生成下一条标识符；Markdown 编辑器为渲染块编辑组件创建 ID。相关代码均改用了 uuidv4()。编辑器与评论修复提交

对使用 Mermaid 图或提示块的团队，这扩展了验收范围。一条聊天消息能发出去之后，还可以打开带渲染块的 Markdown，进入编辑并保存。日常使用评论协作的用户，则检查新建、回复和编辑这几条实际操作。

从工程角度看，值得借鉴的是 按调用位置检查环境依赖。同一个 API 可能分散在聊天状态、编辑器挂载、临时草稿等路径。只修最显眼的聊天入口，其他功能仍可能遇到相同条件。这个结论来自对本次多个修改位置的分析，适用于自己维护 AI 前端时设计回归检查。

发布说明支持的结论范围，是列出的 UUID 相关路径恢复兼容。文件上传、模型服务连接、插件行为等项目，应按各自功能继续验证。HTTP 的传输方式也需单独评估，跨设备传递聊天内容时，团队仍可按自己的部署要求配置 HTTPS。

[配图建议：聊天视图、评论草稿和 Markdown 渲染块三个位置各有一个标识符节点，统一接入兼容调用 + 源码关系图风格。]

四、升级后，回到出问题的那台设备验收

如果正在使用 v0.13.1，且地址和报错对应，可以把 v0.13.2 作为明确的修复目标。官方更新指南建议共享实例固定版本，升级前保存数据并阅读版本说明，更新后刷新浏览器资源。现有数据卷、环境变量和接入配置也应一并记录，便于核对升级后的实例。官方更新指南

第一次验证可以这样安排。

1. 记录原始条件。保存版本、设备、完整访问地址和控制台报错，选一条能够打开验证的历史对话。
2. 按原部署方式升级。Docker 部署选择对应的 v0.13.2 镜像变体，保留原来的数据挂载和必要配置，启动后确认实际版本。
3. 刷新前端资源。重新加载页面，再从最初出问题的设备和 HTTP 地址进入，分别检查新建与历史对话。
4. 发送一条可核对的请求。观察消息能否提交、是否收到完整回答，再按日常用法补测评论和 Markdown 编辑。

要核对浏览器条件，可以在自己部署页面的开发者工具中读取下面两个值。操作仅用于观察属性。

window.isSecureContext
typeof window.crypto?.randomUUID

在普通局域网 HTTP 页面上，可能看到 false 和 "undefined"。升级后的应用应能通过修复过的路径正常工作。记录页面表现和实际版本，比只等待这两个值变化更贴近本次验收目标。

如果升级后仍转圈，保留新的报错、调用位置和网络请求状态，继续缩小问题范围。对于自己维护的前端，可以把“另一设备通过局域网 HTTP 打开聊天”加入发布前检查，并为初始化失败显示可定位的提示。

[配图建议：原设备、原地址与升级后版本放入同一验收单，旁边列新对话、历史对话和编辑操作 + 清晰的测试笔记插画。]

今天先核对一次真实访问地址

这次更新最值得内网自托管用户关注，尤其是刚升级到 v0.13.1、遇到聊天页转圈的人。今天先从发生故障的设备打开服务，记下完整地址与第一条控制台错误，再决定是否采用本次修复。

已经正常使用的团队，也可以补上一条跨设备验收。你的 AI 工具最近一次测试，是只在部署机器上打开，还是包含了同事实际使用的访问路径？

[配图建议：一张验收单写着设备、地址、版本和结果，连接到恢复使用的聊天窗口 + 与封面一致的纸雕收尾插画。]

资料核查于 2026 年 11 月 9 日，Asia/Shanghai。本文依据官方发布说明、问题记录、源码与浏览器文档分析，本站未安装该版本实测。场景与验收方案由作者编写，封面为原创 AI 概念图。