SyncTV 1.0 之後，開源遠端一起看電影變成要自己架的伺服器

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

異地戀的情侶想一起看同一部片，暫停和快轉都要同步，這件事在技術上不難，難在找到一個不必把片源交給第三方、又能自己掌控的方案。SyncTV 是這個題目上少數持續活躍的開源答案：一個用 Rust 寫的同步觀影平台，一群人進同一個房間，誰暫停、誰拖進度，所有人都停在同一格畫面。專案從 2023 年 10 月做到現在，主倉庫在撰稿當下約有兩千四百七十顆星、兩百四十二個 fork，容器映像在 Docker Hub 上累計約十八萬九千次拉取。

Pin

如果你最近才聽到這個工具，找到的資訊很可能還停留在 2025 年的舊印象：下載一支執行檔就能跑，還有官方示範站可以逛。這些敘述在 2026 年 8 月之後全部過期。SyncTV 在 8 月 7 日推出 1.0.0，接著 8 月 8 日與 8 月 12 日連發兩個修正版，而 1.0 是一次砍掉重練的大改版。這篇文章以官方文件、GitHub 儲存庫與映像登錄的公開資料為本，整理這次改版實際改了什麼；我沒有實際把伺服器架起來跑，牽涉播放體感與延遲的說法，一律標明為官方文件或待驗證。

一支執行檔換成三個容器

舊版 SyncTV 的最後一個版本，是 2025 年 9 月 22 日的 v0.9.15。那個年代的自架體驗圍繞著執行檔：Releases 頁面連同原始碼包在內一共六十三個附件，Windows、macOS、Linux、FreeBSD 各種架構的預編譯執行檔任你挑，單檔約六十四到七十一 MB。v1.0.0 之後的 Releases 完全變了樣：三個新版本各自只附一個七十幾位元組的 image-digest.txt，內容是指向容器映像的摘要值，伺服器本體的預編譯執行檔不再隨 Release 發布。

官方安裝文件現在只提供兩條路：Docker Compose 或 Helm。倉庫裡的 docker-compose.yml 會一次啟動三個服務：SyncTV 本體、postgres:18 資料庫、redis:8 快取。PostgreSQL 在官方文件裡被定義為主要的持久性儲存層，使用者、房間、播放清單、媒體詮釋資料、稽核資料與來源憑證都存在裡面，屬於必要依賴。Redis 在單機模式可以省略，官方寫明沒有 Redis 時會改用記憶體 fallback，重開機後這些短期狀態會消失，叢集模式則一定要 Redis。

Pin

更硬的一條線寫在 v1.0.0 的 release notes 第一行：從 v0.x.x 升級到 v1.x.x 辦不到，需要全新安裝。舊的使用者帳號、房間與歷史播放清單都帶不過去，搬到 1.0 一律重來。對已經架了 v0.9 的人來說，這次升級沒有任何折扣可打。

Pin

語言換掉，家也搬了

這次重寫連程式語言都換了。v0.9.15 的倉庫根目錄放的是 go.mod 與 main.go，是個 Go 專案；v1.0 的倉庫變成一個 Rust workspace，拆成二十多個 crate：核心的 synctv-core、代理層 synctv-proxy、即時同步層 synctv-realtime、叢集層 synctv-cluster、媒體來源層 synctv-media-providers 各自獨立，資料庫遷移腳本與 .sqlx 查詢驗證也一併進了倉庫。

發布工程也一併升級。主倉庫的 Release 頁面變成用戶端下載入口，伺服器與用戶端的版本協調移到另一個 synctv-release 倉庫，裡面放的是日期版次的鎖定檔與 checksum，容器映像登錄則維持 main、版號與 commit 雜湊多種標籤並行。

搬家不只發生在程式碼。專案的官方網域從 synctv.wiki 換到 syncs.tv，新文件站 docs.syncs.tv 用 Astro Starlight 架了完整的中英文文件；舊示範站 demo.synctv.wiki 已經連不上，舊文件站 docs.synctv.wiki 還掛著，內容卻停在舊版。照著舊資料操作的人，第一步就會撞牆。

用戶端也分了家。2026 年 1 月新開的 synctv-app 倉庫用 Flutter 打造跨平台用戶端，Android、iOS、macOS、Windows、Linux 都有官方建構，採 Apache-2.0 授權，倉庫描述直接寫著它服務的對象是異地情侶的同步觀看需求。用戶端不綁任何固定伺服器，裝好之後填入你自架的伺服器地址就能用，官方沒有提供公共伺服器；iOS 一般使用者走 App Store 版本，IPA 檔只留給開發與企業分發。

房間、來源與線路：同步觀影的三層結構

SyncTV 的核心抽象是清楚的。最上層是房間，成員在房間裡共享同一份播放狀態，誰暫停、誰快轉、誰調倍速，狀態即時廣播給所有人。中間層是 Provider，也就是媒體來源轉接器，官方清單涵蓋 Bilibili、Twitch、YouTube、抖音、TikTok、虎牙、鬥魚、AcFun、CCTV 這類公共平台，也涵蓋 Alist、Cloudreve、Emby 與 Jellyfin、群暉、威聯通、FNOS、Nextcloud、Seafile、TrueNAS 這類自架儲存與媒體庫，外加直鏈與 RTMP、HLS、HTTP-FLV、RTSP 直播來源。會把 AList 當來源的人，可以想成它接的就是AList 這類把雲端硬碟縫合成自架入口的工具，SyncTV 站在它的下游當播放層。

最底層是線路政策，這是 1.0 文件裡值得細讀的一段。每個來源產生播放資訊時可以走直連或代理，官方定義了 Auto、Prefer、Only、DirectPrefer、DirectOnly 五種模式。Auto 的規則以認證資訊保護為先：公開資源傾向直連；Bilibili 的影片與直播依賴簽名網址、Cookie 與 Referer，一律只產生代理線路；NAS 與雲端硬碟來源依賴 Provider 工作階段，同樣只產生代理。換句話說，愈需要登入或簽名的來源，流量就愈集中在你的伺服器上。

代理層的邊界官方也寫得明白：proxy 只快取 Range 切片、不做整檔快取；只轉發來源端明確給出的標頭，瀏覽器送來的 Cookie 或身分標頭不會自動轉給上游。官方文件同時提醒，第三方來源、CDN 與媒體源的長期穩定它無法保證，Bilibili 的上游政策、Cookie、Referer、User-Agent 與 Range 行為變化都可能影響播放。這段提醒有實際佐證：8 月中旬的 commit 記錄裡，就有兩筆修的正是 Bilibili 播放可靠性與字幕修復。習慣把直播來源收進單一視窗的人，可以對照DTV 那篇拆過的直播來源依賴，上游改版吃掉播放器的風險在這類工具上是共通的。

帳號與權限的設計也有營運規格。官方文件寫明本地二因素依賴通行碼、passkey 或已驗證信箱，OAuth2 只當外部身分、不當本地因素；JWT 的強制撤銷依賴 Redis 的撤銷清單與有效期；8 月 17 日的 commit 還為強度不足的 JWT 金鑰加上警告。房間治理的粒度也切得更細，同一週的兩筆變更把房間可見度和訪客設定拆開，管理者能分開控制誰看得到房間、訪客進來能做什麼。

自己當機房要算的三筆帳

頻寬是最直接的一筆。官方容量規劃文件給的估算式很直白：代理頻寬等於代理使用者數乘上平均碼率再乘上峰值係數。一家人用三五個裝置看自己 NAS 裡的高碼率片源，流量全部穿過伺服器，家用上傳頻寬很快見底；文件也把來源與代理並列為六類容量瓶頸之一，與資料庫、WebSocket 同級。成員間的音訊視訊則走 WebRTC 點對點，伺服器只負責信令與權限，這部分不佔伺服器頻寬，預設推薦的 peer_to_peer 模式可啟用內建 STUN（UDP 3478）。

憑證是更隱形的一筆。伺服器集中保管 Alist token、Emby API key、Bilibili cookie 這類來源憑證，靠一把 credential_encryption_key 加密。官方要求這把金鑰是六十四個十六進位字元、必須長期穩定：金鑰弄丟，已加密的憑證無法可靠還原；金鑰外洩，則要輪替所有相關憑證，並回頭評估資料庫備份的暴露風險。架這套伺服器的人，手上握的是全家的鑰匙圈。

另一組要自己調的旋鈕是限流。文件提供 WebSocket 連線建立限流、登入與 API 限流、聊天訊息限流，以及單一連線的資源訂閱上限；資料庫連線池預設二十條連線，官方提醒副本數乘上連線池不能超過資料庫的總上限。這些數字平常不必動，出狀況時它們就是第一份體檢表。

保留週期則是官方主動交代的部分。文件列出的預設值：聊天訊息有九十天的絕對保留上限，每個房間預設保留五百則；播放歷史保留九十天、每房最多一千條；通知最多保留九十天；被軟刪除的使用者與房間九十天後永久清理。稽核記錄會記下操作者、動作、目標、IP 與瀏覽器識別資訊，官方自己標註這對資安調查是必要的，但也含個人資料。這些邊界一開就寫清楚，比多數同類專案透明。

文件寫給營運者，App 寫給情侶

用戶端與伺服器兩份文件擺在一起，很難不注意到一種張力：用戶端倉庫的介紹寫著異地情侶，伺服器文件卻照著營運手冊的規格在寫。生產部署清單要求資料常駐保存並備份 PostgreSQL、長期保存完整的金鑰組、公用網路入口啟用 HTTPS；維運文件涵蓋容量規劃、金鑰輪替、備份還原，以及滾動更新時長連線的緩衝時間；叢集文件甚至提醒，資料庫、Redis、金鑰與直播模型沒處理好之前，多副本只會放大問題，別為了看起來高可用而過早擴張。判斷這套工具適不適合你的核心就在這裡：它假定有一個人願意扮演營運者。

版本配對是另一個要記住的現實。官方在套件發布說明裡明寫 SyncTV App v1.1.22+21 對應 Server v1.0.2，伺服器與用戶端分開發版、各自升級；文件也說 API 還在早期階段，protobuf、HTTP 欄位與即時訊息格式可能隨版本調整，依賴這些介面的自訂用戶端要納入升級驗證。對只想開房看片的人，這代表每次升級前得先看配對表。

維運面的介面也照平台慣例開好：Prometheus 格式的 metrics、management gRPC 控制面，以及選配的 OpenAPI 文件頁。官方同時劃清界線，management gRPC 與 metrics 只該透過 Unix socket、私網、VPN 或受控的叢集入口曝露，不該面向公用網路。

誰該架，誰該先繞路

我的判斷：家裡已經跑著 NAS 或常駐伺服器、容器對你來說是日常的人，SyncTV 1.0 值得一架。它把同步觀影需要的房間權限、來源轉接、線路政策與資料保留一次做齊，MIT 授權的伺服器搭配 Apache-2.0 的用戶端，沒有付費牆也沒有託管版；Docker Hub 十八萬九千次拉取代表的社群基數，配合 8 月連三個正式版與推進到撰稿當日的 commit 記錄，短期活性不必擔心。

反過來說，臨時想跟朋友看一部片、手上沒有可長期開機的機器的人，1.0 之後的 SyncTV 離下載就能跑的年代已經很遠，門檻實實在在墊高了一級。只在家裡區網自己看片，有VidServe 這種掃碼即看的輕方案；跨網路的同步觀影，免自架又兼顧隱私的選擇本來就少，這也正是 SyncTV 這類專案存在的原因。內容授權要自己負責：SyncTV 只做聚合與代理，房間裡放什麼由營運者決定，公共平台來源的播放穩定性官方也明言無法保證。想在瀏覽器直接播 HLS 來源的人，可以先讀M3U8 Player 那篇的直連播放分析當背景知識。

真要動手，官方倉庫的 Makefile 提供 make compose-init 一次產生資料庫與應用程式的金鑰組，改好環境變數檔裡的啟動管理員通行碼再 make compose-up；文件站的安裝頁另提供網頁版環境檔產生器給不想碰 make 的人。升級前備份資料庫、先在非正式環境驗證資料庫遷移，是官方文件反覆強調的兩個動作。這些步驟我沒有實際走過，出問題時的排解請以官方文件與 GitHub Issues 為準。

常見問題

舊版還能繼續用嗎？

v0.9.15 的執行檔仍留在 Releases 頁面可下載，授權同樣是 MIT。但上游依賴會持續漂移，Bilibili 相關的播放問題在 1.0 之後都修在新的程式碼上，舊版只會愈來愈難對付現在的上游行為，加上官方已無升級路徑，等於每次搬家都要重建。

手機上哪裝？

Android 的通用 APK、macOS 的 DMG、Windows 的 EXE 安裝程式與 Linux 的 DEB 都在 synctv-app 的 GitHub Releases；iOS 一般使用者走 App Store。裝完的第一件事是填入自架伺服器地址，官方沒有公共伺服器可用。

一定要 PostgreSQL 和 Redis 嗎？

依官方文件，PostgreSQL 是必要依賴，Compose 部署會把它包進來；Redis 單機可選，官方把單機加 Redis 稱為生產基線，叢集模式則必需。

一台機器跑得動嗎？

官方容量表把單機加 PostgreSQL 定位為小規模試用或個人長期服務，單機加 Redis 稱為生產基線；多副本留給需要滾動更新或橫向擴展的場景。個人或一個家庭的使用，一台 NAS 或小 VPS 就是官方預設的形態。

授權與費用怎麼算？

伺服器 MIT、用戶端 Apache-2.0，兩者都是寬鬆授權，自用或改作都不必付授權費。專案沒有託管版與付費方案，成本落在你自己的機器、頻寬與維運時間。