JellyfinはWi-Fiでは動作するが、有線LANまたはVPNでは接続できない

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Jellyfin Works on Wi-Fi but Fails on Ethernet or VPN - Zima Store Online

JellyfinがWi-Fi経由では動作するのに、Ethernet経由またはVPN経由では失敗する場合、通常はサーバー自体は正常で、サーバーまでの経路が変わっています。最も一般的なのは、異なるIP／サブネットまたはDNS応答、誤ったインターフェースを優先するルート、接続を異なるものとして分類するファイアウォール／ローカルネットワークルール、あるいはLANと重複するVPNルートです。

既知の正常なJellyfin URLを1つ使い、影響を受けるクライアントから段階的にテストしてください。まず宛先IPとポートを確認し、次にルートを比較し、その後でファイアウォールとJellyfinのローカルネットワークを確認します。VPN固有のサブネットや出口ノードの動作を調べるのは最後にしてください。同じサーバーに別のインターフェース経由で接続できる間は、Jellyfinを再インストールしないでください。その証拠は、問題がアプリケーションの状態ではなくネットワークにあることをすでに示しています。

Wi-FiとEthernetで宛先アドレスを比較する

正常に動作するWi-Fi接続で、Jellyfinのホスト名、解決されたIPアドレス、クライアントのサブネット、ポートを記録します。Ethernetに切り替え、同じ確認を繰り返してください。ホスト名が別のアドレスや到達不能なアドレスに解決される場合は、Jellyfinの設定を変更する前にDNSまたはクライアントのルートを修正します。

Jellyfinのネットワークに関するドキュメントでは、通常のアクセスにはホストIPと設定されたHTTP(S)ポートを使用し、ローカル検出はローカルサブネットに限定されると説明されています。有線クライアントがWi-Fiネットワークとは異なるVLANまたはサブネットにある場合は、ローカルネットワークの動作を確認してください。

EthernetからサーバーIPに直接接続してテストします。IPでは動作するのにホスト名では失敗する場合、その分岐はDNSです。どちらも動作しない場合は、ルートとファイアウォールの確認に進んでください。TCPポートには接続できるのにアプリの動作が異なる場合は、Jellyfinによるローカル／リモートの分類を確認します。

クライアントが実際に使用しているインターフェースとルートを確認する

Wi-Fi、Ethernet、VPNアダプターを備えたマシンでは、複数のルートが同時に存在することがあります。Ethernetを接続すると、オペレーティングシステムが新しいデフォルトルートや、より具体的なサブネットルートを優先し、JellyfinのトラフィックがWi-Fiで正常だった経路とは別の場所へ送られる場合があります。

オペレーティングシステムのルーティングツールを使ってJellyfinサーバーのIPへのルートを確認し、正常な状態と比較します。分岐を確認するため、一度に1つのインターフェースだけを一時的に無効にしてから再度有効にしてください。どのルールが誤っているか分かるまでは、ルートを恒久的に削除しないでください。

ルートが正しいEthernetゲートウェイを指し、pingではサーバーに到達できるのにJellyfinのポートに接続できない場合、次に確認すべきなのはDNSではなくファイアウォールまたはサービスのバインドです。

ファイアウォールルールとJellyfinのローカルネットワークを確認する

Ethernetサブネット、VPNサブネット、Wi-Fiサブネットに対するファイアウォールポリシーを比較します。ホームルーターや管理対象スイッチでは、3つの接続がすべて物理的には同じ家庭内にあっても、異なるVLANまたはゲストネットワークのルールが適用されることがあります。

Jellyfinで、ローカルネットワークのCIDR値とリモートアクセスのポリシーを確認します。登録されていないサブネットから接続するクライアントはリモートとして扱われる可能性があり、サーバーが正常に待ち受けていても、そのユーザーのアクセス許可が変わることがあります。

ローカルでは成功する一方でリモート経路では失敗する状況を分けて考える例については、ローカルアクセスとリモートアクセスの経路を参照してください。ここでも同じように、アプリケーションを変更する前に各ネットワークホップを確認します。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

VPNのサブネット重複や出口ノードの動作を確認する

VPNを有効にした場合だけ失敗するなら、VPNのルートと物理LANを比較します。同じプライベートサブネットを使用する2つのネットワークがあると、サーバーが物理的には近くにあるにもかかわらず、クライアントがJellyfinのトラフィックをトンネルへ送信することがあります。

Tailscaleでは、サブネットルート、出口ノード、またはLANアクセス設定によって、クライアントがローカルデバイスに到達できなくなる場合について説明しています。VPNルーティングによって、トンネルを有効にする前に機能していた経路がどのように上書きされるかを確認する例として、LAN接続のトラブルシューティングを利用してください。

VPNルートの受け入れまたは出口ノードを一時的に無効にし、同じJellyfin IPで再テストします。すぐにアクセスが戻る場合は、Jellyfinサーバーを変更せず、VPNのルーティングまたはLANアクセスのポリシーを修正してください。

各ネットワーク修正後に元のクライアント経路を再テストする

分岐を特定したら、該当する変更だけを適用します。DNSを修正する、ルートのメトリックまたはプレフィックスを調整する、ファイアウォールでEthernet／VPNサブネットを許可する、またはJellyfinのローカルネットワークのエントリを修正する、といった対応です。その後、通常のすべてのインターフェースを復元し、元の接続方法を繰り返します。

家庭内で両方を使用している場合は、JellyfinのWebクライアントとネイティブクライアントを1つずつ確認してください。検出、保存されたサーバーURL、直接HTTPアクセスでは異なる経路が使われることがあります。また、クライアントの再起動または再接続後にもテストし、キャッシュされたルートによって一時的な成功を恒久的なものと誤認しないようにします。

宛先IP、ルート、ファイアウォール、ローカルネットワークの分類がすべて正しいのに同じインターフェースだけが失敗する場合に限り、詳しい調査へ進みます。正常時と失敗時のルーティングテーブル、クライアントIP、1回の試行時に記録されたサーバーログを取得してください。Jellyfinを再インストールしたり、すべてのネットワーク設定を一度にリセットしたりするよりも、その証拠の方がはるかに役立ちます。