• Nginx 1.31 släpps med forward proxy-stöd och flera säkerhetsfixar

    Nginx är en av internets viktigaste byggstenar. Den används för att leverera webbsidor, fördela trafik mellan servrar och fungera som mellanhand mellan användare och webbapplikationer. Med Nginx 1.31 tar projektet ett nytt steg: webbservern får stöd för HTTP forward proxy, samtidigt som flera säkerhetshål i moderna webbprotokoll som HTTP/2 och HTTP/3 täpps till.

    För de flesta internetanvändare är Nginx osynligt. Ändå är det ofta just Nginx som står mellan webbläsaren och den webbplats man besöker. Programmet fungerar som en effektiv trafikdirigent: det tar emot förfrågningar, skickar dem vidare till rätt server och ser till att svaren kommer tillbaka snabbt.

    Nginx har länge varit känt som webbserver och reverse proxy. En reverse proxy står framför en eller flera servrar och tar emot trafik från internet. Den kan till exempel skicka besökare vidare till rätt webbserver, avlasta systemet eller hantera krypterade HTTPS-anslutningar.

    Med Nginx 1.31 introduceras en funktion som gör att programmet även kan användas på ett annat sätt: som HTTP forward proxy.

    Vad är en forward proxy?

    En forward proxy fungerar från andra hållet jämfört med en reverse proxy. I stället för att skydda och styra trafiken in till en webbplats används den av klienter som vill nå ut till internet.

    Man kan likna det vid en reception. I stället för att varje dator kontaktar webben direkt skickar den sin begäran till proxyn. Proxyn gör sedan själva kontakten med omvärlden och skickar tillbaka svaret.

    Detta kan användas för att:

    samla internettrafik via en central punkt
    kräva inloggning innan trafik släpps vidare
    logga eller styra åtkomst
    skapa kontrollerade miljöer för företag, skolor eller labb

    Den nya modulen ngx_http_tunnel_module gör det möjligt för Nginx att hantera sådan trafik via CONNECT-metoden. CONNECT används ofta när HTTPS-trafik ska tunnlas genom en proxy.

    Det betyder att Nginx nu får en mer flexibel roll. Från att främst ha varit en servernära komponent kan den även användas som kontrollerad mellanhand för klienttrafik.

    Inloggning till proxyn

    En viktig del av den nya funktionen är stöd för proxyautentisering. Det innebär att användaren kan behöva logga in innan proxyn tillåter trafik.

    I Nginx 1.31 kan detta göras med direktiv som:

    auth_basic
    satisfy
    auth_delay

    För en administratör betyder det att forward proxy-funktionen inte behöver vara helt öppen. Det är viktigt, eftersom en öppen proxy snabbt kan missbrukas för anonym trafik, spam, attacker eller kringgående av nätverksregler.

    Med autentisering kan proxyn i stället användas i mer kontrollerade miljöer där bara godkända användare får tillgång.

    Smartare lastbalansering med least_time

    En annan nyhet i Nginx 1.31 är direktivet least_time i upstream-blocket. Det låter Nginx välja backend-server baserat på svarstid.

    Traditionell lastbalansering kan exempelvis bygga på att skicka varannan förfrågan till server A och varannan till server B. Det fungerar i enkla miljöer, men tar inte alltid hänsyn till hur servrarna faktiskt mår.

    Om en server är långsam, hårt belastad eller har problem kan svarstiden bli högre. Med least_time kan Nginx i stället väga in hur snabbt servrarna svarar och styra trafiken mot den som för tillfället verkar mest effektiv.

    Det är lite som att välja kö i mataffären. Man går inte nödvändigtvis till den kö som ser kortast ut, utan till den som faktiskt rör sig snabbast.

    Funktionen kan användas både för vanlig HTTP-trafik och för stream-trafik.

    ALPN för säkra upstream-anslutningar

    För stream-modulerna introduceras även direktivet proxy_ssl_alpn.

    ALPN står för Application-Layer Protocol Negotiation. Det är en teknik som används under TLS-anslutningar för att komma överens om vilket protokoll som ska användas.

    Det kan exempelvis vara relevant när en server kan tala flera olika protokoll över samma krypterade anslutning. Med proxy_ssl_alpn får administratören bättre kontroll över vilket protokoll Nginx ska välja när den ansluter till SSL-baserade upstream-servrar.

    Säkerhetsfixar i flera moduler

    Nginx 1.31 är inte bara en funktionsrelease. Den innehåller också flera säkerhetsfixar.

    En av de åtgärdade bristerna är CVE-2026-42926, en sårbarhet i HTTP/2-hanteringen i ngx_http_proxy_module. Problemet är kopplat till direktivet proxy_set_body och kan beskrivas som en request injection-sårbarhet.

    En sådan sårbarhet innebär att en angripare i vissa situationer kan påverka hur en förfrågan tolkas eller vidarebefordras. I proxyprogramvara är detta särskilt känsligt, eftersom proxyn står mitt i trafikflödet.

    En annan viktig fix gäller CVE-2026-42945, en heap buffer overflow i ngx_http_rewrite_module. Minnesfel av detta slag kan i värsta fall leda till att angripare får möjlighet att köra kod.

    Även följande sårbarheter har åtgärdats:

    CVE-2026-42946 – heap buffer overread i ngx_http_scgi_module och ngx_http_uwsgi_module
    CVE-2026-42934 – buffer overread kopplad till UTF-8-avkodning i charset_map i ngx_http_charset_module
    CVE-2026-40460 – adressförfalskning i HTTP/3 och QUIC connection migration
    CVE-2026-40701 – use-after-free vid DNS-svarshantering när ssl_ocsp används

    Det tekniska språket kan låta avskräckande, men i praktiken handlar det om samma grundproblem som ofta förekommer i systemprogramvara: data måste tolkas exakt rätt, minne måste hanteras korrekt och nätverkstrafik får inte kunna lura servern att göra något oväntat.

    HTTP/2 och HTTP/3 blir striktare

    HTTP/2 och HTTP/3 är modernare versioner av webbens grundprotokoll. De är byggda för högre prestanda och bättre hantering av många samtidiga anslutningar.

    Men när gamla och nya protokoll möts uppstår ibland risker. Vissa headers som används i HTTP/1.1 hör inte hemma i HTTP/2 och HTTP/3. Om de ändå släpps igenom kan det skapa oväntade beteenden i kedjan mellan klient, proxy och backend-server.

    Därför avvisar Nginx 1.31 nu HTTP/2- och HTTP/3-förfrågningar som innehåller anslutningsspecifika headers som:

    Connection
    Proxy-Connection
    Keep-Alive
    Transfer-Encoding
    Upgrade

    Headern TE tillåts bara när den är satt till trailers.

    Detta gör hanteringen mer strikt och minskar risken för felaktig tolkning av trafik.

    WebDAV får hårdare kontroller

    Även WebDAV-modulen har förstärkts. WebDAV gör det möjligt att hantera filer på en server via HTTP, till exempel kopiera, flytta eller ändra resurser.

    I Nginx 1.31 avvisas nu COPY– och MOVE-förfrågningar om källan och destinationen är samma plats, eller om de har ett förälder–barn-förhållande.

    Det kan låta som en liten detalj, men den typen av kontroller är viktiga. Utan dem kan filoperationer skapa logiska konflikter, oändliga kopieringsproblem eller andra oönskade effekter.

    Mindre brus i loggarna

    Versionen innehåller också mindre förändringar som påverkar drift och felsökning. Bland annat har loggnivån sänkts för vissa SSL-relaterade fel.

    För systemadministratörer kan detta vara välkommet. Alla fel är inte lika allvarliga, och för höga loggnivåer kan göra det svårare att hitta verkligt viktiga problem i stora loggfiler.

    Det finns även ett nytt configure-alternativ för att kunna inaktivera upstream sticky-modulen, samt fixar för HTTP/2 backend keepalive när proxy_set_body eller proxy_pass_request_body används.

    Varför är Nginx 1.31 viktig?

    Nginx 1.31 är intressant därför att den både breddar vad Nginx kan göra och stärker säkerheten i befintliga funktioner.

    Forward proxy-stödet gör att Nginx kan användas i fler nätverksroller än tidigare. Samtidigt visar säkerhetsfixarna hur komplex modern webbtrafik har blivit. HTTP/2, HTTP/3, TLS, OCSP, QUIC, WebDAV och olika proxyfunktioner skapar tillsammans ett kraftfullt men avancerat ekosystem.

    Ju fler lager som finns i trafikkedjan, desto viktigare blir det att varje del tolkar data på rätt sätt.

    Sammanfattning

    Nginx 1.31 är en viktig mainline-version för administratörer och tekniskt intresserade. Den stora nyheten är stödet för HTTP forward proxy via ngx_http_tunnel_module, men minst lika viktigt är de många säkerhetsfixarna i HTTP/2, HTTP/3, OCSP och flera centrala moduler.

    För den som driver Nginx i produktion är detta en version att granska noggrant. Särskilt gäller det installationer som använder avancerad proxyhantering, HTTP/2, HTTP/3, WebDAV, SCGI, uWSGI eller OCSP.

    Nginx fortsätter därmed att utvecklas från en snabb webbserver till ett allt mer mångsidigt verktyg för modern internettrafik.

    https://github.com/nginx/nginx/releases/tag/release-1.31.0

    Teknisk faktaruta: Nginx 1.31

    Version: Nginx 1.31

    Utgåva: Mainline-release

    Största nyheten: HTTP forward proxy-stöd via ngx_http_tunnel_module och CONNECT-metoden.

    Proxyautentisering: Stöd via auth_basic, satisfy och auth_delay.

    Lastbalansering: Nytt least_time-direktiv för att balansera trafik baserat på svarstid.

    Stream-moduler: Nytt proxy_ssl_alpn-direktiv för ALPN-val mot SSL-upstreams.

    Säkerhetsfixar: Åtgärdar sårbarheter i HTTP/2, HTTP/3, OCSP, WebDAV, rewrite-, proxy-, charset-, SCGI- och uWSGI-moduler.

    Berörda CVE:er: CVE-2026-42926, CVE-2026-42945, CVE-2026-42946, CVE-2026-42934, CVE-2026-40460 och CVE-2026-40701.

    Rekommendation: Administratörer som använder Nginx med HTTP/2, HTTP/3, OCSP, WebDAV eller avancerade proxyfunktioner bör granska uppdateringen noggrant.

  • NGINX 1.30 – snabbare, säkrare och smartare webb

    Den nya versionen av NGINX markerar ett viktigt steg för hur framtidens webb ska fungera. Med fokus på hastighet, säkerhet och modern teknik introducerar version 1.30 flera förbättringar som påverkar allt från hur snabbt webbsidor laddas till hur väl användarnas integritet skyddas.

    Den nya stabila versionen av NGINX, version 1.30, har släppts och för med sig en rad förbättringar som gör webben både snabbare och säkrare. NGINX är idag en av världens mest använda webbservrar och driver över 30 procent av alla webbplatser, vilket gör varje uppdatering betydelsefull för en stor del av internet.

    Snabbare webb med Early Hints

    En av de mest spännande nyheterna är stöd för HTTP Early Hints, även kallat statuskod 103. Det innebär att servern kan börja skicka information till webbläsaren innan hela sidan är färdigbehandlad.

    I praktiken betyder det att webbläsaren kan börja ladda viktiga resurser, som stilmallar och skript, tidigare än förut. Resultatet blir kortare laddningstider och en snabbare upplevelse för användaren.

    Starkare integritet med Encrypted ClientHello

    En annan viktig nyhet är stöd för Encrypted ClientHello (ECH). Trots att HTTPS redan krypterar mycket av trafiken har vissa delar tidigare varit synliga, till exempel vilken webbplats användaren försöker nå.

    Med ECH krypteras även denna information, vilket gör det svårare för utomstående att övervaka surfvanor. Det är ett viktigt steg mot en mer privat och säker internetanvändning.

    Smartare trafikhantering

    NGINX 1.30 introducerar också förbättrad hantering av trafik mellan servrar. En ny funktion är så kallade sticky sessions, som ser till att en användare konsekvent kopplas till samma server i ett kluster.

    Detta är särskilt viktigt för tjänster där sessioner spelar roll, som inloggningar eller e-handel. Dessutom har stödet för HTTP/2 utökats till kommunikationen mellan servrar, vilket gör interna system snabbare och mer effektiva.

    Förbättringar i HTTP/2 och HTTP/3

    Den nya versionen innehåller flera förbättringar för både HTTP/2 och HTTP/3. Dessa inkluderar bättre stabilitet, färre buggar och effektivare hantering av dataöverföring.

    Även tekniska problem som tidigare kunnat orsaka krascher eller ineffektiv kommunikation har åtgärdats, vilket bidrar till en mer robust webbupplevelse.

    Starkare kryptering och TLS-stöd

    NGINX 1.30 förbättrar också stödet för modern kryptering. Bland nyheterna finns certifikatkomprimering, vilket kan snabba upp säkra anslutningar, samt bättre kompatibilitet med framtida versioner av krypteringsbibliotek som OpenSSL.

    Dessutom introduceras nya variabler och förbättrad hantering av hur servrar identifieras vid säkra anslutningar.

    Små förbättringar med stor effekt

    Utöver de större funktionerna innehåller uppdateringen många mindre förbättringar. Till exempel är keep-alive nu aktiverat som standard, vilket förbättrar prestandan genom att återanvända anslutningar.

    Flera buggar har också rättats, bland annat inom gRPC, cachehantering och proxyfunktioner, vilket gör systemet mer stabilt i praktisk användning.

    Varför det spelar roll

    Eftersom NGINX används av en så stor del av internet får dessa förbättringar bred påverkan. För användare innebär det snabbare laddningstider, bättre säkerhet och en mer stabil upplevelse.

    För utvecklare och företag innebär det effektivare verktyg, modernare teknikstöd och färre tekniska problem att hantera.

    Sammanfattning

    NGINX 1.30 markerar ett tydligt steg framåt för webbteknik. Med förbättrad prestanda, starkare integritetsskydd och modernare protokollstöd bidrar uppdateringen till ett snabbare, säkrare och mer tillförlitligt internet.

    Teknisk fakta: NGINX 1.30

    Vad är NGINX?
    NGINX är en webbserver och reverse proxy som används för att leverera webbsidor, hantera trafik och agera mellanhand mellan användare och backend-servrar. Den är känd för sin höga prestanda, låga resursanvändning och förmåga att hantera många samtidiga anslutningar. NGINX används ofta även som lastbalanserare och cache för att snabba upp webbapplikationer.


    Version: 1.30

    Gren: Ny stabil branch

    Huvudfunktioner:
    HTTP Early Hints (snabbare laddning), Encrypted ClientHello (förbättrad integritet), sticky sessions (stabil sessionshantering), HTTP/2 till backend-servrar

    Transport: Multipath TCP

    Standard upstream: HTTP/1.1 med keep-alive aktiverat

    TLS/SSL:
    Certifikatkomprimering, stöd för OSSL_STORE, förbättrad SNI-hantering, nya variabler för signaturalgoritmer och kompatibilitet med framtida OpenSSL-versioner

    HTTP/2 & HTTP/3:
    Förbättrad stabilitet, buggfixar, bättre hantering av headers och anslutningar, samt förbättrad QUIC-integration

    Övrigt:
    Upstream keepalive aktiverat som standard, förbättrad cachehantering, fixar för gRPC och proxyfunktioner

  • En ringklocka utan sladdar – när webben ringer på dörren

    En QR-kod på dörren, en webbsida som “ringer”, och en konsol inomhus som plingar till via en egen ntfy-server – kan det verkligen fungera som ringklocka? I praktiken visade det sig vara oväntat stabilt och snabbt, även om det knappast ersätter en klassisk installation permanent. Här publicerar vi den testade koden och visar vilka få inställningar du behöver ändra för att komma igång.

    Tänk dig en ringklocka som inte sitter i väggen, inte kräver någon särskild hårdvara och inte ens behöver vara i samma byggnad som du själv. I stället består den av en QR-kod, en webbsida och en notifieringstjänst. Det låter som ett experiment – och det är det också – men ett förvånansvärt fungerande sådant.

    I en tidigare artikel beskrev vi hur man kan bygga en mjukvarubaserad ringklocka med hjälp av QR-kod, egen domän och en självhostad ntfy-server. Nu har lösningen testats i praktiken, och dessutom publiceras den kod som faktiskt användes. Den skiljer sig något från den som visades i det första inlägget.

    Resultatet? Inte något man installerar som permanent ersättning för en vanlig ringklocka, men absolut ett intressant och lärorikt bygge.

    Två delar som tillsammans bildar ett “pling”

    Systemet är uppdelat i två tydliga delar som samverkar via webben.

    Den första delen är webbsidan som QR-koden pekar på. QR-koden sitter exempelvis på dörren eller porten. När någon skannar den öppnas en enkel webbsida där besökaren kan ”ringa på”. Ett klick räcker för att ett meddelande ska skickas vidare.

    Den andra delen är konsolen på insidan. Det kan vara en dator, surfplatta eller mobil som har en webbsida öppen i webbläsaren. Den sidan lyssnar på notifieringar från ntfy-servern. När någon ringer på hörs ett ljud och ett meddelande visas direkt på skärmen.

    All kommunikation sker i realtid, helt via webbläsaren.

    Hur fungerade det i praktiken?

    Överraskande bra.

    Notiserna dök upp snabbt, ljudsignalen fungerade stabilt och hela lösningen kändes oväntat robust så länge nätverket var tillförlitligt. Samtidigt märks det tydligt att detta inte är tänkt som en långsiktig hushållsprodukt. Det är mer ett tekniskt experiment än en färdig konsumentlösning.

    Men som koncept och demonstration är det mycket lyckat.

    Den testade koden och nödvändiga ändringar

    När du laddar ner och packar upp arkivet med koden hittar du två mappar, en för webbsidan bakom QR-koden och en för konsolen.

    I filen index.html för webbdelen behöver du ändra adressen till din egen ntfy-server:

    const NTFY_URL = ”https://ntfy.exempel.se/ringklocka-Ringer”;

    Sätt adressen till den domän där din ntfy-server faktiskt finns.

    I konsolens index.html gör du motsvarande ändring:

    const NTFY_BASE = ”https://ntfy.exempel.se”;

    Även här ska adressen peka på din egen ntfy-domän.

    Vad krävs för att lösningen ska fungera?

    För att systemet ska fungera pålitligt behöver du några grundläggande förutsättningar. Du bör ha en egen domän, både för stabilitet och för att kunna använda HTTPS. Du behöver också tillgång till en ntfy-server, helst självhostad. Slutligen krävs en enhet som är igång och har konsolsidan öppen i webbläsaren.

    I övrigt behövs inga appar, inga användarkonton och ingen specialutrustning.

    Installera ntfy

    För att installera en ntfy-server på Ubuntu är det en fördel att ta det steg för steg. Börja med att se till att systemet är uppdaterat och att du har grundläggande verktyg som curl och gpg installerade. Därefter lägger du till ntfy-projektets officiella paketkälla. Det görs genom att hämta GPG-nyckeln och registrera arkivet i systemets APT-konfiguration. När paketkällan är på plats uppdaterar du paketlistan och installerar ntfy med systemets vanliga pakethanterare.

    När programmet är installerat skapar du en konfigurationsfil, vanligtvis /etc/ntfy/server.yml. Där anger du grundläggande inställningar, till exempel vilken extern adress servern ska använda, som https://ntfy.dindomän.se, samt vilken lokal port tjänsten ska lyssna på. Konfigurationsfilen behöver inte vara avancerad till att börja med, utan kan hållas mycket enkel.

    Nästa steg är att köra ntfy som en systemtjänst. Genom att aktivera tjänsten med systemd ser du till att den startar automatiskt vid omstart av servern. När tjänsten väl är igång kan du kontrollera att den fungerar genom att skicka ett testmeddelande till ett valfritt ämne.

    För praktisk och säker användning placeras ntfy normalt bakom en webbserver som Apache. Webbservern fungerar då som en omvänd proxy och vidarebefordrar HTTPS-trafik till ntfy-tjänsten som kör lokalt. Slutligen säkrar du uppkopplingen med ett TLS-certifikat, till exempel via Let’s Encrypt och Certbot.

    När dessa delar är på plats har du en stabil och självhostad ntfy-server som kan användas för allt från notifieringar till den mjukvarubaserade ringklockan till andra typer av realtidsmeddelanden.

    Varför är detta intressant?

    För att det visar hur långt man kan komma med enkla webbtekniker och öppna standarder. Med bara HTML, JavaScript och en notifieringstjänst går det att koppla samman den fysiska världen med webben på ett mycket direkt sätt.

    Samma idé kan användas för andra ändamål, till exempel enkla larmsystem, interna notifieringar, hjälpknappar eller tillfälliga installationer på mässor och evenemang.

    Det är kanske inte framtidens ringklocka, men det är ett tydligt exempel på hur kreativ mjukvara kan ersätta hårdvara – åtminstone ibland.

    Texten ovan bör ses som en övergripande beskrivning. Ett tips är att ta hjälp av en lämplig AI för att få allt att fungera.

    Länk för att ladda hem koden

    https://www.linux.se/kod/ringkloocka.tar

    Fakta: Mjukvaruringklocka med QR-kod och ntfy
    En experimentell ringklocka som använder en QR-kod på dörren och en webbsida som skickar en notifiering till en konsol via en egen ntfy-server.
    Består av:
    • Webbsida som QR-koden pekar på (”ring på”-knapp)
    • Konsolvy i webbläsaren som spelar ljud och visar meddelanden
    • ntfy-server som förmedlar notifieringar i realtid
    Du behöver:
    • Egen domän och HTTPS
    • En ntfy-server (helst självhostad på Ubuntu)
    • En enhet som är igång och har konsolsidan öppen
    Filer att ändra i koden:
    index.html: NTFY_URL
    consol/index.html: NTFY_BASE
    Tips: Se texten i artikeln som en övergripande beskrivning. Ta gärna hjälp av en lämplig AI för att få detaljerna rätt i din egen miljö.

Etikett: webbteknik

  • Nginx 1.31 släpps med forward proxy-stöd och flera säkerhetsfixar

    Nginx är en av internets viktigaste byggstenar. Den används för att leverera webbsidor, fördela trafik mellan servrar och fungera som mellanhand mellan användare och webbapplikationer. Med Nginx 1.31 tar projektet ett nytt steg: webbservern får stöd för HTTP forward proxy, samtidigt som flera säkerhetshål i moderna webbprotokoll som HTTP/2 och HTTP/3 täpps till. För de…

  • NGINX 1.30 – snabbare, säkrare och smartare webb

    Den nya versionen av NGINX markerar ett viktigt steg för hur framtidens webb ska fungera. Med fokus på hastighet, säkerhet och modern teknik introducerar version 1.30 flera förbättringar som påverkar allt från hur snabbt webbsidor laddas till hur väl användarnas integritet skyddas. Den nya stabila versionen av NGINX, version 1.30, har släppts och för med…

  • En ringklocka utan sladdar – när webben ringer på dörren

    En QR-kod på dörren, en webbsida som “ringer”, och en konsol inomhus som plingar till via en egen ntfy-server – kan det verkligen fungera som ringklocka? I praktiken visade det sig vara oväntat stabilt och snabbt, även om det knappast ersätter en klassisk installation permanent. Här publicerar vi den testade koden och visar vilka få…