Jeśli Immich nadal otwiera się w domowej sieci Wi-Fi po wymianie routera, ale nie działa przez dane komórkowe, serwer prawdopodobnie działa poprawnie, a zmieniła się warstwa zdalnej ścieżki dostępu.
Wymiana lub zresetowanie routera może zmienić adres serwera w sieci LAN, usunąć reguły przekierowania portów, przydzielić inny publiczny adres IP, zmienić działanie DNS albo przełączyć połączenie w inny tryb NAT. Zacznij od prawdziwego testu spoza sieci i sprawdzaj wszystko od serwera na zewnątrz. Zmieniaj jedną warstwę naraz — otwieranie dodatkowych portów przed ustaleniem, który etap zawiódł, może zwiększyć ekspozycję bez przywrócenia dostępu.
Potwierdź, że problem występuje wyłącznie zdalnie
Najpierw przetestuj Immich na urządzeniu w tej samej sieci LAN, używając bieżącego lokalnego adresu serwera. Następnie wyłącz Wi-Fi w telefonie i powtórz test zdalny przez sieć komórkową. Jeśli dostęp lokalny również nie działa, przestań traktować ten problem jako związany z krawędzią sieci routera i najpierw napraw serwer lub sieć lokalną.
Jeśli dostęp lokalny działa, a zdalny nie, zanotuj dokładną nazwę hosta, protokół i wyświetlany błąd. Limit czasu oznacza coś innego niż ostrzeżenie dotyczące certyfikatu lub strona błędu proxy. Zwróć też uwagę, czy korzystasz z bezpośredniego przekierowania portów, odwrotnego proxy, VPN typu mesh czy tunelu, ponieważ wymiana routera wpływa na te rozwiązania w różny sposób.
Nie używaj tej samej domowej sieci Wi-Fi jako jedynego testu zdalnego. Niektóre routery obsługują wewnętrzne żądania do publicznej nazwy hosta przez hairpin NAT, a inne nie, więc test z sieci LAN może dać fałszywy wynik negatywny lub pozytywny. Wynikiem tego etapu powinien być jednoznaczny objaw: lokalny Immich działa, ale jedna określona zewnętrzna ścieżka dostępu nie działa.
Sprawdź, czy router nadal kieruje ruch do tego samego celu w sieci LAN
Nowy router często przydziela hostowi Immich inny prywatny adres IP. Porównaj bieżący adres serwera w sieci LAN z celem zapisanym w regule przekierowania portów, serwerze nadrzędnym odwrotnego proxy, obiekcie zapory sieciowej lub rezerwacji DHCP. Jeśli reguła nadal wskazuje stary adres, popraw to mapowanie przed wprowadzaniem zmian w Immich.
Odtwórz tylko tę regułę ruchu przychodzącego, której faktycznie wymaga wybrany sposób dostępu. Zweryfikuj zewnętrzny port, wewnętrzny cel, wewnętrzny port i protokół jako jeden zestaw. Jeśli korzystasz z odwrotnego proxy, router zwykle przekazuje ruch do proxy, a nie bezpośrednio do Immich; przekierowanie obu ścieżek może utworzyć drugi, niepotrzebny publiczny punkt dostępu.
Po poprawieniu celu ponownie przetestuj połączenie przez sieć komórkową i sprawdź, czy proxy lub serwer rejestruje żądanie. Jeśli logi nadal są całkowicie puste, ruch nadal zatrzymuje się przed aplikacją. Jeśli żądanie dociera już do proxy lub hosta, ale zwraca błąd aplikacji, krawędź routera prawdopodobnie działa poprawnie, a kolejna sekcja powinna skupić się na publicznym adresowaniu lub rozpoznawaniu nazw.
Porównaj publiczny adres IP, rekord DNS i tryb NAT
Wymiana routera może zbiec się z przydzieleniem nowej dzierżawy WAN. Rozwiąż nazwę hosta używaną przez Immich i porównaj uzyskany wynik z publicznym adresem IP aktualnie przypisanym do domowego połączenia. Jeśli adresy się różnią, nazwa kieruje klientów do starego punktu końcowego, mimo że wszystkie usługi lokalne działają poprawnie.
Dynamiczny DNS utrzymuje nazwę hosta zgodną ze zmieniającym się adresem publicznym. Jeśli nazwa hosta nadal rozwiązuje się do starego adresu WAN, klienci zewnętrzni będą nadal trafiać do niewłaściwego celu, dopóki rekord i odpowiednie pamięci podręczne nie zostaną zaktualizowane. Sprawdź jak dynamiczny DNS śledzi zmieniające się adresy IP, popraw aktualizator lub rekord, a następnie ponownie przetestuj połączenie z użyciem zewnętrznego resolvera i danych komórkowych.
Jeśli adres WAN routera nie odpowiada publicznemu adresowi widocznemu z internetu, nowe połączenie może znajdować się za NAT-em operatorskim lub inną nadrzędną warstwą NAT. Przy NAT między urządzeniami a publicznym internetem zmiana przekierowania portów na domowym routerze może nigdy nie uczynić usługi dostępną. W takim przypadku użyj publicznego adresu, ścieżki VPN lub nakładkowej albo innej metody dostępu, która nie zależy od niezamówionego przekierowywania ruchu przychodzącego.
Po zmianie sieci zweryfikuj stan odwrotnego proxy, TLS i zapory
Jeśli ruch zewnętrzny dociera do hosta, ale Immich nadal się nie otwiera, sprawdź warstwy tożsamości, którymi router nie zarządza. Potwierdź, że odwrotne proxy nadal wskazuje bieżący adres i port Immich, nazwa hosta pasuje do trasy proxy, a zapora serwera zezwala na zamierzoną ścieżkę z nowej podsieci LAN.
Domena kierująca do niewłaściwej witryny proxy, zapętlająca przekierowania lub wyświetlająca błąd nazwy certyfikatu nie oznacza już prostego problemu z przekierowaniem portów. Podczas sprawdzania DNS, SNI, routingu Host i skonfigurowanego publicznego adresu URL rozdziel działającą ścieżkę opartą na adresie IP od niedziałającej ścieżki opartej na nazwie hosta. Nie generuj ponownie certyfikatów bez zastanowienia, gdy nazwa hosta nadal rozwiązuje się do niewłaściwego publicznego adresu.
W przypadku szerszego drzewa decyzyjnego najpierw oddziel osiągalność lokalną od problemów z publiczną ścieżką dostępu, zanim ponownie zaczniesz wprowadzać poprawki po stronie serwera. Gdy potwierdzisz, że lokalny Immich działa poprawnie, wymiana routera zawęża poszukiwania do stanu adresowania, NAT, DNS, zapory, proxy i TLS.
Przetestuj ponownie z zewnątrz i wybierz najmniej ryzykowną ścieżkę dostępu
Po usunięciu jednej z przyczyn powtórz pierwotny test przez dane komórkowe, używając tej samej nazwy hosta i klienta. Następnie raz uruchom ponownie router i raz zrestartuj hosta Immich. Rozwiązanie jest trwałe tylko wtedy, gdy serwer zachowuje oczekiwany cel w sieci LAN, DNS nadal rozwiązuje nazwę prawidłowo, a dostęp zdalny wraca bez ręcznej interwencji.
Jeśli korzystasz z bezpośredniego udostępniania ruchu przychodzącego, sprawdź, czy publicznie dostępna jest tylko zamierzona ścieżka HTTPS i czy usunięto stare, tymczasowe reguły. W przypadku dostępu wyłącznie dla rodziny VPN typu mesh lub uwierzytelniony tunel może zmniejszyć zależność od przekierowania portów i zmieniających się adresów publicznych, zwłaszcza gdy nowy router lub ścieżka operatora są trudne do kontrolowania.
Przestań rozszerzać zmiany sieciowe, gdy żądania niezawodnie docierają do właściwego punktu końcowego proxy lub Immich, a pierwotny klient znów działa. Jeśli dostęp lokalny pozostaje sprawny, ale żadne zewnętrzne pakiety nigdy nie docierają do routera mimo poprawnej ścieżki publicznej i DNS, skontaktuj się z operatorem lub zmień model dostępu; jest to problem na granicy sieci, a nie powód do ponownego wdrażania Immich.
Wsparcie i wskazówki
Więcej do przeczytania

Jak zoptymalizować połączenia z bazą danych Immich dla równoczesnych kontenerów
Nie zwiększaj najpierw wartości max_connections. Zmierz sesje Immich, zsumuj zapotrzebowanie wszystkich kontenerów, zachowaj rezerwę dla administratora i dostosuj tylko faktycznie potwierdzone wąskie gardło.

Jak zapobiegać duplikowaniu zadań lub importów w Immich
Oddziel powtarzające się zadania od zduplikowanych zasobów. Użyj jednej kanonicznej ścieżki pozyskiwania danych, kontroluj ponowne próby i zmiany ścieżek, a następnie przetestuj ponowne wprowadzanie...

Jak naprawić Immich po zapełnieniu woluminu bazy danych
Nigdy nie usuwaj dziennika WAL PostgreSQL, aby zwolnić miejsce. Zatrzymaj operacje zapisu w Immich, zachowaj stan bazy danych, bezpiecznie zwiększ pojemność, odzyskaj działanie PostgreSQL,...

