卡顿往往是一组链路没对齐，而不是「换一个节点」能根治
TikTok 的网页端与 App 一样，会在短时间内拉起大量并发请求：应用壳、推荐接口、缩略图与短片段、埋点与实验配置，有时还有跨域的静态资源。进入 LIVE 后，除了常规 HTTPS，还常见实时信令走 WSS（WebSocket Secure），以及媒体面在部分网络路径上依赖UDP 特性。只要你用 Clash Meta（Mihomo）做透明代理，任意一类主机名被误直连、被过大范围的 GEOIP 提前匹配、或 DNS 解析落在与策略出口不一致的池子里，浏览器里就会表现为网页卡顿、播放器起播失败、直播间频繁重连。
与同站 小红书网页、Figma 画布等问题同构：要先建立可复查的证据链，再写规则。若客户端尚未就绪，可先按 Windows Clash 安装步骤 导入订阅，把模式切到规则匹配，打开连接日志复现一次卡死时间窗，把那一刻出现的主机名当成你分流表的第一手来源。
Web 刷短视频 vs LIVE：观测重点不完全相同
仅刷短视频时，你多半看到的是密集的 HTTPS 短连接与少量 WebSocket；问题常见形态是某些 CDN 子域在日志里被分流到了与主站不同的策略组，导致首屏脚本与媒体分片出口不一致，从而在浏览器里表现为无限 loading 或只有首帧。进入 LIVE 后，除了继续依赖多域资源，还可能出现低频长连接与UDP 流：若你的入站是系统代理而游戏/语音类规则偏TUN，或反过来，浏览器子进程的流量没有完整进隧道，就会出现「短视频凑合能看、一进直播就断」的错觉——本质是不同协议族没走同一套策略入口。
为什么不要盲目堆「最快节点」
峰值测速高并不代表会话稳定。直播与 WebSocket 往往怕中途换线：策略组若在 url-test 节奏里频繁切换出口，浏览器端可能来不及优雅重连，表现为弹幕延迟、音视频卡顿或观众端直接掉线。更优先的目标是：为「你日志里反复出现、且与 TikTok 体验强相关的那批主机」准备低抖动的策略组，必要时在一段时间内手动固定单一出口做对照，再谈自动切换。
连接日志里优先对齐什么
建议按时间线抓住：主机名 / SNI → 规则名 → 策略组 → 链路结果。若只能看到裸 IP，可结合内核嗅探与 HTTPS 域名还原 把维度补齐，再回到 分流规则；否则容易出现「我明明写了 DOMAIN，却永远命中不了」的假配置。对 LIVE 场景，留意是否有成批 UDP 会话与常用 HTTPS 主机不在同一策略路径——这是很多「Web 还行、直播爆」的根因。
1先做 DNS：FakeIP、DoH 与解析漂移
启用 FakeIP 时，若 fake-ip-filter、nameserver-policy 与回退链路的边界不清，典型症状是偶发能开、刷新又挂，或仅部分子资源失败。请先按 Meta 内核 DNS 防泄漏 中的顺序核对：保证「解析 → 选路」在同一套逻辑里闭环，再扩展大段规则。若你同时开浏览器扩展代理、公司 PAC 或多块网卡虚拟适配器，DNS 还容易被重复劫持，看上去像网页问题，本质是解析走岔。
需要仅 Chromium 走 Clash、其余保持系统直连时，可参考 Chrome 与系统代理分离：先把变量面收窄，再观察 TikTok 是否仍间歇性超时，避免把多个代理栈叠在同一台机器上打擂。
2分流规则：给短视频 + 直播相关流量单独占位
在泛用规则之上，为日志里高频出现且与体验耦合的主机名单独建策略组，并把它放在会被误抢的泛规则（过宽的 GEOIP、粗暴的 MATCH）之前。关于自上而下首条命中与 MATCH 语义，可对照 Clash Meta 规则顺序，避免个人覆写永远排在订阅大块之后。若你用 mixin 合并多份远程配置，最终行序以导出结果为准，细节见 Mihomo mixin 覆写。
3YAML 片段示意（域名须用当日日志校核）
下列片段只说明结构与相对位置，不是可不经测试照搬的生产配置。将 TIKTOK-STABLE 换成真实策略组名；后缀与关键字必须来自你当前连接日志中出现的主机名，而不是社交平台上转载的静态列表。
# Example only — replace group name and domains using your live Clash logs
rules:
- DOMAIN-SUFFIX,tiktok.com,TIKTOK-STABLE
- DOMAIN-SUFFIX,tiktokv.com,TIKTOK-STABLE
- DOMAIN-KEYWORD,tiktok,TIKTOK-STABLE
- GEOIP,CN,DIRECT
- MATCH,TIKTOK-STABLE
DOMAIN-KEYWORD 可能过度匹配，仅在确认副作用可控时使用；更安全的是对日志里的精确主机逐步追加 DOMAIN / DOMAIN-SUFFIX。是否出现 byteoversea、p16 系列 CDN、或其他第三方库域名，请以你本地浏览器版本与当时网络下的日志为准。
4LIVE：WebSocket 与 UDP/TUN 侧检查清单
当症状集中在直播：先确认浏览器进程相关流量是否完整进入你期望的TUN 或系统代理路径；混用两者时，容易出现 HTTPS 走了代理而 UDP 仍直连被干扰的情况。其次检查是否对实时相关流量误用了会频繁切换节点的 url-test 组；做法与 url-test 与自动切换 一文中讨论的一致，只是业务换成了直播会话。若你要对照长视频 CDN 行为，也可并行阅读 YouTube 4K 缓冲 一文，但请注意二者域名体系不同，不要混抄规则。
5间歇性失败与策略组抖动
网页卡顿有时是TCP 会话在策略切换时被打断；有时是 TLS 握手阶段就因为 SNI 与出口不一致而失败。对可复现时段，临时固定单节点验证是否与自动测速切换相关；若是明确 reset，可用 connection reset 与时间线 把规则命中与断开时刻对齐，区分是本地策略还是远端策略。
按现象快速对照
短视频能刷，点开 LIVE 就断：优先核对 UDP 与 WSS 相关主机是否落在同一策略组，以及入站是否统一（代理模式 / TUN / 仅浏览器）。
偶发能开、刷新就白屏：优先怀疑 FakeIP 与 DoH 竞态或多代理并存；先收敛为单一入口再观察。
全局慢但别站正常：多为 CDN 子域未归档完整；回到日志把失败请求的 host 全量抄出再写入规则。
提示：各区域运营的域名、CDN 与灰度策略会变更。本文不替代平台文档与公告；分流规则与 fake-ip-filter 应以你当次复现的日志为准，保持可增量维护。
客户端获取：安装与更新请优先使用本站下载页；开源仓库适合查看 Issue 与行为变更，与安装包分发入口建议分开理解。
合规：请遵守所在地法律法规、网络使用政策与相关平台服务条款；勿将代理用于未授权的数据处理或违规用途。
小结
让 TikTok 网页与 LIVE 在 Clash 环境下更稳定，关键是用连接日志把 Web 侧的 HTTPS / WebSocket 与直播侧可能出现的 UDP 路径放在同一套「可预期」的分流规则与低抖动策略组里，并先把 DNS（含 FakeIP、DoH）与选路对齐；少背域名表、多信复现数据，才能把网页卡顿与直播断流从玄学变成可定位的工程问题。与同站热点 AI 服务类文章相比，本文刻意落在短视频 + 直播链路侧，与同系列的 Threads、YouTube 选题互补不重复。
Mihomo / Clash Meta 的可观测性与规则组合能力，适合这种「主机多、会话长、协议杂」的浏览场景——把复杂度留在可版本管理的配置里，而不是留给每一次刷新首页的运气。