LiteSpeed üzerinde sorunsuz ve hızlı çalışan bir web sitesi, Nginx'e taşındığında bazı durumlarda beklenenden daha yavaş çalışabilir.

Bu durumun sebeplerinden biri, LiteSpeed üzerinde kullanılan .htaccess kurallarının Nginx'e doğrudan veya hatalı şekilde migrate edilmesi ve gereksiz rewrite kurallarının Nginx tarafında her istekte çalıştırılmasıdır.

Özellikle yüksek hit alan WordPress, WooCommerce ve PHP tabanlı sitelerde rewrite kurallarının yanlış yapılandırılması;

• TTFB değerlerinin yükselmesine,

• CPU kullanımının artmasına,

• Gereksiz redirect'lere,

• Fazladan location/rewrite kontrollerine,

• Cache bypass edilmesine,

• PHP'ye gereksiz istek gönderilmesine

neden olabilir.

Bu nedenle LiteSpeed'den Nginx'e geçiş sırasında .htaccess dosyasının birebir çevrilmesi yerine kuralların analiz edilerek Nginx yapısına uygun şekilde yeniden düzenlenmesi daha sağlıklı bir yaklaşımdır.

.htaccess ile Nginx Arasındaki Temel Fark

LiteSpeed ve Apache tabanlı sistemlerde .htaccess kullanımı oldukça yaygındır.

Örneğin klasik WordPress .htaccess yapısı:

RewriteEngine On

RewriteBase /
RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Nginx ise .htaccess dosyasını kullanmaz.

Kurallar doğrudan Nginx server configuration içerisinde tanımlanır.

Örneğin WordPress için temel yapı:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Bu nedenle .htaccess içerisinde bulunan onlarca kuralı Nginx'e birebir çevirmek her zaman doğru değildir.

Neden Yavaşlama Oluşabilir?

Nginx normal şartlarda oldukça hızlı bir web sunucusudur. Ancak yapılandırma sırasında gereksiz veya hatalı rewrite kuralları eklenirse avantajının bir kısmı kaybedilebilir.

Özellikle aşağıdaki durumlara dikkat edilmelidir:

• Çok fazla rewrite kullanılması

• Gereksiz regex kullanımı

• Aynı URL'nin birden fazla rewrite işleminden geçirilmesi

• Birden fazla if bloğu kullanılması

• Gereksiz redirect zincirleri

• Cache'e girmesi gereken isteklerin bypass edilmesi

• Statik dosyaların PHP'ye gönderilmesi

• WordPress için gereğinden fazla rewrite tanımlanması

.htaccess Dosyasını Birebir Çevirmeyin

En sık yapılan hatalardan biri .htaccess içerisinde bulunan tüm kuralları Nginx'e birebir çevirmeye çalışmaktır.

Örneğin .htaccess içerisinde:

RewriteCond %{HTTP_HOST} ^www\.domain\.com$ [NC]
RewriteRule ^(.*)$  https://domain.com/$1  [R=301,L]

gibi bir kural varsa bunu Nginx'e doğrudan çok sayıda regex kuralıyla taşımak yerine daha sade bir server block oluşturulabilir.

Örneğin:

server {
    server_name www.domain.com;

    return 301  https://domain.com$request_uri; 
}

Burada regex tabanlı rewrite yerine doğrudan return 301 kullanılması daha temiz ve daha performanslıdır.

Rewrite Yerine return Kullanılabilecek Durumlar

Basit redirect işlemlerinde mümkün olduğunca rewrite yerine return tercih edilebilir.

Örneğin:

rewrite ^/(.*)$  https://domain.com/$1  permanent;

yerine:

return 301  https://domain.com$request_uri; 

kullanılabilir.

Bu yaklaşım özellikle HTTP → HTTPS ve www → non-www gibi basit yönlendirmelerde daha sade bir yapı sağlar.

WordPress İçin Gereksiz Rewrite Kurallarından Kaçının

WordPress sitelerde çoğu zaman bütün routing işlemini aşağıdaki yapı karşılayabilir:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Burada:

/urun/test
/blog/yazi
/kategori/haber

gibi URL'ler fiziksel bir dosya veya klasör değilse WordPress'in index.php dosyasına gönderilir.

Bu nedenle .htaccess içerisindeki WordPress rewrite kurallarının tamamını Nginx'e taşımaya çoğu zaman gerek yoktur.

Statik Dosyaları PHP'ye Göndermeyin

En önemli optimizasyonlardan biri budur.

Aşağıdaki dosyalar doğrudan Nginx tarafından sunulmalıdır:

.css
.js
.jpg
.jpeg
.png
.gif
.webp
.svg
.ico
.woff
.woff2

Örneğin:

location ~* \.(css|js|jpg|jpeg|png|gif|webp|svg|ico|woff|woff2)$ {
    expires 30d;
    access_log off;
    log_not_found off;
}

Böylece statik dosyalar için PHP'ye gereksiz istek gönderilmesinin önüne geçilebilir.

PHP Location Yapısını Kontrol Edin

PHP isteklerinin doğru şekilde PHP-FPM'e yönlendirilmesi gerekir.

Örneğin:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Burada kullanılan PHP-FPM socket'i sunucudaki gerçek PHP sürümüne göre değişebilir.

Yanlış PHP location yapılandırması, özellikle yoğun trafikte ciddi performans sorunlarına neden olabilir.

Rewrite Zincirlerinden Kaçının

Örneğin bir ziyaretçinin:

 http://www.domain.com 

adresine gittiğini düşünelim.

Eğer sistem:

 http://www.domain.com 
        ↓
 https://www.domain.com 
        ↓
 https://domain.com 
        ↓
 https://domain.com/ 

şeklinde birden fazla redirect uyguluyorsa gereksiz HTTP istekleri oluşur.

Bunun yerine mümkünse tek redirect kullanılmalıdır:

 http://www.domain.com 
        ↓
 https://domain.com 

Nginx tarafında:

server {
    listen 80;
    server_name domain.com www.domain.com;

    return 301  https://domain.com$request_uri; 
}

Bu yapı hem daha sade hem de daha hızlıdır.

Regex Kullanımını Minimumda Tutun

Nginx'te regex güçlüdür ancak her şeyi regex ile çözmeye çalışmak doğru değildir.

Örneğin:

location ~* ^/(.*)\.(jpg|jpeg|png|gif|webp)$ {
    ...
}

gibi çok sayıda regex location kullanılması yerine mümkün olan yerlerde daha basit location tanımları tercih edilmelidir.

Özellikle yüksek trafikli sitelerde yapılandırmanın gereksiz yere karmaşıklaştırılmaması önemlidir.

if Kullanımına Dikkat

Nginx yapılandırmalarında çok fazla if kullanılması da sık karşılaşılan problemlerdendir.

Örneğin:

if ($request_uri ~* "/test") {
    ...
}

gibi çok sayıda koşul oluşturmak yerine mümkünse location, map veya doğrudan return gibi Nginx'in uygun mekanizmaları kullanılmalıdır.

Her if kesin olarak performans problemi oluşturmaz; ancak .htaccess mantığını birebir Nginx'e taşımak amacıyla yüzlerce koşul oluşturmak doğru bir yaklaşım değildir.

Cache Sistemini Rewrite Kurallarıyla Bozmayın

Yüksek trafikli sitelerde rewrite optimizasyonunun yanında cache yapısı da mutlaka kontrol edilmelidir.

Örneğin cache'e alınması gereken bir WordPress isteği gereksiz şekilde:

Nginx
 ↓
Rewrite
 ↓
PHP-FPM
 ↓
WordPress
 ↓
MySQL

akışına giriyorsa sunucu gereksiz yere PHP ve veritabanı kaynaklarını tüketebilir.

İdeal durumda cache'lenebilir içerik mümkün olduğunca erken aşamada karşılanmalıdır.

Özellikle:

/wp-admin/
/wp-login.php
/cart/
/checkout/
/my-account/

gibi dinamik alanların cache davranışı ayrıca değerlendirilmelidir.

.htaccess İçerisindeki Her Kural Gerekli Değildir

Migration öncesinde .htaccess dosyasını analiz etmek önemlidir.

Özellikle aşağıdaki kuralların gerçekten gerekli olup olmadığı kontrol edilmelidir:

• Eski domain redirectleri

• HTTP → HTTPS redirectleri

• www → non-www redirectleri

• Eski URL yönlendirmeleri

• Güvenlik amaçlı kurallar

• Hotlink protection

• Cache kuralları

• Gzip/Brotli ayarları

• Browser cache ayarları

• WordPress rewrite kuralları

• Eklentilerin eklediği otomatik kurallar

Bazı WordPress eklentileri .htaccess dosyasına otomatik olarak çok sayıda kural ekleyebilir.

Bu kuralların tamamının Nginx'e taşınması gerekmez.

Migration Sonrası Test

Nginx'e geçiş yaptıktan sonra sadece sitenin açılması yeterli değildir.

Aşağıdaki kontroller yapılmalıdır:

nginx -t

Ardından:

systemctl reload nginx

HTTP response kontrolü:

curl -I  https://domain.com 

Redirect kontrolü:

curl -I  http://domain.com 

Belirli URL'lerin kontrolü:

curl -I  https://domain.com/test-url 

Burada özellikle:

• 301

• 302

• 404

• 403

• 500

• 502

• 503

cevaplarına dikkat edilmelidir.

Redirect Zincirini Kontrol Edin

Redirect'lerin gerçekten tek adımda tamamlandığını görmek için:

curl -IL  https://domain.com 

kullanılabilir.

Örneğin ideal sonuç:

HTTP/2 200

veya yalnızca gerekli bir redirect:

HTTP/1.1 301
location:  https://domain.com/ 

şeklinde olmalıdır.

Bir URL'nin 3-4 farklı adrese yönlendirilmesi performans açısından gereksizdir.

Sonuç

LiteSpeed'den Nginx'e geçişte amaç `.htaccess dosyasını birebir Nginx'e çevirmek değil, mevcut kuralların ne yaptığını analiz ederek Nginx'in çalışma mantığına uygun daha sade bir yapı oluşturmaktır.

Özellikle yüksek hit alan sitelerde:

• Gereksiz rewrite kurallarını kaldırın.

• Basit redirectlerde return kullanın.

• Redirect zincirlerini engelleyin.

• Regex kullanımını minimumda tutun.

• Statik dosyaları doğrudan Nginx üzerinden servis edin.

• WordPress için gereksiz rewrite kuralları oluşturmayın.

• PHP'ye giden gereksiz istekleri azaltın.

• Cache bypass kurallarını kontrol edin.

• .htaccess içerisindeki eski veya kullanılmayan kuralları taşımayın.

• Migration sonrasında curl ve Nginx loglarıyla gerçek istekleri test edin.

Özetle: LiteSpeed üzerinde çalışan .htaccess dosyasını olduğu gibi Nginx'e taşımak yerine, kuralları sadeleştirip Nginx'in location, try_files, return ve gerektiğinde map mekanizmalarından yararlanmak daha sağlıklı ve performanslı bir yapı oluşturur.