Hoppscotch自托管服务中GraphQL请求路径错误的解决方案

问题背景

在使用Docker Compose自托管Hoppscotch平台时，开发者遇到了一个典型的GraphQL请求路径配置问题。当应用部署在多子域名架构下时，前端应用在刷新后会错误地向BASE_URL而非配置的BACKEND_GQL_URL发送GraphQL请求。

技术细节分析

该问题出现在以下典型的三层架构部署中：

1. 主应用部署在sandbox.domain.com
2. 管理后台部署在admin.sandbox.domain.com
3. GraphQL后端服务部署在api.sandbox.domain.com

环境变量配置中明确指定了：

• VITE_BASE_URL为主应用地址
• VITE_BACKEND_GQL_URL为后端GraphQL服务地址

问题现象

首次登录时一切正常，但普通刷新后出现异常：

1. 用户认证信息（Me查询）请求被错误发送到主域名下的/graphql端点
2. 团队信息等用户相关数据无法加载
3. 硬刷新（清除缓存）可暂时解决问题

根本原因

经过深入分析，问题根源在于：

1. 服务工作者(Service Worker)缓存了初始配置
2. 应用可能在LocalStorage中存储了初始的GraphQL端点
3. 当后端配置变更时，缓存未正确更新

解决方案

临时解决方案

1. 手动清除浏览器存储数据（LocalStorage、Service Worker缓存）
2. 使用硬刷新（Ctrl+Shift+R或Cmd+Shift+R）

长期解决方案

1. 确保部署时环境变量配置正确且完整
2. 实现配置变更时的缓存清除机制
3. 在应用启动时验证后端端点可用性

最佳实践建议

对于自托管Hoppscotch的用户，建议：

1. 首次部署前仔细规划域名结构
2. 确保所有相关子域名都包含在WHITELISTED_ORIGINS中
3. 配置变更后执行全面的缓存清除
4. 考虑实现自动化的配置版本检查机制

技术启示

这个问题揭示了现代Web应用中常见的配置管理挑战，特别是在使用Service Worker和客户端存储时。开发者在设计类似系统时应考虑：

1. 配置的版本控制
2. 缓存失效策略
3. 配置变更的传播机制

通过正确处理这些方面，可以避免类似的生产环境问题。