Bazarr 與 Prowlarr，字幕與索引器的整合差異

字幕供應商整合與評分機制

Bazarr 支援的字幕供應商數量相當可觀，包含 OpenSubtitles、Podnapisi、Addic7ed、Subscene、Assrt、Subf2m、BSPlayer、Titlovi 等數十個來源，並且持續有新供應商透過社群貢獻加入。使用者在設定介面中，可以針對每個供應商設定帳號密碼、API 金鑰、是否啟用、以及「優先級分數」。Bazarr 的字幕評分機制相當細緻，除了供應商層級的優先級之外，還會考慮字幕與影片的「匹配度」——例如字幕檔的版本標籤是否與影片的發行群組一致、字幕的語言是否為使用者指定的方言（如繁體中文 vs. 簡體中文）、字幕的格式是否為 SRT 或 ASS 等。

實務上，評分機制的調校往往是 Bazarr 使用者的「進階課題」。預設值雖然可用，但如果你特別在意繁體中文的品質，通常會需要把 Assrt、Subf2m 等華語圈較常用的供應商優先級調高，並搭配「只接受特定上傳者」或「排除機器翻譯」之類的過濾條件。Bazarr 也支援「手動搜尋」與「強制下載」功能，讓使用者在自動結果不理想時，仍能介入處理。

與 Sonarr、Radarr 的連動細節

Bazarr 與 Sonarr、Radarr 的連動是透過 API 金鑰與主機位址設定完成的。在 Bazarr 的「設定 → Sonarr」與「設定 → Radarr」頁面中，填入對應的 URL 與 API Key 後，Bazarr 就能讀取媒體庫清單。這裡有幾個常見的坑：第一，若 Sonarr 或 Radarr 使用了自訂的 URL 基底（例如掛在反向代理的子路徑下），Bazarr 的 URL 設定就必須包含該子路徑，否則會出現 404 錯誤。第二，Bazarr 的掃描頻率不宜過高，否則在媒體庫龐大時容易造成 API 負載過重；一般建議設定為每 12 至 24 小時掃描一次，並搭配「即時監聽」功能（若 Sonarr 或 Radarr 支援 webhook）。第三，Bazarr 寫入字幕後，並不會自動觸發媒體伺服器（如 Plex、Jellyfin）重新掃描，若希望字幕即時生效，通常需要額外設定媒體伺服器的自動掃描或使用 webhook。

此外，Bazarr 也支援「字幕同步」功能，能針對時間軸偏移的字幕進行自動校正，這對於來源品質參差不齊的華語字幕尤其有用。整體而言，Bazarr 的設計哲學是「深度整合、被動補完」，它不追求成為獨立運作的服務，而是盡可能融入既有的 Sonarr／Radarr 工作流。

Prowlarr 深度解析：索引器的統一管理入口

Prowlarr 的出現，是為了解決一個在 Servarr 使用者圈中存在已久的痛點：當你同時使用 Sonarr、Radarr、Lidarr、Readarr 等多套工具時，每一套都必須各自設定索引器（Indexer），而且每當新增或修改一個索引器，就得在每一套工具中重複操作。這不僅耗時，還容易出現設定不一致的情況。Prowlarr 的定位就是「索引器的中央管理台」，讓使用者只需在一個地方維護索引器清單，就能自動同步到所有下載客戶端與媒體管理工具。

索引器管理與同步機制：單一來源、多點部署

Prowlarr 的核心概念是「索引器即資源」。使用者可以在 Prowlarr 中新增各種索引器，包含公開追蹤器（如 The Pirate Bay、1337x、RARBG 的替代站）、私有追蹤器（如 TorrentLeech、PassThePopcorn）、Usenet 索引器（如 NZBgeek、DrunkenSlug），以及透過 Cardigann 定義檔支援的長尾站點。每個索引器都可以設定類別、優先級、是否啟用、以及對應的 API 金鑰或登入資訊。Prowlarr 會定期測試每個索引器的可用性，並在介面上以顏色標示狀態。

同步機制是 Prowlarr 最關鍵的設計。在 Prowlarr 的「設定 → 應用程式」頁面中，使用者可以新增 Sonarr、Radarr、Lidarr、Readarr 等「應用程式」，填入對應的 URL 與 API Key。完成後，Prowlarr 會自動將索引器清單推送給這些應用程式，並且在索引器新增、修改、刪除時即時同步。這意味著，使用者不再需要手動在每一套工具中重複新增索引器，大幅降低了維護成本。Prowlarr 也支援「應用程式同步」的排程設定，可以選擇即時同步或定時同步，兼顧即時性與效能。

與下載器、Sonarr／Radarr 的整合方向

Prowlarr 的整合方向與 Bazarr 正好相反。Bazarr 是「向內整合」，從 Sonarr／Radarr 讀取媒體庫清單；Prowlarr 則是「向外推送」，將索引器設定主動散佈到多個應用程式。這種「一對多」的推送模型，讓 Prowlarr 成為整個生態系中唯一具備「中央控制」角色的工具。除了 Sonarr、Radarr 之外，Prowlarr 也能與下載器（如 qBittorrent、Transmission、SABnzbd）整合，主要用於測試索引器的下載連結是否有效，以及處理某些需要透過下載器驗證的私有站點。

值得一提的是，Prowlarr 本身並不負責下載或整理媒體，它只負責「告訴其他工具去哪裡找資源」。這種職責單一的設計，讓 Prowlarr 的資源佔用相對較低，卻能顯著改善整體系統的可維護性。對於同時運行多套 Servarr 工具的使用者來說，Prowlarr 幾乎是必備的基礎設施。

FlareSolverr 與反爬蟲處理：進階索引器的通關密語

許多索引器（尤其是公開追蹤器）會使用 Cloudflare 等反爬蟲機制來阻擋自動化請求。Prowlarr 本身無法繞過這些機制，但可以透過整合 FlareSolverr 這個外部服務來處理。FlareSolverr 是一個以 Puppeteer 為基礎的代理伺服器，能夠模擬瀏覽器行為、通過 JavaScript 挑戰，並將結果回傳給 Prowlarr。在 Prowlarr 的「設定 → 索引器」中啟用 FlareSolverr 並填入其位址後，原本會回傳 403 或 Cloudflare 驗證頁面的索引器，就有機會恢復正常運作。

這項整合是 Prowlarr 相對 Bazarr 的獨特優勢之一。Bazarr 雖然也有部分供應商需要處理反爬蟲，但其規模與複雜度遠低於 Prowlarr 所面對的索引器生態。對於重度依賴公開追蹤器的使用者來說，FlareSolverr 的設定幾乎是 Prowlarr 部署過程中的必經環節。需要提醒的是，FlareSolverr 會消耗較多記憶體與 CPU，建議以獨立容器部署，並避免與 Prowlarr 共用過於緊縮的資源限制。

核心差異比較：字幕整合 vs 索引器整合

理解了兩套工具各自的運作原理後，我們可以從多個維度進行系統性的比較。以下將分別從「功能定位」、「資料流方向」、「設定複雜度與維護成本」三個角度切入，並在最後整理成一張對照表，方便讀者快速掌握重點。

功能定位差異：補完內容 vs 管理來源

Bazarr 與 Prowlarr 最根本的差異，在於它們所處理的「資料類型」完全不同。Bazarr 處理的是「字幕」這種附屬於媒體檔案的後設資料，它的價值在於讓已經下載完成的影片變得更完整、更易於觀賞。Prowlarr 處理的則是「索引器」這種指向外部資源的設定資訊，它的價值在於讓搜尋與下載的過程更順暢、更一致。前者關注的是「影片之後」，後者關注的是「影片之前」。

這種定位差異也反映在它們的觸發時機上。Bazarr 是在媒體檔案已經存在於硬碟後才開始工作，它的輸入是 Sonarr／Radarr 的媒體庫狀態；Prowlarr 則是在使用者（或 Sonarr／Radarr）發起搜尋請求時才發揮作用，它的輸出是索引器設定與搜尋結果。換句話說，Bazarr 是「收尾型」工具，Prowlarr 是「開場型」工具，兩者在時間軸上幾乎沒有重疊。

資料流與整合方向差異：向內讀取 vs 向外推送

資料流方向是另一個關鍵差異。Bazarr 的整合模式是「向內讀取」：它主動向 Sonarr 與 Radarr 的 API 查詢媒體庫資訊，並將下載完成的字幕寫回對應的資料夾。這種模式讓 Bazarr 成為一個「依賴者」，它必須依附在 Sonarr／Radarr 之下才能運作。Prowlarr 的整合模式則是「向外推送」：它將索引器設定主動推送給 Sonarr、Radarr 等應用程式，成為一個「供應者」。這種模式讓 Prowlarr 成為整個生態系的上游，其他工具反而依賴它來取得索引器清單。

這個差異在實務上會造成什麼影響？首先，Bazarr 的部署順序必須在 Sonarr／Radarr 之後，否則無法讀取媒體庫；Prowlarr 則可以在 Sonarr／Radarr 之前或之後部署，但建議先完成 Prowlarr 的索引器設定，再讓 Sonarr／Radarr 接收同步。其次，Bazarr 的故障影響範圍相對局部——即使 Bazarr 掛掉，Sonarr／Radarr 仍可正常下載與整理，只是字幕會缺漏；Prowlarr 的故障影響範圍則較廣——若 Prowlarr 掛掉，新索引器無法同步，但既有的索引器設定仍會保留在 Sonarr／Radarr 中，因此不至於完全中斷。理解這些影響範圍，有助於在資源有限時決定優先修復哪一套服務。

設定複雜度與維護成本比較

從設定複雜度來看，Bazarr 的入門門檻較低。基本流程只需填入 Sonarr／Radarr 的 URL 與 API Key，選擇語言，啟用幾個字幕供應商，就能開始運作。真正的調校重點在於「字幕品質」，例如繁體中文的供應商優先級、機器翻譯的過濾、時間軸同步等，這些屬於「進階優化」而非「必要設定」。Prowlarr 的入門門檻則相對較高，因為它涉及的索引器種類繁多，每個索引器的設定方式不盡相同（有些需要 API Key、有些需要帳號密碼、有些需要 cookie、有些需要 FlareSolverr），而且索引器的可用性經常變動，需要定期維護與測試。

從維護成本來看，Bazarr 的維護相對單純，主要是定期檢查字幕供應商是否失效、評分機制是否需要調整。Prowlarr 的維護則需要持續關注索引器的狀態，尤其是公開追蹤器經常更換網域或調整反爬蟲策略，使用者可能需要定期更新 Cardigann 定義檔或調整 FlareSolverr 設定。這也解釋了為什麼社群中常有「Prowlarr 設定一次之後就不太想動」的說法——它的設定成本高，但一旦穩定運行，帶來的效益也相當顯著。

比較項目

Bazarr

Prowlarr

核心功能

字幕自動搜尋、下載、同步

索引器集中管理與同步

處理對象

字幕檔（後設資料）

索引器設定（來源資訊）

整合方向

向內讀取 Sonarr／Radarr 媒體庫

向外推送索引器至多個應用程式

觸發時機

媒體檔案下載完成後

搜尋請求發起前

依賴關係

依賴 Sonarr／Radarr

被 Sonarr／Radarr 依賴

入門難度

較低

較高

維護重點

字幕供應商可用性、評分機制

索引器可用性、反爬蟲處理

特殊整合

字幕時間軸同步

FlareSolverr 反爬蟲代理

實務部署建議與常見問題

了解了理論層面的差異後，接下來要談的是實務面的部署與除錯。無論你是使用 Docker、裸機安裝，還是透過 NAS 的套件管理器部署，以下幾個環節都是 Bazarr 與 Prowlarr 使用者最常遇到的問題，值得在正式上線前先做好準備。

Docker 部署要點：網路模式、路徑映射與權限

Docker 是目前最主流的部署方式，而網路模式與路徑映射則是最容易出錯的兩個環節。首先，Bazarr 與 Prowlarr 都需要能與 Sonarr、Radarr 互相通訊，若使用 Docker 的 bridge 網路模式，建議將所有 Servarr 容器放在同一個自訂網路中，並透過容器名稱互相連線，避免使用 localhost 或 127.0.0.1 而導致連線失敗。若使用 host 網路模式，則需注意連接埠衝突問題。其次，路徑映射必須確保 Bazarr 與 Sonarr／Radarr 看到的是「相同的媒體路徑」，否則 Bazarr 寫入字幕時會因為路徑不一致而失敗。舉例來說，若 Sonarr 容器將媒體庫掛載為 /media/tv，Bazarr 容器也必須掛載為 /media/tv，兩邊的路徑字串必須完全一致。

權限問題同樣不容忽視。Bazarr 與 Prowlarr 的容器通常以非 root 使用者運行，若媒體資料夾的擁有者與容器使用者不一致，就可能出現「無法寫入字幕」或「無法讀取索引器設定」的錯誤。建議在 Docker Compose 中明確指定 PUID 與 PGID，並確保這些 ID 對媒體資料夾具有讀寫權限。此外，Prowlarr 若需要整合 FlareSolverr，也應確認兩者位於同一網路中，並在 Prowlarr 設定中填入正確的 FlareSolverr 容器位址。

常見錯誤與排查：API 連線、字幕不同步、索引器失效

在 Bazarr 方面，最常見的錯誤是「API 連線失敗」。這通常肇因於 URL 設定錯誤（包含或省略了 http:// 前綴、連接埠錯誤、反向代理子路徑未包含），或是 API Key 輸入錯誤。排查時，可以先在瀏覽器中直接開啟 Sonarr／Radarr 的 API 端點，確認能否正常回應，再比對 Bazarr 中的設定。另一個常見問題是「字幕下載後沒有出現在媒體伺服器中」，這通常是因為媒體伺服器（Plex、Jellyfin、Emby）的快取機制所致，需要手動觸發重新掃描，或設定媒體伺服器的自動掃描排程。

在 Prowlarr 方面，最常見的錯誤是「索引器測試失敗」。這可能來自多種原因：索引器網域變更、反爬蟲機制升級、API Key 過期、或是 FlareSolverr 未正確設定。排查時，建議先查看 Prowlarr 的日誌（Log），確認錯誤類型是 403（反爬蟲）、404（網域變更）、還是 401（驗證失敗）。若是反爬蟲問題，可嘗試啟用 FlareSolverr；若是網域變更，則需更新 Cardigann 定義檔或手動修改索引器設定。另一個常見問題是「Sonarr／Radarr 沒有收到索引器同步」，這通常是因為「應用程式」設定中的 URL 或 API Key 錯誤，或是同步排程尚未觸發，可以先手動點擊「同步」按鈕測試。

最後，建議所有使用者養成「定期備份設定」的習慣。Bazarr 與 Prowlarr 都支援設定匯出與匯入，特別是在進行版本升級或遷移主機前，先備份設定檔可以省下大量重新設定的時間。對於 Prowlarr 而言，索引器清單往往是長時間累積的成果，一旦遺失就需要重新逐一設定，備份的重要性不言而喻。

結論：兩者互補而非替代，依需求選擇整合策略

回到本文的核心問題：Bazarr 與 Prowlarr 的整合差異究竟在哪裡？總結來說，Bazarr 是「字幕層」的整合工具，它以 Sonarr／Radarr 的媒體庫為基礎，向內補完缺失的字幕；Prowlarr 則是「來源層」的整合工具，它以索引器為核心，向外推送設定到多個應用程式。兩者的功能完全不重疊，卻共同構成了 Servarr 生態系中「前後包夾」的完整體驗。

對於剛入門的使用者，建議的部署順序是：先完成 Sonarr／Radarr 的基本設定，接著導入 Prowlarr 集中管理索引器，最後再加入 Bazarr 處理字幕。這樣的順序可以讓你在每個階段都有一個可運作的系統，避免一次導入太多工具而導致除錯困難。對於進階使用者，則可以進一步整合 FlareSolverr、設定 webhook 自動化、調校字幕評分機制，讓整套系統達到接近「無人值守」的境界。

最後要提醒的是，Bazarr 與 Prowlarr 都是活躍的開源專案，功能與介面會隨著版本更新而調整。本文所描述的架構與設定邏輯，在可預見的未來應該仍然適用，但具體的選項名稱與操作步驟，仍建議以官方文件與社群 wiki 為準。只要掌握「Bazarr 管字幕、Prowlarr 管索引器」這個核心原則，無論工具如何演進，你都能快速找到對應的設定位置，讓自架媒體伺服器持續穩定運行。

整體而言，這場「字幕 vs 索引器」的比較並不是一場零和競賽，而是一場分工合作。Bazarr 讓你的影片看得懂，Prowlarr 讓你的影片找得到，兩者各司其職，缺一不可。與其問「哪一個比較重要」，不如問「我的系統目前缺的是哪一塊」，然後針對缺口選擇對應的工具，這才是自架媒體伺服器最務實的整合策略。

```

🏠 返回首頁