Web UI 首页能正常显示，实时状态却不更新，控制按钮也可能提示连接中断。先重装依赖、换 GPU 或重建实例，往往没有触及问题：

首页加载和 WebSocket 握手是两次不同的网络交互

，不能推出 WebSocket 已经建立；看到 

，也不能推出应用后续消息已经处理成功。

这类故障最好先留下一次失败请求的证据，再按

浏览器发出的连接地址 → 反向代理的升级与路径转发 → 上游应用的握手条件

定位。以下检查面向已获授权的开发或测试环境，不涉及如何对外开放服务。

从浏览器记录开始：请求到底连向了哪里？

打开开发者工具的 Network（网络）面板，保留请求记录后刷新页面。分别找到首页文档请求和 WebSocket 请求，记下 

Request URL、状态、发起来源及报错

。如果没有 WebSocket 请求，还要查看前端 Console 是否有脚本错误，以及应用是否真的进入需要实时连接的操作流程。

判断时先比较页面地址与 WebSocket 目标。例如，下面是

，不是云端 GPU 实例。此时先检查应用如何生成 WebSocket URL，以及代理传入的 Host 和路径前缀，不能只靠修改 Nginx 升级头解决地址本身错误的问题。公开的 

 就记录了反代访问下，由该应用自己的 Host 解析逻辑导致 WebSocket 回退至 

 的情况；它是具体应用案例，不能推定其他 Web UI 具有同样的根因。

如果 WS 地址的主机、协议与路径符合当前应用的预期，才继续检查这条请求在反向代理和上游之间发生了什么。不要猜所有应用都使用 

，也不要把浏览器页面显示成功当作实时连接成功的证据。

请求地址没错，再核代理有没有完成升级

WebSocket 握手在常见的 HTTP/1.1 升级场景中需要客户端发送 

，代理将必要的逐跳头传给上游，并由上游接受后返回 

 不会像普通端到端请求头那样自动转交，反代配置必须显式处理。

因此，检查不能停留在“配置文件里写过代理”。先用 

 确认版本，再核对实际命中的 

 路径改写、上游目标及升级头。

需要显式指定向上游使用 HTTP/1.1；自 1.29.7 起，HTTP/1.1 已是反向代理的默认协议版本，但升级头仍需显式处理。本文实验使用 NGINX 1.26.3，对应的关键片段是：

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

，必须位于实际命中的代理配置中，不是可直接覆盖生产环境的完整配置。Host、路径前缀和认证要求仍应以目标应用为准；版本判断来自 

对于项目实例上采用文档化多服务路径转发的情况，云端 GPU 算力平台

提供了一个可核对的具体位置：其 ComfyUI 子路径示例除了设置 

 等字段。沿用该类转发方式的开发者，可将

与示例、目标应用说明对照，明确该查哪一段；示例本身不能证明任意应用都能完成握手，更不代表平台替应用处理了 Host 或身份校验。

 可以检查配置语法，但它不会发出 WebSocket 握手。若还要核对运行时采用的配置，应检查对应实例真正加载的文件和路径；检查配置输出时注意隐藏可能包含的凭据，不要为排查直接修改线上服务。

用一次请求的三段证据决定下一步

把浏览器请求、代理访问或错误记录、应用端日志放在同一时间窗口内比对。重点不是统计出现了几个 

请求走到了哪里、由谁返回响应

是：如果 WS URL 已经指向错误主机，先停在地址生成层；如果地址正确而未完成升级，优先查看代理与上游的握手证据；如果握手已返回 

，就不应继续把“有没有传 Upgrade 头”当作唯一问题。此时还应留意断开的时间规律：NGINX 默认情况下，若代理上游在 

，连接可能被关闭；实际是否超时要看当前 

 和应用心跳，而非仅凭“约一分钟断线”判定。对于需要登录或特定 Origin、子协议的应用，仍须依据应用自身规则解释拒绝结果。

为了检验这套判断是否只停留在术语层面，本次在

搭建了合成 HTTP/WebSocket 上游服务（Node.js v22.16.0）和 NGINX 1.26.3。上游普通 

，符合条件的 WebSocket 升级请求返回 

，另一支故意省略这两项。端口由测试脚本随机选择并且只监听 

；没有真实 GPU、ComfyUI 或算家云实例参与。

 在 Linux 环境准备 Node.js、NGINX、Python 3 和 curl，将本次合成上游、双分支配置与 

，再对上游及两个代理入口分别发送普通首页请求和有效的 HTTP/1.1 WebSocket 升级请求。升级请求的关键字段如下；其中 

GET /demo/socket HTTP/1.1
Host: 127.0.0.1:PORT
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

 替换为相应的本地测试入口端口；脚本还使用 

 对两个代理分支交叉核对。实验的

唯一代理配置差异是是否转发升级头

，不是两个服务采用了不同的业务代码。含两个 

 无法区分代理升级头是否正确转发，语法检查通过也不能代替 WebSocket 握手验证。

 是本次合成上游对非升级请求刻意规定的响应，

真实应用漏传升级头时必然出现的状态码。要复现这组具体状态，需要使用相同的合成上游，不能把结果套用到任意线上应用。

实验只验证 HTTP/1.1 升级与代理转发的条件差异，没有验证 WebSocket 消息帧、业务操作或生产环境稳定性。对真实问题，最终仍要回到浏览器实际 WS URL、该请求的代理/上游证据和应用交互结果：

能定位握手失败发生在哪一段，才有依据决定修 URL、修代理配置，还是检查应用自身条件。

**资料来源：**原始问题来自 Paseo 公开 issue；协议与超时条件依据 NGINX 官方文档；算家云帮助文档仅作为多服务路径转发的配置核查依据。

Web UI 首页能正常显示，实时状态却不更新，控制按钮也可能提示连接中断。先重装依赖、换 GPU 或重建实例，往往没有触及问题：首页加载和 WebSocket 握手是两次不同的网络交互。HTTP 首页返回 200，不能推出 WebSocket 已经建立；看到 101 Switching Protocols，也不能推出应用后续消息已经处理成功。

页面能打开，WebSocket 却断了：反向代理要先核哪三段证据？

Web UI 首页能正常显示，却不代表 WebSocket 已连通。本文从浏览器连接地址、Nginx 协议升级与应用端握手三个环节建立排查流程，通过本地 Nginx 对照实验解释相同的 HTTP 200 为什么可能对应不同的 WebSocket 结果。

网络与通信

运维

开发工具

首页HTTP 200不代表WebSocket连接成功，需分别检查浏览器WS请求URL、代理升级头转发及上游握手条件。先对比页面地址与WS目标，再核对Nginx的Upgrade/Connection配置，最后通过101状态码验证完整握手。

4核4G3M云服务器 新用户低至38元/年！

腾讯云双十一大促

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

页面能打开，WebSocket 却断了：反向代理要先核哪三段证据？

页面能打开，WebSocket 却断了：反向代理要先核哪三段证据？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐