NAS组播转单播：udpxy、msd_lite、rtp2httpd怎么选

NAS教程
17NAS17NAS
2026/9/18
4 reads

目标：让局域网里任意设备（电脑、手机、电视）直接看 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 更重要 —— 千兆网口跑 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

千兆局域网完全够用，但如果是 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 本来就在跑），换来的体验提升很明显。

Back to article list