Apa itu Nginx? #

Every time kita mengakses sebuah website — membuka halaman, mengklik tautan, atau menonton video — ada sebuah program yang bekerja di balik layar untuk menerima permintaan kita 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 kita 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 kita mengkonfigurasinya:

flowchart TD
    subgraph NGX ["Platform Pemrosesan Trafik NGINX"]
        direction TB
        WS["Web Server<br/>(Melayani file statis HTML, CSS, JS, Gambar)"]
        RP["Reverse Proxy<br/>(Meneruskan request ke server backend internal)"]
        LB["Load Balancer<br/>(Mendistribusikan trafik ke klaster server)"]
        HC["HTTP Cache<br/>(Menyimpan respons agar tidak membebani backend)"]
        ST["SSL Terminator<br/>(Menangani jabat tangan & enkripsi HTTPS)"]
    end

    style NGX stroke:#0288d1,stroke-width:3px
    style WS stroke:#8e24aa,stroke-width:1.5px
    style RP stroke:#8e24aa,stroke-width:1.5px
    style LB stroke:#8e24aa,stroke-width:1.5px
    style HC stroke:#8e24aa,stroke-width:1.5px
    style ST stroke:#8e24aa,stroke-width:1.5px

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:

sequenceDiagram
    autonumber
    participant Klien as Browser Pengguna
    participant DNS as Server DNS
    participant NGX as Nginx Server
    participant Backend as Server Aplikasi (NodeJS/PHP)
    participant Disk as Disk Aset Lokal

    Klien->>DNS: 1. DNS Lookup (Mendapatkan IP example.com)
    DNS-->>Klien: Kembalikan IP Server
    Klien->>NGX: 2. Kirim TCP Request (Port 443)
    Note over NGX: 3. Dekripsi TLS & Parse HTTP Request
    Note over NGX: 4. Cocokkan server_name & location block
    alt Skenario A: Request File Statis
        NGX->>Disk: Request file statis (/var/www/html/about.html)
        Disk-->>NGX: Kirim isi file
        NGX-->>Klien: Kirim Response HTTP (200 OK + Payload)
    else Skenario B: Request Konten Dinamis
        NGX->>Backend: proxy_pass http://localhost:3000 (Internal Socket)
        Backend-->>NGX: Response Aplikasi (JSON / HTML Dinamis)
        NGX-->>Klien: Kirim Response HTTP (200 OK + Payload)
    end

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 kita 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.

flowchart TD
    subgraph Konvensional ["Proses Konvensional (Tanpa sendfile)"]
        direction TB
        D1[("Disk")] -->|"Copy 1"| K1["Kernel Read Buffer"]
        K1 -->|"Copy 2"| U1["User Space (Nginx)"]
        U1 -->|"Copy 3"| K2["Kernel Socket Buffer"]
        K2 -->|"Copy 4"| N1["Network Interface Card"]
    end

    subgraph ZeroCopy ["Proses Zero-Copy Nginx (Dengan sendfile)"]
        direction TB
        D2[("Disk")] -->|"Copy 1"| K3["Kernel Read Buffer"]
        K3 -->|"Direct Kernel Transfer"| N2["Network Interface Card"]
    end

    style D1 stroke:#d32f2f,stroke-width:1.5px
    style D2 stroke:#388e3c,stroke-width:1.5px
    style U1 stroke:#d32f2f,stroke-width:1.5px
    style K3 stroke:#388e3c,stroke-width:1.5px

Hasilnya: 2-3x lebih sedikit penyalinan data di memori RAM dan penggunaan CPU yang jauh lebih rendah.

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 kita gunakan untuk mengakses internet). Dalam reverse proxy, Nginx berdiri di depan server — bukan di depan klien.

flowchart LR
    subgraph FP ["Forward Proxy (Mewakili Klien)"]
        direction LR
        K1["Klien"] --> FProxy["Forward Proxy / VPN"]
        FProxy --> Internet["Internet / Server Publik"]
    end

    subgraph RP ["Reverse Proxy (Mewakili Server)"]
        direction LR
        Internet2["Internet / Publik"] --> RProxy["Nginx (Reverse Proxy)"]
        RProxy --> Backend["Internal Server (Port 3000)"]
    end

    style FProxy stroke:#8e24aa,stroke-width:2px
    style RProxy stroke:#0288d1,stroke-width:3px

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, kita 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.

flowchart TD
    subgraph TanpaTerm ["Tanpa SSL Termination (Beban CPU Berat di Backend)"]
        direction TB
        C1["Klien"] -->|"HTTPS (Port 443)"| B1["NodeJS App (Enkripsi/Dekripsi)"]
        C2["Klien"] -->|"HTTPS (Port 443)"| B2["PHP App (Enkripsi/Dekripsi)"]
    end

    subgraph DenganTerm ["Dengan SSL Termination di Nginx (Optimal)"]
        direction TB
        C3["Klien"] -->|"HTTPS (Trafik Terenkripsi)"| NGX["Nginx SSL Terminator"]
        NGX -->|"HTTP (Trafik Ringan & Cepat)"| B3["NodeJS App"]
        NGX -->|"HTTP (Trafik Ringan & Cepat)"| B4["PHP App"]
    end

    style NGX stroke:#0288d1,stroke-width:2.5px
    style B1 stroke:#d32f2f,stroke-width:1.5px
    style B2 stroke:#d32f2f,stroke-width:1.5px
    style B3 stroke:#388e3c,stroke-width:1.5px
    style B4 stroke:#388e3c,stroke-width:1.5px

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, kita butuh PHP-FPM. Untuk Node.js, kita butuh proses Node yang berjalan terpisah.

  ANTI-PATTERN (salah kaprah):
    "Nginx langsung memproses file index.php secara mandiri"
  
  BENAR:
    Nginx menerima request → meneruskan ke PHP-FPM socket → PHP-FPM menjalankan kode PHP
    → PHP-FPM mengembalikan respons ke Nginx → Nginx mengirim ke browser klien
  

• 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, kita 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:

flowchart TD
    Klien["Internet / Klien Luar"] -->|"Port 80/443"| CDN["CDN Layer (Cloudflare / Fastly)"]
    CDN -->|"Trafik Terfilter"| NGX["Nginx Edge Server"]
    
    subgraph Edge ["Edge Services (Nginx)"]
        NGX -->|"SSL Termination"| SSL["HTTPS Block"]
        NGX -->|"Rate Limiting"| RL["IP Rate Zone"]
        NGX -->|"Serving File"| SF["Static Files Folder"]
    end

    NGX -->|"proxy_pass"| App1["App Server 1 (Node.js)"]
    NGX -->|"proxy_pass"| App2["App Server 2 (Go App)"]

    App1 --> DB[("Database Cluster (PostgreSQL)")]
    App2 --> DB
    App1 --> Cache[("Cache Memory (Redis)")]
    App2 --> Cache

    style NGX stroke:#0288d1,stroke-width:3px
    style CDN stroke:#ffb300,stroke-width:2px
    style DB stroke:#43a047,stroke-width:2px
    style Cache stroke:#e53935,stroke-width:2px

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 kita ketahui:

• Nginx Open Source (nginx.org) adalah versi gratis yang tersedia di semua package manager Linux. Ini yang kita gunakan 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.

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 hingga 99% jika konten stabil dan trafik tinggi. Fitur cache ini yang membuat Nginx sering diposisikan sebagai lapisan pertahanan pertama sebelum backend.

flowchart TD
    subgraph Request1 ["1. Request Pertama (Cache Miss)"]
        direction LR
        K1["Browser Klien"] -->|"HTTP GET"| N1["Nginx Proxy"]
        N1 -->|"Cache MISS"| B1["Backend Application"]
        B1 -->|"200 OK Response"| N1
        N1 -->|"Simpan di Disk Cache"| Disk["Disk Storage"]
        N1 -->|"Kirim Respons"| K1
    end

    subgraph RequestNext ["2. Request Selanjutnya (Cache Hit)"]
        direction LR
        K2["Browser Klien"] -->|"HTTP GET"| N2["Nginx Proxy"]
        N2 -->|"Cache HIT (Cepat)"| Disk2["Disk Storage"]
        Disk2 -->|"Kirim Aset"| N2
        N2 -->|"Kirim Respons"| K2
        Note over N2: Backend tidak disentuh sama sekali!
    end

    style N1 stroke:#0288d1,stroke-width:2px
    style N2 stroke:#0288d1,stroke-width:2px
    style B1 stroke:#8e24aa,stroke-width:2px

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 kita 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 (belum aktif)
│   └── default
├── sites-enabled/          # Symlink ke sites-available yang aktif
│   └── default → ../sites-available/default
├── mime.types              # Mapping ektensi file ke MIME type
├── fastcgi_params          # Parameter FastCGI untuk integrasi PHP
├── proxy_params            # Parameter default pengiriman HTTP proxy
├── snippets/               # Konfigurasi modular yang bisa di-include
│   ├── fastcgi-php.conf
│   └── snakeoil.conf
└── modules-enabled/        # Symlink ke modul dinamis yang diaktifkan

/var/log/nginx/
├── access.log              # Log semua HTTP request masuk
└── error.log               # Log error engine dan warning

/var/www/html/              # Default root direktori aset web
└── index.html

/usr/lib/nginx/             # File binary dan library modul Nginx
/var/cache/nginx/           # Penyimpanan data cache (jika diaktifkan)

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, kita bisa melihat prosesnya di task manager:

# Lihat proses Nginx yang berjalan di server
ps aux | grep nginx

# Output (server dengan 4 core CPU):
# 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/aman)

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 (zero-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:

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:

1. 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.
2. Konfigurasi yang ekspresif: File konfigurasi Nginx menggunakan sintaks direktif dan blok yang bisa menggambarkan logika routing yang kompleks dengan cara yang relatif mudah dibaca.
3. Ekosistem yang matang: Setelah lebih dari 20 tahun, hampir semua masalah yang bisa kita temui sudah pernah dialami orang lain. Dokumentasi, tutorial, dan komunitas yang besar membuatnya mudah untuk menemukan solusi.
4. 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.
5. 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 portofolio:

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, beberapa 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, kita perlu memonitor Nginx secara aktif. Beberapa tools yang umum digunakan:

Prometheus + Grafana #

flowchart LR
    NGX["Nginx Web Server"] -->|"Metrics Export"| PE["Prometheus Exporter"]
    PE -->|"Pull Scraping"| PM["Prometheus Server"]
    PM -->|"Query & Visualisasi"| GF["Grafana Dashboard"]

    style NGX stroke:#0288d1,stroke-width:2px
    style PM stroke:#e53935,stroke-width:2px
    style GF stroke:#ffb300,stroke-width:2px

• Metrics yang dipantau: Request rate (req/detik), Error rate (5xx, 4xx), Active connections, Request duration (p50, p95, p99), Upstream response time, dan Cache hit rate.

GoAccess: Real-time Log Analysis #

# Analisis log Nginx secara real-time langsung di terminal
goaccess /var/log/nginx/access.log --log-format=COMBINED

# Atau untuk web interface HTML real-time:
tail -f /var/log/nginx/access.log | goaccess -a -o /var/www/html/report.html --real-time-html

Keamanan Default Nginx #

Nginx relatif aman secara default, tapi ada beberapa konfigurasi tambahan yang disarankan untuk production:

server {
    # Sembunyikan versi Nginx dari header respons Server
    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.

← Sebelumnya: Pengenalan   Berikutnya: Sejarah & Evolusi →