企业官网建设流程全解析

Jackett 越来越卡？这份种子索引器聚合器性能优化指南帮你快速提速

【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett

Jackett 用着用着，搜索从 2 秒出结果变成卡 10 秒、十几秒，内存还越占越高。Jackett 是一个种子索引器聚合器，给各类 torrent tracker 提供统一的 Torznab API。这篇 Jackett 性能优化指南带你从诊断到调参，把速度找回来。

图：Jackett 配置界面中的性能相关设置区域，Cache TTL (seconds) 显示 2100，Cache max results per indexer 显示 1000

🔍 为什么 Jackett 会越用越卡

本段讲清楚性能下降的三个来源，让你后面每一步调参都知道在治什么病。

索引器越配越多，每次搜索都要并发问遍所有追踪器，响应时间取决于最慢的那个。缓存是 Jackett 的提速手段：同样的查询第二次直接返回内存里的结果。但缓存配置不当会反噬：TTL 太短，缓存几乎不命中，等于白开；每索引器缓存条数太大，内存被越堆越高。再加上搜索习惯问题，没用的请求全打出去，自然越来越卡。

🩺 先定位瓶颈：日志、资源、单测三步自查

别急着改配置。先花 10 分钟定位卡在哪一环，改错方向只会更卡。

第一步：打开 View logs 找超时和错误行

在配置页点绿色的 View logs 按钮，翻最近 100 行。超时和 Exception 集中在哪个 indexer，问题基本就锁定了。频繁刷错的站点要么网络不通，要么接口改版，它会把整体拖慢。

第二步：用 top 或任务管理器盯住内存和 CPU

Linux 上跑top，Windows 打开任务管理器，找到 Jackett 进程看两个数。常驻内存稳定在 500MB-1GB 属正常；长期超过 1.5GB，多半是缓存条数设大了。CPU 持续 50% 以上而你没在搜索，说明第三方工具轮询太密。

第三步：对单个索引器点 Test 测响应时长

打开 Configured Indexers 页面，给可疑站点点 Test，或者用 Manual Search 手动搜索——结果页上方会显示每个追踪器的耗时，单位是毫秒。单次超过 10 秒的站点就是瓶颈：先清它的缓存再测，还是慢就把它移除。

图：Jackett 索引器管理界面，显示已配置的索引器列表、Public / Private / Semi-Private 标签和 Test 操作

⚡ 核心调整：把缓存三项参数改成这几个值

缓存是 Jackett 变慢的第一修复点。下面三个参数直接给出建议数值，照着改就行。

勾选 Cache enabled (recommended) 打开缓存开关

配置页默认是勾选状态，先确认它没被关掉。开关一关，每次搜索都真打一遍所有站点，响应时间直接翻倍。这个开关对应源码里的CacheEnabled配置项，实现在 CacheService.cs。

把 Cache TTL (seconds) 设为 2100-3600

官方默认 2100 秒（35 分钟），README 里写明这个值对 Sonarr、Radarr 等工具的轮询节奏都合适。建议保持在 2100-3600 区间。低于 900 秒缓存基本失效，高于 3600 秒你拿到的资源发布时间就不新鲜了。

按内存调整 Cache max results per indexer 到 500-2000

默认 1000 条，超过上限自动淘汰最旧的。内存紧张就降到 500，机器有 4GB 以上空闲内存再升到 1500-2000，别超过 2000，多出来的只有内存开销没有速度收益。

改过索引器配置就清一次缓存

改动某个索引器配置后，Jackett 会自动清掉它的旧缓存（CleanIndexerCache，见 IndexerManagerService.cs）。如果手动搜索后想要最新结果、绕开缓存，Torznab 查询加&cache=false参数即可，只影响这一次请求。

🧹 索引器瘦身与分组：只保留真正在用的站

本段解决“查询面太大”的问题。索引器数量直接决定每次搜索要问多少家。

移除长期不用的索引器，账号配置先留档

Jackett 没有单个索引器的禁用开关，所以用不上的站要移除，但移除前先用 Copy Torznab Feed 把接口地址和配置要点记到文档里，回头恢复时省得重新录账号。移除后立省一次并发查询，响应时间立降。

用 Filter 分组只查相关组

Jackett 自带元索引器，把已配置站按 public、private、semi-public 和自定义标签分组（MetaIndexers.cs）。手动搜索界面的 Filter 下拉里选一个组，搜索就只落在组内。第三方工具也可以把接口指向对应分组，而不是每次查 all。

🎯 搜索习惯：用筛选器把查询范围砍到最小

改完配置，搜索习惯决定最终体感。两个动作：精确筛选、串行搜索。

用 Tracker、Category、Filter 三个筛选器收窄范围

手动搜索界面有 Query、Filter、Tracker、Category 四个条件。查电影就在 Category 选 2000 (Movies)，查音乐选 5000 (Audio)，Tracker 只留目标站点，Filter 选对应分组。条件越精确，返回数据越小，翻页渲染越快。

一次只发一个大型搜索

Jackett 对选中的索引器是并发查询，连续发多个全量搜索会互相抢资源。等上一次结果完整出来再发下一次。第三方工具的轮询间隔保持 15-60 分钟，别设 5 分钟以下。

图：Jackett 手动搜索界面，Filter、Tracker、Category 三个筛选器可用，结果上方显示每个追踪器各自的耗时

💾 系统层调优：2GB 内存加每周自动重启

应用内参数调完，最后看宿主环境。

给运行 Jackett 的机器至少 2GB 内存

缓存全部放内存里。2GB 是底线；1GB 内存的小盒子，把 Cache max results per indexer 降到 500，TTL 保持 2100，比硬扛强。

每 7 天自动重启一次 Jackett

用 crontab、systemd timer（Linux）或任务计划程序（Windows）每 7 天重启一次服务，清掉堆积的内存碎片。重启时间放在凌晨没人用的时段。

✅ 验证优化生效：三个指标对照前后数据

改完别凭感觉，用这三个数对照调整前后。

1. 响应时间：同一条搜索词，总耗时应从十几秒降到 5 秒以内；第二次搜同一词应秒回，说明缓存命中了。
2. 内存占用：top 里 Jackett 进程常驻内存稳定在 500MB-1GB 区间，不再持续爬升。
3. 日志错误数：View logs 里超时和错误行数比调参前明显变少。

核心一句话：先开缓存、调好 TTL 和条数，再瘦身索引器。哪一步让你提速最多？评论区聊聊。

【免费下载链接】JackettAPI Support for your favorite torrent trackers项目地址: https://gitcode.com/GitHub_Trending/ja/Jackett