Si altii). Versiune curentă,0.6.x, este considerat stabil din punct de vedere al fiabilității, iar lansările din ramura 0.7 sunt considerate instabile. Este important de remarcat faptul că funcționalitatea unor module se va modifica, drept urmare directivele se pot modifica și, prin urmare compatibilitate inversăîn nginx înainte de versiunea 1.0.0 nu este garantat.

De ce este nginx atât de bun și de ce administratorii proiectelor cu încărcare mare îl iubesc atât de mult? De ce să nu folosești Apache?

De ce este rău Apache?

În primul rând, trebuie să explicăm cum funcționează în general serverele de rețea. Cei care sunt familiarizați cu programare în rețea, știți că există în esență trei modele de funcționare a serverului:

1. Consistent. Serverul deschide o priză de ascultare și așteaptă să apară o conexiune (este într-o stare blocată în timp ce așteaptă). Când ajunge o conexiune, serverul o procesează în același context, închide conexiunea și așteaptă din nou conexiunea. Evident, acesta este departe de cel mai bun mod, mai ales când lucrul cu un client durează mult și există o mulțime de conexiuni. În plus, modelul serial are mult mai multe dezavantaje (de exemplu, incapacitatea de a utiliza mai multe procesoare), iar în conditii reale practic nu este folosit.
2. Multi-proces (multi-threaded). Serverul deschide o priză de ascultare. Când sosește o conexiune, o acceptă, după care creează (sau preia dintr-un grup de conexiuni pre-create) un nou proces sau fir care poate funcționa cu conexiunea atâta timp cât se dorește și, la terminarea lucrului, se încheie sau întoarce-te la piscină. Între timp, firul principal este gata să accepte o nouă conexiune. Acesta este cel mai popular model deoarece este relativ ușor de implementat, permite efectuarea de calcule complexe și consumatoare de timp pentru fiecare client și utilizează toate procesoarele disponibile. Un exemplu de utilizare a acestuia este Web server Apache. Cu toate acestea, această abordare are și dezavantaje: cu un număr mare de conexiuni simultane, se creează o mulțime de fire de execuție (sau, și mai rău, procese), iar sistemul de operare irosește o mulțime de resurse pe comutatoarele de context. Este deosebit de rău când clienții acceptă foarte încet conținutul. Acest lucru are ca rezultat sute de fire de execuție sau procese ocupate cu trimiterea de date către clienții lenți, ceea ce creează încărcare suplimentară pe planificatorul sistemului de operare, crește numărul de întreruperi și consumă destul de multă memorie.
3. Prize non-blocante/mașină de stat. Serverul operează într-un singur fir, dar folosește socket-uri neblocante și un mecanism de sondare. Acestea. server la fiecare iterație buclă nesfârșită Selectează din toate soclulurile pe cel care este gata să primească/trimite date folosind apelul select(). După ce socket-ul este selectat, serverul îi trimite date sau îl citește, dar nu așteaptă confirmarea, ci trece la starea inițială și așteaptă un eveniment pe alt socket sau îl prelucrează pe următorul în care a avut loc evenimentul în timpul procesării socket-ului. precedentul. Acest model Folosește procesorul și memoria foarte eficient, dar este destul de complex de implementat. În plus, în cadrul acestui model, procesarea evenimentelor pe un socket trebuie să aibă loc foarte rapid - altfel multe evenimente se vor acumula în coadă și, în cele din urmă, se vor deborda. Acesta este exact modelul pe care lucrează nginx. În plus, vă permite să rulați mai multe procese de lucru (așa-numitele lucrători), de exemplu. poate folosi mai multe procesoare.

Deci, imaginați-vă următoarea situație: 200 de clienți cu un canal de 256 Kbit/s se conectează la un server HTTP cu un canal de 1 Gbit/s:

Ce se întâmplă în cazul Apache? Sunt create 200 de fire/procese care generează conținut relativ rapid (ar putea fi ceva de genul pagini dinamice, și fișierele statice citite de pe disc), dar le livrează încet clienților. Sistemul de operare este forțat să facă față unei mulțimi de fire și blocări I/O.

În această situație, Nginx cheltuiește cu un ordin de mărime mai puține resurse ale sistemului de operare și memorie pe fiecare conexiune. Cu toate acestea, există o limitare aici model de rețea nginx: nu poate genera continut dinamicîn interiorul tău, pentru că acest lucru va duce la blocaje în interiorul nginx. Desigur, există o soluție: nginx poate trimite astfel de solicitări (pentru generarea de conținut) către orice alt server web (de exemplu, același Apache) sau către un server FastCGI.

Să considerăm mecanismul de funcționare al combinației nginx ca server „principal” și Apache ca server pentru generarea de conținut dinamic:

Nginx acceptă conexiunea de la client și citește întreaga solicitare de la acesta. Trebuie remarcat aici că până când nginx nu a citit întreaga solicitare, nu o trimite pentru „procesare”. Din această cauză, aproape toți indicatorii de progres de descărcare a fișierelor se „rup” de obicei - cu toate acestea, este posibil să-i remediați folosind modul terță parte upload_progress (acest lucru va necesita modificarea aplicației).

După ce nginx a citit întregul răspuns, deschide o conexiune la Apache. Acesta din urmă își face treaba (generează conținut dinamic), după care își trimite răspunsul către nginx, care îl tamponează în memorie sau într-un fișier temporar. Între timp, Apache eliberează resurse. În continuare, nginx livrează lent conținutul clientului, în timp ce cheltuiește ordin de mărime mai puține resurse decât Apache.

Această schemă se numește frontend + backend și este folosită foarte des.

Instalare

Deoarece nginx abia începe să câștige popularitate, există unele probleme cu pachetele binare, așa că fiți pregătit să îl compilați singur. De obicei, nu există probleme cu aceasta, trebuie doar să citiți cu atenție rezultatul comenzii./configure --help și să selectați opțiunile de compilare de care aveți nevoie, de exemplu acestea:

./configure\
--prefix=/opt/nginx-0.6.x \ # prefix de instalare
--conf-path=/etc/nginx/nginx.conf \ # locația fișierului de configurare
—pid-path=/var/run/nginx.pid \ # ... și fișierul pid
—user=nginx \ # nume de utilizator sub care va rula nginx
—cu-http_ssl_module —cu-http_gzip_static_module —cu-http_stub_status_module \ # listă de necesare
—fără-http_ssi_module —fără-http_userid_module —fără-http_autoindex_module —fără-http_geo_module —fără-http_referer_module —fără-http_memcached_module —fără-http_limit_zone_module # ... și module inutile

După configurare, ar trebui să rulați instalarea standard make && make, după care puteți utiliza nginx.

În plus, în Gentoo puteți utiliza un ebuild din arborele standard de porturi; în RHEL/CentOS de către depozitul epel (care conține nginx 0.6.x) sau srpm pentru versiunea 0.7, care poate fi descărcat de aici: http://blogs.mail.ru/community/nginx; pe Debian puteți folosi pachetul nginx din ramura instabilă.

Fișier de configurare

Fișierul de configurare nginx este foarte convenabil și intuitiv. Se numește de obicei nginx.conf și se află în $prefix/conf/ dacă locația nu a fost suprascrisă în timpul compilării. Îmi place să îl pun în /etc/nginx/, la fel ca și dezvoltatorii tuturor pachetelor menționate mai sus.

Structura fișierului de configurare este următoarea:

utilizator nginx; # nume de utilizator cu ale cărui drepturi va rula nginx
lucrător_procese 1; # număr de procese de lucru
evenimente (
<…># acest bloc specifică mecanismul de interogare care va fi utilizat (vezi mai jos) și suma maxima posibile conexiuni
}

Http(
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;

# descrierea serverelor (aceasta este ceea ce se numește VirtualHost în apache)
Server (
# adresa și numele serverului
asculta *:80;
nume_server aaa.bbb;

<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;

# și așa puteți defini o locație, pentru care puteți, de asemenea, să suprascrieți aproape toate directivele specificate la niveluri mai globale
locație /abcd/ (
<директивы>;
}
# În plus, puteți face locația folosind o expresie regulată, de exemplu, ca aceasta:
locație ~ \.php$ (
<директивы>;
}
}

# un alt server
Server (
asculta *:80;
nume_server ccc.bbb;

<директивы>
}
}

Vă rugăm să rețineți că fiecare directivă trebuie să se încheie cu punct și virgulă.
Reverse proxy și FastCGI

Deci, mai sus ne-am uitat la avantajele schemei frontend + backend, ne-am dat seama de instalarea, structura și sintaxa fișierului de configurare, iar acum ne vom uita la cum să implementăm reverse proxy în nginx.

Și este foarte simplu! De exemplu astfel:

Locație/(
proxy_pass http://1.2.3.4:8080;
}

În acest exemplu, toate cererile care se încadrează în locație / vor fi trimise proxy către serverul 1.2.3.4, portul 8080. Acesta poate fi fie apache, fie orice alt server http.

Cu toate acestea, există mai multe subtilități legate de faptul că aplicația va considera că, în primul rând, toate solicitările îi vin de la aceeași adresă IP (care poate fi privită, de exemplu, ca o încercare de atac DDoS sau de ghicire a parolei), și în al doilea rând, să presupunem că rulează pe gazda 1.2.3.4 și pe portul 8080 (în consecință, generați redirecționări incorecte și legături absolute). Pentru a evita aceste probleme fără a fi nevoie să rescrieți aplicația, găsesc la îndemână următoarea configurație:
Nginx ascultă în față pe portul 80.

Dacă backend-ul (să spunem Apache) este situat pe aceeași gazdă ca nginx, atunci „ascultă” pe portul 80 pe 127.0.0.1 sau pe o altă adresă IP internă.

Configurația nginx în acest caz arată astfel:

Server (
asculta 4.3.2.1:80;
# setați antetul Host și X-Real-IP: pentru fiecare solicitare trimisă către backend
proxy_set_header X-Real-IP $adresă_la distanță;
proxy_set_header Gazdă $gazdă:$proxy_port;
# sau „proxy_set_header Host $host;” dacă aplicația va adăuga:80 la toate linkurile
}

Pentru ca aplicația să distingă adresele IP ale vizitatorilor, trebuie fie să instalați modulul mod_extract_forwarded (dacă este executat de serverul Apache), fie să modificați aplicația astfel încât să preia informații despre adresa IP a utilizatorului de la X- Antet HTTP real-IP.

O altă opțiune de backend este utilizarea FastCGI. În acest caz, configurația nginx va arăta cam așa:

Server (
<…>

# locație unde vor merge cererile pentru scripturi php
locație ~ .php$ (
fastcgi_pass 127.0.0.1:8888; # determinați adresa și portul serverului fastcgi,
fastcgi_index index.php; # ...fișier index

# și câțiva parametri care trebuie să fie transferați serverului fastcgi, astfel încât acesta să înțeleagă ce script să execute și cu ce parametri:
fastcgi_param SCRIPT_FILENAME /usr/www/html$fastcgi_script_name; # nume de script
fastcgi_param QUERY_STRING $șir_interogare; # șir de interogare
# și parametrii de solicitare:
fastcgi_param REQUEST_METHOD $cerere_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
}

# datorită faptului că locațiile cu expresii regulate au o „prioritate” mare, toate solicitările non-php vor cădea aici.

Locație/(
rădăcină /var/www/html/
}

Statică

Pentru a încărca mai puțin backend-ul, este mai bine să serviți fișiere statice numai prin nginx - face față mai bine acestei sarcini, deoarece cheltuiește mult mai puține resurse pentru fiecare solicitare (nu este nevoie să generați un nou proces, iar procesul Nginx consumă de obicei mai puțină memorie și poate deservi multe conexiuni).

ÎN Fișier de configurare arata cam asa:

Server (
asculta *:80;
nume_server serverul meu.com;

Locație/(
proxy_pass


„>http://127.0.0.1:80;

}

# presupunem că toate fișierele statice sunt în /fișiere
locație /fișiere/ (
rădăcină /var/www/html/; # indica calea către fs
expiră 14d; # adăugați antetul Expires:
error_page 404 = @back; # iar dacă fișierul nu este găsit, îl trimitem la locația numită @back
}

# solicitările de la /fișiere pentru care nu a fost găsit niciun fișier sunt trimise la backend și poate fi generată fișierul necesar, sau spectacol frumos mesaj despre eroare
locație @back (
proxy_pass
"title="http://127.0.0.1:80;

„>http://127.0.0.1:80;

}

Dacă toate statisticile nu sunt plasate într-un anumit director, atunci utilizați o expresie regulată:

locație ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf |js)$ (
# similar cu ceea ce este mai sus, numai toate cererile care se termină cu unul dintre sufixele specificate vor merge în această locație
rădăcină /var/www/html/;
error_page 404 = @back;
}

Din păcate, nu este implementat în nginx lucru asincron cu dosare. Cu alte cuvinte, lucrătorul nginx este blocat la operațiunile I/O. Deci dacă aveți o mulțime de fișiere statice și mai ales dacă sunt citite din ele diferite discuri, este mai bine să creșteți numărul de procese de lucru (la un număr care este de 2-3 ori mai mare decât numărul total de capete de pe disc). Acest lucru, desigur, crește încărcarea sistemului de operare, dar performanța generală crește. Pentru a lucra cu o cantitate tipică de static (nu foarte un numar mare de fișiere relativ mici: CSS, JavaScript, imagini) unul sau două fluxuri de lucru sunt suficiente.

Va urma

Legături

Aici puteți găsi informații suplimentare despre nginx:

Buna ziua! Astăzi vom vorbi despre un concept atât de necesar ca gazde virtualeîn serverul web nginx. Vom folosi sistemul de operare Ubuntu ca exemplu. Pentru alte sisteme Linux, configurația va arăta foarte asemănătoare. Acest articol instructiv va fi de interes în principal pentru webmasterii și administratorii începători, deoarece... ei au cel mai adesea această întrebare.

O gazdă virtuală este...

Mai întâi, să definim o gazdă virtuală. Asa de, gazda virtuală esteîmpărțirea spațiului de adrese a serverului web, de exemplu, după numele site-ului, permițându-vă să rulați mai multe site-uri web/aplicații pe o singură server fizic. În terminologia documentației nginx, se numește și o gazdă virtuală „Bloc server”, dar pentru a-l face mai asemănător cu Apache, îl voi numi uniform, pentru că scopul lor este același. Și încă un acord - să numim ceea ce vom configura un site pentru simplitate.

Crearea unei gazde virtuale

Multe dintre comenzile din acest manual necesită ca utilizatorul să aibă drepturi sudoer la VPS. Prin urmare, dacă nu le aveți, din păcate, este puțin probabil să puteți configura gazde virtuale.

Presetat

Acum o să vă spun ceva ce trebuie să știe toată lumea! Pentru a configura o gazdă virtuală în nginx, aveți nevoie de un server web nginx instalat pe mașina dvs. Căpitanul Obvious este cu noi! Dacă aveți deja instalat nginx, puteți sări peste acest pas în siguranță și să continuați conform instrucțiunilor. Dacă, dintr-un motiv oarecare, încă nu îl aveți pe computer, introduceți comanda în consolă:

Sudo apt-get install -y nginx

Opțiune "-y" Adăugăm comanda apt-get pentru a nu răspunde da-da-da la întrebările enervante ale instalatorului, deoarece suntem siguri că vrem să instalăm acest pachet și să fim de acord cu utilizarea spațiului pe disc pe care îl ocupă. Dacă încă nu sunteți sigur că sunteți de acord cu totul, atunci nu adăugați această opțiune.

Crearea unui director de site

Deci, înainte de a crea o gazdă virtuală, să facem un folder de site unde vom plasa toate fișierele cu care va funcționa serverul nostru web.

Calea către acest folder în configurația gazdei care este creată va fi Rădăcina documentului, un fel de context, un punct de izolare, deasupra căruia afară fără presetat configurația nu poate fi accesată și în raport cu care sunt construite căile către fișierele solicitate. Cu optiune "-p" Cu comanda mkdir nu trebuie să ne facem griji cu privire la crearea directoarelor părinte, acestea vor fi create automat:

Sudo mkdir -p /var/www/mysite.ru/public_html

Aici folosim un domeniu DNS real verificat cu înregistrări corecte care indică către mașina noastră. Pentru a crea o gazdă virtuală cu un domeniu neînregistrat, de exemplu pentru dezvoltare locală, trebuie să faceți o intrare corespunzătoare în fișierul /etc/hosts. Mai multe detalii despre acest lucru vor fi la sfârșitul articolului.

Drepturi de acces

Acum doar utilizatorul root are drepturi la folderul creat. Trebuie să acordăm permisiuni directorului pentru utilizatorul dorit, pentru a nu lucra constant cu el în modul super-utilizator. Puteți înlocui utilizatorul „www-data” folosit mai jos cu altul, dar nginx rulează ca acest utilizator în mod implicit.

Sudo chown -R www-data:www-data /var/www/mysite.ru/public_html

Acum să ne asigurăm că toți utilizatorii pot citi noile noastre fișiere:

Sudo chmod 755 /var/www

Adică lucrăm cu un VPS pe care toți utilizatorii nu fac nimic rău sau pe care ești doar tu. Prin urmare, putem acorda permisiuni 755 folderului /var/www. Dacă în cazul dvs. este imposibil să acordați tuturor utilizatorilor sistemului drepturi de a citi acest director, studiați problema diferențierii drepturilor și configurați-o singur.

Acum ești gata cu drepturile tale!

Crearea unei pagini

Acum trebuie să plasăm în folderul nostru câteva fișiere statice (pagini HTML, imagini, scripturi, stiluri etc.) pe care serverul nostru le va distribui. Să creăm o pagină HTML index.htm, care va fi pagina principală a site-ului nostru:

Sudo nano /var/www/mysite.ru/public_html/index.htm

Și adăugați niște markup la acesta, care vor fi afișate utilizatorului:

Ura! Ați reușit să configurați Virtual Host în nginx!

Salvează și ieși.

Crearea unei configurații de gazdă virtuală

Am ajuns la punctul de a crea noul nostru fișier de configurare a gazdei virtuale, care va conține toate informațiile despre site de care are nevoie serverul web.

În nginx, în directorul /etc/nginx/sites-available există un șablon pentru configurațiile de creat. Să o copiem pentru site-ul nostru:

Sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/mysite.ru

Configurare gazdă virtuală

Deschis fișier nou configurații și le vei vedea pe toate informatie necesara pe care ar trebui să le completați.

Sudo nano /etc/nginx/sites-available/mysite.ru

Trebuie să facem modificări la configurația curentă. Rezultatul pentru cazul nostru simplu ar trebui să fie cam așa:

Server (ascultă 80; root /var/www/mysite.ru/public_html; index index.html index.htm; server_name mysite.ru www.mysite.ru; )

Aici vi se cere să specificați corect calea către folderul cu statica site-ului și numele serverului prin care vă veți accesa site-ul. Dacă specificați calea incorect sau deloc, nu veți putea configura gazda virtuală. Ca server_name, puteți specifica și o adresă IP sau mai multe nume separate printr-un spațiu, prin care gazda va fi accesibilă, așa cum am făcut noi.

Gata, am terminat cu acest fișier. Salvați-l și închideți-l.

Activarea gazdei virtuale

Nginx are foldere disponibile și activate pentru site-uri. Prima stochează configurațiile TOATE gazdele virtuale care pot fi activate acest server, iar în directorul de site-uri activate există legături simbolice către cele active. Nimeni nu interzice plasarea fișierului de configurare original în site-uri activate mai degrabă decât într-un link, dar acest lucru va fi mai puțin convenabil, deoarece dacă este necesar să-l dezactivați, va trebui fie să ștergeți fișierul (atunci va fi problematic să îl activați înapoi), fie să îl mutați în alt director (atunci trebuie să ne amintim unde l-am mutat). Este mult mai ușor să blocați o legătură simbolică!

Prin urmare, acum, pentru a ne activa gazda virtuală, trebuie să creăm o legătură simbolică între directorul site-uri disponibile, unde se află fișierul nostru de configurare, și site-urile activate. Apache o are pentru asta echipa speciala a2ensite. Nu există o astfel de comandă în nginx, așa că haideți să facem următoarele:

Sudo ln -s /etc/nginx/sites-available/mysite.ru /etc/nginx/sites-enabled/mysite.ru

Pentru a evita „eroare de nume de server conflictuală” și asigurați-vă că site-ul dvs. este difuzat informatie necesara, îl puteți elimina pe cel implicit din lista de gazde active:

Sudo rm /etc/nginx/sites-enabled/default

Reporniți

Am parcurs deja o mulțime de pași și am configurat aproape totul. Acum să repornim serverul nostru web, astfel încât să folosească configurație nouă, dar înainte de a face acest lucru, este o bună practică să verificați dacă totul cu configurația este corect și nginx o înțelege corect. Pentru a face acest lucru, trebuie să rulați diagnosticarea nginx cu următoarea comandă:

Sudo nginx -t

O astfel de verificare este extrem de necesară la configurarea pe serverele de producție, astfel încât să nu se dovedească că am apelat comanda nginx restart, dar din cauza unei configurații incorecte nu a putut porni și toate gazdele noastre virtuale nu răspund.

Dacă răspunsul primit a fost cam așa:

Nginx: sintaxa fișierului de configurare /etc/nginx/nginx.conf este ok nginx: testul fișierului de configurare /etc/nginx/nginx.conf a reușit

Apoi totul este bine și puteți reporni în siguranță serverul cu comanda:

Reporniți serviciul Sudo nginx

În caz contrar, trebuie să vă uitați la fișierul de configurare a gazdei. Ai indicat ceva greșit acolo.

Configurarea gazdelor locale

Dacă ați specificat o adresă IP ca nume de server, puteți sări peste acest pas, deoarece Nu trebuie să configurați o gazdă locală; gazda dvs. virtuală va funcționa fără ea. Dar, dacă doriți să lucrați cu gazda virtuală fără un nume de domeniu real, puteți configura localhosts pe mașina dvs. După cum am spus mai sus, acest lucru este foarte convenabil, de exemplu, în timpul dezvoltării. Pot crea mysite.dev, iar pe el va rula o versiune locală instabilă a site-ului. Pentru sistemele MacOS și Linux, trebuie să rulați următoarea comandă:

Sudo nano /etc/hosts

Dacă lucrați sub Windows, atunci fișierul cu gazde locale ar trebui să fie aproximativ această cale C:\Windows\System32\drivers\etc\hosts.

Adăugați o intrare despre noua gazdă locală la fișier. În cazul nostru, trebuie să adăugăm două înregistrări, deoarece în server_name am specificat două domenii.

12.34.56.789 mysite.ru 12.34.56.789 www.mysite.ru

Acum, până când această intrare este ștearsă, apelurile către mysite.ru vor primi informații despre această gazdă din acest fișier și vă vor redirecționa către serverul dvs. la distanță. Dacă serverul este implementat local, trebuie să scrieți „127.0.0.1” în loc de „12.34.56.789”.

Pentru a evita problemele viitoare, este o practică bună să ștergeți intrările gazdă după ce și-au îndeplinit scopul.

rezultate

Acum putem vedea rezultatele muncii noastre! Introducem adresa http://mysite.ru sau http://www.mysite.ru în browser și admirăm pagina de start pe care am creat-o din index.htm. Ambele adrese trebuie să arate noastre pagina principala. Asta e tot! Gazda noastră virtuală funcționează excelent.

Pe acest moment Cele două servere web care au câștigat cea mai mare popularitate. Acestea sunt Apache și Ngnix. Fiecare dintre ele are propriile sale avantaje și dezavantaje. Apache a fost dezvoltat încă din 1995 și dezvoltarea sa nu a ținut cont de toate nevoile posibile ale utilizatorilor, consumă multă memorie și resurse de sistem, dar este ușor de configurat; Nginx a fost dezvoltat puțin mai târziu în 2002, ținând cont de erorile Apache și concentrându-se pe performanță maximă.

Nu vom intra în detalii despre avantajele și dezavantajele ambelor servere web. Fiecare dintre ele are propriul său domeniu de aplicare. Acest ghid va acoperi instalarea Nginx Ubuntu 16.04. Deși voi vorbi despre Ubuntu 16.04, toți pașii vor funcționa și pentru alte distribuții. Configurarea Nginx este aceeași peste tot, doar comanda de instalare este diferită.

Primul pas este să instalați serverul web în sine pe sistem. Programul se află în depozitele oficiale, dar versiunea sa este deja puțin depășită, așa că dacă doriți cel mai mult versiune noua, trebuie să adăugați PPA:

sudo apt-add-repository ppa:nginx/stable

În prezent, versiunea 1.10.0 este disponibilă în depozitele oficiale, iar 1.10.1 este deja disponibilă în PPA stabil. Dacă nu aveți nevoie de versiune, puteți face fără PPA. Apoi, actualizați listele de pachete din depozite:

Și instalează ngnix:

sudo apt install nginx

După finalizarea instalării serverului Nginx, adăugați programul la pornire, astfel încât să pornească automat:

sudo systemctl enable nginx

Dacă deschideți browserul acum, veți vedea că nginx rulează, dar tot trebuie să îl configuram.

Configurarea Nginx Ubuntu

Configurarea Nginx Ubuntu este mult mai complicată decât Apache. Aici nu vom lua în considerare toate opțiunile și capacitățile programului, ci vom vorbi doar despre cele principale. Există diverse configurații în care Nginx este folosit ca server proxy și serverul principal Apache, dar nu ne va interesa asta. Trebuie să instalăm Nginx ca server web autonom.

Setările Nginx sunt foarte diferite - există un singur fișier de configurare principal și fișiere pentru gazdele virtuale. Configurația din fiecare director, ca în Apache, nu este acceptată.

• /etc/nginx/nginx.conf- fișierul de configurare principal
• /etc/nginx/sites-available/*- fisiere de configurare pentru gazde virtuale, cu alte cuvinte, pentru fiecare site.
• /etc/nginx/sites-enabled/*- fișierele de configurare ale site-urilor activate.

De fapt, fișierele de configurare pentru gazde virtuale sunt citite numai din directorul site-uri activate, dar acesta conține link-uri către site-uri disponibile. Acest sistem a fost inventat pentru a face posibilă dezactivarea temporară a anumitor site-uri fără a le șterge configurația. Toate celelalte fișiere conțin doar declarații variabile și setări standard, care nu trebuie schimbate. În ceea ce privește nginx.conf, toate fișierele de la site-enables sunt incluse în el și, prin urmare, pot conține exact aceleași instrucțiuni. Acum să ne uităm la fișierul de configurare principal:

sudo vi /etc/nginx/nginx.conf

După cum puteți vedea, fișierul este împărțit în secțiuni. Structura generală este:

opțiuni globale
evenimente()
http(
Server (
Locație()
}
Server()
}
Poștă()

• opțiuni globale sunt responsabili pentru funcționarea întregului program.
• evenimente- această secțiune conține setări pentru lucrul cu rețeaua.
• http- conține setări de server web. Trebuie să conțină o secțiune de server pentru reglaj fin fiecare site.
• Server- aceasta sectiune contine setarile pentru fiecare site gazduit pe serverul web.
• Locație- secțiunea de locație poate fi localizată doar în interiorul secțiunii de server și conține setări doar pentru o anumită solicitare.
• Poștă- conține setări de proxy de e-mail.

Înainte de a trece la opțiuni, trebuie să mai spunem câteva cuvinte despre sintaxa liniei din fișierul de configurare. Arata cam asa:

valoarea parametrului valoare_suplimentară...;

Linia trebuie să se termine cu „;” și toate parantezele deschise (trebuie să fie închise.

Acum că ați studiat puțin structura globală, puteți trece la analizarea parametrilor înșiși. Nu există multe opțiuni globale:

• utilizator- utilizatorul în numele căruia va rula programul.
• procese_lucrători- setează câte procese trebuie lansate pentru a paraleliza activitatea programului, nu trebuie să lansați mai multe procese decât aveți nuclee; Puteți seta parametrul autoși apoi programul va determina el însuși acest număr.
• pid= fișier pid program.
• worker_rlimit_nofile- indică numărul maxim de fișiere pe care programul le poate deschide. Calculat ca worker_processes * worker_connections* 2.

Am terminat cu opțiunile globale, nu erau multe și nu erau atât de interesante. Mult mai interesante din punct de vedere al optimizării sunt opțiunile din secțiunea evenimente:

• conexiuni_lucrători- numărul de conexiuni pe care programul le poate procesa simultan pe un proces. Dacă înmulțim worker_process cu acest parametru, obținem numărul maxim de utilizatori care se pot conecta la server în același timp. Se recomandă setarea valorii de la 1024 la 4048.
• multi_accept- permite acceptarea mai multor conexiuni în același timp, setați parametrul pornit sau dezactivat.
• utilizare- o modalitate de a lucra cu stiva de rețea. Valoarea implicită este poll, dar pe Linux este mai eficient să utilizați epoll.

• Trimite fișier- utilizați metoda de trimitere a datelor sendfile. Valoarea este activată.
• tcp_nodelay, tcp_nopush- trimiteți antetele și începutul fișierului într-un singur pachet. Valoarea este activată.
• keepalive_timeout- timeout de așteptare înainte ca conexiunea Keepalive să fie închisă, implicit este 65, dar poate fi redus la 10 secunde.
• keepalive_requests- numărul maxim de conexiuni keepalive de la un client, recomandat 100.
• reset_timedout_connection- întrerupeți conexiunile după un timeout. Valoarea este activată.
• open_file_cache- cache informații despre deschide fișiere. Linia de setare arată astfel: open_file_cache max=200000 inactive=20s; max - numărul maxim de fișiere în cache, timpul de stocare în cache.
• open_file_cache_valid- indică după ce oră trebuie ștearsă informațiile din cache. De exemplu: open_file_cache_valid 30s;
• open_file_cache_min_uses- cache informații despre fișierele care au fost cel puțin deschise cantitate specificată o singura data.
• open_file_cache_errors- cache informații despre fișierele lipsă, valoarea activată.

Principalii parametri au fost revizuiți. Aceste setări vă vor ajuta să obțineți performanțe mai bune de la nginx. Ne vom uita la secțiunile server și locație în configurarea gazdelor virtuale.

Configurarea compresiei Gzip

Comprimarea conținutului este necesară pentru a reduce dimensiunea datelor descărcate de browser. Acest lucru accelerează încărcarea site-ului, dar adaugă încărcare suplimentară procesorului serverului. Pentru a activa compresia în secțiunea http, trebuie să adăugați următorul parametru:

Această directivă poate fi folosită și în secțiunea server, atunci va funcționa numai pentru domeniul virtual specificat. În continuare, configurăm parametrii de compresie folosind următoarele opțiuni:

• gzip_min_length- lungimea minimă a paginii în octeți la care trebuie utilizată compresia, de exemplu, 1000 (1 kb)
• gzip_proxied- dacă este necesar să comprimați cererile proxy, orice spune că totul trebuie comprimat.
• gzip_types- tipuri de fișiere care trebuie comprimate, de exemplu: text/plain application/xml application/x-javascript text/javascript text/css text/json;
• gzip_disable „msie6”- compresia nu este acceptată în IE 6, așa că o dezactivăm.
• gzip_comp_level- nivel de compresie, opțiuni disponibile de la 1 la 10. 1 - minim, 10 - compresie maximă.

Configurarea gazdelor virtuale

După cum știți, un server poate găzdui mai multe site-uri web. Toate cererile vin la IP-ul serverului, iar nginx determină deja, pe baza domeniului, ce conținut trebuie servit. Pentru ca nginx să știe ce domeniu aparține, trebuie să configurați gazde virtuale. Fiecare gazdă este de obicei plasată într-un fișier separat. Configurația gazdei se află în secțiunea server, dar deoarece toate fișierele de pe site-uri activate sunt importate în secțiunea http, logica structurii fișierelor de configurare nu este întreruptă.

Să ne uităm la un exemplu de configurare:

vi /etc/nginx/sites-enabled/site.conf

• asculta 80- specifică că o conexiune ar trebui ascultată pe portul 80, poate conține și o opțiune server implicit, ceea ce înseamnă că acest domeniu va fi deschis dacă domeniul nu a fost specificat în cerere.
• rădăcină /var/www/html- directorul în care se află fișierele site-ului.
• index index.html- pagina care se va deschide implicit.
• numele serverului - Numele domeniului site-ul.
• access_log- un fisier pentru inregistrarea unui jurnal de solicitari catre server, poate fi folosit atat global in sectiunea http cat si pentru anumit tip fișiere în locație.
• error_log- jurnalul erorilor serverului web, poate accepta un parametru suplimentar care indică detaliile jurnalului. warn - maxim, crit - numai erori critice.

Acestea sunt toate setările de bază pentru gazda virtuală, după care va funcționa deja. Dar există și o secțiune de locație, care vă permite să configurați comportamentul serverului pentru anumite directoare și fișiere. Sintaxa locației este:

adresa locatiei()

Atât o interogare directă cu privire la rădăcina serverului, cât și expresiile regulate pot fi folosite ca adresă. Pentru a utiliza expresii regulate, acesta este precedat de un caracter „~”. Să ne uităm la exemplele de mai jos, dar deocamdată să ne uităm la posibilele directive:

• permite- permite accesul la locație pentru utilizatori, toți - toată lumea, puteți specifica și un ip sau o subrețea.
• nega- interziceți accesul la locație, tuturor - pentru toată lumea.
• fișierele de încercare- încearcă să deschidă fișierele într-o anumită ordine, deschide primul fișier găsit. De exemplu, această construcție: $uri $uri/index.html $uri.html =404; mai întâi încearcă să deschidă $uri, apoi index.html, dacă $uri.html nu este găsit și apoi, dacă niciun fișier prepozițional nu există, dă o eroare 404.
• expiră- setează timpul de stocare în cache a browserului pentru elementul dat, de exemplu, 1d - o zi, 2h - două ore, 30s - 30 secunde.

Pe lângă aceste directive principale, aici pot fi utilizate și altele. Pentru mai multe detalii, consultați documentația oficială. Să ne uităm la câteva exemple:

Nu înregistrați favicon:

locație = /favicon.ico (
log_not_found off;
access_log off;
}

Interziceți accesul la fișierele care încep cu un punct:

locație ~ /\. (
nega totul;
}

Cache fișiere obișnuite timp de 90 de zile:

locație ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2 |doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ (
access_log off; log_not_found off; expiră 90d;

14 august 2009 la 19:29

Configurarea nginx

• Nginx

Subiectul configurării corecte a nginx este foarte mare și, mă tem, nu se poate încadra în cadrul unui articol despre Habré. În acest text am încercat să vorbesc structura generala config, pot apărea mai târziu lucruri mici și detalii mai interesante. :)

Un bun punct de plecare pentru configurarea nginx este configurația care vine cu distribuția, dar multe dintre capabilitățile acestui server nici măcar nu sunt menționate în el. Un exemplu mult mai detaliat este pe site-ul lui Igor Sysoev: sysoev.ru/nginx/docs/example.html. Totuși, să încercăm mai bine să ne construim configurația de la zero, cu bridge și poeteses. :)

Sa incepem cu setari generale. În primul rând, vom indica utilizatorul în numele căruia va rula nginx (este rău să funcționeze ca root, toată lumea știe :))

Acum, să spunem lui nginx câte procese de lucru să apară. De obicei, buna alegere există un număr de procese egal cu numărul nuclee de procesor pe serverul dvs., dar merită să experimentați cu această setare. Dacă se așteaptă o sarcină mare HDD, puteți face un proces pentru fiecare hard disk fizic, deoarece toată munca va fi încă limitată de performanța sa.

Lucrător_procese 2;

Să clarificăm unde să scriem jurnalele de erori. Apoi, pentru individ servere virtuale, acest parametru poate fi suprascris, astfel încât în ​​acest jurnal să apară doar erori „globale”, de exemplu, legate de pornirea serverului.

Notificare Error_log /spool/logs/nginx/nginx.error_log; # Nivelul de notificare „notificare” poate fi desigur modificat

Acum vine secțiunea „evenimente” foarte interesantă. În acesta puteți seta numărul maxim de conexiuni pe care un proces de lucru le va procesa simultan și metoda care va fi utilizată pentru a primi notificări asincrone despre evenimentele din sistemul de operare. Desigur, puteți selecta doar acele metode care sunt disponibile pe sistemul de operare și au fost incluse în timpul compilării.

Aceste setări pot avea un impact semnificativ asupra performanței serverului dvs. Acestea trebuie selectate individual, în funcție de sistemul de operare și hardware. Pot să dau doar câteva reguli generale.

Module pentru lucrul cu evenimente:
- select și poll sunt de obicei mai lente și încarcă procesorul destul de greu, dar sunt disponibile aproape peste tot și funcționează aproape întotdeauna;
- kqueue și epoll - mai eficiente, dar disponibile numai pe FreeBSD și, respectiv, Linux 2.6;
- rtsig - drăguță metoda eficienta, și este acceptat chiar și de Linux-uri foarte vechi, dar poate cauza probleme când un numar mare conexiuni;
- /dev/poll - din câte știu eu, funcționează în puțin mai mult sisteme exotice, ca Solaris, și este destul de eficient în el;

parametru worker_connections:
- Numărul maxim total de clienți serviți va fi egal cu worker_processes * worker_connections;
- Uneori pot lucra Partea pozitivă chiar și cele mai extreme valori, cum ar fi 128 de procese, 128 de conexiuni per proces sau 1 proces, dar cu parametrul worker_connections=16384. În acest din urmă caz, totuși, cel mai probabil va trebui să reglați sistemul de operare.

Evenimente (
conexiuni_muncitor 2048;
utilizați kqueue; # Avem BSD :)
}

Următoarea secțiune este cea mai mare și conține cele mai interesante lucruri. Aceasta este o descriere a serverelor virtuale și a unor parametri comuni tuturor acestora. Voi omite setările standard care sunt în fiecare configurație, cum ar fi căile către jurnale.

Http(
# Tot codul de mai jos va fi în această secțiune %)
# ...
}

În această secțiune pot exista niște parametri destul de interesanți.

Apelul de sistem sendfile este relativ nou pentru Linux. Vă permite să trimiteți date în rețea fără a fi nevoie să le copiați în spațiul de adrese al aplicației. În multe cazuri, acest lucru îmbunătățește semnificativ performanța serverului, așa că cel mai bine este să activați întotdeauna opțiunea sendfile.

Parametrul keepalive_timeout este responsabil pentru timp maxim menținerea unei conexiuni keepalive dacă utilizatorul nu solicită nimic prin intermediul acesteia. Luați în considerare modul în care site-ul dvs. trimite solicitări și ajustați această setare. Pentru site-urile care folosesc activ AJAX, este mai bine să păstrați conexiunea mai mult timp pentru paginile statice pe care utilizatorii le vor citi mult timp, este mai bine să întrerupeți conexiunea mai devreme; Rețineți că, menținând o conexiune keepalive inactivă, luați o conexiune care ar putea fi utilizată diferit. :)

Keepalive_timeout 15;

Separat, merită evidențiate setările proxy nginx. Cel mai adesea, nginx este folosit tocmai ca server proxy, prin urmare au destul mare importanță. În special, este logic să setați dimensiunea bufferului pentru cererile proxy nu mai puțin decât dimensiunea de răspuns așteptată de la serverul backend. Cu backend-uri lente (sau, dimpotrivă, foarte rapide), este logic să schimbați intervalele de timp pentru așteptarea unui răspuns din partea backend-ului. Amintiți-vă, cu cât aceste timeout-uri sunt mai lungi, cu atât utilizatorii dvs. vor aștepta mai mult un răspuns dacă backend-ul este lent.

Proxy_buffers 8 64k;
proxy_intercept_errors activat;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Un mic truc. În cazul în care nginx deservește mai mult de o gazdă virtuală, este logic să se creeze o „gazdă virtuală implicită” care va procesa cererile în cazurile în care serverul nu poate găsi o altă alternativă folosind antetul Host din cererea clientului.

# gazdă virtuală implicită
Server (
asculta 80 implicit;
nume_server gazdă locală;
nega totul;
}

Aceasta poate fi urmată de una (sau mai multe) secțiuni „server”. Fiecare dintre ele descrie o gazdă virtuală (cel mai adesea, bazată pe nume). Pentru proprietarii mai multor site-uri pe o singură găzduire sau pentru hosteri, poate exista ceva de genul unei directive

Includeți /spool/users/nginx/*.conf;

Cel mai probabil, restul își vor descrie gazda virtuală direct în configurația principală.

Server (
asculta 80;

# Vă rugăm să rețineți că directiva server_name poate specifica mai multe nume în același timp.
nume_server myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log cronometrat;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Să setăm codarea implicită pentru ieșire.

Charset utf-8;

Și să spunem că nu vrem să acceptăm cereri de la clienți care au o lungime mai mare de 1 megaoctet.

Client_max_body_size 1m;

Să activăm SSI pentru server și să cerem să rezervăm cel mult 1 kilobyte pentru variabilele SSI.

Si on;
ssi_value_length 1024;

Și, în final, vom descrie două locații, dintre care una va duce la backend, la Apache care rulează pe portul 9999, iar a doua va trimite imagini statice din sistemul de fișiere local. Pentru două locații, acest lucru nu are sens, dar pentru un număr mai mare dintre ele are sens, de asemenea, să definiți imediat o variabilă în care va fi stocat directorul rădăcină a serverului și apoi să o utilizați în descrierile locațiilor.

Nginx este un server web popular și puternic și un proxy invers.

Nginx are multe avantaje, dar setările sale sunt destul de complexe și nu întotdeauna clare pentru începători. Acest manual vă va ajuta să înțelegeți parametrii de bază, sintaxa și fișierele de configurare ale lui Nginx.

Notă: Acest tutorial a fost realizat pe Ubuntu 12.04.

Ierarhia directorului Nginx

Nginx stochează fișierele de configurare în directorul /etc/nginx.

Acest director conține mai multe directoare și fișiere de configurare modulare.

cd /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf site-available/win-utf
koi-utf naxsi_core.rules proxy_params site-uri activate/

Utilizatorii Apache sunt deja familiarizați cu directoarele disponibile pentru site-uri și site-uri activate. Aceste directoare definesc configurațiile site-ului. Fișierele sunt de obicei create și stocate în site-uri disponibile; site-uri activate stochează numai configurațiile site-urilor activate. Pentru a face acest lucru, trebuie să creați un link simbolic de la site-uri disponibile la site-uri activate.

Directorul conf.d poate fi folosit și pentru a stoca configurații. Fiecare fișier cu o extensie .conf va fi citit când Nginx pornește. Sintaxa unor astfel de fișiere nu trebuie să conțină erori.

Aproape toate fișierele rămase sunt stocate în /etc/nginx, care conține informații de configurare pentru anumite procese sau componente suplimentare.

Fișierul principal de configurare Nginx este nginx.conf.

fișierul nginx.conf

Fișierul nginx.conf citește fișierele de configurare corespunzătoare și le combină într-un singur fișier de configurare atunci când serverul pornește.

Deschideți fișierul:

sudo nano /etc/nginx/nginx.conf

utilizator www-data;
lucrător_procese 4;
pid /var/run/nginx.pid;
evenimente (
conexiuni_muncitor 768;
#multi_accept on;
}
http(
. . .

Primele rânduri oferă informații generale despre Nginx. Utilizatorul de linie www-data specifică utilizatorul cu care este pornit serverul.

Directiva pid specifică unde vor fi stocate PID-urile de proces uz intern. Linia worker_processes determină numărul de procese pe care Nginx le poate suporta simultan.

De asemenea, puteți specifica jurnalele în această parte a fișierului (de exemplu, jurnalul de erori este definit folosind directiva error_log).

In spate Informații generale despre server urmează secțiunea de evenimente. Acesta gestionează gestionarea conexiunilor Nginx. Este urmat de blocul http. Înainte de a continua cu configurațiile serverului web, trebuie să înțelegem cum este formatat fișierul de configurare Nginx.

Structura fișierului de configurare Nginx

Fișierul de configurare Nginx este împărțit în blocuri.

Primul bloc este evenimente, urmat de http și începe ierarhia principală a configurațiilor.

Detaliile de configurare ale unui bloc http sunt stratificate folosind blocuri închise care moștenesc proprietăți de la blocul în care se află. Blocul http stochează majoritatea configurațiilor generale Nginx, care sunt împărțite în blocuri de server, care la rândul lor sunt împărțite în blocuri de locații.

Când configurați Nginx, este important să rețineți următoarea regulă: cu cât este mai mare nivelul de configurare, cu atât mai multe blocuri moștenesc această configurație; cu cât nivelul de configurare este mai scăzut, cu atât este mai „individual”. Adică, dacă parametrul X trebuie utilizat în fiecare bloc de server, atunci un astfel de parametru trebuie plasat în blocul http.

Dacă te uiți cu atenție la fișier, vei observa că acesta conține multe opțiuni care determină comportamentul programului în ansamblu.

De exemplu, pentru a configura compresia fișierelor, trebuie să setați următorii parametri:

gzip on;
gzip_disable „msie6”;

Acest lucru va activa suportul gzip pentru comprimarea datelor trimise către client și va dezactiva gzip pentru Internet Explorer 6 (deoarece acest browser nu acceptă compresia datelor).

Dacă vreun parametru ar trebui să aibă sens diferitîn mai multe blocuri de server, atunci un astfel de parametru poate fi activat nivel superiorși apoi suprascrieți-l în interiorul blocurilor serverului. Ca rezultat, Nginx va executa parametrul de cel mai jos nivel.

Acest nivel de configurații evită nevoia de a gestiona mai multe fișiere identice. De asemenea, dacă ați uitat să definiți parametrii Cel mai mic nivel, Nginx va implementa pur și simplu opțiunile implicite.

Blocul http din fișierul nginx.conf se termină astfel:

includ /etc/nginx/conf.d/*.conf;
includ /etc/nginx/sites-enabled/*;

Aceasta înseamnă că blocurile de server și locație, care definesc setările pentru anumite site-uri și adrese URL, vor fi stocate în afara acestui fișier.

Acest lucru permite o arhitectură de configurare modulară în care pot fi create noi fișiere pentru a servi site-uri noi. De asemenea, vă permite să grupați fișiere similare.

Închideți fișierul nginx.conf. Acum trebuie să studiați setările site-urilor individuale.

Blocuri virtuale Nginx

Blocurile de server din Nginx sunt analoge cu cele virtuale gazde Apache(dar pentru comoditate sunt numite și gazde virtuale). În esență, blocurile de server sunt specificații site-uri web separate găzduite pe același server.

În directorul site-uri disponibile puteți găsi fișierul implicit de blocare a serverului care vine cu serverul. Acest fisier contine toate datele necesare intretinerii site-ului.

site-uri cd-disponibile
sudo nano implicit

root /usr/share/nginx/www;
index index.html index.htm;
nume_server gazdă locală;
Locație/(

}
locație /doc/ (

alias /usr/share/doc/;
autoindex activat;
permite 127.0.0.1;
nega totul;

Fișierul implicit este foarte bine comentat, dar în exemplul de mai sus comentariile sunt omise pentru simplitate și comoditate.

Blocul server include toate setările plasate între acolade:

Server (
. . .
}

Acest bloc este plasat în fișierul nginx.conf aproape de sfârșitul blocului http folosind directiva include.

Directiva rădăcină specifică directorul în care va fi stocat conținutul site-ului. Nginx va căuta în acest director fișierele solicitate de utilizator. În mod implicit, acesta este /usr/share/nginx/www.

Vă rugăm să rețineți: toate liniile se termină cu punct și virgulă. Acesta este modul în care Nginx separă o directivă de alta. Dacă nu există punct și virgulă, Nginx va citi cele două directive (sau mai multe directive) ca o singură directivă cu argumente suplimentare.

Directiva index specifică fișierele care vor fi folosite ca index. Serverul web va verifica fișierele în ordinea în care sunt listate. Dacă nu a fost solicitată nicio pagină, blocul serverului va găsi și va returna fișierul index.html. Dacă nu poate găsi acel fișier, va încerca să proceseze index.htm.

directiva nume_server

Directiva server_name conține o listă de nume de domenii care vor fi servite de acest bloc de server. Numărul de domenii este nelimitat; Domeniile din listă trebuie separate prin spații.

Un asterisc (*) la începutul sau la sfârșitul unui domeniu specifică un nume cu o mască, unde asteriscul se potrivește cu o parte (sau mai multe părți) din nume. De exemplu, numele *.example.com se potrivește cu numele forum.example.com și www.animals.example.com.

Dacă adresa URL solicitată se potrivește cu mai multe directive server_name, va răspunde mai întâi cu cea care se potrivește exact.

Dacă adresa nu găsește o potrivire, va căuta cel mai mult nume lung cu o mască care se termină cu un asterisc. Dacă nu găsește un astfel de nume, va returna prima potrivire a expresiei regulate.

Numele de server care folosesc expresii regulate încep cu un tilde (~). Din pacate, Acest subiect depășește domeniul de aplicare al acestui articol.

Blocuri de locație

Locația/linia indică faptul că directivele din paranteze se vor aplica tuturor resurselor solicitate care nu se potrivesc cu niciun alt bloc de locație.

Astfel de blocuri pot conține o cale uri (de exemplu /doc/). Pentru a stabili o potrivire completă între locație și uri, se folosește simbolul =. Caracterul ~ se potrivește cu expresiile regulate.

Un tilde activează modul diferențiat între majuscule și minuscule, în timp ce un tilde cu un asterisc activează modul care nu ține seama de majuscule.

Dacă cererea se potrivește pe deplin cu blocul de locație, atunci serverul oprește căutarea și folosește un astfel de bloc. Dacă serverul nu găsește un bloc de locație care se potrivește complet, compară URI-ul cu parametrii directivelor de locație. Nginx va selecta un bloc care folosește combinația de caractere ^~ și care se potrivește cu URI.

Dacă opțiunea ^~ nu este utilizată, Nginx va selecta cea mai apropiată potrivire și va efectua o căutare a expresiei regulate pentru a încerca să se potrivească cu unul dintre modelele disponibile. Dacă găsește o astfel de expresie, o folosește. Dacă nu există o astfel de expresie, atunci serverul utilizează potrivirea URI găsită anterior.

Ca o notă finală, Nginx preferă potrivirile exacte. Dacă nu există astfel de meciuri, se caută expresie uzualași apoi caută după URI. Pentru a schimba prioritatea de căutare a unui URI, utilizați combinația de caractere ^~.

directiva try_files

Directiva try_files este foarte unealtă folositoare, care verifică fișierele într-o anumită ordine și utilizează primul fișier găsit pentru a procesa cererea.

Acest lucru vă permite să utilizați parametri suplimentari pentru a defini modul în care Nginx va servi cererile.

Fișierul de configurare implicit are linia:

try_files $uri $uri/ /index.html;

Aceasta înseamnă că atunci când se primește o solicitare care este servită de un bloc de locație, Nginx va încerca mai întâi să servească uri ca fișier (acest comportament este specificat de variabila $uri).

Dacă serverul nu găsește o potrivire pentru variabila $uri, va încerca să folosească uri ca director.

Folosind o bară oblică finală, serverul verifică existența unui director, de exemplu $uri/.

Dacă nu este găsit niciun fișier sau director, Nginx execută fișierul implicit (în acest caz index.html în directorul rădăcină al blocului server). Fiecare directivă try_files folosește ultimul parametru ca alternativă, deci fișierul trebuie să existe în sistem.

În cazul în care serverul web nu găsește o potrivire în parametrii anteriori, poate returna o pagină de eroare. Pentru a face acest lucru, utilizați semnul egal și codul de eroare.

De exemplu, dacă locația/blocul nu poate găsi resursa solicitată, ar putea returna o eroare 404 în loc de un fișier index.html:

try_files $uri $uri/ =404;

Pentru a face acest lucru, trebuie să puneți un semn egal și să setați codul de eroare ca ultimul parametru (=404).

Opțiuni suplimentare

Directiva alias permite Nginx să servească pagini de blocare a locației în afara unui director dat (de exemplu, în afara rădăcină).

De exemplu, fișierele solicitate din /doc/ vor fi difuzate din /usr/share/doc/.

Directiva autoindex on vă permite să activați listarea directoarelor Nginx pentru o anumită directivă de locație.

Liniile de autorizare și refuzare controlează accesul la directoare.

Concluzie

Serverul web Nginx este bogat în funcții și foarte puternic, dar terminologia și opțiunile sale pot fi confuze.

Odată ce înțelegeți configurațiile Nginx și învățați cum să lucrați cu ele, veți beneficia de toate beneficiile acestui instrument puternic și ușor.

Etichete: ,