几分钟验完 500 个直播源：iptv-checker 部署、检测与定时巡检指南-开发者社区

几分钟验完 500 个直播源：iptv-checker 部署、检测与定时巡检指南

【免费下载链接】iptv-checkerIPTV checker tool for Docker && CMD, check your playlist is available项目地址: https://gitcode.com/GitHub_Trending/ip/iptv-checker

周日午后你在播放器里切台，体育频道全部转圈。打开那份 M3U 列表，里面还是三个月前收的链接，一半早就不通了。

逐个点开验证？500 个频道要一下午。这种活可以交给程序：iptv-checker 是一个开源的 IPTV 源检测工具，把列表里的每个地址批量验一遍，再把可用的部分导出成新列表。

一句话定位：它是跑在你自己机器上的播放列表体检工具，适合手里常年攥着几份 IPTV 源、需要定期清理失效链接的人。

检测原理不复杂：工具把列表里的每个 URL 当成待测目标，并发地发 HTTP 请求，按响应状态和超时判定是否在线。想更严格一点，可以开启 FFmpeg 强制检测，让工具真正拉一段流，确认"能连上"和"能播放"是两回事。M3U、M3U8、TXT 三种格式的列表都能直接喂进去。

Docker 是最省事的路径，两条命令：

docker pull zmisgod/iptvchecker docker run -d -p 8081:8089 --name iptv-checker zmisgod/iptvchecker

图省事的话直接用仓库自带的 docker-compose.yaml，端口映射 8081:8089 和开机自启都配好了，docker-compose up -d一条命令即可。

启动后浏览器打开http://127.0.0.1:8081进入管理界面。首次使用建议按这个顺序做三件事：

基线列表是后面一切对比的前提。没有它，"源是不是挂了"只能靠感觉。

按实际使用频率从高到低拆开讲。

把列表交给任务后，界面以表格列出每个频道的状态，在线和失效一眼可分。检测是并发执行的，进度实时刷新，大列表也不用守着页面。

检测完的核心动作是导出。支持 M3U 和 TXT 两种格式；4.4.0 版本起还能把 IPv4 与 IPv6 的结果分开输出，家里走 IPv6、外网走 IPv4 时，两份列表各取所需。

不想每次手动点检测，就把任务挂进后台调度，设定周期后到期自动执行，结果持续更新。4.7.0 起后台任务支持并发执行，5.0.0 修复了单源检查无硬超时导致的任务卡死问题——如果你挂的是长周期任务，建议顺手确认一下当前版本。

默认检测只看 HTTP 层，有的源返回 200 但流根本播不了。在任务设置里打开 FFmpeg 强制检测，工具会实际拉流验证。代价是速度变慢、占用变高，适合列表不大、或对播放质量有硬性要求的场景。超时时间也在这里按源的质量单独配置。

场景一：CI 里做质量门禁。如果你维护的订阅源要分发给别人，可以把 CLI 版本接进流水线，每次更新列表先过一轮检测，不合格直接阻断发布。README 也把 CI/CD 自动化检测列为适用场景之一。

场景二：换播放器前先过滤。桌面播放器导入新源之前，先用 Web 界面跑一轮检测，导入过滤后的列表。开播成功率比直接扔一份原始 M3U 进去高得多。

场景三：配合 EPG 整理频道名。4.7.0 起有独立的 EPG 管理和频道分组映射，导入的杂牌列表经过规范化后，tvg-name 和分组都能对上，播放器里不再是一堆乱码名。

坑的部分列成表更清楚：

现象	原因	规避办法
拉取 GitHub 公共源被限流	匿名 API 配额只有 60 次/小时	系统配置里填入 github_token，配额提到 5000 次/小时，保存时会自动验证有效性
状态显示在线、实际播不了	源返回 200 但没有有效流	对该任务开启 FFmpeg 强制检测
大列表检测变慢、本机带宽被占满	并发数偏高	从低并发开始逐步加，以自己的带宽上限为准