# Nginx Reverse Proxy: Zero dan Production-ready konfiguratsiyagacha mukammal qo'llanma Zamonaviy web arxitekturada reverse proxy - bu mikroservislar, containerlar va distributed tizimlar orasidagi muhim ko'prik vazifasini bajaruvchi texnologiya. Nginx esa bu sohadagi mutlaq lider sifatida tanilgan. Ushbu mukammal qo'llanmada biz Nginx reverse proxy texnologiyasini zero dan boshlab production-ready darajagacha chuqur o'rganamiz. > [!IMPORTANT] > Bu maqola faqat "sozlash" haqida emas - bu Nginx reverse proxy ekotizimining MUKAMMAL enciklopediyasi. Har bir konfiguratsiya, har bir parametr, har bir optimization texnikasi bilan tanishasiz. ## Reverse Proxy nima va nima uchun kerak? ### Proxy texnologiyasining tarixi va evolyutsiyasi Internet'ning dastlabki kunlarida web sahifalar oddiy statik HTML fayllar edi. 1990-yilning boshlarida Tim Berners-Lee tomonidan yaratilgan World Wide Web tizimi elementar request-response modeliga asoslangan edi. Bitta server, bitta dastur, to'g'ridan-to'g'ri client-server aloqasi - bu o'sha davrning standard arxitekturasi edi. Biroq internetning ekspansiyasi va foydalanuvchilar sonining eksponensial o'sishi bilan birga murakkablik ham ortdi. 1990-yillarning o'rtalarida HTTP/1.0 protokoli paydo bo'ldi, ammo u har bir request uchun alohida TCP connection ochishni talab qilardi. Bu inefficient edi va server resurslari tez tugab qolar edi. 1994-yilda CERN'da birinchi proxy server yaratildi. Bu server client va origin server orasidagi vositachi vazifasini bajarib, caching va security funksiyalarini ta'minlardi. Proxy texnologiyasi ikki yo'nalishda rivojlandi: **Forward Proxy evolyutsiyasi:** - **1994-1998**: CERN httpd va Squid proxy'lari paydo bo'ldi - **1998-2002**: Content filtering va corporate firewall'lar - **2002-2008**: Transparent proxying va WAN optimization - **2008-hozir**: CDN va Edge computing **Reverse Proxy evolyutsiyasi:** - **1995-2000**: Load balancing uchun hardware solution'lar - **2000-2004**: Software-based reverse proxy (Apache mod_proxy) - **2004**: Nginx paydo bo'lishi - bu texnologiyada inqilob - **2008-hozir**: Cloud load balancer'lar va service mesh ### Forward vs Reverse Proxy: Fundamental farqlar Forward proxy va reverse proxy o'rtasidagi farqni tushunish uchun network topology va traffic flow'ni chuqur tahlil qilish kerak: ```mermaid graph TB subgraph "Forward Proxy Architecture" subgraph "Corporate Network" C1[Employee 1] --> FP[Forward Proxy
Squid/Corporate Proxy] C2[Employee 2] --> FP C3[Employee 3] --> FP end FP -->|"Filtered/Cached Requests"| I1[Internet] I1 --> WS1[Web Server 1] I1 --> WS2[Web Server 2] I1 --> WS3[Web Server 3] end subgraph "Reverse Proxy Architecture" I2[Internet] --> RP[Reverse Proxy
Nginx/HAProxy] subgraph "Backend Infrastructure" RP --> AS1[App Server 1
:8001] RP --> AS2[App Server 2
:8002] RP --> AS3[App Server 3
:8003] AS1 --> DB[(Database)] AS2 --> DB AS3 --> DB end end ``` **Forward Proxy xususiyatlari va foydalanish holatlari:** 1. **Client-side Proxy**: Client'lar tomonidan explicit ravishda configure qilinadi 2. **Outbound Traffic Management**: Internal network'dan internet'ga chiquvchi traffic'ni nazorat qiladi 3. **Content Filtering**: - Malicious website'larni bloklash - Social media va boshqa non-productive site'larga kirish cheklash - Keyword-based filtering 4. **Bandwidth Management**: - Per-user bandwidth limiting - Time-based access control - Protocol-based QoS 5. **Privacy Enhancement**: - Client IP'sini yashirish - User-Agent masking - Encrypted tunnel'lar (SOCKS5) **Reverse Proxy xususiyatlari va foydalanish holatlari:** 1. **Server-side Proxy**: Client'lar uchun transparent 2. **Inbound Traffic Management**: Internet'dan internal network'ga keladigan traffic'ni boshqaradi 3. **Load Distribution**: - Multiple backend server'lar o'rtasida traffic taqsimoti - Health monitoring va automatic failover - Geographic load balancing 4. **SSL/TLS Termination**: - Centralized certificate management - Hardware-accelerated crypto operations - Backend server'larni SSL overhead'dan ozod etish 5. **Caching va Performance**: - Static content caching - Database query result caching - Gzip compression 6. **Security Enhancement**: - DDoS protection - Rate limiting - Web Application Firewall (WAF) integration ### Network Layer'da proxy ishlash printsiplari Proxy server'lar OSI model'ning turli layer'larida ishlashi mumkin: ```mermaid graph LR subgraph "OSI Layer Analysis" L7[Layer 7
Application
HTTP/HTTPS
Content-based routing] L4[Layer 4
Transport
TCP/UDP
Port-based routing] L3[Layer 3
Network
IP
IP-based routing] end subgraph "Proxy Types" L7 --> HTTP_PROXY[HTTP Proxy
Nginx, Apache] L4 --> TCP_PROXY[TCP Proxy
HAProxy, Envoy] L3 --> IP_PROXY[IP Proxy
Netfilter, iptables] end ``` **Layer 7 (Application) Proxy:** - HTTP header'larni o'qiy oladi va modify qilishi mumkin - Content-based routing (URL path, header value) - SSL termination va re-encryption - Request/Response modification - Advanced logging va analytics **Layer 4 (Transport) Proxy:** - TCP/UDP level'da ishlaydi - IP va port asosida routing - Connection multiplexing - Load balancing without HTTP awareness - Lower latency, higher throughput **Layer 3 (Network) Proxy:** - IP packet level'da ishlaydi - Transparent proxy functionality - NAT-based routing - Kernel-level processing ### Zamonaviy web arxitekturada reverse proxy'ning o'rni Bugungi kunda web dasturlari monolitik arxitekturadan mikroservislar arxitekturasiga o'tdi. Bu o'zgarish bir qator yangi muammolarni keltirib chiqardi: ```mermaid graph TB subgraph "Traditional Monolithic Architecture" U1[Users] --> LB1[Simple Load Balancer] LB1 --> M1[Monolith App 1] LB1 --> M2[Monolith App 2] M1 --> DB1[(Single Database)] M2 --> DB1 end subgraph "Modern Microservices Architecture" U2[Users] --> IG[API Gateway
Nginx/Kong/Istio] IG --> US[User Service
:3001] IG --> PS[Product Service
:3002] IG --> OS[Order Service
:3003] IG --> PS2[Payment Service
:3004] IG --> NS[Notification Service
:3005] IG --> AS[Analytics Service
:3006] subgraph "Data Layer" US --> UDB[(User DB
PostgreSQL)] PS --> PDB[(Product DB
MongoDB)] OS --> ODB[(Order DB
MySQL)] PS2 --> PDB2[(Payment DB
PostgreSQL)] NS --> Queue[Message Queue
Redis/RabbitMQ] AS --> Analytics[(Analytics DB
ClickHouse)] end end ``` **Mikroservislar arxitekturasining muammolari:** 1. **Service Discovery**: Qaysi service qayerda ishlayotganini aniqlash 2. **Inter-service Communication**: Service'lar orasidagi secure aloqa 3. **Circuit Breaking**: Bitta service'ning ishlamay qolishi boshqalarini ta'sir qilmasligi 4. **Distributed Tracing**: Request'ning barcha service'lar orqali yo'lini kuzatish 5. **Centralized Logging**: Barcha service'lardan log'larni yig'ish 6. **Rate Limiting**: Per-service yoki per-user limit'lar 7. **Authentication/Authorization**: Centralized security 8. **Protocol Translation**: HTTP, gRPC, GraphQL orasida translate **Reverse Proxy'ning mikroservislar ekotizimidagi roli:** ```mermaid sequenceDiagram participant C as Client participant RP as Nginx Reverse Proxy participant SD as Service Discovery participant US as User Service participant PS as Product Service participant OS as Order Service C->>RP: GET /api/user/profile RP->>SD: Resolve user service SD-->>RP: user-service:3001 RP->>US: GET /profile US-->>RP: User data RP-->>C: Response with user data C->>RP: POST /api/order RP->>SD: Resolve order service SD-->>RP: order-service:3003 RP->>OS: POST /create OS->>PS: GET /product/validate PS-->>OS: Product validation OS-->>RP: Order created RP-->>C: Order confirmation ``` ### Nginx'ning reverse proxy sohaidagi ustunligi Nginx 2004-yilda Igor Sysoev tomonidan yaratilgan va dastlab C10K muammosini hal qilish uchun ishlab chiqilgan. C10K muammosi - bu bitta serverni 10,000 ta concurrent connection'ni qayta ishlay olmaslik muammosi edi. **Nginx'ning tarixiy evolyutsiyasi:** - **2002**: Igor Sysoev'ning Rambler.ru'da ishlash davrida loyiha boshlanadi - **2004**: Birinchi public release (0.1.0) - **2006**: HTTP proxy va FastCGI support qo'shildi - **2009**: Windows support va embedded variables - **2011**: IPv6 support va WebSocket proxying - **2013**: SPDY support (HTTP/2'ning predecessor'i) - **2015**: HTTP/2 support va dynamic modules - **2018**: gRPC proxying va advanced load balancing - **2020**: HTTP/3 va QUIC protocol support **Nginx'ning texnik arxitektura afzalliklari:** #### 1. Event-driven Architecture Apache'ning process/thread per connection modeli o'rniga, Nginx event-driven non-blocking I/O model ishlatadi: ```mermaid graph TB subgraph "Apache Architecture (Multi-Process/Thread)" C1[Connection 1] --> T1[Thread 1
~8MB Memory] C2[Connection 2] --> T2[Thread 2
~8MB Memory] C3[Connection 3] --> T3[Thread 3
~8MB Memory] CN[Connection N] --> TN[Thread N
~8MB Memory] end subgraph "Nginx Architecture (Event-Driven)" subgraph "Single Worker Process" EQ[Event Queue] EQ --> E1[Event 1: Read Ready] EQ --> E2[Event 2: Write Ready] EQ --> E3[Event 3: Timer Expired] EQ --> EN[Event N: Connection Closed] end C1_N[Connection 1] --> EQ C2_N[Connection 2] --> EQ C3_N[Connection 3] --> EQ CN_N[Connection N] --> EQ end ``` **Event loop'ning ishlash printsisi:** 1. **Epoll/Kqueue**: OS-level event notification system 2. **Non-blocking I/O**: Operation'lar thread'ni block qilmaydi 3. **State Machine**: Har bir connection'ning holati saqlanadi 4. **Cooperative Multitasking**: Worker process'lar event'larni navbat bilan qayta ishlaydi #### 2. Memory Efficiency ```bash # Apache memory consumption (typical) # 100 connections × 8MB per thread = 800MB # Plus process overhead = ~1GB total # Nginx memory consumption (typical) # 100,000 connections = ~10-20MB # Plus minimal process overhead = ~50MB total ``` #### 3. CPU Efficiency Nginx'ning CPU efficiency bir necha omilga asoslangan: ```mermaid graph LR subgraph "Context Switching Comparison" subgraph "Apache" A_CPU[CPU Core] --> A_T1[Thread 1] A_CPU --> A_T2[Thread 2] A_CPU --> A_T3[Thread 3] A_T1 --> A_CS[Context Switch
Overhead ~1000 cycles] A_T2 --> A_CS A_T3 --> A_CS end subgraph "Nginx" N_CPU[CPU Core] --> N_WP[Worker Process] N_WP --> N_EL[Event Loop
No Context Switch] end end ``` #### 4. Scalability Metrics Real-world performance comparison: | Metric | Apache (mod_php) | Apache (mod_proxy) | Nginx | |--------|------------------|-------------------|--------| | Memory per connection | 8MB | 2MB | 20KB | | Max concurrent connections | 1,000 | 5,000 | 100,000+ | | CPU usage (idle connections) | High | Medium | Very Low | | Configuration reload | Restart required | Restart required | Hot reload | | Static file serving | 1,000 req/sec | 2,000 req/sec | 10,000+ req/sec | #### 5. Configuration Simplicity ```nginx # Nginx - Simple and readable server { listen 80; server_name example.com; location / { proxy_pass http://backend; } } ``` ```apache # Apache - More verbose ServerName example.com ProxyPreserveHost On ProxyPass / http://backend/ ProxyPassReverse / http://backend/ ProxyPassReverse / ``` ## Nginx arxitekturasi va ishlash printsipi ### Master-Worker Process modeli Nginx'ning process arxitekturasi Unix'ning time-tested pattern'lariga asoslangan: ```mermaid graph TD subgraph "Nginx Process Architecture" M[Master Process
PID: 1234
User: root
Memory: 1MB] subgraph "Worker Processes" W1[Worker 1
PID: 1235
User: nginx
Memory: 10MB] W2[Worker 2
PID: 1236
User: nginx
Memory: 10MB] W3[Worker 3
PID: 1237
User: nginx
Memory: 10MB] W4[Worker 4
PID: 1238
User: nginx
Memory: 10MB] end subgraph "Cache Processes" CM[Cache Manager
PID: 1239
User: nginx
Memory: 2MB] CL[Cache Loader
PID: 1240
User: nginx
Memory: 2MB] end M --> W1 M --> W2 M --> W3 M --> W4 M --> CM M --> CL end subgraph "External Interaction" CONF[nginx.conf] --> M SIGNALS[System Signals
SIGHUP, SIGTERM] --> M SOCK[Listen Socket
:80, :443] --> W1 SOCK --> W2 SOCK --> W3 SOCK --> W4 end ``` **Master Process vazifalar va funksionallik:** 1. **Configuration Management**: ```bash # Configuration syntax check nginx -t # Configuration reload (hot reload) nginx -s reload # or kill -HUP $(cat /var/run/nginx.pid) ``` 2. **Process Lifecycle Management**: - Worker process'larni spawn qilish - Crashed worker'larni restart qilish - Graceful shutdown coordination - Signal handling va distribution 3. **Privilege Management**: - Root privilege'lar bilan start - Privileged port'larga bind (80, 443) - Worker process'larni non-privileged user'da run qilish 4. **Resource Allocation**: - Shared memory segment'lar yaratish - SSL session cache allocation - Zone-based memory management **Worker Process vazifalar va specialization:** ```mermaid sequenceDiagram participant C as Client participant W1 as Worker Process 1 participant B as Backend Server participant CM as Cache Manager C->>W1: HTTP Request alt Static Content W1->>W1: File system read W1->>C: Static file response else Dynamic Content W1->>B: Proxy request B->>W1: Dynamic response W1->>CM: Store in cache (if configured) W1->>C: Dynamic response end ``` **Worker Process'larning specialized functionality:** 1. **Connection Handling**: - Accept new connections - Keep-alive connection management - Connection pooling to backends 2. **Request Processing**: - HTTP parsing va validation - Location matching - Variable interpolation 3. **Response Generation**: - Static file serving - Proxy response forwarding - Dynamic content generation 4. **I/O Operations**: - Non-blocking file reads - Network socket operations - Asynchronous DNS resolution ### Event-driven I/O modeli deep dive Nginx'ning performance secret'i event-driven arquitekturada yotadi. Bu model'ni tushunish uchun OS-level event notification system'larni o'rganish kerak: #### Operating System Event Mechanisms ```mermaid graph TB subgraph "Linux - epoll" EPOLL[epoll_create
epoll_ctl
epoll_wait] EPOLL --> E_EVENTS[EPOLLIN: Read ready
EPOLLOUT: Write ready
EPOLLERR: Error
EPOLLHUP: Hangup] end subgraph "BSD/macOS - kqueue" KQUEUE[kqueue
kevent] KQUEUE --> K_EVENTS[EVFILT_READ
EVFILT_WRITE
EVFILT_TIMER
EVFILT_SIGNAL] end subgraph "Windows - IOCP" IOCP[CreateIoCompletionPort
GetQueuedCompletionStatus] IOCP --> I_EVENTS[Overlapped I/O
Completion callbacks] end ``` #### Event Loop Implementation Nginx'ning event loop'i quyidagi bosqichlardan iborat: ```c // Simplified event loop pseudocode while (1) { // 1. Wait for events with timeout n = epoll_wait(epfd, events, MAX_EVENTS, timeout); // 2. Process timer events process_timer_events(); // 3. Process I/O events for (i = 0; i < n; i++) { if (events[i].events & EPOLLIN) { // Read event ready process_read_event(events[i].data.ptr); } if (events[i].events & EPOLLOUT) { // Write event ready process_write_event(events[i].data.ptr); } } // 4. Process posted events process_posted_events(); } ``` #### State Machine for HTTP Connections Har bir HTTP connection Nginx'da state machine orqali boshqariladi: ```mermaid stateDiagram-v2 [*] --> WAITING_REQUEST: New connection accepted WAITING_REQUEST --> READING_REQUEST_HEADERS: First byte received READING_REQUEST_HEADERS --> PROCESSING_REQUEST: Headers complete READING_REQUEST_HEADERS --> READING_REQUEST_BODY: Content-Length > 0 READING_REQUEST_BODY --> PROCESSING_REQUEST: Body complete PROCESSING_REQUEST --> UPSTREAM_CONNECT: Proxy request PROCESSING_REQUEST --> SENDING_RESPONSE: Static file UPSTREAM_CONNECT --> UPSTREAM_SEND: Connection established UPSTREAM_SEND --> UPSTREAM_RESPONSE: Request sent UPSTREAM_RESPONSE --> SENDING_RESPONSE: Response received SENDING_RESPONSE --> WAITING_REQUEST: Keep-alive SENDING_RESPONSE --> [*]: Connection close ``` #### Connection Memory Pooling Nginx har bir connection uchun memory pool yaratadi: ```mermaid graph LR subgraph "Connection Memory Pool" CP[Connection Pool
~1KB default] subgraph "Pool Blocks" B1[Block 1: 1KB
Request headers] B2[Block 2: 1KB
Response headers] B3[Block 3: 4KB
Request body] BN[Block N: Size varies
Various buffers] end CP --> B1 CP --> B2 CP --> B3 CP --> BN end ``` **Memory pool advantages:** - Reduced malloc/free calls - Memory fragmentation prevention - Automatic cleanup on connection close - Faster allocation through pre-allocated chunks ### Nginx modullar tizimi va extensibility Nginx'ning modulli arxitekturasi uning moslashuvchanligining asosi: #### Module Architecture ```mermaid graph TB subgraph "Nginx Core" CORE[Core Module
ngx_core_module] EVENT[Event Module
ngx_event_module] HTTP[HTTP Core Module
ngx_http_core_module] end subgraph "HTTP Modules" PROXY[Proxy Module
ngx_http_proxy_module] UPSTREAM[Upstream Module
ngx_http_upstream_module] SSL[SSL Module
ngx_http_ssl_module] GZIP[Gzip Module
ngx_http_gzip_module] HEADERS[Headers Module
ngx_http_headers_module] ACCESS[Access Module
ngx_http_access_module] AUTH[Auth Module
ngx_http_auth_basic_module] LOG[Log Module
ngx_http_log_module] REWRITE[Rewrite Module
ngx_http_rewrite_module] end subgraph "3rd Party Modules" LUA[Lua Module
lua-resty-*] MODSEC[ModSecurity
WAF functionality] ECHO[Echo Module
Development/testing] UPLOAD[Upload Module
File upload handling] end CORE --> HTTP HTTP --> PROXY HTTP --> UPSTREAM HTTP --> SSL HTTP --> GZIP HTTP --> HEADERS HTTP --> ACCESS HTTP --> AUTH HTTP --> LOG HTTP --> REWRITE ``` #### Module Lifecycle HTTP module'larning request processing cycle'dagi o'rni: ```mermaid sequenceDiagram participant R as Request participant ACCESS as Access Module participant AUTH as Auth Module participant REWRITE as Rewrite Module participant PROXY as Proxy Module participant HEADERS as Headers Module participant LOG as Log Module R->>ACCESS: NGX_HTTP_ACCESS_PHASE ACCESS->>AUTH: Allow/Deny check AUTH->>REWRITE: Authentication check REWRITE->>REWRITE: URL rewriting REWRITE->>PROXY: NGX_HTTP_CONTENT_PHASE PROXY->>HEADERS: Proxy to backend HEADERS->>LOG: Add response headers LOG->>R: NGX_HTTP_LOG_PHASE ``` #### Module Development Framework Nginx module'lari C da yoziladi va specific API'ni follow qiladi: ```c // Simplified module structure static ngx_http_module_t ngx_http_custom_module_ctx = { NULL, /* preconfiguration */ ngx_http_custom_init, /* postconfiguration */ NULL, /* create main configuration */ NULL, /* init main configuration */ NULL, /* create server configuration */ NULL, /* merge server configuration */ ngx_http_custom_create_conf, /* create location configuration */ ngx_http_custom_merge_conf /* merge location configuration */ }; ngx_module_t ngx_http_custom_module = { NGX_MODULE_V1, &ngx_http_custom_module_ctx, /* module context */ ngx_http_custom_commands, /* module directives */ NGX_HTTP_MODULE, /* module type */ NULL, /* init master */ NULL, /* init module */ NULL, /* init process */ NULL, /* init thread */ NULL, /* exit thread */ NULL, /* exit process */ NULL, /* exit master */ NGX_MODULE_V1_PADDING }; ``` #### Dynamic Modules (Nginx 1.9.11+) Static compile qilish o'rniga, runtime'da module load qilish imkoniyati: ```bash # Dynamic module compile ./configure --add-dynamic-module=../nginx-module-vts make modules # nginx.conf'da module load qilish load_module modules/ngx_http_vhost_traffic_status_module.so; http { vhost_traffic_status_zone; server { location /status { vhost_traffic_status_display; } } } ``` #### Built-in Module Reference **Core HTTP Modules:** | Module | Functionality | Key Directives | |--------|---------------|----------------| | `ngx_http_core_module` | HTTP server basic functionality | `server`, `location`, `listen` | | `ngx_http_proxy_module` | HTTP proxy functionality | `proxy_pass`, `proxy_set_header` | | `ngx_http_upstream_module` | Load balancing | `upstream`, `server`, `least_conn` | | `ngx_http_ssl_module` | SSL/TLS support | `ssl_certificate`, `ssl_ciphers` | | `ngx_http_gzip_module` | Response compression | `gzip`, `gzip_types`, `gzip_level` | | `ngx_http_headers_module` | Response headers manipulation | `add_header`, `expires` | | `ngx_http_access_module` | IP-based access control | `allow`, `deny` | | `ngx_http_auth_basic_module` | HTTP Basic authentication | `auth_basic`, `auth_basic_user_file` | | `ngx_http_log_module` | Access logging | `access_log`, `log_format` | | `ngx_http_rewrite_module` | URL rewriting | `rewrite`, `return`, `if` | ### Configuration Processing Architecture Nginx configuration file processing murakkab multi-stage process: ```mermaid graph TB subgraph "Configuration Processing Pipeline" CF[Configuration File
nginx.conf] --> LEX[Lexical Analysis
Tokenization] LEX --> PARSE[Parse Tree
Directive validation] PARSE --> CTX[Context Tree
Hierarchy building] CTX --> MERGE[Configuration Merge
Inheritance resolution] MERGE --> COMPILE[Compilation
Runtime structures] end subgraph "Runtime Structures" COMPILE --> MAIN[Main Configuration] COMPILE --> HTTP[HTTP Configuration] COMPILE --> SERVER[Server Configurations] COMPILE --> LOCATION[Location Configurations] end ``` #### Configuration Inheritance Model ```nginx # Global HTTP context http { sendfile on; # Inherited by all servers tcp_nopush on; # Inherited by all servers server { listen 80; sendfile off; # Overrides global setting location / { tcp_nopush off; # Overrides server setting proxy_pass http://backend; } location /static/ { # Inherits sendfile off from server # Inherits tcp_nopush on from http (location doesn't override) root /var/www; } } } ``` #### Variable System Nginx'ning variable system'i request processing'ning muhim qismi: ```nginx # Built-in variables $remote_addr # Client IP $remote_port # Client port $server_name # Server name from config $request_uri # Full original request URI $uri # Current URI (can be modified) $args # Query string arguments $request_method # HTTP method $scheme # http or https $request_time # Request processing time $upstream_response_time # Backend response time # Custom variables set $custom_var "value"; set $dynamic_var "${remote_addr}_${request_time}"; # Variables in configuration proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Request-ID $request_id; ``` ## Nginx o'rnatish va advanced sozlash ### Sistema talablar va planning Production-ready Nginx deployment uchun to'g'ri planning muhim: #### Hardware Requirements ```mermaid graph TB subgraph "Small Deployment (1-10K users)" S_CPU[CPU: ```