Biliup项目中的B站录制403问题分析与解决方案

问题背景

Biliup是一款流行的开源直播录制工具，近期在版本升级过程中出现了一个与B站录制相关的403错误问题。该问题表现为：当用户同时录制虎牙和B站直播时，B站的开播检测接口会返回403 Forbidden错误，导致后续无法正常进行B站直播的检测和录制。

问题现象

用户反馈在从v0.4.78升级至v0.4.81版本后，发现录制B站直播间会出现403错误，且后续无法正常进行B站开播检测。重启biliup后问题暂时解决，但会反复出现。通过日志分析发现，问题在添加虎牙直播间并开始录制后稳定触发。

技术分析

HTTP客户端机制

Biliup项目中使用的是全局httpx客户端，这意味着所有的HTTP请求共享同一个客户端实例。在httpx客户端中，请求头(header)的处理方式是"update"而非"overwrite"，这导致上一次请求的header会被保留并影响后续请求。

虎牙直播的特殊处理

在虎牙直播的插件实现中，开发者添加了referer头信息以通过平台的风控检测。这个referer头会被保留在全局客户端中，影响后续的所有请求。

B站接口的变化

在v0.4.79版本中，Bilibili插件移除了referer头项，同时添加了短链支持。这一变更使得当虎牙的referer头被带到B站接口请求时，B站服务器会拒绝该请求，返回403错误。

问题根源

问题的根本原因在于：

1. 全局httpx客户端共享请求头信息
2. 虎牙插件添加的referer头被保留
3. 这个保留的referer头被带到B站接口请求中
4. B站服务器检测到异常的referer头后拒绝请求

临时解决方案

在问题修复前，用户可以采取以下临时解决方案：

1. 在多个目录下分别启动Biliup实例
2. 分平台添加录制主播（即不同平台的主播在不同实例中录制）

长期解决方案

开发团队已经意识到这个问题，并计划在下一个版本中修复。可能的修复方向包括：

1. 为不同平台的请求使用独立的客户端实例
2. 在每次请求前清除不必要的头信息
3. 实现更精细化的头信息管理机制

技术启示

这个问题给我们带来了一些技术上的启示：

1. 全局状态在复杂应用中的管理需要谨慎
2. HTTP客户端的头信息处理方式对应用行为有重要影响
3. 不同平台API的风控机制差异需要考虑
4. 版本升级时需要注意各组件间的交互影响

总结

Biliup项目中出现的这个403问题是一个典型的多平台集成和HTTP客户端管理问题。通过分析这个问题，我们不仅理解了其技术原因，也看到了在开发类似工具时需要考虑的各种因素。开发团队已经着手解决这个问题，用户也可以采取临时方案规避影响。这类问题的解决将进一步提升Biliup的稳定性和用户体验。