Վեբ սերվերի stack-ը՝ nginx, PHP-FPM և Node

01Ինչ է անում վեբ սերվերը, և ինչպես է դա անում nginx-ը

Պատկերացրու զբաղված ռեստորան։ Դռան մոտ կանգնած host-ը դիմավորում է յուրաքանչյուր հյուրի, մենյու է տալիս (static ֆայլեր) և իրական պատվերներն ուղարկում է խոհանոց (քո հավելվածը)։ Վեբ սերվերը հենց այդ host-ն է։ Այն լսում է 80 և 443 port-երով, parse է անում HTTP request-ը, որոշում է, թե ով պետք է պատասխանի դրան, և պատասխանը հետ է ուղարկում։ nginx-ը event-driven է․ փոքր թվով worker պրոցեսներ (սովորաբար մեկը յուրաքանչյուր CPU core-ի համար) յուրաքանչյուրը մշակում է հազարավոր միացումներ non-blocking I/O-ով, ուստի պարապ կամ դանդաղ client-ը գրեթե ոչինչ չարժե։ Apache-ն ավանդաբար օգտագործում էր մեկ պրոցես կամ thread յուրաքանչյուր միացման համար (prefork/worker MPM-ներ)․ նրա ժամանակակից event MPM-ը կրճատեց տարբերությունը, և Apache-ն դեռ փայլում է per-directory .htaccess ֆայլերով և մոդուլների հսկայական էկոհամակարգով։ Գործնականում շատ stack-եր, այդ թվում hosting պանելների մեծ մասը, nginx-ը դնում են առջևում static ֆայլերի և TLS-ի համար, իսկ Apache-ն պահում են դրա հետևում՝ համատեղելիության համար։

• Master պրոցես՝ կարդում է config-ը, բացում է port-երը, կառավարում է worker-ները։
• Worker պրոցեսներ՝ մշակում են միացումները․ worker_processes auto-ն համապատասխանեցնում է CPU core-երին։
• Apache-ի .htaccess-ը հարմար է, բայց կարդացվում է յուրաքանչյուր request-ի ժամանակ․ nginx-ը համարժեք չունի, և դա միտումնավոր է։

02Server block-եր և location-ներ

nginx config-ը ծառ է։ http context-ը պահում է գլոբալ կարգավորումները։ Դրա ներսում յուրաքանչյուր server block մեկ virtual host է, որն ընտրվում է ըստ port-ի և Host header-ի (server_name)։ Server-ի ներսում location block-երը համապատասխանեցնում են URL-ի ճանապարհը և որոշում, թե ինչ տեղի ունենա՝ սպասարկել ֆայլ, փոխանցել PHP-ին, proxy անել Node-ին, թե մերժել։ Location-ների համընկնումն ունի կանոններ, որոնք արժե անգիր անել․ ճշգրիտ համընկնումները (=) հաղթում են առաջինը, հետո ամենաերկար prefix համընկնումը, եթե միայն regular-expression location-ը (~) նույնպես չի համընկնում, որի դեպքում հաղթում է առաջին համընկնող regex-ը (^~ prefix-ը կանգնեցնում է regex-ի ստուգումները)։ try_files-ը հիմնական աշխատող գործիքն է․ այն ստուգում է իրական ֆայլը, հետո դիրեկտորիան, հետո fallback է անում հավելվածի entry point-ին։ Ubuntu-ում կայքերը գտնվում են /etc/nginx/sites-available-ում և միացվում են sites-enabled-ում symlink-ով։

1server {
2    listen 80;
3    server_name static.example.com;
4    root /var/www/static/public;
5    index index.html;
6 
7    location / {
8        try_files $uri $uri/ =404;
9    }
10 
11    location ~* \.(css|js|svg|png|jpg|webp|woff2)$ {
12        expires 30d;
13        access_log off;
14    }
15 
16    location ~ /\.(?!well-known) {
17        deny all;
18    }
19}

03PHP-FPM՝ ինչպես է nginx-ը գործարկում PHP

nginx-ը ինքը չի կարող PHP կատարել։ Այն request-ը FastCGI պրոտոկոլով փոխանցում է PHP-FPM-ին (FastCGI Process Manager)՝ առանձին ծառայության, որը պատրաստ պահում է PHP worker պրոցեսների pool։ Միացումը սովորաբար Unix socket է, օրինակ՝ /run/php/php8.5-fpm.sock (PHP 8.5-ը լռելյայն է Ubuntu 26.04-ում, 24.04-ը գալիս է 8.3-ով)։ Pool-ը worker-ների խումբ է՝ իր օգտատիրոջով, socket-ով և սահմանափակումներով։ Յուրաքանչյուր հավելվածի տուր իր pool-ը, որն աշխատում է իր system user-ով․ այդ դեպքում մեկ կոտրված կայքը չի կարող կարդալ մեկ այլ կայքի ֆայլերը, և մեկ դանդաղ հավելվածը չի կարող խժռել բոլոր worker-ները։ pm = dynamic-ը worker-ները scale է անում սահմանների միջև․ pm.max_children-ը կոշտ սահմանն է, ուստի չափավորիր այն մոտավորապես որպես (RAM PHP-ի համար) բաժանած (worker-ի միջին հիշողությանը, Laravel-ի համար հաճախ 40-ից 80 MB)։ Երբ բոլոր child-երը զբաղված են, request-ները հերթ են կանգնում, և տեսնում ես 502/504 սխալներ և «server reached pm.max_children» FPM log-ում։

1; /etc/php/8.5/fpm/pool.d/api.conf
2[api]
3user = api
4group = api
5listen = /run/php/php8.5-fpm-api.sock
6listen.owner = www-data
7listen.group = www-data
8pm = dynamic
9pm.max_children = 20
10pm.start_servers = 4
11pm.min_spare_servers = 2
12pm.max_spare_servers = 6
13pm.max_requests = 500
14request_terminate_timeout = 60s

04Laravel API nginx-ի հետևում

Laravel-ն ունի մեկ entry point՝ public/index.php, և document root-ը պետք է ուղղված լինի public թղթապանակին, որպեսզի .env-ը, storage-ը և vendor-ը երբեք հասանելի չլինեն վեբից։ try_files-ը նախ սպասարկում է իրական ֆայլերը, իսկ մնացած ամեն ինչ ուղարկում է index.php՝ query string-ը անփոփոխ։ $document_root-ի փոխարեն $realpath_root-ի օգտագործումը կարևոր է, երբ deploy ես անում «current» symlink-ով․ այդ դեպքում PHP-ն տեսնում է resolve արված release ճանապարհը, ուստի OPcache-ը չի շարունակում սպասարկել հին release-ը symlink-ի փոխարկումից հետո։ Ստորև certificate-ների ճանապարհներն այն են, ինչ certbot-ը ստեղծում է Let's Encrypt-ի համար։ http2 on-ը HTTP/2 միացնելու ժամանակակից ձևն է․ հին «listen 443 ssl http2» ձևը deprecated է nginx 1.25.1-ից ի վեր։

1server {
2    listen 443 ssl;
3    http2 on;
4    server_name api.example.com;
5    root /var/www/api/current/public;
6    index index.php;
7    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
8    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
9    client_max_body_size 20m;
10 
11    location / { try_files $uri $uri/ /index.php?$query_string; }
12 
13    location ~ \.php$ {
14        include snippets/fastcgi-php.conf;
15        fastcgi_pass unix:/run/php/php8.5-fpm-api.sock;
16        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
17        fastcgi_param DOCUMENT_ROOT $realpath_root;
18    }
19    location ~ /\.(?!well-known) { deny all; }
20}

05Next.js frontend reverse proxy-ի միջոցով

Node հավելվածը (Next.js, NestJS, Express) իր սեփական HTTP սերվերն է, որը լսում է լոկալ port-ով, օրինակ՝ 127.0.0.1:3000։ nginx-ը գործում է որպես reverse proxy․ այն ընդունում է public HTTPS միացումը և request-ը փոխանցում այդ port-ին՝ ավելացնելով header-ներ, որպեսզի հավելվածն իմանա client-ի իրական IP-ն և պրոտոկոլը։ Node հավելվածը bind արա 127.0.0.1-ին, որպեսզի այն երբեք ուղիղ հասանելի չլինի։ Պրոցեսը կենդանի պահիր pm2-ով (pm2 start npm --name web -- start, հետո pm2 startup և pm2 save) կամ systemd unit-ով Restart=always-ով։ map block-ը պատկանում է http context-ին․ այն թույլ է տալիս WebSocket upgrade-ներին անցնել՝ սովորական request-ները պահելով կրկնակի օգտագործվող keepalive միացումների վրա։ Ավելացրու երկրորդ server block 80 port-ով, որը վերադարձնում է 301 դեպի HTTPS, և միացրու gzip (gzip_types CSS-ի, JS-ի, JSON-ի, SVG-ի համար)․ Brotli-ին պետք է լրացուցիչ մոդուլ, կամ կարող ես թողնել, որ Cloudflare-ի նման CDN-ը սեղմի edge-ում։

1map $http_upgrade $connection_upgrade { default upgrade; '' ''; }
2upstream web_app { server 127.0.0.1:3000; keepalive 16; }
3server {
4    listen 443 ssl;
5    http2 on;
6    server_name example.com;
7    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
8    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
9 
10    location / {
11        proxy_pass http://web_app;
12        proxy_http_version 1.1;
13        proxy_set_header Host $host;
14        proxy_set_header X-Real-IP $remote_addr;
15        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
16        proxy_set_header X-Forwarded-Proto $scheme;
17        proxy_set_header Upgrade $http_upgrade;
18        proxy_set_header Connection $connection_upgrade;
19    }
20}

06Zero-downtime reload-ներ և deploy-ներ

Երբեք nginx-ը restart մի արա config-ի փոփոխությունը կիրառելու համար։ Ստուգիր այն, հետո reload արա․ master պրոցեսը կարդում է նոր config-ը, գործարկում է նոր worker-ներ և թույլ է տալիս հին worker-ներին ավարտել իրենց ընթացիկ request-ները մինչև դուրս գալը։ Եթե ստուգումը ձախողվում է, ոչինչ չի փոխվում, և հին config-ը շարունակում է սպասարկել։ Նույն գաղափարը վերաբերում է հավելվածներին։ PHP-FPM-ն աջակցում է graceful reload։ Laravel-ի համար յուրաքանչյուր release deploy արա իր թղթապանակում, այնտեղ գործարկիր composer install և migration-ները, հետո ատոմար փոխարկիր «current» symlink-ը և reload արա PHP-FPM-ը․ rollback-ը պարզապես symlink-ը հետ ուղղելն է։ Restart արա queue worker-ները (php artisan queue:restart), որպեսզի դրանք վերցնեն նոր կոդը։ Node-ի համար pm2 reload-ը cluster ռեժիմում instance-ները restart է անում մեկ առ մեկ․ մեկ fork-mode instance-ի դեպքում դա փաստացի restart է, ուստի գործարկիր առնվազն երկու instance, եթե քեզ պետք է իրական zero downtime։

1# nginx: validate, then graceful reload
2sudo nginx -t && sudo systemctl reload nginx
3 
4# Laravel release switch (atomic symlink swap)
5ln -sfn /var/www/api/releases/2026-11-05_1200 /var/www/api/current
6sudo systemctl reload php8.5-fpm
7php /var/www/api/current/artisan queue:restart
8 
9# Node: rolling restart of a pm2 cluster
10pm2 reload web

07Hosting պանելներ ընդդեմ մաքուր սերվերի

Plesk-ի և cPanel-ի նման պանելները քո փոխարեն տեղադրում և կառավարում են այս ամբողջ stack-ը՝ վեբ սերվեր, PHP-ի տարբերակներ, տվյալների բազաներ, mail, DNS, certificate-ներ և backup-ներ, ամեն ինչ վեբ UI-ով։ Դրանք հիանալի են, երբ շատ փոքր կայքեր պետք է կառավարվեն ոչ մասնագետների կողմից, կամ երբ hosting ես վաճառում։ Գինը վերահսկողությունն ու overhead-ն է։ Պանելներն ավելացնում են լիցենզիայի վճարներ, լրացուցիչ ծառայություններ, որոնք հիշողություն են օգտագործում և patch-ի կարիք ունեն, իրենց config template-ները, որոնք վերագրում են ձեռքով արված փոփոխությունները, և ավելի մեծ attack surface (պանելն ինքը login էջ է ինտերնետում)։ nginx-ով, PHP-FPM-ով, Node-ով և մի քանի script-ով մաքուր սերվերն ավելի թեթև է և ամբողջությամբ հասկանալի, բայց յուրաքանչյուր մաս քոնն է՝ թարմացումներ, certificate-ներ, backup-ներ և monitoring։ Ինժեների կողմից գործարկվող մի քանի հավելվածի համար մաքուրը սովորաբար ավելի լավն է, տասնյակ brochure կայքերի և mailbox-ների համար պանելը դեռ կարող է պրագմատիկ ընտրություն լինել։

08Buffering, դանդաղ client-ներ և streaming պատասխաններ

nginx-ի ամենաարժեքավոր աշխատանքներից մեկն անտեսանելի է՝ buffering-ը։ Երբ թույլ կապով հեռախոսը form է վերբեռնում, nginx-ը նախ կարդում է հարցման ամբողջ body-ն (հիշողության մեջ՝ մինչև client_body_buffer_size, հետո ժամանակավոր ֆայլում) և միայն դրանից հետո է այն փոխանցում PHP-FPM-ին կամ Node-ին։ Վերադարձի ճանապարհին այն արագ կարդում է upstream-ի ամբողջ պատասխանը proxy կամ FastCGI buffer-ների մեջ և ինքն է այն կաթիլ առ կաթիլ փոխանցում դանդաղ client-ին։ Թանկ application worker-ը ազատվում է միլիվայրկյաններում, փոխանակ վայրկյաններով զբաղված մնալու գնացքում նստած ինչ-որ մեկի պատճառով։ Բացառությունը streaming-ն է. Server-Sent Events-ը, long polling-ը և stream արվող AI կամ հաշվետվության պատասխանները պետք է հասնեն client-ին, երբ արտադրվում են։ Այդ location-ների համար անջատեք proxy buffering-ը և բարձրացրեք proxy_read_timeout-ը, որը լռելյայն 60 վայրկյան է երկու read-երի միջև։ Հավելվածը կարող է նաև անջատել buffering-ը կոնկրետ պատասխանի համար X-Accel-Buffering: no header-ով։

1location /events/ {
2    proxy_pass http://web_app;
3    proxy_http_version 1.1;
4    proxy_set_header Connection "";
5    proxy_set_header Host $host;
6    proxy_buffering off;          # send bytes as soon as they arrive
7    proxy_cache off;
8    proxy_read_timeout 1h;        # default 60s would cut idle streams
9}

09Microcaching. ինչպես դիմանալ տրաֆիկի պիկին

Այն էջերի համար, որոնք նույնն են յուրաքանչյուր անանուն այցելուի համար (ապրանքների ցուցակ, հրապարակային API պատասխան), nginx-ը կարող է քեշավորել upstream-ի պատասխանը նույնիսկ ընդամենը մեկ վայրկյանով։ Թվում է անօգուտ, բայց վայրկյանում 500 հարցման դեպքում այն 500 PHP կատարումը վերածում է մեկի։ fastcgi_cache_lock-ը ստիպում է նույն չքեշավորված key-ի միաժամանակյա հարցումներին սպասել մեկ upstream fetch-ի, փոխանակ PHP-ի վրա «խուժելու», իսկ fastcgi_cache_use_stale-ը updating-ով մատուցում է մի փոքր հին պատճենը, մինչ մեկ հարցումը այն թարմացնում է background-ում։ Վտանգը անձնական տվյալների քեշավորումն է։ Քեշավորեք միայն GET և HEAD անանուն օգտատերերի համար. շրջանցեք cache-ը, երբ առկա է session cookie կամ Authorization header, և երբեք մի քեշավորեք cookie սահմանող պատասխանները։ X-Cache header-ը (HIT, MISS, BYPASS, STALE) թույլ է տալիս վարքագիծը ստուգել curl -I-ով։ proxy_cache-ը նույն կերպ է աշխատում Node հավելվածների առջև։

1# http context
2fastcgi_cache_path /var/cache/nginx/api levels=1:2 keys_zone=api_cache:50m
3                   max_size=1g inactive=10m use_temp_path=off;
4 
5# inside location ~ \.php$
6fastcgi_cache api_cache;
7fastcgi_cache_key "$scheme$request_method$host$request_uri";
8fastcgi_cache_valid 200 1s;
9fastcgi_cache_lock on;
10fastcgi_cache_use_stale error timeout updating http_500 http_503;
11fastcgi_cache_background_update on;
12fastcgi_cache_bypass $cookie_app_session $http_authorization;
13fastcgi_no_cache     $cookie_app_session $http_authorization;
14add_header X-Cache $upstream_cache_status always;

10Rate limiting limit_req-ով

limit_req-ը իրականացնում է leaky bucket ըստ key-ի, սովորաբար՝ client-ի հասցեի։ limit_req_zone-ը գտնվում է http context-ում և սահմանում է key-ը, shared memory zone-ը և արագությունը (r/s կամ r/m)։ 64-բիթանոց համակարգերում յուրաքանչյուր վիճակ զբաղեցնում է 128 բայթ, ուստի 10m zone-ը հետևում է մոտ 80,000 հասցեի։ location-ի ներսում limit_req-ը կիրառում է այն։ burst-ը արագությունից բարձր հարցումների հերթի չափն է։ Առանց nodelay-ի այդ հերթագրված հարցումները ուշացվում են՝ արագությանը համապատասխանելու համար, ինչը upstream-ները հարթ է պահում, բայց էջերը դանդաղ են թվում. nodelay-ով դրանք մատուցվում են անմիջապես, և մերժվում են միայն burst-ից դուրս հարցումները։ delay=N-ը (1.15.7-ից) համատեղում է երկուսը։ Մերժումները լռելյայն 503 են, ինչը մոնիթորինգի համար outage է թվում, ուստի սահմանեք limit_req_status 429։ Հիշողություն խնայելու համար օգտագործեք $binary_remote_addr՝ $remote_addr-ի փոխարեն, և եթե առջևում CDN կա, նախ կարգավորեք իրական IP-ները, այլապես բոլոր այցելուները կկիսեն CDN-ի bucket-ը։

1# http context
2limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
3limit_req_zone $binary_remote_addr zone=api:10m   rate=10r/s;
4limit_req_status 429;
5 
6# server context
7location = /api/login {
8    limit_req zone=login burst=5 nodelay;
9    try_files $uri /index.php?$query_string;
10}
11location /api/ {
12    limit_req zone=api burst=20 nodelay;
13    try_files $uri /index.php?$query_string;
14}

11Edge case-եր. default server-ներ, իրական IP-ներ և կապերի սահմանաչափեր

Եթե հարցման Host header-ը չի համընկնում ոչ մի server_name-ի հետ, nginx-ը այն փոխանցում է այդ port-ի default server-ին, որը առաջին սահմանվածն է, եթե միայն մեկը նշված չէ default_server։ Scanner-ները, որոնք դիմում են ուղիղ ձեր IP-ին, այդ դեպքում կտեսնեն ձեր առաջին կայքը, իսկ HTTPS-ով՝ նրա սերտիֆիկատը, ինչը բացահայտում է, թե որ դոմեններն են այնտեղ։ Catch-all server-ը, որը մերժում է TLS handshake-ը (ssl_reject_handshake, nginx 1.19.4+) և պարզ HTTP-ն փակում է ոչ ստանդարտ 444-ով, խուսափում է դրանից։ Cloudflare-ի կամ load balancer-ի հետևում օգտագործեք realip մոդուլը. set_real_ip_from՝ յուրաքանչյուր վստահելի proxy range-ի համար, և real_ip_header CF-Connecting-IP կամ X-Forwarded-For, որպեսզի log-երը, rate limit-ները և fail2ban-ը տեսնեն այցելուին։ Երբեք մի վստահեք այդ header-ին չվստահված աղբյուրներից։ Վերջապես՝ թողունակությունը. worker_processes-ը բազմապատկած worker_connections-ով սահմանափակում է միաժամանակյա կապերը, իսկ proxy արված հարցումն օգտագործում է երկու կապ (client գումարած upstream), ուստի worker_connections-ի հետ միասին բարձրացրեք worker_rlimit_nofile-ը։

1server {
2    listen 80 default_server;
3    listen 443 ssl default_server;
4    server_name _;
5    ssl_reject_handshake on;   # no certificate leaked to IP scanners
6    return 444;                # close the connection without a response
7}
8 
9# http context, behind Cloudflare (one line per range from cloudflare.com/ips)
10set_real_ip_from 173.245.48.0/20;
11real_ip_header CF-Connecting-IP;