Çok Fazla Yönlendirme (ERR_TOO_MANY_REDIRECTS) Hatası Çözümü

Siteyi açıyorsunuz, adres çubuğu bir an titriyor ve tarayıcı pes ediyor: "ornek.com sizi çok fazla kez yönlendirdi — ERR_TOO_MANY_REDIRECTS". Yönetim paneline girmeyi deniyorsunuz, orası da aynı hatayı veriyor. Site tamamen erişilemez durumda ve hiçbir hata sayfası, hiçbir PHP çıktısı yok — çünkü sunucu bir içerik üretmiyor, sadece tekrar tekrar "başka bir adrese git" diyor. Çok fazla yönlendirme hatası, tarayıcının bu sonsuz döngüyü fark edip zinciri kestiğini gösterir.

Bu hatanın Türkçe kaynaklarda hakkı verilmemiş bir sebebi var: Cloudflare'ın "Flexible" SSL modu ile sunucudaki HTTPS yönlendirmesinin çakışması. Türkiye'de Cloudflare kullanımı bu kadar yaygınken, arama sonuçlarında bu senaryoyu anlatan neredeyse hiçbir Türkçe sayfa yok; kullanıcı doğrudan İngilizce kaynaklara düşüyor. Bu yazıda önce döngüyü görünür hâle getireceğiz, sonra en sık dört kaynağı — Cloudflare SSL modu, WordPress adres ayarları, .htaccess kuralları ve çerez tabanlı oturum döngüleri — tek tek eleyeceğiz. Panele giremediğiniz durumlar için de acil kurtarma adımları var.

Yönlendirme Döngüsü Nedir, Tarayıcı Neden Duruyor#

Yönlendirme döngüsü, A adresinin B'ye, B'nin de doğrudan ya da dolaylı olarak tekrar A'ya yönlenmesidir. Sunucu her istekte 301 veya 302 durum kodu ve bir Location başlığı döndürür; tarayıcı bu başlığı takip eder, yeni adrese gider, oradan da yeni bir yönlendirme alır. Bu süreç teorik olarak sonsuza kadar sürebileceği için tarayıcılar bir üst sınır koyar — Chrome'da bu sınır 20 civarındadır — ve aşıldığında isteği iptal edip ERR_TOO_MANY_REDIRECTS gösterir.

Kritik nokta şudur: sunucuda hata yoktur. Sunucu, kendisine sorulan her soruya kusursuz biçimde "şuraya git" cevabı verir. Bu yüzden PHP hata kaydında hiçbir şey görmezsiniz ve 500 hatası aramak boşunadır. Hatanın kanıtı erişim kayıtlarındadır: aynı IP'nin saniyeler içinde aynı yolu 20 kez istediğini görürsünüz. cPanel'de bu kayıtlara nasıl ulaşacağınız cpanel hata kayıtları yazısında anlatılıyor.

Döngüyü Görmek: curl ile Yönlendirme Zincirini Okuma#

Tahmin yürütmeden önce zinciri gözünüzle görün. Bu, teşhis süresini dakikalara indiren tek adımdır:

curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://ornek.com

Daha okunaklı bir çıktı için başlıkları doğrudan izleyin:

curl -sIL --max-redirs 10 https://ornek.com | grep -i -E "^HTTP/|^location:"

Tipik bir Cloudflare Flexible döngüsünde çıktı şuna benzer:

HTTP/2 301
location: https://ornek.com/
HTTP/2 301
location: https://ornek.com/
HTTP/2 301
location: https://ornek.com/

Aynı adrese aynı adres tekrar tekrar yönleniyorsa, sunucu isteğin zaten HTTPS olduğunu göremiyor demektir. Bu, aşağıdaki Cloudflare senaryosunun imzasıdır. Eğer çıktı http:// ile https:// arasında ya da www ile wwwsuz arasında gidip geliyorsa, kural çakışması vardır. curl ile HTTP başlıklarını okumaya alışkın değilseniz curl ile http istekleri yazısı temel kullanımı gösteriyor.

En Sık Sebep: Cloudflare Flexible SSL ile Sunucu HTTPS Yönlendirmesi Çakışması#

Bu, Türkçe kaynaklarda anlatılmayan ama pratikte en sık karşılaşılan senaryodur ve mekanizması şudur:

Cloudflare'ın Flexible SSL modunda ziyaretçi ile Cloudflare arasındaki bağlantı HTTPS'tir, ancak Cloudflare ile sizin sunucunuz arasındaki bağlantı düz HTTP olarak kurulur. Sunucunuzda ise "HTTP gelirse HTTPS'e yönlendir" kuralı vardır. Sonuç:

1. Ziyaretçi https://ornek.com ister.
2. Cloudflare bunu sunucuya http://ornek.com olarak iletir.
3. Sunucu "bu HTTP, HTTPS'e yönlendireyim" der ve 301 → https://ornek.com döndürür.
4. Cloudflare bu yönlendirmeyi ziyaretçiye iletir, ziyaretçi tekrar https://ornek.com ister.
5. Adım 2'ye dönülür. Döngü kapanmıştır.

Çözüm, SSL modunu sunucunuzun gerçek yapılandırmasıyla eşleştirmektir:

Doğru kurulum neredeyse her zaman Full (strict) modudur: sunucuda geçerli bir sertifika bulundurup Cloudflare'ın uçtan uca şifreli bağlanmasını sağlarsınız. Ücretsiz sertifika kurulumu için Let's Encrypt ücretsiz SSL yazısındaki adımlar yeterlidir; cPanel'de zaten otomatik kurulum vardır ve autossl nedir yazısında anlatılıyor.

Flexible modunda kalmak zorundaysanız (sunucuya sertifika kuramıyorsanız), sunucudaki HTTPS yönlendirme kuralını kaldırın ve yönlendirmeyi Cloudflare tarafındaki "Always Use HTTPS" seçeneğine bırakın. İkisini aynı anda açık bırakmak döngüyü garanti eder.

Sunucu Tarafında Doğru Koşul Nasıl Yazılır#

Cloudflare arkasındayken orijinal protokolü X-Forwarded-Proto başlığından okumanız gerekir. Apache'de doğru yönlendirme kuralı şudur:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteCond %{HTTP:CF-Visitor} !'"scheme":"https"'
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Nginx tarafında karşılığı:

if ($http_x_forwarded_proto = "http") {
    return 301 https://$host$request_uri;
}

Bu kurallar %{HTTPS} off koşulundan farklıdır: %{HTTPS} sunucuya gelen bağlantının protokolüne bakar ve Cloudflare arkasında her zaman off döner — döngünün kaynağı tam olarak budur. Yönlendirme kurallarının genel mantığı için https yönlendirme yazısına bakabilirsiniz.

WordPress Adres Ayarları Yanlışsa#

WordPress'te siteurl ve home seçenekleri sitenin kendi adresini nasıl bildiğini belirler. Bu iki değerden biri yanlışsa WordPress her istekte ziyaretçiyi "doğru" saydığı adrese yönlendirir ve o adres de tekrar aynı yere gelirse döngü oluşur. En klasik hâli: siteurl alanında https:// yazarken sunucuda HTTPS çalışmıyor olması ya da www uyumsuzluğu (home alanında wwwsuz, .htaccess kuralında wwwlu).

Panele giremediğiniz için ayarları arayüzden düzeltemezsiniz. İki yolunuz var.

Yol 1 — wp-config.php ile geçici sabitleme. Dosyayı FTP ya da cPanel Dosya Yöneticisi ile açıp /* That's all, stop editing! */ satırının üstüne ekleyin:

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

Bu tanımlar veritabanındaki değerleri ezer ve döngüyü anında keser. Panele girdikten sonra Ayarlar → Genel ekranından değerleri düzeltip bu iki satırı kaldırın; kalıcı bırakırsanız Ayarlar ekranındaki alanlar gri kalır.

Yol 2 — Doğrudan veritabanından. phpMyAdmin'de SQL sekmesinden:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl','home');

UPDATE wp_options SET option_value = 'https://ornek.com'
WHERE option_name IN ('siteurl','home');

Tablo öneki wp_ olmayabilir; wp-config.php içindeki $table_prefix değerini kontrol edin. Adres değişikliğinin tüm veritabanı etkilerini görmek isterseniz wordpress site adresi yanlış değiştirildi yazısı tam bu senaryoyu ele alıyor.

htaccess'te Çakışan www ve HTTPS Kuralları#

.htaccess dosyasına zaman içinde eklenen kurallar birbiriyle çelişir hâle gelir. En sık gördüğüm çakışma, bir kuralın www eklemesi diğerinin kaldırmasıdır:

 # Yanlış: iki kural birbirini iptal ediyor
RewriteRule ^(.*)$ https://www.ornek.com/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

Doğru yaklaşım, tek bir kanonik hedef belirleyip tüm varyantları oraya tek seferde yönlendirmektir:

RewriteEngine On

 # Hem www hem protokol tek adımda normalleştirilir
RewriteCond %{HTTP:X-Forwarded-Proto} =http [OR]
RewriteCond %{HTTP_HOST} !^ornek\.com$ [NC]
RewriteRule ^(.*)$ https://ornek.com/$1 [R=301,L]

Kuralı yayına almadan önce curl ile test edin. .htaccess kural mantığının tamamı htaccess yönlendirme yazısında ele alınıyor.

Bir şey daha: dizin bazlı .htaccess dosyaları birikir. Alt dizinlerde unutulmuş bir Redirect satırı üst dizindeki kuralla çelişebilir. Şüpheliyseniz sırayla bakın:

find /home/kullanici/public_html -name ".htaccess" -exec echo "== {}" \; -exec cat {} \;

Kök .htaccess dosyasını .htaccess_yedek olarak yeniden adlandırıp siteyi test etmek, sorunun bu dosyada olup olmadığını on saniyede söyler. WordPress'te dosya silinirse panele girip Kalıcı Bağlantılar ekranında "Değişiklikleri kaydet" demeniz yeterlidir; WordPress dosyayı yeniden üretir.

Nginx Tarafında Döngü#

Nginx kullanıyorsanız döngü genelde iki server bloğunun birbirine yönlendirmesinden çıkar. Klasik hata, HTTPS bloğunun içine yine HTTPS yönlendirmesi koymaktır:

 # Yanlış: 443 bloğunun içinde tekrar https'e yönlendirme
server {
    listen 443 ssl;
    server_name ornek.com;
    return 301 https://$host$request_uri;   # sonsuz döngü
}

Doğrusu, yönlendirmeyi yalnızca 80 portundaki blokta yapmaktır:

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

server {
    listen 443 ssl http2;
    server_name www.ornek.com;
    return 301 https://ornek.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name ornek.com;
    root /var/www/ornek.com;
    # uygulama yapılandırması
}

Ters vekil (reverse proxy) kullanıyorsanız arka uca doğru protokolü iletmeyi unutmayın; aksi hâlde arka uçtaki uygulama isteği HTTP sanıp kendi yönlendirmesini üretir:

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;

Ayrıntılı yapılandırma için nginx reverse proxy yapılandırma yazısına bakın.

Çerez ve Oturum Kaynaklı Döngüler#

Bazı döngüler yönlendirme kuralından değil, uygulamanın oturum mantığından doğar. En tanıdık örneği WordPress'te wp-admin ile wp-login.php arasında gidip gelen döngüdür: kullanıcı giriş yapar, WordPress panele yönlendirir, panel oturumu tanımaz ve tekrar giriş ekranına atar.

Bu durumun tipik sebepleri:

• Çerez alan adı uyumsuzluğu. wp-config.php içinde eski bir COOKIE_DOMAIN tanımı kalmış olabilir. Alan adı değiştiyse bu satırı kaldırın.
• Tarayıcı çerezleri. Site için kayıtlı eski çerezler bozulmuş olabilir; tarayıcıda o siteye ait çerezleri silin ve gizli sekmede deneyin. Gizli sekmede açılıyorsa sebep çerezdir.
• Önbellek eklentisi. Bir sayfa önbelleği, yönlendirme cevabını (301) önbelleğe almış olabilir ve düzelttikten sonra bile eski cevabı sunar. Eklenti önbelleğini ve varsa sunucu önbelleğini temizleyin.
• Cloudflare önbelleği. Cloudflare panelinde "Purge Everything" yapın; ayrıca test sırasında "Development Mode" açmak önbelleği tamamen devre dışı bırakır ve değişikliklerinizin etkisini anında görmenizi sağlar.

Panele hiç giremiyorsanız eklentileri FTP üzerinden devre dışı bırakabilirsiniz: wp-content/plugins klasörünü plugins_kapali olarak yeniden adlandırın. Site açılıyorsa klasör adını geri alıp eklentileri tek tek etkinleştirerek suçluyu bulun. Bu yöntemin detayı wordpress admin paneline giremiyorum yazısında.

HSTS Açıkken Testleri Neden Yanıltır#

Sitenizde HSTS (Strict-Transport-Security) başlığı yayınlanıyorsa, tarayıcı o alan adını belirtilen süre boyunca yalnızca HTTPS üzerinden ziyaret eder. Bu, yönlendirme döngüsü teşhisinde iki yanıltıcı etki yaratır. Birincisi, http://ornek.com adresini elle yazsanız bile tarayıcı sunucuya hiç sormadan HTTPS'e geçer; yani "HTTP tarafında ne oluyor" sorusunu tarayıcıdan cevaplayamazsınız. İkincisi, döngüyü çözdükten sonra bile tarayıcı içsel yönlendirmeyi uygulamaya devam eder ve sorun sürüyormuş gibi görünür.

Bu yüzden HSTS açıkken teşhisi tarayıcıyla değil curl ile yapın — curl bu politikayı uygulamaz ve sunucunun gerçek cevabını gösterir:

curl -sI http://ornek.com | grep -i -E "^HTTP/|^location:|^strict-transport"

Chrome'da bir alan adının HSTS kaydını temizlemek gerekirse chrome://net-internals/#hsts ekranındaki "Delete domain security policies" alanına alan adını yazıp silebilirsiniz. Başlığın nasıl çalıştığı ve max-age değerinin sonuçları için hsts nedir yazısına bakın; HSTS'i yayına almadan önce HTTPS yapılandırmanızın kesinlikle sağlam olması gerekir, çünkü geri dönüşü tarayıcı önbelleği süresince mümkün değildir.

Acil Kurtarma Sırası#

Panele giremediğiniz ve zaman baskısı altında olduğunuz durumlar için sıralı bir kurtarma listesi:

1. Cloudflare'ı geçici olarak bypass edin. DNS kaydındaki turuncu bulut simgesini gri yapın (DNS only). Site açılıyorsa sorun kesinlikle Cloudflare yapılandırmasındadır ve SSL moduna bakacaksınız.
2. .htaccess dosyasını yeniden adlandırın. Site açılıyorsa sorun kural çakışmasındadır.
3. wp-config.php'ye WP_HOME ve WP_SITEURL sabitlerini ekleyin. Site açılıyorsa sorun veritabanındaki adres değerlerindedir.
4. Eklentiler klasörünü yeniden adlandırın. Site açılıyorsa sorun bir eklentidedir.
5. Erişim kayıtlarına bakın. Hâlâ döngü varsa access_log içinde aynı yolun art arda 301 aldığını görüp Location hedefinden kuralın nereden geldiğini çıkarın.

Her adımdan sonra tarayıcı çerezlerini silin ve gizli sekmede test edin; aksi hâlde düzelttiğiniz hâlde eski çerez yüzünden hatayı görmeye devam edebilirsiniz.

Sıkça Sorulan Sorular#

ERR_TOO_MANY_REDIRECTS hatası sunucu arızası mı#

Hayır, bu bir sunucu arızası değil yapılandırma hatasıdır. Sunucu tamamen çalışır durumdadır ve kendisine gelen her isteğe düzgün bir yönlendirme cevabı döndürür; sorun bu yönlendirmelerin birbirini işaret ederek kapalı bir halka oluşturmasıdır. Bu yüzden PHP hata kaydında ya da sistem günlüklerinde bir çökme izi bulamazsınız. Kanıtı erişim kaydında aynı adresin art arda 301 alması olarak görürsünüz.

Site açılmıyor ama yönetim paneline de giremiyorum, ne yapmalıyım#

Yönetim paneli de aynı yönlendirme zincirine takıldığı için erişim FTP veya dosya yöneticisi üzerinden olmalıdır. Önce .htaccess dosyasını yeniden adlandırıp siteyi test edin, sonra wp-config.php içine WP_HOME ve WP_SITEURL sabitlerini ekleyin. Cloudflare kullanıyorsanız DNS kaydını geçici olarak gri buluta çekmek en hızlı testtir. Bu üç adımdan biri neredeyse her zaman paneli geri açar.

Cloudflare SSL modunu hangi seçeneğe almalıyım#

Sunucunuzda geçerli bir SSL sertifikası varsa Full (strict) modunu seçmelisiniz. Bu mod hem ziyaretçi ile Cloudflare arasını hem de Cloudflare ile sunucunuz arasını şifreler ve sunucudaki HTTPS yönlendirmesiyle çakışmaz. Flexible modu yalnızca sunucuda hiç sertifika yoksa geçicidir ve o durumda sunucudaki HTTPS yönlendirme kuralını kaldırmanız şarttır. Flexible ile sunucu yönlendirmesini birlikte kullanmak sonsuz döngünün en yaygın sebebidir.

Yönlendirme döngüsünü nasıl görebilirim#

Terminalden curl -sIL --max-redirs 10 https://ornek.com | grep -i -E "^HTTP/|^location:" komutuyla zincirin tamamını görebilirsiniz. Çıktıda aynı adresin tekrar tekrar kendisine yönlendiğini ya da iki adres arasında gidip geldiğini net biçimde okursunuz. Aynı adres kendine yönleniyorsa protokol bilgisi sunucuya yanlış ulaşıyordur, iki adres arasında gidip geliyorsa kural çakışması vardır. Bu tek komut, tahminle geçirilecek saatleri ortadan kaldırır.

htaccess dosyasını sildim, siteme zarar verir mi#

WordPress kullanıyorsanız zarar vermez, çünkü WordPress bu dosyayı yeniden üretebilir. Panele girdikten sonra Ayarlar → Kalıcı Bağlantılar ekranında hiçbir şey değiştirmeden "Değişiklikleri kaydet" düğmesine basmanız yeterlidir. Yine de dosyayı silmek yerine .htaccess_yedek şeklinde yeniden adlandırmak daha güvenlidir; içinde özel yönlendirmeler ya da güvenlik kuralları olabilir. Özelleştirilmiş kurallarınız varsa yedeği açıp tek tek geri taşıyın.

Sadece bazı sayfalarda döngü var, sitenin geri kalanı çalışıyor#

Bu durumda sorun genel bir protokol yönlendirmesi değil, o sayfalara özel bir kuraldır. Bir SEO eklentisiyle tanımlanmış 301 yönlendirmesi, eski bir URL yapısından yenisine geçerken kurulan kural ya da o dizindeki ayrı bir .htaccess dosyası muhtemel kaynaklardır. Yönlendirme eklentisinin listesini açıp hedef adresin kaynak adresle aynı olup olmadığına bakın. Sunucuda tüm .htaccess dosyalarını taramak da çakışan kuralı bulmanın hızlı yoludur.

Düzelttim ama hata devam ediyor, sebebi ne olabilir#

Büyük olasılıkla önbellek ya da çerez kaynaklıdır. Tarayıcılar 301 yönlendirmelerini kalıcı sayıp önbelleğe alır; bu yüzden düzeltmenizden sonra bile eski yönlendirmeyi uygularlar. Tarayıcı çerezlerini o site için silin ve gizli sekmede test edin. Cloudflare kullanıyorsanız "Purge Everything" yapın; sunucuda veya eklentide sayfa önbelleği varsa onu da temizleyin.

Kapanış#

Çok fazla yönlendirme hatası, kaynağı bir kez görüldüğünde hızlıca kapanan ama körlemesine denemeyle saatler yiyebilen bir arızadır. Yöntem sabittir: önce curl ile zinciri görün, sonra döngünün tipine bakın. Aynı adresin kendine yönlenmesi protokol bilgisinin sunucuya yanlış ulaştığını — yani Cloudflare SSL modu çakışmasını — gösterir; iki adres arasında gidip gelme ise .htaccess ya da WordPress adres ayarlarındaki çakışmayı işaret eder. Kalıcı çözüm her zaman tek bir kanonik adres belirleyip yönlendirmeyi tek noktada yapmaktır.

Bu tür yapılandırma çakışmalarıyla uğraşmak istemiyorsanız, sertifikanın otomatik kurulup yenilendiği ve HTTPS yönlendirmesinin panelden tek tıkla ayarlandığı bir ortam işi ciddi biçimde sadeleştirir: WordPress hosting paketlerinde bu yapılandırma hazır gelir, SSL sertifikası tarafında ise Full (strict) moduna uygun geçerli bir sertifikayı kurulumuyla birlikte alırsınız. Kendi sunucusunu yöneten ekipler için sunucu yönetimi hizmeti Nginx/Apache yönlendirme kurallarını, ters vekil başlıklarını ve Cloudflare arkasındaki protokol yapılandırmasını tek elden üstlenir — yani bu yazıdaki dört senaryonun da kalıcı olarak kapanmasını sağlar.