Mengira Rule .htaccess Langsung Aktif di OpenLiteSpeed Tanpa Restart

Kamu menambahkan redirect atau rewrite rule baru di .htaccess, menyimpan file, lalu membuka situs. Hasilnya tidak berubah. Rule-nya sudah dicek berkali-kali dan sintaksnya terlihat benar. Di server Apache, kebiasaan ini memang jalan. Di OpenLiteSpeed (OLS), sering kali rule tersebut belum dimuat sama sekali. Pertanyaan ini cukup sering muncul di support, biasanya dari orang yang baru pindah dari shared hosting berbasis Apache ke VPS dengan OpenLiteSpeed. Yang salah biasanya bukan rule-nya. Yang keliru adalah asumsi bahwa web server membaca file itu setiap kali ada request.

Kenapa OpenLiteSpeed tidak membaca ulang .htaccess

Apache dengan AllowOverride aktif mengecek file .htaccess di setiap direktori yang dilewati request, dan itu terjadi di setiap request. Itu sebabnya perubahan langsung terasa. Harganya ada di performa, karena ada banyak operasi baca file yang terus berulang. OpenLiteSpeed memilih jalan lain. Secara default, OLS tidak memproses .htaccess sama sekali. Rule di dalamnya baru dipakai kalau pengaturan rewrite di virtual host (vhost, konfigurasi per situs di web server) mengaktifkan opsi auto load dari .htaccess. Kalau opsi itu aktif, OLS membaca file tersebut lalu menyimpan hasilnya di memori. Request berikutnya memakai versi yang sudah di-cache, bukan isi file terbaru di disk. Akibatnya, perubahan di .htaccess biasanya baru berlaku setelah graceful restart. Graceful restart adalah restart yang memberi kesempatan request yang sedang berjalan selesai dulu, lalu proses baru dijalankan dengan konfigurasi baru. Ada satu hal lagi yang sering terlewat. OLS hanya mengambil directive rewrite (RewriteEngine, RewriteCond, RewriteRule, dan sejenisnya) dari .htaccess. Directive lain seperti php_value atau Options tidak diproses. Jadi kalau yang kamu ubah bukan rule rewrite, restart pun tidak akan mengubah apa-apa. Perilaku ini khusus OpenLiteSpeed. LiteSpeed Web Server versi Enterprise dirancang kompatibel dengan Apache dan menangani .htaccess dengan cara yang berbeda. Jangan samakan keduanya saat troubleshooting.

Cek dulu apakah vhost memang memuat .htaccess

Sebelum menyalahkan cache, pastikan dulu OLS memang diberi izin membaca .htaccess untuk situs itu. Setelah itu, bandingkan dua waktu: kapan .htaccess terakhir diubah, dan kapan proses OpenLiteSpeed terakhir dijalankan. Kalau file diubah setelah proses start, hampir pasti rule baru belum dimuat.

BASH

# Lihat pengaturan rewrite di config vhost (ganti NamaVhost sesuai setup kamu)
grep -n -A6 -i 'rewrite' /usr/local/lsws/conf/vhosts/NamaVhost/vhconf.conf

# Waktu terakhir .htaccess diubah (sesuaikan path document root)
stat -c '%y %n' /var/www/situs/public_html/.htaccess

# Waktu start proses OpenLiteSpeed
ps -eo pid,lstart,cmd | grep '[l]sws'

Di output grep, cari blok rewrite dengan enable bernilai 1 dan autoLoadHtaccess bernilai 1. Kalau autoLoadHtaccess tidak ada atau bernilai 0, OLS tidak membaca .htaccess sama sekali, dan restart berapa kali pun tidak membantu. Lokasi file config bisa berbeda tergantung cara OLS dipasang. Beberapa setup mendefinisikan vhost langsung di httpd_config.conf, ada juga yang dikelola lewat panel. Kalau file di atas tidak ditemukan, cek pengaturan yang sama di WebAdmin console, di bagian Rewrite pada vhost yang bersangkutan. Untuk perintah ps, perhatikan kolom waktu start. Bandingkan dengan hasil stat. Pola yang perlu dicurigai adalah proses berjalan sejak kemarin sementara .htaccess baru diubah sepuluh menit lalu.

Tes rule langsung ke server, bukan lewat browser

Browser bukan alat tes yang bagus untuk redirect. Redirect 301 bisa disimpan di cache browser. Kalau situs ada di belakang CDN atau reverse proxy, respons yang kamu lihat mungkin juga berasal dari cache di sana. Kamu bisa saja melihat redirect lama padahal server sudah berubah, atau sebaliknya. Cara yang lebih bersih adalah memakai curl dan mengarahkan domain langsung ke server lewat opsi --resolve. Dengan cara ini, DNS publik dan CDN dilewati, tetapi header Host dan SNI tetap benar.

BASH

# Jalankan di server itu sendiri, ganti domain dan path sesuai rule yang diuji
curl -skI --resolve example.com:443:127.0.0.1 https://example.com/halaman-lama | grep -iE '^(HTTP|location)'

Opsi -I hanya mengambil header. -s menyembunyikan progress bar. -k mengabaikan error validasi sertifikat yang kadang muncul saat koneksi diarahkan ke 127.0.0.1. Jalankan perintah ini sebelum restart dan catat hasilnya. Kalau rule redirect belum dimuat, biasanya kamu melihat status 200 atau 404 tanpa header Location. Kalau sudah dimuat, kamu melihat 301 atau 302 beserta header Location yang mengarah ke tujuan baru. Hasil sebelum restart ini penting sebagai pembanding. Tanpa catatan itu, sulit membedakan apakah restart yang memperbaiki masalah atau ada faktor lain.

Graceful restart lalu verifikasi ulang

Graceful restart di OpenLiteSpeed bisa dilakukan lewat tombol Graceful Restart di WebAdmin console, atau lewat CLI dengan lswsctrl. Prosesnya tidak memutus koneksi yang sedang berjalan secara paksa, jadi biasanya aman dilakukan di jam kerja. Kalau server melayani trafik besar, tetap pilih waktu yang wajar.

BASH

# Graceful restart OpenLiteSpeed
sudo /usr/local/lsws/bin/lswsctrl restart

# Pastikan proses benar-benar baru: waktu start harus berubah
ps -eo pid,lstart,cmd | grep '[l]sws'

# Ulangi tes yang sama seperti sebelum restart
curl -skI --resolve example.com:443:127.0.0.1 https://example.com/halaman-lama | grep -iE '^(HTTP|location)'

# Cek error log kalau ada masalah saat memuat config
sudo tail -n 50 /usr/local/lsws/logs/error.log

Urutan pengecekannya sengaja dibuat begitu.

Pastikan waktu start proses sudah berubah. Kalau masih sama, restart belum terjadi, mungkin karena perintah gagal atau kamu menjalankannya di server yang salah.
Ulangi tes curl. Sekarang seharusnya muncul status redirect dan header Location yang benar.
Baca error log. Error di sini bisa menunjukkan masalah saat OLS memuat konfigurasi.

Sebagai contoh format output, hasil curl yang berhasil kira-kira berupa satu baris HTTP/2 301 diikuti baris location: https://example.com/halaman-baru. Ini hanya ilustrasi format, bukan hasil dari server tertentu.

Kalau setelah restart rule tetap tidak jalan

Kalau proses sudah baru tetapi curl masih menunjukkan perilaku lama, masalahnya ada di rule atau di cara OLS menafsirkannya. Ada beberapa hal yang biasanya dicek, kurang lebih sesuai urutan seberapa sering penyebab itu muncul. Pertama, aktifkan log rewrite sementara. Di pengaturan Rewrite vhost ada opsi log level (logLevel di blok rewrite pada vhconf.conf). Nilai yang lebih tinggi membuat OLS mencatat langkah pencocokan setiap rule ke error log, termasuk pattern yang dicoba dan hasilnya. Ubah nilainya, lakukan graceful restart, kirim satu request dengan curl, lalu baca error.log. Di beberapa setup, log ini baru muncul kalau level log server juga dinaikkan, jadi cek pengaturan itu juga. Setelah selesai, kembalikan ke 0, karena log rewrite yang detail cepat membuat file log membengkak. Kedua, perhatikan tempat rule ditulis. Rule yang ditaruh di field Rewrite Rules pada vhost diproses dalam konteks yang berbeda dengan rule di .htaccess. Perbedaan yang paling sering bikin bingung ada di slash di depan path. Pattern seperti ^halaman-lama$ bisa cocok di .htaccess tetapi tidak cocok di level vhost, yang melihat path dengan slash di depan. Kalau kamu memindahkan rule dari satu tempat ke tempat lain, cek bagian ini dulu. Ketiga, pastikan .htaccess yang kamu edit memang berada di document root yang dipakai vhost. Cara paling cepat adalah melihat setting document root vhost lalu membandingkannya dengan path file yang kamu ubah. Kesalahan ini sering muncul saat ada beberapa salinan situs atau folder staging di server yang sama. Keempat, ingat batasan yang tadi: hanya directive rewrite yang diproses. Kalau tujuanmu sebenarnya mengubah setting PHP atau header, .htaccess di OpenLiteSpeed bukan tempatnya. Pengaturan itu biasanya dilakukan di konfigurasi vhost, di php.ini, atau lewat mekanisme lain sesuai setup. Terakhir, kalau dari server hasil curl sudah benar tetapi pengunjung masih melihat perilaku lama, masalahnya sudah di luar web server. Penyebabnya bisa cache browser yang menyimpan 301 lama, cache CDN yang perlu di-purge, atau DNS yang masih mengarah ke server lain. Tes dengan --resolve tadi berguna untuk memisahkan dua kemungkinan ini. Kebiasaan yang paling membantu di OpenLiteSpeed sederhana: setiap kali mengubah .htaccess, anggap rule baru belum aktif sampai kamu melakukan graceful restart dan memverifikasinya sendiri dengan curl langsung ke server. Bandingkan waktu ubah file dengan waktu start proses, uji sebelum dan sesudah restart, dan jangan jadikan browser sebagai bukti. Dengan tiga langkah itu, sebagian besar kasus "rule tidak berpengaruh" bisa dipastikan penyebabnya dalam beberapa menit.