先對齊症狀：短片正常、直播才崩？還是全網頁一起卡？
調規則前建議把現象分桶。第一類是產品或帳戶層：版本灰度、區域策略、登入態異常、瀏覽器擴充套件或硬體解碼問題——此時往往直連與代理同樣差，錯誤訊息偏應用語意。第二類才是本文範圍：瀏覽器網頁為了滑短影音、看LIVE、載留言與禮物動效，會對大量不同網名建立 HTTPS、WebSocket，直播情境還可能出現對 UDP 或 WebRTC 類路徑的倚賴；只要其中一段落到直連、另一段走代理，或同一產品的不同主機落在不同策略組，就會出現畫面卡頓、音畫不同步、聊天室轉圈或錯誤重試風暴。
若只看錄播短片略可、一進 LIVE 就明顯惡化，請優先懷疑接管範圍：僅系統 HTTP 代理時，部分直播相關UDP可能繞過代理；若改 TUN 後明顯改善，方向就清晰了。若TUN 與系統代理切換會改變卡頓型態，也代表問題更像路徑分裂而不是單純延遲。另可參考 Discord 語音與 UDP／TUN 的排查語彙，與本文直播側角度互補（產品不同，除錯順序可類比）。
TikTok 系流量在網路層常長什麼樣？
使用者在同一分頁內滑短影音，背後往往是多個邊緣域名與 CDN輪替；進入LIVE後，為了低延遲，除了常見的 TLS 控制面，還可能伴隨長連線的 WebSocket、信令與統計請求，以及依客戶端與瀏覽器組合而異的QUIC／UDP行為。對 Clash 來說這不是「一個 tiktok.com 就結束」，而是大量獨立連線各自走完 DNS → 規則 → proxy-groups → 節點；任一要衝（例如某條直播媒體或某個 API 簇）走錯出口，介面就可能看似載入中卻永遠等不到資料。
公開網名會隨產品改版、地區與實驗分桶而變；撰寫本文時無法給「永久官方全表」。實務上請以連線日誌中出現的完整網名（小寫）為準，把與您這次工作階段相關的主機分批納入私有規則集，並在 App／網頁大改版後用「滑首頁 → 進 LIVE → 開／關彈幕與聊天」重跑一次掃描。相較 Threads 偏重 Graph／社群 API 簇，TikTok這邊請特別留意短片與直播是否命中不同 CDN 後綴或不同媒體路徑。
網頁短片與 LIVE：WebSocket、UDP 與「只看 TCP 代理」的縫隙
許多讀者習慣用「瀏覽器 + 系統代理」組合：對純 HTTPS API往往足夠，但直播與即時互動常仰賴長連線；若核心或本機防火牆對 WebSocket 升級、長連線 keep-alive 或特定埠別有不一致處理，就會表現為連線穩定變差。更關鍵的是：部分直播路徑偏好 UDP／QUIC，而「只攔 TCP」的代理路徑可能看不到或吃不滿這些封包——這也是為何同站上 TUN 模式教學值得與本文一起閱讀。
若您已在別篇處理過即時協作工具的 WebSocket 與畫布同步，可以把那套「長連線要同一出口、規則先看域名再看 IP」的思維搬過來；差別在於短影音／直播往往還多一層媒體邊緣與信令拆分，更吃日誌收斂。
實務建議：LIVE 卡頓時，除看 TLS 目標外，請在日誌裡一併搜 UDP 與進程／網卡視角；若只在開 TUN 後才「像樣」，先把接管範圍當成第一嫌疑，而非急著換機場。
FakeIP、DoH 與解析漂移：為何會拖累網頁握手？
啟用 fake-ip 時，應用程式可能先看到核心配置的虛擬位址，連線階段再還原網名與路由。若此時 DNS 區段的 nameserver-policy、fallback 與 rules 優先序彼此打架，或瀏覽器另行啟用加密 DNS，就容易出現前半請求與後半請求解析不一致，最終以網頁卡頓、間歇逾時呈現。
DoH 也需要避免自鎖：在「只有代理可到特定 DoH」的拓樸下，若未正確配置 proxy-server-nameserver（或您核心版本對應鍵名），可能 DNS 管線根本起不來。完整觀念請對讀 Meta 核心 DNS 防洩漏與 FakeIP；若懷疑直連網名誤入 FakeIP，請交叉參考 fake-ip-filter。
實務建議：除錯期關閉瀏覽器「安全 DNS」類選項，讓解析權威集中在 Clash 可觀測鏈路。
TUN、系統代理與瀏覽器：為何 LIVE 特別敏感？
桌機瀏覽器多會跟隨系統代理，但直播相關 UDP 與部分非代理感知行為，仍可能在僅 HTTP 代理下漏接。TUN 能把更多流量納入同一視角——導入前請讀 Clash Verge Rev TUN 模式 與 Windows 環境安裝教學，並留意與其他 VPN、虛擬網卡並存時的路由邊界。
1先做 DNS 閉環：nameserver-policy、fallback 與劫持
在撰寫大量 DOMAIN-SUFFIX 規則前，建議把 dns 區段當成規則的一部分。對跨區短影音常用後綴，可在個人設定以 nameserver-policy 指定可信上游，並為「僅能經代理連到的 DoH」預留避免自鎖配置。若切換 DoH 供應商後症狀立刻變化，優先懷疑污染／劫持／邊緣解析錯位，而不是先堆更多 GEOIP。
建議保留可重現紀錄：時間戳、網路環境（住宅／熱點）、是否開啟瀏覽器 encrypt DNS、當時是否 TUN——數月後仍可還原變因。
2再把網名接到同一策略組：YAML 骨架示例
下列片段僅演示類型與順序；請將 PROXY 換成您介面中實際存在的 proxy-groups 名稱，並以日誌中的真實網名覆寫；切勿直接複製成「萬用清單」。註解使用英文以符合常見儲存庫慣例。
# Example only — verify every FQDN in client logs; TikTok hostnames change by region
rules:
- DOMAIN-SUFFIX,tiktok.com,PROXY
- DOMAIN-SUFFIX,tiktokv.com,PROXY
- DOMAIN-SUFFIX,ttwstatic.com,PROXY
# Add CDN / live / API hosts observed in YOUR sessions (see logs)
- GEOIP,CN,DIRECT
- MATCH,PROXY
若策略是特定網域一律不可直連內地，請把相關規則放在 GEOIP,CN,DIRECT 之前，避免被寬鬆國別規則提前命中。若連線先以 IP 出現在日誌、網名稍晚才由 Sniffer 補上，請對照 Sniffer 與 HTTPS 嗅探。規則順序可讀 Clash Meta 誰先匹配？
3排查順序：DNS → 規則第一條命中 → TUN／UDP → 節點
當 TikTok 網頁或 LIVE 不穩時，建議固定此順序，避免同時改太多參數：
DNS與FakeIP：關掉瀏覽器平行 encryptDNS；檢查路由器或公司策略是否覆寫解析。- 規則命中：在連線列表找出卡頓時段的請求，確認第一條命中是否一致；是否出現同一產品不同主機落到不同
proxy-groups。 TUN與UDP：若直播才崩，比較開／關 TUN 與本機防火牆是否阻擋UDP；必要時與UDP語音除錯對照思路。- 節點品質：策略已對齊後，再測延遲、丟包與
TLS握手；若只有長連線易斷，也少見純粹「換一顆節點」就永治。
若IPv6／雙棧也在環境內啟用，間歇逾時可能被放大，可並讀 prefer-ipv6 與 DNS 雙棧排查。
法規、服務條款與責任邊界
請遵守所在地法律、平台服務條款與智慧財產權。本文僅協助您在自有裝置上進行合法合規的連線除錯與路由設定，不構成規避內容審查或帳戶政策的指引。若直連與代理均同等失敗且跨網路可重現，請優先考量服務端或帳戶因素。
提醒：勿在未授權的企業或公共網路擅自改動路由與 DNS 政策。
開源資訊與安裝包取得方式
若需查閱授權條款、原始碼或提交議題，公開程式庫仍是合適資訊來源。取得圖形客戶端安裝包時，建議優先使用 本站 Clash 下載頁，並參考 設定說明；將「下載可執行檔」與「閱讀專案 README」分開，可降低誤解。
結語
TikTok的網頁卡頓與LIVE（直播）不穩，在網路層經常可收斂為短片與直播各自依賴的多段連線是否在同一出口，以及 DNS／FakeIP 是否造成解析漂移。先把解析與分流規則對齊，再驗證 TUN 是否吃滿 UDP／長連線，最後才換節點——順序對了，比盲目試機場更省時間。相較長影音站點偏重單一媒體域的緩衝體驗，短影音＋直播更吃「多主機、多協定」的一致性；建立可維護的私有網名表並在改版後增量更新，長期維持連線穩定會現實得多。
就工具體系而言，Clash／Mihomo 在規則、策略組與連線日誌之間的對照清楚，適合當成與朋友或同事共用的除錯語言。