“Çok Fazla Yönlendirme” Hatasının Temel Nedenleri ve Çözümleri

The "Too Many Redirects" hatası — tarayıcılarda ERR_TOO_MANY_REDIRECTS olarak görüntülenir ve bir HTTP yönlendirme döngüsüne karşılık gelir — bir web sunucusu ile istemcinin hiçbir zaman nihai bir hedefe ulaşmayan döngüsel bir yönlendirme zincirine girdiğinde oluşur. Tarayıcı, yönlendirme eşiğini aştıktan sonra (genellikle Chrome’da 20 atlama) isteği iptal eder ve sayfayı yüklemek yerine bu hatayı gösterir.

Bu belirsiz bir ağ sorunu değildir. Sunucu kurallarınızdaki, SSL ayarlarınızdaki, CMS veritabanı değerlerinizdeki, CDN yapılandırmanızdaki veya önbelleğe alınmış yönlendirme verilerinizdeki belirli bir yanlış yapılandırmanın neden olduğu deterministik bir hatadır. Her örneğin izlenebilir bir kök nedeni vardır ve her kök nedenin kesin bir çözümü vardır. Bu kılavuz, bir VPS Hosting ortamında WordPress sitesi, özel uygulama veya ham sunucu yığını çalıştırıyor olsanız da sorunu kalıcı olarak çözmek için gereken teknik derinlikte tüm bunları ele almaktadır.

Yönlendirme Döngüsü Sırasında Gerçekte Ne Olur

Bir tarayıcı bir URL talep ettiğinde, sunucu yeni bir konuma işaret eden 301 Moved Permanently, 302 Found veya 307 Temporary Redirect durum koduyla yanıt verebilir. Tarayıcı bu konum başlığını takip eder, başka bir istek yapar ve zincirde bir noktada 200 OK yanıtı bekler.

Bir yönlendirme döngüsü şu durumlarda oluşur:

• URL A, URL B’ye yönlendirir ve URL B tekrar URL A’ya yönlendirir (iki atlamalı döngü)
• URL A, URL B’ye yönlendirir, URL B, URL C’ye yönlendirir, URL C tekrar URL A’ya yönlendirir (çok atlamalı döngü)
• Tek bir URL kendisine yönlendirir (öz-referanslı döngü)

Tarayıcılar süresiz olarak döngüye girmez. Chrome ve Firefox her ikisi de yaklaşık 20 yönlendirmeden sonra sonlandırır ve ERR_TOO_MANY_REDIRECTS görüntüler. Safari "Safari Can't Open the Page" gösterir. Temel HTTP davranışı hepsinde aynıdır.

Kök Nedenler ve Kesin Çözümler

1. .htaccess veya Nginx’te Yanlış Yapılandırılmış Yönlendirme Kuralları

En yaygın teknik neden, sunucu yapılandırma katmanındaki çakışan veya döngüsel yeniden yazma kurallarıdır.

Bozuk döngünün Apache .htaccess örneği:

RewriteEngine On
RewriteRule ^page$ /page [R=301,L]

Bu kural /page‘yi /page‘e yönlendirir — öz-referanslı bir döngü. Benzer şekilde, /old-url ile /new-url arasında zıt yönlerde yönlendirme yapan iki kural aynı hataya neden olur.

Nasıl teşhis edilir:

.htaccess dosyanızı açın ve her RewriteRule ile Redirect yönergesini manuel olarak izleyin. Hedef desenin başka bir kuralın kaynağıyla eşleşebildiği herhangi bir kural arayın.

grep -n "Redirect|RewriteRule|RewriteCond" /var/www/html/.htaccess

Nginx için, eşdeğer sorun server veya location bloklarında görünür:

# Broken example — loop between two location blocks
location /old {
    return 301 /new;
}
location /new {
    return 301 /old;
}

Nginx yapılandırmanızı şununla denetleyin:

nginx -T | grep -A3 "return 301|rewrite"

Çözüm: Her yönlendirme kuralının benzersiz, örtüşmeyen bir kaynak ve hedefe sahip olduğundan emin olun. Bir eşleşme bulunduğunda kural işlemeyi durdurmak için Apache’de [L] bayrağını kullanın. Nginx’te, netlik ve istenmeyen zincirlemeyi önlemek için rewrite yerine return 301 tercih edin.

2. HTTP’den HTTPS’ye Yönlendirme Yanlış Yapılandırması

Bu, özellikle uygulama düzeyindeki yapılandırmayı güncellemeden bir SSL Sertifikası ekledikten sonra modern barındırma ortamlarında en yaygın tek nedendir.

Hata modeli şöyle görünür:

• Web sunucusu, .htaccess veya Nginx yapılandırması aracılığıyla tüm HTTP trafiğini HTTPS’ye zorlar
• Uygulama (örn. WordPress), veritabanında siteurl veya home seçeneğini http:// olarak ayarlamıştır
• Uygulama daha sonra HTTPS isteklerini tekrar HTTP’ye yönlendirir
• Döngü şudur: HTTP → HTTPS (server) → HTTP (app) → HTTPS (server) → ...

Doğru Apache .htaccess HTTPS yönlendirmesi:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Doğru Nginx HTTPS yönlendirmesi:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Kritik tuzak: Bir yük dengeleyici veya ters proxy (Cloudflare dahil) arkasındaysanız, arka uç sunucu HTTPS’yi doğrudan görmeyebilir. Proxy, SSL’yi sonlandırır ve isteği HTTP olarak kaynak sunucunuza iletir. Sunucunuz daha sonra %{HTTPS} = off görür ve tekrar HTTPS’ye yönlendirir — bu da bir döngü oluşturur.

Çözüm, bunun yerine X-Forwarded-Proto başlığını kontrol etmektir:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3. Cloudflare ve CDN SSL Modu Uyumsuzluğu

Kaynak sunucunuzun önünde Cloudflare veya başka bir CDN kullanıyorsanız, SSL/TLS şifreleme modu kaynak sunucunuzun gerçek sertifika durumuyla eşleşmelidir.

En yaygın Cloudflare döngü senaryosu: SSL modu Esnek olarak ayarlanmıştır ve kaynak sunucuda HTTP’yi HTTPS’ye zorlayan bir .htaccess kuralı vardır. Cloudflare kaynağa HTTP gönderir, kaynak HTTPS’ye yönlendirir, Cloudflare bu yönlendirmeyi alır, tekrar HTTP gönderir — sonsuz döngü.

Çözüm: Cloudflare SSL modunu Tam (Katı) olarak ayarlayın ve kaynağınızın geçerli bir sertifikaya sahip olduğundan emin olun. Alternatif olarak, Esnek modunu kullanmanız gerekiyorsa, HTTP→HTTPS yönlendirmesini kaynak sunucunuzdan tamamen kaldırın ve Cloudflare’in bunu bir Sayfa Kuralı veya "Her Zaman HTTPS Kullan" geçişi aracılığıyla halletmesine izin verin.

Kaynağınız zaten yönlendirmeleri işliyorsa Cloudflare’deki Otomatik HTTPS Yeniden Yazmaları‘nı da devre dışı bırakın — her ikisinin de aktif olması yönlendirme mantığını ikiye katlar.

4. WordPress URL Ayarları Uyumsuzluğu

WordPress, kurallı URL’lerini iki veritabanı alanında saklar: siteurl (WordPress çekirdek kurulum URL’si) ve home (kamuya açık URL). Bu değerler sunucunun yönlendirme kurallarıyla veya birbirleriyle çakıştığında, bir döngü neredeyse kaçınılmazdır.

WP-CLI aracılığıyla mevcut değerleri kontrol edin:

wp option get siteurl
wp option get home

Veya veritabanını doğrudan sorgulayın:

mysql -u dbuser -p dbname -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Her iki değer de sunucu yapılandırmanızın uyguladığı aynı protokolü (https://) ve aynı alan adı biçimini (www ile veya olmadan) kullanmalıdır.

WP-CLI aracılığıyla düzeltin:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

wp-config.php aracılığıyla düzeltin (veritabanı değerlerini geçersiz kılar, yönetici paneline erişim engellendiğinde kullanışlıdır):

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Eklenti çakışmaları: Yönlendirme yöneticisi eklentileri (Redirection, Simple 301 Redirects, Yoast SEO’nun yönlendirme modülü), sunucu düzeyindeki kurallarla çakışan veritabanında saklanan yönlendirme kuralları oluşturabilir. Sorunu izole etmek için eklentiler dizinini geçici olarak yeniden adlandırın:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Döngünün ortadan kalktığını doğruladıktan sonra eklentileri tek tek yeniden etkinleştirin.

5. Tarayıcı Önbelleği ve Önbelleğe Alınmış 301 Yönlendirmeleri

Tarayıcılar 301 Moved Permanently yanıtlarını tasarım gereği agresif biçimde önbelleğe alır. Bir URL için daha önce 301 yönlendirmesi sunulduysa ve ardından yönlendirme hedefi değiştirildiyse, tarayıcı hâlâ eski önbelleğe alınmış yönlendirmeyi takip edebilir; bu da artık döngüye giren bir hedefe işaret edebilir.

Bu, özellikle yanıltıcı bir senaryodur çünkü döngü yeni bir tarayıcıda veya başka bir cihazda yeniden oluşmayabilir; bu da yöneticilerin sunucunun sorunsuz olduğu sonucuna yanlış biçimde varmasına neden olur.

Teşhis adımları:

1. URL’yi gizli/özel pencerede açın (önbelleğe alınmış veri yok)
2. Tarayıcı önbelleğini tamamen atlamak için curl ile test edin:

curl -I -L --max-redirs 10 https://example.com

1. Sunucu tarafında her atlamayı görmek için çevrimiçi bir yönlendirme zinciri izleyici kullanın (örn. redirect-checker.org veya httpstatus.io)

Çözüm: Etkilenen alan adı için tarayıcı önbelleğini ve çerezleri temizleyin. Chrome’da: Ayarlar > Gizlilik ve Güvenlik > Tarama Verilerini Temizle > Önbelleğe Alınan Resimler ve Dosyalar + Çerezler’i seçin.

Sunucu tarafı önbelleği için (Varnish, Redis, OPcache veya W3 Total Cache gibi bir önbellekleme eklentisi):

# Flush Varnish cache
varnishadm ban req.url ~ .

# Flush OPcache via PHP CLI
php -r "opcache_reset();"

6. www ile www Olmayan Yönlendirme Çakışmaları

Yönlendirme döngülerinin sıkça gözden kaçan bir kaynağı, www alt alan adının tutarsız işlenmesidir. Sunucunuz www.example.com‘yi example.com‘e yönlendirirken aynı zamanda example.com‘yi www.example.com‘e yönlendiriyorsa, bir döngünüz var demektir.

Mevcut DNS ve yönlendirme yapılandırmanızı kontrol edin:

curl -sI http://www.example.com | grep -i location
curl -sI http://example.com | grep -i location

Doğru Apache yapılandırması (kurallı non-www):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Bu kuralın, non-www sürümünü tekrar www‘e yönlendiren başka bir kuralla eşleştirilmediğinden emin olun.

7. Bozuk veya Çakışan Çerezler

Bazı uygulamalar, yönlendirme durumunu yönetmek için çerezler kullanır (örn. giriş yönlendirmeleri, yerel ayar algılama, A/B test çerçeveleri). Bir çerez, başka bir yönlendirmeyi tetikleyen bir yönlendirme hedefi depoluyorsa, döngü sunucu yapılandırması yerine uygulama mantığı tarafından yönlendirilir.

Teşhis: URL’yi o alan adı için tüm çerezler temizlenmiş şekilde test edin. Chrome DevTools’da (F12), Uygulama > Depolama > Çerezler’e gidin, alan adını seçin ve tüm girişleri silin. Sayfayı yenileyin.

Çerezleri temizledikten sonra hata ortadan kalkarsa, sorun sunucu yapılandırmasında değil, uygulamanızın oturum veya yönlendirme mantığındadır.

Karşılaştırma: Yaygın Yönlendirme Döngüsü Senaryoları ve Çözümleri

Sistematik Teşhis İş Akışı

Herhangi bir yapılandırma dosyasına dokunmadan önce, nedeni izole etmek için şu sırayı izleyin:

Adım 1 — Önbellek olmadan yeniden oluşturun:

curl -v -L --max-redirs 25 https://example.com 2>&1 | grep -E "Location:|< HTTP"

Bu, her yönlendirme atlamasını ve son yanıt kodunu gösterir. Aynı URL’lerin tekrarlandığını görürseniz, döngüyü doğrulamış ve hangi URL’lerin dahil olduğunu tespit etmişsinizdir.

Adım 2 — Sunucu hata günlüklerini kontrol edin:

# Apache
tail -100 /var/log/apache2/error.log | grep -i redirect

# Nginx
tail -100 /var/log/nginx/error.log | grep -i rewrite

Adım 3 — Katmanı izole edin:

• .htaccess kurallarını yorum satırına aldığınızda döngü ortadan kalkarsa, sorun Apache yapılandırmasındadır
• Cloudflare’i atladığınızda (doğrudan IP üzerinden test edin) ortadan kalkarsa, sorun CDN ayarlarındadır
• Eklentiler dizinini yeniden adlandırdığınızda ortadan kalkarsa, sorun bir WordPress eklentisindedir
• Gizli modda ortadan kalıyor ancak normal modda devam ediyorsa, sorun tarayıcı önbelleği veya çerezlerdir

Adım 4 — SSL sertifikası bağlamasını doğrulayın:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "subject|issuer|Verify"

Geçersiz veya uyumsuz bir sertifika, döngü olarak kendini gösteren HTTPS yönlendirme hatalarına neden olabilir.

Üretimde Yönlendirme Döngülerini Önleme

Sorun çözüldükten sonra, bu uygulamalar tekrarlanmasını önler:

• Tek bir kurallı yönlendirme kuralı kullanın; hem HTTP→HTTPS hem de www→non-www’yi etkileşime girebilecek iki ayrı kural yerine tek bir geçişte ele alın
• Herhangi bir yapılandırma değişikliğinden sonra curl -L veya çevrimiçi bir yönlendirme denetleyicisi kullanarak yönlendirme zincirlerini dağıtmadan önce test edin
• 301 yönlendirmelerini yalnızca kalıcı olduğunda ayarlayın — tarayıcıların yönlendirmeyi önbelleğe almaması için test sırasında 302 kullanın
• Her yönlendirme kuralını .htaccess veya Nginx yapılandırmanızda amacı açıklayan satır içi yorumlarla belgeleyin
• Yönlendirme zincirlerini takip eden ve atlama sayısı bir eşiği aştığında uyarı veren çalışma süresi araçlarıyla izleyin

cPanel ile VPS üzerinde birden fazla siteyi yöneten ekipler için, cPanel’in Yönlendirmeler modülü yönlendirme kurallarını yönetmek için görsel bir arayüz sağlar; ancak .htaccess‘e yazar — GUI’yi kullandıktan sonra çıktıyı her zaman manuel olarak doğrulayın.

Yüksek trafikli bir site veya birden fazla alan adı çalıştırıyorsanız, bir Dedicated Server, yönlendirme hata ayıklamasını karmaşıklaştırabilecek paylaşımlı ortam kısıtlamalarını ortadan kaldırarak sistem düzeyinde Nginx veya Apache yapılandırması üzerinde tam kontrol sağlar.

Plesk veya DirectAdmin gibi VPS Control Panels kullanan siteler için, yönlendirme kuralları panelin arayüzü aracılığıyla ve doğrudan yapılandırma dosyalarında yönetilebilir — birbirini çelişip çelişmediğinden emin olmak için her iki konumu da kontrol edin.

Teknik Temel Kontrol Listesi

ERR_TOO_MANY_REDIRECTS teşhis ederken bunu bir ön kontrol listesi olarak kullanın:

• [ ] Herhangi bir yapılandırmaya dokunmadan önce tam yönlendirme zincirini haritalamak için curl -v -L --max-redirs 25 çalıştırın
• [ ] WordPress’teki siteurl ve home‘nin sunucunuzun uyguladığı protokol ve alan adıyla eşleştiğini doğrulayın
• [ ] Kaynağınızın geçerli bir sertifikası varsa Cloudflare SSL modunun Tam (Katı) olduğunu doğrulayın
• [ ] Bir proxy arkasındayken .htaccess veya Nginx yapılandırmasının %{HTTPS} yerine X-Forwarded-Proto kullandığını kontrol edin
• [ ] www ve www olmayan yönlendirmelerin tek yönlü olduğundan emin olun — yalnızca bir kurallı form
• [ ] Yönlendirmeyle ilgili tüm eklentileri geçici olarak devre dışı bırakın ve tek tek yeniden etkinleştirin
• [ ] Önbelleğe alınmış 301 yanıtlarını dışlamak için tarayıcı önbelleğini temizleyin ve gizli modda test edin
• [ ] Döngüyü yönlendiren yönlendirme durumu için uygulama çerezlerini inceleyin
• [ ] SSL sertifikasının geçerli olduğunu ve alan adına doğru şekilde bağlandığını doğrulayın
• [ ] Düzelttikten sonra, bozuk bir yönlendirmenin yeniden önbelleğe alınmasını önlemek için 301‘e geçmeden önce geçici olarak 302 kullanın

SSS

ERR_TOO_MANY_REDIRECTS ile 310 HTTP durum kodu arasındaki fark nedir?

ERR_TOO_MANY_REDIRECTS, tarayıcı yönlendirme takip sınırını aştıktan sonra (genellikle 20) tetiklenen istemci taraflı bir tarayıcı hatasıdır. HTTP 310, protokol düzeyinde "Çok Fazla Yönlendirme" anlamına gelen nadiren kullanılan bir durum kodudur. Pratikte, üretimde karşılaştığınız neredeyse tüm yönlendirme döngüsü hataları, sunucu tarafından verilen 310 yanıtı değil, tarayıcı taraflı ERR_TOO_MANY_REDIRECTS‘dır.

Yönlendirme döngüsü neden yalnızca bazı tarayıcılarda veya cihazlarda görünür, diğerlerinde görünmez?

En yaygın neden, tarayıcıda önbelleğe alınmış ve artık geçersiz bir hedefe işaret eden 301 yönlendirmesidir. 301 yanıtları varsayılan olarak süresiz olarak önbelleğe alındığından, URL’yi daha önce ziyaret etmiş bir tarayıcı eski bir yönlendirme zincirini takip edebilir. Gizli modda veya yeni bir cihazda test etmek bu önbelleği atlar ve sunucunun mevcut davranışını ortaya koyar.

Yönetici paneline erişemediğimde WordPress’teki yönlendirme döngüsünü nasıl düzeltirim?

Veritabanı URL değerlerini geçersiz kılmak için doğrudan wp-config.php‘e aşağıdaki satırları ekleyin, ardından ayarları düzgün şekilde düzeltmek için yönetici paneline erişin:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Alternatif olarak, değerleri wp-cli kullanarak veya wp_options tablosuna karşı doğrudan bir MySQL sorgusuyla veritabanında güncelleyin.

Yönlendirme döngüsü SEO sıralamalarını etkiler mi?

Evet. Yönlendirme döngüsü 200 OK yanıtı döndürmez; bu da Googlebot’un etkilenen URL’yi tarayamayacağı veya dizine ekleyemeyeceği anlamına gelir. Döngü ana sayfanızı veya önemli açılış sayfalarınızı etkiliyorsa, zamanla dizinden çıkarılmayla sonuçlanacaktır. Ayrıca, döngüye giren URL üzerinden geçen 301 bağlantı değeri etkin biçimde kaybolur. Döngüyü derhal çözmek ve Google Search Console’da taranabilirliği doğrulamak çok önemlidir.

Cloudflare’in SSL kurulumumla yönlendirme döngülerine neden olmasını nasıl önlerim?

Cloudflare’in SSL/TLS şifreleme modunu SSL/TLS panosunda Tam (Katı) olarak ayarlayın. Bu, Cloudflare’in kaynağınızla doğrulanmış bir sertifika kullanarak HTTPS üzerinden iletişim kurmasını sağlar ve Esnek modun kaynak sunucu da HTTPS’yi zorladığında oluşturduğu HTTP↔HTTPS döngüsünü ortadan kaldırır. Ayrıca, kaynağınız veya .htaccess zaten HTTP’den HTTPS’ye yönlendirmeyi işliyorsa, çift yönlendirme mantığını önlemek için Cloudflare’deki "Otomatik HTTPS Yeniden Yazmaları"nı devre dışı bırakın.