NGINX 1.30 ændrede genbrug af upstream-forbindelser: Det skal du kontrollere før opgraderingen

Af Greg Nowak. Opdateret 21. juli 2026.

NGINX 1.30 ændrer en forudsætning, der i årevis ubemærket har ligget i mange reverse proxy-konfigurationer. HTTP-proxying bruger nu HTTP/1.1 og holder som standard upstream-forbindelser åbne i stedet for normalt at oprette en ny forbindelse for hver request.

For en moderne applikation er genbrug af forbindelser som regel en velkommen forbedring: færre connection handshakes og mindre unødvendigt arbejde mellem NGINX og backenden. Men en tilsyneladende rutinemæssig pakkeopdatering kan afdække gamle applikationer, forbindelsesafhængig autentificering eller konfiguration, der er kopieret fra en tidligere NGINX-æra. Derfor er dette et mindre kompatibilitetsprojekt og ikke blot en opgave i package manageren.

Pr. 21. juli 2026 er NGINX 1.30.4 den aktuelle stabile udgivelse. Den indeholder også sikkerhedsrettelser, der blev offentliggjort 15. juli, så teams, der allerede kører en tidligere 1.30.x-version, bør planlægge at gå videre til den patchede version frem for at stoppe ved 1.30.0.

Hvad er ændret i NGINX 1.30?

Ændringen blev først introduceret i mainline-version 1.29.7 og kom med i den stabile gren i 1.30.0. Standardprotokollen til proxying er nu proxy_http_version 1.1. NGINX aktiverer også en upstream keep-alive-cache svarende til keepalive 32 local: op til 32 inaktive forbindelser pr. worker, som holdes lokale for den location, der bruger upstreamen.

Tallet 32 er ikke en grænse for det samlede antal backend-forbindelser. Det styrer kun, hvor mange inaktive forbindelser hver worker må beholde. Aktiv trafik kan stadig oprette flere. Denne forskel er vigtig, når backendens kapacitet skal estimeres, eller en stigning i antallet af åbne sockets skal undersøges.

Gennemgå den konfiguration, NGINX faktisk indlæser

Begynd ikke med den ene konfigurationsfil, som nogen kan huske at have redigeret. Includes, deployment templates og kontrolpaneler hos hostingudbydere betyder ofte, at den effektive konfiguration ser helt anderledes ud. Indstillingen -T kontrollerer konfigurationen og udskriver alle indlæste filer:

sudo nginx -T 2>/dev/null | grep -nE \
'proxy_http_version|proxy_set_header[[:space:]]+Connection|keepalive|ntlm'

sudo nginx -V
sudo nginx -t

Den første kommando finder de directives, der med størst sandsynlighed påvirker denne ændring. nginx -V registrerer den installerede version samt build-indstillinger og moduler; nginx -t bør køres igen umiddelbart før reload.

Vær især opmærksom på proxy_set_header. Disse directives nedarves kun fra parent context, når der ikke er defineret nogen på det aktuelle niveau. Hvis én header tilføjes i en location, kan det derfor forhindre, at hele sættet fra parent context nedarves. Gennemgå hver block samlet i stedet for at slette en enkelt linje isoleret.

Sæt spørgsmålstegn ved gamle keep-alive-snippets

Før 1.29.7 aktiverede administratorer typisk genbrug af upstream-forbindelser med:

proxy_http_version 1.1;
proxy_set_header Connection "";

Disse linjer er ikke længere nødvendige blot for at få almindelig HTTP/1.1 keep-alive-adfærd. De er ikke automatisk skadelige, men overflødig konfiguration skaber tvivl om, hvad der er tilsigtet. Fjern dem som en testet ændring, især hvis det samme include bruges på flere kundesites.

En eksplicit keepalive 32; fortjener et nærmere eftersyn. Med NGINX’ nuværende adfærd anvendes lokale forbindelsescaches, når dette directive udelades. Skrives det uden parameteren local, kan matchende cachede forbindelser genbruges på tværs af locations, der benytter den samme upstream-adresse. Hvis hensigten er isolation, skal det angives eksplicit:

upstream application_backend {
    server 127.0.0.1:8080;
    keepalive 32 local;
}

Justér ikke keepalive_requests, keepalive_time eller keepalive_timeout, blot fordi indstillingerne findes. Ændr dem kun som reaktion på en dokumenteret begrænsning i backenden, målt pres på sockets eller en reproducerbar fejl.

Giv besværlige backends en snæver undtagelse

Ældre applikationer kan bygge på forbindelsesspecifikke antagelser, som almindelig test i browseren ikke afslører. Test login og logout, parallelle requests, filuploads, administrative handlinger, recovery efter timeout samt requests efter en inaktiv periode. Ved NTLM- eller Negotiate-autentificering skal du bekræfte, at upstreamen bruger NGINX’ ntlm-håndtering, og teste med realistiske samtidige sessioner.

Hvis en backend reelt kræver HTTP/1.0 og lukkede forbindelser, skal undtagelsen begrænses til dens location:

location /legacy-app/ {
    proxy_pass http://legacy_backend;
    proxy_http_version 1.0;
    proxy_set_header Connection "Close";
}

På den måde opgives genbrug kun dér, hvor det er nødvendigt. En nedgradering for hele serveren ville skjule kompatibilitetsproblemet og samtidig fjerne fordelen for alle velfungerende applikationer.

Gør udrulningen observerbar og reversibel

Registrér en baseline før opgraderingen: upstream-svartider og forbindelsestider, forekomsten af 502- og 504-fejl, autentificeringsfejl, antal backend-forbindelser og applikationslogs. Udrul derefter som canary på de routes, hvor problemer mest sandsynligt vil vise sig – autentificering, administration og ældre branchespecifikke applikationer – frem for at antage, at den mest besøgte offentlige side er den bedste test.

Sørg for fortsat at have adgang til den tidligere pakke og deployment-processen for konfigurationen, men foretræk en snæver undtagelse i konfigurationen, hvis én backend fejler. Dokumentér, hvorfor undtagelsen findes, og hvem der har ansvaret for at fjerne den. Ellers bliver dagens nødrettelse til morgendagens uforklarlige infrastrukturfolklore.

For virksomhedsejere og bureauteams er det værdifulde resultat ikke blot »NGINX opgraderet«. Det er en oversigt over berørte applikationer, en testet konfiguration, aftalt overvågning og en beslutning om rollback, som nogen rent faktisk kan gennemføre. Hvis jeres systemlandskab blander nedarvede kundekonfigurationer med ældre leverandørsystemer, kan Greg hjælpe med at omsætte gennemgangen til en kontrolleret opgraderingsplan.

Relateret indhold på GrN.dk

• MariaDB 10.6 EOL: Skjult teknisk gæld i CMS-hosting kræver en reel opgraderingsplan før juli 2026
• AI-automatiseringer kræver et dashboard over forbruget før den første løbske regning
• Apache 2.4.68 minder os om, at gamle proxyregler kræver en reel gennemgang

Har du brug for hjælp til denne type opgave?

Drøft din NGINX-opgradering med Greg. Kontakt Greg.

Kilder

• NGINX-nyheder: 2026
• Keep-alive til upstreams er nu standard i NGINX 1.29.7
• Modulet ngx_http_upstream_module
• Modulet ngx_http_proxy_module
• Kommandolinjeparametre til NGINX