NAS組播轉單播：udpxy、msd_lite、rtp2httpd怎麼選

NAS組播轉單播：udpxy、msd_lite、rtp2httpd怎麼選

NAS教程
17NAS17NAS
2026/9/18
178 閱讀

目標：讓區域網路裡任意裝置（電腦、手機、電視）直接看 IPTV 直播，不用機上盒
效果：一次部署，全家所有裝置都能看；換台速度、並行路數自己可控
難度：中等 —— 需要先完成光纖數據機改橋接，再在 NAS 上跑一個 Docker 容器
耗時：約 30 分鐘

一、為什麼需要「組播轉單播」

組播是什麼

電信商的 IPTV 用的是組播（Multicast）：一份資料流，從源頭發一次，
網路裡所有「訂閱了」這個頻道的裝置同時收到。

好處是省頻寬 —— 100 個人看同一個頻道，電信商只發一份資料。

問題：一般裝置播不了組播

組播依賴 IGMP 協定，而這套協定只在區域網路內部有效。
問題在於：

  • 手機、平板、智慧電視大多不支援 IGMP
  • 就算支援，也不支援電信商那套帶 VLAN 的組播
  • 跨網段（例如 WiFi 裝置）就更播不了

結果就是：你的機上盒能看，但你的手機、電腦、Apple TV 都看不了。

組播轉單播解決什麼

在區域網路裡跑一個轉發服務，它：

  1. 用 IGMP 訂閱組播流
  2. 把組播流轉成普通的 HTTP 單播流
  3. 任何裝置只要能用播放器打開一個 HTTP 位址，就能看
電信商組播流  ->  [NAS 上的轉發服務]  ->  HTTP 單播  ->  任意裝置
rtp://239.x.x.x:4120              http://NAS_IP:5893/rtp/239.x.x.x:4120

前置的光纖數據機改橋接步驟，參考 光纖數據機改橋接教學。

二、前置條件（必須先做完這兩步）

1. 光纖數據機改橋接

這一步是必須的。 如果光纖數據機還在路由模式，IPTV 的 VLAN 資料到不了你的 NAS。

完整步驟見 光纖數據機改橋接教學，這裡只說要點：

  • 拿到光纖數據機超級密碼
  • 備份原設定
  • 把上網的 VLAN 改成橋接，由自己的路由器撥號
  • 關鍵：IPTV 的 VLAN 保持不動，不要一起改橋接

2. 路由器／軟路由開啟 IGMP 代理

在路由器的 IPTV 設定裡，打開 IGMP Proxy（或者叫 IGMP Snooping／組播代理）。

不同系統的位置：

系統 位置 OpenWrt 網路 → 介面 → IPTV 介面 → 勾選 IGMP Proxy 愛快 進階應用 → 組播設定 華碩 內部網路 → IPTV → 啟用 IGMP Proxy 群暉路由 通常不需要額外設定

3. 拿到電信商的組播位址

組播位址因地區和電信商而異，沒有通用值。 取得方式：

  1. 抓包：在機上盒正常播放時，用路由器抓包，找 IGMP Join 封包
  2. 上網搜：搜「[你的城市] [電信商] iptv 組播位址」
  3. 問裝機師傅：有時能直接問到

你需要兩個東西：

  • VLAN ID（例如 85、3961，各電信商不同）
  • 組播 IP 和連接埠（例如 239.125.2.66:4120）

順手檢測一下目前的網路環境：NAT 類型檢測工具

三、三個方案怎麼選（核心）

先說結論：這三個工具做的是同一件事，差別在維護狀態和效能。

方案一：udpxy —— 最老牌，資料最多

這是中文 IPTV 圈用了十幾年的方案。

項 說明 優點 Docker 映像檔成熟（ifmm/udpxy 有 19,691 次拉取）、教學最多、踩坑資料全 缺點 官方已 4 年未維護 適合 初次嘗試、單一裝置觀看

必須知道的事實：udpxy 官方 README 自己寫著：

udpxy has not been extended or supported for 4+ years,
having been replaced by Gigapxy - a superior enterprise-oriented product.

這不代表它不能用 —— 它穩定跑了十幾年，只是不再更新了。
但如果你追求更好的效能或新特性，看下面兩個。

方案二：msd_lite —— udpxy 的現代替代

名字來自 Multi Stream daemon，是社群裡公認的 udpxy 替代品。

項 說明 優點 更輕量、資源占用更低、效能更好 缺點 中文資料比 udpxy 少 適合 OpenWrt 路由器、需要長期穩定運行

如果你在恩山之類的論壇搜「udpxy 替代」，第一個被推薦的就是它。

方案三：rtp2httpd —— 功能最全

這個專案的定位就是「udpxy 的現代化版本」，作者在 V2EX 上發表過。

項 說明 優點 支援 FCC 快速換台協定、支援 RTP/RTSP 多種協定 缺點 設定比 udpxy 稍複雜 適合 多裝置並行、在意換台速度

對比總結

維度 udpxy msd_lite rtp2httpd 維護狀態 停止（4 年+） 活躍 活躍 上手難度 最低 中 中高 資源占用 中 低 中 換台速度 一般 好 最好（FCC） 中文資料 最多 中 少 推薦情境 首次嘗試 長期運行 追求體驗

我的建議：

  • 第一次玩：用 udpxy，資料多，出問題好搜
  • 跑穩定後想優化：換 msd_lite
  • 多裝置 + 在意換台速度：上 rtp2httpd

下面用 udpxy 示範，因為它最容易上手，且遷移到另外兩個時思路完全一樣。

四、實戰：在 NAS 上用 Docker 部署 udpxy

為什麼用 NAS 而不是路由器

路由器也能跑，但 NAS 有幾個優勢：

  • CPU 通常更強，多路並行更穩
  • 24 小時開機，不用管路由器負載
  • Docker 管理方便，升級／回滾容易
  • 順便還能跑其他的（例如媒體庫）

docker-compose.yml

在 NAS 的 Docker 目錄下新建一個 udpxy 資料夾，放這個檔案：

version: "2"
services:
  udpxy:
    image: ifmm/udpxy
    container_name: udpxy
    network_mode: host
    restart: always

然後啟動：

docker-compose up -d

需要產生更複雜的 compose 設定？用 docker-compose 產生器。

三個必須注意的點

1. network_mode: host 是必須的

這是最容易踩的坑。 udpxy 需要直接監聽組播流量，
如果用了 Docker 的預設橋接網路，它根本收不到組播封包。

所以 network_mode: host 不能省。

2. 連接埠 5893

udpxy 固定用 5893 連接埠，同時提供兩個功能：

路徑 用途 http://NAS_IP:5893/status/ 查看運行狀態、目前訂閱數 http://NAS_IP:5893/restart/ 重啟服務 http://NAS_IP:5893/rtp/組播IP:連接埠 轉單播後的播放位址

3. NAS 的網路設定

需要保證 NAS 和 IPTV 的 VLAN 在同一個二層網路裡。
兩種常見做法：

  • NAS 雙網口：一個口接一般網路，一個口接 IPTV VLAN
  • 交換器 Trunk：在交換器上把 IPTV VLAN 透傳給 NAS

如果你用旁路由方案，參考 OpenWrt 旁路由部署教學。

驗證是否成功

第一步：瀏覽器打開狀態頁

http://NAS_IP:5893/status/

能看到統計資訊就說明服務跑起來了。

第二步：測試一個頻道

# 假設組播位址是 239.125.2.66:4120
curl -I 'http://NAS_IP:5893/rtp/239.125.2.66:4120'

回傳 HTTP/1.0 200 OK 就說明轉發正常。

五、在播放器裡使用

位址格式

記住這個轉換規則就夠了：

原組播位址 轉成播放位址 rtp://239.125.2.66:4120 http://NAS_IP:5893/rtp/239.125.2.66:4120

電腦端

播放器 用法 VLC 媒體 → 開啟網路串流 → 貼上位址 PotPlayer Ctrl+U → 貼上位址 MPV mpv http://NAS_IP:5893/rtp/...

電視／機上盒

  • Kodi：安裝 PVR IPTV Simple Client 外掛，匯入 m3u 播放清單
  • 智慧電視：用電視內建播放器或裝 VLC for Android TV
  • Apple TV：用 VLC 或 Infuse

建議做法：把所有頻道的位址整理成一個 .m3u 檔案，
播放器匯入一次就能看全部頻道，不用每次輸入位址。

#EXTM3U
#EXTINF:-1, CCTV-1 綜合
http://NAS_IP:5893/rtp/239.125.2.66:4120
#EXTINF:-1, CCTV-2 財經
http://NAS_IP:5893/rtp/239.125.2.67:4120

六、哪些 NAS 跑得動

好消息：組播轉單播是 IO 密集型任務，對 CPU 要求不高。

壞消息：多路 4K 並行時，CPU 和網路都有要求。

大致參考（非實測，請依自身情況驗證）

情境 大致硬體需求 單路 1080p 幾乎所有 NAS 都行（包括 ARM 低階型號） 2-3 路 1080p Intel N100 等級的 x86 NAS 很輕鬆 單路 4K N100 以上 多路 4K 並行 建議 J4125 以上，且需要 2.5G 網口

幾個容易被忽略的點：

  1. 網口比 CPU 更重要 —— Gigabit 網口跑 3 路 4K 就吃緊了
  2. NAS 上的其他服務會搶資源 —— 如果同時跑 Plex 轉碼，要留餘量
  3. ARM NAS 也能跑 —— ifmm/udpxy 映像檔支援 arm64 和 armv7

想查具體型號的跑分？看 NAS CPU 效能天梯圖 的 CoreMark 實測資料。

七、常見問題解答

Q1：播不出來，一直轉圈？

按這個順序排查：

  1. 先測狀態頁（/status/）能否打開 —— 打不開說明容器沒跑起來
  2. 確認 network_mode: host —— 這是最常見的原因
  3. 確認組播位址正確 —— 抓包核對，不要靠記憶
  4. 確認路由器開了 IGMP 代理
  5. 確認 NAS 在 IPTV 的 VLAN 裡

Q2：能看但很卡，怎麼排查？

先分清是「源卡」還是「網路卡」：

  • 換一個頻道試試 —— 如果只有某個頻道卡，是源的問題
  • 用有線連接試 —— 如果 WiFi 卡、有線不卡，是無線頻寬問題
  • 看狀態頁的流量統計 —— 確認轉發本身沒掉包

Q3：換台要等 3-5 秒，正常嗎？

正常。 組播轉單播的換台延遲主要來自：

  • 播放器重新發起 HTTP 請求
  • 服務重新 IGMP Join
  • 等待關鍵畫面（I 幀）

想更快：用支援 FCC 快速換台協定的 rtp2httpd。

Q4：為什麼只有部分頻道能看？

常見原因：

  • 頻道清單不全 —— 你抓到的組播位址只是當時機上盒訂閱的
  • 部分頻道是加密的 —— 需要機上盒授權，轉發不了
  • VLAN 不對 —— 有些電信商的直播和回看隨選在不同 VLAN

Q5：手機連 WiFi 能看嗎？

能，只要手機和 NAS 在同一個區域網路。
但如果 NAS 在 IPTV VLAN 而手機在一般網路，需要路由器做跨 VLAN 路由。

Q6：會占用很多頻寬嗎？

關鍵概念：組播在區域網路內只占一份頻寬，不管多少人看。
但轉成單播後，每路觀看各占一份。

情境 區域網路頻寬占用 1 路 1080p 約 8-15 Mbps 1 路 4K 約 25-40 Mbps 3 路 1080p 同時看 約 24-45 Mbps

Gigabit 區域網路完全夠用，但如果是 WiFi 需要注意訊號品質。

Q7：電信商會發現我在內網轉發嗎？

技術上：轉發發生在你的區域網路內部，電信商端看到的是和你機上盒一樣的 IGMP 訂閱。
實際上：有些電信商會限制同時訂閱數（例如只允許 2 路），超過會拒絕。

建議：不要過度並行，這既影響體驗也可能觸發限制。

Q8 補充：多撥會影響 IPTV 嗎？

會。 如果你同時用了單線多撥，多撥產生的多線路出口可能干擾 IPTV 的 VLAN，
導致機上盒無法透過 IGMP 組播。

建議：把 IPTV 介面排除在 mwan3 負載平衡之外，具體做法參考
OpenWrt單線多撥教學：mwan3實現網速疊加。

Q8：群暉／威聯通／極空間都能跑嗎？

都能，只要能跑 Docker。

品牌 說明 群暉 Container Manager 裡直接匯入 compose 威聯通 Container Station 支援 compose 極空間 支援 Docker，但介面限制較多 綠聯／飛牛 都支援

唯一的差異是網路設定方式 —— 單網口和雙網口的設定不同。

八、總結

三個方案一句話版

方案 一句話 udpxy 老牌穩定，資料最多，第一次玩選它 msd_lite 更輕更快，跑穩定後換它 rtp2httpd 換台最快，多裝置追求體驗選它

最容易踩的三個坑

  1. 忘了 network_mode: host —— 收不到組播，表現為「一直轉圈」
  2. 光纖數據機還在路由模式 —— VLAN 到不了 NAS，先做橋接
  3. 沒開路由器 IGMP 代理 —— 組播封包進不了你的區域網路

核心價值

這套方案的本質是把電信商的 IPTV 從「一台機上盒」解放出來，
變成「區域網路裡的一個 HTTP 流」——從此任何裝置都能看，
而且可以自由選擇播放器、自由組織頻道清單。

部署成本幾乎為零（NAS 本來就在跑），換來的體驗提升很明顯。

返回文章列表