Bör Immich använda värdnätverk eller ett bryggat nätverk?
För de flesta Docker-baserade Immich-distributioner är ett användardefinierat bryggnätverk det renare standardvalet; värdnätverk är en riktad lösning, inte en generell prestandauppgradering.
Immich behöver främst tillförlitliga anslutningar mellan klient och server, server och databas, server och Redis, maskininlärning samt omvänd proxy. Båda nätverkslägena kan tillhandahålla dem. Valet bör göras genom att återskapa det verkliga felet eller åtkomstkravet, testa ett läge i taget och behålla den konfiguration som är enklast att övervaka och återställa.
Börja med de anslutningar som Immich faktiskt behöver
Rita upp stacken som anslutningar i stället för containrar: klienter når Immichs offentliga eller lokala slutpunkt; proxyn når Immich-servern; applikationen når PostgreSQL och Redis; och servern når maskininlärningen. Notera vilka anslutningar som stannar inom Docker och vilka som passerar värdgränsen.
Ett användardefinierat bryggnätverk ger containrarna ett eget nätverksnamnområde och låter samtidigt tjänster i samma nätverk hitta varandra via tjänstenamn. Översikten över Docker-nätverkslägen är användbar för denna skillnad: publicerade portar betjänar värd- eller externa klienter, medan container-DNS hanterar trafik mellan tjänster.
Om alla nödvändiga anslutningar redan fungerar via en brygga har värdnätverk inte löst något påvisat problem. Behåll bryggan och dokumentera tjänstenamn, nätverk och publicerade portar så att senare ändringar av proxy eller Compose kan kontrolleras mot en känd topologi.
Föredra ett användardefinierat bryggnätverk när isolering och stabila tjänstenamn är viktiga
Bryggläget låter Immichs tjänster kommunicera via ett uttryckligt applikationsnätverk utan att exponera varje containerport på värden. Detta är särskilt användbart när en omvänd proxy delar nätverket och kan ansluta direkt till Immich-tjänstens namn, vilket minskar beroendet av en container-IP-adress som kan ändras efter att containern återskapats.
Analysen av avvägningarna med värdnätverk i hemmalabb noterar att borttagning av Dockers NAT sällan ger någon meningsfull prestandavinst för vanlig web trafik i hemmalabb. De viktigare skillnaderna gäller isolering av namnområden, publicering av portar och hur tjänster hittar varandra.
Bryggläget är bara en bristande design när en nödvändig anslutning inte kan uttryckas eller förblir opålitlig efter att nätverk, DNS, brandvägg och proxyns nätverksmedlemskap har korrigerats. Byt inte läge bara för att en klient rapporterar ”servern kan inte nås”; bevisa först att begäran faktiskt stoppas vid Docker-gränsen.
Använd värdnätverk endast för ett specifikt, reproducerbart krav
Värdläget placerar containern i värdens nätverksnamnområde, vilket tar bort Dockers portöversättning och ger tjänsten värdens nätverkskontext. Det kan förenkla vissa upptäckts- eller ovanliga routningsfall, men tar samtidigt bort containerlagrets portgräns och ökar risken för krockar mellan värdportar.
En aktuell jämförelse mellan brygg- och värdnätverk sätter valet i relation till prestanda, isolering, tjänsteexponering och felsökning. Tillämpa dessa dimensioner på Immichs anslutningar i stället för att anta att värdläget i sig är mer tillförlitligt.
Om värdläget löser ett symtom ska du återskapa testet två gånger och förklara varför. Bekräfta till exempel att samma värdnamn, konto, proxy och klient misslyckas med bryggan men fungerar med värdläget, samtidigt som applikationsloggarna i övrigt är felfria. Om resultatet inte kan upprepas kan lägesändringen bara ha dolt ett DNS-problem eller ett inaktuellt nätverkstillstånd.
Behåll den omvända proxyn på en uttrycklig och återställningsbar rutt
En omvänd proxy bör nå Immich via en stabil uppströmsdefinition även efter omstarter av containrar. I ett bryggnätverk bör du föredra ett gemensamt användardefinierat nätverk och en uppströmsanslutning via tjänstenamn framför en manuellt kopierad container-IP. I värdläge ska proxyn riktas mot den avsedda värdadressen och porten, samtidigt som du kontrollerar om portar krockar.
ZimaSpaces testmönster för värd kontra brygga använder en motsvarande villkorsregel: enkel upptäckt kan motivera värdläge, medan isolering och uttrycklig proxyintegrering talar för en brygga. Immich använder andra protokoll, så återanvänd beslutsmetoden i stället för Plex-specifika antaganden om portar.
Starta om proxyn ensam, därefter Immich ensamt och sedan hela stacken. En fungerande design återställer samma lokala och fjärranslutna rutter varje gång utan att IP-adresser behöver redigeras. En topologi som kräver manuell omkoppling efter att containrar återskapats är inte tillräckligt stabil, oavsett om den använder värd- eller bryggnätverk.
Välj det läge som klarar samma acceptanstest med minst risk
Testa lokal webbinloggning, anslutning från mobilappen, en liten uppladdning, en stor uppladdning, åtkomst via omvänd proxy, hälsokontroll mellan tjänster och en fullständig omstart. Dokumentera svarstider och fel, men lägg inte för stor vikt vid små skillnader i genomströmning om båda lägena ändå ligger långt under nätverkets kapacitet.
Välj bryggan när alla funktioner fungerar och du har nytta av uttrycklig exponering, container-DNS och isolering. Välj värdläget när en nödvändig anslutning reproducerbart misslyckas med en korrekt konfigurerad brygga och värdläget löser problemet utan att skapa portkrockar eller utöka exponeringen mer än du accepterar.
Om båda lägena misslyckas på samma sätt ska du sluta växla mellan nätverkslägen. Orsaken finns troligare i DNS, TLS, proxyhuvuden, autentisering, brandvägg, lagring eller själva applikationen. Bevara den misslyckade begäran och loggarna, återgå till den enklare kända fungerande topologin och felsök nästa gräns.
Rekommenderade produkter
Support och tips
Mer att läsa
Så optimerar du Immich-databasanslutningar för samtidiga containrar
Höj inte max_connections först. Mät Immich-sessionerna, summera alla containers behov, behåll utrymme för administratörsåtkomst och justera bara den flaskhals som har bevisats.
Så förhindrar du duplicerade jobb eller importer i Immich
Separera upprepade jobb från duplicerade resurser. Använd en enda kanonisk inläsningsväg, kontrollera omförsök och sökvägsändringar och testa sedan återinmatning på en liten grupp.
Så reparerar du Immich när dess databasvolym blir full
Ta aldrig bort PostgreSQL-WAL för att frigöra utrymme. Stoppa skrivningar till Immich, bevara databastillståndet, lägg till säker lagringskapacitet, återställ PostgreSQL och förhindra sedan att...
