OpenLiteSpeed'de .htaccess'in çalışmayan yarısı

Apache ile fark

OpenLiteSpeed, Apache uyumluluğunu bir uyum katmanı olarak sunar; motorun kendisi Apache değildir. Bu ayrım pratikte şu anlama gelir: yaygın kullanılan yeniden yazma kuralları çalışır, geri kalan yönergelerin çoğu ya yok sayılır ya da yapılandırma hatası olarak değerlendirilir.

Sorun bu davranışın sessiz olmasıdır. Apache'de hatalı bir yapılandırma genellikle 500 hatası ve hata kaydında açık bir satır üretir. OpenLiteSpeed'de ise çoğu zaman yalnızca 403 görürsünüz — üstelik hata kaydında sebebi anlatan bir satır olmayabilir.

Daha kötüsü: hata bir blok hatası olduğunda dosyanın tamamı geçersiz sayılabilir. Yani dosyanın başındaki geçerli HTTPS yönlendirmesi de çalışmaz. Bu, "kural yazdım ama hiçbir şey olmuyor" şikâyetinin en sık sebebidir.

Çalışanlar

Pratikte güvenle kullanılabilecek olanlar yeniden yazma ailesidir:

# HTTPS ve www olmayan adrese tek adımda yönlendirme
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://alanadi.com/$1 [R=301,L]

# index.html -> klasör adresi (kopya URL'leri engeller)
RewriteCond %{THE_REQUEST} \s/+(([^\s?]*/)?)index\.html[\s?] [NC]
RewriteRule ^ https://alanadi.com/%1 [R=301,L]

RewriteEngine, RewriteCond, RewriteRule ve bunların bayrakları (R, L, NC, QSA) beklendiği gibi işler. WordPress'in kendi kalıcı bağlantı kuralları da bu kapsamdadır — bu yüzden WordPress OpenLiteSpeed üzerinde sorunsuz çalışır.

Çalışmayanlar

Aşağıdakiler Apache'de rutin, OpenLiteSpeed'de sorun kaynağıdır:

# ✗ Güvenlik başlıkları — .htaccess'te çalışmaz
<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

# ✗ Dosya erişim kısıtı — 403 üretir ve dosyayı geçersiz kılar
<Files "wp-config.php">
  Require all denied
</Files>

# ✗ Uzantı bazlı kurallar
<FilesMatch "\.(env|log|bak|sql)$">
  Require all denied
</FilesMatch>

# ✗ Önbellek süreleri
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
</IfModule>

Bu blokların tehlikesi yalnızca işe yaramamaları değil. Bir .htaccess dosyasına eklendiklerinde, o dosyadaki çalışan kuralları da götürebilirler. Yani sitenin HTTPS yönlendirmesi bir gün sessizce durur ve kimse neden olduğunu anlamaz.

Belirtiyi tanımak

Şu üç belirtiden biri varsa doğrudan .htaccess içeriğine bakın:

• Site kökü ya da belirli bir klasör beklenmedik şekilde 403 Forbidden dönüyor, ama dosya izinleri doğru.
• Yazdığınız yönlendirme hiç çalışmıyor — sanki dosya okunmuyormuş gibi.
• Bir kural eklendikten sonra daha önce çalışan başka bir kural bozuldu.

Hızlı doğrulama yöntemi: dosyayı geçici olarak yeniden adlandırıp siteyi test edin.

mv .htaccess .htaccess.test
curl -sI https://alanadi.com/ | head -1
# 403 gitti mi? Sebep dosyanın içindeydi.
mv .htaccess.test .htaccess

Sonra dosyayı ikiye bölerek hangi bloğun sorun çıkardığını daraltın. Neredeyse her seferinde bir <IfModule>, <Files> ya da Header satırı çıkar.

Doğru yer: vhost

.htaccess'e sığmayan her şey sanal konak yapılandırmasına gider. CyberPanel kullanıyorsanız bu, sitenin vhost.conf dosyasıdır ve panelden düzenlenebilir.

Güvenlik başlıkları ve önbellek süreleri burada tanımlanır:

context / {
  extraHeaders            <<<END_extraHeaders
X-Content-Type-Options nosniff
X-Frame-Options SAMEORIGIN
Referrer-Policy strict-origin-when-cross-origin
Strict-Transport-Security max-age=31536000; includeSubDomains
  END_extraHeaders
}

expires {
  enableExpires           1
  expiresByType           image/webp=A31536000, text/css=A31536000, application/javascript=A31536000, text/html=A300
}

Buradaki text/html=A300 ayrıntısına dikkat: HTML dosyaları uzun süre önbelleğe alınmamalıdır. Statik bir sitede varlıkları bir yıl önbelleğe alıp HTML'i beş dakikada bir tazelemek doğru dengedir — içerik güncellemesi kısa sürede görünür, buna karşılık CSS/JS/görsel tekrar indirilmez.

Dosya erişim kısıtları için ise yeniden yazma kullanılır; bu .htaccess'te de çalışır:

RewriteRule ^(.*/)?\.(env|git|htaccess|htpasswd)$ - [F,L]
RewriteRule \.(log|bak|sql|sql\.gz|tar\.gz|zip)$ - [F,L]

[F] bayrağı 403 döndürür ve blok sözdizimi gerektirmediği için OpenLiteSpeed'de sorunsuz işler.

Statik dosya tuzağı

Bir ayrıntı daha, güvenlik açısından önemli: OpenLiteSpeed statik dosyaları rewrite kurallarına uğratmadan servis edebilir. Bu, performans için iyi bir davranış ama beklenmedik bir sonuç doğurur — yedek dosyalarınız korunmasız kalabilir.

Yaygın senaryo şu: bir dosyayı düzenlemeden önce yanına yedeğini alırsınız.

# Riskli alışkanlık
cp wp-config.php wp-config.php.bak
cp index.html index.html.20260902.bak

Bu dosyalar site kökünde durduğu sürece, tarayıcıdan adresleri tahmin edilerek indirilebilir — ve .bak uzantısı PHP olarak yorumlanmadığı için içeriği düz metin olarak görünür. Veritabanı parolanız dâhil.

Doğru alışkanlık, yedekleri web kökünün dışına almaktır:

mkdir -p /home/alanadi.com/code-backups
cp /home/alanadi.com/public_html/wp-config.php \
   /home/alanadi.com/code-backups/wp-config.php.20260902

Web sunucusu bu klasörü hiç görmez; erişim kuralına da gerek kalmaz.

Özet

OpenLiteSpeed üzerinde .htaccess'i yalnızca yeniden yazma dosyası olarak kullanın. Başlık, önbellek ve dosya blokları vhost yapılandırmasına aittir; erişim engelleri [F] bayraklı rewrite kurallarıyla yazılır.

Ve bir kural değişikliğinden sonra her zaman siteyi test edin: bu sunucuda hatalar gürültü çıkarmaz, sessizce çalışmayı bırakır.