有人一直在利用种子站搞我的Sonarr：一次追剧自动化维护实录

Sonarr 是很多自建媒体库玩家的核心工具，它负责监控剧集更新、自动匹配资源并推送给下载器。但当你把它的索引器接到公开种子站时，麻烦往往不是来自配置错误，而是来自屏幕另一头那些故意投放垃圾资源的人。

这次的问题不是 Sonarr 崩了，而是它太好用了——好用到被人当成攻击面。

被污染的索引结果

最初的症状很轻微：Sonarr 抓到的剧集和预期对不上。标题看着像模像样，文件实际上是完全不相关的内容，或者是体积异常的假种子。

这类资源通常有几个共同特征：

• 标题故意模仿正规发布组的命名规则
• 文件体积比正常剧集大得离谱或小得离谱
• 发布者账号是新注册的，历史记录为空

它们的目标不是让你下载到病毒那么直接，而是浪费你的带宽、硬盘和自动化流程的信任。

关于索引器与 RSS 机制

Sonarr 本身并不存储资源，它依赖"索引器"（Indexer）来搜索剧集。索引器本质上是一组配置，告诉 Sonarr 去哪里找资源、用什么方式解析返回结果。常见的索引器类型包括 Torznab、Newznab 以及针对特定站点的自定义实现。公开种子站一般通过 RSS 或 API 提供搜索结果，Sonarr 会周期性拉取这些结果并与本地剧集库比对。正因为索引结果是外部数据，其内容质量完全取决于站点的管理力度。公开站缺乏审核，任何人都能上传，因此 RSS 返回的条目里混入垃圾资源是常态而非例外。理解这一点，就能明白为什么问题根源不在 Sonarr 的解析逻辑，而在上游数据的可信度。

为什么 Sonarr 会成为目标

Sonarr 的行为模式非常可预测：它会按照设定的质量偏好、分辨率标准和发布时间窗口去索引站里搜索并下载。

只要有人摸清了这个规律，就能反推出你可能在追哪部剧、大概什么时候会触发下载。公开种子站没有准入门槛，任何人都可以上传，于是自动化工具就成了被投喂垃圾的对象。

这不是 Sonarr 的漏洞，而是把自动化流程暴露在开放社区里的结构性风险。

实际有效的应对手段

收紧索引器与发布组白名单

最直接的办法是减少索引器的数量，只保留信誉较好的站，并在 Sonarr 里配置发布组白名单，把已知的垃圾发布者排除掉。

什么是发布组白名单

发布组（Release Group）是指资源打包和发布时使用的署名，通常出现在文件名末尾，比如 -GROUP。正规发布组有长期积累的命名规范和口碑，而垃圾投放者往往会随意起一个看起来正规的名字。Sonarr 允许在设置中指定"优先"或"必须包含"的发布组列表，也可以设置黑名单排除已知垃圾组。白名单的作用不是保证内容一定正确，而是把搜索范围收缩到有历史记录、可追溯的来源。配合索引器优先级设置，可以让 Sonarr 优先查询可信站点，降低被低质结果命中的概率。

启用延迟下载与人工确认

对于不熟悉的来源，可以开启延迟抓取，让 Sonarr 先标记、不立即推送下载器。这段时间足够你人工看一眼标题和体积是否合理。

依赖评分与体积校验

Sonarr 自带的评分机制可以根据分辨率、编码、发布组等维度给资源打分。配合体积范围限制，能过滤掉大量明显异常的条目。

Sonarr 评分机制的工作原理

Sonarr 的评分系统会根据多个维度给每个搜索结果打分，包括分辨率、来源（如 WEB-DL、BluRay）、编码格式（H.264、H.265）、发布组以及是否包含多语言音轨等。用户可以自定义各维度的权重，并设置最低分阈值，低于阈值的资源会被直接丢弃。体积校验则是独立的一层过滤，通过设定单集或整季的最小/最大文件体积，可以排除掉那些体积明显异常的假种子。两项机制结合使用时，评分负责"质量偏好"，体积负责"合理性检查"，能覆盖大部分低级垃圾投放。

更大的教训

这件事真正暴露的问题是：自动化越省心，越需要边界。

Sonarr 本身没有问题，问题在于把「完全信任」当成了默认设置。公开索引器、无限制的发布组、自动下载一气呵成——这套组合在理想环境下很爽，在开放网络里就是给别人留了后门。

对自建媒体库的人来说，花十分钟收紧一下索引器和评分规则，比事后到处删垃圾文件要划算得多。

自动化流程中的信任边界

任何自动化系统都隐含着一组信任假设。Sonarr 默认信任索引器返回的结果、信任发布组的命名、信任文件体积与内容匹配。在封闭或半封闭的私有站点里，这些假设基本成立；一旦接入完全开放的公开网络，假设就变成了攻击面。类似的结构性问题并非 Sonarr 独有，邮件过滤、爬虫、CI/CD 流水线都面临同样的挑战。通用的应对思路是引入"零信任"原则：对每个环节设置验证点，而不是端到端放行。对媒体库玩家来说，这意味着在索引、筛选、下载三个环节各留一道人工或规则检查，而不是把所有决策权交给工具。