IPTV 直播源怎么找？m3u/txt 五种来源渠道与检测验证方法

IPTV 直播源全解 · 第 2 篇 / 共 8 篇

直播源就是一行地址，但这一行地址背后的门道不少。这一篇讲清它的几种形态（m3u、txt、IPv4 与 IPv6）、五条获取路径、公开渠道地图，以及拿到源之后怎么验证它到底能不能用、值不值得留。

约 1.7 万字 阅读时间 38 分钟 含 13 张图解（9 张真机截图） 含 7 张速查表

CHAPTER 2直播源

2.1直播源就是一行地址，但这一行地址有讲究

抛开所有包装，一个直播源最小形态就是一行文本：

# 频道名,播放地址
CCTV-1 综合,http://some-server.com/live/cctv1.m3u8

逗号左边是给人看的名字，右边是给播放器用的地址。就这样，没别的了。所谓「一份直播源」，就是这样的行堆了几百上千条。

但它跟你在浏览器里点开的普通网址有三个关键区别。

• 它是流，不是文件。普通网址下载完就结束了，直播源是源源不断往你这边推数据的，播放器不会「下完」，只会「一直在收」。
• 它是一条要一直挂着的连接。你打开一个直播源，服务器可能只分配给你这一路，你切台它就断了。所以同一个源，你一个人看没问题，分享给一万人看就崩。
• 它经常带有时效性和来源校验。很多源地址后面挂着一串 token，或者要求请求头里带特定的 Referer / User-Agent，缺了就拒绝。这就是为什么你从浏览器复制出来的地址，粘到播放器里却播不了。

所以「找源」这件事，本质上找的不是一个网址，而是一个可以稳定访问的地址，加上一组正确的访问姿势。后者经常是隐形的，也是新手最卡的地方。

2.2看后缀就能猜到七八分

直播源的地址后缀，直接暴露了它用的是什么协议。熟悉这几个，你会省很多事。

延迟那一栏别太当真，它取决于源本身的架构，不完全是协议的锅。但有一点基本成立：同一个台，如果能选，优先选 FLV 或 TS，其次才是 HLS。HLS 的延迟是切片机制决定的，改不了。

2.3IPv4 源和 IPv6 源：同一个台，两条路

前面两节讲的都是「地址长什么样」「用什么协议传」。还剩一个维度没碰：地址本身属于哪一代 IP。这件事听着像网络课的内容，但实际用起来，它经常直接决定你是流畅看 4K，还是一直在那转圈。

先把结论放这儿：同一个频道，你手里往往同时有 IPv4 和 IPv6 两条源。它们通向同一个台，但走的是两条完全不同的路。

2.3.1区别的根子：要不要经过 NAT

IPv4 的地址在 2011 年前后全球就分完了。分完的直接后果是，你家上网用的那个「公网地址」并不是你家独占的，而是跟同一个片区里的很多户共享。中间必须架一层 NAT，把一堆设备翻译成少量公网地址转发出去。这一层就是拥堵最容易发生的地方——晚高峰整片区域的人一起看直播，全堵在同一个出口上排队。

IPv6 的地址数量是 2 的 128 次方，多到给地球上每一粒沙子都分一个还有富余。所以它不需要 NAT，你家设备可以拿自己的地址，直接跟服务器对话。

拿电话打个比方。IPv4 像是老式写字楼的总机——整栋楼对外只有一个号码，外面打进来还得总机转一道。IPv6 像是每个人都配了直拨分机——不用转，直接通。对直播这种「一路数据要持续不断送过来」的场景，少一层转发就是少一个可能出事的地方。

2.3.2地址写起来不一样，有个细节必须注意

两类源摆在一起是这样：

# IPv4 源
CCTV-1 综合,http://218.63.12.34:8080/live/cctv1.m3u8

# IPv6 源
CCTV-1 综合,http://[240e:3a1c:8f00::1]:8080/live/cctv1.m3u8

注意 IPv6 那对方括号。它不是排版装饰，是必需的。原因很直接：IPv6 地址本身就用冒号分八段，而冒号在网址里又是「端口从这里开始」的标志。不打方括号，播放器根本分不清哪个冒号属于地址、哪个冒号是端口。少这一对括号，这条源就是废的——这是复制 IPv6 源时最容易踩的坑。

反过来，识别也很简单：地址里出现方括号包着一长串带冒号的东西，那就是 IPv6。纯 IPv4 就是四组点分数字。有些源写的是域名，那就要看域名解析出来什么——同时有 IPv4 和 IPv6 记录的域名，走哪条取决于你的设备和网络当时的判断。

2.3.3为什么这几年 IPv6 源被单独拎出来说

三个原因，按实际重要性排：

1. 画质。这条最实在。三大运营商的 IPTV 平台里，超高清（4K、部分 8K）频道大量只挂在 IPv6 侧。IPv4 侧要么根本没有，要么严格鉴权和限速。所以你去看那些标着「4K 直播源」的清单，会发现清一色是方括号开头的。想要高码率的国内频道，IPv6 常常是唯一入口。
2. 通畅。IPv6 的实际用户量还在爬坡，同一批 CDN 节点上，走 IPv6 的人比走 IPv4 的少一大截。同一个台，IPv4 侧晚上八点卡成一格一格，IPv6 侧可能还很轻松。这不是 IPv6 协议本身「更快」，说白了就是那条路上人少。
3. 省事。运营商 CDN 的 IPv6 节点，相当一部分对访问姿势没那么多讲究——不加 Referer、不带特定 UA 也能拉。前面反复说的「浏览器能放、播放器放不了」，在 IPv6 源上遇到的概率低很多。

这三点连起来看，还能解释一个现象：运营商供着的那批免费源里，IPv6 那一支活得明显更久。用户少、负载低、运营商没动力去管，它就这么一直开着。（这个逻辑在第 12 章讲「谁在供养免费源」时还会用到。）

2.3.4但门槛经常在你自己这边

IPv6 源的第一个坑从来不在源，在你家网络。它要求整条链路都支持才行：

四层里任何一层掉链子，结果都一样：所有 IPv6 源一条都放不出来。而这时候你几乎一定会误判成「这批源全挂了」——这是最冤的一种情况。

2.3.5先弄清自己有没有 IPv6，再谈源

这一步最容易被跳过，但它是全部前提。Windows 下开命令行敲：

ipconfig

看有没有以 240e、2408、2409 开头的地址——这三段分别是电信、联通、移动的 IPv6 地址段。注意要的是全局地址，不是 fe80 开头的本地链路地址（那个每台设备都有，说明不了任何事）。

或者更干脆，直接试出口：

ping -6 www.qq.com

能通，说明你家有 IPv6；不通，后面所有 IPv6 源都不用试了。

这里有个细节值得单独提一句：ping 默认走 IPv4，测 IPv6 必须加 -6。不少人在这儿测了个寂寞，看到 ping 通就以为 IPv6 正常，其实那条命令压根没碰过 IPv6。

确认没开的话，两条路能走通：一是打运营商客服电话，说要「开通宽带的 IPv6 权限」，这是免费的，后台点一下，通常十分钟内生效；二是自己进路由器把 IPv6 打开，位置一般在「IPv6 设置」或「网络设置 → IPv6」，模式选自动（SLAAC）或 DHCPv6。

2.3.6IPv6 源怎么测

测法和 IPv4 源只差一个参数，但就是这一个参数决定结果准不准：

curl -6 -I "http://[240e:3a1c:8f00::1]:8080/live/cctv1.m3u8"

-6 是强制走 IPv6。不加它，如果那个地址是域名、且域名同时有 IPv4 记录，curl 可能就走了 IPv4，那你测出来的结果跟 IPv6 通不通毫无关系。用 ffprobe 探流同理，该强制就强制。

然后是那条一定要记住的判据：如果你机器本身就没有 IPv6（上一步 ping -6 不通），那你测任何 IPv6 源都会失败。这时候失败的不是你手上的源，是你的网络。先把自己的网络搞通，再去怀疑源——顺序反了，只会白折腾一晚上。

2.3.7两类源摆在一起比

2.3.8务实的用法

别把这件事理解成「IPv6 源更高级，我要全换过去」。它只是另一条路，各有各的用处。

• 你家有 IPv6，那就两条路都用。同一个频道把 IPv4 和 IPv6 的源都留一份，播放器播不了这条会自动往下找下一条。这是最省心的配置。
• 你家没有 IPv6，也不必急。先用 IPv4 那套跑着，等哪天觉得画质或稳定性不够了，再回头把 IPv6 打开。开通是免费的，但调路由器要花点时间，不急就不用现在做。
• 唯一的例外：你就是想要那几个 4K 超高清频道。那几个台经常只在 IPv6 侧有，这种情况下 IPv6 就从「备选」变成了「必须」，不开就没得看。

最后回答一个常被问到的：IPv4 源和 IPv6 源能混在同一个 m3u 里吗？能，完全没问题。播放器是一个一个去试的，它不关心你给的是哪一代地址，能出画面就行。所以最稳的做法，就是把手上所有的源不分代际混成一队，让播放器自己往下挑。

2.4直播源到底从哪来：五条路

这个问题被问得最多，但答案往往被含糊过去。实际就五条路，每条路的门槛、成本、产出质量都不一样。我按「普通人能走多远」的顺序排。

2.4.1路径一：公开开源项目（最干净，但内容偏境外）

互联网上有一个知名度极高的开源项目 iptv-org/iptv。它做的事就是把散落在各处的公开直播地址自动抓取、清洗、去重、分类，整理成一份每天更新的播放列表。这个项目在 GitHub 上有十万量级的收藏，几百位贡献者持续在提交新频道、修失效链接。

它给出的播放列表地址是：

# 全量主列表（所有国家和地区的频道）
https://iptv-org.github.io/iptv/index.m3u

# 按国家拆分的子列表，例如只看中国大陆的
https://iptv-org.github.io/iptv/countries/cn.m3u

# 按分类拆分的子列表，例如只看新闻类
https://iptv-org.github.io/iptv/categories/news.m3u

这份列表的特点是：地址全部来自公开渠道，性质最干净（项目用的许可近乎公共领域），每天自动更新，覆盖两百多个国家和地区。

但你用之前得知道它的短板：它以境外频道为主，国内的央视频道和省级卫视收录得很少，而且里面大量地址在国内网络环境下需要代理才能看。所以它的正确用法不是「拿它当主力」，而是「想看某个国家的新闻台时，进去按国家筛一份出来」。想靠它替代国内的常用频道列表，会失望。

2.4.2路径二：社区整理者的订阅链接（国内台最全）

这才是绝大多数人实际在用的东西。一些长期做这件事的个人或小团队，会把自己整理维护好的列表挂在自己的服务器或代码托管平台上，形成一条可以长期订阅的链接。

它的形态通常是这几种：

• 一条 .txt 或 .m3u 直链，软件里填进去就能用。
• 一个配置接口的 JSON，里面的 lives 字段指向直播列表——这是 TVBox 用户最常见的形态。
• 嵌在一个多仓地址里，你选了某个仓之后自动带出来。

这类源的质量差距极大，而且差别不在技术，在人。同样一份 500 台的列表，有人整理的版本台名规范、分组清楚、死链清得干净；有人整理的就是随手复制粘贴，一半打不开，台名还重复三遍。所以圈子里那句「认人比认地址重要」是真的。

2.4.3路径三：自己抓包扒源（可控，但要花时间）

如果某个台你在别处就是找不到，自己动手是唯一办法。原理简单：任何在你设备上播放的视频，地址一定经过了网络收发，把请求记录下来，从里面找出真正拉流的那一条。

具体到常见场景，做法不太一样。手机 APP 里的直播，一般是在手机上装抓包工具、配好证书和代理，然后在 APP 里播放，去记录里找形如 xxx.m3u8、xxx.flv 的请求。网页端最省事，浏览器按 F12，切到「网络」面板，播放的时候看请求列表，按类型筛一下基本就出来了。电视盒子麻烦一些，需要把盒子的网关指到电脑上的抓包代理去。

抓出来之后还有一步不能省：把地址变成「能重复使用」的形态。直接从请求里复制的地址往往带着一次性的 token、绑着设备标识，或者依赖某个请求头。所以你还得把 token 去掉试试、把依赖的 Referer 和 UA 记下来，补进 m3u 的 #EXTVLCOPT 里。「扒源」的完整工作量，一半在抓，一半在还原访问条件。

2.4.4路径四：从运营商 IPTV 专网转换（前提是你本来就有业务）

如果你家里正常办了运营商的 IPTV 业务，那专网里那几百个频道其实是可以变成自己能用的单播地址的。做法是在局域网里跑一个转换工具（路由器插件里就有成熟实现），让它以组播成员的身份去「加组」，收到数据后再以 HTTP 的形式分发给任何来访者。转出来的地址形如：

http://192.168.1.1:4022/udp/239.45.1.1:1234

这条路径的产出质量其实是最高的——毕竟直接来自运营商，清晰度和稳定性都不是网上那些二道源能比的。但它有三条明确的边界：只在你自己的局域网内有效；想在外网看就得开端口映射并绑动态域名，带宽和安全性都要自己扛；而且这一切的前提是你本来就有这个业务的权限，把它公开出去给别人用就是盗播了。

2.4.5路径五：完全自建

手上有信号源（比如采集卡接卫星接收机）又有服务器的人，可以直接自己推流、自己分发。技术上完全可行，成本主要是上行带宽——一路 1080P 的流跑满一个月，就是几百 GB 的流量。这条路属于「有资源的人才玩得起」，对绝大多数人没意义。

2.5公开的源到底去哪找：一份渠道地图

上一节讲的是「源从哪来」，那是原理层面的分类。但实际被问得最多的，是更具体的一句：我今天想给电视补上几个台，第一步该打开哪个网站？

这一节就把这件事做实。我按门槛从低到高，把实际在用的几个渠道过一遍，每个都讲清三件事：里面有什么、进去要付什么代价、拿到的东西大概能活多久。

先说一个贯穿全部的结论：门槛越低的地方，拿到的源越脏、越短命。这不是道德判断，是结构决定的——一个不需要注册、不需要验证、不需要对任何人负责的地方，也就没有谁在为质量兜底。

2.5.1一、技术论坛：恩山是绕不过去的一站

国内做这件事最集中的地方，是恩山无线论坛里的一个板块，全名「国内 IPTV 直播源、播放软件与网络视听代码」。名字看着挺正式，实质是个大型分享区。

那这将近两万四千个帖子里到底在发什么？翻几页就有感觉了。板块的「推荐主题」栏最直观——标题几乎全是「某省某运营商」开头。

这就是国内直播源最重要的一条常识，论坛管理员自己在置顶帖里也写了：这类源天生带地域性。同一个台，联通、电信、移动三家的地址完全不同；同一个运营商，隔一个省又是另一套。所以你在论坛看到一条「完美可用」的源，第一件事是看发帖人的运营商和省份——跟你不一致，就先别激动。

把列表往下拉，帖子大致能归成四类。一类是运营商专网源的整理，标题像「上海电信IPTV组播源」，这类质量最高，但基本只对同网同省的人有用。一类是抓包记录，像「大连云抓包大连台，大连仅剩3个台」，属于单点突破，别人的环境复制不了。第三类是软件发布与魔改，前面几章讲的酷9、影视仓、蜂蜜版，最早的发布和持续更新大多就在这个板块里。最后一类是从酒店、公共场所扒出来的源，碰运气性质。

看帖本身没有门槛，我实测不登录就能打开列表页、看到全部标题和正文。但要真把东西拿到手，有两道关。第一道是手机号验证：论坛公告要求所有账号绑定国内手机号，没绑的账号不能发帖、不能跟帖、不能发站内信。公告里还写了发送频率上限——每分钟 1 条、每小时 2 条、每天 4 条，所以收不到验证码时别狂点重发。第二道是积分：不少帖子把附件设成「售价 1 恩山币」，你得先回帖攒分才下得了。

但真正值得你记住的，是这个板块置顶说明里管理员自己写的话。我原样引几句，因为他说得比我清楚：

翻成大白话就是：论坛不是仓库，是集市。管理员明确说了自己不验货，出了问题自己找卖家。你在这儿拿到的东西，有效期可能只有几天，判断权完全在你手上——回帖里有没有人喊「打不开」、发帖时间是不是三个月前，这两样比标题里写的「稳定可用」有用得多。

还有一条边界要讲清楚。这个板块有一条明确的置顶规定：不得发布涉及中国台湾地区以及境外的频道源和程序，违反的会被封号处理。一个正规的国内技术社区，内容是有明确边界和合规要求的。这件事对你判断「渠道靠不靠谱」其实是个正面信号：愿意挂这种公告、并且真的执行的社区，说明它自己在承担合规责任；反过来，什么都敢发、什么源都往里塞的地方，你就要多想一层了。

2.5.2二、开源项目：唯一能查到「这东西是谁在维护」

第二类放在代码托管平台上的公开项目。最有代表性的还是前面提过的 iptv-org/iptv。我在写这一节时查了它的实时数据：14 万 star、8100 多个 fork，最后一次代码提交就在当天，许可证是 Unlicense——相当于放弃版权、完全交给公共领域。

这类项目好在哪？好在一切都可查。谁提交的、什么时候提交的、删了什么加了什么，全在提交记录里；链接有效性由自动化任务每天跑一遍；许可证写清楚了你能怎么用、能用到哪一步。这是所有渠道里唯一能做到「我大概知道这些东西是谁在维护、上次动是什么时候」的一类。

短板也一直在：以境外台为主，国内央卫视收录得少。所以它的正确用法是「想看某个特定频道时进去筛一份出来」，不是拿来当主力。

还有一类更小众的：按省拆分的项目。比如有人专门维护某一个省的公开 IPTV 频道，仓库里就一份列表文件加一份说明。这类项目的价值在于够专，只在做一件事，往往比大项目做得细。但也正因为小，作者停更就是真停更，更新节奏全看个人心情。

第三类思路完全不同：不给你源，给你一个能生成源的程序。你自己跑一遍，它去各个公开来源抓取、去重、验活，最后吐出一份属于你自己的列表。这类工具的价值在于——生成出来的东西在你自己的服务器上，不依赖任何人替你续命。第 11 章讲自建的时候会展开。

2.5.3三、导航站：不生产源，只做索引

第三类介于两者之间，是各种「IPTV 导航站」。它们自己不做源，做的事是把上游渠道列出来、分好类、摆整齐。

这类站点的价值很实在：它能让你一次看清上游都有谁。省得你一个个去搜。刚入门的时候拿它当地图看一遍，对这个圈子的结构就有概念了。

但你要知道风险在哪。它不产生内容，只做转述，所以它列的地址可能是从别处抄来的、可能早就过期、也可能掺了自己的推广。中间商这一层，天然比源头多一份不确定性。

我的建议是把它当索引，不当来源。看到感兴趣的名字，去它自己的原始出处——GitHub 仓库、论坛原帖——确认一遍再动手。

2.5.4四、私域：公众号、群、短视频评论区

最后一类最常见，也最需要留个心眼：各种「公众号回复关键词领源」「加群获取」「评论区置顶」。

先把话说公道：这里面确实有认真的作者，在公众号里写教程、长期维护源，做得比很多公开渠道都细致。问题不在人，在形态。

私域渠道的共同特征是：没有公开记录，没有版本，没有历史。一篇文章今天发了、明天删了，你手里的地址就成了孤儿；这份源是哪天抓的、能用到什么时候、作者还更不更新，全都查不到痕迹。更麻烦的是，这类渠道的目的往往不只是「给你源」——「加群」「回复关键词」「关注后获取」这些动作本身，才是它的用途。

2.5.5五、你自己的运营商

这条前面讲过，这里只补一句它为什么必须在这张地图上占一个位置：它是唯一一条链条上没有任何陌生人的路。源来自你花钱买的业务，中间不经过任何第三方，寿命跟你的宽带套餐一样长，画质还是原始信号。

代价是它有前提：你得本来就有这个业务，而且转出来的东西只在你自己的局域网里有效。想把这条利用起来，看第 11 章。

2.5.6把五个渠道摆在一起

如果只让我说一条规律：获取门槛和内容可靠度基本是正相关的。左下角那些「打开就能拿」的地方，你省下的每一步，最后都会以「这条源什么时候挂、我该找谁」的形式还回来。

最后给三条能直接用上的规矩。

一、别在同一个渠道上吊死。手上同时养两三个不同来源的列表，某一条挂了立刻切。这比去找「一条永久的源」现实得多——那种东西不存在。

二、看帖先看两样：发帖时间和回帖。发帖时间决定它大概还有没有效，回帖里有没有人喊「打不开」决定它现在是不是已经废了。标题里那句「稳定可用」，是最不值得信的。

三、认人比认地址重要。这是圈子里的老话。同一个板块里，有人整理的东西能连着用很久，有人发一次就没了影。跟着长期更新的人走，比收集一堆地址有用得多。

2.6拿到源之后：怎么验证它到底能不能用

这件事比找源更重要。你拿到的可能是 500 条、3000 条的一份列表，而实际能用的往往只有一两成。如果一条一条拖进播放器里试，一下午就没了，而且试到第 50 条你就不想试了，最后留下一堆根本播不了的死链。

所以验证必须分层做，而且要自动化。核心思路是「先用最低成本砍掉绝大部分，再对少数幸存者做精细检查」。

2.6.1最简单的办法：用播放器手工试一条

手上只有几条源的时候，不用上工具。把地址粘进 VLC 或 PotPlayer 的「打开网络串流」，然后看这几件事：

• 多久出画面。3 秒内出画面算健康；超过 10 秒还在转圈，可以直接判死，不用再等。
• 画面有没有花屏、马赛克、大面积色块。有的话是流本身有问题或者带宽不够，这种源属于「能播但没法看」。
• 声音和画面同不同步。不同步的源，看新闻还行，看比赛会疯。
• 让它自己挂着跑五分钟。很多源就是三分钟一断，前两分钟看不出问题。

然后是判定。下面这张表基本覆盖了所有你会遇到的情况。

2.6.2进阶一点：用 ffprobe 探一次

如果你装了 FFmpeg（它自带 ffprobe 这个探测工具），就能在不解码播放的情况下，直接问服务器「你这条流里有什么」。这条命令最实用：

ffprobe -v error -rw_timeout 8000000 -select_streams v:0 ^
  -show_entries stream=codec_name,width,height,avg_frame_rate ^
  -of default=noprint_wrappers=1 "http://xxx/live.m3u8"

（Windows 命令提示符里换行用 ^，PowerShell 里用反引号，或者干脆写成一行。）

它会回给你类似这样的东西：

codec_name=h264
width=1920
height=1080
avg_frame_rate=25/1

于是你就知道了三件事：能连上、有视频轨、是 1080P25。反过来，如果它只回一个错误，那这条源就不用再试了。这个判断比拖进播放器快得多，因为播放器还要等缓冲和渲染。

还有一个更短的「活着吗」命令，只判断能不能取到流，不关心内容：

ffprobe -v error -i "http://xxx/live.m3u8" -t 2 -f null -

能跑完不出错就是活的，报错就是死的。批量跑的时候用这个。

2.6.3真正省事的办法：用现成的批量工具

手工验证只适合收尾，批量必须靠工具。目前成熟的路子有两条。

一条是图形界面的桌面工具。社区里有一个叫 IPTV Checker 的开源桌面应用，Windows 上可以直接用包管理器装：

winget install --id=kristofferR.IPTVChecker -e

它能把整个 m3u 文件或一条订阅链接全部跑一遍，自动标出每条频道是「活着 / 死了 / 被地域限制 / 加密的 / 只有声音」，还会用 ffmpeg 抓一张画面的缩略图让你肉眼确认，顺便报出编码、分辨率、帧率、码率。跑完能导出成 CSV，或者直接导出「只剩活着的那些」的干净 m3u。这个「导出干净 m3u」的功能，是整个流程里最省时间的一步。

另一条是命令行的检测器。有一个基于 ffprobe 的命令行工具，用起来是这样的：

# 直接清洗整个播放列表，只保留能用的（会覆写原文件，先备份）
iptv-checker --file playlist.m3u --workers 10

# 深度模式：真的抓一帧画面，看是不是「频道已下线」这类提示图
iptv-checker --file playlist.m3u --thorough --workers 10

那个 --thorough 参数解决的是一个很隐蔽的问题：有些源其实已经停了，但服务器还在，返回的是一张写着「频道已下线」或者「Error」的图片。普通检测只会告诉你「这条能连上」，深度检测会抓帧看图，把这种伪装成活的源挑出来。用过一次你就知道值。

2.6.4另一条路：中文圈里的「工具箱」

上面那个 IPTV Checker 是英文软件，功能也单一——只干检测这一件事。而在中文圈子里，更主流的一类工具被统称为「工具箱」：它们不只做检测，还把搜源、去重、分组、试播、导出全揉进同一个界面。你提到的橙子工具箱和 WT 工具箱都属于这一类，而且它俩还有点渊源，得先说清楚——WT 工具箱是「前身」，橙子工具箱是「现在」，同一个作者的东西。这个脉络不说清，你在网上搜的时候会同时撞见这两个名字，很容易以为是两款互不相干的软件。

工具箱这类工具真正解决的，是前面反复强调的那个矛盾：源的平均寿命只有一个月左右，所以「搜到新源 → 立刻测一遍 → 只留活的 → 导出替换」必须是一个连贯动作。如果拆成三个软件分步做，你坚持不了几轮就会放弃。工具箱的价值不在于它比 IPTV Checker 测得准，而在于它把这条流水线压进了一个窗口。

2.6.5WT 工具箱：这一类工具的起点

WT 工具箱是一个开源的小工具，作者网名「一个橙子」（早期叫「变饼档」）。它其实只做一件事：把一份列表里的每一条地址都请求一遍，告诉你哪些还活着。界面朴素到有点简陋，但功能完全对口。

它有四个设计细节，用起来才知道好：

• 并发可调。检测是同时跑多条，设置里可以调「极速模式并发数量」。作者的建议是别超过 12 条——调太高，服务器被并发压住，本来能播的源反而会被误判成死的。
• 两种检测引擎。HTTP 模式只发一个请求看状态码，快，但测不出分辨率；FFMPEG 模式会真的解码一小段，慢一些，但能测出分辨率、编码，以及揪出「连得上却播不了」的假活源。
• 自动清除无效源 + 检测列表持久化。一个是边测边扔，一个是关了软件下次打开列表还在。这两个开关都建议打开。
• 右键菜单。列表里点右键，能做去重、清除无效源、清除列表。同一地址在列表里出现三次是常态，光去重就能砍掉一大半体积。

另外提醒一个实操上的坑：导出按钮只会导出「已检测且有效」的源。如果你还没测完就点导出，会得到一个空白文件或者半成品。很多人第一次用会以为软件坏了，其实只是导出逻辑如此——它默认你已经先测完了。还有，「健康模式」这个选项是拿来过滤某些不良源地址的，作者的原话是「还请自觉打开」。

2.6.6一个橙子工具箱 / 迷途工具箱

WT 工具箱后来停更了。作者没有继续单独维护，而是把它拆成了一个插件，装进自己做的另一个平台里——这就是「一个橙子工具箱」，现在叫迷途工具箱（metools）。所以你在网上会遇到三种叫法：橙子工具箱、迷途工具箱、metools，指的都是同一个东西。

它和 WT 工具箱最大的区别是架构变了：橙子工具箱本身是个「空平台」，具体功能靠插件往里装，WT 检测只是其中一个插件（项目名叫 metools-app-wtv）。这个设计的好处是作者能持续往里加新工具、老插件照样能用；代价是你得先装平台、再装插件，比当年一个 exe 双击打开要麻烦一点。

插件版的检测流程和 WT 一模一样：导入 m3u/txt、逐条检测，结果显示速度（毫秒）、分辨率、帧率，支持去重、按速度排序、右键重命名/复制/清除无效，另外多了个「扫源助手」负责从别处把源导进来，以及一个能按范围导出的对话框。换句话说，换了个壳，里面还是那个测源器。

2.6.7这两款工具最特殊的地方：「搜源」

WT 工具箱的「搜一搜」是它和所有同类工具拉开差距的功能，也最容易被误解，所以值得单独讲。

理解它的关键在一句话：软件自己不提供任何直播源。你在搜索框里敲「湖南」，它不会凭空变出湖南卫视。它实际干的事是——把你输入的关键词，发给一个你自己配置好的搜索接口，那个接口返回一批候选地址，工具把结果填进列表、顺手测一遍。所以搜索能不能用，取决于两个前提：你有没有配搜索地址（或者激活码），以及那个地址背后的服务还在不在。

作者为此做了一个「内置源」模式：在设置里填一个激活码，就不用自己找搜索接口了。码是限量的、会过期，需要去他的公众号取。想彻底自己掌握，也可以自己搭一个搜索接口——格式是固定的，就是一个普通的 GET 请求：

GET http://你的域名/api/tv?tvName=关键词&ipv6=1

返回：
{
  "code": 0,
  "msg": null,
  "data": [
    { "name": "cctv-1", "url": "http://xxx.m3u8" }
  ]
}

搜索框还支持「联合搜索」，用竖线把多个关键词隔开，一次搜一批：

湖南|湖北|陕西|南京

但这里有个容易踩的坑。单个搜索也好、联合搜索也好，都只是一种「约定」——某几个关键词怎么解析、竖线代表什么，是接口那一端的代码在定义，不是软件在定义。换个接口，同一套语法可能就完全不认了。所以看到别人分享的搜索语法，先确认它配套的是哪个接口。

2.6.8这些工具横向比一比

到这里，测源这条路你已经见过好几种走法了。放在一张表里对比一下，按你的场景挑就行。

如果要我给一个干脆的建议：主力用工具箱类工具跑「搜—测—导」这条流水线，最后一步拿 IPTV Checker 再洗一遍导出成干净的 m3u。前者解决效率，后者解决输出质量。两件事各用各的强项，比指望某一个软件全能要靠谱。

2.6.9不想装工具：自己写个循环

如果你只是偶尔清一次列表，用 Windows 自带的 curl.exe 写个几十行的 PowerShell 就够了。思路是：把地址从列表里抠出来，逐个请求，把返回 200 的挑出来。

# 1. 从 txt 列表里抠出所有地址
$urls = Get-Content .\live.txt |
  Where-Object { $_ -notmatch '^#' } |
  ForEach-Object { ($_ -split ',')[-1].Trim() } |
  Where-Object { $_ -match '^https?://' } |
  Select-Object -Unique

# 2. 逐个探测，记录状态码和耗时
$result = foreach ($u in $urls) {
  $t0 = Get-Date
  $code = & curl.exe -s -o NUL -m 8 -w "%{http_code}" `
            -A "VLC/3.0.20 LibVLC/3.0.20" "$u"
  [pscustomobject]@{
    Url  = $u
    Code = $code
    Ms   = [int]((Get-Date) - $t0).TotalMilliseconds
  }
}

# 3. 存活的导出来
$result | Where-Object Code -eq '200' |
  Select-Object -ExpandProperty Url |
  Set-Content .\alive.txt -Encoding UTF8

几个细节别踩坑：那个 -A 参数是在伪装成 VLC 的 User-Agent，必须加，否则很多源会直接把你挡掉，你会误判成死链。另外 -m 8 是超时 8 秒，太短会误杀慢源，太长会拖慢整批。Select-Object -Unique 是在去重——列表里同一条地址出现三次是常态。

2.7怎么判断一个源好不好：五个维度

新手挑源只看「能不能播」，这不够。真正决定体验的是这五项。