--- title: "Setelan sysctl Linux untuk Server Web Bertrafik Tinggi" description: "Setelan kernel mana yang benar-benar berpengaruh saat server web ramai, nilai bawaannya di kernel modern, dan cara mengubahnya tanpa menebak-nebak." url: "https://nivelva.com/insight/setelan-sysctl-linux-server-web-bertrafik-tinggi" category: "Server \u0026 Infrastruktur" tags: ["sysctl","linux","nginx","kinerja server","jaringan"] author: "Lucas Tan" published: "2026-11-11T13:25:00+07:00" updated: "2026-11-11T13:25:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Setelan sysctl Linux untuk Server Web Bertrafik Tinggi > **Jawaban singkat:** Di kernel Linux modern, banyak nilai bawaan sysctl sudah layak untuk server web. Yang paling sering perlu disentuh adalah antrean koneksi (somaxconn dan backlog aplikasi), rentang port lokal untuk reverse proxy, dan BBR. Ubah satu per satu, simpan di /etc/sysctl.d, lalu ukur hasilnya. Bayangkan websitemu sedang ramai karena promo. CPU masih longgar, RAM masih sisa, tapi sebagian pengunjung mendapat koneksi gagal atau halaman yang lama sekali mulai dimuat. Di log Nginx tidak ada error yang jelas. Pada situasi seperti ini, orang biasanya mulai mencari "setelan sysctl untuk server ramai" dan menemukan daftar panjang berisi puluhan baris yang disalin dari satu blog ke blog lain. Masalahnya, banyak daftar itu ditulis untuk kernel lama. Sebagian nilainya sudah menjadi bawaan, sebagian lagi sudah dihapus dari kernel, dan ada yang justru merugikan. Artikel ini membahas setelan yang memang berpengaruh untuk server web, berikut nilai bawaannya menurut dokumentasi kernel, supaya kamu bisa memutuskan sendiri apa yang perlu diubah. ## Mulai dari mengukur, bukan menyalin Sebelum mengubah apa pun, pastikan masalahnya memang di lapisan kernel. Server yang lambat karena PHP-FPM kehabisan worker atau database yang mengunci tabel tidak akan tertolong oleh sysctl. Cek dulu beban sistem, dan kalau angkanya tinggi, baca [arti load average tinggi di Linux](https://nivelva.com/insight/load-average-tinggi-linux-artinya-solusinya) sebelum melangkah lebih jauh. Tanda bahwa antrean koneksi kernel penuh bisa dilihat dari statistik jaringan. Perintah `nstat -az | grep -i listen` menampilkan penghitung seperti `TcpExtListenOverflows` dan `TcpExtListenDrops`. Kalau angkanya terus naik saat trafik puncak, berarti ada koneksi yang ditolak karena antrean penuh. Perintah `ss -lnt` juga membantu: pada soket yang sedang mendengarkan, kolom `Send-Q` menunjukkan batas antrean dan `Recv-Q` menunjukkan isinya saat itu. Untuk menghasilkan trafik puncak dengan sengaja, lakukan uji beban di jam sepi. Caranya dibahas di [cara load test website dengan k6](https://nivelva.com/insight/cara-load-test-website-k6-sebelum-kampanye). Dengan begitu kamu punya angka pembanding sebelum dan sesudah setelan diubah. ## Setelan apa yang paling sering berpengaruh? Tabel berikut merangkum setelan yang relevan untuk server web. Nilai bawaan diambil dari dokumentasi resmi kernel Linux. | Setelan | Fungsi | Bawaan kernel modern | Kapan diubah | |:--|:--|:--|:--| | `net.core.somaxconn` | Batas atas antrean koneksi yang siap diterima aplikasi | 4096 (sebelum kernel 5.4 hanya 128) | Jarang perlu di kernel baru | | `net.ipv4.tcp_max_syn_backlog` | Antrean koneksi yang masih dalam proses jabat tangan | Menyesuaikan besar RAM | Bila ada banjir SYN atau trafik sangat tinggi | | `net.ipv4.ip_local_port_range` | Rentang port untuk koneksi keluar | 32768 sampai 60999 | Reverse proxy dengan sangat banyak koneksi ke backend | | `net.ipv4.tcp_tw_reuse` | Pakai ulang soket TIME_WAIT untuk koneksi keluar | 2 (hanya untuk loopback) | Proxy ke backend di mesin lain | | `net.ipv4.tcp_fin_timeout` | Lama menunggu di status FIN-WAIT-2 | 60 detik | Jarang perlu | | `net.ipv4.tcp_syncookies` | Pertahanan saat antrean SYN penuh | 1 (aktif) | Biarkan aktif | | `net.ipv4.tcp_congestion_control` | Algoritma kendali kemacetan | Ditentukan saat kernel dibangun, umumnya cubic | Bila ingin memakai BBR | Satu hal yang sering terlewat: `somaxconn` hanya batas atas. Aplikasi tetap meminta ukuran antreannya sendiri. Nginx, misalnya, memakai backlog 511 di Linux bila tidak diatur, sesuai dokumentasi modul `listen`. Jadi menaikkan `somaxconn` tanpa menaikkan parameter `backlog=` di direktif `listen` Nginx tidak mengubah apa-apa untuk Nginx. Contohnya `listen 443 ssl backlog=4096;`. ## Kenapa reverse proxy bisa kehabisan port lokal? Server yang menjadi reverse proxy (Nginx di depan Node.js, PHP-FPM lewat TCP, atau aplikasi di container) membuka koneksi keluar ke backend untuk setiap permintaan, kecuali koneksi itu dipakai ulang. Setiap koneksi keluar memakan satu port lokal. Setelah ditutup, port itu masih tertahan dalam status TIME_WAIT beberapa saat. Dengan rentang bawaan 32768 sampai 60999, tersedia sekitar 28 ribu port untuk satu pasangan alamat tujuan. Saat trafik sangat tinggi dan setiap permintaan membuka koneksi baru, port bisa habis dan muncul error seperti "Cannot assign requested address". Perbaikan paling sehat ada di aplikasi, bukan kernel: aktifkan keepalive ke upstream. Di Nginx, ini berarti direktif `keepalive` di blok `upstream` disertai `proxy_http_version 1.1;` dan header `Connection` yang dikosongkan. Kalau masih kurang, barulah perlebar rentang port, misalnya `net.ipv4.ip_local_port_range = 10000 65000`. Pastikan rentang baru tidak menabrak port layanan yang kamu jalankan sendiri. Port yang perlu dilindungi bisa dicadangkan lewat `net.ipv4.ip_local_reserved_ports`. Untuk `tcp_tw_reuse`, nilai bawaan 2 hanya berlaku pada koneksi loopback. Kalau backend ada di mesin lain, nilai 1 membuka pemakaian ulang untuk semua koneksi keluar. Setelan ini hanya memengaruhi koneksi yang dibuka server, bukan koneksi pengunjung yang masuk. ## Setelan lama yang sebaiknya dibuang Beberapa baris masih sering beredar di tutorial lama. `net.ipv4.tcp_tw_recycle` sudah dihapus dari kernel sejak versi 4.12 karena merusak koneksi dari pengguna di balik NAT, jadi menulisnya hanya menghasilkan error saat sysctl dibaca. Menaikkan buffer `tcp_rmem` dan `tcp_wmem` secara besar-besaran juga jarang perlu untuk website biasa, karena kernel sudah menyesuaikan buffer secara otomatis dan batas maksimumnya mengikuti besar RAM. Hati-hati juga dengan setelan yang mematikan pertahanan, misalnya `tcp_syncookies = 0`. Nilai bawaan 1 justru menjaga server tetap menerima koneksi saat ada banjir SYN. ## Cara menerapkan dengan rapi Simpan perubahan di file tersendiri, misalnya `/etc/sysctl.d/90-web.conf`: ``` net.core.somaxconn = 4096 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.ip_local_port_range = 10000 65000 net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr ``` Nilai di atas hanya contoh susunan, bukan resep pasti. Terapkan dengan `sudo sysctl --system`, lalu periksa satu per satu dengan `sysctl nama.setelan`. File terpisah memudahkan kamu menghapus perubahan bila ternyata tidak membantu. Kalau ingin memakai BBR, langkah dan cara mengujinya ada di [cara mengaktifkan TCP BBR](https://nivelva.com/insight/cara-mengaktifkan-tcp-bbr-mempercepat-jaringan-vps). Batas file terbuka (`ulimit -n`) untuk proses web server bukan urusan sysctl. Di sistem dengan systemd, batas itu diatur lewat `LimitNOFILE` pada unit layanan, sedangkan Nginx punya direktif `worker_rlimit_nofile` sendiri. Lalu jangan lupa lapisan aplikasi: jumlah worker PHP sering jadi leher botol yang sebenarnya, seperti dibahas di [cara mengatur PHP-FPM agar tahan trafik tinggi](https://nivelva.com/insight/cara-mengatur-php-fpm-website-tahan-trafik-tinggi). Ringkasnya, kernel Linux modern sudah membawa nilai bawaan yang masuk akal untuk kebanyakan server web. Yang sering perlu disentuh hanya antrean koneksi di sisi aplikasi, rentang port untuk reverse proxy, dan pilihan algoritma kemacetan. Ukur dulu, ubah satu per satu, dan simpan perubahannya di file terpisah agar mudah ditelusuri. ## Sumber - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/setelan-sysctl-linux-server-web-bertrafik-tinggi Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com