HLS 在手機能播放，投放到電視卻失敗：投放故障排查指南

一條 HLS 串流可能在手機或電腦上播放正常，連上電視後卻在幾秒內停止。這個結果不能證明電視的 Wi-Fi 訊號太弱，也不能證明播放清單適用於所有裝置。在許多投放系統中，遠端接收器會自行載入媒體；傳送端已成功完成的請求和解碼能力，不再代表完整的播放路徑。

本指南把傳送端控制、接收端網路、媒體支援、授權和輸出行為分開檢查。請只測試自己擁有或獲准檢查的串流。分享記錄前，務必移除簽章查詢參數、Cookie、裝置識別碼、IP 位址和帳號資料。

*驗證方法 — 2026 年 9 月 21 日：*我們使用 Node.js 24.12.0 執行一個只監聽本機回送位址的 HTTP 測試服務，並建立兩個合成請求來源。伺服器允許 https://sender.example.test，但沒有為 https://receiver.example.test 傳回 Access-Control-Allow-Origin。兩個來源都收到了播放清單位元組，以及四位元組 Range 請求的 206 回應；只有傳送端獲得相符的 CORS 回應標頭。這項測試只驗證測試服務的 HTTP 標頭差異與 Range 回應。Node 的 fetch 不會執行瀏覽器的 CORS 限制。我們沒有測試 Chromecast、Apple TV、AirPlay 接收器、智慧型電視、DRM 系統或真實媒體解碼器。下文的裝置相關說明均來自文件核對。測試腳本位於 scripts/test-cast-hls-origin-headers.cjs。

先確認播放工作轉移到了哪裡

「投放」可能代表幾種完全不同的架構：瀏覽器分頁鏡像、系統把媒體 URL 交給接收器，或應用程式與自己的接收端程式通訊。因此，電視可能只是在顯示傳送端算出的畫面，也可能正在執行一個獨立播放器，由它自行發出 HLS 請求。

記錄實際使用的是螢幕鏡像、瀏覽器 Remote Playback、Google Cast、AirPlay、智慧型電視應用程式還是 HDMI。不要把這些路徑的結果統稱為「投放結果」。MDN 將 Web Remote Playback API 標示為支援度有限，因此不能因為作業系統其他位置出現 Cast 或 AirPlay 按鈕，就推斷網頁 API 一定可用。

分別收集傳送端與接收端證據

傳送端瀏覽器的開發者工具通常只顯示傳送端頁面發出的請求，不一定會列出接收器請求。交接後傳送端立即停止下載片段，可能是正常現象；如果沒有接收端記錄，傳送端的 Network 面板無法告訴你接收器的哪個請求失敗。

對於自己控制的應用程式，應取得接收端記錄，或查詢交接時段的 CDN 請求記錄。使用不會洩露隱私的工作階段 ID 或請求 ID 進行關聯，不要公開媒體 URL。建議記錄：

1. 精確的交接時間與時區。
2. 傳送裝置、瀏覽器或應用程式版本、網路，以及本機播放狀態。
3. 接收器型號、韌體或接收端版本、網路和顯示輸出裝置。
4. 重新導向後的最終播放清單 URL，以及接收端發出的第一個請求。
5. 第一個失敗請求的狀態碼、內容類型、Range 標頭、快取結果和最終 URL。
6. 選取的變體、編解碼器、音訊群組、字幕軌和目前媒體位置。
7. 控制狀態變成播放、緩衝、閒置還是錯誤。

若無法取得接收端記錄，伺服器或 CDN 記錄通常是確認電視是否請求過播放清單的第一份可靠證據。我們的開發者工具請求檢查指南仍適用於傳送端，但不能代替接收端追蹤。

檢查接收端路徑的 CORS

Google 的 Web Receiver 文件說明，串流協定使用受 CORS 約束的非同步請求，內容伺服器決定媒體可以在哪些位置使用。Google 也指出，自適應媒體和媒體軌需要正確的 CORS 回應標頭。因此，只允許包含 Cast 按鈕的網站來源往往不夠，因為接收端應用程式可能使用另一個來源。

我們的測試呈現了一個常見誤區：兩個合成來源都取得播放清單的 HTTP 200，但接收端來源沒有得到相符的 Access-Control-Allow-Origin。伺服器記錄出現 200，並不能證明接收端 JavaScript 可以讀取回應。真正的接收器平台決定是否以及如何執行 CORS；Node 測試沒有模擬這層限制。

要檢查整條資源鏈，而不只是入口清單：

• 多變體播放清單與媒體播放清單。
• 初始化片段和媒體片段。
• 備用音訊、字幕播放清單及其片段。
• 加密金鑰和允許存取的授權伺服器端點。
• 重新導向後的目標位址，而不只是原始主機名稱。
• Range 請求，以及適用時的預檢請求回應。

不要架設開放的公用 Proxy，也不要把放寬正式環境存取控制當作長期修正。應在自己控制的基礎架構設定準確的來源、憑證、方法和請求標頭，再以真實接收器重新測試。

比較授權資料，但不要複製機密

本機播放可能依賴瀏覽器 Cookie、Authorization 請求標頭、Referrer 或短效簽章 URL。遠端接收器不會自動繼承傳送端工作階段的全部資料。主播放清單可能能夠載入，但子播放清單、金鑰或片段卻使用了過期或不完整的授權。

沿著接收器的第一個請求檢查完整的播放清單鏈。比較各請求包含哪些查詢參數和標頭、簽章有效多久，以及重新導向是否刪除或改變授權。如果串流先播放片刻再停止，可以把權杖到期時間與失敗時間比較，但不能只因時間接近就斷定是過期造成的。

不要把仍有效的簽章 URL 貼到公開問題中，也不要硬編碼進網頁。向服務負責人提供去識別化路徑、狀態碼、有效期間長度和請求 ID 即可。

核對 Range 行為和回應類型

即使本機播放只請求完整物件，接收器也可能使用位元組 Range 請求。我們的測試對受控片段請求回傳了 206 Partial Content、Content-Range 和 Accept-Ranges，但沒有驗證媒體容器或任何裝置行為。

對於獲准測試的真實媒體，應確認 Range 請求得到內部一致的回應：適用時狀態為 206、Content-Range 有效、總長度正確、傳回的是所要求的位元組，內容類型也符合媒體。留意 CDN 或授權層是否忽略、移除或拒絕 Range。某些資源和用戶端路徑回傳 200 也可能合理，因此要配合實際請求與平台文件判斷，不能把單一規則套用到所有情況。

也要確認 .m3u8 位址回傳以 #EXTM3U 開頭的 HLS 文字，而不是 HTML 登入頁或 CDN 驗證頁。我們的完整 HLS 播放故障排查指南說明為什麼成功狀態仍可能搭配錯誤內容。

依接收器能力配對編解碼器，而不是依手機判斷

手機和電視的硬體解碼器、支援的 Profile、聲道配置、最高解析度、影格率、HDR 能力和容器限制都可能不同。傳送端能夠解碼，不代表接收端一定相容。

Google 公布了各 Cast 裝置的媒體支援資訊，也為相容的接收端應用程式提供 CastReceiverContext.canDisplayType()。目前文件列出的編解碼器和解析度限制因裝置而異；例如，文件明確說明 Transport Stream 容器不支援 HEVC。應查閱目前的目標裝置表，不要只根據「4K」標示或一次手機播放成功做判斷。

檢查多變體播放清單的 CODECS、RESOLUTION、FRAME-RATE、音訊聲道和真實媒體內容。如果產品需求與裝置支援情況允許，可以提供保守的 H.264/AAC 版本，但不能只把不相容媒體的標籤改掉。若遇到備用音訊問題，可使用HLS 音軌故障排查指南。

把直播交接視為時間視窗問題

接收器加入直播時，會依自己的播放清單快照和直播位置開始播放。如果播放清單快取過久、片段在真正可用前就被公布，或接收器從即將消失的視窗邊緣開始，本機播放仍可能正常，而接收端會失敗。

儲存連續兩次接收端媒體播放清單回應，比較 #EXT-X-MEDIA-SEQUENCE、最新片段、快取標頭、請求時間，以及接收器選取的第一個片段。確認該片段在交接當下是否仍可用。不要根據手機仍在播放就推斷接收器也已恢復；兩個用戶端可能位於不同的直播位置。

可用我們的過期播放清單與缺失片段診斷指南，區分沒有更新的直播快照，和新公布後卻回傳 404 的媒體物件。對於低延遲 HLS，應確認接收端路徑支援內容實際採用的功能，不要假定所有 HLS 模式完全相同。

檢查輸出和控制狀態

如果請求與解碼看起來都正常，還要確認播放是否只是無聲、輸出到其他裝置、被暫停，或受到 HDMI、HDCP、顯示模式影響。記錄接收器音量、靜音狀態、音訊路由、顯示裝置能力，以及影片時間是否持續前進。

傳送端按鈕顯示「已連線」，只能證明控制工作階段成立，不能證明媒體播放成功。電視上的封面也可能在任何片段解碼前由中繼資料產生。應記錄接收端媒體狀態變化和第一個有意義的錯誤，不要把連線狀態當作播放狀態。

DRM 會再增加一層邊界。受保護的串流需要接收器支援的 DRM 路徑、授權交換、憑證和輸出保護。通用接收器無法自行產生授權，也不能繞過保護。只能在官方授權的應用程式流程中測試。

建立可重現的裝置矩陣

逐項測試支援的組合，每次不要同時改變多個變數：

至少測試一個低位元率和一個高位元率版本、備用音訊和字幕、拖曳、暫停與繼續，以及直播視窗推進後的交接。把桌面瀏覽器縮到電視尺寸，並不等於測試接收器。無法取得的硬體或不支援的平台，應明確標示為未測試。

圍繞接收端的第一個失敗點撰寫報告

一份可執行的報告可以這樣寫：「本機繼續播放。18:42:11，X 型號接收器請求媒體播放清單並收到 200；之後第一個片段請求在重新導向後回傳 403。去識別化請求 ID 為 Y。」這樣的描述能夠界定負責範圍和下一步檢查項目。

報告應包含投放架構、傳送端與接收端版本、接收端第一個資源的類型和狀態、CORS 與 Range 標頭、選取的編解碼器或變體、授權有效期間、直播序號和媒體狀態變化。不要包含原始憑證或私人 URL。

第一手參考資料

• Google Cast：自訂 Web Receiver 與 CORS
• Google Cast：支援的媒體格式和裝置編解碼器限制
• Google Cast：Web Receiver 串流協定
• Google Cast：媒體軌的 CORS 要求
• MDN：Remote Playback API
• RFC 8216：HTTP Live Streaming

當 HLS 在本機正常、電視卻無法播放時，先確認究竟是誰在請求媒體。接著依序檢查接收端 CORS、授權、Range 行為、編解碼器支援、直播時間、解碼和輸出。傳送端的一次成功請求，不能證明另一條接收端路徑也正常。