B站视频数据获取失败：先看清楚错误代码，然后对症下药

B站视频数据获取失败往往就会猜是接口出问题了，于是就开始盲目地重试、更换IP地址、修改代码，折腾了半天还是没有解决问题。

其实B站数据获取失败的时候会有很清晰的错误码体系，不同的码表示的是完全不同的原因。首先弄明白错误码的意思，这样查找问题的速度就会快很多。

一、一共三种常见的错误码，分别是哪一种

B站API的公共错误码文档中列出了所有返回码的意义，在此与数据获取失败相关的有以下三个：

风控校验失败（-352）

这是开发者最常碰到的一个错误码，提示的信息一般为“风控校验失败”。这表示请求已经被B站的安全系统判定为可疑行为了，但是还没有达到完全封杀的地步。

触发的原因大都是因为请求头不全、User-Agent不像正常的浏览器、或者是短时间内请求次数过多。在响应中一般都会有一个v_voucher字段，这是风控系统产生的唯一标识用来追踪异常请求。

-412（请求被阻止）

此码的意思要比-352严重得多，表示客户端IP已经被服务端风控系统所阻断。-352和-412的区别就是，-352是对一次请求行为发出的“警告”，而-412是对一个IP进行“封锁”。如果服务器的IP被标记了的话，那么所有的请求都会被拦截掉，只有等到IP解封或者换一个新的才行。

-403（访问权限不足）

该码与风控没有关系，主要是因为认证信息不全或者权限设置错误造成的。比如说没有带上正确的登录状态Cookie、SessionData已经失效或者是调用了一些必须要有特殊权限才能使用的API但是账号并没有相应的权限。

二、第二步就是分层次地进行排查：客户端、账号以及平台

拿到错误码之后，按由外向内的顺序去查找，可以最快地找到问题所在。

第一部分是客户端部分。

验证请求头是否齐全，比如User-Agent是否使用了真实的浏览器模拟、Referer是否指向bilibili.com、Accept-Language等字段有没有缺少的情况。

很多-352错误都是由于请求头不够复杂而被风控系统识别为脚本请求。另外还要注意请求的频率，在短时间内连续发出十几条请求的话，触发风控就基本可以确定了。在请求之间要留有一定的随机时间间隔，单个域名的请求间隔不得少于1秒。

第二步就是账号这边了。

保证SESSDATA、bili_jct、buvid3等重要Cookies的有效性和不超时。过期的cookie不但不能得到数据，而且会加大被风控的风险。

如果是使用了第三方API库的话，则要查看该库的版本是不是最新的——因为B站接口更新很快，老版本的库可能会继续调用已经被下线的端点，从而返回-400或者-403这样的错误码。

第三步就是平台这边了。

经过上述检查仍不能排除故障，则有可能是B站服务端出现了暂时性的故障，或者你的服务器IP被加入到风控名单里了。可以用其他的IP或者通过代理来避开它，看看能不能恢复正常。

如果是偶尔出现的失败情况，在等待一段时间之后再重新尝试一般都会得到自动恢复。

三、三条可以减少的高频次场景

场景一：批量获取用户的视频列表的时候出现中途失败的情况。

这就是请求频率的问题。最初的请求是正常的，但是拉取到第十个左右的时候突然返回了-352，这表明请求频率已经超过了滑动窗口的检测范围。

解决的方法就是在每次请求之间增加一个延迟，并且实现错误重试机制，在遇到-352的时候暂停一段时间后再继续。

场景二：创作者中心页面的数据加载不成功。

如果是通过浏览器访问B站创作中心并且出现页面错误的话，那么首先应该检查一下浏览器插件是否存在干扰的情况。有用户反映ChatHub插件对URL的过度匹配会使得创作中心页面返回403错误。

可以打开无痕模式或者关闭插件之后再重新访问网站来确定是不是因为插件的原因导致的问题。

场景三：本地开发一切正常，但是部署到服务器之后就出现了问题。

这是最容易被人忽视的一个地方。本地IP一般为住宅IP，风控容忍度比较高；而服务器IP（特别是云服务商的IP段）则比较容易被标示为可疑。

B站搜索接口对于服务器IP有着严格的风险控制策略，直接用yt-dlp调用搜索端点很容易得到412。在这种情形下要换掉请求的方式或者使用合法的数据服务去取得数据。

小结

B站的数据获取不成功，错误码就是诊断开始的地方。**-352查询请求头和频率，-412查询IP和代理，-403查询认证和权限。**拿到代码后按照客户端、账号、平台三个层次进行排查，要比盲目重试好很多。

接口变了，风控也在更新，但是排查的思路并没有改变：首先确定问题是出现在哪一层上，然后针对该层进行处理。