Apa itu Nginx? #
Setiap kali kamu mengakses sebuah website — membuka halaman, mengklik tautan, atau menonton video — ada sebuah program yang bekerja di balik layar untuk menerima permintaanmu dan mengirimkan respons yang tepat. Program itulah yang disebut web server. Nginx (dibaca: “engine-x”) adalah salah satu web server paling populer di dunia, sekaligus salah satu perangkat lunak infrastruktur yang paling sering disalahpahami fungsinya. Artikel ini membangun fondasi yang kamu butuhkan: apa sebenarnya Nginx itu, apa yang bisa dan tidak bisa ia lakukan, dan mengapa ia menjadi pilihan dominan di industri.
Definisi dan Fungsi Dasar #
Nginx adalah perangkat lunak open-source yang pada intinya melakukan satu hal: menerima koneksi jaringan masuk, memproses permintaan HTTP, dan mengirimkan respons. Sesederhana itu secara konseptual — tetapi implementasi “sesederhana itu” ternyata menyimpan kompleksitas yang sangat dalam.
Nginx bisa berfungsi dalam beberapa peran sekaligus, tergantung bagaimana kamu mengkonfigurasinya:
Peran Nginx dalam infrastruktur modern:
┌─────────────────────────────────────────────────────┐
│ NGINX │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌────────────┐ │
│ │ Web Server │ │Reverse Proxy│ │Load Balancer│ │
│ │ │ │ │ │ │ │
│ │ Melayani │ │ Meneruskan │ │ Mendistri- │ │
│ │ file statis │ │ request ke │ │ busikan │ │
│ │ HTML, CSS, │ │ backend app │ │ traffic ke │ │
│ │ JS, gambar │ │ (Node, PHP, │ │ beberapa │ │
│ │ │ │ Python...) │ │ server │ │
│ └─────────────┘ └─────────────┘ └────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │HTTP Cache │ │SSL Terminator│ │
│ │ │ │ │ │
│ │ Menyimpan │ │ Menangani │ │
│ │ respons │ │ enkripsi │ │
│ │ untuk permi-│ │ HTTPS agar │ │
│ │ ntaan yg │ │ backend tdk │ │
│ │ sama │ │ perlu urus │ │
│ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────┘
Yang membuat Nginx istimewa bukan hanya kemampuannya melakukan semua peran di atas — tetapi kemampuannya melakukan semuanya secara bersamaan, dengan konsumsi memori yang sangat rendah, bahkan di bawah beban trafik yang sangat tinggi.
Bagaimana Nginx Bekerja — Gambaran Umum #
Sebelum masuk ke detail teknikal, penting untuk memahami gambaran besar alur kerja Nginx. Ketika seseorang mengakses https://example.com/about, ini yang terjadi:
Browser Pengguna
│
│ 1. DNS lookup → mendapat IP server
│
▼
Nginx (port 443, HTTPS)
│
│ 2. Terima koneksi TCP
│ 3. Dekripsi TLS (jika HTTPS)
│ 4. Parse HTTP request
│ - Method: GET
│ - Path: /about
│ - Headers: Host, User-Agent, dll
│
│ 5. Cocokkan dengan konfigurasi
│ - Server block mana yang cocok?
│ - Location block mana yang cocok?
│
├─ Jika file statis → baca dari disk → kirim respons
│
└─ Jika aplikasi → teruskan ke backend
│
▼
Backend App
(Node.js/PHP/Python)
│
▼
Nginx menerima respons backend
│
▼
Nginx kirim ke browser
Proses ini terjadi dalam hitungan milidetik, dan Nginx mampu menjalankan ribuan proses ini secara bersamaan dengan model konkurensi yang akan dibahas di artikel Arsitektur.
Nginx sebagai Web Server #
Dalam peran paling dasar sebagai web server, Nginx melayani file statis — HTML, CSS, JavaScript, gambar, video, font, dan file lainnya yang tersimpan di disk.
Ketika kamu mengakses sebuah halaman website sederhana, ini yang terjadi di sisi Nginx:
# Konfigurasi paling sederhana: melayani file statis
server {
listen 80;
server_name example.com;
root /var/www/html;
location / {
# Nginx mencari file di /var/www/html sesuai path URL
# GET /about → cari /var/www/html/about (atau about.html, about/index.html)
try_files $uri $uri/ =404;
}
}
Nginx sangat efisien untuk file statis karena ia menggunakan system call kernel yang dioptimasi — sendfile() di Linux — yang mengirim file langsung dari disk ke socket jaringan tanpa menyalin data ke user-space terlebih dahulu. Ini disebut “zero-copy” dan merupakan salah satu alasan performa Nginx untuk file statis sangat tinggi.
Tanpa sendfile() (konvensional):
Disk → Kernel Buffer → User Space (Nginx) → Kernel Socket Buffer → Network
[copy 1] [copy 2] [copy 3]
Dengan sendfile() (Nginx):
Disk → Kernel Buffer → Network
[copy 1, langsung via kernel]
Hasilnya: 2-3x lebih sedikit penyalinan data, lebih sedikit CPU usage.
Nginx sebagai Reverse Proxy #
Aplikasi web modern — Node.js, Django, Laravel, Rails — tidak dirancang untuk langsung menghadapi internet. Mereka berjalan di port internal (misalnya 3000, 8000, 8080) dan tidak menangani HTTPS, rate limiting, atau caching secara efisien. Di sinilah Nginx berperan sebagai reverse proxy.
Istilah “reverse” membedakannya dari “forward proxy” (seperti VPN atau proxy kantor yang kamu gunakan untuk mengakses internet). Dalam reverse proxy, Nginx berdiri di depan server — bukan di depan klien.
Forward Proxy (kamu kenal sebagai VPN/proxy):
Klien → [Forward Proxy] → Internet
Proxy mewakili KLIEN
Reverse Proxy (Nginx):
Internet → [Nginx/Reverse Proxy] → Backend Server
Proxy mewakili SERVER
Sebagai reverse proxy, Nginx menerima semua request dari internet dan meneruskannya ke satu atau beberapa backend server:
server {
listen 80;
server_name api.example.com;
location / {
# Teruskan semua request ke aplikasi Node.js di port 3000
proxy_pass http://localhost:3000;
# Tambahkan header agar backend tahu IP asli klien
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
}
}
Keuntungan arsitektur ini banyak: backend tidak perlu mengurus SSL, satu server Nginx bisa melayani banyak aplikasi di port berbeda, dan Nginx bisa melakukan caching sehingga request yang sama tidak harus selalu mengenai backend.
Nginx sebagai Load Balancer #
Ketika satu server backend tidak cukup untuk menangani trafik, kamu menjalankan beberapa instance. Nginx kemudian bertindak sebagai load balancer — mendistribusikan request secara merata ke semua instance yang tersedia.
upstream backend_app {
server 192.168.1.10:3000; # Server 1
server 192.168.1.11:3000; # Server 2
server 192.168.1.12:3000; # Server 3
}
server {
listen 80;
location / {
proxy_pass http://backend_app;
# Nginx secara otomatis mendistribusikan request
# ke Server 1, 2, 3 secara bergantian (round-robin)
}
}
Nginx mendukung beberapa algoritma load balancing — round-robin, least connection, IP hash — yang akan dibahas lengkap di Section 06.
Nginx sebagai SSL Terminator #
HTTPS membutuhkan enkripsi dan dekripsi yang intensif secara komputasi. Daripada setiap backend server mengurus sertifikat SSL sendiri-sendiri, Nginx menangani semua itu di satu tempat.
Tanpa SSL Termination:
Klien ←HTTPS→ Backend Node.js (harus urus SSL sendiri)
Klien ←HTTPS→ Backend PHP (harus urus SSL sendiri)
Klien ←HTTPS→ Backend Python (harus urus SSL sendiri)
Dengan SSL Termination di Nginx:
Klien ←HTTPS→ Nginx ←HTTP→ Backend Node.js
←HTTP→ Backend PHP
←HTTP→ Backend Python
Nginx urus SSL satu kali, backend komunikasi via HTTP internal (lebih cepat).
Konfigurasinya terlihat seperti ini:
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
# Backend menerima HTTP biasa, Nginx yang urus HTTPS
proxy_pass http://localhost:3000;
}
}
Apa yang Nginx Bukan #
Memahami batas kemampuan Nginx sama pentingnya dengan memahami kemampuannya.
Nginx bukan application server. Nginx tidak bisa menjalankan kode PHP, Python, atau JavaScript secara langsung. Ia hanya bisa meneruskan request ke proses yang menjalankan kode tersebut. Untuk PHP, kamu butuh PHP-FPM. Untuk Node.js, kamu butuh proses Node yang berjalan terpisah.
ANTI-PATTERN (salah kaprah):
"Nginx menjalankan PHP"
BENAR:
Nginx menerima request → meneruskan ke PHP-FPM → PHP-FPM menjalankan kode PHP
→ PHP-FPM mengembalikan respons ke Nginx → Nginx mengirim ke browser
Nginx bukan database. Nginx tidak menyimpan data aplikasi. Caching yang dilakukan Nginx adalah caching HTTP response — bukan data bisnis.
Nginx bukan firewall. Meski Nginx bisa melakukan pembatasan IP dan rate limiting, ini bukan pengganti firewall jaringan yang proper (iptables, UFW, atau solusi cloud seperti Security Groups).
Nginx bukan pengganti CDN untuk distribusi global. Nginx berjalan di satu lokasi. Untuk mendistribusikan konten ke seluruh dunia dengan latensi rendah, kamu tetap butuh CDN (Cloudflare, Fastly, AWS CloudFront).
Nginx dalam Ekosistem Infrastruktur Modern #
Dalam deployment nyata, Nginx jarang berdiri sendiri. Ia adalah salah satu komponen dalam stack yang lebih besar:
Arsitektur Web Modern (tipikal):
Internet
│
▼
[CDN / DDoS Protection]
(Cloudflare, Akamai)
│
▼
[Nginx — Edge Server]
- SSL Termination
- Rate Limiting
- Static File Serving
- Routing
│
├─────────────────────────┐
▼ ▼
[App Server 1] [App Server 2]
(Node.js / Python) (Node.js / Python)
│ │
└──────────┬──────────────┘
▼
[Database Cluster]
(PostgreSQL / MySQL)
│
▼
[Cache Layer]
(Redis / Memcached)
Nginx duduk di posisi kritis: antara dunia luar dan infrastruktur internal. Posisi ini memberinya visibilitas penuh atas semua trafik yang masuk, sekaligus tanggung jawab untuk memastikan setiap request sampai ke tempat yang tepat dengan aman dan efisien.
Nginx Open Source vs Nginx Plus #
Ada dua versi Nginx yang perlu kamu ketahui:
Nginx Open Source (nginx.org) adalah versi gratis yang tersedia di semua package manager Linux. Ini yang digunakan di sebagian besar instalasi dan yang akan dibahas di seluruh buku ini.
Nginx Plus (nginx.com) adalah versi komersial dengan fitur tambahan: active health checks yang lebih canggih, live activity monitoring dashboard, JWT authentication bawaan, dan dukungan resmi dari tim Nginx. Harganya sekitar $2,500/tahun per instance.
Fitur Open Source Nginx Plus
─────────────────────────────────────────────
Web Server ✓ ✓
Reverse Proxy ✓ ✓
Load Balancing ✓ ✓
SSL/TLS ✓ ✓
Passive Health Check ✓ ✓
Active Health Check ✗ ✓
Live Dashboard ✗ ✓
JWT Auth (bawaan) ✗ ✓
Dukungan Resmi ✗ ✓
Harga Gratis ~$2,500/tahun
Untuk mayoritas kasus penggunaan — termasuk deployment production skala menengah — Nginx Open Source lebih dari cukup.
Nginx sebagai HTTP Cache #
Selain peran-peran di atas, Nginx juga berfungsi sebagai HTTP cache yang powerful. Caching di sini berarti menyimpan respons dari backend dan melayani permintaan yang sama dari cache tanpa perlu mengenai backend setiap kali.
Bayangkan sebuah halaman berita yang dikunjungi 10.000 kali dalam satu menit, tetapi isinya hanya berubah setiap jam. Tanpa cache, backend harus merespons 10.000 kali — membangun HTML, query database, dan seterusnya. Dengan cache Nginx, backend hanya perlu merespons sekali, dan 9.999 request berikutnya dilayani langsung oleh Nginx dari cache.
# Konfigurasi proxy cache dasar
proxy_cache_path /var/cache/nginx
levels=1:2
keys_zone=app_cache:10m
max_size=1g
inactive=60m;
server {
listen 80;
server_name news.example.com;
location / {
proxy_cache app_cache;
proxy_cache_valid 200 1h; # Cache respons 200 OK selama 1 jam
proxy_cache_valid 404 1m; # Cache 404 selama 1 menit
proxy_pass http://backend_app;
# Tambahkan header untuk debug: apakah hit atau miss
add_header X-Cache-Status $upstream_cache_status;
}
}
Skenario ini bisa mengurangi beban backend secara dramatis — bahkan 99% jika konten stabil dan trafik tinggi. Fitur cache ini yang membuat Nginx sering diposisikan sebagai lapisan pertahanan pertama sebelum backend.
Alur Request dengan Cache:
Request pertama:
Browser → Nginx → [Cache MISS] → Backend → Nginx menyimpan respons → Browser
Request berikutnya (selama cache valid):
Browser → Nginx → [Cache HIT] → Browser
(backend tidak pernah disentuh)
Penghematan: backend hanya diakses saat cache expired atau miss.
Nginx sebagai Mail Proxy #
Ini adalah fitur yang kurang dikenal: Nginx juga mendukung protokol email — SMTP, IMAP, dan POP3 — sebagai proxy. Meski tidak sepopuler fitur HTTP-nya, ini berguna untuk infrastruktur email skala besar yang perlu melakukan routing email ke berbagai backend mail server.
mail {
server_name mail.example.com;
auth_http http://localhost:8080/auth; # Autentikasi via HTTP
server {
listen 143; # IMAP
protocol imap;
starttls on;
}
server {
listen 25; # SMTP
protocol smtp;
starttls on;
}
}
Fitur mail proxy ini jarang digunakan di deployment web biasa, tapi menunjukkan betapa fleksibelnya Nginx sebagai proxy layer.
Anatomi Instalasi Nginx #
Ketika kamu menginstal Nginx di sistem Linux, beberapa direktori dan file penting dibuat:
Struktur File Nginx (Ubuntu/Debian):
/etc/nginx/
├── nginx.conf # File konfigurasi utama
├── conf.d/ # Konfigurasi tambahan (*.conf di-include)
│ └── default.conf
├── sites-available/ # Virtual host yang tersedia
│ └── default
├── sites-enabled/ # Symlink ke sites-available yang aktif
│ └── default → ../sites-available/default
├── mime.types # Mapping ekstensi file ke MIME type
├── fastcgi_params # Parameter untuk FastCGI (PHP)
├── proxy_params # Parameter default untuk proxy
├── snippets/ # Konfigurasi yang bisa di-include
│ ├── fastcgi-php.conf
│ └── snakeoil.conf
└── modules-enabled/ # Symlink ke modul yang diaktifkan
/var/log/nginx/
├── access.log # Log semua request
└── error.log # Log error dan warning
/var/www/html/ # Default document root
└── index.html
/usr/lib/nginx/ # Binary dan modul
/var/cache/nginx/ # Cache (jika dikonfigurasi)
Memahami struktur ini penting karena hampir semua operasi Nginx — menambah virtual host, mengaktifkan SSL, mengonfigurasi cache — berputar di sekitar file dan direktori ini.
Proses Nginx: Melihat dari Dalam #
Setelah Nginx berjalan, kamu bisa melihat prosesnya:
# Lihat proses Nginx yang berjalan
ps aux | grep nginx
# Output (server 4 core):
# root 12345 0.0 0.0 nginx: master process /usr/sbin/nginx
# www-data 12346 0.1 0.5 nginx: worker process
# www-data 12347 0.1 0.5 nginx: worker process
# www-data 12348 0.1 0.5 nginx: worker process
# www-data 12349 0.1 0.5 nginx: worker process
# Master process berjalan sebagai root (untuk bind port 80/443)
# Worker processes berjalan sebagai www-data (user non-privileged)
Perhatikan bahwa hanya ada satu master process dan beberapa worker process (biasanya sesuai jumlah CPU core). Ini kontras dengan Apache yang bisa memiliki puluhan atau ratusan proses.
# Reload konfigurasi tanpa downtime
sudo nginx -s reload
# Test konfigurasi sebelum reload (sangat penting!)
sudo nginx -t
# Output jika valid:
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful
# Stop gracefully (tunggu request yang sedang berjalan selesai)
sudo nginx -s quit
# Stop segera (force)
sudo nginx -s stop
Nginx vs Alternatif Modern #
Selain Apache, ada beberapa web server dan reverse proxy modern yang sering dibandingkan dengan Nginx:
Perbandingan Singkat:
┌────────────┬─────────────────────────────────────────────┐
│ Caddy │ Auto-HTTPS, konfigurasi lebih sederhana, │
│ │ ditulis di Go. Cocok untuk proyek kecil │
│ │ yang ingin zero-config SSL. │
├────────────┼─────────────────────────────────────────────┤
│ Traefik │ Cloud-native, auto-discovery container, │
│ │ sangat cocok untuk Kubernetes dan Docker │
│ │ Swarm. Konfigurasi dinamis. │
├────────────┼─────────────────────────────────────────────┤
│ HAProxy │ Fokus pada load balancing TCP/HTTP, │
│ │ performa sangat tinggi untuk use case │
│ │ load balancer murni. │
├────────────┼─────────────────────────────────────────────┤
│ Envoy │ Didesain untuk service mesh, sangat │
│ │ configurable, digunakan di Istio. │
│ │ Lebih kompleks dari Nginx. │
├────────────┼─────────────────────────────────────────────┤
│ Nginx │ Battle-tested, ekosistem besar, performa │
│ │ sangat baik, cocok untuk hampir semua │
│ │ use case web server dan reverse proxy. │
└────────────┴─────────────────────────────────────────────┘
Nginx tetap menjadi pilihan default untuk sebagian besar deployment web karena kombinasi uniknya: matang, dokumentasi lengkap, performa tinggi, dan sangat fleksibel.
Kenapa Nginx Populer? #
Popularitas Nginx bukan kebetulan. Ada beberapa alasan konkret mengapa ia mendominasi pasar web server:
Performa di bawah beban tinggi. Nginx dirancang dari awal untuk menangani puluhan ribu koneksi bersamaan dengan konsumsi memori yang dapat diprediksi. Ini berbeda dengan Apache yang konsumsi memorinya tumbuh linear dengan jumlah koneksi.
Konfigurasi yang ekspresif. File konfigurasi Nginx menggunakan sintaks direktif dan blok yang bisa menggambarkan logika routing yang kompleks dengan cara yang relatif mudah dibaca.
Ekosistem yang matang. Setelah lebih dari 20 tahun, hampir semua masalah yang bisa kamu temui sudah pernah dialami orang lain. Dokumentasi, tutorial, dan komunitas yang besar membuatnya mudah untuk menemukan solusi.
Penggunaan memori yang rendah dan stabil. Sebuah proses worker Nginx umumnya menggunakan sekitar 2-3 MB memori. Server dengan 1 GB RAM bisa menangani ribuan koneksi bersamaan tanpa khawatir kehabisan memori.
Dukungan luas dari platform cloud. Semua platform cloud besar — AWS, GCP, Azure — memiliki image dan dokumentasi resmi untuk Nginx. Kubernetes pun menggunakan Nginx sebagai Ingress Controller default yang paling populer.
Nginx dalam Praktik: Contoh Konfigurasi Nyata #
Untuk memberikan gambaran yang lebih konkret, berikut adalah beberapa skenario konfigurasi yang paling sering ditemui:
Skenario 1: Website Statis Sederhana #
Cocok untuk landing page, dokumentasi, atau portfolio:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/example.com;
index index.html index.htm;
# Aktifkan gzip untuk memperkecil ukuran transfer
gzip on;
gzip_types text/html text/css application/javascript image/svg+xml;
location / {
try_files $uri $uri/ =404;
}
# Cache file statis di browser klien
location ~* \.(css|js|png|jpg|gif|ico|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# Log
access_log /var/log/nginx/example.com-access.log;
error_log /var/log/nginx/example.com-error.log;
}
Skenario 2: API dengan Node.js Backend #
Paling umum di startup modern:
upstream nodejs_backend {
server 127.0.0.1:3000;
keepalive 32;
}
server {
listen 443 ssl;
server_name api.example.com;
ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
# Rate limiting: 100 request per detik per IP
limit_req zone=api_limit burst=200 nodelay;
location / {
proxy_pass http://nodejs_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
}
}
Skenario 3: Multi-Application dalam Satu Server #
Satu server, banyak aplikasi berbeda diakses via subdomain:
# Aplikasi 1: Website utama (PHP-FPM)
server {
listen 80;
server_name example.com www.example.com;
root /var/www/main;
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
include fastcgi_params;
}
}
# Aplikasi 2: API (Node.js port 3000)
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
}
}
# Aplikasi 3: Admin panel (Python/Django port 8000)
server {
listen 80;
server_name admin.example.com;
location / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $host;
# Batasi akses hanya dari IP internal
allow 10.0.0.0/8;
deny all;
}
}
Dengan Nginx, semua ini bisa berjalan di satu server fisik dengan konfigurasi yang bersih dan terstruktur.
Monitoring Nginx dengan Tools Populer #
Dalam production, kamu perlu memonitor Nginx secara aktif. Beberapa tools yang umum digunakan:
Prometheus + Grafana #
Stack monitoring paling populer untuk Nginx modern:
Nginx → nginx-prometheus-exporter → Prometheus → Grafana
(mengekspos metrics) (scraping) (visualisasi)
Metrics yang dipantau:
- Request rate (req/detik)
- Error rate (5xx, 4xx)
- Active connections
- Request duration (p50, p95, p99)
- Upstream response time
- Cache hit rate
GoAccess: Real-time Log Analysis #
# Analisis log Nginx secara real-time di terminal
goaccess /var/log/nginx/access.log --log-format=COMBINED
# Atau untuk web interface real-time:
tail -f /var/log/nginx/access.log | goaccess -a -o /var/www/html/report.html --real-time-html
Datadog / New Relic #
Platform APM komersial ini memiliki integrasi Nginx yang mengumpulkan metrics secara otomatis dan bisa dikombinasikan dengan application metrics dari backend.
Keamanan Default Nginx #
Nginx relatif aman secara default, tapi ada beberapa konfigurasi tambahan yang disarankan untuk production:
server {
# Sembunyikan versi Nginx dari header respons
# (informasi ini berguna untuk penyerang)
server_tokens off;
# Tambahkan security headers
add_header X-Content-Type-Options "nosniff";
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header Referrer-Policy "strict-origin-when-cross-origin";
# Batasi ukuran request body (default: 1m)
client_max_body_size 10m;
# Batasi timeout agar koneksi lambat/idle tidak menumpuk
client_header_timeout 10;
client_body_timeout 10;
keepalive_timeout 30;
send_timeout 10;
}
Konfigurasi keamanan yang lebih detail akan dibahas di Section 08 — Keamanan.
Ringkasan #
- Nginx adalah web server sekaligus reverse proxy — ia bisa melayani file statis langsung dari disk dan meneruskan request ke backend aplikasi.
- Peran utama Nginx: web server, reverse proxy, load balancer, SSL terminator, dan HTTP cache.
- Nginx bukan application server — ia tidak menjalankan PHP, Python, atau JavaScript. Ia hanya meneruskan request ke proses yang melakukannya.
- Zero-copy dengan sendfile() membuat Nginx sangat efisien untuk melayani file statis.
- SSL Termination memungkinkan backend berjalan via HTTP internal, sementara Nginx menangani enkripsi HTTPS.
- Nginx Open Source sudah cukup untuk mayoritas kebutuhan production — Nginx Plus hanya diperlukan untuk fitur enterprise tertentu.
- Posisi Nginx dalam stack: antara internet dan backend, memberikannya visibilitas dan kontrol penuh atas semua trafik masuk.