Typebot.io 项目中端口号在Viewer URL中被忽略的问题分析

问题背景

在Typebot.io项目的实际部署中，当Viewer服务运行在非标准端口（非443端口）时，系统会出现端口号被忽略的问题。具体表现为：虽然环境变量中正确配置了包含端口号的URL地址，但在实际发起API请求时，系统会自动去除端口号，导致请求失败。

问题现象

当开发者在环境变量中设置如下配置时：

NEXT_PUBLIC_VIEWER_URL=https://dev.example.com:10006
NEXT_PUBLIC_CHAT_API_URL=https://dev.example.com:10006

系统在发起startChat API调用时，会自动去除端口号，变成：

https://dev.example.com/api/v1/typebots/my-typebot-bpkjj7k/startChat

技术分析

根本原因

问题的根源在于Viewer组件的URL构建逻辑中，没有正确处理端口号信息。在构建API请求URL时，系统仅使用了协议、主机名和路径，而忽略了端口号部分。

请求头处理机制

在反向代理环境中，请求头对于端口信息的处理存在多种标准：

1. 传统转发头：使用分离的转发主机和转发端口头
2. 标准转发头：采用统一格式包含所有转发信息
3. 主机头：通常包含端口信息

当前实现仅考虑了转发主机头，而没有综合处理其他可能的头信息。

解决方案建议

短期修复方案

可以直接修改URL构建逻辑，显式添加端口号：

url: `${protocol}://${forwardedHost ?? host}:10006${pathname}`

长期完善方案

建议实现一个完整的请求头解析逻辑，按照以下优先级处理：

1. 首先检查标准转发头
2. 然后检查传统转发系列头
3. 最后回退到主机头

具体处理流程应包括：

• 解析转发头中的host、port、proto等信息
• 如果转发头不存在，则检查转发主机头
• 端口号应从多个可能的位置获取，包括：
  • 转发头中的host部分
  • 转发端口头
  • 主机头中的端口部分
• 最终回退到协议默认端口

部署建议

对于使用Nginx作为反向代理的用户，建议配置如下头信息：

proxy_set_header Host $host:$server_port;
proxy_set_header 转发主机 $host;
proxy_set_header 转发端口 $server_port;

这样可以确保后端服务能够获取到完整的端口信息。

总结

Typebot.io项目在非标准端口部署时出现的URL构建问题，反映了Web应用中正确处理反向代理头信息的重要性。开发者应当遵循最新的HTTP标准，同时保持对传统头信息的兼容性，以确保应用在各种部署环境下都能正常工作。