ERR_TOO_MANY_REDIRECTS Hatası: Yönlendirme Döngüsü Çözümü

ERR_TOO_MANY_REDIRECTS ne demek?

Her yönlendirme, sunucunun 301, 302, 307 veya 308 gibi bir durum kodu ve Location başlığıyla "bu içerik şu adreste" demesidir. Tarayıcı bu zinciri belli bir sınıra kadar izler. Chromium'un ağ katmanında bu sınır kMaxRedirects = 20 olarak tanımlıdır; sınır aşıldığında istek durdurulur ve hata sayfası açılır. Yani hata sayfanın "bozuk" olduğunu değil, adreslerin birbirini işaret ederek bir çember oluşturduğunu söyler. Yönlendirme kodlarının farkları için 301 ve 302 yönlendirme rehberimize bakabilirsiniz.

Firefox'un hata sayfası da ek bir ipucu verir: "Bu sorun bazen çerezlerin devre dışı bırakılmasından veya reddedilmesinden kaynaklanabilir." Bazı siteler oturum ya da dil tercihini çereze yazar, çerez okunamazsa kullanıcıyı tekrar aynı adrese gönderir ve döngü bu şekilde oluşur.

Ziyaretçiyseniz: hızlı kontroller

Sorun çoğu zaman sitenin yapılandırmasındadır, ama tarayıcınızda kalmış eski bir çerez veya önbelleğe alınmış bir yönlendirme de hatayı sürdürebilir. Şunları sırayla deneyin:

• Sitenin çerezlerini silin. Chrome Yardım sayfası bu hata için doğrudan çerezleri silmeyi önerir. Tüm geçmişi silmek zorunda değilsiniz; adres çubuğundaki site simgesinden yalnızca o sitenin verilerini temizleyebilirsiniz.
• Gizli pencerede açın. Gizli pencerede site açılıyorsa sorun tarayıcınızdaki çerez veya önbellektir.
• Başka tarayıcı veya cihaz deneyin. Telefonda mobil veriyle de aynı hatayı alıyorsanız sorun büyük ihtimalle sitededir; site sahibine haber verin.
• Çerezleri engelleyen eklentileri kapatın. Çerez engelleyiciler, gizlilik eklentileri veya tarayıcının "üçüncü taraf çerezleri engelle" ayarı oturum çerezine dayanan sitelerde döngüye yol açabilir. Geçici olarak o site için izin verip deneyin.
• Bilgisayarın tarih ve saatini kontrol edin. Saat çok yanlışsa çerezlerin geçerlilik süresi hatalı yorumlanabilir.
• VPN veya proxy kullanıyorsanız kapatıp deneyin. Bazı siteler ülkeye veya IP'ye göre yönlendirme yapar.

Site sahibiyseniz: döngüyü görün, sonra düzeltin

Tahminle kural silmeye başlamadan önce zinciri görmek gerekir. Hangi adresin hangi adrese gittiğini ve yanıtı kimin verdiğini (sunucu mu, CDN mi, WordPress mi) gördüğünüzde çatışan kural genellikle kendini belli eder.

curl ile zinciri izleme

-I (--head) yalnızca başlıkları getirir, -L (--location) ise Location başlığını izler. curl belgesine göre -L ile --head birlikte kullanıldığında zincirdeki her yanıtın başlıkları gösterilir. curl varsayılan olarak en fazla 50 yönlendirme izler; döngüyü görmek için bu sınırı düşürmek işinizi kolaylaştırır:

curl -sIL --max-redirs 10 https://example.com/ | grep -iE "^HTTP|^location|^server"

# Tipik bir döngü çıktısı:
# HTTP/1.1 301 Moved Permanently
# location: https://example.com/
# HTTP/1.1 301 Moved Permanently
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# location: https://example.com/
# curl: (47) Maximum (10) redirects followed

Yukarıdaki örnekte bir kural HTTPS'ye, başka bir kural HTTP'ye gönderiyor. server başlığı ve cf-ray gibi CDN'e özgü başlıklar, yönlendirmeyi kimin ürettiğine dair ipucu verir. Dört olası başlangıç adresini (http/https, www'li/www'siz) ayrı ayrı denemek de iyi bir alışkanlıktır.

Tarayıcı DevTools ile izleme

Chrome'da F12 ile Geliştirici Araçları'nı açın ve Network sekmesine geçin. Preserve log kutusunu işaretleyin; Chrome belgesine göre bu ayar açıkken istekler sayfa yüklemeleri arasında silinmez. Disable cache kutusu da tarayıcı önbelleğini devre dışı bırakır, böylece önbelleğe alınmış eski bir 301 yanıtı sizi yanıltmaz. Sayfayı yenileyin, listedeki her 301/302 isteğine tıklayın ve Headers sekmesindeki Response Headers bölümünde location değerini okuyun.

En sık nedenler ve çözümleri

1. HTTPS iki yerde zorlanıyor

Klasik senaryo şudur: hostingde .htaccess içinde HTTPS yönlendirmesi vardır, üstüne bir SSL eklentisi veya CDN de kendi yönlendirmesini yapar. Kuralların biri yanlış bir koşula bakıyorsa (örneğin proxy arkasında HTTPS'yi hiç göremiyorsa) iki taraf birbirini sonsuza kadar yönlendirir. Çözüm, yönlendirmeyi tek bir katmanda bırakmaktır. Sunucu tarafında yapılması genellikle en temizidir; eklentinin "HTTPS'ye yönlendir" seçeneğini kapatın veya .htaccess kuralını kaldırın, ikisini birlikte tutmayın.

2. www ve www'siz kuralları çatışıyor

Bir kural example.com adresini www.example.com adresine, başka bir yerdeki kural (panel ayarı, eklenti veya CDN sayfa kuralı) tam tersine yönlendiriyorsa döngü oluşur. Hangi adı kanonik kabul edeceğinize bir kez karar verin ve bütün katmanları ona göre ayarlayın: sunucu kuralı, WordPress adresleri, CDN kuralları.

3. WordPress siteurl ve home uyumsuzluğu

WordPress, adres çubuğundaki adres kendi kayıtlı adresiyle eşleşmezse ziyaretçiyi kayıtlı adrese yönlendirir. Sunucu siteyi https://www.example.com adresine yönlendirirken WordPress'te adres http://example.com olarak kayıtlıysa iki taraf birbirine karşı çalışır. Panelde Ayarlar > Genel bölümündeki "WordPress Address (URL)" ve "Site Address (URL)" alanları bu iki değeri tutar; veritabanında siteurl ve home seçenekleridir.

Panele giremiyorsanız WordPress belgesi iki yol gösterir. WP-CLI ile:

wp option get home
wp option get siteurl

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

veya wp-config.php içine sabitleri ekleyerek. Belgeye göre bu sabitler veritabanındaki wp_options değerini geçersiz kılar ama veritabanındaki kaydı değiştirmez; yani adresi koda sabitlemiş olursunuz. Ayrıntılar için wp-config.php sabitleri rehberimize bakın.

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

4. Ters proxy, yük dengeleyici veya CDN arkasında HTTPS algılanamıyor

SSL bağlantısı bir ters proxy, yük dengeleyici veya CDN üzerinde sonlanıyorsa, arka uçtaki sunucu isteği düz HTTP olarak alır. Apache belgesi bunu açıkça yazar: bu durumda %{HTTPS} değişkeni, ziyaretçi HTTPS ile gelmiş olsa bile her zaman "off" döner. PHP tarafında da $_SERVER['HTTPS'] boş kalır. Sonuç: sunucu veya WordPress "bu istek HTTP, HTTPS'ye yönlendireyim" der, proxy yine HTTP ile iletir ve döngü başlar.

Apache belgesinin önerisi, proxy'nin eklediği X-Forwarded-Proto başlığına bakmaktır:

RewriteEngine On
RewriteCond "%{HTTP:X-Forwarded-Proto}" =http [NC]
RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]

WordPress belgesi de aynı durum için wp-config.php'ye şu kodu önerir (wp-settings.php'nin yüklendiği satırdan önce eklenmelidir). Belgedeki notta, bazı kurulumlarda başlığın http,https gibi virgüllü bir liste içerebileceği için "https" geçip geçmediğine bakıldığı belirtilir:

define( 'FORCE_SSL_ADMIN', true );
// in some setups HTTP_X_FORWARDED_PROTO might contain
// a comma-separated list e.g. http,https
// so check for https existence
if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false )
    $_SERVER['HTTPS'] = 'on';

Proxy olarak Nginx kullanıyorsanız, WordPress belgesinin listelediği gibi başlığı arka uca iletmeniz gerekir:

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
}

5. Cloudflare Flexible SSL

Cloudflare belgesine göre Flexible modda Cloudflare, kaynak sunucunuza şifresiz HTTP ile bağlanır. Sunucunuz da tüm HTTP isteklerini HTTPS'ye yönlendiriyorsa döngü oluşur. Belgenin önerdiği çözüm ya kaynak sunucudaki HTTPS yönlendirmesini kaldırmak ya da SSL/TLS şifreleme modunu Full veya daha üstüne almaktır. Tersine, Full modda sunucunuz HTTPS istekleri HTTP'ye yönlendiriyorsa yine döngü oluşur; o zaman sunucudaki HTTP yönlendirmesini kaldırın. Sunucunuzda geçerli bir sertifika varsa (örneğin Let's Encrypt) Full (strict) en güvenli seçenektir.

6. Çerez kaynaklı döngüler

Giriş sayfası, dil seçimi veya yaş doğrulaması gibi akışlar bir çerez yazıp sonraki istekte onu okur. Çerez yazılamıyor veya okunamıyorsa kullanıcı tekrar başa gönderilir. Site HTTPS'e geçtikten sonra çerezin alan adı (www'li/www'siz) veya Secure bayrağı uyumsuz kaldıysa bu tür döngüler görülebilir. Bu durumda hata genellikle tüm ziyaretçilerde değil, belirli tarayıcılarda ve belirli sayfalarda görünür.

Doğru yapılandırma: tek kural, tek adım

Hedef, dört olası giriş adresinin (http, https, www'li, www'siz) tamamını tek adımda kanonik adrese götürmek ve kanonik adresin hiçbir yere yönlendirmemesidir.

Apache (.htaccess)

Apache belgesi, sunucu yapılandırmasına erişiminiz varsa mod_rewrite yerine HTTP sanal sunucusunda Redirect kullanmayı en iyi yöntem olarak önerir. Paylaşımlı hostingde yalnızca .htaccess'e erişiminiz olduğunda ise mod_rewrite uygun araçtır. HTTPS ve www kuralını tek kuralda birleştiren örnek (alan adını kendinizinkiyle değiştirin):

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Bu kuralı .htaccess'in en üstüne, WordPress'in # BEGIN WordPress bloğundan önce koyun ve aynı işi yapan başka bir kural bırakmayın. Proxy veya CDN arkasındaysanız %{HTTPS} yerine yukarıdaki X-Forwarded-Proto koşulunu kullanın. Apache belgesinde ayrıca Let's Encrypt doğrulaması için /.well-known/acme-challenge/ yolunu HTTPS yönlendirmesinden muaf tutan bir tarif de vardır. LiteSpeed kullanan hostinglerde .htaccess kuralları genellikle aynı şekilde çalışır; ayrıntı için hostinginizin belgesine bakın. Daha fazla örnek için Apache .htaccess yönlendirme rehberimize ve WordPress .htaccess kurallarına göz atın.

Nginx

Nginx belgesi, adı kontrol eden if bloğunu "yanlış, hantal ve verimsiz" diye niteler; doğru yol, yönlendirilecek her ad için ayrı bir server bloğu ve return 301 kullanmaktır. HTTPS ve www için:

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

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate ve ssl_certificate_key satırları
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    # ssl_certificate ve ssl_certificate_key satırları
    # sitenin asıl yapılandırması burada; bu blokta yönlendirme yok
}

Değişiklikten sonra nginx -t ile sözdizimini test edip yeniden yükleyin. Ayrıntılar için Nginx yapılandırma rehberimize bakın.

cPanel ve önbellek

cPanel'de alan adı ayarlarında HTTPS yönlendirmesi açıksa, aynı kuralı .htaccess'e ayrıca yazmanız gerekmez; ikisinden birini seçin. Kuralı değiştirdikten sonra LiteSpeed Cache gibi sayfa önbelleklerini ve CDN önbelleğini temizleyin, çünkü önbellekte kalan bir yönlendirme yanıtı eski davranışı sürdürebilir. Bkz. LiteSpeed Cache rehberi.

Sık Sorulan Sorular

Çerezleri sildim ama hata devam ediyor, neden?

Çerez silmek yalnızca tarayıcınızdaki kaynaklı döngüleri çözer. Telefonda veya başka bir ağda da aynı hatayı alıyorsanız döngü sitenin yapılandırmasındadır ve site sahibinin düzeltmesi gerekir.

SSL kurduktan hemen sonra bu hatayı almaya başladım. İlk neye bakmalıyım?

İki şeye: HTTPS'ye birden fazla yerde (.htaccess, eklenti, panel, CDN) zorlayıp zorlamadığınıza ve WordPress adreslerinin https ile güncellenip güncellenmediğine. CDN kullanıyorsanız SSL modunun Flexible olmadığından emin olun.

Hata yalnızca wp-admin'de çıkıyor, site açılıyor. Ne olabilir?

Genellikle FORCE_SSL_ADMIN açıktır ama site proxy veya CDN arkasında olduğu için WordPress isteğin HTTPS olduğunu göremez. WordPress belgesindeki HTTP_X_FORWARDED_PROTO kontrolünü wp-config.php'ye ekleyin. Giriş çerezleriyle ilgili sorunlarda tarayıcı çerezlerini silmek de işe yarar.

Yönlendirmeleri 301 mi 302 mi yapmalıyım?

Kalıcı HTTPS ve www yönlendirmesi için 301 kullanılır; Apache belgesi de R=301 ile kalıcı yönlendirme yapmanın arama motorlarına dizinlerini güncellemelerini söylediğini belirtir. Test aşamasında, tarayıcı önbelleğine takılmamak için geçici olarak 302 kullanıp her şey doğru çalışınca 301'e geçebilirsiniz.

Kaç yönlendirme normaldir?

İdeali sıfır veya bir adımdır. http://example.com adresinden https://www.example.com adresine tek adımda gitmek yerine önce https, sonra www adımı yapılıyorsa bu döngü değildir ama gereksiz bir gecikmedir. Kuralları birleştirmek iki sorunu birden çözer.

Yazılım, tarayıcı ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Mixed content (karma içerik) hatası · SSL sertifika hataları · 301 ve 302 yönlendirme · Apache .htaccess yönlendirme rehberi · Let's Encrypt SSL kurulumu · 500 Internal Server Error