Zrok项目中WebSocket与插页式页面的兼容性问题解析

背景概述

Zrok作为一款开源的网络工具，近期在生产环境版本中引入了插页式页面（interstitial pages）功能。这一变化对WebSocket协议的兼容性产生了显著影响，特别是在浏览器客户端场景下。本文将深入分析该问题的技术原理及解决方案。

问题现象

开发者发现通过Zrok代理的WebSocket服务出现连接异常：

1. 浏览器端JavaScript客户端连接失败（Firefox报错ns_error_websocket_connection_refused）
2. 非浏览器客户端（如Python）仍可正常连接
3. 本地直连场景下一切正常

技术原理分析

插页式页面的工作机制

Zrok生产环境为免费账户默认启用了插页式页面功能，主要作用于：

• 所有通过浏览器发起的HTTP/HTTPS请求
• 基于安全考虑防止网络滥用行为

触发条件：

• User-Agent以"Mozilla/5.0"开头（浏览器标准标识）
• 未携带特殊跳过标识头

WebSocket协议的特殊性

WebSocket握手阶段仍属于HTTP协议范畴，但后续升级为持久化连接。插页式页面的介入会导致：

1. 握手过程被重定向到插页页面
2. 协议升级请求无法正常完成
3. 浏览器安全策略阻止非常规握手过程

解决方案对比

可行方案

1. 修改请求头信息

   • 添加skip_zrok_interstitial自定义头
   • 修改User-Agent不以"Mozilla/5.0"开头 适用场景：可控制客户端的非浏览器环境

2. 服务架构调整

   • 使用私有分享（private share）替代公开分享
   • 升级到付费账户禁用插页功能
   • 自建Zrok前端服务

不可行方案

• 浏览器原生WebSocket API无法自定义User-Agent
• 标准浏览器环境无法添加特殊跳过头

最佳实践建议

对于需要浏览器WebSocket连接的场景，推荐采用：

1. 开发环境：使用私有分享模式
2. 生产环境：考虑付费账户或自建服务
3. 混合架构：关键服务接口使用私有分享，公开内容保留插页保护

技术启示

该案例典型展示了安全功能与协议兼容性的平衡问题。开发者在设计类似系统时需要注意：

• 协议升级类请求（如WebSocket）的特殊处理
• 安全策略的粒度控制
• 客户端能力的差异性考量

通过理解Zrok的这一设计选择，开发者可以更合理地规划自己的网络架构，在安全性和功能性之间取得平衡。