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

Af Greg Nowak. Opdateret 18. oktober 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. 18. oktober 2026 er NGINX 1.30.6 (udgivet 14. oktober) den aktuelle stabile udgivelse, og 1.31.7 er mainline. 1.30.3 til 1.30.6 indeholder alle sikkerhedsrettelser, så teams, der kører en tidligere 1.30.x-version, bør gå til den nyeste frem for at blive på den version, distributionen først leverede.

proxy_http_version: det korte svar

proxy_http_version bestemmer, hvilken HTTP-version NGINX taler til en proxied backend. Til og med 1.29.6 var standarden 1.0, som lukker backend-forbindelsen efter hver request. Fra mainline 1.29.7 og i alle stabile 1.30.x-udgivelser er standarden 1.1, NGINX sender ikke længere en Connection-header til backenden som standard, og upstream keepalive-cachen er slået til. Du behøver kun selv at skrive proxy_http_version 1.1; på en ældre version, eller proxy_http_version 1.0; for at tvinge den gamle adfærd igennem på én route.

Ældre guides tilføjer proxy_set_header Connection ""; for at rydde headeren. På 1.30 er det allerede standard. Connection "keep-alive" er heller ikke nødvendig: en HTTP/1.1-forbindelse forbliver åben, medmindre en af siderne sender close.

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.

502 Bad Gateway eller 504 fra nginx/1.30.x lige efter opgraderingen?

Versionen på fejlsiden, for eksempel nginx/1.30.2 eller nginx/1.30.4, fortæller kun, hvilken NGINX der har lavet siden. Den betyder ikke, at udgivelsen er fejlbehæftet. 502 betyder, at NGINX ikke fik et gyldigt svar fra backenden, og 504, at backenden ikke svarede i tide. Er fejlen ny efter skiftet til 1.30, er genbrug af forbindelser den første mistænkte.

Det typiske mønster: backenden lukker en inaktiv forbindelse efter få sekunder, NGINX har stadig forbindelsen i sin keepalive-cache og sender næste request ad den vej, og requesten fejler. Fejlloggen viser så upstream prematurely closed connection while reading response header from upstream. Søg efter den linje i /var/log/nginx/error.log, og sammenlign backendens idle-timeout med NGINX' upstream-keepalive_timeout, som er 60 sekunder som standard.

upstream application_backend {
    server 127.0.0.1:8080;
    keepalive 32 local;
    keepalive_timeout 5s;   # kortere end backendens egen idle-timeout
}

Hold NGINX' timeout kortere end backendens, så det er NGINX, der lukker inaktive forbindelser. Understøtter backenden slet ikke keep-alive, så brug undtagelsen pr. route ovenfor i stedet. En ny 504 med samme loglinje har samme årsag; står der upstream timed out i loggen, er backenden langsom, og opgraderingen er et sammenfald.

Hurtige svar

Udgivelsesdatoer for NGINX 1.30

Ifølge changeloggen på nginx.org: 1.30.0 den 14. april 2026, 1.30.1 den 13. maj, 1.30.2 den 22. maj, 1.30.3 den 17. juni, 1.30.4 den 15. juli, 1.30.5 den 15. september og 1.30.6 den 14. oktober 2026. 1.30.3 til 1.30.6 indeholder alle sikkerhedsrettelser, så kør den nyeste 1.30.x frem for den, distributionen først leverede.

NGINX 1.30 eller 1.31?

1.30 er den stabile gren og får kun fejl- og sikkerhedsrettelser. 1.31 er mainline, hvor nye funktioner lander først; 1.31.7 er aktuel pr. oktober 2026 og udkom samme dag som 1.30.6. Ændringen af upstream keepalive findes i begge, da den kom i 1.29.7, før grenene blev delt. Til produktion er stabil det normale valg.

Hvad betyder nginx/1.30.2 på en fejlside?

Serveren bag siden kører NGINX 1.30.2. Er det ikke din server, er der intet at opgradere hos dig; fejlen ligger mellem sitet og dets backend. Er det din, er 1.30.2 fire udgivelser bag 1.30.6 og mangler flere sikkerhedsrettelser.

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