はい。サーバー、メディアストレージ、LAN、クライアントがローカルで相互に通信できる場合、Jellyfinは一時的なインターネット障害中もローカルメディアの配信を続けられます。
重要なのは、「Jellyfinはセルフホスト型である」ことが、周辺の依存関係まですべてオフラインで安全になることを意味しない点です。パブリックDNS経路、クラウドトンネル、外部ホストのカスタムCSS、さらにはストリーミングデバイス自体のランチャーも、Jellyfinサーバーが正常なままでも機能しなくなる可能性があります。障害時に頼る前に、ローカルでの視聴経路全体をテストしてください。
インターネットの切断とローカルネットワークの切断を分けて考える
WAN障害とは、ルーターがインターネットに接続できなくなることです。Ethernetスイッチ、Wi-Fiアクセスポイント、DHCP、ローカルルーティングまで停止する必要はありません。サーバーとクライアントを正常に機能している同じLAN上に置き、ローカルアドレスまたはローカルDNS名でJellyfinサーバーにアクセスできるかテストしてください。
コミュニティの障害テストでは、WANアクセスが停止していてもローカル再生は継続できると一貫して報告されていますが、一部のクライアントデバイスには独自のインターネット依存関係があることも指摘されています。この違いがあるため、サーバーとクライアントは別々にテストする必要があります。
WANがないとルーター自体が再起動してWi-FiやローカルDNSを無効にする場合は、まずそのネットワーク動作を修正してください。アプリケーションがクラウド認証を必要としなくても、ホストへの経路を失ったクライアントにJellyfinは配信できません。
パブリックDNSやクラウドトンネルに依存しない経路をローカルクライアントに用意する
すべてのテレビが、DNS、リバースプロキシ、トンネルのいずれかがインターネットに依存するパブリックホスト名経由でしかJellyfinにアクセスできない場合、WAN障害中にローカルサービスが停止したように見えることがあります。ローカルIPまたはローカルDNS名をフォールバックとして記録しておくか、クライアントが自宅にいるときは通常の家庭内ホスト名がローカルで解決されるようにスプリットDNSを設定してください。
ローカル経路はLAN内で終端し、VPSやクラウドサービスを経由せず、意図した同じJellyfinインスタンスに到達する必要があります。実際のクライアントが必要とする証明書とホスト名の動作をテストしてください。フォールバックとして直接ローカルHTTPアドレスを受け入れるアプリもあれば、保存済みのHTTPS URL一つを前提に構成されるアプリもあります。
ZimaSpaceによるローカルアクセスとリモートアクセスを別経路として捉える説明は、正しい考え方です。WAN経路の障害によって、LAN経路まで停止させる必要はありません。
インターネットに依存するメタデータと連携機能の低下を想定する
すでに保存されているメディア、データベースの状態、アートワーク、メタデータはローカルで利用し続けられます。新しいメタデータの検索、プラグインの更新、字幕のダウンロード、リモート画像アセット、その他の外部プロバイダーへの接続は失敗したり、インターネットが復旧するまでタイムアウトを待つ状態になったりします。
オフライン環境でローカルメディアを使ったJellyfinのコミュニティテストでは、既存のローカルメタデータは引き続き利用できる一方、新しいスクレイピングは利用できないと報告されています。すべての拡張機能がコアの再生経路に含まれると考えるのではなく、キャッシュされたローカルアセットを中心に障害時の利用環境を設計してください。
カスタムテーマがパブリックURLからフォントやCSSを読み込む場合、オフライン時のインターフェースに重要であれば、それらのアセットをローカルでホストしてください。同様に、意図的に障害時の依存関係を受け入れているのでない限り、家庭内のローカルユーザーにリモート認証ゲートウェイを必須にすることは避けてください。
JellyfinのWebページだけでなく、クライアントデバイスもテストする
一部のスマートテレビプラットフォームやストリーミングスティックは、Jellyfinクライアントの起動後にローカル通信ができる場合でも、ホーム画面、アプリの起動、アカウント確認、プラットフォームサービスのためにインターネットアクセスを要求します。障害中にノートパソコンのブラウザーで成功しても、リビングルームのデバイスで利用できるとは限りません。
家庭内の報告では、インターネットのないLAN上でのクライアント固有の挙動が説明されています。そのため、デバイスのプラットフォームも可用性設計の一部になります。家族が利用するすべてのクライアント種別をテストしてください。
クラウド起動なしでローカルURLを開けるフォールバッククライアントを少なくとも一つ用意してください。ノートパソコン、タブレット、HTPC、その他の実際にテスト済みのデバイスが使えます。目的はすべてのベンダーの挙動を予測することではなく、次の障害が起きる前に、家庭内で利用可能な経路を一つ実証することです。
WAN切断の管理された訓練を実施する
ルーターやWi-Fiの電源を切ってテストしないでください。ローカルネットワークを維持したまま、WAN uplinkだけを切断またはブロックします。その後、クライアントを完全に終了した状態からJellyfinを開き、必要に応じてログインし、既存のメタデータを閲覧し、ダイレクトプレイのファイルを再生し、家庭で利用している場合はトランスコードを開始し、シーク、再開、ユーザー切り替えを行います。
テスト中は、どの操作がローカルで完了し、どの操作が外部サービスでタイムアウトするかを記録してください。WANを再接続し、失敗したメタデータや更新タスクがライブラリの状態を壊さずに復旧することを確認します。外部接続の処理によってローカル操作が停止する場合は、その機能を障害時の依存関係として正確に記録してください。
通常の家庭内クライアントがサーバーを見つけ、ローカルで認証し、保存済みコンテンツを閲覧し、WANがない状態で代表的なメディアを再生できれば、設計は合格です。失敗する項目は「Jellyfinにはインターネットが必要」と一括りにせず、ローカルネットワーク、クライアントプラットフォーム、パブリック経路、外部連携のいずれに依存するかを分類してください。
よくある質問
インターネットが切断されると、既存のJellyfinのポスターやメタデータは消えますか?
通常は消えません。サーバーにすでに保存されているメタデータやアートワークはローカルに残ります。停止するのはインターネット上のプロバイダーから新しい情報を取得する処理なので、新しく追加したメディアやオンデマンドの情報補完は、接続が復旧するまで不完全になる可能性があります。
なぜスマートフォンではオフラインでJellyfinに接続できるのに、テレビでは接続できないのですか?
Jellyfinサーバーが正常でも、テレビのプラットフォームがランチャー、アプリの起動、DNS、ネットワーク検証のために独自のインターネット接続を必要とする場合があります。WANだけを切断した状態で、実際のテレビやストリーミングボックスをテストし、障害時の視聴が重要ならローカルのフォールバッククライアントを用意してください。
サポートとヒント
もっと読む

Jellyfinでは共有アカウントを1つ使うべきか、それとも家庭内で別々のアカウントを使うべきか?
必要な本人確認、アクセス、ペアレンタルコントロール、復旧の境界に応じて、Jellyfinの家庭用アカウントを選択してください。

作業完了後もJellyfinのメモリ使用量が高いままなのはなぜですか?
Jellyfinプロセスの増加とLinuxキャッシュを切り分け、メモリ使用量が増え続けるか、実際にメモリ圧迫が発生した場合にのみ調査してください。

Jellyfinのストレージ構成が復旧リスクになりつつある兆候
Jellyfinのストレージの役割を監査し、稼働中の状態をバックアップや再構築可能なデータから分離したうえで、復元によってその構成を検証する。

