根治Sonarr抓取假种：打造无人值守媒体库

问题的本质：自动化媒体库的"垃圾进垃圾出"

一位 Reddit 用户分享了他的自动化媒体服务器方案：在迷你 PC 上用 Docker 部署 Sonarr + Prowlarr + aria2 + Jellyfin。整套系统运行流畅，但有一个顽固的痛点——公共索引器（public indexers）不断给他推送伪装成 "1080p WEB-DL" 的假种，下载下来一看，文件夹里躺着的竟是 .scr 或 .exe 可执行文件。

Docker 容器化部署是自建媒体库的主流架构选择。Docker 通过容器化技术将每个应用（Sonarr、Prowlarr、aria2、Jellyfin）隔离在独立的运行环境中，彼此通过定义好的网络和卷（volume）进行通信。这种架构的优势在于：各组件可独立升级和重启而不影响其他服务；通过 docker-compose 一键编排整套栈；迁移时只需备份配置文件和 compose 文件即可在新硬件上快速恢复。docker-compose.yml 文件本质上是一份基础设施即代码（Infrastructure as Code）文档，记录了所有服务的镜像版本、端口映射、环境变量和数据持久化策略。对于 *arr 栈而言，典型的卷映射策略是让所有服务共享同一个根媒体目录（如 /data），通过子目录区分下载中（/data/downloads）和已整理（/data/media）的文件，这样 Sonarr 在导入时可以使用硬链接（hardlink）而非复制文件，极大节省磁盘空间和 I/O 开销。迷你 PC（如 Intel NUC、N100 系列小主机）因低功耗、静音、体积小而成为家庭服务器的热门选择，7×24 小时运行的年电费通常不超过百元。特别是 Intel N100 处理器，其 6W TDP 和内置的 Intel UHD Graphics（支持 AV1 硬件解码）使其成为 Jellyfin 转码和媒体管理的理想选择，单核性能足以应对 *arr 应用的数据库操作，GPU 则可处理 1-2 路 4K 转码流。

由于宿主机是 Linux，这些 Windows 二进制文件既无法运行、也无法被 Sonarr 识别导入，因此并不会真正"搞坏"系统。但问题在于：它们白白消耗了抓取配额（grabs）、堵塞下载队列，迫使用户每隔一两天就得手动加入黑名单（blocklist）。

"我做自动化，本来就是为了不用天天动手管它啊。"

这句略带无奈的吐槽，道出了所有自建媒体库玩家的共同追求：真正意义上的"无人值守"（hands-off）。这篇文章将围绕如何过滤假种、优化抓取策略，以及公共索引器的去留问题展开分析。

为什么Sonarr会抓到.exe/.scr假种？

Sonarr自动化抓取工作流

要理解假种为何能骗过 Sonarr，首先需要了解整个自动化抓取链条的工作原理。Sonarr（电视剧）和 Radarr（电影）是 *arr 家族的核心应用，它们的工作流程是：用户添加想要的剧集 → Sonarr 通过 Prowlarr 查询已配置的索引器 → 根据质量配置（Quality Profile）和发布配置（Release Profile）对搜索结果进行评分和过滤 → 将符合条件的种子/NZB 发送到下载客户端（如 aria2、qBittorrent、SABnzbd）→ 下载完成后 Sonarr 自动重命名文件、移动到媒体库目录 → Jellyfin/Plex 检测到新文件并刮削元数据。整个链条中，"抓取"（grab）是关键环节，一旦抓取了假种，后续所有步骤都会被浪费。

假种的运作逻辑

公共索引器（如各类公开 Torrent/Usenet 站点）没有准入门槛，任何人都能上传内容。恶意上传者利用热门剧集、电影的命名规则（如带上 1080p.WEB-DL.x264 等诱人关键词），实际打包的却是恶意可执行文件或垃圾文件。这类假种的特征往往是：

• 文件体积异常：真正的 1080p 剧集单集通常在 1–4GB，而假种可能只有几 MB 或几百 MB。
• 扩展名可疑：.exe、.scr、.lnk、.bat 等本不该出现在视频资源中。
• 压缩包套娃：把可执行文件塞进 .rar 或 .zip，逃避简单的扩展名过滤。

值得一提的是，.scr 文件在 Windows 系统中是屏幕保护程序文件，但其本质是与 .exe 完全相同的 PE（Portable Executable）格式可执行文件，只是扩展名不同。恶意软件作者偏爱使用 .scr 正是因为许多用户对这个扩展名不够警惕，且部分安全软件对其检测力度低于 .exe。在 BT 传播场景中，假种内的恶意文件通常是加密货币挖矿木马、远控后门（RAT）或勒索软件的载体。

Sonarr默认防护为何不够用

Sonarr 本身有一定的质量识别能力，但它主要依赖**发布名称（release name）**中的元数据来判断质量档位，而假种恰恰在名称上做足了功夫。Sonarr 在抓取阶段只能看到索引器返回的标题信息（如 Show.Name.S01E01.1080p.WEB-DL.x264-FakeGroup），无法预先检查种子内的实际文件列表。这是因为索引器 API（Torznab 协议）返回的 RSS/搜索结果仅包含标题、体积、做种数等元信息，而种子文件内部的文件列表（file list）需要下载 .torrent 文件并解析其 bencode 编码后才能获取。因此单靠默认设置，Sonarr 很容易"上当"抓取，直到下载完成、尝试导入时才发现无有效媒体文件。

Sonarr假种过滤策略：哪些设置真正管用

1. 设置合理的Quality体积下限

这是性价比最高的第一道防线。在 Sonarr 的 Quality（质量）定义 中，为每个分辨率档位设置合理的 Min Size（最小体积）。例如，将 1080p WEB-DL 的单集最小体积设为 500MB–800MB 以上，绝大多数几 MB 的假种会被直接排除，根本不会进入抓取队列。

体积下限的设置需要参考实际发布数据：一集 45 分钟的 1080p WEB-DL 剧集，典型码率在 4-8 Mbps 之间，对应文件大小约 1.3-2.7 GB。30 分钟的情景喜剧则约 800MB-1.8GB。将下限设为略低于最小合理值（如 45 分钟剧集设 1GB，30 分钟设 500MB）是安全的选择。同时也建议设置体积上限，避免抓取到异常膨胀的 Remux 或错误标记的文件。

对于剧集包（season pack），则需要结合集数换算合理阈值。这一招能过滤掉相当大比例的"空壳"假种。

2. 配置Release Profiles关键词过滤

Sonarr 的 Release Profiles 支持 Must Contain / Must Not Contain（必须包含/必须不含） 的正则关键词过滤。可以配置：

• Must Not Contain：加入 \\.exe、\\.scr、\\.lnk 等关键词，直接拦截标题或描述中暴露可执行文件的种子。
• Preferred（偏好词）：给可信的发布组（release group）加分，优先抓取信誉良好的资源。

需要注意的是，Sonarr v4 已将 Release Profiles 演进为 Custom Formats（自定义格式）系统，提供了更灵活的评分和条件组合能力。Custom Formats 引入了条件组合逻辑：每个 Custom Format 由多个条件（Condition）组成，条件之间支持 AND/OR 逻辑运算。条件类型涵盖正则匹配（Release Title）、文件大小范围、索引器标志位（Indexer Flag，如 Freeleech）、来源类型（Source）等。系统通过为每个 Custom Format 分配正负分值，最终计算出一个综合得分来决定抓取优先级。社区维护的 TRaSH Guides（trash-guides.info）提供了一套经过大量用户验证的 Custom Formats 配置方案，覆盖了从画质偏好（如优先 x265/HEVC）到避免特定问题（如 DV/HDR 兼容性问题）的各种场景，强烈建议新手以此为起点进行配置。

3. 在Prowlarr层面做前置过滤

Prowlarr 作为索引器聚合管理工具，可以在源头做过滤。Prowlarr 的核心价值在于：统一管理所有 BT 和 Usenet 索引器的配置；通过 Sync Profile 将索引器按类别同步到 Sonarr/Radarr/Lidarr 等下游应用；支持为不同索引器设置独立的种子数过滤、优先级权重和搜索频率限制。

在 Prowlarr 之前，用户需要在 Sonarr、Radarr、Lidarr 中分别配置相同的索引器，每次索引器 URL 或 API Key 变更都需要逐一修改。Prowlarr 采用中心化管理模式，通过其 Sync Profile 机制将索引器配置自动推送到所有已连接的 *arr 应用。其内部实现了对 Torznab 和 Newznab 这两种标准化 API 协议的支持——Torznab 是 Jackett 项目发明的 BT 索引器标准接口，Newznab 则是 Usenet 索引器的标准接口。Prowlarr 还支持对每个索引器设置独立的请求频率限制（Rate Limiting），避免因请求过于频繁而被索引器封禁 IP。

它还内置了对 FlareSolverr 的支持，用于绕过 Cloudflare 等反爬保护。FlareSolverr 本质上是一个运行在 Docker 中的无头浏览器代理，当索引器站点启用了 Cloudflare 的 JavaScript 挑战时，Prowlarr 会将请求路由到 FlareSolverr，由其执行完整的浏览器环境模拟来通过验证，再将结果返回给 Prowlarr。在假种过滤场景中，Prowlarr 可以在结果到达 Sonarr 之前就做一轮初筛，减少下游的判断负担。

通过为不同索引器配置优先级、种子数下限，以及利用 Prowlarr 的 sync profile，能有效减少低质量源进入 Sonarr 的机会。

4. 做种数（Seeder）与年龄门槛

对 BT 资源设置最低做种数要求（如 Seeders ≥ 3–5），可以过滤掉那些无人做种的"死种"和刚上传的可疑新种。在 BitTorrent 协议中，做种数不仅代表下载速度的保障，更是一个隐含的社区信任信号。其逻辑在于：真实的热门资源会自然积累做种者，因为下载完成的用户默认会继续做种；而假种由于下载者迅速发现文件无效后会立即停止做种并举报，导致其做种数难以自然增长。恶意上传者虽然可以通过多个客户端伪造做种数，但维持长时间的虚假做种需要持续的带宽和 IP 资源成本。因此，"最低做种数"本质上是一个基于群体智慧的概率过滤器——做种数越高，该资源为真实有效文件的概率越大。

同时，设置"最小年龄"（如资源上传后至少存活 15–30 分钟再抓取）也能避免抓取到刚上传、尚未被社区验证或举报的可疑资源。这个时间窗口让公共索引器的自净机制（用户举报、管理员删种、自动化反垃圾系统）先行运作，大幅降低抓取到假种的概率。

公共索引器vs私有Tracker：要不要彻底弃坑？

公共索引器的固有局限

发帖者提出了一个关键问题："你还在用公共索引器吗？还是干脆弃坑了？" 这触及了自建媒体库的核心矛盾。

公共索引器的优势是免费、无门槛，但代价就是：

• 假种、恶意种泛滥；
• 做种质量差、下载速度不稳定；
• 需要持续人工维护黑名单。

换句话说，用公共源就注定无法做到真正的"无人值守"，你省下的会员费，最终会以"手动运维时间"的形式还回来。从经济学角度看，如果每两天需要花 10 分钟手动清理黑名单，一个月累计约 2.5 小时——对比私有 Tracker 或 Usenet 每月几美元到十几美元的成本，这笔"时间账"对大多数人来说并不划算。

私有Tracker的信任机制

私有 Tracker（PT 站）通过一套精密的信任和激励机制来保障资源质量。其核心包括：邀请制或面试制准入，确保用户有基本的技术素养和社区意识；严格的分享率（ratio）要求，用户必须上传一定量的数据才能持续下载；上传审核制度，新种子需经过管理员或自动化工具验证文件完整性和命名规范；以及 Trump 规则，允许更高质量的资源替换低质量版本。这套体系从经济学角度创造了一个"高维护成本=高信任度"的环境，恶意上传者的成本极高（被封禁意味着失去辛苦维护的账号和分享率），因此假种几乎不存在。知名 PT 站如 BTN（电视剧）、PTP（电影）、HDB（高清综合）的资源质量被公认为业界顶级。

在技术实现上，私有 Tracker 使用专门的 Tracker 服务器（如 Gazelle、UNIT3D 框架）来追踪用户的上传/下载数据。每个用户都有唯一的 passkey 嵌入在种子的 announce URL 中，tracker 据此精确统计分享率。同时，这些站点通常配备自动化的 MediaInfo 分析工具，在种子上传时自动检测视频编码参数、音频轨道、字幕信息是否与标称一致，从技术层面杜绝了以假充真的可能。

私有Tracker和Usenet的实际价值

社区的普遍共识是：想要真正 hands-off 的体验，私有 Tracker 或付费 Usenet 是绕不开的选择。

• 私有 BT 站点：有严格的上传审核和做种比例（ratio）要求，几乎不存在假种，资源质量和做种健康度远超公共源。缺点是准入有门槛，且需维护分享率。对于 *arr 用户而言，维护分享率的常见策略包括：利用 Freeleech 活动（下载不计入）大量获取资源、使用 seedbox（专用做种服务器）长期做种、以及参与站点的 bonus point 系统用积分兑换上传量。了解 Scene Groups 和 P2P 内部组的发布组信誉对于配置 Custom Formats 至关重要。Scene（场景组织）是一个有着 30 多年历史的地下数字发行网络，拥有严格的发布规则（如 Standard Definition x264 Releasing Standards），每个场景组发布的资源都遵循统一的命名规范和质量标准。知名场景组如 NTb、FLUX、PECULATE 等，其名称本身就是质量背书。P2P 内部组则是私有 Tracker 站点的官方或认证发布组，通常提供更高码率的编码或稀有资源。

• Usenet + Indexer：Usenet 是一个诞生于 1980 年代的分布式讨论系统，后来演变为文件分享的重要渠道。与 BT 的 P2P 架构不同，Usenet 采用客户端-服务器模式：文件被上传到 Usenet 服务商的中心化服务器集群，用户通过 SSL 加密连接直接从服务器高速下载，不存在做种/吸血的概念。

  Usenet 的技术架构与现代互联网的 HTTP 模型有本质区别。它基于 NNTP（Network News Transfer Protocol）协议，最初用于学术讨论组的文章传播。文件分享利用的是 Usenet 的二进制组（binary newsgroups），大文件被分割成多个文章（articles），每个文章不超过特定大小限制。NZB 文件本质上是一个 XML 格式的清单，记录了组成完整文件的所有 article 的 Message-ID，下载客户端（如 SABnzbd、NZBGet）根据这些 ID 向 Usenet 服务商请求对应的数据块并重组为完整文件。

  Usenet 的三个关键组件是：Provider（服务商，如 Newshosting、Eweka，提供下载带宽和文件保留天数）、Indexer（索引服务，如 NZBGeek、DrunkenSlug，负责解析和索引 Usenet 上的资源并生成 NZB 文件）、以及下载客户端。保留天数（Retention）是 Usenet 服务商的关键指标，主流服务商如 Newshosting 提供超过 5000 天的保留期，意味着十多年前上传的内容仍可下载。DMCA 删除请求是 Usenet 的主要内容风险，block account（备用服务商）策略可以弥补主服务商因 DMCA 导致的文章缺失问题——通常建议配置一个主力服务商加 1-2 个不同后端（backbone）的 block 服务商以获得最高完整率。

  由于上传到主流 Usenet 服务商需要一定门槛，且索引器有人工审核机制，假种问题远比公共 BT 站少。成本上，Usenet 服务商（Provider）约每月几美元，Indexer 通常一年 10–20 美元不等。对于追求稳定的用户，这是公认最省心的方案。许多资深用户会采用"Usenet 为主 + 私有 Tracker 为辅"的混合策略，Usenet 负责日常热门剧集的即时抓取（通常在播出后几分钟内即可用），私有 Tracker 则用于获取 Usenet 上因 DMCA 而缺失的冷门或老旧资源。

打造真正无人值守的媒体库架构建议

综合来看，一个高度自动化、低维护的媒体库栈应遵循以下原则：

1. 源头把关：以私有 Tracker 或 Usenet 为主力索引源，公共源仅作补充或彻底弃用。
2. 多层过滤：Quality 体积下限 + Release Profile 关键词拦截 + Seeder 门槛，三管齐下。
3. 信誉优先：通过 Preferred 词库或 Custom Formats 锁定可信发布组（如知名的 scene groups 和 P2P 内部组），让系统优先抓取已知靠谱的资源。在 Custom Formats 中配置这些组名作为正则匹配条件并赋予高分值，可以让系统在多个候选资源中优先选择来源可靠的版本。
4. Linux 天然屏障：正如发帖者所言，Linux 宿主机让 Windows 恶意二进制"英雄无用武之地"，这本身就是一层被动安全防护。不过需要注意，如果媒体库通过 Samba/NFS 共享给 Windows 客户端访问，仍存在间接传播风险，建议配合 ClamAV 等开源杀毒工具做定期扫描。此外，Docker 的容器隔离也提供了额外的安全边界——即使下载了恶意文件，其执行权限被限制在容器的用户命名空间内，无法影响宿主机系统。
5. 监控与告警：利用 Sonarr/Radarr 的 webhook 功能对接 Telegram/Discord 通知，当出现连续抓取失败或黑名单频繁触发时及时告警，将"无人值守"从"完全不管"升级为"异常时才介入"。进阶用户还可以部署 Notifiarr（原 Discordnotifier）实现更精细的通知管理，或使用 Tautulli（Plex）/ Jellystat（Jellyfin）监控实际播放情况，确保自动下载的内容确实被成功播放。

结语

从 .exe 假种这个小问题，其实能看到自动化媒体库的一条底层规律：自动化的质量，取决于数据源的质量。这与软件工程中"garbage in, garbage out"（垃圾进垃圾出）的经典原则如出一辙。你可以用无数过滤规则去打补丁，但只要还依赖来者不拒的公共索引器，就永远无法摆脱"隔天清一次黑名单"的宿命。

对于真正想要"一次配置、长期省心"的用户，投入少量成本迁移到私有 Tracker 或 Usenet，往往比无休止地调优过滤规则更划算。毕竟，自动化的终极目标，是让你彻底忘记它的存在。

核心要点