疯狂URL 5 5.x
URL 太多、不断新增，应该选哪条
先按模式只看媒体，清空旧结果后重新播放，优先检查最初出现的媒体入口。
进入一个直播间，列表却冒出几十条甚至几百条 URL，而且还在增加——这很常见，不代表打开了很多个视频。除了页面请求，播放器还会不断请求视频分片、更新播放列表。
先不用追着最新一条看。只看媒体，清空旧结果后重新播放，优先检查本次播放最初出现的几条媒体地址，通常更容易找到入口。下面的观察方法适用于网页、手机 App 和模拟器，但不同捕获方式的筛选入口不同。
1. 按捕获方式，只看媒体
已经开启疯狂URL自动下载时，先关闭 自动下载，避免观察和重播时继续投递；猎流中已经开始的任务不会因此停止。
| 当前使用的方式 | 在哪里筛选 |
|---|---|
| 浏览器抓源 | 在浏览器页的抓源结果上方点击 视频。这里不使用“捕获”页的高级过滤规则 |
| 代理模式、网卡模式 | 在“捕获”页打开 过滤器，选择 常用示例 → 仅媒体，确认过滤器为 已启用；初次使用建议选 仅隐藏 |
代理或网卡模式下，高级过滤未启用，或者规则放得很宽，网页、图片、接口等请求就容易混在一起。选择“仅媒体”预设后会自动启用规则，仍要确认开关状态，不能只配置规则却没有启用。这里不需要切到 高级 编辑方式手写表达式，具体见过滤器。
筛完突然什么都没有时，先恢复 全部、清空搜索关键词；代理和网卡模式再暂时关闭过滤器并重新播放，确认是否误筛。视频 和 仅媒体 都只是在缩小范围，不会自动分辨正片、广告或完整视频。
2. 换一个直播间或视频，先清掉旧结果
旧直播间的地址和新直播间混在一起，会更难判断哪个才是目标。每次换内容，尽量从一份干净的列表开始。
清空前先保存需要的记录
清空会删除当前列表中的记录，包括被筛选隐藏的内容。需要留存时先导出；“导出可见数据”只保存当前可见项，想保留全部应先放宽筛选。之前已经被“源头丢弃”的请求无法补回。具体操作见捕获列表与详情。
- 浏览器抓源：默认开启 自动清空（切换页面时）。确认该项没有被关闭；若网页只在当前页面内切换直播间、没有触发自动清空，就手动清空抓源列表，再刷新或重新进入目标内容。清空按钮不是关闭浏览器按钮。
- 代理／网卡模式：“捕获”列表不会随着 App 切换直播间自动清空，需要手动点 清空列表。
顺序是：保存需要的旧记录 → 清空 → 确认正在捕获 → 重新进入直播间或播放视频。已经播放了一段时间才清空，又没有重新加载内容，可能只剩后续分片，看不到最初的入口。
3. 先看本次播放最初出现的几条
列表继续增长时，回看这次进入直播间或开始播放时的记录，不必逐条追看后面新增的 URL。按实际出现顺序判断，调整过排序时不要把屏幕上的第一行当成最早请求。
| 一起出现的内容 | 优先检查 |
|---|---|
M3U8 和很多 TS、M4S、part…mp4 | 最初的几条 M3U8；分片先放一边 |
| MPD 和大量 M4S | MPD 描述文件 |
| FLV 或 RTMP 地址 | 结合来源和播放时刻，验证是否为目标直播 |
| 只有 MP4 等文件 | 先确认它是完整文件、分片还是单独音视频轨道，不能只看后缀 |
浏览器列表刷得太快时，可以暂时点 暂停捕获 后查看已有结果。暂停期间的新请求不会记录，切换内容或清晰度前记得恢复，再重新播放。代理模式下不要为了让列表停下来直接停止代理，否则可能影响目标应用联网。
“先看最初几条”是寻找候选的办法，不是第一条一定正确。片头广告可能更早出现；切换清晰度后需要看那次操作新增的请求。选中候选后，先用 使用播放器打开 核对画面和声音；再按需要验证下载结果。
4. 只看媒体后，为什么还在不断增加
HLS、DASH 会把内容拆成小段交给播放器。直播持续产生新分片，播放列表也要更新；点播播放过程中同样会陆续加载分片。这些都是媒体请求，所以“视频”筛选或“仅媒体”规则仍会显示它们。
下面用虚构地址示意同一次低延迟 HLS 播放的请求顺序。域名、房间号和签名均已替换，不能用于实际播放。
https://media.example.com/live/room123/master.m3u8?mode=lowLatency
https://media.example.com/live/room123/index.m3u8?token=DEMO
https://media.example.com/live/room123/segment100_part0.mp4
https://media.example.com/live/room123/segment100_part1.mp4
https://media.example.com/live/room123/init.mp4
https://media.example.com/live/room123/index.m3u8?token=DEMO&_HLS_msn=101&_HLS_part=0
https://media.example.com/live/room123/segment101_part0.mp4
https://media.example.com/live/room123/index.m3u8?token=DEMO&_HLS_msn=101&_HLS_part=1可以这样看：
- 最初出现的几条 M3U8：结合名称和路径挑候选，不是固定选前两条。示意中的
master.m3u8和room123/index.m3u8值得先检查；实际列表也可能混有探测请求。对比后续列表和分片，看是否有相同的房间标识、路径或清晰度名称，再结合响应内容和使用结果确认，见HLS 主列表和子列表。 part0.mp4、part1.mp4、init.mp4：在这组请求里，它们分别是媒体小段或初始化文件。即使类型显示video/mp4，也不能当成完整视频逐条下载。- 同一路径、不断变化的
_HLS_msn和_HLS_part：这是低延迟 HLS 请求更新播放列表时使用的序号，分别指向媒体段和其中的小段，不代表又出现了一个新视频。相关机制见 Apple 的低延迟 HLS 说明。
名称像 check.m3u8、路径很短的地址，可以先多检查一下，但名称和路径层级都不能判定它是不是媒体：有效播放列表也可能直接放在域名下一层。若抓到了响应正文，正常 HLS 列表应以 #EXTM3U 开头；响应只有一小段 JSON 状态信息或错误文字时，这次返回的就不是可用播放列表。即使状态是 200/OK、类型标成 M3U8，也不能据此确认可播放。没有响应正文时，也不能当作无效，仍需验证。
这一类列表中，优先验证实际捕获到的、最初那几条不带这些更新序号的 M3U8，不用把后面每一次更新都发送给下载器。如果最初的记录没抓到，清空后重新进入一次直播间，往往比逐条猜测更直接。
优先选原始记录，不要手动删参数。 签名、令牌、有效期等参数可能决定地址能否访问。不要把问号后面的内容一起删掉，也不要把所有参数不同的 M3U8 当成同一个地址。优先使用完整的已捕获记录；旧地址失效时重新抓取，最初出现的地址也不保证永久可用。
后续变化也可能来自切换清晰度、换线路或更新访问凭据。已经验证出可用入口时，可以暂时忽略重复更新和分片；目标内容变化或地址失效时，再看对应的新请求。
如果已经知道该看哪些记录，只是不清楚某种地址是什么，继续看识别媒体源。