A 50 legjobb Nginx-interjú kérdés és válasz (2026)

Egy Nginx interjúra való felkészülés előrelátást, tisztánlátást és annak ismeretét igényli, hogy az interjúztatók hogyan értékelik a valós operatív tudást napjainkban. Az Nginx interjúkérdések feltárják a mélységet, a döntéshozatali képességet, a hibaelhárítási képességet és a termelési felkészültséget.

Ezek a szerepkörök utat nyitnak a felhőinfrastruktúra, a teljesítménytervezés és a biztonság területén, ahol a gyakorlati konfigurációk számítanak. A munkáltatók nagyra értékelik a műszaki tapasztalatot, a szakterületi szakértelmet és a terepen végzett munka során szerzett elemzéseket, segítve a pályakezdőket, a középszintű mérnököket és a tapasztalt szakembereket az alapvető és haladó készségek alkalmazásában a csapatokon belül, vezetők és csapatvezetők irányítása alatt. Olvass tovább…

👉 Ingyenes PDF letöltés: Nginx interjúkérdések és válaszok

A legfontosabb Nginx interjúkérdések és válaszok

1) Magyarázd el, mi az NGINX, és miért használják széles körben a webes infrastruktúrában.

Az NGINX egy nagy teljesítményű, nyílt forráskódú webszerver, amely fordított proxyként, terheléselosztóként és HTTP gyorsítótárként is funkcionál. Támogatja a HTTP, HTTPS, SMTP, POP3 és IMAP protokollokat. Az architektúra egy event-driven, asynchronous model amely lehetővé teszi több tízezer egyidejű kapcsolat kezelését alacsony memória- és CPU-használat mellett. Ez a skálázhatóság különösen alkalmassá teszi az NGINX-et nagy forgalmú webalkalmazásokhoz, mikroszolgáltatásokhoz és elosztott architektúrákhoz. Például a nagy forgalmú munkaterheléssel rendelkező vállalatok (például tartalomplatformok vagy API-átjárók) gyakran az NGINX-et részesítik előnyben az egyidejű kapcsolatok és a statikus tartalomszolgáltatás hatékony kezeléséhez.

2) Hogyan kezeli az NGINX belsőleg a HTTP kéréseket (eseményvezérelt architektúra)?

Az NGINX fő erőssége abban rejlik, hogy event-driven, non-blocking architectureAhelyett, hogy minden kéréshez külön szálat vagy folyamatot indítana (mint a hagyományos szervereken), az NGINX kis számú munkafolyamatot használ, amelyek aszinkron eseményhurkokat használnak. Minden munkafolyamat több ezer kapcsolatot képes kezelni azáltal, hogy az operációs rendszer készenléti értesítéseire vár, és az eseményeket azok bekövetkezésekor feldolgozza. Mivel nem blokkolja az I/O műveleteket, az NGINX minimális erőforrásokkal képes statikus és proxyn keresztüli tartalmat kiszolgálni. Ez a modell ideális nagy párhuzamos használati esetekhez, így hatékonyabb, mint a folyamatalapú szerverek nagy terhelés alatt.

3) Melyek a főbb különbségek az NGINX és az Apache között?

Bár mind az NGINX, mind az Apache népszerű webszerverek, architektúrájukban, teljesítményükben és tervezési céljaikban különböznek:

Aspect	nginx	Apache
Egyidejűségi modell	Eseményvezérelt (aszinkron, nem blokkoló)	Folyamat-/szálalapú (blokkoló)
Memóriahasználat	Alacsony kapcsolatonként	Kapcsolatonként magasabb
Legjobb használati eset	Nagy forgalom, statikus tartalom, terheléselosztás	Dinamikus tartalom és gazdag modul ökoszisztéma
skálázhatóság	Kevesebb erőforrással skálázható	A folyamatok miatt több hardvert igényel
Modulkezelés	Fordítási időben kiválasztott modulok	Dinamikus futásidejű

Az NGINX kialakítása optimalizálja a teljesítményt terhelés alatt, míg az Apache nagyobb rugalmasságot biztosít dinamikus modulokkal és széleskörű nyelvi támogatással.

4) Melyek egy NGINX konfigurációs fájl fő összetevői?

Egy NGINX konfigurációs fájl (alapértelmezett elérési út: /etc/nginx/nginx.conf) strukturált direktívablokkokból áll, amelyek meghatározzák az NGINX viselkedését:

Fő kontextus: globális beállítások, mint például worker_processes, error_logés pid
Eseményblokk: kezeli a munkavállalói kapcsolatokat és a többfeldolgozást
HTTP blokk: HTTP-kezelési konfigurációkat tartalmaz (tömörítés, gyorsítótárazás, gzip stb.)
- Szerverblokk: virtuális hosztokat (tartományokat és portokat) definiál
- Helyszínblokk: meghatározza az útválasztási szabályokat és az egyes URI-k kezelésének módját

Ezek a blokkok együttműködve irányítják a kéréseket, definiálják a proxy beállításokat, valamint konfigurálják az SSL/TLS-t és a gyorsítótárat.

5) Hogyan lehet biztonságosan újratölteni az NGINX konfigurációt leállás nélkül?

Az NGINX újratöltése frissített konfigurációkkal without interrupting active connections, a következő parancsot használod:

nginx -s reload

vagy olyan rendszereken, amelyek systemd:

sudo systemctl reload nginx

Ez a parancs jelzi a fő folyamatnak, hogy olvassa újra a konfigurációs fájlokat, és indítsa újra a munkafolyamatokat a meglévő kapcsolatok megszakítása nélkül. Az ilyen zökkenőmentes újratöltések végrehajtásának ismerete elengedhetetlen a magas rendelkezésre állást igénylő környezetekben.

6) Írja le, hogyan lehet beállítani az NGINX-et fordított proxyként.

Egy fordított proxy továbbítja a klienskéréseket a háttérszervereknek (upstream csoport), majd visszaadja a választ. Az alábbiakban egy tipikus NGINX fordított proxy blokk látható:

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

Ez a beállítás javítja a biztonságot, terheléselosztást biztosít, és lehetővé teszi a gyorsítótárazási vagy sebességkorlátozó szabályzatok alkalmazását a kliensek és az alkalmazáskiszolgálók között.

7) Magyarázza el az NGINX Master és Worker folyamatait.

Az NGINX-ben:

A Fő folyamat kezeli a konfigurációt, elindítja a munkafolyamatokat, és kezeli a privilegizált műveleteket, például a portokhoz való kötést.
Munkavégző folyamatok elvégzi a tényleges kéréskezelést – a bejövő kapcsolatok feldolgozását és a konfigurált szabályok végrehajtását.

Több worker használata javítja a párhuzamos működést, és a rendelkezésre álló CPU-magok és a forgalmi igények alapján hangolható. A szerepkörök felosztása fokozza a teljesítményt és a stabilitást.

8) Hogyan korlátozható a nem definiált szervernevek feldolgozása NGINX-ben?

Érvényes adatok nélküli kérelmek elvetése Host fejléc az NGINX-ben:

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

Ez a konfiguráció kódot ad vissza 444, egy nem szabványos NGINX állapot, amely válasz nélkül lezárja a kapcsolatot, gyakorlatilag elutasítva a nem definiált gazdagépeket és javítva a biztonságot.

9) Mire használják az ngx_http_upstream_module-t?

A ngx_http_upstream_module határozza meg groups of backend servers (upstreamek), amelyeknek az NGINX olyan direktívák segítségével tud kéréseket átadni, mint például proxy_pass, fastcgi_passvagy uwsgi_passEz rugalmasságot biztosít az alkalmazások skálázásában terheléselosztott környezetek mögött. Több háttérkiszolgáló csoportosítása esetén az NGINX a meghatározott szabályzatok alapján képes elosztani a forgalmat, támogatva a körforgásos és más stratégiákat.

10) Írja le, hogyan használják az NGINX-et statikus és dinamikus tartalom kiszolgálására.

Az NGINX rendkívül hatékony a kiszolgálásban statikus fájlok (HTML, CSS, képek) közvetlenül optimalizált eseményciklus és fájl I/O mechanizmusok használatával. dinamikus tartalomAz NGINX a kéréseket olyan háttérprocesszoroknak továbbítja, mint a PHP-FPM, Python WSGI szerverek, vagy alkalmazáskeretrendszerek FastCGI/proxy mechanizmusokon keresztül. Ez az elkülönítés lehetővé teszi az NGINX számára, hogy statikus fájlszerverként kiemelkedően működjön, miközben a háttérszolgáltatásokat dinamikus generálásra használja ki, biztosítva az optimális teljesítményt és skálázhatóságot.

11) Hogyan működik a terheléselosztás az NGINX-ben, és milyen módszerek állnak rendelkezésre?

Az NGINX robusztus terhelés elosztás keresztül a upstream direktíva, amely a forgalmat több háttérszerver között osztja el a teljesítmény optimalizálása és a magas rendelkezésre állás biztosítása érdekében. Több módszert is támogat:

Módszer	Leírás	Legjobb használati eset
Round Robin	Alapértelmezett metódus, amely szekvenciálisan cseréli a kéréseket a szerverek között.	Egyenletesen elosztott munkaterhelések.
Legkevesebb kapcsolatok	A kéréseket a legkevesebb aktív kapcsolattal rendelkező szerverre küldi.	Hosszan tartó munkamenetek.
IP hash	A kliens IP-címét használja a kiszolgáló kiválasztásának meghatározásához.	Munkamenet-perzisztencia.
Legrövidebb idő	Az egyenlegek a válaszidő és a kapcsolatok száma alapján kerülnek kiszámításra.	Késés-érzékeny alkalmazások.

Az NGINX is képes végrehajtani egészségügyi ellenőrzések a nem megfelelő állapotú szerverek dinamikus eltávolítása, biztosítva a zökkenőmentes forgalomáramlást és rugalmasságot.

12) Mi a különbség az NGINX nyílt forráskódú és az NGINX Plus között?

nginx Open Source a közösségi verzió, amely alapvető webszerver-, proxy- és terheléselosztási képességeket kínál. NGINX Plus a kereskedelmi kiadás, amely ezeket a funkciókat vállalati szintű fejlesztésekkel bővíti, mint például a fejlett monitorozás, a munkamenet-megőrzés, a dinamikus újrakonfigurálás és az aktív állapotellenőrzések.

Funkció	NGINX nyílt forráskódú	NGINX Plus
Terhelés elosztás	Alapszintű (Körforgás, IP Hash)	Speciális (legrövidebb idő, dinamikus újrakonfigurálás)
megfigyelés	Kézi / külső szerszámok	Beépített irányítópult és API
gyorsítótárral	alapvető	Továbbfejlesztett tisztításvezérléssel
Támogatás	Csak közösség	Vállalati támogatás és frissítések

A kritikus fontosságú munkaterhelésekkel rendelkező szervezetek gyakran választják az NGINX Plus-t a fokozott megbízhatóság és megfigyelhetőség miatt.

13) Hogyan valósítjuk meg a gyorsítótárat NGINX-ben?

Az NGINX gyorsítótárazása javítja a válaszidőt és csökkenti a háttérterhelést azáltal, hogy helyben tárolja a gyakran használt tartalmakat. Engedélyezhető a következő használatával: proxy_cache direktíva. Példa konfiguráció:

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

A gyorsítótárazott válaszok közvetlenül a lemezről kerülnek kiszállításra, amikor egyező kérés érkezik, kihagyva a felsőbb feldolgozást. A gyorsítótár lejáratát a következővel szabályozhatja: proxy_cache_valid és zárjon ki bizonyos URI-kat a proxy_no_cacheEz a mechanizmus kulcsfontosságú a nagy forgalmú környezetekben, például a híroldalakon vagy az e-kereskedelmi oldalakon.

14) Magyarázd el a „try_files” direktíva célját és használatát.

A try_files Az utasítás a megadott sorrendben ellenőrzi a fájlok meglétét, mielőtt a kérést a tartalék helyre továbbítaná. Általában a következő esetekben használják: statikus webhelyútválasztás or egyoldalas kérelmek (SPA-k).

Példa:

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

Itt az NGINX először ellenőrzi, hogy a kért URI egyezik-e egy fájllal, majd egy könyvtárral, és végül a nem egyező kéréseket a következőhöz irányítja: /index.htmlEz javítja a hatékonyságot és a felhasználói élményt azáltal, hogy közvetlenül a gyorsítótárazott vagy statikus fájlokat szolgálja ki, elkerülve a felesleges háttérhívásokat.

15) Hogyan képes az NGINX kezelni a HTTPS és SSL/TLS protokollok megszakítását?

Az NGINX SSL/TLS terminációs proxyként működik, a titkosítást és a visszafejtést a szerver rétegen kezeli, mielőtt a titkosítatlan kéréseket továbbítaná a upstream szolgáltatásoknak. Példa konfiguráció:

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

Támogatja a HTTP / 2, OCSP tűzés, HSTSés modern titkosítócsomagok, lehetővé téve a biztonságos és nagy teljesítményű kommunikációt. Az SSL NGINX-en történő leállítása csökkenti a titkosítási terhelést a háttérszervereken és leegyszerűsíti a tanúsítványkezelést.

16) Mi a különbség az átírás és az átirányítás között NGINX-ben?

Mindkét rewrite és a átirányítás módosíthatják a kérések irányítását, de alapvetően különböznek:

Aspect	átír	Átirányítás
típus	Belső URL átírása	Külső kliens átirányítása
Válaszkód	200 XNUMX (belső)	301/302 (HTTP átirányítás)
Láthatóság	Átlátható a felhasználó számára	Az ügyfél új URL-t lát
Használja az ügyet	SEO-barát URL-ek, útvonaltervezés	Domain migráció, HTTPS kényszerítés

Példa:

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

Ennek a különbségtételnek a megértése kulcsfontosságú a SEO és az útvonaltervezési logika hatékony optimalizálásához.

17) Hogyan védi az NGINX-et a gyakori sebezhetőségektől?

A biztonsági megerősítés a legjobb gyakorlatok kombinációját foglalja magában:

Szerver tokenek letiltása: server_tokens off;
Korlátozza a kérési metódusokat: Csak a GET, POST és HEAD műveletek engedélyezettek.
Puffer túlcsordulások korlátozása: konfigurálása client_max_body_size és a client_body_buffer_size.
Használjon HTTPS-t modern titkosításokkal.
Engedélyezze a sebességkorlátozást keresztül limit_req_zone.
Verzióinformációk elrejtése és a könyvtárlistázás letiltása.

Ezen kívül az a Webalkalmazások tűzfala (WAF) mint ModSecurity with NGINX képes kiszűrni a rosszindulatú forgalmat. Az NGINX rendszeres frissítése és biztonsági javítások telepítése elengedhetetlen a nulladik napi támadások megelőzése érdekében.

18) Mik azok az NGINX változók, és hogyan használhatók a konfigurációkban?

Az NGINX változók dinamikus adatokat tárolnak, amelyeket a konfigurációkban és a naplófeldolgozásban használnak. Ezek lehetnek kérésfejlécek, kliens IP-címek vagy számított értékek. Példák a következőkre: $remote_addr, $host, $uri, $request_methodés $upstream_addr.

Például:

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

A változók rugalmasságot biztosítanak, lehetővé téve a feltételes útválasztást és az egyéni naplózást. Egyéni változókat is definiálhat a set direktíva, amely segíti a moduláris konfigurációtervezést.

19) Hogyan lehet beállítani a sebességkorlátozást az NGINX-ben?

A sebességkorlátozás szabályozza, hogy a felhasználók milyen gyakran küldhetnek kéréseket, védelmet nyújtva a nyers erő és a DDoS támadások ellen. A beállítás a következő használatával történik: limit_req_zone irányelv:

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

Ez másodpercenként egy kérést engedélyez, öt kéréses sorozattal. Az NGINX a konfigurációtól függően elveti vagy késlelteti a felesleges kéréseket. A sebességkorlátozás biztosítja a tisztességes erőforrás-felhasználást és megakadályozza a szerver túlterhelését.

20) Milyen előnyei és hátrányai vannak az NGINX fordított proxyként való használatának?

Az NGINX, mint fordított proxy, számos előnnyel, de néhány kompromisszummal is jár:

Előnyök	Hátrányok
Nagy teljesítmény és párhuzamos kezelés	Nagyméretű telepítésekhez manuális hangolást igényel
SSL-lezárás és központosított biztonság	Korlátozott dinamikus modultámogatás (fordítási idő)
Terheléselosztás és gyorsítótárazás támogatása	Komplex konfiguráció új felhasználók számára
Alkalmazásréteg szűrése	A natív dinamikus tartalom végrehajtásának hiánya

Előnyei messze felülmúlják a korlátokat a legtöbb vállalati forgatókönyvben, így az NGINX a modern webes infrastruktúra nélkülözhetetlen eleme.

21) Hogyan monitorozható az NGINX teljesítménye és állapota éles környezetben?

Az NGINX monitorozása kulcsfontosságú a szűk keresztmetszetek, hibák és a rendellenes forgalmi viselkedés azonosításához. Több megközelítés is alkalmazható:

Beépített állapotmodul (stub_status):
Megjeleníti az aktív kapcsolatokat, a kezelt kéréseket és az olvasási/írási állapotokat. Példa:
```
location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
```
NGINX Plus műszerfal: Valós idejű mérőszámokat biztosít REST API és grafikus felhasználói felület segítségével.
Harmadik féltől származó integrációk: Az olyan eszközök, mint a Prometheus, a Grafana, a Datadog vagy az ELK, képesek metrikákat és naplókat gyűjteni.
Hozzáférési és hibanaplók: A rendszeres naplórotáció és -elemzés olyan eszközökkel, mint a GoAccess vagy az AWStats, javítja a megfigyelhetőséget.

A monitorozás segít biztosítani az üzemidőt, a hibák gyors észlelését és a kapacitástervezést.

22) Mi a különbség a proxy_pass és a fastcgi_pass direktívák között?

Mindkét irányelv a háttérszolgáltatásoknak továbbítja a kéréseket, de különböző protokollokhoz készültek:

Irányelv	Cél	Háttérprotokoll	Használati példa
`proxy_pass`	HTTP vagy HTTPS kéréseket továbbít a háttérszervereknek	HTTP	Revwebes API-k vagy mikroszolgáltatások proxyja
`fastcgi_pass`	Kéréseket küld egy FastCGI processzornak	FastCGI	PHP-FPM, Python FastCGI alkalmazások

Példa:

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

Összefoglalva, használja proxy_pass általános HTTP háttérrendszerekhez és gyorscgi_pass dinamikus nyelvi futási környezetekhez, mint például a PHP.

23) Hogyan konfigurálható a gzip tömörítés NGINX-ben, és milyen előnyei vannak?

A Gzip tömörítés engedélyezése az NGINX-ben csökkenti a sávszélesség-használatot és javítja a betöltési időt azáltal, hogy a szöveges válaszokat tömöríti, mielőtt elküldené azokat az ügyfeleknek.

Példa konfigurációra:

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

Előnyök:

Akár 70%-kal is csökkenti az átviteli fájlok méretét.
Javítja az első bájt betöltéséig eltelt időt (TTFB) és az oldal teljesítménymutatóit.
Sávszélesség-költségeket takarít meg, ami különösen előnyös a mobilfelhasználók számára.

Azonban nem szabad alkalmazni már tömörített fájlokra (pl. .zip, .jpg, .png) a CPU-terhelés elkerülése érdekében.

24) Melyek az NGINX nagy forgalmú környezetben történő finomhangolásának legjobb gyakorlatai?

A nagy forgalmú optimalizálás az erőforrások és a konfigurációs paraméterek gondos hangolását foglalja magában:

Terület	Irányelv	Ajánlott gyakorlat
Dolgozók	`worker_processes auto;`	CPU-magok egyeztetése
kapcsolatok	`worker_connections 4096;`	Párhuzamosság növelése
Életben tartani	`keepalive_timeout 65;`	Optimalizálja az ügyfelek újrafelhasználását
filé Descriptill	OS `ulimit -n`	Emelje a nyitott socketek korlátait
gyorsítótárral	`proxy_cache_path`	Csökkentse a háttérterhelést
Gzip	`gzip on;`	Szöveges válaszok tömörítése

Ezenkívül a aszinkron lemez I/O, terhelés elosztásés upstream egészségügyi ellenőrzések stabilitást és sebességet biztosít nagy mennyiségű egyidejű kérés esetén is.

25) Hogyan kezeli az NGINX a WebSocket kapcsolatokat?

A WebSockets kétirányú kommunikációt tesz lehetővé a kliens és a szerver között – ami elengedhetetlen a valós idejű alkalmazásokhoz. Az NGINX ezt natívan támogatja a megfelelő fejléctovábbításon keresztül.

Példa konfigurációra:

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

Főbb pontok:

A Upgrade és a Connection A fejlécek kitöltése kötelező.
Győződjön meg arról, hogy az NGINX HTTP/1.1-et használ az állandó TCP-kapcsolatokhoz.
A terheléselosztáshoz szükséges WebSockets ragadós munkameneteket igényelhet a következő használatával: ip_hash.

Ez a konfiguráció olyan alkalmazásokat támogat, mint a csevegés, a tőzsdei kereskedés vagy a játékok.

26) Mi a „worker_rlimit_nofile” direktíva célja?

worker_rlimit_nofile meghatározza a munkafolyamatok számára elérhető megnyitott fájlleírók maximális számát. Ez a korlát közvetlenül befolyásolja, hogy hány egyidejű kapcsolatot tud kezelni az NGINX. Példa:

worker_rlimit_nofile 100000;

Ennek a korlátnak a megemelése létfontosságú a nagy párhuzamosságot igénylő rendszerek (például API-átjárók vagy streaming platformok) esetében. Az operációs rendszer korlátja (ulimit -n) értékét is növelni kell, hogy megfeleljen ennek az értéknek a konzisztencia érdekében.

27) Hogyan használható az NGINX URL-ek átírására vagy automatikus HTTPS-re való átirányításra?

A HTTP átirányítása HTTPS-re biztosítja a biztonságos kommunikációt. Példa:

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

Ez a konfiguráció egy 301-es állandó átirányítás HTTP-ről HTTPS-re. A finomabb szabályozás érdekében az átírási szabályok elérési útra specifikus átirányítást is kikényszeríthetnek:

rewrite ^/oldpath$ /newpath permanent;

Az automatikus HTTPS-kényszerítés javítja a SEO-rangsorolást, megakadályozza a közbeékelődéses támadásokat, és egységes felhasználói élményt biztosít.

28) Melyek az „502 Bad Gateway” hibák gyakori okai az NGINX-ben?

Az „502 Hibás Átjáró” hiba azt jelzi, hogy az NGINX proxyként működve nem tudott érvényes választ kapni egy upstream szervertől. Gyakori okok a következők:

A háttérszerver összeomlása vagy elérhetetlensége.
Helytelen proxy_pass URL vagy socket elérési út.
Feltöltési időtúllépés (proxy_read_timeout túl alacsony).
A tűzfal vagy a SELinux blokkolja a feltöltési kapcsolatokat.
Rosszul konfigurált FastCGI paraméterek (PHP-hez).

A hibakereséshez ellenőrizze a hibanaplókat (/var/log/nginx/error.log), ellenőrizze az upstream elérhetőséget, és tesztelje a backend válaszokat közvetlenül a curl.

29) Hogyan támogatja az NGINX a mikroszolgáltatásokat és a konténeralapú architektúrákat (pl. Docker, Kubernetes)?

Az NGINX ideális a következőkhöz: mikroszolgáltatási környezetek könnyű kialakításának és fordított proxy funkcionalitásának köszönhetően. Dockerben vagy Kubernetesben a következőképpen funkcionál:

Bejövő vezérlő: Kezeli a belső szolgáltatások felé irányuló külső HTTP/S forgalmat.
Szolgáltatásátjáró: Útválasztást, terheléselosztást és hitelesítést végez.
Oldalkocsis proxy: Növeli a rugalmasságot és a megfigyelhetőséget a szolgáltatáshálókban (pl. Istio).

Az NGINX konfigurációk dinamikusan frissíthetők a Kubernetes ConfigMaps segítségével, lehetővé téve a központosított forgalomvezérlést és az SSL-kezelést. Moduláris megközelítése tökéletesen illeszkedik a konténerizált és a felhőalapú telepítésekhez.

30) Milyen különböző módokon lehet javítani az NGINX biztonságát éles rendszereken?

Az NGINX biztonságának fokozása többrétegű konfigurációt igényel:

SSL/TLS-keményítés: Használjon modern titkosításokat, tiltsa le az SSLv3/TLSv1.0-t.
HTTP metódusok korlátozása: Csak biztonságos igéket engedélyez (GET, POST, HEAD).

Biztonsági fejlécek:

add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";

Verzióinformációk elrejtése: server_tokens off;
Engedélyezze a sebességkorlátozást és a hozzáférés-vezérlést.
WAF vagy Fail2Ban integrálása a nyers erő megakadályozása érdekében.

Ezek az intézkedések együttesen egy megerősített, éles üzemű NGINX környezetet hoznak létre, amely ellenáll a gyakori támadásoknak.

31) Hogyan lehet hatékonyan hibakeresni az NGINX problémákat?

Az NGINX hibakeresése a naplók, konfigurációs fájlok és folyamatállapotok szisztematikus elemzését foglalja magában. A főbb lépések a következők:

Szintaxis ellenőrzése:

nginx -t

Újratöltés előtt ellenőrzi a konfigurációt.

Hibakeresési naplózás engedélyezése:

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

Részletes futásidejű diagnosztikát biztosít.

Hozzáférési naplók elemzése: Válaszkódok és kérésminták észlelése a következők használatával:

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

Kapcsolat tesztelése: Felhasználás curl -v or wget a háttérrendszer elérhetőségének ellenőrzéséhez.
Aktív kapcsolatok monitorozása: Keresztül stub_status or netstat.

Az NGINX munkafolyamatainak, pufferkorlátainak és a folyamatindító válaszoknak a megértése segít gyorsan meghatározni a szűk keresztmetszeteket az éles rendszerekben.

32) Hogyan konfigurálható az NGINX naplózás, és mik az egyéni naplóformátumok?

Az NGINX rugalmas naplózási mechanizmusokat kínál a következők révén: access_log és a error_log irányelvek.

Példa konfigurációra:

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;

Meghatározhatod egyéni formátumok olyan mutatókat is tartalmazzon, mint $upstream_addr, $request_timevagy $bytes_sent.

A fokozott megfigyelhetőség érdekében a naplókat gyakran ide küldik: ELK, Loki vagy Splunk valós idejű elemzéshez és irányítópultokhoz.

33) Mi a proxy_buffering direktíva szerepe az NGINX-ben?

proxy_buffering azt szabályozza, hogy az NGINX puffereli-e a válaszokat az upstream szerverekről, mielőtt elküldené azokat az ügyfeleknek.

Beállítás	Leírás	Használja az ügyet
`proxy_buffering on;`	Buffera teljes válasz az optimalizált átviteli sebesség érdekében	Alapértelmezett; javítja a teljesítményt
`proxy_buffering off;`	Közvetlenül, pufferelés nélkül továbbítja az adatokat a klienseknek	Valós idejű streamelés vagy API-k

Például a pufferelés letiltásához:

location /stream/ {
    proxy_buffering off;
}

A pufferelés letiltása ideális csevegési vagy streaming szolgáltatásokhoz, de csökkentheti a normál webes forgalom átviteli sebességét.

34) Magyarázza el, hogyan lehet érvényteleníteni vagy kiüríteni az NGINX gyorsítótárat.

Az NGINX nyílt forráskódú nem tartalmaz beépített gyorsítótár-tisztítást, de ez többféleképpen is elérhető:

Kézi tisztítás: Fájlok eltávolítása a gyorsítótár könyvtárából.
```
rm -rf /var/cache/nginx/*
```
Harmadik féltől származó modul: Felhasználás ngx_cache_purge HTTP kérésen keresztüli tisztításhoz:
```
location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
```
NGINX Plus funkció: Lehetővé teszi az API-alapú gyorsítótár dinamikus kiürítését.

A törlés biztosítja az elavult tartalom azonnali cseréjét, megőrizve a tartalom frissességét és konzisztenciáját a CDN-en vagy a többcsomópontos telepítéseken keresztül.

35) Hogyan kezeli az NGINX a csatlakozási időtúllépéseket?

Az NGINX több időtúllépési direktívát biztosít annak szabályozására, hogy mennyi ideig várjon az ügyfél vagy az upstream válaszokra:

Irányelv	Cél	Alapértelmezett(ek)
`client_body_timeout`	Várakozási idő az ügyfél testére	60
`client_header_timeout`	Várakozási idő az ügyfél fejlécére	60
`keepalive_timeout`	Tétlen keepalive kapcsolatok	75
`send_timeout`	Az adatok ügyfélnek történő elküldésének ideje	60
`proxy_read_timeout`	Várakozási idő a felsőbb szintű válaszra	60

A megfelelő hangolás elkerüli a felesleges lecsatlakozásokat, és zökkenőmentesebb felhasználói élményt biztosít változó hálózati körülmények között.

36) Hogyan lehet kék-zöld telepítést megvalósítani NGINX használatával?

egy kék-zöld bevetés, két környezet (kék = aktív, zöld = készenléti) fut egyszerre. Az NGINX forgalmi útválasztóként működik közöttük.

Példa konfigurációra:

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

Amikor az új verziót (zöld) tesztelik és ellenőrzik, a forgalomváltás az upstream definíció frissítésével és az NGINX újratöltésével történik (nginx -s reload).

Ez a módszer biztosítja nulla állásidő alkalmazásfrissítések vagy visszaállítások során.

37) Mi a sebességkorlátozó burst, és hogyan javítja az NGINX teljesítményét?

A sorozatban A sebességkorlátozás paramétere lehetővé teszi a forgalom rövid idejű csúcsainak átmeneti áthaladását azonnali elutasítás nélkül.

Példa:

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

Itt öt további kérést fogadnak el azonnal a szabályozás alkalmazása előtt.

Ez a technika kisimítja a forgalmi túlfeszültségeket, így biztosítva az egységes felhasználói élményt anélkül, hogy túlterhelné a háttérrendszereket.

38) Hogyan kezeli az NGINX az IPv6 és a dual-stack környezeteket?

Az NGINX teljes mértékben támogatja az IPv6-ot mind a szerver, mind az upstream konfigurációkban. Példa:

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

A kettős protokollveremes támogatás (IPv4 + IPv6) a következők együttes beépítésével érhető el:

listen 80;
listen [::]:80;

Az IPv6-kompatibilitás szélesebb körű hozzáférést biztosít, különösen a mobil és a nemzetközi ügyfelek számára, és kritikus fontosságú a modern internetes szabványoknak való megfelelés szempontjából.

39) Hogyan konfigurálhatók a ragadós munkamenetek NGINX terheléselosztásban?

A ragadós munkamenetek biztosítják, hogy az ugyanattól a klienstől érkező kérések mindig ugyanarra a háttérkiszolgálóra legyenek irányítva.

<p></p> ip_hash:

upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}

NGINX Plus ragadós süti:
Speciális munkamenet-megőrzés konfigurálható sütikkel.

A ragadós munkamenetek létfontosságúak az olyan állapotalapú alkalmazásokhoz, mint a felhasználói irányítópultok vagy a bevásárlókosarak, biztosítva a munkamenet-adatok konzisztenciáját megosztott tárhely nélkül.

40) Melyek az NGINX fő naplózási szintjei, és miben különböznek?

Az NGINX támogatja a hierarchikus naplózási szinteket a hibanapló részletességének szabályozásához.

Szintek	Leírás
`debug`	Részletes információk a hibaelhárításhoz (nagyon bőbeszédű)
`info`	Általános futásidejű információk
`notice`	Jelentős, de nem kritikus események
`warn`	Lehetséges problémák vagy helytelen konfigurációk
`error`	Operafigyelmet igénylő intelligenciális hibák
`crit`, `alert`, `emerg`	Kritikus hibák és rendszerriasztások

Példa konfigurációra:

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

A naplózási szintek környezetnek megfelelő beállítása (hibakeresés előzetes környezetben, figyelmeztetés éles környezetben) segít fenntartani az egyensúlyt a láthatóság és a teljesítmény között.

41) Hogyan méred az NGINX teljesítményét?

Az NGINX benchmarkingja magában foglalja az átviteli sebesség, a késleltetés és a párhuzamosság mérését a konfigurációs szűk keresztmetszetek azonosítása érdekében. A gyakori eszközök a következők:

ApacheBench (ab):

ab -n 10000 -c 100 http://example.com/

A tesztek mennyiséget és párhuzamosságot igényelnek.
munka: Részletes késleltetési percentiliseket és kérésarányokat biztosít.
ostrom / httperf: Valós forgalmi terhelést szimulál.
Grafana + Prométheusz: Élő teljesítménymutatókat figyel.

A benchmarkingnak olyan paramétereket kell mérnie, mint a requests per second (RPS), time per requestés error rate.

Hangolási változók, mint például worker_processes, worker_connectionsés keepalive_timeout jelentősen javítja a megfigyelt áteresztőképességet.

42) Hogyan integrálható az NGINX a CI/CD pipeline-okkal?

Az NGINX zökkenőmentesen integrálható a következőkkel: CI / CD az automatizált telepítéshez, teszteléshez és konfigurációkezeléshez. A gyakori megközelítések a következők:

Infrastruktúra mint kód (IaC): Konfigurációk kezelése Ansible, Terraform vagy Helm diagramokkal.
Docker konténerek: NGINX rendszerképek létrehozása és telepítése CI-eszközökkel (Jenkins, GitLab CI vagy GitHub Actions).
Automatizált tesztelés: Konfigurációk validálása a következővel: nginx -t a csővezeték szakaszaiban.
Kék-zöld / Canary Telepítési automatizálás: A bevezetés során dinamikusan frissítse a felsőbb szintű szervereket.

Példa GitLab CI kódrészletre:

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

Az automatizált telepítés biztosítja a konzisztens, verziókövetett és megbízható NGINX bevezetést.

43) Magyarázza el az NGINX Ingress Controller szerepét a Kubernetesben.

A NGINX bemeneti vezérlő Kezeli a Kubernetes szolgáltatásokba bejövő forgalmat. Dinamikusan lefordítja a Kubernetes Ingress erőforrásokat NGINX konfigurációkká.

Főbb funkciók:

A HTTP/S kéréseket a megfelelő szolgáltatáshoz irányítja.
SSL-lezárást, sebességkorlátozást és URL-átírást biztosít.
Támogatja a terheléselosztást a podok között.
Lehetővé teszi a részletes vezérléshez szükséges annotációkat (pl. rewrite-target, proxy-body-size).

Példa YAML bemeneti feldolgozásra:

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

Ez az architektúra a rugalmas skálázhatóság érdekében leválasztja a forgalomirányítási logikát a konténertelepítésekről.

44) Hogyan kezeli az NGINX a HTTP/2-t, és milyen előnyei vannak?

Az NGINX teljes mértékben támogatja HTTP / 2, a HTTP/1.1 utódja, amely a multiplexelés és a fejléc-tömörítés révén javítja a hatékonyságot.

A HTTP/2 engedélyezéséhez:

server {
    listen 443 ssl http2;
    ...
}

Előnyök:

Funkció	Leírás
Multiplexelés	Több kérés TCP-kapcsolatonként
Fejléc tömörítés (HPACK)	Csökkenti a sávszélesség-használatot
Szerver push	Megelőzően küld eszközöket az ügyfeleknek
Gyorsabb TLS	Egyszerűsített, biztonságos kézfogások

A HTTP/2 drasztikusan csökkenti a késleltetést és az oldalak betöltési idejét, különösen a számos elemmel rendelkező modern webalkalmazások esetében.

45) Mi a különbség az upstream keepalive és a connection reuse között NGINX-ben?

Upstream keepalive Példa: állandó kapcsolatot tart fenn a háttérszerverekkel, csökkentve a TCP kézfogás terhelését.

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

Különbség:

Aspect	Életben tartani	Kapcsolat újrafelhasználása
Kör	Az NGINX és az upstream között	Az NGINX és az ügyfelek között
Cél	Háttéroptimalizálás	Frontend teljesítmény
Configuration	`keepalive` belső `upstream`	`keepalive_timeout` in `server` blokkolni

Mindkét technika csökkenti a késleltetést, de különböző kommunikációs rétegeket szolgál ki (kliensoldali vs. szerveroldali).

46) Hogyan lehet dinamikusan újrakonfigurálni az NGINX-et újraindítás nélkül?

Új konfigurációk dinamikus alkalmazása állásidő nélkül, használja a reload gépezet:

nginx -t && nginx -s reload

Ez jelzi a mesterfolyamat hogy új munkagépeket hozzon létre frissített konfigurációkkal, miközben kecsesen leállítja a régieket.

Az NGINX Plusban változtatásokat lehet végezni API-n keresztül (pl. upstream szerverek dinamikus hozzáadása):

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

Ez a képesség támogatja a nulla állásidőt biztosító telepítéseket a modern DevOps folyamatokban.

47) Melyek a legfontosabb különbségek a fordított és a továbbított proxy között az NGINX-ben?

Aspect	Reverse Proxy	Továbbítási proxy
Ügyfélláthatóság	Az ügyfelek nincsenek tisztában a háttérszerverekkel	A szerverek nem ismerik az ügyfél identitását
Elsődleges felhasználás	Terheléselosztás, gyorsítótárazás, SSL-lezárás	Szűrés, anonimitás, hozzáférés-vezérlés
Általános használati eset	Webes forgalomeloszlás	Vállalati vagy biztonságos kimenő böngészés
NGINX támogatás	Natív és széles körben használt	Egyedi konfigurációt igényel

Példa (előrehaladó proxy):

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

RevAz erse proxy továbbra is a domináns felhasználási eset, különösen az API-átjárók és a mikroszolgáltatás-architektúrák esetében.

48) Hogyan használható az NGINX API sebességkorlátozásra és -szabályozásra?

A sebességkorlátozás megvédi az API-kat a visszaélésektől és biztosítja a tisztességes használatot. Példa konfiguráció:

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

Mechanizmus:

limit_req_zone: Meghatározza a megosztott memória zónáját és sebességét.
burst: Korlátozott ideig tartó tüskéket engedélyez.
nodelay: Azonnal érvényesíti a korlátozásokat.

Ez a konfiguráció biztosítja, hogy minden kliens IP-cím másodpercenként csak 10 kérést tud küldeni, miközben rövid kéréscsomagokat tesz lehetővé.

49) Melyek az NGINX tipikus felhasználási esetei vállalati DevOps környezetekben?

A vállalati DevOps ökoszisztémákban az NGINX több kritikus szerepet is betölt:

Web szerver: Nagy teljesítményű statikus tartalomszolgáltatás.
Reverse proxy / terheléselosztó: Forgalomkezelés mikroszolgáltatások között.
API-átjáró: Hitelesítés, útválasztás és szabályozás.
Bejövő vezérlő: Kubernetes klaszterekhez.
Tartalom gyorsítótárazási réteg: Csökkenti a háttérterhelést.
SSL lezárási végpont: Központosított tanúsítványkezelés.
Monitoring végpont: Metrikák és megfigyelhetőségi integráció.

Könnyű méretének és moduláris kialakításának köszönhetően az NGINX nélkülözhetetlen a CI/CD pipeline-okban, a hibrid felhőkben és a nagy rendelkezésre állású klaszterekben.

50) Melyek a fő különbségek az NGINX és a HAProxy között a terheléselosztás tekintetében?

Mindkettő nagy teljesítményű terheléselosztó, de fókuszukban és architektúrájukban különböznek:

Funkció	nginx	HAProxy
Elsődleges szerep	Webszerver + fordított proxy	Dedikált TCP/HTTP terheléselosztó
Konfiguráció egyszerűsége	Könnyebb webalapú munkafolyamatokhoz	Komplex, de részletesebb szabályozás
Réteg támogatás	L7 (HTTP), részleges L4	L4 és L7 teljes
Dinamikus újrakonfiguráció	Korlátozott (nyílt forráskódú)	Natív futásidejű frissítések
Teljesítmény	Kiváló vegyes munkaterhelésekhez	Kiváló a nyers terheléselosztáshoz
További funkciók	Gyorsítótárazás, tömörítés, statikus tartalom	Egészségügyi ellenőrzések, pálcikaasztalok

A vállalkozások gyakran összeolvadnak NGINX (frontend) és a HAProxy (háttér) az optimális útvonaltervezés és skálázhatóság érdekében.

🔍 A legfontosabb NGINX interjúkérdések valós forgatókönyvekkel és stratégiai válaszokkal

1) Mi az NGINX, és miért használják gyakran termelési környezetekben?

Elvárások a jelölttől: Az interjúztató fel szeretné mérni az NGINX alapvető ismereteit, valamint azt, hogy mennyire érti a gyakorlati értékét a valós rendszerekben.

Példa válaszra: „Az NGINX egy nagy teljesítményű webszerver és fordított proxy, amely eseményvezérelt architektúrájáról ismert. Gyakran használják termelési környezetekben, mivel hatékonyan képes kezelni nagyszámú egyidejű kapcsolatot, miközben kevesebb rendszererőforrást fogyaszt, mint a hagyományos webszerverek.”

2) El tudnád magyarázni az NGINX és az Apache közötti különbséget?

Elvárások a jelölttől: Az interjúztató azt értékeli, hogy mennyire vagy képes összehasonlítani a technológiákat, és a használati esetek alapján kiválasztani a megfelelő eszközt.

Példa válaszra: „Az NGINX aszinkron, nem blokkoló architektúrát használ, ami hatékonyabbá teszi a nagy forgalom és a statikus tartalom kezelését. Az Apache egy folyamatvezérelt modellt használ, amely rugalmasabb lehet a dinamikus konfigurációkhoz, de nagy terhelés alatt több erőforrást fogyaszthat.”

3) Hogyan működik az NGINX fordított proxyként?

Elvárások a jelölttől: Az interjúztató szeretné megerősíteni, hogy érted a fordított proxy koncepcióját, és azt, hogy az NGINX hogyan illeszkedik a modern architektúrákba.

Példa válaszra: „Az NGINX fordított proxyként működik azáltal, hogy fogadja a klienskéréseket és továbbítja azokat a háttérszervereknek. Ezután visszaküldi a szerver válaszait a kliensnek, ami javítja a biztonságot, a terheléselosztást és az általános teljesítményt.”

4) Írj le egy olyan helyzetet, ahol NGINX-et használtál terheléselosztásra.

Elvárások a jelölttől: Az interjúztató gyakorlati tapasztalatot és az NGINX funkciók valós helyzetekben való alkalmazásának képességét várja.

Példa válaszra: „Előző munkakörömben úgy konfiguráltam az NGINX-et, hogy a forgalmat több alkalmazáskiszolgáló között ossza el körforgásos és legkisebb kapcsolatokat igénylő algoritmusok segítségével. Ez a megközelítés javította az alkalmazások rendelkezésre állását, és megakadályozta, hogy bármelyik kiszolgáló szűk keresztmetszetet képezzen.”

5) Hogyan kezeled az SSL és HTTPS konfigurációt NGINX-ben?

Elvárások a jelölttől: Az interjúztató fel szeretné mérni a biztonsági legjobb gyakorlatok és a konfigurációkezelés ismereteit.

Példa válaszra: „Egy korábbi pozíciómban SSL-t konfiguráltam tanúsítványok telepítésével, HTTPS-figyelők engedélyezésével és erős titkosítási csomagok kikényszerítésével. Emellett HTTP-HTTPS átirányítást is megvalósítottam a biztonságos kommunikáció biztosítása érdekében az összes végpont között.”

6) Milyen lépéseket tenne egy 502-es Bad Gateway hiba elhárításához NGINX-ben?

Elvárások a jelölttől: Az interjúztató a problémamegoldó képességedet és a hibaelhárítási módszeredet teszteli.

Példa válaszra: „Az NGINX hibanaplóinak ellenőrzésével kezdeném a háttérkapcsolati problémák azonosítását. Ezután ellenőrizném, hogy futnak-e a felsőbb szintű szerverek, megerősíteném a proxybeállítások helyességét, és gondoskodnék arról, hogy az időtúllépések megfelelően legyenek konfigurálva.”

7) Hogyan optimalizálható az NGINX teljesítménye nagy forgalmú alkalmazásokhoz?

Elvárások a jelölttől: Az interjúztató tudni szeretné, hogyan közelíted meg a teljesítményhangolást és a skálázhatóságot.

Példa válaszra: „Az előző munkahelyemen optimalizáltam az NGINX-et a gzip tömörítés engedélyezésével, a munkafolyamatok finomhangolásával és a statikus tartalom gyorsítótárának konfigurálásával. Ezek a változtatások jelentősen csökkentették a válaszidőket és a szerver terhelését.”

8) El tudná magyarázni, hogyan kezeli az NGINX a statikus és a dinamikus tartalmat?

Elvárások a jelölttől: Az interjúztató a kéréskezeléssel és a teljesítményoptimalizálással kapcsolatos ismereteidet méri fel.

Példa válaszra: „Az NGINX statikus tartalmat szolgál ki közvetlenül és nagyon hatékonyan a fájlrendszerből. Dinamikus tartalom esetén továbbítja a kéréseket az alkalmazáskiszolgálóknak vagy olyan szolgáltatásoknak, mint a PHP-FPM, lehetővé téve, hogy minden komponens arra koncentrálhasson, amiben a legjobb.”

9) Hogyan kezeled és teszteled biztonságosan az NGINX konfigurációs változásait?

Elvárások a jelölttől: Az interjúztató meg akarja érteni a megbízhatósághoz és a kockázatcsökkentéshez való hozzáállásodat.

Példa válaszra: „A konfigurációs módosításokat az NGINX configuration test paranccsal validálom a szolgáltatás újratöltése előtt. A módosításokat a karbantartási időszakokban is alkalmazom, és a telepítés után szorosan figyelemmel kísérem a naplókat.”

10) Írjon le egy olyan esetet, amikor gyorsan kellett megoldania egy NGINX-szel kapcsolatos leállást.

Elvárások a jelölttől: Az interjúztató azt értékeli, hogy mennyire vagy képes nyomás alatt teljesíteni és hatékonyan kommunikálni incidensek során.

Példa válaszra: „Előző munkakörömben egy rosszul konfigurált upstream szolgáltatás miatt leállás történt. A naplók segítségével gyorsan azonosítottam a problémát, visszaállítottam a konfigurációt, és a teljes szolgáltatás visszaállításáig folyamatosan tájékoztattam az érdekelt feleket az állapotfrissítésekről.”

A legfontosabb Nginx interjúkérdések és válaszok

1) Magyarázd el, mi az NGINX, és miért használják széles körben a webes infrastruktúrában.

2) Hogyan kezeli az NGINX belsőleg a HTTP kéréseket (eseményvezérelt architektúra)?

3) Melyek a főbb különbségek az NGINX és az Apache között?

4) Melyek egy NGINX konfigurációs fájl fő összetevői?

5) Hogyan lehet biztonságosan újratölteni az NGINX konfigurációt leállás nélkül?

6) Írja le, hogyan lehet beállítani az NGINX-et fordított proxyként.

7) Magyarázza el az NGINX Master és Worker folyamatait.

KAPCSOLÓDÓ CIKKEK

8) Hogyan korlátozható a nem definiált szervernevek feldolgozása NGINX-ben?

9) Mire használják az ngx_http_upstream_module-t?

10) Írja le, hogyan használják az NGINX-et statikus és dinamikus tartalom kiszolgálására.

11) Hogyan működik a terheléselosztás az NGINX-ben, és milyen módszerek állnak rendelkezésre?

12) Mi a különbség az NGINX nyílt forráskódú és az NGINX Plus között?

13) Hogyan valósítjuk meg a gyorsítótárat NGINX-ben?

14) Magyarázd el a „try_files” direktíva célját és használatát.

15) Hogyan képes az NGINX kezelni a HTTPS és SSL/TLS protokollok megszakítását?

16) Mi a különbség az átírás és az átirányítás között NGINX-ben?

17) Hogyan védi az NGINX-et a gyakori sebezhetőségektől?

18) Mik azok az NGINX változók, és hogyan használhatók a konfigurációkban?

19) Hogyan lehet beállítani a sebességkorlátozást az NGINX-ben?

20) Milyen előnyei és hátrányai vannak az NGINX fordított proxyként való használatának?

21) Hogyan monitorozható az NGINX teljesítménye és állapota éles környezetben?

22) Mi a különbség a proxy_pass és a fastcgi_pass direktívák között?

23) Hogyan konfigurálható a gzip tömörítés NGINX-ben, és milyen előnyei vannak?

Előnyök:

24) Melyek az NGINX nagy forgalmú környezetben történő finomhangolásának legjobb gyakorlatai?

25) Hogyan kezeli az NGINX a WebSocket kapcsolatokat?

Főbb pontok:

26) Mi a „worker_rlimit_nofile” direktíva célja?

27) Hogyan használható az NGINX URL-ek átírására vagy automatikus HTTPS-re való átirányításra?

28) Melyek az „502 Bad Gateway” hibák gyakori okai az NGINX-ben?

29) Hogyan támogatja az NGINX a mikroszolgáltatásokat és a konténeralapú architektúrákat (pl. Docker, Kubernetes)?

30) Milyen különböző módokon lehet javítani az NGINX biztonságát éles rendszereken?

31) Hogyan lehet hatékonyan hibakeresni az NGINX problémákat?

32) Hogyan konfigurálható az NGINX naplózás, és mik az egyéni naplóformátumok?

33) Mi a proxy_buffering direktíva szerepe az NGINX-ben?

34) Magyarázza el, hogyan lehet érvényteleníteni vagy kiüríteni az NGINX gyorsítótárat.

35) Hogyan kezeli az NGINX a csatlakozási időtúllépéseket?

36) Hogyan lehet kék-zöld telepítést megvalósítani NGINX használatával?

37) Mi a sebességkorlátozó burst, és hogyan javítja az NGINX teljesítményét?

38) Hogyan kezeli az NGINX az IPv6 és a dual-stack környezeteket?

39) Hogyan konfigurálhatók a ragadós munkamenetek NGINX terheléselosztásban?

40) Melyek az NGINX fő naplózási szintjei, és miben különböznek?

41) Hogyan méred az NGINX teljesítményét?

42) Hogyan integrálható az NGINX a CI/CD pipeline-okkal?

43) Magyarázza el az NGINX Ingress Controller szerepét a Kubernetesben.

Főbb funkciók:

44) Hogyan kezeli az NGINX a HTTP/2-t, és milyen előnyei vannak?

Előnyök:

45) Mi a különbség az upstream keepalive és a connection reuse között NGINX-ben?

Különbség:

46) Hogyan lehet dinamikusan újrakonfigurálni az NGINX-et újraindítás nélkül?

47) Melyek a legfontosabb különbségek a fordított és a továbbított proxy között az NGINX-ben?

48) Hogyan használható az NGINX API sebességkorlátozásra és -szabályozásra?

Mechanizmus:

49) Melyek az NGINX tipikus felhasználási esetei vállalati DevOps környezetekben?

50) Melyek a fő különbségek az NGINX és a HAProxy között a terheléselosztás tekintetében?

🔍 A legfontosabb NGINX interjúkérdések valós forgatókönyvekkel és stratégiai válaszokkal

1) Mi az NGINX, és miért használják gyakran termelési környezetekben?

2) El tudnád magyarázni az NGINX és az Apache közötti különbséget?

3) Hogyan működik az NGINX fordított proxyként?

4) Írj le egy olyan helyzetet, ahol NGINX-et használtál terheléselosztásra.

5) Hogyan kezeled az SSL és HTTPS konfigurációt NGINX-ben?

6) Milyen lépéseket tenne egy 502-es Bad Gateway hiba elhárításához NGINX-ben?

7) Hogyan optimalizálható az NGINX teljesítménye nagy forgalmú alkalmazásokhoz?

8) El tudná magyarázni, hogyan kezeli az NGINX a statikus és a dinamikus tartalmat?

9) Hogyan kezeled és teszteled biztonságosan az NGINX konfigurációs változásait?

10) Írjon le egy olyan esetet, amikor gyorsan kellett megoldania egy NGINX-szel kapcsolatos leállást.

Foglald össze ezt a bejegyzést a következőképpen:

Iratkozzon fel a hírlevélre