Po zmianie dostawcy internetu i ponownej instalacji ZimaOS członek społeczności odkrył, że host mógł pingować witryny internetowe i pobierać obrazy ze sklepu z aplikacjami, podczas gdy aplikacje wewnątrz kontenerów nie mogły łączyć się z usługami zewnętrznymi. qBittorrent nie mógł pobierać danych, a Jellyfin nie mógł pobierać metadanych.
Pierwotny przypadek rozwiązano, przenosząc dotknięte problemem kontenery z sieci mostkowej do trybu hosta. Późniejsze odpowiedzi opisały drugi przypadek z podobnymi objawami, ale inną przyczyną: jako bramę wpisano publiczny adres WAN, a ścieżka sieciowa użytkownika wymagała również IPv6 obok IPv4, aby Jellyfin działał prawidłowo.
Łączność hosta nie potwierdzała łączności kontenerów
Autor mógł korzystać z terminala internetowego ZimaOS i instalować aplikacje, co wykazywało, że sam system operacyjny miał działające połączenie wychodzące. Nie oznaczało to jednak, że każda sieć Dockera miała prawidłowy routing. Dlatego problemy aplikacji należało testować z poziomu kontenera, zamiast wyciągać wnioski na podstawie działania hosta.
Członek zespołu Zima, Giorgio, zasugerował przetestowanie łączności za pomocą kontenera przeglądarki oraz wypróbowanie innego trybu sieciowego w panelu ustawień aplikacji. W poście zaznaczono również, że dodatkowe aplikacje diagnostyczne można instalować z zewnętrznych sklepów, za pomocą pliku YAML lub interfejsu CLI, ale są to opcje, a nie potwierdzony wymóg.
Tryb hosta rozwiązał pierwotny przypadek związany z siecią mostkową
Autor przeniósł wszystkie dotknięte problemem kontenery do trybu hosta i poinformował, że dostęp do internetu zaczął działać. Wątek nie wyjaśnia, dlaczego tryb mostkowy przestał działać po czystej instalacji, dlatego w tej konfiguracji tryb hosta należy uznać za skuteczną zmianę, a nie dowód na powszechną wadę sieci mostkowej.
Późniejszy uczestnik zwrócił uwagę na ważny skutek uboczny: po zmianie trybu link w panelu może nadal wskazywać stary opublikowany port hosta. W przypadku Jellyfin uczestnik musiał przejść bezpośrednio na port 8096, ponieważ panel nadal otwierał port 8097.
Późniejszy przypadek ujawnił nieprawidłową bramę
W logach Jellyfin drugiego użytkownika pojawiał się komunikat No route to host podczas łączenia się z zewnętrzną usługą metadanych. Członkowie społeczności zalecili przetestowanie konfiguracji bez VPN oraz sprawdzenie bramy wyświetlanej w ustawieniach sieciowych ZimaOS.
Na zrzucie ekranu ujawniono, że skonfigurowaną bramą był publiczny adres WAN użytkownika. W odpowiedziach wyjaśniono, że bramą powinien być lokalny adres routera znajdujący się w tej samej podsieci LAN. Użytkownik poprawił bramę i włączył IPv6 obok IPv4 w Jellyfin, ponieważ jego połączenie AT&T preferowało IPv6. Następnie potwierdził, że pobieranie metadanych i obrazów działa.
Te dwa wyniki społeczności należy rozpatrywać oddzielnie
- Pierwotny przypadek z października 2025 r.: sieć mostkowa nie działała w kontenerach autora; dostęp przywróciło użycie trybu hosta.
- Przypadek uzupełniający ze stycznia 2026 r.: jako bramę skonfigurowano publiczny adres IP, a Jellyfin wymagał również włączenia IPv6 w przypadku tego dostawcy internetu.
Oba przypadki powodowały ogólny objaw „aplikacje nie mogą uzyskać dostępu do internetu”, ale nie miały jednej potwierdzonej przyczyny. Wątek uzasadnia sprawdzenie trybu sieciowego, adresu używanego po jego zmianie, konfiguracji bramy, wpływu VPN oraz dostępności protokołów jako oddzielnych ścieżek diagnostycznych.
FAQ
Dlaczego ZimaOS może pobierać aplikacje, gdy kontener pozostaje offline?
Host i kontener Dockera mogą korzystać z różnych konfiguracji routingu i sieci. W pierwotnym przypadku łączność hosta pozostawała prawidłowa, podczas gdy aplikacje korzystające z sieci mostkowej nie działały.
Czy zmiana Jellyfin na tryb hosta zachowuje stary port w panelu?
Niekoniecznie. Jeden z uczestników stwierdził, że panel nadal kierował na port 8097, podczas gdy Jellyfin w trybie hosta był dostępny bezpośrednio na porcie 8096.
