Nginx konfigurācija, kas uztur vietnes ātras

Publicēts 2026. gada 19. septembrī

Vietne var izskatīties pilnīgi vesela, līdz neliela Nginx konfigurācijas kļūda pārvērš ierastu izvietošanu par 502 kļūdu, SSL brīdinājumu vai pāradresācijas cilpu, kas aizved apmeklētājus nekur noderīgi. Nginx ir ātrs un uzticams, taču tas ir arī prasīgs pret precizitāti: viena direktīva nepareizā vietā var mainīt visas vietnes darbību. Labā ziņa ir tā, ka pārdomāta pieeja padara Nginx konfigurāciju daudz mazāk noslēpumainu.

Šajā ceļvedī uzmanība pievērsta iestatījumiem, kas ir vissvarīgākie vietņu mitināšanā: servera blokiem, PHP apstrādei, HTTPS, pāradresācijām, statiskajiem failiem, kešošanai un drošai testēšanai. Jums nav jāiegaumē katra Nginx direktīva. Jums ir jāsaprot, kuri lēmumi ietekmē jūsu vietni un kā tos pārbaudīt, pirms tie ietekmē jūsu apmeklētājus.

Sāciet ar skaidru Nginx konfigurācijas izkārtojumu

Lielākajā daļā Linux instalāciju globālie iestatījumi ir atdalīti no atsevišķu vietņu iestatījumiem. Galvenais konfigurācijas fails, kas parasti atrodas /etc/nginx/nginx.conf, kontrolē darba procesus, žurnalēšanu, saspiešanu un iekļautās konfigurācijas direktorijas. Atsevišķas vietnes parasti atrodas tādā direktorijā kā sites-available, sites-enabled vai conf.d.

Šī atdalīšana ir noderīga praktiska iemesla dēļ: globālie iestatījumi jāmaina uzmanīgi un reti, savukārt vietnes līmeņa iestatījumiem nepieciešama regulāra uzmanība. Jauns domēns, testēšanas vietne vai pāradresācijas noteikums pieder šīs vietnes servera blokam, nevis galvenajam failam.

Pirms kaut ko maināt, identificējiet aktīvo konfigurāciju un pārbaudiet to:

bash nginx -t

Ja pārbaude ir veiksmīga, pārlādējiet Nginx, nepārtraucot aktīvos savienojumus:

bash systemctl reload nginx

Parastām konfigurācijas izmaiņām izmantojiet reload. Pilna restartēšana dažkārt ir nepieciešama, taču tā nav pirmā darbība, kad atjaunināt virtuālo resursdatoru. Šādi mazi ieradumi neļauj piecu minūšu uzdevumam pārvērsties par vēlu vakara atkopšanas darbu.

Izveidojiet vienu servera bloku katrai vietnei

Servera bloks norāda Nginx, kuram domēnam tas kalpo, kur glabājas vietnes faili un kā jāapstrādā pieprasījumi. Domājiet par to kā par vienas vietnes reģistratūru. Kad viens serveris apkalpo vairākus domēnus, sakārtots servera bloks ir tas, kas nodrošina trafika novirzīšanu uz pareizo vietu.

Pamata HTTP vietne var izskatīties šādi:

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 jāuzskaita visi resursdatoru nosaukumi, kurus plānojat apkalpot. Ja apmeklētāji var sasniegt gan saknes domēnu, gan www, iekļaujiet abus, pēc tam izlemiet, kurš no tiem kļūs par kanonisko, izmantojot pāradresāciju.

Ceļam root jānorāda uz direktoriju, kurā atrodas publiskie tīmekļa faili, nevis obligāti uz projekta augstākā līmeņa mapi. WordPress gadījumā tā bieži ir mape, kurā atrodas wp-admin, wp-content un wp-includes. Laravel un līdzīgiem ietvariem tā parasti ir direktorija public. Novirzot Nginx uz nepareizo mapi, var tikt atklāti faili, kuriem nekad nevajadzētu būt publiski pieejamiem.

Noteikums try_files ir pelnījis uzmanību. Tas pārbauda, vai pieprasītais fails vai direktorija eksistē, pirms neatbilstošos pieprasījumus nodod lietotnei. Tas ir būtiski WordPress pastāvīgajām saitēm un daudzām modernām PHP lietotnēm. Bez tā lapas var darboties tikai tad, ja apmeklētāji izmanto pilnu URL ar pievienotu index.php. Nav ideāli, un noteikti ne tāda problēma, par kuru vēlaties vispirms dzirdēt no klientiem.

Izvairieties no noklusējuma servera slazda

Nginx ir nepieciešams noklusējuma serveris pieprasījumiem, kas neatbilst konfigurētam resursdatora nosaukumam. Ja nepareizā vietne ir iestatīta kā noklusējuma, nezināms domēns vai tiešs IP pieprasījums var parādīt kāda cita vietni. Tas labākajā gadījumā ir mulsinoši un sliktākajā — riskanti.

Serveriem ar vairākām vietnēm izmantojiet vienkāršu noklusējuma serveri, kas neatgriež noderīgu saturu, piemēram, 404 atbildi. Īstās vietnes turiet skaidri definētos servera blokos ar to pašu server\_name vērtībām. Tā ir neliela robeža, kas padara koplietojamu serveri vieglāk pārvaldāmu.

Konfigurējiet PHP bez minējumiem

Nginx pats par sevi PHP neapstrādā. Tas nodod PHP pieprasījumus PHP-FPM, kas izpilda kodu. Savienojums parasti ir Unix ligzda vai lokāls TCP ports.

Tipisks PHP atrašanās vietas bloks izskatās šādi:

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 versija un ligzdas ceļš atšķiras atkarībā no servera. Ja pēc PHP atjaunināšanas Nginx atgriež 502 Bad Gateway kļūdu, ligzdas ceļš ir viena no pirmajām vietām, kas jāpārbauda. PHP-FPM var būt apturēts, darboties citā versijā vai klausīties citur, nevis Nginx definētajā ceļā.

Arī rindu try_files $uri =404; ir vērts saglabāt. Tā neļauj Nginx sūtīt pieprasījumus neeksistējošiem PHP failiem uz PHP apstrādātāju. Tas uzlabo gan drošību, gan kļūdu apstrādi.

WordPress gadījumā izvairieties pievienot plašus noteikumus, kas nokopēti no nejaušiem forumu ierakstiem, ja vien nezināt, kāpēc tie ir vajadzīgi. WordPress jau labi darbojas ar tīru try_files iestatījumu, pareizu PHP apstrādi un rakstīšanas tiesībām tikai tur, kur tās WordPress ir nepieciešamas. Vairāk noteikumu automātiski nenozīmē labāku konfigurāciju.

Padariet HTTPS par noklusējuma ceļu

Katrai publiskai vietnei vajadzētu apkalpot HTTPS un pāradresēt HTTP trafiku uz drošo versiju. Parastais modelis ir HTTP servera bloks, kas veic tikai pāradresāciju, un atsevišķs HTTPS bloks, kas apkalpo vietni.

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

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

HTTPS servera bloks pēc tam klausās 443. portā un ietver sertifikāta un privātās atslēgas ceļus. Sertifikātu faili ir atkarīgi no tā, kā SSL tiek nodrošināts, taču princips paliek tas pats: glabājiet sertifikāta konfigurāciju tajā vietnē, kas to izmanto.

Pastāvīga 301 pāradresācija ir piemērota, kad esat pārliecināts par galamērķi. Aktīvas migrācijas vai īstermiņa testa laikā 302 pāradresācija var būt drošāka, jo pārlūkprogrammas to nekešo tik agresīvi. Šis ir viens no tiem gadījumiem, kad tehniski visspēcīgāk izskatīgā opcija ne vienmēr ir pareizā operacionālā izvēle.

Izvēlieties arī vienu vēlamo resursdatora nosaukumu. Pāradresējiet vai nu www uz saknes domēnu, vai saknes domēnu uz www. Abu apkalpošana bez konsekventas pāradresācijas var sadalīt analītiku, radīt meklētājprogrammām dublētas lapas un apgrūtināt sīkdatņu darbības diagnosticēšanu.

Apkalpojiet statiskos failus efektīvi un droši

Attēliem, CSS, JavaScript, fontiem un lejupielādējamiem failiem nevajadzētu patērēt PHP resursus, ja Nginx tos var piegādāt tieši. Iestatiet saprātīgu pārlūkprogrammas kešatmiņu failiem, kas mainās reti:

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

Trīsdesmit dienas ir saprātīgs sākumpunkts, nevis likums. Ja jūsu failu nosaukumos ir versiju numuri vai hešoti failu nosaukumi, ilgāka kešošana var darboties ļoti labi. Ja tas pats faila nosaukums tiek bieži aizstāts, ilga kešatmiņa var likt apmeklētājiem redzēt vecāku dizainu vai skriptu. Kešošana vienmēr ir vienošanās starp ātrumu un to, cik ātri izmaiņām jāparādās.

Neatklājiet slēptos failus nejauši. Vienkāršs noteikums var bloķēt pieprasījumus dotfailiem, vienlaikus atļaujot direktoriju .well-known, ko izmanto sertifikāta validācijai:

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

Atkarībā no jūsu sertifikāta iestatījuma jums var būt nepieciešams īpašs izņēmums priekš .well-known. Pēc piekļuves noteikumu stingrākas noteikšanas pārbaudiet atjaunošanas darbību. Drošības noteikumiem būtu jāsamazina pakļautība riskam, nevis klusām jāsabojā pakalpojumi, uz kuriem paļaujaties.

Izmantojiet drošības galvenes atbilstoši kontekstam

Atbilžu galvenes var uzlabot aizsardzību pārlūkprogrammas pusē, taču tās ir jāpārbauda. Bieži piemēri ietver X-Content-Type-Options nosniff, Referrer-Policy un Content-Security-Policy. Pēdējā no tām ir jaudīga un viegli nepareizi konfigurējama. Stingra politika var bloķēt skriptus, fontus, maksājumu logrīkus, analītiku vai iegultu saturu, ja tā tiek ieviesta, neizprotot vietnes atkarības.

Sāciet ar galvenēm, kurām ir skaidrs mērķis un zems risks, pēc tam pievienojiet satura drošības politiku tikai atskaišu režīmā, ja jūsu lietotne to atbalsta. Mērķis nav savākt iespaidīgu direktīvu kaudzi. Mērķis ir samazināt reālo risku, nesabojājot lapas, kuras cilvēkiem ir jāizmanto.

Ātruma ierobežošana var palīdzēt arī pret ļaunprātīgu trafiku un pieteikšanās uzbrukumiem, īpaši WordPress pieteikšanās galapunktiem. Taču agresīvi ierobežojumi var bloķēt likumīgus lietotājus aiz koplietojamiem biroja tīkliem vai mobilo sakaru operatoriem. Pārskatiet žurnālus un pielāgojiet, pamatojoties uz faktiskajiem trafika modeļiem, nevis izvēloties skaitļus, kas tikai izklausās stingri.

Pārbaudiet izmaiņas tā, it kā tām būtu nozīme

Katrai Nginx izmaiņai jāseko vienai un tai pašai īsajai kārtībai: izveidojiet dublējumu vai nokopējiet pašreizējo failu, veiciet vienu mērķētu izmaiņu, palaidiet nginx -t, pārlādējiet Nginx un pārbaudiet vietni no pārlūkprogrammas un komandrindas. Pārbaudiet paredzēto domēnu, nekanonisko domēnu, HTTP, HTTPS un lapu, ko apstrādā PHP.

Ja kaut kas nedarbojas, pirms konfigurācijas pārrakstīšanas izlasiet kļūdu žurnālus. Nginx piekļuves un kļūdu žurnāli bieži atklāj, vai problēma ir trūkstošs fails, nepareizas atļaujas, neveiksmīgs augšupējais savienojums vai slikta pāradresācija. Minēšana var radīt trīs jaunas problēmas, neizlabojot nevienu.

Vadības panelis var novērst lielu daļu no šī manuālā darba, vienuviet izveidojot un organizējot vietņu līmeņa iestatījumus, sertifikātus, PHP versijas un žurnālus. FASTPANEL ir izstrādāts šim praktiskajam vidusceļam: jūs saglabājat kontroli pār savu mitināšanas vidi, nepārvēršot katru domēna izmaiņu par konfigurācijas arheoloģijas projektu.

Laba Nginx konfigurācija nav par garākā faila izveidi vai katras pieejamās direktīvas izmantošanu. Tā ir par katras vietnes paredzamības nodrošināšanu: pareizais domēns sasniedz pareizos failus, PHP ir veselīgs augšupējais savienojums, HTTPS tiek piespiests, statiskais saturs ir efektīvs, un izmaiņas tiek pārbaudītas, pirms ar tām sastopas apmeklētāji. Kad šis pamats ir izveidots, augoša servera pārvaldība kļūst daudz mazāk dramatiska — tieši tā, kā tam vajadzētu būt.