---
title: "Hardening Nginx untuk Server Produksi"
description: "Checklist hardening Nginx produksi: sembunyikan versi, TLS modern, batasi metode, blokir file tersembunyi, atur timeout dan buffer, plus contoh config."
url: "https://nivelva.com/insight/hardening-nginx-server-produksi"
category: "Server \u0026 Infrastruktur"
tags: ["nginx","hardening server","keamanan server","tls","konfigurasi nginx"]
author: "Theresia Candiawan"
published: "2026-11-07T00:24:00+07:00"
updated: "2026-11-07T00:24:00+07:00"
language: "id"
publisher: "Nivelva (https://nivelva.com)"
---

# Hardening Nginx untuk Server Produksi

> **Jawaban singkat:** Hardening Nginx berarti mengurangi informasi dan permukaan serangan: matikan server_tokens, pakai TLS 1.2 dan 1.3, tolak host tak dikenal, batasi metode HTTP, blokir file tersembunyi seperti .env dan .git, atur timeout, batas ukuran request, rate limit di halaman login, dan log yang rapi.

Hardening Nginx adalah proses mengubah konfigurasi bawaan menjadi konfigurasi yang hanya melayani apa yang perlu, memberi informasi sesedikit mungkin, dan tahan terhadap request yang aneh. Konfigurasi bawaan dirancang agar mudah jalan, bukan agar aman di internet terbuka.

Risikonya konkret. Satu file `.env` yang bisa diunduh membuka password database dan API key. Satu `.git` yang terbuka memungkinkan orang merekonstruksi kode sumbermu. Timeout yang terlalu longgar membuat server mudah kehabisan koneksi oleh klien yang sengaja lambat. Semua itu bisa dicegah dengan beberapa baris konfigurasi.

## Lapisan yang perlu diperkuat

### Sembunyikan informasi versi

Secara bawaan, Nginx menampilkan nomor versinya di header `Server` dan di halaman error. Informasi ini memudahkan penyerang mencocokkan server dengan celah yang diketahui. Matikan dengan `server_tokens off;` di blok `http`. Ini tidak menggantikan update rutin, tapi mengurangi informasi gratis.

### TLS yang modern

Batasi protokol ke TLS 1.2 dan TLS 1.3. TLS 1.0 dan 1.1 sudah dinyatakan usang oleh IETF lewat RFC 8996 dan tidak dibutuhkan browser modern. Nginx versi baru sudah memakai `TLSv1.2 TLSv1.3` sebagai nilai bawaan, tapi menuliskannya eksplisit tetap berguna di server yang versinya beragam. Untuk daftar cipher, ikuti generator konfigurasi Mozilla (profil *intermediate* cocok untuk kebanyakan website bisnis) daripada menyusun sendiri. Aktifkan juga HSTS setelah HTTPS stabil; header ini dan header keamanan lainnya dibahas di [security headers](https://nivelva.com/insight/security-headers-csp-hsts).

### Tolak host yang tidak dikenal

Bot sering mengakses server langsung lewat alamat IP atau nama domain acak. Buat blok `default_server` yang menolak request seperti itu, supaya hanya domain yang kamu daftarkan yang dilayani. Untuk HTTPS, direktif `ssl_reject_handshake on;` (tersedia sejak Nginx 1.19.4) menolak handshake tanpa perlu sertifikat palsu.

### Batasi metode HTTP

Website biasa hanya butuh `GET`, `HEAD`, dan `POST`. Metode lain seperti `TRACE`, `PUT`, atau `DELETE` tidak perlu diterima di level web server kecuali aplikasimu memang memakainya, misalnya API REST.

### Blokir file tersembunyi dan file sensitif

File dan folder yang diawali titik, seperti `.env`, `.git`, `.htpasswd`, dan `.DS_Store`, tidak boleh bisa diakses dari luar. Kecualikan `.well-known`, karena folder itu dipakai validasi sertifikat SSL. Blokir juga ekstensi cadangan seperti `.bak`, `.sql`, dan `.old` yang sering tertinggal setelah migrasi.

### Timeout, buffer, dan batas ukuran

Timeout yang pendek untuk header dan body request membatasi dampak klien yang sengaja mengirim data sangat lambat. `client_max_body_size` membatasi ukuran unggahan; sesuaikan dengan kebutuhan nyata, misalnya ukuran file terbesar yang boleh diunggah pengguna. `large_client_header_buffers` membatasi header yang berlebihan.

### Rate limit di titik rawan

Halaman login, reset password, dan endpoint API publik adalah sasaran brute force. Modul `limit_req` membatasi jumlah request per alamat IP dalam rentang waktu tertentu. Terapkan di lokasi rawan saja, bukan di seluruh website, agar pengunjung biasa tidak terganggu. Untuk serangan volume besar, rate limit di Nginx tidak cukup; perlindungannya dibahas di [anti DDoS untuk VPS](https://nivelva.com/insight/anti-ddos-vps).

### Log yang berguna

Simpan access log dan error log, pastikan rotasi log aktif agar disk tidak penuh, dan tinjau secara berkala. Log adalah bukti pertama saat terjadi insiden.

## Contoh konfigurasi

Contoh berikut bisa kamu sesuaikan. Ganti nama domain, path sertifikat, dan alamat upstream aplikasi.

```nginx
# di dalam blok http
server_tokens off;
client_header_timeout 10s;
client_body_timeout 10s;
send_timeout 10s;
keepalive_timeout 30s;
client_max_body_size 10m;
large_client_header_buffers 4 8k;
limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;

# tolak host tak dikenal
server {
    listen 80 default_server;
    listen 443 ssl default_server;
    ssl_reject_handshake on;
    return 444;
}

server {
    listen 80;
    server_name domainmu.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name domainmu.com;

    ssl_certificate     /etc/ssl/domainmu/fullchain.pem;
    ssl_certificate_key /etc/ssl/domainmu/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_tickets off;

    if ($request_method !~ ^(GET|HEAD|POST)$) {
        return 405;
    }

    location ~ /\.(?!well-known) {
        deny all;
    }

    location ~* \.(bak|old|sql|swp|log)$ {
        deny all;
    }

    location = /login {
        limit_req zone=login burst=5 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
    }

    access_log /var/log/nginx/domainmu.access.log;
    error_log  /var/log/nginx/domainmu.error.log warn;
}
```

Direktif `http2 on;` berlaku untuk Nginx 1.25.1 ke atas. Untuk versi lebih lama, tulis `listen 443 ssl http2;`. Selalu jalankan `nginx -t` sebelum `systemctl reload nginx`.

## Perbandingan bawaan dan setelah hardening

| Area | Kondisi bawaan umum | Setelah hardening |
|:--|:--|:--|
| Versi di header | Ditampilkan | Disembunyikan (`server_tokens off`) |
| Protokol TLS | Bergantung versi dan distro | Hanya TLS 1.2 dan 1.3 |
| Akses via IP atau host asing | Dilayani blok pertama | Ditolak oleh `default_server` |
| Metode HTTP | Diteruskan ke aplikasi | Hanya GET, HEAD, POST |
| File `.env`, `.git` | Bisa terunduh bila ada di web root | Diblokir |
| Timeout dan ukuran request | Longgar | Dibatasi sesuai kebutuhan |
| Login | Tanpa batas percobaan | Rate limit per IP |
| Log | Satu file gabungan | Per situs, dengan rotasi |

> **Uji di staging dulu:**
>
> Pembatasan metode, ukuran body, dan rate limit bisa memutus fitur yang sah, misalnya unggahan file besar, webhook dari pihak ketiga, atau API yang memakai PUT dan DELETE. Terapkan di lingkungan uji atau di luar jam sibuk, lalu pantau error log setelah perubahan.

## Kapan cukup dengan Nginx, kapan perlu lapisan lain?

Hardening Nginx sudah cukup sebagai pondasi untuk website profil, blog, dan aplikasi internal dengan lalu lintas wajar. Kombinasikan dengan firewall server yang hanya membuka port 80, 443, dan SSH, serta update sistem rutin. Dasar pengamanan servernya ada di [cara mengamankan VPS baru](https://nivelva.com/insight/cara-mengamankan-vps-baru).

Lapisan tambahan seperti WAF atau CDN masuk akal ketika website memproses transaksi, sering menjadi sasaran bot, atau pernah diserang. WAF memeriksa isi request, misalnya pola SQL injection, yang tidak dilakukan konfigurasi Nginx biasa. Kalau kamu masih menimbang web server mana yang dipakai, perbandingannya ada di [Nginx vs Apache vs LiteSpeed](https://nivelva.com/insight/nginx-apache-litespeed).

Konfigurasi ini juga butuh pemilik. Tentukan siapa yang memasang update Nginx, membaca error log, dan meninjau ulang direktif secara berkala, entah staf internal atau pihak luar yang kamu tunjuk.

## Pertanyaan yang sering diajukan

### Apakah server_tokens off membuat server aman?

Tidak dengan sendirinya. Itu hanya menyembunyikan versi. Keamanan tetap bergantung pada update rutin dan konfigurasi lain.

### Berapa nilai client_max_body_size yang tepat?

Sesuaikan dengan file terbesar yang memang boleh diunggah. Nilai bawaan Nginx adalah 1 MB, yang sering terlalu kecil untuk CMS, jadi banyak orang menaikkannya.

### Apakah rate limit bisa memblokir pengguna di balik satu IP kantor?

Bisa, karena banyak pengguna berbagi satu IP publik. Pilih batas yang longgar dan gunakan burst agar lonjakan wajar tetap lolos.

### Seberapa sering konfigurasi perlu ditinjau ulang?

Setiap kali ada aplikasi atau fitur baru, dan secara berkala bersama update Nginx, karena rekomendasi TLS dan direktif bisa berubah.

## Sumber

- <https://nginx.org/en/docs/http/ngx_http_core_module.html>
- <https://nginx.org/en/docs/http/ngx_http_ssl_module.html>
- <https://nginx.org/en/docs/http/ngx_http_v2_module.html>
- <https://ssl-config.mozilla.org/>

---

Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/hardening-nginx-server-produksi
Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com