手动追剧这件事经历过的人都懂那种痛苦。刚刷到一个剧集更新消息赶紧跑回媒体服务器去看目录里空空如也于是开始找源、排队下载、等待完成、手动重命名、拖进对应季度文件夹、再刷新媒体库……整套流程下来一集剧的“入库时间”比你看完它还长。这时候你会意识到追剧流程里真正缺的不是勤快而是一个能替你盯住“更新—搜索—下载—整理—入库”整条链路的东西Sonarr 就是为了解决这个场景而生的。Sonarr 是一个面向电视剧集的自动化媒体管理工具英文社区常把它归类为 PVR 风格应用。它不负责播放也不负责压制它干的是“调度和管理”的活你知道自己追哪部剧它帮你盯着发布信息按你设定的规则挑选合适的版本丢给下载客户端再在下载完成后自动完成重命名、分类、归档。这篇文章我会从核心概念讲到实际部署再把我踩过的一些坑摊开来说适合正准备搭建家庭媒体库、或者已经在用相关自动化工具但想理解底层逻辑的朋友。1. 手动追剧的痛点Sonarr 在自动化链路里的位置1.1 一集剧从更新到入库手动流程到底有多繁琐大多数人的追剧流程是从社交平台讨论串或剧集讨论站点开始的。看到一条“某某剧第 3 集出了”的消息接下来你至少要做这么几步先确认自己平时用哪个搜索途径再去搜索对应资源看完标题里的分辨率、压制组、音轨信息后挑一个复制关键词到下载软件里新建任务等它下载完成如果下载下来的是压缩包还得解压接着把视频文件按“剧名 季度 集数”的方式重命名最后拖进媒体服务器指定的目录里可能还要手动触发一次刷新才会出现在播放列表里。这套流程单集重复一遍大约要花掉 15 到 30 分钟看起来不算太久但问题是它重复得极其频繁。剧集是周更的你同时追的剧可能有五六部每周都要反复经历。更要命的是如果你对画质有要求比如说希望追到的是“高清版”而当时下载到的是普通版那后面可能还要再补一次升级操作。手动追剧的本质不是某一个动作难而是这些零散动作在你的日常生活里高频发生每来一次都要打断一次。1.2 Sonarr 是什么它默认不会做什么第一次接触 Sonarr 的人很容易把它和“下载工具”混为一谈以为装上它就能直接下片。实际上 Sonarr 本身没有任何下载能力它是一个指挥者不是执行者。它做的事情可以这样理解它手里有一份你关注的剧集清单知道每一部剧哪些集没有、哪些集已经有了、当前版本是什么、你期望达到什么质量。然后它定期同步索引器里的发布信息一旦发现符合条件的新发布就通知下载客户端开始任务任务完成后Sonarr 再把文件从下载目录移动到媒体库目录并按照你预设的命名规则重命名。它默认不会做的事情也很明确不内置下载引擎不转码不做字幕匹配不负责播放。你可能听说过一些影视自动化全家桶每个软件各管一段。Sonarr 只管剧集而且是“从发现到归档”这一段播放和后续组织交给 Jellyfin、Plex 这类媒体服务器去处理。理解这个边界能帮你少走很多弯路很多新手配置出错往往是因为想让 Sonarr 做超出它职责范围的事。1.3 它和 Radarr、Prowlarr 这些同族工具是什么关系Sonarr 不是孤立的它属于整个媒体自动化生态。我整理了一个最常见的分工表格工具管理对象核心职责Sonarr电视连续剧/剧集剧集发布跟踪、下载调度、重命名入库Radarr电影电影发布跟踪、下载调度、重命名入库Lidarr音乐音乐发布跟踪、下载调度、重命名入库Readarr电子书/有声书书籍发布跟踪与整理Prowlarr索引器统一管理所有索引器并向 Sonarr/Radarr 同步Bazarr字幕自动搜索、下载和同步字幕文件Jellyfin/Plex/Emby媒体播放扫描媒体库、刮削封面信息并提供播放这套生态的使用逻辑是递进的Prowlarr 管“去哪里搜”Sonarr/Radarr 管“搜什么、下了之后怎么放”下载客户端管“实际把数据拉下来”媒体播放器管“放出来给你看”。Bazarr 则是在入库后按需补字幕。对于只追剧的人来说你只需要 Sonarr 一个下载客户端 一个媒体播放器就能跑起来。如果你想电影剧集一起自动化那才会引入 Radarr。Prowlarr 属于锦上添花它可以让你不用在每个工具里分别维护索引器配置我后面会专门讲它的好处。2. 拆开看核心概念系列、剧集、质量档案与索引器2.1 系列与根文件夹先想清楚媒体库要怎么组织Sonarr 的顶层管理单位叫“系列”英文是 Series。一个系列就是一部剧比如某个剧名加年份的对象。每个系列必须放在一个根文件夹Root Folder下面根文件夹可以是某个 TV 目录Sonarr 会在根目录下为每个系列自动创建子目录。目录结构直接决定你后续的管理难度和“硬链接”能否生效建议一开始就按下面的布局规划/media ├── downloads │ └── complete └── tv └── Some Show (2024) ├── Season 01 │ └── Some.Show.S01E01.1080p.WEB-DL.x265.mkv └── Season 02根文件夹填的就是/media/tv下载目录填/media/downloads。Sonarr 在做文件导入时会把/media/downloads/complete里的文件移动到/media/tv/Some Show (2024)/Season 01/下同时按配置好的格式重命名。这块听起来简单但很多人的目录设计是随意的结果后期要么硬链接不生效要么两个容器之间的路径对不上。我的建议是先规划目录再部署服务不要先装完再挪。2.2 剧集监控状态与搜索状态的联动逻辑在系列里面每一集都有一个监控状态和一个搜索状态。监控状态决定 Sonarr 是否关心这一集标记为“已监控”的剧集如果当前不存在它就会出现在缺失列表里后续也会参与搜索“未监控”表示你不想要它“已忽略”则是既不监控也不参与搜索。搜索状态则记录最新的一次搜索是成功还是失败。这两个状态是联动的只有已监控且缺失的剧集才会被 Sonarr 纳入“自动补齐”的范围。你可能会遇到一种情况明明剧集已经在索引器里发布了Sonarr 却纹丝不动。排在第一位的检查项就是这一集的监控状态是不是“已忽略”。我后面在坑位章节会再展开讲因为我自己就因为这个状态被坑过。2.3 质量档案分辨率只是最粗的一层筛选质量档案Quality Profile是 Sonarr 选择版本的核心规则。一个档案由分辨率、来源、编解码器、语言等维度组成。你给系列分配一个档案Sonarr 在搜索时只会接受符合该档案约束的发布。举个例子一个典型的高清剧集档案可能是这样的维度允许值分辨率1080p / 2160p来源WEBDL / Bluray编解码器x264 / x265语言英语在档案里还有一个重要选项叫“允许从更高版本升级”Upgrades Allowed。如果开启Sonarr 入库一集之后如果后续索引器出现了更符合你要求的版本并且你的“升级期望”达到阈值时它会下载新版并替换旧文件。这个机制是 Sonarr 最有价值的地方也是一不小心就会造成重复下载浪费带宽的地方。3. 部署安装与目录规划我为什么默认用 Docker 方案3.1 用 Docker 部署 Sonarr卷怎么挂才算稳妥Sonarr 本身是 .NET 应用支持 Windows、macOS、Linux 和 Docker。但如果你追求可维护性我会毫不犹豫推荐 Docker 方案尤其是用 LinuxServer.io 维护的镜像。这套镜像在家庭媒体服务器圈子里用得极广它对 PUID/PGID 的支持非常顺手想换版本、迁移机器也很干净。一个基础但完整的启动命令是这样的docker run -d \ --namesonarr \ -e PUID1000 \ -e PGID1000 \ -e TZAsia/Shanghai \ -p 8989:8989 \ -v /path/to/config:/config \ -v /path/to/tv:/tv \ -v /path/to/downloads:/downloads \ --restart unless-stopped \ linuxserver/sonarr:latest这里三个卷各有各的任务。/config存 Sonarr 的数据库和配置文件一定要挂/tv是媒体库目录对应前面说的根文件夹/downloads是下载暂存区。很多人图省事只挂/config一个卷后面下载完根本找不到文件所以这步不能省。3.2 宿主机目录、容器目录和媒体库布局容器化的路径问题本质上是“宿主机路径”和“容器内路径”两套视角。你挂载卷的时候冒号左边是宿主机路径右边是容器内路径。比如-v /path/to/tv:/tv意思是宿主机的/path/to/tv在容器内被访问为/tv。这一点非常关键Sonarr 在配置下载客户端、根文件夹时所有路径都必须使用容器内能看到的路径。如果你的下载客户端也是容器那还需要考虑下载客户端容器里看到的路径是否和 Sonarr 容器里看到的路径一致。这也就是我后面要讲的“远程路径映射”问题这里先记住一个原则所有容器访问同一批文件时尽量让挂载路径保持一致不要一边是/media/downloads另一边是/downloads哪怕它们指向同一个宿主机目录那也迟早出问题。3.3 装完之后第一件事确认健康检查容器起来之后打开浏览器访问http://宿主机IP:8989会看到 Sonarr 的引导界面。第一步是设置媒体库根目录就是在管理界面里把/tv添加为根文件夹。然后去系统System标签页下的健康检查Health查看是否有错误。健康检查是 Sonarr 给所有配置做的“体检报告”任何一个问题它都会列在这里比如“下载客户端未配置”“根文件夹不存在”“系统时间偏差过大”等。很多人配置完遇到诡异现象先去看这里比满世界搜日志高效得多。我自己的习惯是每次改完配置都刷新一下健康检查确认没有新增警告再继续下一步。4. 配置联动索引器、下载客户端与媒体管理如何配合4.1 索引器接入的重点不在“加得多”而在“配得稳”索引器是 Sonarr 获取发布信息的窗口。在 Sonarr 里添加索引器时你需要填写协议类型、服务器地址、API 密钥和分类。添加完成后Sonarr 的 RSS 同步任务会定期拉取最新发布列表把和你关注的剧集匹配的条目挑出来。我的经验是索引器不是越多越好而是越稳定越好。如果你同时加了一堆不太稳定的索引器每次同步都超时Sonarr 的重试机制会拖慢整个搜索流程甚至导致新剧发布后迟迟没反应。更建议的做法是用 Prowlarr 把索引器统一管理起来然后在 Prowlarr 里直接同步给 Sonarr缺点是少了维护起来也方便。4.2 下载客户端接入与类别隔离在设置里添加下载客户端时类型选你实际用的下载工具填好地址和端口然后测试连接。连接成功后有一个容易被忽略但很重要的设置类别Category。在下载客户端配置里填一个sonarr类别的标签这样所有由 Sonarr 发起的下载都会带上这个标签。好处有两个一是下载工具的任务列表里能一眼区分哪些是剧集、哪些是电影二是 Sonarr 按类别识别属于自己管理的任务不会出现两个自动化工具抢同一个任务的情况。这里有个小建议Sonarr 触发下载后理论上不需要你再碰下载工具它会通过下载客户端 API 获取任务状态下载完成时自动导入。如果你发现任务下载完了却不自动导入优先检查下载工具是否开启了“自动管理”之外的干扰项比如手动修改过下载目录或者下载工具里的“保存路径”和 Sonarr 看完了不是同一个容器路径。4.3 手动追一整集验证全链路是否打通配置完成后最好找一集缺失的剧集做一次“手动搜索”来完成全链路验证。在系列页面点击对应的缺失剧集选择“自动搜索”然后观察任务状态。正常流程应该是状态从“正在搜索”变成“正在下载”下载工具里多出一条任务下载完成后Sonarr 把它标记为“已下载/正在导入”导入完成后你到媒体库目录去看文件已经按规则重命名好了。整个过程的日志都可以在系统日志里看到。第一次跑通会有一种“家务全自动”的畅快感这种验证也能帮你发现路径映射、权限、命名规则里最基础的问题。5. 从“能入库”到“聪明入库”质量档案与自定义规则5.1 质量档案的升级理想值给系列选质量档案之前先想清楚一个问题你希望一部剧入库到什么质量为止是 720p 能看就行还是非 1080p WEB-DL 以上不要这没有标准答案但你要理解“升级”机制带来的成本。如果开“允许升级”Sonarr 会在一集已经入库后继续留意有没有更高的版本出现。看起来是好事但也意味着同一集可能被重复下载两三次。我的做法是把升级期望设成一个具体的目标值比如“1080p WEB-DL 以上即可不要等 2160p”这样既保证画质也不会看到不同压制组赛跑般发版本时反复下载。档案里的“来源”维度也很值得琢磨。同样一个 1080p 版本WEB-DL 和 Bluray 的压制来源不同体积和画质也有差异。如果你对容量有要求优先选 WEB-DL如果你对画质敏感且硬盘够大选 Bluray 会稳一些。5.2 自定义格式真正解决“版本挑选”问题质量档案解决的是“能接受哪些版本”自定义格式解决的是“在这些版本里更想要哪种”。它的原理是根据发布标题的文本特征打分然后把这些分数作为选择依据。举个例子我想尽量挑带 HDR 或 DV 标记的版本那就建一个自定义格式规则里添加“标题包含正则”条件\b(HDR|DV)\b给这个规则的分数设为 100。然后在档案的“自定义格式分数”里把这个格式加进去设置“升级分数”为 100。这样当一个 1080p HDR 版本出现时它会因为多出 100 分而被优先选择。反过来说如果你特别不想要某个压制组或某种编码也可以建一个自定义格式并给负分。这套机制本质上是在教你把“我想要什么版本”这个模糊感觉转换成可计算的规则。它有一定的正则表达式学习成本但一旦配好Sonarr 的挑选能力会提升一个档次。5.3 自动化规则下的一些小陷阱规则写得太死很容易误伤。比如语言限制里如果只允许英语那有些标题里没写语言标签但实际带中文字幕的版本就不会被选上。再比如对片源关键词要求严苛可能导致某部冷门剧长期“找不到合适版本”这时候你却以为是网络问题实际上是你自己把路堵死了。我现在的原则是自定义格式只约束“必须有”的项目对可选的偏好优先用加分而不是硬性要求。因为 Sonarr 面对的是一个信息不规范的资源生态标题写法千奇百怪规则卡得太死它就只能空手而归。6. 实际用下来我踩过的几个具体问题6.1 Docker 路径映射不一致引发的“文件找不到”有一次 Sonarr 报了“下载文件不存在”的错误但下载工具里明明显示任务已经完成。排查了半天发现是因为下载客户端容器把宿主机/data/downloads挂载成了/data/downloads而 Sonarr 容器把它挂载成了/media/downloads。下载客户端向 Sonarr 报告“文件在/data/downloads/xxx.mkv”Sonarr 在自己的文件系统里找半天当然找不到。解决办法是在 Sonarr 的“远程路径映射”里做一层转换把下载客户端报告的/data映射为 Sonarr 能看到的/media。这种问题基本只在容器化部署中出现也是我最想提醒新人的一点所有容器的挂载路径越统一你踩的坑越少。6.2 硬链接没生效磁盘空间被翻倍占据Sonarr 在导入文件时有一个省空间的利器叫硬链接。简单讲硬链接可以让多个目录条目指向同一个磁盘数据块不复制数据就能让同一个文件出现在两个位置。也就是说下载目录里“保留一份做种”媒体库里也“看起来有一份”但实际上只占一份空间。硬链接有一个苛刻条件必须在同一文件系统内部。如果你的/downloads和/tv挂载自两块不同的磁盘分区硬链接就一定会失败Sonarr 只能退化成复制一盘高清剧的体积直接翻倍。检查方法很简单先在下载目录和媒体库目录分别执行df看是不是同一个分区再用ls -i看文件 inode 是否一致。如果 inode 相同说明硬链接生效了。6.3 权限问题PUID/PGID 与下载客户端不匹配导入被拒Sonarr 需要读取下载客户端产生的文件然后移动或删除这些文件。如果两个容器运行的用户不同比如下载客户端以 uid 1000 运行Sonarr 却以 uid 1001 运行那 Sonarr 可能没有权限读取或删除下载目录里的文件导入就会失败。解法比较朴素把 Sonarr、下载客户端、Prowlarr 这些相关容器全部固定成同一个 PUID 和 PGID并且确保这些目录的属主就是该用户。使用 LinuxServer.io 镜像时这个操作只是一个环境变量的事。我见过不少人在这一步绕了很久最后发现只是用户 ID 差了一个数。6.4 监控状态被意外改动剧集永远停在“已忽略”有一个让我印象很深的坑一部老剧的某一集一直没入库Sonarr 也不检查。变量排查后发现那集的监控状态不知何时被改成了“已忽略”。回想起来大概率是我在日历界面拖拽或批量编辑时不小心点到了。这类问题隐藏得深因为 Sonarr 健康检查不会把它当成错误它只会安安静静地把这集“晾”在一边。如果某部剧“该更新却不更新”先看系列里对应剧集的监控状态再看它是否出现在“缺失”列表里。如果不在十有八九是监控状态的问题去系列编辑器里批量把对应剧集改成“已监控”就行。7. 让它融入整个家庭媒体系统一些进阶用法和个人建议7.1 与 Jellyfin/Plex 的联动Sonarr 入库是自动的媒体播放器的扫描也可以做到自动。Jellyfin 和 Plex 都支持监听媒体库目录变化文件一出现就触发扫描。实际体验下来一集剧在 Sonarr 显示“已导入”后十几秒内播放器里就能看到新的条目整个过程不需要任何人工干预。如果你还想要更细的通知比如“新剧已入库”推送到手机可以在 Sonarr 的“连接”里配置 Webhook 或直接接入 Telegram、Bark 这类通知服务。这个配置很轻但带来的安心感很强你不再需要隔三差五打开 Web UI 去看有没有更新。7.2 日志与健康检查遇到问题先看哪里Sonarr 排错有一个相对固定的顺序先看首页健康检查和系统日志再看下载客户端日志最后才去索引器那边查。绝大多数问题都能在健康检查里给出提示如果不够细开一下日志级别为 Trace重新跑一次搜索日志里会给出完整的搜索、解析、选择链路。日志的位置在“系统 → 日志”不建议日常开着 Trace 级别信息量太大日志文件涨得也快排查问题时临时开一下就好。7.3 长期使用中的几个习惯建议最后分享几个我长期用下来的习惯。第一定期备份/config目录Sonarr 的所有库和配置都在里面迁移机器时直接恢复它就能满血复活。第二给下载目录设置一个合理的保留时间或空间上限避免“自动化”变成“存储失控”。第三尽量减少同时追的剧集数量剧越多RSS 同步和搜索越频繁对索引器和 NAS 的压力也越大。另外想多说一句关于来源合规的话。这整套自动化流程本身是工具能力的问题但具体下载什么内容、来源是否合法授权直接决定这套系统能不能长期安稳用下去。我的原则是只对你有权访问、属于公共领域或明确允许离线保存的内容使用全自动流程不要把它变成规避授权的手段。工具没有原罪用工具的人心里得有数。Sonarr 这套系统真正厉害的地方不在于它单个功能有多惊艳而在于它把“盯发布、选版本、触发下载、整理入库”这件繁琐的事压缩成了后台的无声流程。我至今还记得第一次看着它自己把一整季缺失剧集补齐然后媒体库条目一排排亮起来的画面那种感觉和手动折腾半小时后终于入库的满足感完全不在一个层级。如果你也在为每周反复的手动追剧而头疼按这篇文章的顺序搭建一遍大概率会发现原来追剧也可以这么省心。