Planerat underhåll av proxyn är säkrare när reverse proxyn kan laddas om eller startas om oberoende av autentiserings- och sessionshanteringstjänsterna bakom den.
En proxyprocess behöver vanligtvis inte äga det inloggningstillstånd som den vidarebefordrar. Innan underhållet påbörjas bör du kartlägga vilken komponent som signerar cookies, lagrar serversessioner, avslutar autentiseringen och tömmer aktiva HTTP-anslutningar. Låt dessa tillståndsbevarande komponenter fortsätta köra, föredra en smidig omladdning av proxyn när endast konfigurationen ändras och verifiera att en fullständig ersättning av proxyn återansluter till samma autentiseringsgateway och sessionslager med oförändrade hemligheter.
Separera proxyns livscykel från autentiseringstjänstens livscykel
Kontrollera Compose-beroenden, omstartspolicyer, delade skript och åtgärder i stackhanteraren för att säkerställa att en omstart av proxyn inte automatiskt återskapar autentiseringsgatewayen, applikationen, Redis eller databasen.
Ett exempel på sessionsarkitektur använder Redis utanför proxyns livscykel så att flera autentiseringsinstanser och omstarter kan dela samma sessionsbackend.
Gruppera inte alla edge-tjänster under ett enda otydligt omstartskommando. Om en certifikat- eller ruttändring endast påverkar proxyn bör du låta tjänsterna som validerar befintligt inloggningstillstånd fortsätta köra.
Ladda om konfigurationen i stället för att starta om när det är möjligt
För ändringar av rutter, certifikat eller rubriker bör du använda proxyns stödda smidiga omladdning i stället för att stoppa tjänsten. Validera konfigurationen innan den tillämpas, så att ett syntaxfel inte förvandlar planerat underhåll till driftstopp.
API7:s genomgång av NGINX förklarar hur gamla workers tömmer anslutningarna medan nya workers tar emot förfrågningar enligt den uppdaterade konfigurationen.
En omladdning bevarar proxyprocessfamiljen, men skyddar inte en separat autentiseringstjänst om distributionsskriptet även startar om den tjänsten. Håll dessa två livscykelfrågor åtskilda.
Bevara extern sessionslagring när proxyn ersätts
Om en autentiseringsgateway lagrar sessionsdata utanför cookies bör du låta dess Redis- eller andra sessionsbackend vara beständig och oförändrad under proxyåtgärden. Dokumentera backend-adressen och den hemlighet som används av varje autentiseringsinstans.
OAuth2 Proxy stöder Redis som delad sessionslagring när sessioner måste delas mellan instanser.
Blanda inte ihop en temporär cache med auktoritativt inloggningstillstånd. Om sessionsbackend krävs för att validera aktuella användare bör du endast starta om eller tömma den enligt en separat, testad underhållsprocedur.
Håll cookie- och signeringshemligheter stabila
Dokumentera den krypterings- eller signeringshemlighet för cookies som autentiseringsgatewayen använder och säkerställ att den ersättande proxystacken monterar samma hemlighetskälla. Om ett nytt värde genereras vid en ny distribution blir annars fungerande webbläsarcookies ogiltiga.
En guide om reverse-proxy-sessioner påpekar att stabila sessionsregler överlever omstarter i stället för att vara bundna till livslängden hos en enda TCP-anslutning.
Rotera signeringshemligheter som en separat säkerhetsändring med ett uttryckligt krav på utloggning eller en strategi med överlappning. Kombinera inte rotation av hemligheter med en vanlig planerad omladdning av proxyn om det inte är avsiktligt att sessionerna ska ogiltigförklaras.
Töm anslutningar under en fullständig omstart av proxyn
När proxybinären eller containern måste ersättas bör du använda dess mekanism för smidig eller avbrottsfri omstart när en sådan finns, så att etablerade förfrågningar inte avbryts mitt i ett svar. Ha en tidsgräns för underhåll för långlivade anslutningar.
HAProxy:s vägledning för omladdning visar hur avbrottsfria omladdningar bevarar anslutningar i stället för att omedelbart avsluta den gamla processen.
Anslutningskontinuitet och inloggningskontinuitet är olika saker. Även om en WebSocket återansluter bör sessionen förbli giltig eftersom den ersättande proxyn når samma autentiserings- och tillståndstjänster.
Testa en session före och efter planerat underhåll
Använd en inloggad webbläsare och en ny privat session. Dokumentera sessionscookien, proxyrutten, autentiseringstjänsten och backend före underhållet. Ladda sedan om eller ersätt endast proxyn och upprepa samma skyddade förfrågan.
En driftguide för Caddy rekommenderar omladdning i stället för fullständig omstart vid planerade konfigurationsuppdateringar.
Underhållsdesignen fungerar när befintliga inloggningar överlever, nya inloggningar fortfarande lyckas och ingen tillståndsbevarande beroendetjänst startades om oavsiktligt. Den relaterade ZimaSpace-artikeln om sessionsförlust efter omstart av proxyn är fortfarande rätt återställningsväg om användarna fortfarande är utloggade.
Vanliga frågor
Garanterar en smidig omladdning av proxyn att användarna förblir inloggade?
Nej. Den skyddar proxyanslutningarna, men användare kan fortfarande loggas ut om autentiseringstjänsten, sessionslagringen eller signeringshemligheten för cookies ändras samtidigt.
Bör Redis alltid fortsätta köras efter en omstart av proxyn?
Endast när Redis lagrar sessionstillstånd eller en annan beständig beroendetjänst för autentiseringen. En Redis-instans som endast används som cache har en annan återställningsgräns.
Räcker det att behålla samma cookienamn?
Nej. Signerings- eller krypteringshemligheten och sessionsbackend måste också förbli kompatibla med cookien som webbläsaren redan har.
Support och tips
Mer att läsa

Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.

Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.

Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.

