hls:networkError_manifestLoadErrorは、動画の再生に使う最初のマニフェストを読み込めなかったことを示します。エラー名だけでは、Chrome、回線、配信元のどこが原因かは分かりません。「status 403」「status 410」「fatal: true」がある場合は、その追加情報から対処を選びます。
manifestLoadErrorに403や410が併記される場合は、そのHTTP応答を先に確認し、VPNやDNS変更だけで原因を確定しないようにします。
manifestLoadErrorとfatal: trueの意味
HLSでは、再生する映像等を指定するプレイリスト（マニフェスト、通常は.m3u8）を取得します。hls.jsの公式APIのエラー説明では、初期マニフェストの通信失敗をMANIFEST_LOAD_ERRORとして扱います。動画の途中で使う別のプレイリストや映像データの取得失敗とは区別されます。
| 表示の例 | 読み取れること |
|---|---|
| networkError / manifestLoadError | マニフェストの通信取得に失敗。原因の場所は未確定 |
| fatal: true | そのエラーについてライブラリの復旧試行が尽き、再生を継続できない状態 |
| manifestLoadTimeOut | マニフェスト取得の時間切れ。loadErrorとは別の詳細名 |
| manifestParsingError | 取得した内容をマニフェストとして解釈できない問題 |
詳細名は公式のErrorDetails一覧で確認できます。fatalはPCの故障や危険なファイルという意味ではありません。また、サイトの画面に出る「hls:…」の表記はプレイヤー側で整形される場合があり、同じ名前でも実際の応答を確認する必要があります。
視聴者が最初に試すこと
- 配信サービスの正式な動画ページを開き直します。保存していた.m3u8のURLを直接再利用せず、ログイン状態、視聴権限、配信期間を画面で確認します。
- 同じサイトの別動画を試します。一つの動画だけか、すべての動画で起きるかを分けます。サービスの障害案内がある場合は確認します。
- Chromeを更新し、サイトが対応している別ブラウザーでも、同じアカウント・動画を試します。
- Chromeだけで起きる場合は、動画に関係する拡張機能を一つずつ一時停止して比較します。改善しなかったものは元へ戻します。
- 再現条件とエラー全文を記録します。解消しない場合は、以下のHTTP応答確認へ進みます。
更新はChrome公式の手順を参照できます。別ブラウザーで成功しても、拡張機能が原因と即断せず、ログイン、Cookie、プレイヤー、配信されるURL等の違いを確認します。
status 403の場合：アクセス拒否の理由を確認する
HTTP 403 Forbiddenは、サーバーが要求を理解したうえで処理を拒否した応答です。同じ要求を繰り返すだけでは解消しません。視聴権限、配信側のアクセス条件、署名付きURL等を確認し、必要な要求が変わるかを見ます。
- 動画ページのログイン・購入・契約・利用可能地域等の案内を確認します。サービスが提示している正規の視聴方法で試します。
- 長時間開いたタブや古いリンクなら、動画ページを開き直し、新しい再生セッションで試します。期限付きURLが新しく発行されるかはサービスの仕組みによります。
- 新しい再生要求でも403が続く場合は、発生時刻と対象動画を配信元へ報告します。視聴者がCORSヘッダーや署名を編集して解決する問題ではありません。
CloudFrontの署名付きURLの仕様では、署名、期限、ポリシー等を配信側が検証します。期限切れのほか、署名後にクエリを追加したURLも403になると説明されています。403が出たことだけで「古いCookie」や「ISP制限」とは確定できません。
status 410の場合：古い配信先と現在の動画を照合する
HTTP 410 Goneは、要求したリソースが利用できなくなり、その状態が継続すると考えられる応答です。古い配信URLを何度も再読み込みするより、現在の動画ページから再生し直し、動画自体の配信終了・削除・移動の案内を確認します。
動画ページは公開されているのに、そこから発行される新しいマニフェストにも410が返るなら、ページと配信先の不整合が疑われます。サービスへ対象ページと時刻を伝えてください。410は、単にChromeのキャッシュが壊れたことを示すコードではありません。
Chrome DevToolsでマニフェストの応答を確認する
エラーにステータスが出ない場合は、ChromeのNetworkによる通信確認を使います。ログイン済みの動画ページで開発者ツールを開き、Networkを表示してから再生を再現します。
- Networkの種類をAllにし、記録を有効にした状態で動画ページを再読み込みします。
- .m3u8を検索します。見つからない場合はフィルターを戻し、Consoleのエラーや動画プレイヤーが呼び出した要求も確認します。URLに拡張子が付かない配信もあります。
- 対象要求のHeadersでStatus Code、Response Headersを、Responseで返された内容を確認します。
- HTTPコードがなくfailedやCORS errorになっている場合は、その表示とConsoleの具体的なエラーを記録します。
ChromeのNetworkリファレンスでは、HTTPコードのほか、CORS error、blocked、failed等の表示を区別しています。通信できず応答が得られない状態を、配信サーバーが403を返した状態と同じに扱わないでください。
| 確認結果 | 次の行動 |
|---|---|
| 403 | 視聴権限・署名等のアクセス条件を配信元へ照合 |
| 410 | 現在の動画ページと、使われなくなった配信先を照合 |
| 404 | 要求先を見つけられない。動画ページを開き直して配信元へ確認 |
| 429、500、502、503等 | 応答本文やサービスの案内を確認し、過剰な再試行を避ける |
| CORS error、failed、証明書・名前解決のエラー | Consoleの具体的表示と通信条件を確認 |
| 200でも解析エラー | 本文がHTMLのログイン画面等になっていないか配信管理者が確認 |
HTTP応答の意味はHTTPステータス一覧も参照できます。成功コードが付いても、本文が正しいマニフェストでなければ再生できません。その場合は、表示されるエラー詳細がloadErrorなのかparsingErrorなのかも確認します。
Chromeだけで失敗する場合のCookie・サイトデータ
通常のブラウザーでログインし直しても失敗し、他の対応ブラウザーでは再生できる場合は、対象サイトのデータを確認します。Googleの特定サイトのCookie削除に従い、設定→プライバシーとセキュリティ→サードパーティCookie→すべてのサイトデータと権限を表示で、対象サイトを探します。削除すると、そのサイトからログアウトしたり設定が失われたりする場合があります。必要なデータを確認してから行ってください。
シークレットモードも比較に使えますが、Cookieやログイン、拡張機能の条件が通常モードと異なります。特にサードパーティCookieは標準でブロックされるため、シークレットで失敗したことだけではサービスの不具合と断定できません。
回線を変えた結果から何が分かるか
同じ端末・ブラウザー・動画を別の利用可能な回線で試すと、通信経路との関連を調べられます。ただし、回線やVPNを切り替えると、名前解決、接続元IP、経路、配信CDN側の判定等も変わります。成功してもISPによる遮断を確定する証拠にはなりません。
企業・学校の端末では管理者へ、家庭回線ではルーターや通信事業者の窓口へ、記録した失敗先とエラーを伝えて確認します。DNS変更が有効かは、名前解決の失敗が見られるか等の条件で判断します。403・410の応答だけを見てDNSやMTUを変更する必要はありません。
配信管理者・開発者が確認すること
CORSと認証情報
hls.jsの公式リポジトリは、HLSの各リソースでGET要求を許可するCORSヘッダーが必要と説明しています。初期マニフェストだけでなく、参照されるプレイリスト・映像データ・鍵等も確認します。
Access-Control-Allow-Originがないエラーなら、配信サーバー・CDNで実際の要求元を許可する応答を確認します。認証情報を送る要求ではワイルドカードの許可とcredentialsを組み合わせられないため、正しいオリジンと認証方式に合わせて設定してください。ブラウザーのCORS保護を無効化して視聴者へ配布する方法は修正になりません。
署名付きURL・本文・エラーログ
CloudFrontのcanned policyを使う署名付きURLでは、Expires等はURLのクエリとして組み立てられます。期限はUTCのUnix秒です。すべての配信に同じパラメーターがあるとは限らないので、CloudFront、S3、独自認証等の実際の発行方式で検証します。このExpiresは、一般的なHTTP応答ヘッダーのSignedHeadersから確認する項目ではありません。
200応答なら本文が想定したプレイリストか、エラー時ならCDN・オリジン・認証サーバーのログが同じ時刻で対応するかを確認します。TLSや証明書のエラーが記録されている場合は、その接続先の設定を調べます。
hls.jsのErrorDataではtype、details、fatal、任意のresponseやurl等を記録できます。使用中のhls.jsの版とともに、実際のエラー詳細を取得してください。現在の読み込みポリシーにはmanifestLoadPolicy等がありますが、403や410の原因を残したまま再試行回数を増やしても解決にはなりません。
配信元へ渡す記録
- 対象の動画ページ、動画名、発生時刻とタイムゾーン
- エラー全文、HTTPステータスまたはConsoleの具体的な失敗表示
- Chromeの版、他動画・他の対応ブラウザー・別回線での結果
- 配信元から求められた場合は通信ログ。HARを送る前に内容を確認する
ChromeはCookie・Authorization等を除くHARのsanitized書き出しを用意していますが、署名付きURLのクエリ等に機密情報が残る場合があります。公開掲示板には生のURL・Cookie・トークンを貼らず、配信元の窓口で必要な記録を共有してください。確認結果を揃えると、Chrome側で比較すべき設定と、配信管理者が修正すべき要求先を区別できます。
コメント