网页正常但 WebSocket 连接失败：握手、超时与代理检查

WebSocket 连接失败而 HTTPS 网页正常时，先分清开场握手没有成功，还是已建立的连接随后关闭。网页能打开，并不能证明它使用的实时端点、认证和长连接也都正常。

关键要点：

• 改网络设置前，记录真实端点和失败阶段。
• HTTP/1.1 握手的 101 表示协议升级，不代表应用任务成功。
• 认证拒绝与服务端错误需要分别处理。
• 检查端点和代理后，才对同一授权连接比较另一条路径。

步骤 1：WebSocket 连接失败发生在哪个阶段？

只检查你拥有或明确获准诊断的服务。请运营方提供无害测试频道和预期消息，不要打开别人的订阅或截取私人聊天。记录浏览器版本、系统、脱敏端点、连接时刻和可见错误；多个应用一起失败时，先走设备级排障流程。

复现前打开浏览器开发者工具，在网络面板选择实际 WebSocket 请求；Chrome 有 WS 筛选，但不同浏览器的标签可能不同。核对请求的主机与路径，而非只看网页地址。网页与实时连接可能属于不同域名，认证和路由要求也可能不同。

本文讨论的传统 HTTP/1.1 升级，有效开场响应使用 101 和对应握手头；其他状态表示这次交换尚未建立所需 WebSocket。采用其他标准传输的现代服务可能不同：已明确使用 HTTP/2 机制的部署，不能机械要求出现 101。［1］［4］

流程图把开场拒绝和建立后关闭分开。有响应时记录状态码，不要把浏览器笼统的控制台错误代替它。收到响应说明某个服务器或中间层已经回答，与始终没完成连接的请求是不同证据。

步骤 2：响应究竟证明了什么？

将端点与服务文档的 URL、协议对照。安全网页通常需要安全 WebSocket，不要改成不安全端点来消除报错。应用要求子协议时检查实际协商结果；RFC 定义了子协议协商及浏览器客户端的 Origin，这些属于应用判定，不是选国家的问题。［1］

观察结果	接着检查	安全动作
没有开场响应	名称解析、TLS、网络路径或浏览器限制	保留错误，核对目标端点
401 或明确认证拒绝	会话或 API 凭据	通过获准应用流程重新认证
403 且明确提示 Origin 或权限拒绝	应用访问策略	请运营方确认允许的来源和权限
404 或意外 HTML	路径错误或上游映射	向运营方核对实时请求路径
502 或其他上游错误	反向代理与上游服务	提供时间和脱敏请求编号
101 后连接关闭	已建立通道、定时器或应用行为	查看消息、关闭信息和空闲时长

403 并不自动等于 Origin 错误，要保留服务给出的解释。返回登录页面的 200 也不是升级成功。不要把 Cookie、Bearer token 贴进公开复现，使用运营方提供的测试账户或无敏感信息的本地示例。

普通命令行请求也失败时，另查浏览器与 curl 的请求路径差异。curl 下载成功不能证明握手、子协议和认证订阅正常。证书故障按证书警告检查流程处理，始终保留证书与主机名校验。

步骤 3：WebSocket 代理是否保留升级信息？

管理反向代理时，检查真正处理该实时路径的配置。HTTP/1.1 的 Upgrade、Connection 是逐跳头，NGINX 向上游建立隧道时需要显式转发。官方示例同时要求客户端提出升级、上游返回 101；复制默认配置前确认安装版本。［2］

把反向代理与浏览器前向代理、VPN 隧道分开，它们位于不同环节。换电脑出口不会改写运营方的 location、创建缺失上游或修正应用认证。

请负责人在原信任边界内，对照上游与公开代理的小型授权请求。不要为测试把内部后端暴露到公网，也不要绕过组织强制策略。不管理服务器时，交付端点、时刻、响应状态和连接阶段即可。

本文的受控本地示例实际连接 loopback WebSocket 服务，接收无害消息并记录关闭事件。截图是实时诊断报告，不是生产流量、应用登录页面或任何 VPN 的性能证据。

报告把开场成功、收到消息和关闭拆开，你的记录也应如此。本地回环示例没有互联网路径可供比较，不能证明现实故障由外部中间层造成。

如果这条 WebSocket 路由承载的是经 CDN 的自建代理，VLESS 的 WebSocket 与 XHTTP 教程列出了源站代理需要的 Upgrade 头，并说明如何证明流量确实经过边缘节点。

步骤 4：WebSocket 空闲超时是否可重复？

记录连接建立、最后收到消息和关闭的时间，只重复足以区分固定间隔与偶发中断的无害测试。活跃与空闲会话分开：沉默后断开，与持续传输中断开提供的证据不同。

NGINX 文档默认在 60 秒未收到上游数据后关闭代理连接。这个读取超时不表示每条连接恰好活一分钟，其他组件也可能有不同限值。固定间隔只是检查实际定时器的线索，不是 NGINX 的唯一指纹。［2］

WebSocket 协议 Ping／Pong 与应用 JSON 心跳不同。浏览器 JavaScript 没有可直接发送协议 Ping 的通用接口，应由服务器或合适的非浏览器客户端管理。添加消息或修改频率前，先向应用负责人确认预期心跳。［1］［3］

能取得关闭码与原因时一并保存；没有收到关闭帧的异常断开，无法定位哪一跳失败。正常关闭也可能是结束测试订阅等预期动作。实际使用单向 HTTP 事件流时，改走事件流交付检查。

步骤 5：获准的另一条路径会改变这个频道吗？

端点和权限正确但传输仍失败时，路径对照才有意义。先确认另一条路径获准使用，保留强制代理。若桌面客户端与浏览器表现不同，记录运行环境，不预设两者走同一路线。

在连接 AethoVPN 的受支持电脑上运行浏览器，从 App 当前可用位置选择本国或就近出口，开启全局模式，再打开同一无害频道。比较开场响应、首条预期消息和断开前持续时间，不只检查网页能否打开。

Windows 使用官方安装包，Debian／Ubuntu x64 使用 .deb；Mac 按官网向导取得客户端配置，需要 Pro 或 Premium。先核对当前公网出口，但仍以该 WebSocket 的记录为证据，IP 页面不能独自证明具体请求路径。

这一步改变本地路线，不提供订阅权限，也不修复 Origin 策略或上游超时。需要新账户进行获准对照时，可开始 3 天免费 Pro 试用，每人一次，从注册时起算。

按WebSocket 测试前的线路核对确认准备。如果两条路径都不改变症状，恢复原路线，让运营方查看服务端证据。明确权限拒绝后不继续换位置，也不把一次成功写成将来保证可用。

若直连与获准代理路径表现不同，而你确需覆盖这个本地应用，先弄清 TUN 与系统代理分别覆盖哪些应用再选择接管方式。这改变本地流量覆盖，不改变服务的升级配置或定时器。

步骤 6：恢复哪些设置，向谁升级求助？

恢复临时客户端设置，关闭测试订阅并停止诊断日志。保留精简记录：运行环境、脱敏主机与路径、握手状态、子协议、消息到达、空闲时长、关闭信息、路线及测试时间。不附 token、私人消息、账户标识或签名 URL。

API 测试工具有自己的代理和执行方式，另行失败时用Postman 运行位置与超时检查。不要拿有业务后果的消息当连通性探针，重试前先向应用负责人核实原操作状态。

应用拒绝交给应用负责人；可重复的代理时间问题交基础设施负责人；证书故障交信任配置管理员。重复尝试不再增加信息时停止。准确的失败阶段，比无关主机的大量截图更有用。

总结

• 分开开场交换、消息交付和最终关闭。
• 保留认证、Origin 策略与证书检查。
• 固定空闲间隔是定时器线索，不是某个中间层的确证。
• 只比较同一授权频道，随后恢复设置并移交未解决的问题。

常见问题

为什么网页能打开，WebSocket 却失败？

网页和 WebSocket 可能使用不同主机、路径与认证。HTML 加载成功既不能证明实时端点有权限，也不能证明长连接处理正常。

101 是否代表应用已经正常？

握手有效时，101 表示传统 HTTP/1.1 协议升级。还要收到预期应用消息并有可用会话，才能判断任务成功。

一分钟后断开是否证明代理超时？

固定间隔值得调查空闲定时器，但不能定位组件。先对照最后一次上游数据时间与实际部署限值，再归因于反向代理。

应该用浏览器 JavaScript 发送心跳吗？

只使用应用文档规定的心跳格式。JSON 消息不是协议 Ping，随意发送消息可能引发应用错误或非预期操作。

能关闭 Origin 检查来测试握手吗？

应保留 Origin 检查，让负责人授权正确测试来源。移除安全检查改变了测试系统，也可能暴露其他用户的会话。

VPN 能修复订阅被拒绝吗？

订阅拒绝需要服务方修正认证或权限。网络对照只对传输阶段有意义，不会为应用提供访问资格。

哪些资料适合发给支持人员？

提供脱敏端点、时间、失败阶段、状态和关闭信息。先移除 Cookie、token、私人消息、签名参数和个人或账户标识。

免责声明： 本文用于获准诊断，不保证服务可用。遵守当地法律、组织策略和服务访问规则。

来源：

1. RFC 6455 — The WebSocket Protocol — https://www.rfc-editor.org/rfc/rfc6455
2. NGINX — WebSocket proxying — https://nginx.org/en/docs/http/websocket.html
3. WHATWG — WebSockets — https://websockets.spec.whatwg.org/#ping-and-pong-frames
4. RFC 8441 — Bootstrapping WebSockets with HTTP/2 — https://www.rfc-editor.org/rfc/rfc8441

Sources checked 2026 年 10 月 7 日。

---

延伸阅读：

• 对照命令行和浏览器连接
• 区分事件交付与缓冲
• 核对 API 客户端的本地运行路径
• 重复任务前先验证连接