50 parasta Nginx-haastattelun kysymystä ja vastausta (2026)

by: Bryce Leo Bryce Leo
Hours Päivitetty

Nginxin parhaat haastattelukysymykset ja vastaukset

Nginx-haastatteluun valmistautuminen vaatii ennakointikykyä, selkeyttä ja ymmärrystä siitä, miten haastattelijat arvioivat todellista operatiivista tietoa tänä päivänä. Nginx-haastattelukysymykset paljastavat syvyyttä, päätöksentekokykyä, vianmäärityskykyä ja tuotantovalmiutta.

Nämä roolit avaavat mahdollisuuksia pilvi-infrastruktuurin, suorituskykysuunnittelun ja tietoturvan parissa, joissa käytännön konfiguroinnilla on merkitystä. Työnantajat arvostavat teknistä kokemusta, toimialaosaamista ja kenttätyöstä saatua analyyttistä osaamista, sillä he auttavat vastavalmistuneita, keskitason insinöörejä ja kokeneita ammattilaisia ​​soveltamaan perustaitoja ja edistyneitä taitoja tiimeissä esimiesten ja tiiminvetäjien ohjauksessa. Lue lisää ...

👉 Ilmainen PDF-lataus: Nginx-haastattelukysymykset ja vastaukset

Nginxin parhaat haastattelukysymykset ja vastaukset

1) Selitä, mikä NGINX on ja miksi sitä käytetään laajalti web-infrastruktuurissa.

NGINX on tehokas avoimen lähdekoodin web-palvelin, joka toimii myös käänteisenä välityspalvelimena, kuormituksen tasaajana ja HTTP-välimuistina. Se tukee HTTP-, HTTPS-, SMTP-, POP3- ja IMAP-protokollia. Arkkitehtuuri käyttää event-driven, asynchronous model mikä mahdollistaa sen käsitellä kymmeniätuhansia samanaikaisia ​​yhteyksiä pienellä muistin ja suorittimen käytöllä. Tämä skaalautuvuus tekee NGINX:stä erityisen sopivan paljon liikennettä käyttäville verkkosovelluksille, mikropalveluille ja hajautetuille arkkitehtuureille. Esimerkiksi yritykset, joilla on paljon liikennettä (kuten sisältöalustat tai API-yhdyskäytävät), suosivat usein NGINX:iä samanaikaisten yhteyksien ja staattisen sisällön tehokkaaseen käsittelyyn.

2) Miten NGINX käsittelee HTTP-pyyntöjä sisäisesti (tapahtumapohjainen arkkitehtuuri)?

NGINX:n ydinvahvuus on sen event-driven, non-blocking architectureSen sijaan, että jokaista pyyntöä varten luotaisiin erillinen säie tai prosessi (kuten perinteisillä palvelimilla), NGINX käyttää pientä joukkoa työprosesseja, jotka hyödyntävät asynkronisia tapahtumasilmukoita. Jokainen työprosessi voi hallita tuhansia yhteyksiä odottamalla käyttöjärjestelmän valmiusilmoituksia ja käsittelemällä tapahtumia niiden tapahtuessa. Koska NGINX ei estä I/O-toimintoja, se voi tarjoilla staattista ja välityspalvelimella olevaa sisältöä minimaalisilla resursseilla. Tämä malli sopii erinomaisesti korkean samanaikaisuuden käyttötapauksiin, mikä tekee siitä tehokkaamman kuin prosessipohjaiset palvelimet raskaiden kuormien alla.

3) Mitkä ovat NGINX:n ja Apachen tärkeimmät erot?

Vaikka sekä NGINX että Apache ovat suosittuja web-palvelimia, ne eroavat toisistaan ​​arkkitehtuurin, suorituskyvyn ja suunnittelutavoitteiden suhteen:

Aspect nginx Apache
Samanaikaisuusmalli Tapahtumapohjainen (asynkroninen, ei-estävä) Prosessi-/säiepohjainen (esto)
Muistin käyttö Alhainen yhteyttä kohden Korkeampi yhteyttä kohden
Paras käyttökotelo Paljon liikennettä, staattinen sisältö, kuormituksen tasaus Dynaaminen sisältö ja rikas moduuliekosysteemi
skaalautuvuus Skaalautuu vähemmillä resursseilla Vaatii enemmän laitteistoa prosessien vuoksi
Moduulien käsittely Käännösaikana valitut moduulit Dynaaminen ajonaikana

NGINX:n suunnittelu optimoi suorituskyvyn kuormituksen aikana, kun taas Apache tarjoaa suurempaa joustavuutta dynaamisten moduulien ja laajan kielituen ansiosta.

4) Mitkä ovat NGINX-määritystiedoston keskeiset osat?

NGINX-määritystiedosto (oletuspolku: /etc/nginx/nginx.conf) koostuu strukturoiduista direktiivilohkoista, jotka määrittävät NGINX:n toiminnan:

  • Pääasiallinen konteksti: globaalit asetukset, kuten worker_processes, error_logja pid
  • Tapahtumalohko: hallitsee työntekijöiden yhteyksiä ja moniajoprosessointia
  • HTTP-esto: sisältää HTTP-käsittelyn määritykset (pakkaus, välimuisti, gzip jne.)
    • Palvelinlohko: määrittelee virtuaaliset isännät (verkkotunnukset ja portit)
    • Sijaintilohko: määrittelee reitityssäännöt ja miten tiettyjä URI-osoitteita käsitellään

Nämä lohkot toimivat yhdessä reitittääkseen pyyntöjä, määrittääkseen välityspalvelimen asetukset ja määrittääkseen SSL/TLS:n ja välimuistin.

5) Miten NGINX-kokoonpano ladataan turvallisesti uudelleen ilman käyttökatkoksia?

NGINXin uudelleenlataus päivitetyillä kokoonpanoilla without interrupting active connections, käytät seuraavaa komentoa:

nginx -s reload

tai järjestelmissä, jotka käyttävät systemd:

sudo systemctl reload nginx

Tämä komento antaa pääprosessille signaalin lukea määritystiedostot uudelleen ja käynnistää työprosessit uudelleen katkaisematta olemassa olevia yhteyksiä. Tällaisten saumattomien uudelleenlatausten suorittamisen tunteminen on olennaista ympäristöissä, jotka vaativat korkeaa käytettävyyttä.

6) Kuvaile, miten NGINX asetetaan käänteiseksi välityspalvelimeksi.

Käänteinen välityspalvelin välittää asiakaspyynnöt taustapalvelimille (ylävirran ryhmä) ja palauttaa sitten vastauksen. Alla on tyypillinen NGINX:n käänteisen välityspalvelimen lohko:

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

Tämä asetus parantaa tietoturvaa, tarjoaa kuormituksen jakamisen ja mahdollistaa välimuistin tai nopeusrajoituskäytännöt asiakkaiden ja sovelluspalvelimien välillä.

7) Selitä NGINX:n Master- ja Worker-prosessit.

NGINX:ssä:

  • Pääprosessi hallinnoi kokoonpanoa, käynnistää työprosesseja ja käsittelee etuoikeutettuja toimintoja, kuten portteihin sitomista.
  • Työprosessit hoitaa varsinaisen pyyntöjen käsittelyn – käsittelee saapuvat yhteydet ja suorittaa määritetyt säännöt.

Useiden työryhmien käyttö parantaa samanaikaisuutta ja niitä voidaan säätää käytettävissä olevien suoritinytimien ja liikennevaatimusten mukaan. Roolien jakaminen parantaa suorituskykyä ja vakautta.

AIHEESEEN LIITTYVÄT ARTIKKELIT

8) Miten NGINX:ssä voi rajoittaa määrittelemättömien palvelinnimien käsittelyä?

Hylätäksesi pyynnöt ilman kelvollista Host otsikko NGINX:ssä:

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

Tämä konfiguraatio palauttaa koodin 444, epästandardi NGINX-tila, joka sulkee yhteyden ilman vastausta, hylkää tehokkaasti määrittelemättömät isännät ja parantaa tietoturvaa.

9) Mihin ngx_http_upstream_modulea käytetään?

ngx_http_upstream_module määritellään groups of backend servers (ylävirtaan), joille NGINX voi välittää pyyntöjä käyttämällä direktiivejä, kuten proxy_pass, fastcgi_passtai uwsgi_passTämä mahdollistaa sovellusten skaalaamisen joustavuutta kuormituksen tasaavissa ympäristöissä. Kun useita taustapalvelimia on ryhmitelty, NGINX voi jakaa liikennettä määriteltyjen käytäntöjen perusteella, tukien round-robin- ja muita strategioita.

10) Kuvaile, miten NGINX:iä käytetään staattisen ja dynaamisen sisällön tarjoamiseen.

NGINX on erittäin tehokas palvelemaan staattiset tiedostot (HTML, CSS, kuvat) suoraan optimoitujen tapahtumasilmukoiden ja tiedostojen I/O-mekanismien avulla. dynaaminen sisältö, NGINX välittää pyynnöt taustaprosessoreille, kuten PHP-FPM:lle, Python WSGI-palvelimia tai sovelluskehyksiä FastCGI:n/välityspalvelinmekanismien kautta. Tämä erottelu mahdollistaa NGINX:n erinomaisen toiminnan staattisena tiedostopalvelimena hyödyntäen samalla taustapalveluita dynaamiseen tiedostojen luomiseen varmistaen optimaalisen suorituskyvyn ja skaalautuvuuden.

11) Miten kuormituksen tasapainotus toimii NGINX:ssä, ja mitä eri menetelmiä on käytettävissä?

NGINX tarjoaa vankan kuormituksen tasapainoittaminen kautta upstream direktiivi, joka jakaa liikenteen useille taustapalvelimille suorituskyvyn optimoimiseksi ja korkean käytettävyyden varmistamiseksi. Se tukee useita menetelmiä:

Menetelmä Tuotetiedot Paras käyttökotelo
Round Robin Oletusmenetelmä, joka kierrättää pyyntöjä palvelimien välillä peräkkäin. Tasaisesti jakautuneet työmäärät.
Vähiten yhteydet Lähettää pyynnöt palvelimelle, jolla on vähiten aktiivisia yhteyksiä. Pitkäkestoiset istunnot.
IP Hash Käyttää asiakkaan IP-osoitetta palvelimen valinnan määrittämiseen. Istunnon pysyvyys.
Lyhin aika Saldot perustuvat vasteaikaan ja yhteyksien määrään. Latenssiherkät sovellukset.

NGINX voi myös suorittaa terveystarkastuksia poistaakseen epäterveelliset palvelimet dynaamisesti, varmistaen saumattoman liikenteen kulun ja vikasietoisuuden.

12) Mitä eroa on NGINX:n avoimen lähdekoodin ja NGINX Plussan välillä?

nginx Open Source on yhteisöversio, joka tarjoaa olennaiset web-palvelin-, välityspalvelin- ja kuormituksen tasausominaisuudet. NGINX Plus on kaupallinen versio, joka laajentaa näitä ominaisuuksia yritystason parannuksilla, kuten edistyneellä valvonnalla, istunnon pysyvyydellä, dynaamisella uudelleenkonfiguroinnilla ja aktiivisilla terveystarkistuksilla.

Ominaisuus NGINX avoin lähdekoodi NGINX Plus
Kuormituksen tasapainoittaminen Perus (Round Robin, IP-hajautus) Edistynyt (lyhin aika, dynaaminen uudelleenkonfigurointi)
Seuranta Manuaaliset / ulkoiset työkalut Sisäänrakennettu kojelauta ja API
välimuistia Perus Parannettu huuhteluohjauksella
Tuki vain yhteisö Yritystuki ja päivitykset

Organisaatiot, joilla on kriittisiä työkuormia, valitsevat usein NGINX Plusin sen parannetun luotettavuuden ja havainnoitavuuden vuoksi.

13) Miten välimuisti toteutetaan NGINX:ssä?

NGINX:n välimuisti parantaa vasteaikaa ja vähentää taustajärjestelmän kuormitusta tallentamalla usein käytettyä sisältöä paikallisesti. Se otetaan käyttöön käyttämällä proxy_cache direktiivi. Esimerkki konfiguraatiosta:

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

Välimuistissa olevat vastaukset toimitetaan suoraan levyltä, kun vastaava pyyntö saapuu, ohittaen yläpuolisen käsittelyn. Voit hallita välimuistin vanhenemista käyttämällä proxy_cache_valid ja sulje pois tiettyjä URI-osoitteita proxy_no_cacheTämä mekanismi on ratkaisevan tärkeä paljon liikennettä saaville ympäristöille, kuten uutis- tai verkkokauppasivustoille.

14) Selitä “try_files”-direktiivin tarkoitus ja käyttö.

try_files direktiivi tarkistaa tiedostojen olemassaolon tietyssä järjestyksessä ennen pyynnön välittämistä varasijaintiin. Sitä käytetään yleisesti staattinen sivuston reititys or yksisivuiset hakemukset (SPA).

Esimerkiksi:

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

Tässä NGINX tarkistaa ensin, vastaako pyydetty URI tiedostoa, sitten hakemistoa ja lopuksi reitittää vastaamattomat pyynnöt kohteeseen /index.htmlTämä parantaa tehokkuutta ja käyttökokemusta tarjoamalla välimuistissa olevia tai staattisia tiedostoja suoraan, välttäen tarpeettomia taustakutsuja.

15) Miten NGINX pystyy käsittelemään HTTPS- ja SSL/TLS-päättämistä?

NGINX toimii SSL/TLS-päätevälityspalvelimena, joka käsittelee salauksen ja salauksen purkamisen palvelintasolla ennen salaamattomien pyyntöjen välittämistä ylävirran palveluihin. Esimerkkikokoonpano:

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

Se tukee HTTP-/ 2, OCSP nidonta, HSTSja modernit salausohjelmistot, mikä mahdollistaa turvallisen ja tehokkaan tietoliikenteen. SSL:n päättäminen NGINX:ssä vähentää salauskustannuksia taustapalvelimilla ja yksinkertaistaa varmenteiden hallintaa.

16) Mitä eroa on uudelleenkirjoituksella ja uudelleenohjauksella NGINX:ssä?

molemmat kirjoittaa uudelleen ja kääntää muokata pyyntöjen reititystä, mutta ne eroavat toisistaan ​​perustavanlaatuisesti:

Aspect kirjoittaa uudelleen kääntää
Tyyppi Sisäinen URL-osoitteen uudelleenkirjoitus Ulkoisen asiakkaan uudelleenohjaus
Vastauskoodi 200 (sisäinen) 301/302 (HTTP-uudelleenohjaus)
Näkyvyys Läpinäkyvä käyttäjälle Asiakas näkee uuden URL-osoitteen
Käytä asiaa SEO-ystävälliset URL-osoitteet, reititys Verkkotunnuksen siirto, HTTPS-valvonta

Esimerkiksi:

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

Tämän eron ymmärtäminen on avainasemassa hakukoneoptimoinnin ja reitityslogiikan tehokkaassa optimoinnissa.

17) Miten suojaat NGINX:n yleisiltä haavoittuvuuksilta?

Tietoturvan koventaminen sisältää yhdistelmän parhaita käytäntöjä:

  • Poista palvelintunnukset käytöstä: server_tokens off;
  • Rajoita pyyntömenetelmiä: Salli vain GET, POST ja HEAD.
  • Rajoita puskurin ylivuotoja: Configure client_max_body_size ja client_body_buffer_size.
  • Käytä HTTPS:ää nykyaikaisilla salausmenetelmillä.
  • Ota käyttöön nopeuden rajoittaminen kautta limit_req_zone.
  • Piilota versiotiedot ja poista hakemistolistaus käytöstä.

Lisäksi käyttämällä Verkkosovelluspalomuuri (WAF) pitää ModSecurity with NGINX voi suodattaa haitallista liikennettä. NGINX:n säännöllinen päivittäminen ja tietoturvakorjausten asentaminen on välttämätöntä nollapäivähyökkäysten estämiseksi.

18) Mitä ovat NGINX-muuttujat ja miten niitä käytetään konfiguraatioissa?

NGINX-muuttujat tallentavat dynaamista dataa, jota käytetään konfiguraatioissa ja lokien käsittelyssä. Ne voivat edustaa pyyntöjen otsikoita, asiakkaiden IP-osoitteita tai laskettuja arvoja. Esimerkkejä ovat $remote_addr, $host, $uri, $request_methodja $upstream_addr.

Esimerkiksi:

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

Muuttujat lisäävät joustavuutta mahdollistamalla ehdollisen reitityksen ja mukautetun lokikirjauksen. Voit myös määrittää mukautettuja muuttujia käyttämällä set direktiivi, joka auttaa modulaarisessa kokoonpanosuunnittelussa.

19) Miten NGINX:ssä voi asettaa nopeusrajoituksen?

Nopeudenrajoitus hallitsee sitä, kuinka usein käyttäjät voivat lähettää pyyntöjä, suojaten raa'alta voimalta ja palvelunestohyökkäyksiltä. Se konfiguroidaan käyttämällä limit_req_zone direktiivi:

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

Tämä sallii yhden pyynnön sekunnissa ja viiden pyynnön purskeen. NGINX hylkää ylimääräiset pyynnöt tai viivästyttää niitä kokoonpanon mukaan. Nopeuden rajoittaminen varmistaa resurssien oikeudenmukaisen käytön ja estää palvelimen ylikuormituksen.

20) Mitkä ovat NGINX:n käytön edut ja haitat käänteisenä välityspalvelimena?

NGINX käänteisenä välityspalvelimena tarjoaa lukuisia etuja, mutta myös joitakin kompromisseja:

edut Haitat
Korkea suorituskyky ja samanaikaisuuden käsittely Vaatii manuaalisen säädön laajamittaisissa käyttöönotoissa
SSL-päättäminen ja keskitetty suojaus Rajoitettu dynaamisen moduulin tuki (käännettävä)
Kuormituksen tasapainotus ja välimuistin tuki Monimutkainen määritys uusille käyttäjille
Sovelluskerroksen suodatus Natiivin dynaamisen sisällön toteutuksen puute

Sen edut ovat huomattavasti suuremmat kuin rajoitukset useimmissa yritysskenaarioissa, mikä tekee NGINX:stä välttämättömän osan nykyaikaista web-infrastruktuuria.

21) Miten NGINX:n suorituskykyä ja kuntoa voi seurata tuotannossa?

NGINX:n valvonta on ratkaisevan tärkeää pullonkaulojen, vikojen ja epänormaalin liikennekäyttäytymisen tunnistamiseksi. Käytettävissä on useita lähestymistapoja:

  1. Sisäänrakennettu tilamoduuli (stub_status):

    Näyttää aktiiviset yhteydet, käsitellyt pyynnöt ja luku-/kirjoitustilat. Esimerkki:

    location /nginx_status {
    stub_status;
    allow 127.0.0.1;
    deny all;
}
  2. NGINX Plus -hallintapaneeli: Tarjoaa reaaliaikaisia ​​mittareita REST API:n ja graafisen käyttöliittymän kautta.
  3. Kolmannen osapuolen integraatiot: Työkalut, kuten Prometheus, Grafana, Datadog tai ELK, voivat kerätä mittareita ja lokeja.
  4. Käyttö- ja virhelokit: Säännöllinen lokien kierrätys ja analysointi työkaluilla, kuten GoAccess tai AWStats, parantavat havaittavuutta.

Valvonta auttaa varmistamaan käyttöajan, vikojen nopean havaitsemisen ja kapasiteetin suunnittelun.

22) Mitä eroa on proxy_pass- ja fastcgi_pass-direktiiveillä?

Molemmat direktiivit välittävät pyynnöt taustapalveluille, mutta ne on suunniteltu eri protokollille:

Direktiivi Tarkoitus Taustaprotokolla Käyttöesimerkki
proxy_pass Välittää HTTP- tai HTTPS-pyynnöt taustapalvelimille HTTP Revvälityspalvelimena toimivat web-rajapinnat tai mikropalvelut
fastcgi_pass Lähettää pyynnöt FastCGI-prosessorille FastCGI PHP-FPM, Python FastCGI-sovellukset

Esimerkiksi:

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

Yhteenvetona, käytä proxy_pass yleisille HTTP-taustapalvelimille ja fastcgi_pass dynaamisille kieliympäristöille, kuten PHP:lle.

23) Miten gzip-pakkaus määritetään NGINX:ssä ja mitkä ovat sen hyödyt?

Gzip-pakkauksen käyttöönotto NGINX:ssä vähentää kaistanleveyden käyttöä ja parantaa latausaikaa pakkaamalla tekstipohjaiset vastaukset ennen niiden lähettämistä asiakkaille.

Esimerkki kokoonpanosta:

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

Hyödyt:

  • Pienentää tiedostojen siirtokokoja jopa 70 %.
  • Parantaa ensimmäisen tavun lukemiseen kuluvaa aikaa (TTFB) ja sivun suorituskykypisteitä.
  • Säästää kaistanleveyden kustannuksia, mikä on erityisen hyödyllistä mobiilikäyttäjille.

Sitä ei kuitenkaan pitäisi soveltaa jo pakattuihin tiedostoihin (esim. .zip, .jpg, .png) suorittimen kuormituksen välttämiseksi.

24) Mitä parhaita käytäntöjä NGINX:n virittämiseen suurta liikennettä varten on olemassa?

Suuren liikenteen optimointi edellyttää resurssien ja määritysparametrien huolellista virittämistä:

alue Direktiivi Suositeltu käytäntö
työntekijät worker_processes auto; Yhdistä suorittimen ytimet
Liitännät worker_connections 4096; Lisää samanaikaisuutta
Pitää hengissä keepalive_timeout 65; Optimoi asiakkaan uudelleenkäyttö
filee DescriptTAI OS ulimit -n Nosta avoimien sokettien rajoja
välimuistia proxy_cache_path Vähennä taustajärjestelmän kuormitusta
gzip gzip on; Pakkaa tekstivastaukset

Lisäksi käyttämällä asynkroninen levy-I/O, kuormituksen tasapainoittaminenja alkuvaiheen terveystarkastukset varmistaa vakauden ja nopeuden massiivisten samanaikaisten pyyntöjen aikana.

25) Miten NGINX käsittelee WebSocket-yhteyksiä?

WebSocketit mahdollistavat kaksisuuntaisen kommunikaation asiakkaan ja palvelimen välillä – mikä on ratkaisevan tärkeää reaaliaikaisille sovelluksille. NGINX tukee tätä natiivisti asianmukaisen otsikkovälityksen avulla.

Esimerkki kokoonpanosta:

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

Avainkohdat:

  • Upgrade ja Connection otsikot ovat pakollisia.
  • Varmista, että NGINX käyttää HTTP/1.1-protokollaa pysyville TCP-yhteyksille.
  • Kuormituksen tasapainottaminen WebSocketsissa saattaa vaatia tarttuvia istuntoja käyttämällä ip_hash.

Tämä kokoonpano tukee sovelluksia, kuten chattia, osakekauppaa tai pelaamista.

26) Mikä on ”worker_rlimit_nofile”-direktiivin tarkoitus?

worker_rlimit_nofile määrittää työprosessien käytettävissä olevien avointen tiedostokuvaajien enimmäismäärän. Tämä rajoitus vaikuttaa suoraan siihen, kuinka monta samanaikaista yhteyttä NGINX pystyy käsittelemään. Esimerkki:

worker_rlimit_nofile 100000;

Tämän rajan nostaminen on elintärkeää korkean samanaikaisuuden järjestelmille (kuten API-yhdyskäytäville tai suoratoistoalustoille). Käyttöjärjestelmän raja (ulimit -n) on myös nostettava vastaamaan tätä arvoa johdonmukaisuuden varmistamiseksi.

27) Miten NGINX:iä voidaan käyttää URL-osoitteiden uudelleenkirjoittamiseen tai automaattiseen uudelleenohjaukseen HTTPS:ään?

HTTP:n uudelleenohjaus HTTPS:ksi varmistaa turvallisen tiedonsiirron. Esimerkki:

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

Tämä kokoonpano antaa 301 pysyvä uudelleenohjaus HTTP:stä HTTPS:ään. Tarkempaa hallintaa varten uudelleenkirjoitussäännöt voivat pakottaa polkukohtaisen uudelleenohjauksen:

rewrite ^/oldpath$ /newpath permanent;

Automaattinen HTTPS-valvonta parantaa hakukoneoptimointia, estää välikäsihyökkäykset ja ylläpitää yhtenäistä käyttökokemusta.

28) Mitkä ovat yleisiä syitä "502 Bad Gateway" -virheille NGINX:ssä?

”502 Bad Gateway” -virhe tarkoittaa, että välityspalvelimena toimiva NGINX ei onnistunut vastaanottamaan kelvollista vastausta ylävirran palvelimelta. Yleisiä syitä ovat:

  • Taustapalvelimen kaatuminen tai käyttökatkos.
  • virheellinen proxy_pass URL-osoite tai soketin polku.
  • Ylävirran aikakatkaisu (proxy_read_timeout liian matala).
  • Palomuuri tai SELinux estää ylävirran yhteydet.
  • Väärin konfiguroidut FastCGI-parametrit (PHP:lle).

Virheenkorjausta varten tarkista virhelokit (/var/log/nginx/error.log), varmista ylävirran saavutettavuus ja testaa taustajärjestelmän vastauksia suoraan kautta curl.

29) Miten NGINX tukee mikropalveluita ja konttipohjaisia ​​arkkitehtuureja (esim. Docker, Kubernetes)?

NGINX on ihanteellinen mikropalveluympäristöt kevyen rakenteensa ja käänteisen välityspalvelimen toiminnallisuutensa ansiosta. Dockerissa tai Kubernetesissa se toimii seuraavasti:

  • Sisäänpääsyn ohjain: Hallitsee ulkoista HTTP/S-liikennettä sisäisiin palveluihin.
  • Palveluyhdyskäytävä: Suorittaa reitityksen, kuormituksen tasapainotuksen ja todennuksen.
  • Sivuvaunun välityspalvelin: Parantaa palveluverkkojen (esim. Istio) vikasietoisuutta ja havaittavuutta.

NGINX-kokoonpanoja voidaan päivittää dynaamisesti Kubernetes ConfigMapsin kautta, mikä mahdollistaa keskitetyn liikenteenhallinnan ja SSL-hallinnan. Sen modulaarinen lähestymistapa sopii täydellisesti yhteen konttipohjaisten ja pilvinatiivien käyttöönottojen kanssa.

30) Millä eri tavoilla NGINX:n tietoturvaa voidaan parantaa tuotantojärjestelmissä?

NGINX-tietoturvan parantaminen vaatii monikerroksisen konfiguroinnin:

  1. SSL/TLS-suojauksen vahvistaminen: Käytä moderneja salausmenetelmiä, poista SSLv3/TLSv1.0 käytöstä.
  2. Rajoita HTTP-metodeja: Salli vain turvalliset verbit (GET, POST, HEAD).
  3. Suojausotsikot: 
    add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
  4. Piilota versiotiedot: server_tokens off;
  5. Ota käyttöön nopeuden rajoittaminen ja käyttöoikeuksien hallinta.
  6. Integroi WAF tai Fail2Ban raa'an voiman estämiseksi.

Yhdessä nämä toimenpiteet luovat kovetetun, tuotantoluokan NGINX-ympäristön, joka on vastustuskykyinen yleisille hyökkäyksille.

31) Kuinka voit debugata NGINX-ongelmia tehokkaasti?

NGINX-virheenkorjaus sisältää lokien, määritystiedostojen ja prosessien tilojen systemaattisen analysoinnin. Keskeiset vaiheet ovat:

  1. Tarkista syntaksi:
    2. nginx -t
  2. Vahvistaa kokoonpanon ennen uudelleenlatauksia.

    3. Ota käyttöön virheenkorjausloki:

    error_log /var/log/nginx/error.log debug;
  3. Tarjoaa yksityiskohtaisen ajonaikaisen diagnostiikan.

    4. Analysoi käyttölokeja: Tunnista vastauskoodit ja pyyntökuviot käyttämällä:

    tail -f /var/log/nginx/access.log
  4. Testaa yhteys: Käyttää curl -v or wget varmistaaksesi taustajärjestelmän saavutettavuuden.
  5. Aktiivisten yhteyksien valvonta: kautta stub_status or netstat.

NGINX:n työprosessien, puskurirajojen ja ylävirran vastausten ymmärtäminen auttaa paikantamaan pullonkaulat nopeasti tuotantojärjestelmissä.

32) Miten NGINX-lokikirjaus määritetään ja mitä mukautetut lokitiedostomuodot ovat?

NGINX tarjoaa joustavia lokikirjausmekanismeja access_log ja error_log direktiivejä.

Esimerkki kokoonpanosta:

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;

Voit määrittää mukautetut muodot sisällyttää mittareita, kuten $upstream_addr, $request_timetai $bytes_sent.

Edistyneen havaittavuuden takaamiseksi lokit lähetetään usein osoitteeseen ELK, Loki tai Splunk reaaliaikaista analyysia ja koontinäyttöä varten.

33) Mikä on proxy_buffering-direktiivin rooli NGINX:ssä?

proxy_buffering Määrittää, puskuroiko NGINX vastaukset ylävirran palvelimilta ennen niiden lähettämistä asiakkaille.

Asetus Tuotetiedot Käytä asiaa
proxy_buffering on; Buffers koko vaste optimoidun läpimenon saavuttamiseksi Oletusarvo; parantaa suorituskykyä
proxy_buffering off; Suoratoistaa dataa suoraan asiakkaille ilman puskurointia Reaaliaikainen suoratoisto tai API:t

Esimerkiksi puskuroinnin poistamiseksi käytöstä:

location /stream/ {
    proxy_buffering off;
}

Puskuroinnin poistaminen käytöstä on ihanteellista chat- tai suoratoistopalveluille, mutta se voi heikentää tavallisen verkkoliikenteen läpimenoaikaa.

34) Selitä, miten NGINX-välimuisti voidaan mitätöidä tai tyhjentää.

NGINX Open Source ei sisällä sisäänrakennettua välimuistin tyhjennystä, mutta se voidaan saavuttaa useilla tavoilla:

  1. Manuaalinen puhdistus: Poista tiedostot välimuistihakemistosta. 
    rm -rf /var/cache/nginx/*
  2. Kolmannen osapuolen moduuli: Käyttää ngx_cache_purge tyhjentää HTTP-pyynnön kautta: 
    location ~ /purge(/.*) {
    proxy_cache_purge my_cache $host$1;
}
  3. NGINX Plus -ominaisuus: Sallii API-pohjaisen välimuistin dynaamisen tyhjennyksen.

Tyhjentäminen varmistaa, että vanhentunut sisältö korvataan nopeasti, mikä säilyttää sisällön tuoreuden ja yhdenmukaisuuden CDN- tai usean solmun käyttöönotoissa.

35) Miten NGINX käsittelee yhteyden aikakatkaisut?

NGINX tarjoaa useita aikakatkaisudirektiivejä, joilla hallitaan asiakkaan tai ylävirran vastausten odottamisaikaa:

Direktiivi Tarkoitus Oletusarvo (t)
client_body_timeout Odotusaika asiakkaan keholle 60
client_header_timeout Asiakkaan otsikon odotusaika 60
keepalive_timeout Käyttämättömät keepalive-yhteydet 75
send_timeout Aika lähettää tiedot asiakkaalle 60
proxy_read_timeout Odotusaika ylävirran vastaukselle 60

Oikea viritys välttää tarpeettomat katkokset ja varmistaa sujuvamman käyttökokemuksen vaihtelevissa verkko-olosuhteissa.

36) Miten toteutat vihreän käyttöönoton NGINX:n avulla?

Jonkin sisällä sinivihreä käyttöönottokaksi ympäristöä (sininen = aktiivinen, vihreä = valmiustila) toimii samanaikaisesti. NGINX toimii niiden välillä liikenteen reitittimenä.

Esimerkki kokoonpanosta:

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

Kun uusi versio (vihreä) on testattu ja varmistettu, liikenne vaihdetaan päivittämällä ylävirran määritelmä ja lataamalla NGINX uudelleen (nginx -s reload).

Tämä menetelmä varmistaa nolla seisokkiaika sovelluspäivitysten tai palautusten aikana.

37) Mikä on nopeutta rajoittava purske ja miten se parantaa NGINX:n suorituskykyä?

burst Nopeudenrajoituksen parametri sallii lyhyiden liikennepiikkien tilapäisen läpipääsyn ilman välitöntä hylkäämistä.

Esimerkiksi:

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

Tässä viisi ylimääräistä pyyntöä hyväksytään välittömästi ennen rajoituksen käyttöönottoa.

Tämä tekniikka tasoittaa liikennepiikkejä ja ylläpitää yhtenäistä käyttökokemusta ylikuormittamatta taustajärjestelmiä.

38) Miten NGINX käsittelee IPv6- ja dual-stack-ympäristöjä?

NGINX tukee täysin IPv6:ta sekä palvelin- että ylävirran kokoonpanoissa. Esimerkki:

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

Kaksoispinon tuki (IPv4 + IPv6) saavutetaan sisällyttämällä molemmat:

listen 80;
listen [::]:80;

IPv6-yhteensopivuus varmistaa laajemman saatavuuden, erityisesti mobiili- ja kansainvälisille asiakkaille, ja on ratkaisevan tärkeää nykyaikaisten internet-standardien noudattamisen kannalta.

39) Miten NGINX-kuormituksen tasapainotuksessa määritetään tarttuvat istunnot?

Sticky-istunnot varmistavat, että saman asiakkaan pyynnöt reititetään aina samalle taustapalvelimelle.

  1. Käyttäminen ip_hash: 
    upstream backend {
    ip_hash;
    server app1.example.com;
    server app2.example.com;
}
  2. NGINX Plus -tahmea eväste:
    Edistynyt istunnon pysyvyys konfiguroitavilla evästeillä.

Sticky-istunnot ovat elintärkeitä tilallisille sovelluksille, kuten käyttäjien koontinäytöille tai ostoskoreille, sillä ne varmistavat istuntotietojen yhdenmukaisuuden ilman jaettua tallennustilaa.

40) Mitkä ovat NGINX:n pääasialliset lokitasot ja miten ne eroavat toisistaan?

NGINX tukee hierarkkisia lokitasoja virhelokin yksityiskohtaisuuden hallitsemiseksi.

Taso Tuotetiedot
debug Yksityiskohtaista tietoa vianmäärityksestä (hyvin pitkäveteistä)
info Yleisiä tietoja suorituksenaikaisesta toiminnasta
notice Merkittävät mutta ei-kriittiset tapahtumat
warn Mahdollisia ongelmia tai virheellisiä määrityksiä
error Operahuomion vaativat toiminnalliset virheet
crit, alert, emerg Kriittiset viat ja järjestelmähälytykset

Esimerkki kokoonpanosta:

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

Lokitasojen säätäminen ympäristön mukaan (virheenkorjaus testiympäristössä, varoitus tuotannossa) auttaa ylläpitämään tasapainoa näkyvyyden ja suorituskyvyn välillä.

41) Miten vertailet NGINX:n suorituskykyä?

NGINX-vertailuanalyysiin kuuluu läpimenon, latenssin ja samanaikaisuuden mittaaminen kokoonpanon pullonkaulojen tunnistamiseksi. Yleisiä työkaluja ovat:

ApacheBench (ab):

ab -n 10000 -c 100 http://example.com/
  • Testit vaativat sekä määrän että samanaikaisuuden.
  • työ: Tarjoaa yksityiskohtaiset latenssiprosenttiilit ja pyyntöjen määrät.
  • piiritys / httperf: Simuloi todellista liikennettä.
  • Grafana + Prometheus: Seuraa live-suoritusmittareita.

Vertailuanalyysien tulisi mitata parametreja, kuten requests per second (RPS), time per requestja error rate.

Viritysmuuttujat, kuten worker_processes, worker_connectionsja keepalive_timeout parantaa merkittävästi havaittua läpimenoaikaa.

42) Miten NGINX voidaan integroida CI/CD-putkistojen kanssa?

NGINX integroituu saumattomasti seuraaviin: CI / CD automatisoituun käyttöönottoon, testaukseen ja konfiguraation hallintaan. Yleisiä lähestymistapoja ovat:

  • Infrastruktuuri koodina (IaC): Hallitse konfiguraatioita Ansible-, Terraform- tai Helm-kaavioilla.
  • Docker-säiliöt: Luo ja ota käyttöön NGINX-levykuvia CI-työkaluilla (Jenkins, GitLab CI tai GitHub Actions).
  • Automaattinen testaus: Vahvista konfiguraatiot käyttämällä nginx -t putkilinjan vaiheissa.
  • Sinivihreä / Canary Käyttöönoton automatisointi: Päivitä ylävirran palvelimet dynaamisesti käyttöönoton aikana.

Esimerkki GitLab CI -koodinpätkästä:

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

Automatisoitu käyttöönotto varmistaa yhdenmukaiset, versiohallitut ja luotettavat NGINX-käyttöönotot.

43) Selitä NGINX Ingress Controllerin rooli Kubernetesissa.

NGINX Ingress Controller hallinnoi Kubernetes-palveluihin tulevaa liikennettä. Se muuntaa Kubernetes Ingress -resurssit dynaamisesti NGINX-kokoonpanoiksi.

Keskeiset toiminnot:

  • Reitittää HTTP/S-pyynnöt oikeaan palveluun.
  • Tarjoaa SSL-päättämistä, nopeusrajoitusta ja URL-osoitteen uudelleenkirjoittamista.
  • Tukee kuormituksen tasausta podien välillä.
  • Mahdollistaa merkinnät hienojakoista hallintaa varten (esim. uudelleenkirjoituskohde, välityspalvelimen koko).

Esimerkki YAML-sisällön sisääntulosta:

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

Tämä arkkitehtuuri erottaa liikenteen reitityslogiikan konttien käyttöönotosta joustavan skaalautuvuuden takaamiseksi.

44) Miten NGINX käsittelee HTTP/2:ta ja mitkä ovat sen edut?

NGINX tukee täysin HTTP-/ 2, HTTP/1.1:n seuraaja, joka parantaa tehokkuutta multipleksoinnin ja otsikoiden pakkauksen avulla.

HTTP/2:n ottaminen käyttöön:

server {
    listen 443 ssl http2;
    ...
}

edut:

Ominaisuus Tuotetiedot
Kanavointi Useita pyyntöjä TCP-yhteyttä kohden
Otsikon pakkaus (HPACK) Vähentää kaistanleveyden käyttöä
Palvelimen työntö Lähettää resursseja asiakkaille ennakoivasti
Nopeampi TLS Virtaviivaistetut ja turvalliset kättelyt

HTTP/2 vähentää merkittävästi viivettä ja sivujen latausaikoja, erityisesti nykyaikaisissa verkkosovelluksissa, joissa on paljon resursseja.

45) Mitä eroa on NGINX:n ylävirran keepalive-toiminnolla ja yhteyksien uudelleenkäytöllä?

Ylävirran säilytys ylläpitää pysyviä yhteyksiä taustapalvelimiin, mikä vähentää TCP-kättelyn aiheuttamaa ylimääräistä kuormitusta. Esimerkki:

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

Ero:

Aspect Pitää hengissä Yhteyden uudelleenkäyttö
Laajuus NGINX:n ja ylävirran välillä NGINX:n ja asiakkaiden välillä
Tarkoitus Taustajärjestelmän optimointi Frontend-suorituskyky
Konfigurointi keepalive sisällä upstream keepalive_timeout in server lohko

Molemmat tekniikat vähentävät viivettä, mutta palvelevat eri viestintäkerroksia (asiakaspuoli vs. palvelinpuoli).

46) Miten NGINX:n voi dynaamisesti uudelleenkonfiguroida käynnistämättä sitä uudelleen?

Uusien määritysten dynaaminen käyttöönotto ilman seisokkeja, Käytä reload mekanismi:

nginx -t && nginx -s reload

Tämä viestii siitä, että pääprosessi luoda uusia työntekijöitä päivitetyillä kokoonpanoilla samalla kun vanhat suljetaan sulavasti.

NGINX Plus -sovelluksessa muutoksia voidaan tehdä API:n kautta (esim. ylävirran palvelimien dynaaminen lisääminen):

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

Tämä ominaisuus tukee nollakäyttöisiä käyttöönottoja nykyaikaisissa DevOps-putkissa.

47) Mitkä ovat käänteisen ja eteenpäin suuntautuvan välityspalvelimen keskeiset erot NGINX:ssä?

Aspect Reverse Välityspalvelin Välitä välityspalvelin
Asiakkaan näkyvyys Asiakkaat eivät ole tietoisia taustapalvelimista Palvelimet eivät tiedä asiakkaan identiteettiä
Ensisijainen käyttö Kuormituksen tasapainotus, välimuisti, SSL-päättäminen Suodatus, anonymiteetti, käyttöoikeuksien hallinta
Yhteinen käyttötapaus Verkkoliikenteen jakautuminen Yritys- tai suojattu lähtevä selailu
NGINX-tuki Alkuperäinen ja laajalti käytetty Vaatii mukautetun määrityksen

Esimerkki (välityspalvelin):

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

RevErse-välityspalvelin on edelleen hallitseva käyttötapaus, erityisesti API-yhdyskäytävien ja mikropalveluarkkitehtuurien osalta.

48) Miten NGINX:iä voidaan käyttää API-nopeuden rajoittamiseen ja kuristamiseen?

Nopeuden rajoittaminen suojaa API-rajapintoja väärinkäytöltä ja varmistaa oikeudenmukaisen käytön. Esimerkkikonfiguraatio:

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

Mekanismi:

  • limit_req_zone: Määrittää jaetun muistin vyöhykkeen ja nopeuden.
  • burstSallii rajoitetut tilapäiset piikit.
  • nodelay: Valvoo rajoituksia välittömästi.

Tämä kokoonpano varmistaa, että jokainen asiakkaan IP-osoite voi tehdä vain 10 pyyntöä sekunnissa, mutta sallii lyhyet purskeet.

49) Mitkä ovat tyypillisiä NGINX:n käyttötapauksia yritystason DevOps-ympäristöissä?

Yritysten DevOps-ekosysteemeissä NGINX:llä on useita kriittisiä rooleja:

  1. Verkkopalvelin: Tehokas staattinen sisällön toimitus.
  2. Reverse-välityspalvelin / kuormituksen tasaaja: Liikenteenhallinta mikropalveluiden välillä.
  3. API-yhdyskäytävä: Todennus, reititys ja rajoitus.
  4. Sisäänpääsyn ohjain: Kubernetes-klustereille.
  5. Sisällön välimuistikerros: Vähentää taustajärjestelmän kuormitusta.
  6. SSL-suojauksen päätepiste: Keskitetty varmenteiden hallinta.
  7. Seurannan päätepiste: Mittarit ja havaittavuuden integrointi.

Kevyt kokonsa ja modulaarinen suunnittelunsa tekevät NGINX:stä korvaamattoman CI/CD-putkistoissa, hybridipilvissä ja korkean käytettävyyden klustereissa.

50) Mitkä ovat NGINX:n ja HAProxyn tärkeimmät erot kuormituksen tasapainotuksessa?

Molemmat ovat tehokkaita kuormituksen tasaajia, mutta ne eroavat toisistaan ​​painopisteen ja arkkitehtuurin suhteen:

Ominaisuus nginx HAProxy
Ensisijainen rooli Web-palvelin + käänteinen välityspalvelin Dedikoitu TCP/HTTP-kuormituksen tasaaja
Konfiguraatioiden yksinkertaisuus Helpompi verkkopohjaisille työkuormille Monimutkainen mutta tarkempi hallinta
Tason tuki L7 (HTTP), osittainen L4 L4 ja L7 täynnä
Dynaaminen uudelleenkonfigurointi Rajoitettu (avoimen lähdekoodin) Natiivit ajonaikaiset päivitykset
Suorituskyky Erinomainen sekakuormille Erinomainen raakakuormituksen tasapainotukseen
Lisäominaisuudet Välimuisti, pakkaus, staattinen sisältö Terveystarkastukset, tikkupöydät

Yritykset usein yhdistyvät NGINX (käyttöliittymä) ja HAProxy (taustajärjestelmä) optimaalisen reitityksen ja skaalautuvuuden takaamiseksi.

🔍 NGINX:n parhaat haastattelukysymykset tosielämän skenaarioilla ja strategisilla vastauksilla

1) Mikä on NGINX ja miksi sitä käytetään yleisesti tuotantoympäristöissä?

Ehdokkaalta odotetaan: Haastattelija haluaa arvioida NGINX-perustietämystäsi ja ymmärrystäsi sen käytännön arvosta reaalimaailman järjestelmissä.

Esimerkki vastauksesta: ”NGINX on tehokas web-palvelin ja käänteinen välityspalvelin, joka tunnetaan tapahtumapohjaisesta arkkitehtuuristaan. Sitä käytetään yleisesti tuotantoympäristöissä, koska se pystyy käsittelemään suuren määrän samanaikaisia ​​yhteyksiä tehokkaasti ja kuluttamaan vähemmän järjestelmäresursseja kuin perinteiset web-palvelimet.”

2) Voitko selittää NGINX:n ja Apachen välisen eron?

Ehdokkaalta odotetaan: Haastattelija arvioi kykyäsi vertailla teknologioita ja valita oikea työkalu käyttötapausten perusteella.

Esimerkki vastauksesta: ”NGINX käyttää asynkronista, ei-estävää arkkitehtuuria, mikä tekee siitä tehokkaamman suuren liikenteen ja staattisen sisällön käsittelyssä. Apache käyttää prosessipohjaista mallia, joka voi olla joustavampi dynaamisissa kokoonpanoissa, mutta voi kuluttaa enemmän resursseja raskaan kuormituksen alaisena.”

3) Miten NGINX toimii käänteisenä välityspalvelimena?

Ehdokkaalta odotetaan: Haastattelija haluaa varmistaa, että ymmärrät käänteisen välityspalvelimen käsitteet ja miten NGINX sopii nykyaikaisiin arkkitehtuureihin.

Esimerkki vastauksesta: ”NGINX toimii käänteisenä välityspalvelimena vastaanottamalla asiakaspyyntöjä ja välittämällä ne taustapalvelimille. Sitten se palauttaa palvelimen vastaukset asiakkaalle, mikä parantaa tietoturvaa, kuormituksen jakautumista ja yleistä suorituskykyä.”

4) Kuvaile tilannetta, jossa käytit NGINX:iä kuormituksen tasapainottamiseen.

Ehdokkaalta odotetaan: Haastattelija odottaa käytännön kokemusta ja kykyäsi soveltaa NGINX-ominaisuuksia todellisissa tilanteissa.

Esimerkki vastauksesta: ”Edellisessä roolissani konfiguroin NGINX:n jakamaan liikennettä useiden sovelluspalvelimien kesken käyttämällä round-robin- ja vähiten yhteyksiä vaativia algoritmeja. Tämä lähestymistapa paransi sovellusten saatavuutta ja esti yksittäisen palvelimen muodostumisen pullonkaulaksi.”

5) Miten SSL- ja HTTPS-konfiguraatiot käsitellään NGINX:ssä?

Ehdokkaalta odotetaan: Haastattelija haluaa arvioida ymmärrystäsi tietoturvan parhaista käytännöistä ja konfiguraationhallinnasta.

Esimerkki vastauksesta: ”Aiemmassa työssäni konfiguroin SSL:n asentamalla varmenteita, ottamalla käyttöön HTTPS-kuuntelijat ja valvomalla vahvoja salaussarjoja. Toteutin myös HTTP:stä HTTPS:ään uudelleenohjauksen varmistaakseni turvallisen tiedonsiirron kaikkien päätepisteiden välillä.”

6) Mitä toimenpiteitä tekisit vianmääritykseen NGINX:ssä ilmenevän 502 Bad Gateway -virheen yhteydessä?

Ehdokkaalta odotetaan: Haastattelija testaa ongelmanratkaisutaitojasi ja vianmääritysmenetelmiäsi.

Esimerkki vastauksesta: "Aloittaisin tarkistamalla NGINX-virhelokit taustajärjestelmän yhteysongelmien tunnistamiseksi. Sitten tarkistaisin, että ylävirran palvelimet ovat käynnissä, vahvistaisin oikeat välityspalvelinasetukset ja varmistaisin, että aikakatkaisut on määritetty oikein."

7) Miten optimoit NGINX:n suorituskyvyn paljon liikennettä käyttäville sovelluksille?

Ehdokkaalta odotetaan: Haastattelija haluaa tietää, miten lähestyt suorituskyvyn hienosäätöä ja skaalautuvuutta.

Esimerkki vastauksesta: ”Edellisessä työssäni optimoin NGINX:n ottamalla käyttöön gzip-pakkauksen, virittämällä työprosesseja ja määrittämällä staattisen sisällön välimuistin. Nämä muutokset lyhensivät merkittävästi vasteaikoja ja palvelimen kuormitusta.”

8) Voitko selittää, miten NGINX käsittelee staattista ja dynaamista sisältöä?

Ehdokkaalta odotetaan: Haastattelija arvioi ymmärrystäsi pyyntöjen käsittelystä ja suorituskyvyn optimoinnista.

Esimerkki vastauksesta: ”NGINX tarjoaa staattista sisältöä suoraan ja erittäin tehokkaasti tiedostojärjestelmästä. Dynaamisen sisällön osalta se välittää pyynnöt sovelluspalvelimille tai palveluille, kuten PHP-FPM, jolloin jokainen komponentti voi keskittyä siihen, mitä se parhaiten osaa.”

9) Miten NGINX-kokoonpanon muutoksia hallitaan ja testataan turvallisesti?

Ehdokkaalta odotetaan: Haastattelija haluaa ymmärtää lähestymistapasi luotettavuuteen ja riskien vähentämiseen.

Esimerkki vastauksesta: "Vahvistan määritysmuutokset NGINX-määritystestikomennolla ennen palvelun uudelleenkäynnistystä. Sovellan muutoksia myös ylläpitojaksojen aikana ja seuraan lokeja tarkasti käyttöönoton jälkeen."

10) Kuvaile tilannetta, jossa jouduit ratkaisemaan nopeasti NGINX:ään liittyvän käyttökatkoksen.

Ehdokkaalta odotetaan: Haastattelija arvioi kykyäsi toimia paineen alla ja kommunikoida tehokkaasti tilanteissa.

Esimerkki vastauksesta: ”Edellisessä roolissani tapahtui käyttökatkos väärin konfiguroidun ylävirran palvelun vuoksi. Tunnistin ongelman nopeasti lokien avulla, palautin määritykset ja tiedotin tilannepäivityksistä sidosryhmille, kunnes täysi palvelu oli palautettu.”

Tiivistä tämä viesti seuraavasti: