Nginx, Apache, atau Caddy? Memilih Web Server, Hasil Pengujian, dan Konfigurasi yang Sering Terlewat

Setiap aplikasi web berjalan di belakang web server, dan kebanyakan tim memilihnya karena kebiasaan: nginx karena proyek sebelumnya memakai itu, atau Apache karena sudah bawaan hosting. Keduanya biasanya tidak masalah. Yang sering menimbulkan masalah di production jarang sekali pilihan web server-nya, melainkan satu pengaturan bawaan yang tidak pernah dicek siapa pun. Untuk menunjukkan kedua sisi itu, kami menjalankan nginx, Apache, dan Caddy dalam pengujian yang sama: melayani file statis dan menjadi reverse proxy di depan aplikasi. Hasil throughput-nya kurang lebih sesuai dugaan. Hasil uji proxy-nya tidak.

Peran Web Server Saat Ini

Dalam arsitektur modern, web server jarang menjalankan aplikasinya sendiri. Ia berdiri di depan aplikasi dan menangani pekerjaan yang dibutuhkan setiap aplikasi: menangani HTTPS, melayani gambar, CSS, dan JavaScript langsung dari disk, mengompres response, menegakkan batas upload dan timeout, lalu meneruskan sisanya ke aplikasi. Untuk Laravel dan WordPress, aplikasinya adalah PHP-FPM; untuk Next.js, NestJS, Express, Go, atau Django, aplikasinya adalah server yang mendengarkan di port lokal. Peran terakhir inilah, reverse proxy, yang paling sering menjadi sumber masalah di production.

Para Kandidat

• Nginx: server berbasis event yang dirancang untuk menangani banyak koneksi dengan sedikit proses dan memori kecil. Ini pilihan paling umum untuk reverse proxy dan file statis. Cabang stabilnya saat ini adalah 1.30, dirilis April 2026; versi 1.30.6 pada 14 Oktober menambal lima celah keamanan.
• Apache HTTP Server: yang paling tua di antara ketiganya dan masih ada di mana-mana, terutama di shared hosting. Keunggulan utamanya adalah .htaccess, yang memungkinkan setiap situs mengubah aturan rewrite dan pengaturan lain tanpa menyentuh konfigurasi utama, dan banyak dipakai WordPress serta aplikasi PHP. Apache modern dengan event MPM jauh lebih efisien daripada reputasinya di era prefork.
• Caddy: server yang lebih baru, ditulis dengan Go, dengan fitur andalan HTTPS otomatis. Arahkan domain ke server, tulis dua baris konfigurasi, dan Caddy akan mengambil serta memperpanjang sertifikat sendiri, lengkap dengan HTTP/3 yang aktif secara default. Format konfigurasinya jauh lebih ringkas daripada nginx atau Apache.
• LiteSpeed: server komersial yang bisa membaca konfigurasi Apache dan file .htaccess, dipakai banyak penyedia shared hosting di Indonesia, terutama karena cache WordPress bawaannya. Edisi gratisnya, OpenLiteSpeed, hanya mendukung sebagian fitur .htaccess.

Cara Kami Menguji

Kami menjalankan nginx 1.30.6, Apache 2.4.69 dengan event MPM, dan Caddy 2.11.7 di Docker secara bergantian, masing-masing dibatasi di dua core CPU yang sama. Load generator oha berjalan di tiga core lain, dan backend Node.js kecil di core tersendiri. Setiap server memakai konfigurasi bawaan dengan access log dimatikan, ditambah baris yang diperlukan untuk melayani file dan meneruskan ke backend. Setiap pengujian memakai 100 koneksi bersamaan selama 15 detik setelah pemanasan, dan tabel menampilkan nilai tengah dari tiga kali percobaan. File yang diuji adalah halaman HTML 2 KB dan file JavaScript 100 KB.

Nginx melayani sekitar dua kali lebih banyak request daripada Apache dan tiga kali lebih banyak daripada Caddy, dengan latensi terendah dan memori yang jauh lebih kecil. Latensi ekor Apache yang tinggi sebagian berasal dari pengaturan bawaannya, yang menutup koneksi keep-alive setelah 100 request dan memulai dengan jumlah thread terbatas; men-tuning keduanya akan mempersempit selisihnya. Caddy paling lambat di sini, tetapi 13.000 request per detik di dua core tetap berarti lebih dari satu miliar request per hari. Untuk sebagian besar website dan aplikasi bisnis, ketiganya sudah cukup cepat, dan aplikasi di belakangnya akan menjadi titik lemah jauh sebelum web server-nya.

Temuan Sebenarnya: Error 502 dari Pengaturan Bawaan

Tabel di atas menunjukkan hasil proxy dengan fitur pemakaian ulang koneksi yang sudah diaktifkan. Dengan pengaturan bawaan, hasilnya sangat berbeda. Secara default, nginx berkomunikasi dengan backend memakai HTTP/1.0 dan membuka koneksi TCP baru untuk setiap request. Dalam lima detik pertama, nginx sanggup melayani sekitar 3.500 request per detik dan meninggalkan 17.323 koneksi tertutup dalam status TIME_WAIT. Linux menahan koneksi keluar yang sudah ditutup dalam status itu selama 60 detik, sementara port lokal yang tersedia secara default hanya sekitar 28.000. Begitu habis, nginx sama sekali tidak bisa membuka koneksi baru. Pada percobaan 15 detik berikutnya, 6.329 dari 6.690 request berakhir dengan 502 Bad Gateway.

Caddy sebenarnya memakai ulang koneksi secara default, tetapi hanya menyimpan maksimal 32 koneksi idle per backend. Dengan 100 request bersamaan, sisanya terus dibuka dan ditutup: 16.001 koneksi dalam status TIME_WAIT setelah delapan detik, dan pada percobaan berikutnya lebih dari separuh request gagal dengan 502. Menaikkan batasnya ke 256 membuat TIME_WAIT turun menjadi 11 dan throughput naik dari sekitar 6.800 menjadi 11.800 request per detik. Apache adalah satu-satunya dari ketiganya yang sudah memakai ulang koneksi ke backend dengan baik sejak awal.

Dalam angka: 28.000 port dibagi 60 detik berarti masalah mulai muncul di sekitar 470 koneksi baru per detik ke alamat backend yang sama. API yang sibuk, flash sale, atau load test bisa dengan mudah mencapainya, dan gejalanya, error 502 acak yang hilang sendiri ketika trafik turun, sering kali disangka masalah aplikasi. Perbaikannya cukup beberapa baris konfigurasi:

• Nginx: definisikan backend di blok upstream dengan keepalive 64 (atau lebih), lalu di dalam location atur proxy_http_version 1.1 dan proxy_set_header Connection dengan nilai kosong.
• Caddy: di dalam reverse_proxy, tambahkan blok transport http dengan keepalive_idle_conns_per_host di atas jumlah koneksi bersamaan yang diperkirakan, misalnya 256.
• Apache: pemakaian ulang koneksi ke backend HTTP sudah aktif secara default di mod_proxy_http. Pastikan tidak ada bagian konfigurasi yang mematikannya lewat disablereuse.

Jika backend berjalan di mesin yang sama dan diakses lewat 127.0.0.1, Linux bisa memakai ulang port yang sedang TIME_WAIT sehingga batasnya lebih longgar. Jika backend berada di container lain, server lain, atau di belakang load balancer, kelonggaran itu tidak berlaku. Bagaimanapun juga, koneksi baru untuk setiap request berarti satu handshake TCP tambahan di setiap pemanggilan, dan itulah sebabnya throughput sudah jauh lebih rendah bahkan sebelum error muncul.

Jadi, Pilih yang Mana?

• VPS atau cloud server yang menjalankan Laravel, Next.js, Node.js, Go, atau Python: nginx. Dokumentasinya paling lengkap untuk reverse proxy, pemakaian memorinya paling kecil, dan setiap framework punya contoh konfigurasi nginx di panduan deployment-nya.
• WordPress atau aplikasi PHP yang bergantung pada .htaccess, atau shared hosting: Apache, atau LiteSpeed jika hosting Anda menyediakannya. Memindahkan aturan .htaccess bertahun-tahun ke nginx jarang sepadan untuk situs kecil.
• Tim kecil yang ingin HTTPS tanpa repot mengurus sertifikat, tool internal, atau banyak situs kecil di satu server: Caddy. Konfigurasi yang ringkas dan sertifikat otomatis menghemat lebih banyak waktu daripada selisih throughput-nya.
• Kubernetes: yang perlu dipilih adalah ingress atau gateway controller, bukan web server. Perlu dicatat, controller Ingress NGINX dari komunitas Kubernetes sudah pensiun sejak Maret 2026 dan tidak lagi mendapat perbaikan keamanan. Nginx sendiri tidak terdampak, tetapi cluster yang masih memakai controller tersebut sebaiknya pindah ke controller yang masih didukung atau ke Gateway API.

Pengaturan yang Sering Terlewat

• Batas upload. Secara default nginx menolak body request di atas 1 MB dengan error 413, sehingga upload file dan gambar gagal. Atur client_max_body_size sesuai kebutuhan aplikasi, dan ingat bahwa PHP juga punya upload_max_filesize dan post_max_size sendiri.
• Timeout proxy. Secara default nginx menunggu backend selama 60 detik. Ekspor atau laporan yang lama akan berakhir dengan 504 Gateway Timeout. Naikkan timeout hanya untuk route tersebut, atau lebih baik lagi, pindahkan pekerjaan panjang ke queue.
• Header forwarded. Aplikasi perlu tahu IP asli pengunjung dan bahwa request aslinya memakai HTTPS. Kalau tidak, log akan mencatat alamat proxy, dan aplikasi membuat link http atau redirect loop. Nginx membutuhkan baris proxy_set_header untuk X-Forwarded-For dan X-Forwarded-Proto; Caddy mengirimkannya otomatis. Di Laravel, sesuaikan juga pengaturan trusted proxies.
• Kompresi. Konfigurasi nginx bawaan di Docker image resmi menonaktifkan gzip, dan banyak konfigurasi distro hanya mengompres HTML. Aktifkan untuk CSS, JavaScript, JSON, dan SVG, atau sajikan file yang sudah dikompres sebelumnya. Caddy membutuhkan directive encode, dan Apache perlu mod_deflate yang dikonfigurasi.
• Cache untuk file statis. File yang namanya mengandung hash, seperti aset dari Vite atau Next.js, boleh di-cache browser selama setahun. Tanpa header Cache-Control, pengunjung mengunduhnya ulang jauh lebih sering dari yang perlu.
• Informasi versi. Matikan nomor versi di response dan halaman error dengan server_tokens off di nginx atau ServerTokens Prod di Apache. Ini tidak menambal celah, tetapi mencegah scanner otomatis menandai server Anda berdasarkan versinya.
• Update. Nginx 1.30.6 saja menambal lima CVE pada Oktober 2026. Paket distro seperti milik Ubuntu tetap memakai nomor versi lama tetapi mendapat perbaikan yang di-backport, jadi lakukan update lewat package manager lalu restart service-nya; untuk Docker image resmi, image-nya perlu di-build ulang.

Sebelum Mengganti Web Server

Mengganti web server jarang menjadi cara tercepat untuk membuat situs lebih cepat. Jika halaman terasa lambat, penyebabnya hampir selalu aplikasi, database, atau tidak adanya cache. Ukur dulu: jika proses web server bukan yang menghabiskan CPU, mengganti web server tidak akan membantu. Yang benar-benar terasa hasilnya adalah memeriksa konfigurasi yang sudah ada berdasarkan daftar di atas, lalu mengujinya dengan beban yang realistis sebelum kampanye atau peluncuran, bukan saat sedang berlangsung. Jika Anda ingin konfigurasi server Anda diperiksa oleh pihak kedua, tim kami menangani hal ini untuk klien sebagai bagian dari layanan managed service.