Top 50 Nginx-interviewvragen en antwoorden (2026)

Door: Bryce Leo Bryce Leo
Hours Bijgewerkt

Veelgestelde vragen en antwoorden over Nginx tijdens sollicitatiegesprekken

De voorbereiding op een Nginx-interview vereist vooruitziendheid, helderheid en inzicht in hoe interviewers tegenwoordig daadwerkelijke operationele kennis beoordelen. Nginx-interviewvragen onthullen diepgang, besluitvaardigheid, probleemoplossend vermogen en gereedheid voor productie.

Deze functies bieden carrièremogelijkheden binnen cloudinfrastructuur, performance engineering en security, waar praktische configuraties van groot belang zijn. Werkgevers waarderen technische ervaring, domeinexpertise en analytisch vermogen opgedaan in de praktijk. Dit helpt starters, engineers met een gemiddeld ervaringsniveau en senior professionals om basis- tot geavanceerde vaardigheden toe te passen binnen teams onder begeleiding van managers en teamleiders. Lees meer ...

👉 Gratis PDF-download: Nginx-interviewvragen en -antwoorden

Veelgestelde vragen en antwoorden over Nginx tijdens sollicitatiegesprekken

1) Leg uit wat NGINX is en waarom het zo veelvuldig wordt gebruikt in webinfrastructuren.

NGINX is een krachtige open-source webserver die ook functioneert als reverse proxy, load balancer en HTTP-cache. Het ondersteunt de protocollen HTTP, HTTPS, SMTP, POP3 en IMAP. De architectuur maakt gebruik van een event-driven, asynchronous model Hierdoor kan NGINX tienduizenden gelijktijdige verbindingen verwerken met een laag geheugen- en CPU-gebruik. Deze schaalbaarheid maakt NGINX bijzonder geschikt voor webapplicaties met veel verkeer, microservices en gedistribueerde architecturen. Bedrijven met een hoge verkeersbelasting (zoals contentplatforms of API-gateways) geven bijvoorbeeld vaak de voorkeur aan NGINX voor het efficiënt afhandelen van gelijktijdige verbindingen en de levering van statische content.

2) Hoe verwerkt NGINX HTTP-verzoeken intern (gebeurtenisgestuurde architectuur)?

De kernkracht van NGINX ligt in zijn event-driven, non-blocking architectureIn plaats van voor elk verzoek een aparte thread of proces te starten (zoals traditionele servers), gebruikt NGINX een kleine set workerprocessen die gebruikmaken van asynchrone event loops. Elke worker kan duizenden verbindingen beheren door te wachten op meldingen van het besturingssysteem over de gereedheid en gebeurtenissen te verwerken wanneer deze zich voordoen. Omdat NGINX niet blokkeert op I/O-bewerkingen, kan het statische en geproxyeerde content serveren met minimale resources. Dit model is ideaal voor gebruikssituaties met een hoge gelijktijdigheid, waardoor het onder zware belasting efficiënter is dan op processen gebaseerde servers.

3) Wat zijn de belangrijkste verschillen tussen NGINX en Apache?

Hoewel zowel NGINX als Apache populaire webservers zijn, verschillen ze in architectuur, prestaties en ontwerpdoelstellingen:

Aspect NGINX apache
Gelijktijdigheidsmodel Gebeurtenisgestuurd (asynchroon, niet-blokkerend) Proces-/threadgebaseerd (blokkerend)
Geheugengebruik Laag per aansluiting Hoger per verbinding
Beste gebruiksgeval Veel verkeer, statische content, load balancing Dynamische content en een rijk ecosysteem van modules
Schaalbaarheid Schaalbaar met minder middelen Vereist meer hardware vanwege de processen.
Moduleverwerking Modules geselecteerd tijdens het compileren Dynamisch tijdens de uitvoering

Het ontwerp van NGINX optimaliseert de prestaties onder belasting, terwijl Apache meer flexibiliteit biedt met dynamische modules en brede taalondersteuning.

4) Wat zijn de belangrijkste onderdelen van een NGINX-configuratiebestand?

Een NGINX-configuratiebestand (standaardpad: /etc/nginx/nginx.conf) bestaat uit gestructureerde instructieblokken die bepalen hoe NGINX zich gedraagt:

  • Hoofdcontext: wereldwijde instellingen zoals worker_processes, error_logen pid
  • Evenementenblok: beheert werknemersverbindingen en multiprocessing
  • HTTP-blokkering: Bevat configuraties voor HTTP-afhandeling (compressie, caching, gzip, enz.).
    • Serverblokkering: definieert virtuele hosts (domeinen en poorten)
    • Locatieblok: definieert routeringsregels en hoe specifieke URI's worden verwerkt.

Deze blokken werken samen om verzoeken door te sturen, proxy-instellingen te definiëren en SSL/TLS en caching te configureren.

5) Hoe kunt u de NGINX-configuratie veilig herladen zonder downtime?

Om NGINX opnieuw te laden met bijgewerkte configuraties. without interrupting active connections, gebruik je het volgende commando:

nginx -s reload

of op systemen die gebruikmaken van systemd:

sudo systemctl reload nginx

Dit commando geeft het hoofdproces het signaal om de configuratiebestanden opnieuw in te lezen en de werkprocessen soepel opnieuw op te starten zonder de bestaande verbindingen te verbreken. Het beheersen van dergelijke naadloze herstartprocessen is essentieel in omgevingen die hoge beschikbaarheid vereisen.

6) Beschrijf hoe je NGINX als reverse proxy configureert.

Een reverse proxy stuurt clientverzoeken door naar backendservers (de upstream-groep) en stuurt vervolgens het antwoord terug. Hieronder ziet u een typisch NGINX reverse proxy-blok:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend;
            proxy_set_header Host $host;
        }
    }
}

Deze configuratie verbetert de beveiliging, zorgt voor taakverdeling en maakt caching of snelheidsbeperking mogelijk tussen clients en de applicatieservers.

7) Leg de master- en workerprocessen van NGINX uit.

In NGINX:

  • De Masterproces Beheert de configuratie, start werkprocessen en handelt geprivilegieerde bewerkingen af, zoals het binden aan poorten.
  • Werkprocessen De daadwerkelijke afhandeling van verzoeken verzorgen: inkomende verbindingen verwerken en geconfigureerde regels uitvoeren.

Meerdere workers verbeteren de gelijktijdigheid en kunnen worden afgestemd op het aantal beschikbare CPU-cores en de verkeersvraag. Het verdelen van taken verbetert de prestaties en stabiliteit.

GERELATEERDE ARTIKELEN

8) Hoe kun je de verwerking van ongedefinieerde servernamen in NGINX beperken?

Verzoeken zonder geldige gegevens worden afgewezen Host header in NGINX:

server {
    listen 80;
    server_name "";
    return 444;
}

Deze configuratie retourneert code 444Dit is een niet-standaard NGINX-status die de verbinding sluit zonder reactie, waardoor ongedefinieerde hosts effectief worden geweigerd en de beveiliging wordt verbeterd.

9) Waarvoor wordt de ngx_http_upstream_module gebruikt?

De ngx_http_upstream_module definieert groups of backend servers (upstreams) waarnaar NGINX verzoeken kan doorgeven met behulp van instructies zoals proxy_pass, fastcgi_passof uwsgi_passDit biedt flexibiliteit bij het schalen van applicaties in load-balanced omgevingen. Wanneer meerdere backendservers gegroepeerd zijn, kan NGINX het verkeer verdelen op basis van gedefinieerde beleidsregels, waarbij round-robin en andere strategieën worden ondersteund.

10) Beschrijf hoe NGINX wordt gebruikt om statische en dynamische content te serveren.

NGINX is zeer efficiënt in het leveren van diensten. statische bestanden (HTML, CSS, afbeeldingen) rechtstreeks via de geoptimaliseerde event loop en bestands-I/O-mechanismen. Voor dynamische inhoudNGINX stuurt verzoeken door naar backend-processors zoals PHP-FPM. Python WSGI-servers, of applicatie-frameworks via FastCGI/proxy-mechanismen. Deze scheiding stelt NGINX in staat om uit te blinken als statische bestandsserver, terwijl gebruik wordt gemaakt van backend-services voor dynamische generatie, wat optimale prestaties en schaalbaarheid garandeert.

11) Hoe werkt load balancing in NGINX en welke verschillende methoden zijn er beschikbaar?

NGINX biedt robuuste oplossingen taakverdeling door de upstream Deze richtlijn verdeelt het verkeer over meerdere backendservers om de prestaties te optimaliseren en een hoge beschikbaarheid te garanderen. Het ondersteunt verschillende methoden:

Methode Beschrijving Beste gebruiksgeval
Round Robin De standaardmethode verdeelt verzoeken sequentieel over de servers. Gelijkmatig verdeelde werklasten.
Minste verbindingen Verstuurt verzoeken naar de server met de minste actieve verbindingen. Langdurige sessies.
IP-hash Gebruikt het IP-adres van de client om de serverselectie te bepalen. Sessiepersistentie.
Kortste tijd Balans op basis van reactietijd en aantal verbindingen. Toepassingen die gevoelig zijn voor latentie.

NGINX kan ook de volgende prestaties leveren: gezondheidchecks Het dynamisch verwijderen van ongezonde servers, waardoor een naadloze verkeersstroom en veerkracht worden gewaarborgd.

12) Wat is het verschil tussen NGINX open source en NGINX Plus?

NGINX Open-Source Dit is de communityversie die essentiële webserver-, proxy- en loadbalancingfunctionaliteiten biedt. NGINX Plus Dit is de commerciële editie die deze functies uitbreidt met verbeteringen van enterprise-niveau, zoals geavanceerde monitoring, sessiepersistentie, dynamische herconfiguratie en actieve statuscontroles.

Kenmerk NGINX Open-source NGINX Plus
Load Balancing Basis (Round Robin, IP-hash) Geavanceerd (Korte tijd, Dynamische herconfiguratie)
Monitoren Handmatige / externe gereedschappen Ingebouwd dashboard en API
Caching Basic Verbeterd met spoelregeling
Support Alleen gemeenschap Ondersteuning en updates voor bedrijven

Organisaties met bedrijfskritische workloads kiezen vaak voor NGINX Plus vanwege de verbeterde betrouwbaarheid en observeerbaarheid.

13) Hoe implementeer je caching in NGINX?

Caching in NGINX verbetert de reactiesnelheid en vermindert de belasting van de backend door veelgebruikte content lokaal op te slaan. Het wordt ingeschakeld met behulp van de proxy_cache richtlijn. Voorbeeldconfiguratie:

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g;
server {
    location / {
        proxy_cache my_cache;
        proxy_pass http://backend;
    }
}

Wanneer een overeenkomend verzoek binnenkomt, worden antwoorden uit de cache direct vanaf de schijf verzonden, waardoor de verwerking verderop in het proces wordt overgeslagen. U kunt de vervaldatum van de cache beheren met proxy_cache_valid en specifieke URI's uitsluiten met proxy_no_cacheDit mechanisme is cruciaal voor omgevingen met veel verkeer, zoals nieuws- of e-commercewebsites.

14) Leg het doel en het gebruik van de “try_files”-richtlijn uit.

De try_files Deze instructie controleert of bestanden in een specifieke volgorde aanwezig zijn voordat een verzoek wordt doorgestuurd naar de alternatieve locatie. Het wordt vaak gebruikt voor statische site routing or single-page applicaties (SPA's).

Voorbeeld:

location / {
    try_files $uri $uri/ /index.html;
}

Hier controleert NGINX eerst of de gevraagde URI overeenkomt met een bestand, vervolgens met een map, en stuurt verzoeken die niet overeenkomen door naar de juiste map. /index.htmlDit verbetert de efficiëntie en de gebruikerservaring doordat gecachede of statische bestanden direct worden aangeboden, waardoor onnodige backend-aanroepen worden vermeden.

15) Hoe kan NGINX HTTPS en SSL/TLS-terminatie afhandelen?

NGINX fungeert als een SSL/TLS-terminatieproxy en verzorgt de encryptie en decryptie op serverniveau voordat niet-gecodeerde verzoeken worden doorgestuurd naar de upstream-services. Voorbeeldconfiguratie:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/example.crt;
    ssl_certificate_key /etc/ssl/private/example.key;
    location / {
        proxy_pass http://backend;
    }
}

Het ondersteunt HTTP / 2, OCSP-nieten, HSTSen moderne cijfersuiteswaardoor veilige en hoogwaardige communicatie mogelijk wordt. Het beëindigen van SSL bij NGINX vermindert de encryptiebelasting op backendservers en vereenvoudigt het certificaatbeheer.

16) Wat is het verschil tussen rewrite en redirect in NGINX?

Beiden herschrijven en redirect Ze wijzigen de manier waarop verzoeken worden doorgestuurd, maar ze verschillen fundamenteel van elkaar:

Aspect Herschrijven redirect
Type Interne URL-herschrijving Externe clientomleiding
Reactiecode 200 (intern) 301/302 (HTTP-omleiding)
Zichtbaarheid Transparant voor de gebruiker De klant ziet een nieuwe URL.
Use Case SEO-vriendelijke URL's, routering Domeinmigratie, HTTPS-handhaving

Voorbeeld:

rewrite ^/oldpage$ /newpage permanent;  # Redirect
rewrite ^/img/(.*)$ /assets/$1 break;   # Rewrite

Het begrijpen van dit onderscheid is essentieel voor het effectief optimaliseren van SEO en routinglogica.

17) Hoe beveilig je NGINX tegen veelvoorkomende kwetsbaarheden?

Beveiligingsversterking omvat een combinatie van best practices:

  • Servertokens uitschakelen: server_tokens off;
  • Beperk de aanvraagmethoden: Sta alleen GET, POST en HEAD toe.
  • Bufferoverloop beperken: Configure client_max_body_size en client_body_buffer_size.
  • Gebruik HTTPS met moderne versleutelingstechnieken.
  • Snelheidsbeperking inschakelen via limit_req_zone.
  • Verberg versie-informatie en schakel de directoryweergave uit.

Daarnaast is het gebruik van een Firewall voor webtoepassingen (WAF) als ModSecurity with NGINX Kan kwaadaardig verkeer filteren. Regelmatige updates van NGINX en het toepassen van beveiligingspatches zijn essentieel om zero-day exploits te voorkomen.

18) Wat zijn NGINX-variabelen en hoe worden ze gebruikt in configuraties?

NGINX-variabelen slaan dynamische gegevens op die worden gebruikt in configuraties en logverwerking. Ze kunnen verzoekheaders, client-IP-adressen of berekende waarden vertegenwoordigen. Voorbeelden zijn: $remote_addr, $host, $uri, $request_methoden $upstream_addr.

Bijvoorbeeld:

log_format custom '$remote_addr - $host - $uri';

Variabelen bieden meer flexibiliteit, waardoor voorwaardelijke routering en aangepaste logboekregistratie mogelijk worden. U kunt ook aangepaste variabelen definiëren met behulp van de set richtlijn, die helpt bij het ontwerpen van modulaire configuraties.

19) Hoe kunt u snelheidsbeperking instellen in NGINX?

Rate limiting regelt hoe vaak gebruikers verzoeken kunnen verzenden en beschermt zo tegen brute force- en DDoS-aanvallen. Het wordt geconfigureerd met behulp van de limit_req_zone richtlijn:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
server {
    location / {
        limit_req zone=mylimit burst=5;
    }
}

Dit staat één verzoek per seconde toe, met een piek van vijf. NGINX verwijdert overtollige verzoeken of vertraagt ​​ze, afhankelijk van de configuratie. Rate limiting zorgt voor een eerlijk gebruik van resources en voorkomt overbelasting van de server.

20) Wat zijn de voor- en nadelen van het gebruik van NGINX als reverse proxy?

NGINX als reverse proxy biedt talrijke voordelen, maar kent ook enkele nadelen:

Voordelen Nadelen
Hoge prestaties en goede afhandeling van gelijktijdige processen Vereist handmatige afstemming voor grootschalige implementaties.
SSL-terminatie en gecentraliseerde beveiliging Beperkte ondersteuning voor dynamische modules (tijdens compilatie)
Ondersteuning voor load balancing en caching Complexe configuratie voor nieuwe gebruikers
Filteren op de applicatielaag Gebrek aan native dynamische content-uitvoering

De voordelen wegen in de meeste bedrijfsomgevingen ruimschoots op tegen de beperkingen, waardoor NGINX een onmisbaar onderdeel is van moderne webinfrastructuren.

21) Hoe kunt u de prestaties en de status van NGINX in een productieomgeving bewaken?

Het monitoren van NGINX is cruciaal voor het identificeren van knelpunten, storingen en afwijkend verkeersgedrag. Er kunnen verschillende benaderingen worden gebruikt:

  1. Ingebouwde statusmodule (stub_status):

    Toont actieve verbindingen, verwerkte verzoeken en lees-/schrijfstatus. Voorbeeld:

    location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
  2. NGINX Plus-dashboard: Biedt realtime meetgegevens via REST API en grafische gebruikersinterface.
  3. Integraties van derden: Tools zoals Prometheus, Grafana, Datadog of ELK kunnen meetwaarden en logboeken verzamelen.
  4. Toegangs- en foutenlogboeken: Regelmatige logrotatie en -analyse met tools zoals GoAccess of AWStats verbeteren de observeerbaarheid.

Monitoring helpt bij het waarborgen van de beschikbaarheid, het snel opsporen van storingen en de capaciteitsplanning.

22) Wat is het verschil tussen de proxy_pass- en fastcgi_pass-richtlijnen?

Beide richtlijnen sturen verzoeken door naar backend-services, maar zijn ontworpen voor verschillende protocollen:

Richtlijn Doel Backend-protocol Voorbeeld gebruik
proxy_pass Stuurt HTTP- of HTTPS-verzoeken door naar backendservers. HTTP Reverse proxying web API's of microservices
fastcgi_pass Verstuurt verzoeken naar een FastCGI-processor. FastCGI PHP-FPM, Python FastCGI-toepassingen

Voorbeeld:

location /api/ {
    proxy_pass http://backend;
}
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
}

Samengevat, gebruik proxy_pass voor generieke HTTP-backends en snelcgi_pass voor dynamische taalomgevingen zoals PHP.

23) Hoe configureert u gzip-compressie in NGINX en wat zijn de voordelen ervan?

Door Gzip-compressie in NGINX in te schakelen, wordt het bandbreedtegebruik verminderd en de laadtijd verbeterd doordat tekstgebaseerde reacties worden gecomprimeerd voordat ze naar clients worden verzonden.

Voorbeeldconfiguratie:

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 6;
gzip_vary on;

Voordelen:

  • Vermindert de bestandsgrootte bij overdracht met wel 70%.
  • Verbetert de Time-to-First-Byte (TTFB) en de paginaprestaties.
  • Bespaart bandbreedtekosten, wat vooral gunstig is voor mobiele gebruikers.

Het is echter niet aan te raden om dit toe te passen op reeds gecomprimeerde bestanden (bijvoorbeeld: .zip, .jpg, .png) om CPU-overbelasting te voorkomen.

24) Wat zijn enkele best practices voor het optimaliseren van NGINX voor veel verkeer?

Optimalisatie voor hoge verkeersbelasting vereist een zorgvuldige afstemming van resources en configuratieparameters:

De Omgeving Richtlijn Aanbevolen praktijk
Werknemers worker_processes auto; CPU-kernen op elkaar afstemmen
aansluitingen worker_connections 4096; Verhoog de gelijktijdigheid
In leven houden keepalive_timeout 65; Optimaliseer hergebruik door de klant
Dien in Descriptors OS ulimit -n Verhoog de limieten voor open sockets
Caching proxy_cache_path Verminder de belasting van de backend
gzip gzip on; Tekstreacties comprimeren

Bovendien, met behulp van asynchrone schijf-I/O, taakverdelingen gezondheidscontroles stroomopwaarts Garandeert stabiliteit en snelheid bij een groot aantal gelijktijdige verzoeken.

25) Hoe verwerkt NGINX WebSocket-verbindingen?

WebSockets maken bidirectionele communicatie tussen client en server mogelijk – cruciaal voor realtime-applicaties. NGINX ondersteunt dit van nature via de juiste header forwarding.

Voorbeeldconfiguratie:

location /ws/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Sleutelpunten:

  • De Upgrade en Connection Kopteksten zijn verplicht.
  • Zorg ervoor dat NGINX HTTP/1.1 gebruikt voor persistente TCP-verbindingen.
  • Load balancing voor WebSockets vereist mogelijk sticky sessions. ip_hash.

Deze configuratie ondersteunt toepassingen zoals chatten, aandelenhandel of gamen.

26) Wat is het doel van de richtlijn “worker_rlimit_nofile”?

worker_rlimit_nofile Definieert het maximale aantal open bestandsdescriptors dat beschikbaar is voor workerprocessen. Deze limiet heeft direct invloed op hoeveel gelijktijdige verbindingen NGINX kan verwerken. Voorbeeld:

worker_rlimit_nofile 100000;

Het verhogen van deze limiet is essentieel voor systemen met een hoge gelijktijdigheid (zoals API-gateways of streamingplatforms). De limiet van het besturingssysteem (ulimit -n) moet ook worden verhoogd om overeen te komen met deze waarde, voor de consistentie.

27) Hoe kan NGINX worden gebruikt voor het automatisch herschrijven van URL's of het doorverwijzen naar HTTPS?

Door HTTP naar HTTPS door te verwijzen, wordt veilige communicatie gegarandeerd. Voorbeeld:

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

Deze configuratie geeft een 301 permanente omleiding van HTTP naar HTTPS. Voor meer controle kunnen herschrijfregels padspecifieke omleidingen afdwingen:

rewrite ^/oldpath$ /newpath permanent;

Automatische HTTPS-handhaving verbetert de SEO-ranking, voorkomt man-in-the-middle-aanvallen en zorgt voor een consistente gebruikerservaring.

28) Wat zijn enkele veelvoorkomende oorzaken van “502 Bad Gateway”-fouten in NGINX?

Een "502 Bad Gateway"-foutmelding geeft aan dat NGINX, dat als proxy fungeert, geen geldig antwoord van een upstream-server heeft ontvangen. Veelvoorkomende oorzaken zijn:

  • Storing of onbeschikbaarheid van de backend-server.
  • Onjuist proxy_pass URL of socketpad.
  • Time-out stroomopwaarts (proxy_read_timeout te laag).
  • Firewall of SELinux blokkeert verbindingen met de upstream-partner.
  • Onjuist geconfigureerde FastCGI-parameters (voor PHP).

Om de fout op te sporen, controleer de foutenlogboeken (/var/log/nginx/error.log), de bereikbaarheid van de bovenliggende server te verifiëren en de reacties van de backend rechtstreeks te testen via curl.

29) Hoe ondersteunt NGINX microservices en op containers gebaseerde architecturen (bijv. Docker, Kubernetes)?

NGINX is ideaal voor microservice-omgevingen vanwege het lichte ontwerp en de reverse proxy-functionaliteit. In Docker of Kubernetes fungeert het als:

  • Ingress Controller: Beheert extern HTTP/S-verkeer naar interne services.
  • Servicegateway: Voert routering, taakverdeling en authenticatie uit.
  • Sidecar-proxy: Verbetert de veerkracht en observeerbaarheid in service meshes (bijv. Istio).

NGINX-configuraties kunnen dynamisch worden bijgewerkt via Kubernetes ConfigMaps, waardoor gecentraliseerde verkeersregeling en SSL-beheer mogelijk zijn. De modulaire aanpak sluit perfect aan bij containergebaseerde en cloud-native implementaties.

30) Op welke verschillende manieren kan de beveiliging van NGINX voor productiesystemen worden verbeterd?

Het verbeteren van de NGINX-beveiliging vereist een configuratie met meerdere lagen:

  1. SSL/TLS-beveiliging: Gebruik moderne versleutelingstechnieken en schakel SSLv3/TLSv1.0 uit.
  2. Beperk HTTP-methoden: Sta alleen veilige werkwoorden toe (GET, POST, HEAD).
  3. Beveiligingsheaders: 
    add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
  4. Versie-informatie verbergen: server_tokens off;
  5. Schakel snelheidsbeperking en toegangscontrole in.
  6. Integreer WAF of Fail2Ban ter voorkoming van brute-force-aanvallen.

Gecombineerd creëren deze maatregelen een robuuste, productieklare NGINX-omgeving die bestand is tegen veelvoorkomende exploits.

31) Hoe kun je NGINX-problemen effectief oplossen?

Het debuggen van NGINX omvat het systematisch analyseren van logbestanden, configuratiebestanden en processtatussen. De belangrijkste stappen zijn:

  1. Controleer de syntaxis:
    2. nginx -t
  2. Controleert de configuratie vóór het herladen.

    3. Debuglogboekregistratie inschakelen:

    error_log /var/log/nginx/error.log debug;
  3. Biedt gedetailleerde diagnostische informatie tijdens de uitvoering.

    4. Analyseer toegangslogboeken: Detecteer responscodes en verzoekpatronen met behulp van:

    tail -f /var/log/nginx/access.log
  4. Connectiviteit testen: Gebruik curl -v or wget om de bereikbaarheid van de backend te controleren.
  5. Actieve verbindingen bewaken: Via stub_status or netstat.

Inzicht in de workerprocessen, bufferlimieten en upstream-reacties van NGINX helpt bij het snel opsporen van knelpunten in productiesystemen.

32) Hoe configureert u de logboekregistratie in NGINX en welke aangepaste logformaten zijn er?

NGINX biedt flexibele logboekregistratiemechanismen via access_log en error_log richtlijnen.

Voorbeeldconfiguratie:

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

access_log /var/log/nginx/access.log main;
error_log /var/log/nginx/error.log warn;

U kunt definiëren aangepaste formaten om meetgegevens zoals op te nemen $upstream_addr, $request_timeof $bytes_sent.

Voor geavanceerde observatiemogelijkheden worden logbestanden vaak verzonden naar ELK, Loki of Splunk voor realtime analyse en dashboards.

33) Wat is de rol van de proxy_buffering-richtlijn in NGINX?

proxy_buffering Hiermee wordt bepaald of NGINX reacties van upstream-servers buffert voordat ze naar clients worden verzonden.

omgeving Beschrijving Use Case
proxy_buffering on; BufferDit is het volledige antwoord voor een geoptimaliseerde doorvoer. Standaard; verbetert de prestaties
proxy_buffering off; Verzendt gegevens rechtstreeks naar clients zonder buffering. Realtime streaming of API's

Om bijvoorbeeld buffering uit te schakelen:

location /stream/ {
    proxy_buffering off;
}

Het uitschakelen van buffering is ideaal voor chat- of streamingdiensten, maar kan de doorvoersnelheid voor regulier webverkeer verminderen.

34) Leg uit hoe NGINX-caching ongeldig gemaakt of gewist kan worden.

NGINX Open Source biedt geen ingebouwde cache-opschoning, maar dit kan op verschillende manieren worden bereikt:

  1. Handmatig wissen: Verwijder bestanden uit de cachemap. 
    rm -rf /var/cache/nginx/*
  2. Module van derden: Gebruik ngx_cache_purge Om te wissen via een HTTP-verzoek: 
    location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
  3. NGINX Plus-functie: Maakt het mogelijk om de cache dynamisch te legen via een API.

Door het opschonen wordt verouderde content snel vervangen, waardoor de actualiteit en consistentie van de content behouden blijft in CDN- of multi-node-implementaties.

35) Hoe gaat NGINX om met time-outs bij verbindingen?

NGINX biedt meerdere time-outrichtlijnen om te bepalen hoe lang het wacht op reacties van de client of upstream-servers:

Richtlijn Doel Standaard(en)
client_body_timeout Wachttijd voor het lichaam van de cliënt 60
client_header_timeout Wachttijd voor clientheader 60
keepalive_timeout Inactieve keepalive-verbindingen 75
send_timeout Tijd om gegevens naar de klant te verzenden 60
proxy_read_timeout Wachttijd voor reactie van de upstream-partij 60

Een goede afstemming voorkomt onnodige onderbrekingen en zorgt voor een soepelere gebruikerservaring, zelfs onder wisselende netwerkomstandigheden.

36) Hoe implementeer je blue-green deployment met NGINX?

In een blauwgroene inzetTwee omgevingen (Blauw = actief, Groen = stand-by) draaien gelijktijdig. NGINX fungeert als verkeersrouter tussen deze omgevingen.

Voorbeeldconfiguratie:

upstream app_cluster {
    server blue.example.com;
    #server green.example.com; # Uncomment during switch
}
server {
    location / {
        proxy_pass http://app_cluster;
    }
}

Wanneer de nieuwe versie (groen) is getest en geverifieerd, wordt het verkeer omgeschakeld door de upstream-definitie bij te werken en NGINX opnieuw te laden.nginx -s reload).

Deze methode zorgt ervoor nul uitvaltijd tijdens applicatie-updates of terugdraaiingen.

37) Wat is rate limiting burst en hoe verbetert het de prestaties van NGINX?

De burst Deze parameter in de snelheidsbeperking maakt het mogelijk dat korte pieken in het verkeer tijdelijk worden doorgelaten zonder onmiddellijk te worden geblokkeerd.

Voorbeeld:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
location /api/ {
    limit_req zone=mylimit burst=5 nodelay;
}

Hier worden vijf extra verzoeken direct geaccepteerd voordat de beperking wordt toegepast.

Deze techniek zorgt voor een gelijkmatige verdeling van de verkeerspieken, waardoor een consistente gebruikerservaring behouden blijft zonder de backend-systemen te overbelasten.

38) Hoe gaat NGINX om met IPv6 en dual-stack-omgevingen?

NGINX biedt volledige ondersteuning voor IPv6 in zowel server- als upstream-configuraties. Voorbeeld:

server {
    listen [::]:80 ipv6only=on;
    server_name example.com;
}

Ondersteuning voor dual-stack (IPv4 + IPv6) wordt bereikt door beide op te nemen:

listen 80;
listen [::]:80;

IPv6-compatibiliteit zorgt voor bredere toegankelijkheid, met name voor mobiele en internationale gebruikers, en is cruciaal voor het voldoen aan moderne internetstandaarden.

39) Hoe configureert u sticky sessions in NGINX load balancing?

Dankzij sticky sessions worden verzoeken van dezelfde client altijd naar dezelfde backend-server doorgestuurd.

  1. gebruik ip_hash: 
    upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}
  2. NGINX Plus Sticky Cookie:
    Geavanceerde sessiepersistentie met configureerbare cookies.

Sticky sessions zijn essentieel voor stateful applicaties zoals gebruikersdashboards of winkelwagens, omdat ze de consistentie van sessiegegevens garanderen zonder gedeelde opslag.

40) Wat zijn de belangrijkste logniveaus in NGINX en waarin verschillen ze van elkaar?

NGINX ondersteunt hiërarchische logniveaus om de gedetailleerdheid van het foutenlogboek te regelen.

Niveau Beschrijving
debug Gedetailleerde informatie voor het oplossen van problemen (zeer uitgebreid)
info Algemene runtime-informatie
notice Belangrijke maar niet-kritieke gebeurtenissen
warn Mogelijke problemen of verkeerde configuraties
error Operationele fouten die aandacht vereisen
crit, alert, emerg Kritieke storingen en systeemwaarschuwingen

Voorbeeldconfiguratie:

error_log /var/log/nginx/error.log warn;

Het aanpassen van logniveaus aan de omgeving (debug in de testomgeving, warn in de productieomgeving) helpt bij het behouden van een balans tussen inzicht en prestaties.

41) Hoe meet je de prestaties van NGINX?

Benchmarking van NGINX omvat het meten van doorvoer, latentie en gelijktijdigheid om knelpunten in de configuratie te identificeren. Veelgebruikte tools zijn onder andere:

ApacheBench (ab):

ab -n 10000 -c 100 http://example.com/
  • Tests meten het volume en de gelijktijdigheid van de aanvragen.
  • werk: Geeft gedetailleerde latentiepercentielen en aanvraagsnelheden weer.
  • belegering / httperf: Simuleert de verkeersdrukte in de praktijk.
  • Grafana + Prometheus: Monitort realtime prestatiegegevens.

Bij benchmarking moeten parameters zoals requests per second (RPS), time per requesten error rate.

Het afstemmen van variabelen zoals worker_processes, worker_connectionsen keepalive_timeout Dit verbetert de waargenomen doorvoer aanzienlijk.

42) Hoe kan NGINX worden geïntegreerd met CI/CD-pipelines?

NGINX integreert naadloos met CI / CD voor geautomatiseerde implementatie, testen en configuratiebeheer. Veelgebruikte methoden zijn onder andere:

  • Infrastructuur als code (IaC): Beheer configuraties met Ansible-, Terraform- of Helm-grafieken.
  • Docker-containers: Bouw en implementeer NGINX-images met behulp van CI-tools (Jenkins, GitLab CI of GitHub Actions).
  • Geautomatiseerd testen: Valideer configuraties met behulp van nginx -t in de pijplijnfase.
  • Blauwgroen / Canary Implementatie automatisering: Update de upstream-servers dynamisch tijdens de uitrol.

Voorbeeld van een GitLab CI-codefragment:

deploy:
  script:
    - nginx -t
    - systemctl reload nginx

Geautomatiseerde implementatie zorgt voor consistente, versiebeheerde en betrouwbare NGINX-uitrol.

43) Leg de rol van de NGINX Ingress Controller in Kubernetes uit.

De NGINX Ingress-controller Het beheert inkomend verkeer naar Kubernetes-services. Het vertaalt Kubernetes Ingress-resources dynamisch naar NGINX-configuraties.

Belangrijkste Functies:

  • Routeert HTTP/S-verzoeken naar de juiste service.
  • Biedt SSL-terminatie, snelheidsbeperking en URL-herschrijving.
  • Ondersteunt taakverdeling over pods.
  • Maakt annotaties mogelijk voor nauwkeurige controle (bijv. rewrite-target, proxy-body-size).

Voorbeeld Ingress YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Deze architectuur ontkoppelt de logica voor verkeersroutering van de containerimplementaties voor flexibele schaalbaarheid.

44) Hoe gaat NGINX om met HTTP/2 en wat zijn de voordelen ervan?

NGINX biedt volledige ondersteuning HTTP / 2, de opvolger van HTTP/1.1, die de efficiëntie verbetert door middel van multiplexing en headercompressie.

Om HTTP/2 in te schakelen:

server {
    listen 443 ssl http2;
    ...
}

Voordelen:

Kenmerk Beschrijving
multiplexing Meerdere verzoeken per TCP-verbinding
Headercompressie (HPACK) Vermindert bandbreedtegebruik
Server Push Stuurt preventief activa naar klanten.
Snellere TLS Gestroomlijnde, veilige handdrukken

HTTP/2 reduceert de latentie en laadtijden van pagina's aanzienlijk, met name voor moderne webapplicaties met veel elementen.

45) Wat is het verschil tussen upstream keepalive en connection reuse in NGINX?

Stroomopwaarts in leven houden Onderhoudt permanente verbindingen met backendservers, waardoor de overhead van de TCP-handshake wordt verminderd. Voorbeeld:

upstream backend {
    server app1.example.com;
    keepalive 32;
}

Verschil:

Aspect In leven houden Hergebruik van verbindingen
strekking Tussen NGINX en upstream Tussen NGINX en klanten
Doel Backend-optimalisatie Frontend-prestaties
Configuratie keepalive binnen upstream keepalive_timeout in server blok

Beide technieken verlagen de latentie, maar bedienen verschillende communicatielagen (clientzijde versus serverzijde).

46) Hoe kun je NGINX dynamisch herconfigureren zonder het opnieuw op te starten?

Om dynamisch nieuwe configuraties toe te passen zonder stilstand, gebruik het reload mechanisme:

nginx -t && nginx -s reload

Dit geeft aan dat masterproces om nieuwe workers met bijgewerkte configuraties te starten en tegelijkertijd de oude workers op een gecontroleerde manier af te sluiten.

In NGINX Plus kunnen wijzigingen worden aangebracht. via API (bijvoorbeeld het dynamisch toevoegen van upstream-servers):

curl --request POST \
  --url http://localhost:8080/api/3/http/upstreams/backend/servers \
  --header 'Content-Type: application/json' \
  --data-raw '{"server":"10.0.0.12"}'

Deze functionaliteit ondersteunt implementaties zonder downtime in moderne DevOps-pipelines.

47) Wat zijn de belangrijkste verschillen tussen een reverse proxy en een forward proxy in NGINX?

Aspect Reverse proxy Proxy doorsturen
Zichtbaarheid van de klant Klanten zijn zich niet bewust van de backend-servers. Servers die de identiteit van de client niet kennen
Primair gebruik Load balancing, caching, SSL-terminatie Filtering, anonimiteit, toegangscontrole
Veelvoorkomend gebruiksscenario Webverkeersverdeling Zakelijk of beveiligd uitgaand internetgebruik
NGINX-ondersteuning Inheems en veelgebruikt Vereist aangepaste configuratie

Voorbeeld (voorwaartse proxy):

location / {
    proxy_pass $scheme://$http_host$request_uri;
    proxy_set_header Host $http_host;
}

RevErse-proxying blijft de meest voorkomende toepassing, met name voor API-gateways en microservice-architecturen.

48) Hoe kan NGINX worden gebruikt voor het beperken en vertragen van API-aanvragen?

Rate limiting beschermt API's tegen misbruik en zorgt voor eerlijk gebruik. Voorbeeldconfiguratie:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
    location /api/ {
        limit_req zone=api_limit burst=20 nodelay;
        proxy_pass http://backend;
    }
}

Mechanisme:

  • limit_req_zone: Definieert de gedeelde geheugenzone en -snelheid.
  • burst: Maakt beperkte, tijdelijke pieken mogelijk.
  • nodelay: Handhaaft onmiddellijk limieten.

Deze configuratie zorgt ervoor dat elk client-IP-adres maximaal 10 verzoeken per seconde kan doen, terwijl korte pieken wel zijn toegestaan.

49) Wat zijn de typische gebruiksscenario's van NGINX in DevOps-omgevingen binnen bedrijven?

In DevOps-ecosystemen van bedrijven vervult NGINX meerdere cruciale rollen:

  1. Web Server: Hoogwaardige levering van statische content.
  2. Reverse Proxy / Load Balancer: Verkeersbeheer over microservices.
  3. API-gateway: Authenticatie, routering en beperking van bandbreedte.
  4. Ingress Controller: Voor Kubernetes-clusters.
  5. Inhoudscachelaag: Vermindert de belasting van de backend.
  6. SSL-terminatie-eindpunt: Gecentraliseerd certificaatbeheer.
  7. Monitoring-eindpunt: Integratie van meetgegevens en observeerbaarheid.

Dankzij het compacte formaat en het modulaire ontwerp is NGINX onmisbaar in CI/CD-pipelines, hybride clouds en clusters met hoge beschikbaarheid.

50) Wat zijn de belangrijkste verschillen tussen NGINX en HAProxy voor load balancing?

Beide zijn krachtige load balancers, maar ze verschillen in focus en architectuur:

Kenmerk NGINX HAProxy
Hoofdrol Webserver + reverse proxy Dedicated TCP/HTTP load balancer
Configuratie eenvoud Gemakkelijker voor webgebaseerde workloads Complexere maar meer gedetailleerde controle
Ondersteuning van lagen L7 (HTTP), gedeeltelijke L4 L4 & L7 volledig
Dynamische herconfiguratie Beperkt (open-source) Native runtime-updates
Prestaties Uitstekend geschikt voor een gevarieerde werkbelasting. Uitermate geschikt voor het balanceren van ruwe belasting.
Extra functies Caching, compressie, statische inhoud Gezondheidscontroles, priktafels

Ondernemingen combineren vaak NGINX (frontend) en HAProxy (backend) voor optimale routering en schaalbaarheid.

🔍 Top NGINX-interviewvragen met praktijkvoorbeelden en strategische antwoorden

1) Wat is NGINX en waarom wordt het zo vaak gebruikt in productieomgevingen?

Verwacht van kandidaat: De interviewer wil uw basiskennis van NGINX en uw begrip van de praktische waarde ervan in daadwerkelijke systemen toetsen.

Voorbeeld antwoord: “NGINX is een krachtige webserver en reverse proxy die bekend staat om zijn gebeurtenisgestuurde architectuur. Het wordt veel gebruikt in productieomgevingen omdat het een groot aantal gelijktijdige verbindingen efficiënt kan verwerken en daarbij minder systeembronnen verbruikt dan traditionele webservers.”

2) Kun je het verschil tussen NGINX en Apache uitleggen?

Verwacht van kandidaat: De interviewer beoordeelt uw vermogen om technologieën te vergelijken en op basis van toepassingsvoorbeelden de juiste tool te kiezen.

Voorbeeld antwoord: “NGINX maakt gebruik van een asynchrone, niet-blokkerende architectuur, waardoor het efficiënter is voor het verwerken van veel verkeer en statische content. Apache gebruikt een procesgestuurd model dat flexibeler kan zijn voor dynamische configuraties, maar onder zware belasting meer resources kan verbruiken.”

3) Hoe fungeert NGINX als reverse proxy?

Verwacht van kandidaat: De interviewer wil uw begrip van reverse proxy-concepten en uw plaats binnen moderne architecturen toetsen.

Voorbeeld antwoord: "NGINX fungeert als een reverse proxy door clientverzoeken te ontvangen en door te sturen naar backendservers. Vervolgens stuurt het de serverreacties terug naar de client, wat de beveiliging, de taakverdeling en de algehele prestaties verbetert."

4) Beschrijf een situatie waarin je NGINX hebt gebruikt voor load balancing.

Verwacht van kandidaat: De interviewer is op zoek naar praktijkervaring en uw vermogen om NGINX-functies in reële situaties toe te passen.

Voorbeeld antwoord: “In mijn vorige functie heb ik NGINX geconfigureerd om verkeer over meerdere applicatieservers te verdelen met behulp van round-robin- en least-connections-algoritmes. Deze aanpak verbeterde de beschikbaarheid van applicaties en voorkwam dat één server een knelpunt werd.”

5) Hoe ga je om met SSL- en HTTPS-configuratie in NGINX?

Verwacht van kandidaat: De interviewer wil uw kennis van best practices op het gebied van beveiliging en configuratiebeheer toetsen.

Voorbeeld antwoord: “In mijn vorige functie heb ik SSL geconfigureerd door certificaten te installeren, HTTPS-listeners in te schakelen en sterke cipher suites af te dwingen. Ik heb ook HTTP naar HTTPS-omleiding geïmplementeerd om veilige communicatie tussen alle eindpunten te garanderen.”

6) Welke stappen zou u ondernemen om een ​​502 Bad Gateway-fout in NGINX op te lossen?

Verwacht van kandidaat: De interviewer test uw probleemoplossende vaardigheden en uw methodiek voor het oplossen van storingen.

Voorbeeld antwoord: “Ik zou beginnen met het controleren van de NGINX-foutlogboeken om verbindingsproblemen met de backend te identificeren. Vervolgens zou ik controleren of de upstream-servers actief zijn, de juiste proxy-instellingen bevestigen en ervoor zorgen dat de time-outs correct zijn geconfigureerd.”

7) Hoe optimaliseer je de NGINX-prestaties voor applicaties met veel verkeer?

Verwacht van kandidaat: De interviewer wil weten hoe u prestatieoptimalisatie en schaalbaarheid aanpakt.

Voorbeeld antwoord: “Bij mijn vorige baan optimaliseerde ik NGINX door gzip-compressie in te schakelen, workerprocessen te optimaliseren en caching voor statische content te configureren. Deze wijzigingen zorgden voor een aanzienlijke verlaging van de responstijden en de serverbelasting.”

8) Kun je uitleggen hoe NGINX omgaat met statische versus dynamische content?

Verwacht van kandidaat: De interviewer beoordeelt uw begrip van het afhandelen van aanvragen en het optimaliseren van prestaties.

Voorbeeld antwoord: “NGINX levert statische content direct en zeer efficiënt vanuit het bestandssysteem. Voor dynamische content stuurt het verzoeken door naar applicatieservers of services zoals PHP-FPM, waardoor elk onderdeel zich kan concentreren op waar het het beste in is.”

9) Hoe kunt u NGINX-configuratiewijzigingen veilig beheren en testen?

Verwacht van kandidaat: De interviewer wil inzicht krijgen in uw aanpak van betrouwbaarheid en risicobeperking.

Voorbeeld antwoord: “Ik valideer configuratiewijzigingen met behulp van het NGINX-configuratietestcommando voordat ik de service opnieuw laad. Ik voer wijzigingen ook door tijdens onderhoudsvensters en controleer de logbestanden nauwlettend na de implementatie.”

10) Beschrijf een situatie waarin u snel een NGINX-gerelateerde storing moest oplossen.

Verwacht van kandidaat: De interviewer beoordeelt uw vermogen om onder druk te presteren en effectief te communiceren tijdens incidenten.

Voorbeeld antwoord: “In mijn vorige functie deed zich een storing voor als gevolg van een verkeerd geconfigureerde upstream-service. Ik heb het probleem snel vastgesteld aan de hand van logbestanden, de configuratie teruggedraaid en de betrokkenen op de hoogte gehouden van de status totdat de service volledig was hersteld.”

Vat dit bericht samen met: