Nginxi konfiguratsioon, mis hoiab saidid kiirena

Avaldatud 19. septembril 2026

Sait võib näida täiesti korras, kuni väike Nginxi konfiguratsiooniviga muudab tavapärase juurutuse 502 veaks, SSL-hoiatuseks või ümbersuunamistsükliks, mis ei vii külastajaid kuhugi kasulikku. Nginx on kiire ja töökindel, kuid see nõuab täpsust: üks vales kohas olev direktiiv võib muuta kogu saidi käitumist. Hea uudis on see, et korrastatud lähenemine muudab Nginxi konfiguratsiooni palju vähem müstiliseks.

See juhend keskendub sätetele, mis on veebisaitide majutamisel kõige olulisemad: serveriplokid, PHP käsitlemine, HTTPS, ümbersuunamised, staatilised failid, vahemällu salvestamine ja ohutu testimine. Te ei pea pähe õppima iga Nginxi direktiivi. Te peate mõistma, millised otsused mõjutavad teie saiti ja kuidas neid kontrollida enne, kui need teie külastajaid mõjutavad.

Alustage selge Nginxi konfiguratsioonistruktuuriga

Enamik Linuxi paigaldusi eraldab globaalsed sätted üksikute veebisaitide sätetest. Peamine konfiguratsioonifail, mis asub tavaliselt asukohas /etc/nginx/nginx.conf, juhib tööprotsesse, logimist, tihendamist ja kaasatud konfiguratsioonikatalooge. Üksikud saidid asuvad tavaliselt kataloogis nagu sites-available, sites-enabled või conf.d.

See eraldatus on praktilisel põhjusel kasulik: globaalseid sätteid tuleks muuta hoolikalt ja harva, samal ajal kui veebisaidi taseme sätted vajavad regulaarset tähelepanu. Uus domeen, testkeskkonna sait või ümbersuunamisreegel kuulub selle saidi serveriplokki, mitte põhifaili.

Enne millegi muutmist tuvastage aktiivne konfiguratsioon ja testige seda:

bash nginx -t

Kui test õnnestub, laadige Nginx uuesti ilma aktiivseid ühendusi katkestamata:

bash systemctl reload nginx

Tavapäraste konfiguratsioonimuudatuste jaoks kasutage reload. Täielik taaskäivitamine on mõnikord vajalik, kuid see ei ole esimene samm, kui värskendate virtuaalhosti. Sellised väikesed harjumused hoiavad ära selle, et viieminutilisest ülesandest saaks hilisõhtune taastamistöö.

Looge iga veebisaidi jaoks üks serveriplokk

Serveriplokk ütleb Nginxile, millist domeeni see teenindab, kus veebisaidi failid asuvad ja kuidas päringuid tuleks käsitleda. Mõelge sellest kui ühe veebisaidi vastuvõtulauast. Kui mitu domeeni jagavad üht serverit, siis just korrastatud serveriplokk hoiab liikluse õiges kohas.

Põhiline HTTP-sait võib välja näha selline:

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

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

server_name peaks loetlema kõik hostinimed, mida kavatsete teenindada. Kui külastajad pääsevad ligi nii juurdomeenile kui ka www, lisage mõlemad ja seejärel otsustage, kumb neist peaks ümbersuunamise kaudu muutuma kanooniliseks.

root tee peab osutama kataloogile, mis sisaldab avalikke veebifaile, mitte tingimata projekti ülemise taseme kaustale. WordPressi puhul on see sageli kaust, kus asuvad wp-admin, wp-content ja wp-includes. Laraveli ja sarnaste raamistike puhul on see tavaliselt kataloog public. Kui suunate Nginxi valesse kausta, võivad avalikuks saada failid, mis ei tohiks kunagi olla avalikult kättesaadavad.

try_files reegel väärib tähelepanu. See kontrollib, kas taotletud fail või kataloog on olemas, enne kui edastab sobimatud päringud rakendusele. See on hädavajalik WordPressi püsilinkide ja paljude kaasaegsete PHP-rakenduste jaoks. Ilma selleta võivad lehed töötada ainult siis, kui külastajad kasutavad täielikku URL-i koos lisatud index.php-ga. Mitte just ideaalne, ega ka probleem, millest soovite, et kliendid esimesena teataksid.

Vältige vaikimisi serveri lõksu

Nginx vajab vaikimisi serverit päringute jaoks, mis ei vasta ühelegi konfigureeritud hostinimele. Kui vale sait on määratud vaikimisi saidiks, võib tundmatu domeen või otsene IP-päring kuvada kellegi teise veebisaiti. Parimal juhul on see segadust tekitav ja halvimal juhul riskantne.

Mitme saidiga serverite puhul kasutage lihtsat vaikimisi serverit, mis ei tagasta kasulikku sisu, näiteks 404-vastust. Hoidke päris veebisaidid selgesõnalistes serveriplokkides, millel on oma server\_name väärtused. See on väike piir, mis muudab jagatud serveri haldamise lihtsamaks.

Seadistage PHP ilma oletusteta

Nginx ei töötle PHP-d iseseisvalt. See edastab PHP-päringud PHP-FPM-ile, mis käivitab koodi. Ühendus on tavaliselt Unixi sokkel või kohalik TCP-port.

Levinud PHP asukohaplokk näeb välja selline:

location ~ \.php$ {
    try_files $uri =404;

    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

PHP versioon ja sokli tee erinevad serveriti. Kui Nginx tagastab pärast PHP värskendust vea 502 Bad Gateway, on sokli tee üks esimesi kohti, mida kontrollida. PHP-FPM võib olla peatatud, töötada teise versiooniga või kuulata mujal kui Nginxis määratud teel.

Samuti tasub säilitada rida try_files $uri =404;. See takistab Nginxil saatmast olematute PHP-failide päringuid PHP töötlejale. See parandab nii turvalisust kui ka vigade käsitlemist.

WordPressi puhul vältige laiade reeglite lisamist, mis on kopeeritud juhuslikest foorumipostitustest, kui te ei tea, miks neid vaja on. WordPress töötab juba hästi puhta try_files seadistusega, korrektse PHP käsitlemisega ja kirjutusõigustega ainult seal, kus WordPress neid vajab. Rohkem reegleid ei tähenda automaatselt paremat konfiguratsiooni.

Muutke HTTPS vaikimisi teeks

Iga avalik veebisait peaks teenindama HTTPS-i kaudu ja suunama HTTP-liikluse turvalisse versiooni ümber. Tavapärane muster on HTTP serveriplokk, mis teeb ainult ümbersuunamise, ning eraldi HTTPS-plokk, mis teenindab saiti.

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

    return 301 https://example.com$request_uri;
}

HTTPS serveriplokk kuulab seejärel porti 443 ja sisaldab sertifikaadi ning privaatvõtme teid. Sertifikaadifailid sõltuvad sellest, kuidas SSL on kasutusele võetud, kuid põhimõte jääb samaks: hoidke sertifikaadi konfiguratsioon selle saidi sees, mis seda kasutab.

Püsiv 301-ümbersuunamine on sobiv siis, kui olete sihtkoha osas kindel. Aktiivse migreerimise või lühiajalise testi ajal võib 302-ümbersuunamine olla turvalisem, sest brauserid ei salvesta seda nii agressiivselt vahemällu. See on üks neist juhtudest, kus tehniliselt kõige tugevamana näiv valik ei ole alati õige operatiivne valik.

Valige ka üks eelistatud hostinimi. Suunake kas www juurdomeenile või juurdomeen aadressile www. Mõlema teenindamine ilma järjepideva ümbersuunamiseta võib killustada analüütikat, luua otsingumootorite jaoks duplikaatlehti ja muuta küpsiste käitumise diagnoosimise keerulisemaks.

Teenindage staatilisi faile tõhusalt ja turvaliselt

Pildid, CSS, JavaScript, fondid ja allalaaditavad failid ei peaks kulutama PHP ressursse, kui Nginx saab need otse edastada. Määrake mõistlik brauseri vahemällu salvestamine failidele, mis muutuvad harva:

location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|ico|woff2)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Kolmkümmend päeva on mõistlik lähtepunkt, mitte seadus. Kui teie failinimed sisaldavad versiooninumbreid või räsitud failinimesid, võib pikem vahemällu salvestamine väga hästi toimida. Kui sama failinimi asendatakse sageli, võib pikk vahemälu jätta külastajatele nähtavaks vanema kujunduse või skripti. Vahemällu salvestamine on alati kokkulepe kiiruse ja selle vahel, kui kiiresti peavad muudatused nähtavale ilmuma.

Ärge avaldage peidetud faile kogemata. Lihtne reegel võib blokeerida dotfile’ide päringud, lubades samal ajal sertifikaadi valideerimiseks kasutatava kataloogi .well-known:

location ~ /\.(?!well-known(?:/|$)) {
    deny all;
}

Sõltuvalt teie sertifikaadi seadistusest võib teil olla vaja konkreetset erandit asukoha .well-known jaoks. Pärast juurdepääsureeglite rangemaks muutmist testige uuendamise käitumist. Turvareeglid peaksid vähendama kokkupuudet riskidega, mitte vaikselt rikkuma teenuseid, millele te toetute.

Kasutage turvapäiseid konteksti arvestades

Vastusepäised võivad parandada brauseripoolset kaitset, kuid neid tuleb testida. Levinud näited hõlmavad X-Content-Type-Options nosniff, Referrer-Policy ja Content-Security-Policy. Neist viimane on võimas ja seda on lihtne valesti seadistada. Range poliitika võib blokeerida skripte, fonte, maksevidinaid, analüütikat või manustatud sisu, kui see võetakse kasutusele ilma saidi sõltuvusi mõistmata.

Alustage päistega, mille eesmärk on selge ja risk väike, seejärel lisage ainult aruanderežiimis sisuturbe poliitika, kui teie rakendus seda toetab. Eesmärk ei ole koguda muljetavaldavat direktiivide virna. Eesmärk on vähendada tegelikku riski ilma lehti rikkumata, mida inimesed peavad kasutama.

Kiiruse piiramine võib samuti aidata kuritarvitava liikluse ja sisselogimisrünnakute vastu, eriti WordPressi sisselogimise lõpp-punktide puhul. Kuid agressiivsed piirangud võivad blokeerida seaduslikke kasutajaid jagatud kontorivõrkude või mobiilioperaatorite taga. Vaadake logid üle ja kohandage sätteid tegelike liiklusmustrite põhjal, selle asemel et valida numbreid, mis lihtsalt kõlavad rangelt.

Testige muudatusi nii, nagu need oleksid olulised

Iga Nginxi muudatus peaks järgima sama lühikest rutiini: varundage või kopeerige praegune fail, tehke üks sihipärane muudatus, käivitage nginx -t, laadige Nginx uuesti ja testige veebisaiti brauserist ning käsurealt. Kontrollige kavandatud domeeni, mittekanoonilist domeeni, HTTP-d, HTTPS-i ja PHP poolt töödeldavat lehte.

Kui miski ebaõnnestub, lugege enne konfiguratsiooni ümberkirjutamist vealogisid. Nginxi juurdepääsu- ja vealogid näitavad sageli, kas probleem on puuduvas failis, valedes õigustes, nurjunud ülesvooluühenduses või halvas ümbersuunamises. Oletamine võib kolme uut probleemi tekitada, ilma et ükski saaks lahendatud.

Juhtpaneel võib suure osa sellest käsitööst kõrvaldada, luues ja korraldades veebisaidi taseme sätted, sertifikaadid, PHP versioonid ja logid ühes kohas. FASTPANEL on loodud selle praktilise kesktee jaoks: säilitate kontrolli oma majutuskeskkonna üle, muutmata iga domeenimuudatust konfiguratsiooniarheoloogia projektiks.

Hea Nginxi konfiguratsioon ei tähenda kõige pikema faili loomist ega iga saadaoleva direktiivi kasutamist. See tähendab iga saidi etteaimatavaks muutmist: õige domeen jõuab õigete failideni, PHP-l on terve ülesvool, HTTPS on jõustatud, staatiline sisu on tõhus ja muudatusi testitakse enne, kui külastajad nendega kokku puutuvad. Kui see vundament on paigas, muutub kasvava serveri haldamine palju vähem dramaatiliseks – täpselt nii, nagu see olema peaks.