解决浏览器 WebSocket 认证难题：豆包语音识别的代理方案实践
原文中文，约8600字，阅读约需21分钟。
📝
内容提要
本文探讨了如何通过后端代理解决浏览器 WebSocket API 不支持自定义 HTTP header 的问题，特别是在豆包语音识别服务中。采用后端代理方案后，成功实现了安全传递认证信息，并在 HagiCode 项目中验证了其可行性和稳定性。
🔎
延伸解读
WebSocket 认证的挑战
浏览器的 WebSocket API 不支持自定义 HTTP header，这对需要认证的语音识别服务构成了重大挑战。开发者必须寻找替代方案，以确保认证信息的安全传递，避免将敏感凭证暴露在前端。
后端代理的优势
通过后端代理方案，开发者能够安全地传递认证信息，避免直接在前端处理敏感数据。这种方法不仅提高了安全性，还简化了实现过程，适合需要高效双向通信的应用场景。
部署与监控的重要性
在生产环境中，建议使用 Docker 部署代理服务，以便于管理和扩展。同时，定期监控连接状态和错误处理是确保系统稳定性的关键，能够及时发现并解决潜在问题。
❓
Q&A
为什么浏览器 WebSocket API 不支持自定义 HTTP header 会影响语音识别服务？
因为语音识别服务需要通过 HTTP header 传递认证信息，而浏览器 WebSocket API 只能在 URL 中传递参数，无法设置 headers。
后端代理方案是如何解决 WebSocket 认证问题的？
后端代理方案通过在后端实现 WebSocket 代理，安全地传递认证信息，避免将凭证暴露在前端。
HagiCode 项目中如何验证后端代理方案的可行性？
在 HagiCode 项目中，后端代理方案最初在 playground 试验场验证，确认稳定后才应用到生产环境。
使用原生 WebSocket 的优缺点是什么？
原生 WebSocket 轻量、简单，适合简单场景，但需要手动处理连接管理。
如何确保敏感凭证的安全性？
敏感凭证存储在后端配置文件中，避免暴露给前端，并支持多环境配置。
在部署代理服务时有哪些建议？
建议使用 Docker 部署代理服务，方便扩展和管理，同时实现负载均衡和健康检查。
🏷️
