Efter byte av internetleverantör och ominstallation av ZimaOS upptäckte en communitymedlem att värden kunde pinga webbplatser på internet och ladda ned avbildningar från App Store, medan applikationer i containrar inte kunde nå externa tjänster. qBittorrent kunde inte ladda ned, och Jellyfin kunde inte hämta metadata.
Det ursprungliga fallet löstes genom att flytta de berörda containrarna från bryggnätverk till värdläge. Senare svar dokumenterade ett annat fall med liknande symtom men en annan orsak: en offentlig WAN-adress hade angetts som gateway, och användarens ISP-anslutning krävde dessutom IPv6 tillsammans med IPv4 för Jellyfin.
Värdanslutning bevisade inte containeranslutning
Författaren kunde använda ZimaOS webbterminal och installera appar, vilket visade att själva operativsystemet hade en fungerande utgående anslutning. Det bevisade inte att varje Docker-nätverk hade korrekt routing. Apparnas problem behövde därför testas från containersidan i stället för att härledas från värden.
Giorgio från Zima-teamet föreslog att man skulle testa anslutningen via en webbläsarcontainer och prova ett annat nätverksläge i applikationens inställningspanel. Inlägget nämner också att tredjepartsbutiker, YAML-installation och CLI-installation kan tillhandahålla diagnostikappar, men dessa är alternativ och inget bekräftat krav.
Värdläge löste det ursprungliga fallet med bryggnätverk
Författaren flyttade alla berörda containrar till värdläge och rapporterade att internetåtkomsten började fungera. Tråden fastställer inte varför bryggläget slutade fungera efter den rena installationen, så värdläge bör dokumenteras som den fungerande ändringen för denna konfiguration, inte som ett bevis på ett allmänt fel i bryggnätverk.
En senare deltagare påpekade en viktig bieffekt: efter byte av läge kan länken i instrumentpanelen fortfarande hänvisa till den gamla publicerade värdporten. För Jellyfin behövde deltagaren gå direkt till port 8096 eftersom instrumentpanelen fortfarande öppnade port 8097.
Ett senare fall visade en felaktig gateway
Den andra användarens Jellyfin-loggar innehöll No route to host vid kontakt med en extern metadatatjänst. Communitymedlemmar rekommenderade att testa utan VPN och kontrollera gatewayen som visades i ZimaOS nätverksinställningar.
En skärmbild visade att den konfigurerade gatewayen var användarens offentliga WAN-adress. Svaren förklarade att gatewayen i stället skulle vara den lokala routerns adress på samma LAN-subnät. Användaren korrigerade gatewayen och aktiverade även IPv6 tillsammans med IPv4 i Jellyfin eftersom AT&T-anslutningen föredrog IPv6. Därefter bekräftade användaren att metadata och bilder kunde hämtas.
Håll de två communityresultaten åtskilda
- Det ursprungliga fallet från oktober 2025: bryggnätverk fungerade inte för författarens containrar; värdläge återställde åtkomsten.
- Uppföljningsfallet från januari 2026: gatewayen var konfigurerad som en offentlig IP-adress, och Jellyfin behövde även IPv6 aktiverat för den ISP-anslutningen.
Båda gav det övergripande symtomet ”appar kan inte komma åt internet”, men de hade inte en gemensamt verifierad grundorsak. Tråden stöder att nätverksläge, adressen som används efter ett lägesbyte, gatewaykonfiguration, VPN-inverkan och protokolltillgänglighet kontrolleras som separata felsökningsspår.
Vanliga frågor
Varför kan ZimaOS ladda ned appar medan en container fortfarande är offline?
Värden och en Docker-container kan använda olika routing och nätverkskonfiguration. I det ursprungliga fallet förblev värdanslutningen fungerande medan applikationer i bryggnätverk misslyckades.
Behåller Jellyfin den gamla instrumentpanelsporten när man byter till värdläge?
Inte nödvändigtvis. En deltagare upptäckte att instrumentpanelen fortfarande länkade till port 8097, medan Jellyfin i värdläge kunde nås direkt på 8096.
