组播总断流？我用 Gemini 3 Pro写了个“续命”神器，可以彻底解决组播断流？

你有没有遇到过这种情况：

很多组播节目正在播放精彩瞬间时，突然画面卡住，然后直接黑屏或提示错误。一查原因，原来是udpxy 服务崩溃重启，或者是组播源稍微抖动了一下。

虽然 udpxy 重启只需要几秒钟，但播放器非常敏感，一旦检测到连接断开（TCP FIN），它就会立即停止播放或自动跳转下一节目。你必须重新点击播放，不仅扫兴，还可能错过了关键时刻。

痛点： 源头断 1 秒，播放器就“死”给你看。

为了解决这个问题，我向 Gemini 3 Pro 提出了需求。经过几轮调教，AI 帮我写出了一个带自动重连和内存缓冲功能的中间件，并打包成了 Docker 镜像。

今天不讲复杂的代码，直接教大家怎么一键部署这个神器！

🛠️ 核心原理：它是怎么“续命”的？

这个容器就像一个蓄水池（Buffer），架在 udpxy 和播放器之间。

1. 蓄水：它会预先下载约 20MB 的视频流数据缓存在内存里。
2. 抗断：当源头断流时，播放器不会收到断开信号，而是继续播放“蓄水池”里的库存。
3. 重连：与此同时，容器会在后台疯狂尝试重连源头。一旦连上，新水进池，播放无缝衔接。

结论：只要源头断开时间不超过 20 秒，你的播放体验就是“无感”的！

🚀 极速部署 (Docker)

不管你是飞牛 NAS 还是 OpenWrt，只要能跑 Docker，一条命令搞定。

镜像已经支持了 x86_64 、 ARM64 、ARMv7架构。

命令行运行

复制以下命令在 SSH 中执行：

docker run -d \
  --name udp-stream \
  --restart=always \
  -p 5000:5000 \
  ghcr.io/cqshushu/udp-stream:latest

• -p 5000:5000: 服务端口，你可以把左边的 5000 改成你喜欢的端口。
• --restart=always: 关键参数，确保容器开机自启，挂了也会自动复活。

📺 如何使用？

部署好后，你需要稍微修改一下你的 M3U 列表或播放地址。

1. 原始模式（不推荐）

假设原本的播放地址是： http://192.168.2.1:4022/udp/239.238.1.1:7980 (这是直接连组播，一旦断开，播放立即停止)

2. 缓冲模式（神器模式）

假设你运行 Docker 的 NAS IP 是 192.168.2.100，端口是 5000。 新的播放地址就变成了：

http://192.168.2.100:5000/live?url=http://192.168.2.1:4022/udp/239.238.1.1:7980

格式说明： http://NAS_IP:5000/live?url= + 原始播放地址

小技巧：你可以用文本编辑器批量替换 M3U 文件中的前缀，瞬间完成升级。

📊 效果对比与状态监控

效果对比

查看运行状态

不知道代理有没有在工作？不知道现在缓存了多少数据？ 浏览器访问：http://192.168.2.100:5000/status

你将看到如下的实时状态面板：

{
  "active_connections": 1,
  "streams": [
    {
      "id": "a1b2c3d4",
      "url": "http://192.168.2.1:4022/udp/...",
      "state": "STREAMING",          <-- 当前状态：正在拉流
      "uptime_seconds": 300,         <-- 已经运行了多久
      "reconnect_count": 1,          <-- 帮你挡了几次断流
      "buffer_usage_percent": 98.5,  <-- 蓄水池满了，非常稳
      "total_mb": 150.5
    }
  ]
}

• reconnect_count: 这个数字就是它默默守护你的次数。
• buffer_usage_percent: 只要不是 0%，你就不会卡。

📝 总结

借助 AI 的力量，我们用极低的成本解决了 IPTV 最头疼的断流问题。这个 Docker 镜像非常轻量，几乎不占用 CPU，建议所有使用 udpxy 转单播的朋友都挂载一个，给你的看球体验上一道保险！

镜像拉取地址： ghcr.io/cqshushu/udp-stream:latest

觉得好用的话，别忘了点个赞！