Nginx Reverse Proxy met SSL

Als u een webtoepassing op een privépoort uitvoert (zoals Localhost: 3000), het is niet direct toegankelijk via internet.Een van de meest effectieve manieren om die app veilig bloot te leggen, is om er een omgekeerde proxy voor te plaatsen.

Nginx is een lichtgewicht bekende tool die precies dat kan doen-ontvang inkomend verkeer en stuur het door naar uw app-terwijl hij ook HTTPS afhandelt met een gratis SSL-certificaat van Let's Encrypt.

In deze gids leert u:

• Stel nginx in als een omgekeerde proxy voor een interne webservice
  
• Beveilig het met een SSL -certificaat met Certbot
  
• Begrijp elk deel van de configuratie, zodat u weet wat het doet en waarom

Nieuw bij webservers?Bekijk onze uitleg over Hoe webservers werken.

Wat is een omgekeerde proxy, en waarom zou je er een gebruiken?

EEN omgekeerde proxy is een server die tussen uw gebruikers en uw backend -services zit.In plaats van dat uw app publiekelijk op een poort luistert (zoals 3000), ontvangt Nginx eerst het verkeer en geeft het vervolgens door aan de app die op de achtergrond wordt uitgevoerd.

Dit is waarom deze aanpak zo nuttig is:

• Verbergt interne poorten en diensten
  Uw app hoeft niet rechtstreeks aan het publiek te worden blootgesteld.Dat vermindert het aanvalsoppervlak en helpt u de toegang te beheersen.
  
• Behandelt https voor jou
  Veel webframeworks kunnen HTTPS rechtstreeks bedienen, maar het is vaak gemakkelijker en betrouwbaarder om Nginx het te laten doen - vooral bij het gebruik van gratis SSL -certificaten van Let's Encrypt.
  
• Schakelt meerdere services op één server in
  U kunt meerdere apps uitvoeren op verschillende poorten (zoals 3000, 4000, 5000) en routeverkeer op basis van domein of pad met slechts één openbaar IP.
  
• Verbetert logboekregistratie en monitoring
  Nginx geeft u gecentraliseerde toegangs- en foutlogboeken, dus het is gemakkelijker om de prestaties te bewaken of problemen te onderzoeken.
  
• Biedt optionele caching, load balancing en rate beperkende
  U kunt de verkeersstroom optimaliseren en backend -services beschermen met slechts enkele extra lijnen in uw Nginx -configuratie.

Zelfs als uw app het webverkeer al kan verwerken, vereenvoudigt het gebruik van Nginx als een omgekeerde proxy vaak de instelling, verbetert de flexibiliteit en verhoogt het de controle.

Vereisten

Laten we ervoor zorgen dat u alles hebt wat u nodig heeft: voordat we aan de slag gaan:

• Een VPS of Cloud Server met Ubuntu 20.04 of hoger: De meeste opdrachten en pakketversies die in deze zelfstudie worden gebruikt, nemen een Debian-gebaseerd systeem aan.Terwijl Nginx en CertBot werken aan andere distributies, kan het installatieproces verschillen.
• Root- of sudo -toegang: U installeert pakketten, bewerkingssysteembestanden en herstartservices - die allemaal verhoogde privileges vereisen.
• Een geregistreerde domeinnaam: U hebt dit nodig om een ​​SSL -certificaat aan te vragen.Laten we Encrypt Valideert het eigendom van uw domein voordat een certificaat wordt uitgegeven.Zonder DNS te wijzen op uw server, zal validatie mislukken.
• DNS wijst op het openbare IP van uw server: Zorg ervoor dat de DNS -records van uw domein worden bijgewerkt.Een eenvoudig een record dat wijst op het IP van uw server is voldoende:

A yourdomain.com → 123.123.123.123
A www.yourdomain.com → 123.123.123.123

Voortplanting kan een paar minuten tot een paar uur duren.

Weet je niet hoe je je DNS moet configureren?Hier is Hoe u een A -record toevoegt met de meeste domeinhosts.

• Een applicatie die wordt uitgevoerd op localhost (bijv. http://localhost:3000): Dit is de app waaraan u proxying zult hebben.Het kan alles zijn - node.js, python -kolf, robijn op rails, enz. Zolang het op een lokale poort luistert, kun je er naartoe gaan.

Notitie: Als uw app nog niet wordt uitgevoerd, is dat oké - u kunt nog steeds door de installatie gaan en later testen.

• Nginx geïnstalleerd: Nginx zal fungeren als de openbaar gerichte server.Als het nog niet is geïnstalleerd:

sudo apt update
sudo apt install nginx

Controleer dan dat het actief is:

sudo systemctl status nginx

Je zou "actief (hardlopen) moeten zien."

• Certbot geïnstalleerd met de Nginx -plug -in: Certbot automatiseert het proces van het verkrijgen en vernieuwen van SSL -certificaten van Let's Encrypt.Installeer het als volgt:

sudo apt install certbot python3-certbot-nginx

Met deze plug -in kan CertBot uw Nginx -configuratie automatisch wijzigen wanneer u een certificaat aanvraagt ​​- geen handmatig bewerken vereist voor basisinstellingen.

Heb je een ander besturingssysteem?Volg deze gids op Hoe te installeren, laten we coderen op Fedora en Debian

Stap 1: Stel de nginx omgekeerde proxy in

Nu uw systeem klaar is, is de eerste echte stap om Nginx te configureren om naar verkeer op uw domein te luisteren en door te sturen naar uw interne toepassing - dit is wat Nginx maakt als een omgekeerde proxy.

Waarom dit ertoe doet

Zonder deze installatie zouden gebruikers die proberen uw website te bezoeken, een lege pagina of het standaard NGINX -welkomstscherm raken.U moet Nginx expliciet vertellen:

• Op welke domein (en) het moet reageren
  
• Wat te doen met inkomende verzoeken
  
• Waar het verkeer achter de schermen naartoe te sturen

Maak een nieuw serverblok

U maakt een configuratiebestand voor uw domein in de sites-beschikbare map van Nginx.Dit houdt configuraties georganiseerd en maakt het gemakkelijk om individuele sites in te schakelen of uit te schakelen.

sudo nano /etc/nginx/sites-available/yourdomain.com

Plak in het volgende blok en stel de domein- en app -poort indien nodig aan:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;

        # Pass important headers to the backend
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Wat deze configuratie doet

• Luister 80;
  Vertelt Nginx om te luisteren naar HTTP -verkeer op poort 80.
  
• server_name yourdomain.com www.yourdomain.com;
  Komt overeen met dit blok op verzoeken aan uw domein.U kunt subdomeinen indien nodig toevoegen of verwijderen.
  
• Locatie /
  Vangt alle verzoeken naar de root en stuurt ze naar uw app.
  
• proxy_pass http: // localhost: 3000;
  Dit is het hart van de omgekeerde proxy - het stuurt het verzoek naar uw backend -app die op poort 3000 wordt uitgevoerd.
  
• proxy_set_header -lijnen
  Deze bewaren details van het originele klantverzoek, zoals:
  
  • Het IP -adres van de gebruiker (X-Real-IP)
    
  • Het originele protocol (http of https)
    
  • De originele hostnaam
    
• Deze info is handig voor logboekregistratie, analyse of wanneer uw app URL's moet genereren die overeenkomen met de ervaring van de bezoeker.

Schakel de configuratie in

Nginx gebruikt symbolische links in de sites-toegepast Directory om sites te activeren.Dus nu maak je een link en opnieuw laden nginx:

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t

Controleer op syntaxisfouten.Als alles er goed uitziet:

sudo systemctl reload nginx

Uw omgekeerde proxy is nu live - verzoeken om http://yourdomain.com wordt doorgegeven aan uw app op poort 3000.

Stap 2: SSL toevoegen met Let's Encrypt en Certbot

Met de omgekeerde proxy die werkt via HTTP, is de volgende stap om het te beveiligen met HTTPS.Dit voegt codering toe aan alle communicatie tussen uw gebruikers en uw server - het beschermen van inloggegevens, API -aanvragen, persoonlijke gegevens en meer.

U gebruikt Let's Encrypt, een gratis certificaatautoriteit en Certbot, die het proces automatiseert.

Waarom https belangrijk is

• Codeert verkeer Dus niemand kan ermee onderscheppen of ermee knoeien
  
• Verbetert SEO - Zoekmachines geven de voorkeur aan veilige sites
  
• Bouwt vertrouwen op - Gebruikers verwachten het hangslotpictogram te zien
  
• Vereist voor veel API's, aanmeldingen en betalingssystemen

Vraag het certificaat aan

Voer deze opdracht uit en vervang de domeinen door uw werkelijke waarden:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Wat dit doet:

• Vertelt Certbot om de nginx -plug -in te gebruiken
  
• Geeft aan welke domeinen u om een ​​certificaat vraagt

Certbot zal:

• Voer domeinvalidatie uit door een tijdelijk bestand te maken in uw Nginx -configuratie
  
• Neem contact op met het coderen om het domeinbezit te verifiëren
  
• Download uw SSL -certificaat en privésleutel
  
• Wijzig uw nginx -configuratie om https te gebruiken
  
• Optioneel omleiden alle HTTP -verkeer naar HTTPS

Tip: Als uw DNS niet volledig wordt voortgebracht of uw serverfirewall poort 80 blokkeert, mislukt validatie.U kunt dit testen met:

curl -I http://yourdomain.com

Bekijk onze gids op om poorten beter te begrijpen Hoe webserverpoorten werken.

Controleer de wijzigingen

Nadat CertBot is voltooid, moet uw Nginx -configuratie zoiets bevatten:

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

U zou nu https://ourdomain.com moeten kunnen bezoeken en uw site kunnen zien met een geldig SSL -certificaat.

Optioneel: Force HTTPS

Als u de optie Redirect niet hebt gekozen tijdens de certbot -installatie, kunt u dit handmatig toevoegen:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

Dit dwingt al het HTTP -verkeer dat moet worden doorgestuurd naar HTTPS, waardoor gebruikers niet per ongeluk de onzekere versie van uw site gebruiken.

Stap 3: SSL -instellingen verbeteren (aanbevolen voor productie)

Zodra uw SSL-certificaat aanwezig is, kunt u Nginx verfijnen om de beveiliging en compatibiliteit te verbeteren.Deze instellingen gaan in het HTTPS -serverblok.

Hier is een verbeterd voorbeeld:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Wat deze instellingen doen

• ssl_protocols TLSv1.2 TLSv1.3
  Schakelt oudere, minder veilige protocollen uit zoals TLS 1.0 en 1.1.
  
• SSL_PREFER_SERVER_CIPHERS ON
  Laat uw server het coderingsalgoritme beslissen, in plaats van uit te stellen naar de browser - die de blootstelling aan zwakke cijferaanvallen kan verminderen.
  
• SSL_CIPHERS HOOG :! Anull :! MD5
  Specificeert sterke cijfer suites en sluit zwakke of gebroken uitsluiting uit (zoals MD5- en nulcijfers).
  
• SSL_Session_Cache en SSL_Session_Timeout
  Controle SSL -sessie hergebruik, die de prestaties enigszins kan verbeteren zonder de beveiliging in gevaar te brengen.
  
• SSL_Session_Tickets Uit
  Schakelt sessietickets uit, wat een bezorgdheid over beveiliging kan zijn als ze niet regelmatig zijn gedraaid.

Deze wijzigingen verbeteren uw SSL -beveiligingsscore en beschermen bezoekers tegen downgrade -aanvallen of onzekere coderingskeuzes.

Optioneel: U kunt uw site testen met SSL -laboratoria om te zien hoe uw configuratie presteert en specifieke verbeteringssuggesties te krijgen.

Stap 4: (Optioneel) Diffie-Hellman Parameters toevoegen

Voor nog sterkere codering kunt u een aangepaste Diffie-Hellman (DH) -toets genereren.Deze stap is optioneel, maar het wordt vaak aanbevolen voor productieomgevingen.

Voer deze opdracht uit om een ​​2048-bit DH-groep te genereren:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Voeg vervolgens de volgende regel toe aan uw SSL Server -blok:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Waarom dit toevoegen?

Diffie-Hellman-parameters versterken voorwaartse geheimhouding, wat betekent dat zelfs als uw privésleutel in de toekomst op de een of andere manier wordt gecompromitteerd, in het verleden gecodeerde sessies nog steeds veilig zullen zijn.

Het duurt een paar minuten om de DH-groep te genereren, maar het is een eenmalige stap en het waard om te doen voor een betere beveiligingshouding.

Stap 5: Stel Auto-verlenging in voor SSL-certificaten

Laten we certificaten coderen om elke 90 dagen af ​​te lopen.Gelukkig installeert CertBot een systeemtimer die twee keer per dag controleert op certificaten die aflopen en deze automatisch verlengt.

U kunt bevestigen dat de timer actief is met:

sudo systemctl list-timers | grep certbot

Je zou zoiets als dit moeten zien:

NEXT                         LEFT    LAST                         PASSED  UNIT           ACTIVATES
2025-06-19 04:00:00 UTC      12h     2025-06-18 04:00:00 UTC       11h ago certbot.timer  certbot.service

Voer het vernieuwingsproces handmatig te testen (zonder wijzigingen aan te brengen):

sudo certbot renew --dry-run

Dit simuleert het volledige vernieuwingsproces en bevestigt dat uw systeem klaar is om het automatisch te verwerken.

Als er geen fouten zijn, zullen uw certificaten in de achtergrond rustig worden verlengd.

Laatste stappen en goede gewoonten

Nu uw omgekeerde proxy is ingesteld en beveiligd met SSL, is het een goed idee om een ​​paar praktische controles en best practices af te ronden.

Deze eenvoudige gewoonten kunnen helpen om problemen langs de lijn te voorkomen, uw configuratie gemakkelijker te onderhouden te maken en ervoor te zorgen dat alles blijft lopen zoals u verwacht.

Zelfs als alles lijkt te werken, kan hier een paar extra minuten doorbrengen je tijd en problemen besparen.

Start uw app opnieuw als deze niet automatisch wijzigingen detecteert
Sommige apps moeten opnieuw worden gestart om correct achter een proxy te werken.

Controleer logboeken
U kunt NGINX -logboeken volgen op fouten of ongebruikelijk verkeer:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Houd nginx en certbot bijgewerkt
Gebruik Sudo APT -update && sudo APT -upgrade regelmatig.Bijgewerkte pakketten repareren bugs, verbeteren de compatibiliteit en patchbeveiligingsproblemen.

Geavanceerde use cases voor nginx reverse proxy met SSL

Nadat u de basisprincipes van het instellen van een beveiligde omgekeerde proxy hebt onder de knie, kunt u uw configuratie uitbreiden om complexere behoeften te ondersteunen.Hier zijn enkele veel voorkomende scenario's die u kunnen helpen meer uit uw server te halen.

Het hosten van meerdere applicaties op één server

Als u verschillende web -apps op verschillende poorten uitvoert, kan Nginx verzoeken naar elke app routeren op basis van domein- of URL -pad.

Voorbeeld: verschillende domeinen

server {
    listen 80;
    server_name app1.example.com;

    location / {
        proxy_pass http://localhost:3001;
        # proxy headers here
    }
}

server {
    listen 80;
    server_name app2.example.com;

    location / {
        proxy_pass http://localhost:3002;
        # proxy headers here
    }
}

Met deze installatie kunt u meerdere apps bedienen met behulp van afzonderlijke subdomeinen, allemaal via Nginx op standaardpoorten.

Docker gebruiken?Leren Hoe u meerdere Docker -apps kunt proxy met nginx.

Op pad gebaseerd proxying

Als alternatief kunt u op basis van URL -paden proxy, wat handig is als u alle apps onder één domein wilt:

server {
    listen 80;
    server_name example.com;

    location /app1/ {
        proxy_pass http://localhost:3001/;
        # proxy headers here
    }

    location /app2/ {
        proxy_pass http://localhost:3002/;
        # proxy headers here
    }
}

Notitie: Bij het gebruik van op pad gebaseerd proxying, kan het achterhalen van schuine strepen en het herschrijven van URL lastig worden-zorg ervoor dat je backend-app kan worden omgekomen onder een subpad.

Rentebeperking toevoegen om uw app te beschermen

U kunt beperken hoeveel verzoeken een klant in een bepaald tijdsbestek kan doen om uw backend te beschermen tegen misbruik of toevallige overbelasting.

Voeg dit toe in het HTTP -blok in /etc/nginx/nginx.conf:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

Dan in uw server of locatieblok:

limit_req zone=mylimit burst=20 nodelay;

Deze configuratie maakt 10 aanvragen per seconde mogelijk met uitbarstingen van maximaal 20 verzoeken, waardoor overtollige verzoeken worden laten vallen om te voorkomen dat uw app overweldigt.

Laad balanceren over meerdere backend -servers

Als u verschillende instanties van uw app heeft die worden uitgevoerd (bijvoorbeeld meerdere containers of VPS's), kan Nginx het verkeer onder hen verdelen:

upstream backend {
    server 192.168.1.10:3000;
    server 192.168.1.11:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        # proxy headers here
    }
}

Nginx balances-aanvragen round-robin standaard, maar u kunt het configureren voor andere methoden zoals de minste verbindingen of IP-hash.

Bekijk voor meer informatie onze gids op DNS Load Balancing.

Logging en foutopsporing

U kunt logboekregistratie aanpassen om belangrijke proxy -info op te nemen voor probleemoplossing of analyse:

log_format proxy '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 'upstream_response_time $upstream_response_time '
                 'request_time $request_time';

access_log /var/log/nginx/proxy_access.log proxy;

Dit registreert stroomopwaartse responstijden en totale aanvraagtijden, waardoor trage backend -antwoorden worden geïdentificeerd.

Aangepaste headers en beveiligingsverbeteringen

Misschien wilt u HTTP -headers toevoegen of wijzigen voor beveiliging of functionaliteit:

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Deze headers beschermen tegen clickjacking, mime snuiven en handhaven HTTPS -gebruik.