Jackett 报 429 Rate limited 怎么办TooManyRequestsException 排查与修复指南【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett你是否在日志里见过这样的报错站点返回 429Jackett 打出Rate limited搜索结果直接空白Jackett 是给 Sonarr、Radarr 这类客户端提供 torrent 追踪器统一搜索接口的工具。当查询打得太密追踪器会拒绝请求。读完本文你能判断自己是否中了这个病知道该等多久以及怎么让它不再反复出现。快速自检确认是不是频率限制 对照下面 5 点命中 3 个以上基本可以确诊日志或 API 响应里出现Rate limitedHTTP 状态码是429Torznab 错误码 900。只有部分索引器indexer出错其余站点查询正常。报错是间歇性的不做任何改动过几分钟再搜就成功了。Jackett 服务本身运行正常没有进程崩溃或整体挂死。接口返回头里带Retry-After值是一个秒数——这是站点告诉你等多久再来。对应源码在 TooManyRequestsException.cs它就是一个普通异常外加一个RetryAfter等待时长属性会从响应头里自动解析等待时间。根源剖析429 是怎么被处理掉的追踪器tracker为了保护服务器都会限制单位时间内的查询次数。Jackett 每次搜索都要替客户端去请求这些站点查询多了就会撞上限制。关键在于 Jackett不会在一次请求里死等、反复重试。它的策略是记一笔账先退避具体链路是这样的索引器收到 429 就抛出TooManyRequestsException比如 FileList.cs 和 AvistazTracker.cs 里都有这个判断。BaseIndexer.cs 第 393 行捕获它把RetryAfter秒数记成该索引器的冷却截止时间冷却期内这个索引器被视为不健康Jackett 不会再去打扰它。最终 ResultsController.cs 把错误透传给客户端响应头写上Retry-After站点没给就默认 1 分钟HTTP 状态返回 429。所以结论先行这个错误是设计好的退避信号不是故障。Jackett 自己会等你只需要别让重试的人太心急。分步修复从最省事的开始第 1 步看 Retry-After 的秒数等完再查成本最低的一步。打开返回的响应头看Retry-After是多少秒等到时间过了再发一次查询。做完应该看到同一个索引器搜索成功日志里不再出现Rate limited。第 2 步在 Dashboard 和日志里定位是哪个索引器打开 Jackett 的 Dashboard 页面看索引器列表。进入冷却期的索引器状态会显示为不健康红/黄一眼就能对上名字。再翻日志搜Rate limited每次出现都对应一个索引器。日志会告诉你限流发生在哪个站点、什么时间。做完应该看到你明确知道是哪一两个站点在被限而不是全局故障。第 3 步压低客户端的搜索频率查询的来源通常是 Sonarr、Radarr、Lidarr 的定时同步任务。三个客户端的定时任务挤在同一分钟等于瞬间三倍请求量。做法把各客户端的同步/搜索间隔调大并且错开它们的执行时间点比如一个每 15 分钟、一个每 30 分钟起始时间不同。做完应该看到日志里 429 的出现频率明显下降最好几天不出现一次。第 4 步对反复被限的索引器单独处理如果某个站点持续触发 429说明它限制严格或你的使用量确实超了。两个选择减少对该站点的依赖优先使用不限流的站点在 Jackett 里删除该索引器配置后重新添加顺带检查 Cookie 或 API 密钥是否过期配置失效有时也会引发异常请求。做完应该看到该站点不再出现在限流日志里。调优与加固让限流不再找你麻烦利用查询缓存Jackett 支持缓存查询结果相同搜索词在缓存有效期内直接返回不会重复打站点。客户端查询时尽量走缓存重复搜索几乎零成本。分散请求时间多客户端、多索引器时把请求在时间轴上摊开避免瞬时并发尖峰。监控限流趋势定期在日志里统计Rate limited出现次数行内命令grep -c Rate limited jackett.log。趋势上涨就该回头查客户端配置了。进阶改退避策略如果你是自托管且熟悉 C#RetryAfter的解析和冷却时长都在前面提到的源码文件里可以扩展成指数退避等策略。延伸与验证下次再看到 429你已经知道该等多久、该查谁了。相关源码与文档README.mdTooManyRequestsException.csBaseIndexer.csResultsController.cs索引器定义目录【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jackett 报 429 Rate limited 怎么办？TooManyRequestsException 排查与修复指南
Jackett 报 429 Rate limited 怎么办TooManyRequestsException 排查与修复指南【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett你是否在日志里见过这样的报错站点返回 429Jackett 打出Rate limited搜索结果直接空白Jackett 是给 Sonarr、Radarr 这类客户端提供 torrent 追踪器统一搜索接口的工具。当查询打得太密追踪器会拒绝请求。读完本文你能判断自己是否中了这个病知道该等多久以及怎么让它不再反复出现。快速自检确认是不是频率限制 对照下面 5 点命中 3 个以上基本可以确诊日志或 API 响应里出现Rate limitedHTTP 状态码是429Torznab 错误码 900。只有部分索引器indexer出错其余站点查询正常。报错是间歇性的不做任何改动过几分钟再搜就成功了。Jackett 服务本身运行正常没有进程崩溃或整体挂死。接口返回头里带Retry-After值是一个秒数——这是站点告诉你等多久再来。对应源码在 TooManyRequestsException.cs它就是一个普通异常外加一个RetryAfter等待时长属性会从响应头里自动解析等待时间。根源剖析429 是怎么被处理掉的追踪器tracker为了保护服务器都会限制单位时间内的查询次数。Jackett 每次搜索都要替客户端去请求这些站点查询多了就会撞上限制。关键在于 Jackett不会在一次请求里死等、反复重试。它的策略是记一笔账先退避具体链路是这样的索引器收到 429 就抛出TooManyRequestsException比如 FileList.cs 和 AvistazTracker.cs 里都有这个判断。BaseIndexer.cs 第 393 行捕获它把RetryAfter秒数记成该索引器的冷却截止时间冷却期内这个索引器被视为不健康Jackett 不会再去打扰它。最终 ResultsController.cs 把错误透传给客户端响应头写上Retry-After站点没给就默认 1 分钟HTTP 状态返回 429。所以结论先行这个错误是设计好的退避信号不是故障。Jackett 自己会等你只需要别让重试的人太心急。分步修复从最省事的开始第 1 步看 Retry-After 的秒数等完再查成本最低的一步。打开返回的响应头看Retry-After是多少秒等到时间过了再发一次查询。做完应该看到同一个索引器搜索成功日志里不再出现Rate limited。第 2 步在 Dashboard 和日志里定位是哪个索引器打开 Jackett 的 Dashboard 页面看索引器列表。进入冷却期的索引器状态会显示为不健康红/黄一眼就能对上名字。再翻日志搜Rate limited每次出现都对应一个索引器。日志会告诉你限流发生在哪个站点、什么时间。做完应该看到你明确知道是哪一两个站点在被限而不是全局故障。第 3 步压低客户端的搜索频率查询的来源通常是 Sonarr、Radarr、Lidarr 的定时同步任务。三个客户端的定时任务挤在同一分钟等于瞬间三倍请求量。做法把各客户端的同步/搜索间隔调大并且错开它们的执行时间点比如一个每 15 分钟、一个每 30 分钟起始时间不同。做完应该看到日志里 429 的出现频率明显下降最好几天不出现一次。第 4 步对反复被限的索引器单独处理如果某个站点持续触发 429说明它限制严格或你的使用量确实超了。两个选择减少对该站点的依赖优先使用不限流的站点在 Jackett 里删除该索引器配置后重新添加顺带检查 Cookie 或 API 密钥是否过期配置失效有时也会引发异常请求。做完应该看到该站点不再出现在限流日志里。调优与加固让限流不再找你麻烦利用查询缓存Jackett 支持缓存查询结果相同搜索词在缓存有效期内直接返回不会重复打站点。客户端查询时尽量走缓存重复搜索几乎零成本。分散请求时间多客户端、多索引器时把请求在时间轴上摊开避免瞬时并发尖峰。监控限流趋势定期在日志里统计Rate limited出现次数行内命令grep -c Rate limited jackett.log。趋势上涨就该回头查客户端配置了。进阶改退避策略如果你是自托管且熟悉 C#RetryAfter的解析和冷却时长都在前面提到的源码文件里可以扩展成指数退避等策略。延伸与验证下次再看到 429你已经知道该等多久、该查谁了。相关源码与文档README.mdTooManyRequestsException.csBaseIndexer.csResultsController.cs索引器定义目录【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考