Die 50 wichtigsten Fragen und Antworten zu Nginx-Interviews (2026)

By: Bryce Leo Bryce Leo
Hours Aktualisiert

Die wichtigsten Nginx-Interviewfragen und Antworten

Die Vorbereitung auf ein Nginx-Interview erfordert Weitsicht, Klarheit und ein Verständnis dafür, wie Interviewer heutzutage praktisches Fachwissen bewerten. Nginx-Interviewfragen offenbaren fundierte Kenntnisse, Entscheidungsfähigkeit, Problemlösungskompetenz und Produktionsreife.

Diese Positionen eröffnen Karrierewege in den Bereichen Cloud-Infrastruktur, Performance Engineering und Sicherheit, wo praktische Konfigurationen von Bedeutung sind. Arbeitgeber schätzen technische Erfahrung, Fachkompetenz und Analysefähigkeiten, die durch die Arbeit in der Praxis erworben wurden.ping Berufsanfänger, Ingenieure mit mittlerer Berufserfahrung und erfahrene Fachkräfte wenden grundlegende bis fortgeschrittene Kenntnisse in Teams unter der Anleitung von Managern und Teamleitern an. Lese mehr ...

👉 Kostenloser PDF-Download: Nginx-Interviewfragen und -Antworten

Die wichtigsten Nginx-Interviewfragen und Antworten

1) Erklären Sie, was NGINX ist und warum es in der Web-Infrastruktur weit verbreitet ist.

NGINX ist ein leistungsstarker Open-Source-Webserver, der gleichzeitig als Reverse-Proxy, Load Balancer und HTTP-Cache fungiert. Er unterstützt die Protokolle HTTP, HTTPS, SMTP, POP3 und IMAP. Die Architektur basiert auf … event-driven, asynchronous model Dadurch kann NGINX Zehntausende gleichzeitige Verbindungen mit geringem Speicher- und CPU-Verbrauch verarbeiten. Diese Skalierbarkeit macht NGINX besonders geeignet für stark frequentierte Webanwendungen, Microservices und verteilte Architekturen. Beispielsweise bevorzugen Unternehmen mit hohem Datenverkehr (wie Content-Plattformen oder API-Gateways) NGINX häufig für die effiziente Verarbeitung gleichzeitiger Verbindungen und die Auslieferung statischer Inhalte.

2) Wie verarbeitet NGINX HTTP-Anfragen intern (ereignisgesteuerte Architektur)?

Die Kernstärke von NGINX liegt in seiner event-driven, non-blocking architectureAnstatt für jede Anfrage einen separaten Thread oder Prozess zu starten (wie herkömmliche Server), verwendet NGINX eine kleine Anzahl von Worker-Prozessen mit asynchronen Ereignisschleifen. Jeder Worker kann Tausende von Verbindungen verwalten, indem er auf Bereitschaftsbenachrichtigungen des Betriebssystems wartet und Ereignisse verarbeitet, sobald diese auftreten. Da NGINX nicht durch E/A-Operationen blockiert wird, kann es statische und proxied Inhalte mit minimalem Ressourcenaufwand bereitstellen. Dieses Modell ist ideal für Anwendungsfälle mit hoher Parallelität und daher unter hoher Last effizienter als prozessbasierte Server.

3) Was sind die Hauptunterschiede zwischen NGINX und Apache?

NGINX und Apache sind zwar beides beliebte Webserver, unterscheiden sich aber in Architektur, Leistung und Designzielen:

Aspekt NGINX Apache
Parallelitätsmodell Ereignisgesteuert (asynchron, nicht blockierend) Prozess- / threadbasiert (blockierend)
Memory Usage Niedrig pro Verbindung Höher pro Verbindung
besten Use Case Hoher Datenverkehr, statische Inhalte, Lastverteilung Dynamische Inhalte und ein umfangreiches Modul-Ökosystem
Skalierbarkeit Skaliert mit weniger Ressourcen Aufgrund der Prozesse wird mehr Hardware benötigt.
Modulhandhabung Module, die zur Kompilierzeit ausgewählt wurden Dynamisch zur Laufzeit

Das Design von NGINX optimiert die Leistung unter Last, während Apache mit dynamischen Modulen und breiter Sprachunterstützung mehr Flexibilität bietet.

4) Was sind die wichtigsten Bestandteile einer NGINX-Konfigurationsdatei?

Eine NGINX-Konfigurationsdatei (Standardpfad: /etc/nginx/nginx.conf) besteht aus strukturierten Direktivenblöcken, die das Verhalten von NGINX bestimmen:

  • Hauptkontext: globale Einstellungen wie z. B. worker_processes, error_log und pid
  • Ereignisblock: verwaltet Worker-Verbindungen und Multiprocessing
  • HTTP-Blockierung: Enthält Konfigurationen für die HTTP-Verarbeitung (Komprimierung, Caching, gzip usw.).
    • Serverblock: definiert virtuelle Hosts (Domänen und Ports)
    • Standortblock: Definiert Routingregeln und die Behandlung bestimmter URIs.

Diese Blöcke arbeiten zusammen, um Anfragen weiterzuleiten, Proxy-Einstellungen zu definieren und SSL/TLS sowie Caching zu konfigurieren.

5) Wie kann die NGINX-Konfiguration sicher und ohne Ausfallzeiten neu geladen werden?

Um NGINX mit aktualisierten Konfigurationen neu zu laden without interrupting active connectionsVerwenden Sie dazu folgenden Befehl:

nginx -s reload

oder auf Systemen, die systemd:

sudo systemctl reload nginx

Dieser Befehl signalisiert dem Masterprozess, die Konfigurationsdateien neu einzulesen und die Workerprozesse ordnungsgemäß neu zu starten, ohne dass es zu Paketverlusten kommt.ping Bestehende Verbindungen. Zu wissen, wie man solche nahtlosen Neuladevorgänge durchführt, ist in Umgebungen, die hohe Verfügbarkeit erfordern, unerlässlich.

6) Beschreiben Sie, wie man NGINX als Reverse-Proxy einrichtet.

Ein Reverse-Proxy leitet Client-Anfragen an Backend-Server (Upstream-Gruppe) weiter und sendet anschließend die Antwort zurück. Nachfolgend ein typischer NGINX-Reverse-Proxy-Block:

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;
        }
    }
}

Diese Konfiguration verbessert die Sicherheit, sorgt für eine gleichmäßige Lastverteilung und ermöglicht Caching- oder Ratenbegrenzungsrichtlinien zwischen Clients und Anwendungsservern.

7) Erläutern Sie die Master- und Worker-Prozesse von NGINX.

In NGINX:

  • Das Masterprozess Verwaltet die Konfiguration, startet Worker-Prozesse und führt privilegierte Operationen wie das Binden an Ports durch.
  • Arbeitsprozesse Die eigentliche Anfragebearbeitung – die Verarbeitung eingehender Verbindungen und die Ausführung konfigurierter Regeln – wird durchgeführt.

Mehrere Worker verbessern die Parallelverarbeitung und können je nach verfügbaren CPU-Kernen und Datenverkehrsaufkommen optimiert werden. Die Aufteilung der Aufgaben erhöht Leistung und Stabilität.

ÄHNLICHE ARTIKEL

8) Wie kann man die Verarbeitung undefinierter Servernamen in NGINX einschränken?

Um Anfragen ohne gültigen Eintrag zu verwerfen Host Header in NGINX:

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

Diese Konfiguration gibt folgenden Code zurück 444, ein nicht standardmäßiger NGINX-Status, der die Verbindung ohne Antwort schließt, wodurch undefinierte Hosts effektiv abgewiesen und die Sicherheit verbessert wird.

9) Wozu dient das ngx_http_upstream_module?

Das ngx_http_upstream_module definiert groups of backend servers (Upstreams), an die NGINX Anfragen mithilfe von Direktiven wie z. B. weiterleiten kann proxy_pass, fastcgi_passden uwsgi_passDies ermöglicht flexible Skalierung von Anwendungen in Load-Balancing-Umgebungen. Bei der Gruppierung mehrerer Backend-Server kann NGINX den Datenverkehr anhand definierter Richtlinien verteilen und dabei Round-Robin-Verfahren sowie andere Strategien unterstützen.

10) Beschreiben Sie, wie NGINX zum Ausliefern statischer und dynamischer Inhalte verwendet wird.

NGINX ist hocheffizient beim Bedienen von Diensten statische Dateien (HTML, CSS, Bilder) direkt unter Verwendung seiner optimierten Ereignisschleife und Datei-E/A-Mechanismen. Für dynamischer InhaltNGINX leitet Anfragen an Backend-Prozessoren wie PHP-FPM weiter. Python WSGI-Server oder Anwendungsframeworks über FastCGI/Proxy-Mechanismen. Diese Trennung ermöglicht es NGINX, als statischer Dateiserver hervorragende Leistungen zu erbringen und gleichzeitig Backend-Dienste für die dynamische Generierung zu nutzen, wodurch optimale Leistung und Skalierbarkeit gewährleistet werden.

11) Wie funktioniert Load Balancing in NGINX und welche verschiedenen Methoden stehen zur Verfügung?

NGINX bietet robuste Lastverteilung durch das upstream Direktive, die den Datenverkehr auf mehrere Backend-Server verteilt, um die Leistung zu optimieren und eine hohe Verfügbarkeit zu gewährleisten. Sie unterstützt mehrere Methoden:

Methodik Beschreibung besten Use Case
Round Robin Standardmethode, die Anfragen sequenziell zwischen den Servern rotiert. Gleichmäßig verteilte Arbeitslasten.
Wenigste Verbindungen Sendet Anfragen an den Server mit den wenigsten aktiven Verbindungen. Lang andauernde Sitzungen.
IP-Hash Die Serverauswahl erfolgt anhand der Client-IP-Adresse. Sitzungspersistenz.
Am wenigsten Zeit Die Gewichtung basiert auf Antwortzeit und Verbindungsanzahl. Latenzempfindliche Anwendungen.

NGINX kann auch Folgendes ausführen Gesundheitschecks um fehlerhafte Server dynamisch zu entfernen und so einen reibungslosen Datenfluss und Ausfallsicherheit zu gewährleisten.

12) Worin besteht der Unterschied zwischen NGINX Open Source und NGINX Plus?

NGINX Open Source ist die Community-Version, die grundlegende Webserver-, Proxy- und Load-Balancing-Funktionen bietet. NGINX Plus ist die kommerzielle Edition, die diese Funktionen um Verbesserungen auf Unternehmensebene erweitert, wie z. B. erweiterte Überwachung, Sitzungspersistenz, dynamische Rekonfiguration und aktive Integritätsprüfungen.

Funktion NGINX Open Source NGINX Plus
Load Balancing Basisverfahren (Round Robin, IP-Hash) Fortgeschritten (kürzeste Zeit, dynamische Rekonfiguration)
Überwachung Manuelle / externe Werkzeuge Integriertes Dashboard und API
Caching Plug-and-Play-Betrieb Verbesserte Spülsteuerung
Unterstützung Nur Community Unterstützung und Updates für Unternehmen

Organisationen mit geschäftskritischen Arbeitslasten entscheiden sich oft für NGINX Plus aufgrund seiner verbesserten Zuverlässigkeit und Beobachtbarkeit.

13) Wie implementiert man Caching in NGINX?

Caching in NGINX verbessert die Antwortgeschwindigkeit und reduziert die Backend-Last, indem häufig aufgerufene Inhalte lokal gespeichert werden. Es wird durch die folgende Funktion aktiviert: proxy_cache Direktive. Beispielkonfiguration:

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;
    }
}

Zwischengespeicherte Antworten werden direkt von der Festplatte ausgeliefert, wenn eine passende Anfrage eintrifft; überspringenping Upstream-Verarbeitung. Sie können den Ablauf des Caches steuern mit proxy_cache_valid und bestimmte URIs ausschließen mit proxy_no_cacheDieser Mechanismus ist für stark frequentierte Umgebungen wie Nachrichten- oder E-Commerce-Websites von entscheidender Bedeutung.

14) Erläutern Sie Zweck und Verwendung der Direktive „try_files“.

Das try_files Die Direktive prüft, ob Dateien in einer bestimmten Reihenfolge vorhanden sind, bevor eine Anfrage an den Ausweichspeicherort weitergeleitet wird. Sie wird häufig verwendet für statisches Site-Routing or Single-Page-Anwendungen (SPAs).

Ejemplo:

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

Hier prüft NGINX zunächst, ob die angeforderte URI mit einer Datei übereinstimmt, dann mit einem Verzeichnis und leitet schließlich nicht übereinstimmende Anfragen an /index.htmlDies verbessert die Effizienz und das Benutzererlebnis, indem zwischengespeicherte oder statische Dateien direkt ausgeliefert werden und unnötige Backend-Aufrufe vermieden werden.

15) Wie kann NGINX HTTPS und SSL/TLS-Terminierung handhaben?

NGINX fungiert als SSL/TLS-Terminierungsproxy und übernimmt die Ver- und Entschlüsselung auf Serverebene, bevor unverschlüsselte Anfragen an vorgelagerte Dienste weitergeleitet werden. Beispielkonfiguration:

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;
    }
}

Es unterstützt HTTP / 2, OCSP-Heften, HSTS und moderne VerschlüsselungssuitenDies ermöglicht eine sichere und leistungsstarke Kommunikation. Die Terminierung von SSL bei NGINX reduziert den Verschlüsselungsaufwand auf Backend-Servern und vereinfacht die Zertifikatsverwaltung.

16) Worin besteht der Unterschied zwischen Rewrite und Redirect in NGINX?

Beides umschreiben , umleiten Sie verändern die Art und Weise, wie Anfragen weitergeleitet werden, unterscheiden sich aber grundlegend:

Aspekt Umschreiben Umleiten
Typ Interne URL-Umschreibung Umleitung externer Clients
Antwort Code 200 (intern) 301/302 (HTTP-Weiterleitung)
Sichtbarkeit Für den Benutzer transparent Der Client sieht die neue URL
Luftüberwachung SEO-freundliche URLs, Routing Domänenmigration, HTTPS-Erzwingung

Ejemplo:

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

Das Verständnis dieses Unterschieds ist der Schlüssel zur effektiven Optimierung von SEO und Routing-Logik.

17) Wie schützt man NGINX vor häufig auftretenden Sicherheitslücken?

Die Verbesserung der IT-Sicherheit umfasst eine Kombination bewährter Verfahren:

  • Server-Token deaktivieren: server_tokens off;
  • Methoden zur Beschränkung von Anfragen: Nur GET, POST und HEAD zulassen.
  • Pufferüberläufe einschränken: Einrichtung client_max_body_size , client_body_buffer_size.
  • Verwenden Sie HTTPS mit modernen Verschlüsselungsverfahren.
  • Aktivieren Sie die Ratenbegrenzung limit_req_zone.
  • Versionsinformationen ausblenden und Verzeichnisauflistung deaktivieren.

Zusätzlich mit a Webanwendungs-Firewall (WAF) Google Trends, Amazons Bestseller ModSecurity with NGINX NGINX kann schädlichen Datenverkehr filtern. Regelmäßige Updates von NGINX und die Installation von Sicherheitspatches sind unerlässlich, um Zero-Day-Exploits zu verhindern.

18) Was sind NGINX-Variablen und wie werden sie in Konfigurationen verwendet?

NGINX-Variablen speichern dynamische Daten, die für Konfigurationen und die Protokollverarbeitung verwendet werden. Sie können Anfrageheader, Client-IP-Adressen oder berechnete Werte darstellen. Beispiele hierfür sind: $remote_addr, $host, $uri, $request_method und $upstream_addr.

Zum Beispiel:

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

Variablen erhöhen die Flexibilität und ermöglichen bedingtes Routing und benutzerdefinierte Protokollierung. Sie können auch benutzerdefinierte Variablen mithilfe von … definieren. set Direktive, die bei der Gestaltung modularer Konfigurationen hilft.

19) Wie kann man in NGINX eine Ratenbegrenzung einrichten?

Die Ratenbegrenzung steuert, wie häufig Benutzer Anfragen senden können und schützt so vor Brute-Force- und DDoS-Angriffen. Sie wird mithilfe der folgenden Konfiguration eingerichtet: limit_req_zone Richtlinie:

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

Dies ermöglicht eine Anfrage pro Sekunde mit einer Spitzenrate von fünf Anfragen. NGINX verwirft überschüssige Anfragen oder verzögert sie je nach Konfiguration. Die Ratenbegrenzung gewährleistet eine faire Ressourcennutzung und verhindert eine Serverüberlastung.

20) Was sind die Vor- und Nachteile der Verwendung von NGINX als Reverse-Proxy?

NGINX als Reverse-Proxy bietet zahlreiche Vorteile, aber auch einige Nachteile:

Vorteile Nachteile
Hohe Leistungsfähigkeit und gleichzeitige Verarbeitung Für großflächige Implementierungen ist eine manuelle Anpassung erforderlich.
SSL-Terminierung und zentralisierte Sicherheit Eingeschränkte Unterstützung dynamischer Module (Kompilierzeit)
Lastverteilung und Caching-Unterstützung Komplexe Konfiguration für neue Benutzer
Filterung auf Anwendungsebene Fehlende native dynamische Inhaltsausführung

Seine Vorteile überwiegen in den meisten Unternehmensszenarien die Einschränkungen bei Weitem, was NGINX zu einem unverzichtbaren Bestandteil moderner Webinfrastrukturen macht.

21) Wie können Sie die Leistung und den Zustand von NGINX im Produktivbetrieb überwachen?

Die Überwachung von NGINX ist entscheidend, um Engpässe, Ausfälle und ungewöhnliches Datenverkehrsverhalten zu erkennen. Hierfür können verschiedene Ansätze verwendet werden:

  1. Eingebautes Statusmodul (stub_status):

    Zeigt aktive Verbindungen, bearbeitete Anfragen und Lese-/Schreibstatus an. Beispiel:

    location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
  2. NGINX Plus Dashboard: Bietet Echtzeitmetriken über REST-API und GUI.
  3. Integrationen von Drittanbietern: Tools wie Prometheus, Grafana, Datadog oder ELK können Metriken und Protokolle sammeln.
  4. Zugriffs- und Fehlerprotokolle: Regelmäßige Logrotation und -analyse mit Tools wie GoAccess oder AWStats verbessern die Beobachtbarkeit.

Die Überwachung trägt zur Sicherstellung der Betriebszeit, zur schnellen Erkennung von Fehlern und zur Kapazitätsplanung bei.

22) Worin besteht der Unterschied zwischen den Direktiven proxy_pass und fastcgi_pass?

Beide Direktiven leiten Anfragen an Backend-Dienste weiter, sind aber für unterschiedliche Protokolle ausgelegt:

Direktive Zweck Backend-Protokoll Beispielanwendung
proxy_pass Leitet HTTP- oder HTTPS-Anfragen an Backend-Server weiter. HTTP Reverse proxying web APIs or microservices
fastcgi_pass Sendet Anfragen an einen FastCGI-Prozessor. SchnellCGI PHP-FPM, Python FastCGI-Anwendungen

Ejemplo:

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

Zusammenfassend verwenden Proxy_pass für generische HTTP-Backends und fastcgi_pass für dynamische Sprachlaufzeitumgebungen wie PHP.

23) Wie kann man die gzip-Komprimierung in NGINX konfigurieren und welche Vorteile bietet sie?

Durch die Aktivierung der Gzip-Komprimierung in NGINX wird die Bandbreitennutzung reduziert und die Ladezeit verbessert, indem textbasierte Antworten vor dem Senden an die Clients komprimiert werden.

Beispielkonfiguration:

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

Vorteile:

  • Reduziert die Dateiübertragungsgrößen um bis zu 70 %.
  • Verbessert die Time-to-First-Byte (TTFB) und die Seitenleistung.
  • Spart Bandbreitenkosten, was insbesondere für mobile Nutzer von Vorteil ist.

Dies sollte jedoch nicht auf bereits komprimierte Dateien angewendet werden (z. B. .zip, .jpg, .png) um CPU-Overhead zu vermeiden.

24) Was sind einige bewährte Vorgehensweisen zur Optimierung von NGINX für hohes Datenaufkommen?

Die Optimierung bei hohem Datenverkehr erfordert eine sorgfältige Abstimmung der Ressourcen und Konfigurationsparameter:

Gebiet Direktive Empfohlene Praxis
Arbeitskräfte worker_processes auto; CPU-Kerne anpassen
Verbindungen worker_connections 4096; Gleichzeitigkeit erhöhen
Bleib am Leben keepalive_timeout 65; Optimierung der Kundenwiederverwendung
Reichen Sie das DescriptGolde OS ulimit -n Grenzwerte für offene Steckdosen erhöhen
Caching proxy_cache_path Backend-Last reduzieren
Gzip gzip on; Textantworten komprimieren

Darüber hinaus verwenden Sie asynchrone Festplatten-E/A, Lastverteilung und Gesundheitsprüfungen im Upstreambereich gewährleistet Stabilität und Geschwindigkeit auch bei einer massiven Anzahl gleichzeitiger Anfragen.

25) Wie handhabt NGINX WebSocket-Verbindungen?

WebSockets ermöglichen die bidirektionale Kommunikation zwischen Client und Server – unerlässlich für Echtzeitanwendungen. NGINX unterstützt dies nativ durch entsprechendes Header-Forwarding.

Beispielkonfiguration:

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

Die wichtigsten Punkte:

  • Das Upgrade , Connection Header sind obligatorisch.
  • Stellen Sie sicher, dass NGINX HTTP/1.1 für persistente TCP-Verbindungen verwendet.
  • Für den Lastausgleich von WebSockets können Sticky Sessions erforderlich sein. ip_hash.

Diese Konfiguration unterstützt Anwendungen wie Chat, Aktienhandel oder Spiele.

26) Welchen Zweck hat die Direktive „worker_rlimit_nofile“?

worker_rlimit_nofile Definiert die maximale Anzahl offener Dateideskriptoren, die für Workerprozesse verfügbar sind. Diese Grenze beeinflusst direkt, wie viele gleichzeitige Verbindungen NGINX verarbeiten kann. Beispiel:

worker_rlimit_nofile 100000;

Die Anhebung dieses Grenzwerts ist für Systeme mit hoher Parallelität (wie API-Gateways oder Streaming-Plattformen) unerlässlich. Allerdings ist der Grenzwert des Betriebssystems (ulimit -n) muss aus Gründen der Konsistenz ebenfalls erhöht werden, um diesem Wert zu entsprechen.

27) Wie kann NGINX für das automatische Umschreiben von URLs oder die automatische Weiterleitung auf HTTPS verwendet werden?

Die Umleitung von HTTP auf HTTPS gewährleistet eine sichere Kommunikation. Beispiel:

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

Diese Konfiguration gibt ein Problem aus 301 permanente Weiterleitung von HTTP zu HTTPS. Für eine feinere Steuerung können Rewrite-Regeln eine pfadspezifische Umleitung erzwingen:

rewrite ^/oldpath$ /newpath permanent;

Die automatische HTTPS-Erzwingung verbessert das SEO-Ranking, verhindert Man-in-the-Middle-Angriffe und gewährleistet ein einheitliches Benutzererlebnis.

28) Was sind einige häufige Gründe für „502 Bad Gateway“-Fehler in NGINX?

Die Fehlermeldung „502 Bad Gateway“ bedeutet, dass NGINX als Proxy keine gültige Antwort von einem Upstream-Server empfangen hat. Häufige Ursachen sind:

  • Backend-Serverausfall oder Nichtverfügbarkeit.
  • Falsch proxy_pass URL oder Socket-Pfad.
  • Upstream-Timeout (proxy_read_timeout zu niedrig).
  • Firewall oder SELinux blockieren Upstream-Verbindungen.
  • Falsch konfigurierte FastCGI-Parameter (für PHP).

Zur Fehlersuche sollten Sie die Fehlerprotokolle überprüfen (/var/log/nginx/error.log), die Erreichbarkeit der vorgelagerten Systeme zu überprüfen und Backend-Antworten direkt zu testen über curl.

29) Wie unterstützt NGINX Microservices und containerbasierte Architekturen (z. B. Docker, Kubernetes)?

NGINX ist ideal für Microservice-Umgebungen Aufgrund seines schlanken Designs und seiner Reverse-Proxy-Funktionalität dient es in Docker oder Kubernetes als:

  • Ingress-Controller: Verwaltet den externen HTTP/S-Datenverkehr zu internen Diensten.
  • Service-Gateway: Führt Routing, Lastausgleich und Authentifizierung durch.
  • Sidecar-Proxy: Verbessert die Ausfallsicherheit und Beobachtbarkeit in Service-Meshes (z. B. Istio).

NGINX-Konfigurationen lassen sich dynamisch über Kubernetes ConfigMaps aktualisieren, was eine zentrale Steuerung des Datenverkehrs und die SSL-Verwaltung ermöglicht. Der modulare Ansatz eignet sich ideal für containerisierte und Cloud-native Bereitstellungen.

30) Welche verschiedenen Möglichkeiten gibt es, die Sicherheit von NGINX für Produktionssysteme zu verbessern?

Die Verbesserung der NGINX-Sicherheit erfordert eine mehrschichtige Konfiguration:

  1. SSL/TLS-Härtung: Verwenden Sie moderne Verschlüsselungsverfahren, deaktivieren Sie SSLv3/TLSv1.0.
  2. Beschränkung der HTTP-Methoden: Nur sichere Verben (GET, POST, HEAD) zulassen.
  3. Sicherheitsheader: 
    add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
  4. Versionsinformationen ausblenden: server_tokens off;
  5. Ratenbegrenzung und Zugriffskontrollen aktivieren.
  6. WAF oder Fail2Ban integrieren zur Verhinderung von Brute-Force-Angriffen.

Zusammengenommen schaffen diese Maßnahmen eine gehärtete, produktionsreife NGINX-Umgebung, die resistent gegen gängige Angriffe ist.

31) Wie lassen sich NGINX-Probleme effektiv beheben?

Die Fehlersuche in NGINX erfordert die systematische Analyse von Protokollen, Konfigurationsdateien und Prozesszuständen. Zu den wichtigsten Schritten gehören:

  1. Syntax prüfen:
    2. nginx -t
  2. Überprüft die Konfiguration vor dem Neuladen.

    3. Debug-Protokollierung aktivieren:

    error_log /var/log/nginx/error.log debug;
  3. Bietet detaillierte Laufzeitdiagnose.

    4. Zugriffsprotokolle analysieren: Erkennen von Antwortcodes und Anfragemustern mithilfe von:

    tail -f /var/log/nginx/access.log
  4. Konnektivität testen: Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen, curl -v or wget um die Erreichbarkeit des Backends zu überprüfen.
  5. Aktive Verbindungen überwachen: Über stub_status or netstat.

Das Verständnis der Worker-Prozesse, Puffergrenzen und Upstream-Reaktionen von NGINX hilft dabei, Engpässe in Produktionssystemen schnell zu lokalisieren.

32) Wie konfiguriert man die NGINX-Protokollierung, und was sind benutzerdefinierte Protokollformate?

NGINX bietet flexible Protokollierungsmechanismen durch access_log , error_log Richtlinien.

Beispielkonfiguration:

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;

Sie können definieren benutzerdefinierte Formate einschließlich Kennzahlen wie $upstream_addr, $request_timeden $bytes_sent.

Für eine erweiterte Beobachtbarkeit werden Protokolle häufig an folgende Adresse gesendet: ELK, Loki oder Splunk für Echtzeitanalysen und Dashboards.

33) Welche Rolle spielt die Direktive proxy_buffering in NGINX?

proxy_buffering Steuert, ob NGINX Antworten von Upstream-Servern puffert, bevor sie an Clients gesendet werden.

Rahmen Beschreibung Luftüberwachung
proxy_buffering on; Buffers die gesamte Antwort für optimierten Durchsatz Standardeinstellung; verbessert die Leistung
proxy_buffering off; Streamt Daten direkt an Clients ohne Pufferung Echtzeit-Streaming oder APIs

Zum Beispiel zum Deaktivieren der Pufferung:

location /stream/ {
    proxy_buffering off;
}

Das Deaktivieren des Pufferns ist ideal für Chat- oder Streaming-Dienste, kann aber den Durchsatz bei normalem Webverkehr verringern.

34) Erläutern Sie, wie der NGINX-Caching ungültig gemacht oder gelöscht werden kann.

NGINX Open Source beinhaltet keine integrierte Cache-Bereinigung, diese kann jedoch auf verschiedene Arten erreicht werden:

  1. Manuelle Spülung: Dateien aus dem Cache-Verzeichnis entfernen. 
    rm -rf /var/cache/nginx/*
  2. Drittanbietermodul: Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen, ngx_cache_purge zum Löschen per HTTP-Anfrage: 
    location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
  3. NGINX Plus-Funktion: Ermöglicht die dynamische Cache-Bereinigung über die API.

Durch das Bereinigen wird sichergestellt, dass veraltete Inhalte umgehend ersetzt werden, wodurch die Aktualität und Konsistenz der Inhalte über CDN- oder Multi-Node-Bereitstellungen hinweg erhalten bleibt.

35) Wie geht NGINX mit Verbindungs-Timeouts um?

NGINX bietet mehrere Timeout-Direktiven, um zu steuern, wie lange auf Client- oder Upstream-Antworten gewartet wird:

Direktive Zweck Standard(s)
client_body_timeout Wartezeit für den Kunden 60
client_header_timeout Wartezeit für Client-Header 60
keepalive_timeout Leerlauf-Keepalive-Verbindungen 75
send_timeout Zeit, Daten an den Kunden zu senden 60
proxy_read_timeout Wartezeit für die Antwort des vorgelagerten Systems 60

Durch die richtige Konfiguration werden unnötige Verbindungsabbrüche vermieden und ein reibungsloseres Benutzererlebnis unter variablen Netzwerkbedingungen gewährleistet.

36) Wie implementiert man Blue-Green-Deployment mit NGINX?

Kurz und Blau-Grün-BereitstellungZwei Umgebungen (Blau = aktiv, Grün = Standby) laufen gleichzeitig. NGINX fungiert als Datenverkehrsrouter zwischen ihnen.

Beispielkonfiguration:

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

Wenn die neue Version (Grün) getestet und verifiziert ist, wird der Datenverkehr durch Aktualisieren der Upstream-Definition und Neuladen von NGINX umgeschaltet (nginx -s reload).

Diese Methode stellt sicher Keine Ausfallzeit während Anwendungsaktualisierungen oder Rollbacks.

37) Was versteht man unter Rate Limiting Burst, und wie verbessert es die Leistung von NGINX?

Das Burst Ein Parameter zur Ratenbegrenzung ermöglicht es, kurze Verkehrsspitzen vorübergehend durchzulassen, ohne sie sofort zurückzuweisen.

Ejemplo:

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

Hier werden fünf zusätzliche Anfragen sofort akzeptiert, bevor die Drosselung angewendet wird.

Diese Technik gleicht Verkehrsspitzen aus und gewährleistet ein gleichbleibendes Nutzererlebnis, ohne die Backend-Systeme zu überlasten.

38) Wie geht NGINX mit IPv6 und Dual-Stack-Umgebungen um?

NGINX unterstützt IPv6 vollständig sowohl in Server- als auch in Upstream-Konfigurationen. Beispiel:

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

Dual-Stack-Unterstützung (IPv4 + IPv6) wird durch die Einbindung beider Protokolle erreicht:

listen 80;
listen [::]:80;

Die IPv6-Kompatibilität gewährleistet eine breitere Zugänglichkeit, insbesondere für mobile und internationale Clients, und ist für die Einhaltung moderner Internetstandards von entscheidender Bedeutung.

39) Wie konfiguriert man Sticky Sessions im NGINX Load Balancing?

Sticky Sessions gewährleisten, dass Anfragen desselben Clients immer an denselben Backend-Server weitergeleitet werden.

  1. Die Verwendung von ip_hash: 
    upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}
  2. NGINX Plus Sticky Cookie:
    Erweiterte Sitzungsspeicherung mit konfigurierbaren Cookies.

Sticky Sessions sind für zustandsbehaftete Anwendungen wie Benutzer-Dashboards oder Shop-Systeme unerlässlich.ping Warenkorbsysteme, die die Konsistenz der Sitzungsdaten ohne gemeinsamen Speicher gewährleisten.

40) Was sind die wichtigsten Protokollierungsebenen in NGINX und wie unterscheiden sie sich?

NGINX unterstützt hierarchische Protokollierungsstufen, um die Ausführlichkeit des Fehlerprotokolls zu steuern.

Niveau Beschreibung
debug Detaillierte Informationen zur Fehlerbehebung (sehr ausführlich)
info Allgemeine Laufzeitinformationen
notice Bedeutende, aber nicht kritische Ereignisse
warn Mögliche Probleme oder Fehlkonfigurationen
error OperaIrrtümer, die Aufmerksamkeit erfordern
crit, alert, emerg Kritische Ausfälle und Systemwarnungen

Beispielkonfiguration:

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

Durch die Anpassung der Protokollierungsstufen an die jeweilige Umgebung (Debug-Protokollierung in der Staging-Umgebung, Warnungsprotokollierung in der Produktionsumgebung) wird ein Gleichgewicht zwischen Transparenz und Leistungsfähigkeit gewahrt.

41) Wie messen Sie die Leistung von NGINX?

Das Benchmarking von NGINX umfasst die Messung von Durchsatz, Latenz und Parallelität, um Konfigurationsengpässe zu identifizieren. Gängige Tools sind:

ApacheBench (ab):

ab -n 10000 -c 100 http://example.com/
  • Tests erfordern hohes Testvolumen und gleichzeitige Anforderungen.
  • Arbeit: Liefert detaillierte Latenz-Perzentile und Anfrageraten.
  • Belagerung / httperf: Simuliert die Verkehrslast in der realen Welt.
  • Grafana + Prometheus: Überwacht Live-Leistungskennzahlen.

Beim Benchmarking sollten Parameter wie die folgenden gemessen werden: requests per second (RPS), time per request und error rate.

Abstimmungsvariablen wie worker_processes, worker_connections und keepalive_timeout verbessert den beobachteten Durchsatz signifikant.

42) Wie lässt sich NGINX in CI/CD-Pipelines integrieren?

NGINX integriert sich nahtlos mit CI / CD für die automatisierte Bereitstellung, das Testen und die Konfigurationsverwaltung. Gängige Ansätze sind:

  • Infrastruktur als Code (IaC): Konfigurationen lassen sich mit Ansible-, Terraform- oder Helm-Charts verwalten.
  • Docker-Container: NGINX-Images mit CI-Tools (Jenkins, GitLab CI oder GitHub Actions) erstellen und bereitstellen.
  • Automatisierte Tests: Konfigurationen validieren mit nginx -t in den jeweiligen Pipeline-Phasen.
  • Blaugrün / Canary Bereitstellungsautomatisierung: Die Upstream-Server werden während des Rollouts dynamisch aktualisiert.

Beispielhafter GitLab CI-Codeausschnitt:

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

Die automatisierte Bereitstellung gewährleistet konsistente, versionskontrollierte und zuverlässige NGINX-Rollouts.

43) Erläutern Sie die Rolle des NGINX Ingress Controllers in Kubernetes.

Das NGINX-Ingress-Controller Verwaltet den eingehenden Datenverkehr zu Kubernetes-Diensten. Es übersetzt Kubernetes-Ingress-Ressourcen dynamisch in NGINX-Konfigurationen.

Zentrale Funktionen:

  • Leitet HTTP/S-Anfragen an den richtigen Dienst weiter.
  • Bietet SSL-Terminierung, Ratenbegrenzung und URL-Umschreibung.
  • Unterstützt Lastverteilung über Pods hinweg.
  • Ermöglicht die Verwendung von Annotationen für eine detaillierte Steuerung (z. B. rewrite-target, proxy-body-size).

Beispiel für 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

Diese Architektur entkoppelt die Logik des Datenverkehrsroutings von den Containerbereitstellungen, um eine flexible Skalierbarkeit zu gewährleisten.

44) Wie handhabt NGINX HTTP/2 und welche Vorteile bietet es?

NGINX unterstützt dies vollständig. HTTP / 2, der Nachfolger von HTTP/1.1, der die Effizienz durch Multiplexing und Header-Komprimierung verbessert.

So aktivieren Sie HTTP/2:

server {
    listen 443 ssl http2;
    ...
}

Vorteile:

Funktion Beschreibung
Multiplexing Mehrere Anfragen pro TCP-Verbindung
Header-Komprimierung (HPACK) Reduziert die Bandbreitennutzung
Server-Push Sendet Vermögenswerte proaktiv an Kunden
Schnelleres TLS Optimierte, sichere Händedrücke

HTTP/2 reduziert Latenz und Seitenladezeiten drastisch, insbesondere bei modernen Webanwendungen mit zahlreichen Ressourcen.

45) Worin besteht der Unterschied zwischen Upstream-Keepalive und Verbindungswiederverwendung in NGINX?

Upstream-Keepalive Hält dauerhafte Verbindungen zu Backend-Servern aufrecht und reduziert so den TCP-Handshake-Overhead. Beispiel:

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

Unterschied:

Aspekt Bleib am Leben Verbindungswiederverwendung
Geltungsbereich Zwischen NGINX und Upstream Zwischen NGINX und Clients
Zweck Backend-Optimierung Frontend-Performance
Konfiguration keepalive innerhalb upstream keepalive_timeout in server Schutzmassnahmen bei

Beide Techniken reduzieren die Latenz, bedienen aber unterschiedliche Kommunikationsschichten (Clientseite vs. Serverseite).

46) Wie kann man NGINX dynamisch rekonfigurieren, ohne es neu zu starten?

Neue Konfigurationen dynamisch anwenden ohne Ausfallzeiten, Verwenden Sie die reload Mechanismus:

nginx -t && nginx -s reload

Dies signalisiert die Masterprozess Neue Worker mit aktualisierten Konfigurationen zu starten und gleichzeitig alte Worker ordnungsgemäß herunterzufahren.

In NGINX Plus können Änderungen vorgenommen werden. über API (z. B. dynamisches Hinzufügen von Upstream-Servern):

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"}'

Diese Funktion unterstützt Bereitstellungen ohne Ausfallzeiten in modernen DevOps-Pipelines.

47) Was sind die wichtigsten Unterschiede zwischen Reverse-Proxy und Forward-Proxy in NGINX?

Aspekt Reverse Proxy Weiterleitungs-Proxy
Kundensichtbarkeit Clients, die keine Kenntnis von den Backend-Servern haben Server, die die Identität des Clients nicht kennen
Hauptnutzen Lastverteilung, Caching, SSL-Terminierung Filterung, Anonymität, Zugriffskontrolle
Häufiger Anwendungsfall Web-Traffic-Verteilung Unternehmensinternes oder sicheres ausgehendes Surfen
NGINX-Unterstützung Einheimisch und weit verbreitet Erfordert eine benutzerdefinierte Konfiguration

Beispiel (Forward-Proxy):

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

RevDas Proxying bleibt der dominierende Anwendungsfall, insbesondere für API-Gateways und Microservice-Architekturen.

48) Wie kann NGINX zur Begrenzung und Drosselung von API-Raten eingesetzt werden?

Die Ratenbegrenzung schützt APIs vor Missbrauch und gewährleistet eine faire Nutzung. Beispielkonfiguration:

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;
    }
}

Mechanismus:

  • limit_req_zone: Definiert die gemeinsam genutzte Speicherzone und die Speicherrate.
  • burst: Ermöglicht begrenzte, vorübergehende Spitzenwerte.
  • nodelaySetzt die Beschränkungen sofort durch.

Diese Konfiguration gewährleistet, dass jede Client-IP nur 10 Anfragen pro Sekunde stellen kann, erlaubt aber kurze Anfragespitzen.

49) Was sind die typischen Anwendungsfälle von NGINX in DevOps-Umgebungen von Unternehmen?

In DevOps-Ökosystemen von Unternehmen erfüllt NGINX mehrere wichtige Rollen:

  1. Webserver: Hochleistungsfähige Auslieferung statischer Inhalte.
  2. Reverse Proxy / Load Balancer: Verkehrsmanagement über Microservices hinweg.
  3. API-Gateway: Authentifizierung, Routing und Drosselung.
  4. Ingress-Controller: Für Kubernetes-Cluster.
  5. Inhalts-Caching-Schicht: Reduziert die Backend-Last.
  6. SSL-Terminierungsendpunkt: Zentralisierte Zertifikatsverwaltung.
  7. Überwachungsendpunkt: Integration von Metriken und Observability.

Dank seines geringen Ressourcenbedarfs und seines modularen Designs ist NGINX in CI/CD-Pipelines, Hybrid-Clouds und Hochverfügbarkeitsclustern unverzichtbar.

50) Was sind die Hauptunterschiede zwischen NGINX und HAProxy beim Lastausgleich?

Beide sind Hochleistungs-Loadbalancer, unterscheiden sich aber in ihrem Fokus und ihrer Architektur:

Funktion NGINX HAProxy
Hauptrolle Webserver + Reverse-Proxy Dedizierter TCP/HTTP-Loadbalancer
Einfache Konfiguration Einfacher für webbasierte Workloads Komplexe, aber feinere Steuerung
Layer-Unterstützung L7 (HTTP), partielles L4 L4 & L7 voll
Dynamische Rekonfiguration Eingeschränkt (Open-Source) Native Laufzeitaktualisierungen
Leistung Hervorragend geeignet für gemischte Arbeitslasten Hervorragend geeignet für die Rohlastverteilung
Zusätzliche Funktionen Zwischenspeicherung, Komprimierung, statischer Inhalt Gesundheitschecks, Tische mit Stöcken

Unternehmen kombinieren häufig NGINX (Frontend) , HAProxy (Backend) für optimale Routenplanung und Skalierbarkeit.

🔍 Die wichtigsten NGINX-Interviewfragen mit realen Szenarien und strategischen Antworten

1) Was ist NGINX und warum wird es häufig in Produktionsumgebungen eingesetzt?

Vom Kandidaten erwartet: Der Interviewer möchte Ihre grundlegenden Kenntnisse von NGINX und Ihr Verständnis für dessen praktischen Nutzen in realen Systemen beurteilen.

Beispielantwort: „NGINX ist ein leistungsstarker Webserver und Reverse-Proxy, der für seine ereignisgesteuerte Architektur bekannt ist. Er wird häufig in Produktionsumgebungen eingesetzt, da er eine große Anzahl gleichzeitiger Verbindungen effizient verarbeiten kann und dabei weniger Systemressourcen verbraucht als herkömmliche Webserver.“

2) Können Sie den Unterschied zwischen NGINX und Apache erklären?

Vom Kandidaten erwartet: Der Interviewer beurteilt Ihre Fähigkeit, Technologien zu vergleichen und anhand von Anwendungsfällen das richtige Werkzeug auszuwählen.

Beispielantwort: „NGINX verwendet eine asynchrone, nicht-blockierende Architektur, wodurch es bei hohem Datenverkehr und statischen Inhalten effizienter ist. Apache verwendet ein prozessorientiertes Modell, das flexibler für dynamische Konfigurationen sein kann, aber unter hoher Last mehr Ressourcen verbrauchen kann.“

3) Wie fungiert NGINX als Reverse-Proxy?

Vom Kandidaten erwartet: Der Interviewer möchte sich vergewissern, dass Sie die Konzepte des Reverse-Proxys verstehen und wissen, wie NGINX in moderne Architekturen passt.

Beispielantwort: „NGINX fungiert als Reverse-Proxy, indem es Client-Anfragen empfängt und an Backend-Server weiterleitet. Anschließend sendet es die Serverantworten an den Client zurück, was die Sicherheit, die Lastverteilung und die Gesamtleistung verbessert.“

4) Beschreiben Sie eine Situation, in der Sie NGINX für den Lastausgleich verwendet haben.

Vom Kandidaten erwartet: Der Interviewer sucht nach praktischen Erfahrungen und Ihrer Fähigkeit, NGINX-Funktionen in realen Szenarien anzuwenden.

Beispielantwort: „In meiner vorherigen Position habe ich NGINX so konfiguriert, dass der Datenverkehr mithilfe von Round-Robin- und Least-Connections-Algorithmen auf mehrere Anwendungsserver verteilt wird. Dieser Ansatz verbesserte die Anwendungsverfügbarkeit und verhinderte, dass ein einzelner Server zum Flaschenhals wird.“

5) Wie handhaben Sie die SSL- und HTTPS-Konfiguration in NGINX?

Vom Kandidaten erwartet: Der Interviewer möchte Ihr Verständnis von Best Practices im Bereich IT-Sicherheit und Konfigurationsmanagement beurteilen.

Beispielantwort: „In meiner vorherigen Position habe ich SSL konfiguriert, indem ich Zertifikate installiert, HTTPS-Listener aktiviert und starke Verschlüsselungssammlungen erzwungen habe. Außerdem habe ich die HTTP-zu-HTTPS-Umleitung implementiert, um eine sichere Kommunikation über alle Endpunkte hinweg zu gewährleisten.“

6) Welche Schritte würden Sie unternehmen, um einen 502 Bad Gateway-Fehler in NGINX zu beheben?

Vom Kandidaten erwartet: Der Interviewer testet Ihre Problemlösungsfähigkeiten und Ihre Vorgehensweise bei der Fehlersuche.

Beispielantwort: „Ich würde zunächst die NGINX-Fehlerprotokolle überprüfen, um Probleme mit der Backend-Verbindung zu identifizieren. Anschließend würde ich sicherstellen, dass die Upstream-Server laufen, die korrekten Proxy-Einstellungen bestätigen und die Timeouts ordnungsgemäß konfiguriert sind.“

7) Wie optimiert man die NGINX-Performance für Anwendungen mit hohem Datenverkehr?

Vom Kandidaten erwartet: Der Interviewer möchte wissen, wie Sie an die Leistungsoptimierung und Skalierbarkeit herangehen.

Beispielantwort: „In meinem vorherigen Job habe ich NGINX optimiert, indem ich die gzip-Komprimierung aktiviert, die Worker-Prozesse angepasst und das Caching für statische Inhalte konfiguriert habe. Diese Änderungen haben die Antwortzeiten und die Serverlast deutlich reduziert.“

8) Können Sie erklären, wie NGINX mit statischen und dynamischen Inhalten umgeht?

Vom Kandidaten erwartet: Der Interviewer prüft Ihr Verständnis für die Bearbeitung von Anfragen und die Leistungsoptimierung.

Beispielantwort: „NGINX liefert statische Inhalte direkt und sehr effizient aus dem Dateisystem aus. Dynamische Inhalte werden hingegen an Anwendungsserver oder Dienste wie PHP-FPM weitergeleitet, sodass sich jede Komponente auf ihre Kernaufgaben konzentrieren kann.“

9) Wie verwaltet und testet man NGINX-Konfigurationsänderungen sicher?

Vom Kandidaten erwartet: Der Interviewer möchte Ihre Herangehensweise an Zuverlässigkeit und Risikominderung verstehen.

Beispielantwort: „Ich überprüfe Konfigurationsänderungen mithilfe des NGINX-Konfigurationstestbefehls, bevor ich den Dienst neu lade. Außerdem wende ich Änderungen während Wartungsfenstern an und überwache die Protokolle nach der Bereitstellung genau.“

10) Beschreiben Sie eine Situation, in der Sie einen NGINX-bedingten Ausfall schnell beheben mussten.

Vom Kandidaten erwartet: Der Interviewer beurteilt Ihre Fähigkeit, unter Druck zu arbeiten und in Krisensituationen effektiv zu kommunizieren.

Beispielantwort: „In meiner letzten Position kam es aufgrund einer Fehlkonfiguration eines vorgelagerten Dienstes zu einem Ausfall. Ich identifizierte das Problem schnell anhand von Protokollen, setzte die Konfiguration zurück und informierte die Beteiligten über den Status, bis der vollständige Dienst wiederhergestellt war.“

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: