Validator Konfigurasi Nginx
Tempel nginx.conf untuk menemukan kesalahan sintaks, direktif yang salah tempat, dan kesalahan keamanan umum — sebelum Anda me-reload nginx.
Seret file .conf ke sini, atau tempel teks konfigurasi di atas.
Semua diproses di browser Anda — konfigurasi Anda tidak pernah diunggah ke server mana pun.
Tempel konfigurasi nginx di atas (atau muat contoh) dan hasil pemeriksaan akan muncul di sini.
Menggunakan mesin regex JavaScript, bukan mesin PCRE asli nginx — sangat mirip, tetapi tidak identik (tanpa possessive quantifier/atomic group).
Menangkap kesalahan konfigurasi nginx sebelum sampai ke produksi
nginx.conf yang rusak biasanya menampakkan diri dengan salah satu dari dua cara yang tidak menyenangkan: `nginx -t` menolak reload dengan error nomor baris yang samar, atau — lebih buruk — `reload` diam-diam mempertahankan konfigurasi lama (yang berfungsi) di memori sementara yang baru rusak di disk, sehingga tidak ada yang tampak salah sampai restart penuh berikutnya. Keduanya dapat dihindari dengan menangkap jenis kesalahan yang sama lebih awal, saat Anda masih mengedit.
Kesalahan nginx.conf yang paling umum di dunia nyata sebenarnya tidak aneh — titik koma yang terlupa. Karena tata bahasa nginx hanya peduli pada `;`, `{`, dan `}` (bukan pemisah baris), `;` yang hilang tidak menghasilkan error bersih "baris 12: expected ;" seperti kebanyakan parser modern; sebaliknya, nama dan argumen direktif berikutnya diam-diam terserap sebagai argumen tambahan direktif sebelumnya, kadang tanpa error sama sekali sampai ada sesuatu di hilir yang berperilaku aneh. Heuristik pemisah baris pada alat ini secara khusus mengawasi pola tersebut — nama direktif yang dikenal muncul di tengah daftar argumen pada baris sumber baru — dan menandainya sebelum menjadi tiket dukungan.
Penempatan direktif adalah jebakan umum kedua: `proxy_pass` hanya masuk akal di dalam blok `location` (atau `if`), `listen`/`server_name` hanya di dalam `server`, dan seterusnya — tetapi parser nginx sendiri tidak menolak direktif hanya karena berada di tempat yang tidak lazim, dan pesan error-nya mengarah ke registri direktif internal nginx, bukan ke "Anda menyarangkannya dengan salah." Validator ini memeriksa tabel direktif-ke-konteks secara langsung, sehingga `proxy_pass` yang tidak sengaja tertinggal di tingkat `http` (di luar `server`/`location`) ditandai pada baris yang tepat, bukan sekadar "konfigurasi gagal dimuat."
Di luar sintaksis, beberapa pilihan konfigurasi kecil berdampak besar bagi keamanan: membiarkan `server_tokens` pada nilai default (`on`) membuka versi nginx Anda yang persis di setiap header respons dan halaman error default, yang merupakan pengintaian gratis bagi siapa pun yang mencari CVE khusus versi; memakai variabel `$uri` yang sudah didekode URL di dalam `return`/`rewrite`/`add_header` (bukan `$request_uri` yang mentah) dapat memungkinkan penyerang menyisipkan karakter ke target redirect pada beberapa konfigurasi. Keduanya tidak merusak apa pun secara kasatmata saat pengujian normal, dan itulah alasan keduanya layak diperiksa khusus, bukan mengandalkan mata untuk menyadarinya di konfigurasi 200 baris.
Pertanyaan yang sering diajukan
Apakah ini menggantikan `nginx -t`?
Tidak. `nginx -t` adalah satu-satunya alat yang memeriksa konfigurasi Anda terhadap build nginx dan modul yang benar-benar terpasang di server Anda, dan itulah keputusan akhir sebelum reload. Validator ini menangkap jenis kesalahan yang sama (kesalahan sintaksis, penempatan direktif yang salah, beberapa indikasi masalah keamanan) bahkan sebelum Anda sampai ke server yang terpasang nginx — berguna saat mengedit secara lokal, di langkah CI, atau ketika Anda belum punya akses shell ke mesin tujuan.
Apakah daftar periksa keamanannya lengkap?
Tidak — hanya mencakup sekumpulan kecil pemeriksaan yang sengaja dipilih (`server_tokens off;` yang hilang, `autoindex on;`, dan `$uri` yang dipakai padahal `$request_uri` lebih aman) dengan inspirasi longgar dari Gixy, auditor konfigurasi nginx sumber terbuka. Ini bukan pengganti Gixy maupun audit keamanan menyeluruh.
Mengapa penguji regex berperilaku sedikit berbeda dari nginx asli?
Pencocokan `location ~` dan `location ~*` di nginx memakai PCRE (lewat pustaka PCRE bawaan di biner nginx). Alat ini berjalan sepenuhnya di browser, sehingga memakai mesin RegExp bawaan JavaScript — keduanya sangat mirip untuk pola umum, tetapi fitur khusus PCRE seperti possessive quantifier atau atomic group tidak akan berperilaku sama di sini.
Apakah konfigurasi saya pernah meninggalkan browser?
Tidak. Parsing, validasi, dan kedua simulator berjalan dengan JavaScript biasa di tab ini. Tidak ada yang diunggah, dicatat, atau dikirim ke mana pun — Anda bahkan bisa memutus koneksi internet setelah halaman dimuat dan alat ini tetap berfungsi.