Yönlendirme döngüsü: ERR_TOO_MANY_REDIRECTS nasıl bulunur ve düzeltilir

Bir yönlendirme döngüsü, hiçbir zaman bir yere varmayan bir HTTP yönlendirmeleri zinciridir: URL A tarayıcıyı URL B'ye gönderir, B onu A'ya geri gönderir ve yaklaşık yirmi sıçramadan sonra tarayıcı denemeyi bırakır ve ERR_TOO_MANY_REDIRECTS yazdırır. Hedef sayfada bozuk hiçbir şey yoktur. İki kural, URL'nin nerede yaşaması gerektiği konusunda anlaşamaz ve her biri diğerini geri almaya devam eder.

Döngüye giren bir yönlendirme, doğru şeye baktığınız sürece kendi nedenini kendisi adlandıran nadir web hatalarından biridir. Tarayıcıya değil, hata sayfasına değil ve kesinlikle önbelleğe değil: yönlendirme zincirine. Her sıçrama bir Location üstbilgisi taşır ve tekrar edip duran iki adres, uzlaştırmanız gereken iki kuraldır. Bu yazı, teşhisi tek bir komutla, çözmek zorunda kaldığım hemen hemen her yönlendirme döngüsünün ardındaki nedenleri ve başka bir yerde sessizce ikinci bir döngü yaratmayan düzeltmeyi ele alır. Yönlendirme ailesinin kendisi bulanıksa URL yönlendirme türleri yazısı haritadır; bu ise sorun giderme versiyonudur.

ERR_TOO_MANY_REDIRECTS gerçekte ne anlama gelir

Tarayıcılar sizin adınıza yönlendirmeleri takip eder, ama sonsuza kadar değil. Her istemci bir sıçrama bütçesi tutar ve bu bütçe tükendiğinde isteği terk eder: Chrome 20'de durur ve bunu değiştirmenize izin vermez, Firefox aynı varsayılanı network.http.redirection-limit altında sunar, curl ise şikayet etmeden önce 50'ye izin verir. Standart bu sayıyı açık bırakır. RFC 9110 yalnızca bir istemcinin döngüsel yönlendirmeleri tespit edip müdahale etmesi gerektiğini söyler, bu da spesifikasyonun her tarayıcının bir devre kesiciye ihtiyacı olduğunu söylemenin kibar yoludur.

Bu ayrım teşhis için önemlidir, çünkü hata, bir döngü olduğunu hiç kanıtlamaz. Tekrar içermeyen yirmi bir farklı sıçramadan oluşan bir zincir, sonsuza kadar birbirine sekip duran iki URL ile tamamen aynı mesajı tetikler. İkisini de düzeltmeye değer ama yalnızca birinin uzlaştırılması gereken bir adres çifti vardır. MDN'nin yönlendirme referansı her iki şekli de ele alır ve pratik fark, zinciri yazdırdığınız anda ortaya çıkar.

Hata sayfasının gizlediği bir şey daha var: kalıcı bir yönlendirme tarayıcı tarafından önbelleğe alınır. Döngü 301 yanıtlarından oluşuyorsa, ziyaretçiler siz sunucuyu düzeltseniz bile o önbellek girişi süresi dolana ya da onu temizleyene kadar yerel olarak döngüye girmeye devam eder. Bu tek gerçek, yönlendirme değişikliklerini neden bir 302 ile test edip zincir doğru olduğunda ancak 301'e yükselttiğimin nedenidir; 301 ile 302 yönlendirmeleri yazısı bu alışkanlığın tam gerekçesini sunar.

Yönlendirme zincirini tek bir komutla izleyin

Tarayıcıyı atlayın. Herhangi bir yönlendirme döngüsünü okumanın en hızlı yolu terminaldir, çünkü curl sıçramaları tek bir hata sayfasında birleştirmek yerine her birini yazdırır:

curl -sIL https://example.com | grep -E '^HTTP|^[Ll]ocation'

Sıçrama başına sırayla bir durum satırı ve bir Location üstbilgisi alırsınız. Yukarıdan aşağıya okuyun, üç kalıptan biri ortaya çıkar. Birbirine değişen iki URL, gerçek bir döngü anlamına gelir ve çift, hatalı olan her iki kuralı da adlandırır. Farklı URL'lerden oluşan uzun bir yürüyüş, birinin yıllar içinde üst üste yığdığı ve her sıçraması tek başına meşru olan bir zincir anlamına gelir. Terminalde sorunsuz çözülen ama tarayıcıda hâlâ başarısız olan bir zincir ise döngünün çerez kaynaklı olduğu anlamına gelir, çünkü curl varsayılan olarak hiçbir çerez göndermez.

Bu son durum kendi kontrolünü hak eder, çünkü insanların bir öğleden sonra boyunca DNS'lerini suçlamasına neden olan durum budur:

curl -sIL -c jar.txt -b jar.txt https://example.com/account | grep -E '^HTTP|^[Ll]ocation'

Bir çerez kavanozu eklendiğinde, bir giriş ya da izin döngüsü komut satırında yeniden üretilir; burada hangi uç noktanın oturumu sürekli ayarlayıp sonra reddettiğini gerçekten görebilirsiniz. Tarayıcıda buna karşılık gelen görünüm, sayfa yön değiştirdiğinde önceki sıçramaların silinmesini engelleyen "Preserve log" etkinleştirilmiş Network panelidir. Hiç terminal açmak istemiyorsanız, bağlantı denetleyicimiz zinciri tarayıcıda izler ve her sıçramada durum kodunu yazdırır.

Hemen hemen her yönlendirme döngüsünün ardındaki nedenler

Zinciri görebildiğinizde neden genellikle az sayıdaki olasılıktan biridir. Tekrar eden URL çifti, hangi katmana bakmanız gerektiğini söyler: ileri geri değişen şema TLS sonlandırmasına işaret eder, değişen ana bilgisayar adı bir kanonik ana bilgisayar kuralına işaret eder ve sürekli bir eğik çizgi kazanıp kaybeden bir yol, yeniden yazma sıralamasına işaret eder.

TLS'i sonlandıran bir proxy'nin arkasındaki https kuralları

Bu, modern webdeki en yaygın sonsuz yönlendirmedir ve proxy'ler kaynakların önünde TLS'i sonlandırmaya başladığı anda ortaya çıkmıştır. Proxy, ziyaretçiden gelen bir HTTPS isteğini kabul eder, ardından kaynağınızı düz HTTP üzerinden getirir. Kaynağınız güvensiz bir istek görür, ona söylediğinizi yapar ve HTTPS'e yönlendirir. Proxy bu yönlendirmeyi sunar, tekrar sorulur, kaynağı yine HTTP üzerinden getirir ve döngü böyle devam eder. Cloudflare bu tam hatayı esnek şifreleme modu altında belgeler ve diğer her proxy'de aynı tuzak farklı bir adla vardır.

İki temiz düzeltme vardır. Proxy'yi, kaynağınızla TLS üzerinden konuşacağı full şifreleme moduna geçirin; bu hemen hemen her durumda doğru cevaptır. Ya da kaynağa giden sıçramanın gerçekten düz kalması gerekiyorsa, kaynağın kuralının ham bağlantı yerine X-Forwarded-Proto üstbilgisini okumasını sağlayın, böylece edge'de zaten güvenli olan istekleri yönlendirmeyi durdurur.

www ve apex, hangi ana bilgisayarın kazandığı konusunda anlaşamıyor

Bir kanonik ana bilgisayar kuralı sorun değildir. Farklı zamanlarda farklı kişiler tarafından yazılmış iki tanesi ise bir döngüdür. Klasik versiyonda bir sunucu yapılandırması apex'i www'e gönderirken uygulama yapılandırması www'i apex'e geri gönderir ve ikisi de haklı olduğundan emindir. Bunu zincirde anında görürsünüz: example.com'dan www.example.com'a, oradan tekrar example.com'a, sonsuza kadar.

Bir ana bilgisayar seçin, onu tam olarak tek bir yerde zorunlu kılın ve ikisini uzlaştırmaya çalışmak yerine diğer kuralı silin. Aynısı sondaki eğik çizgi ya da küçük harfe çevirme yeniden yazması için de geçerlidir: iki kural aynı URL'yi zıt yönlerde normalleştirdiğinde, her kural tek başına makul olsa bile bir yönlendirme döngüsü elde edersiniz.

Artık eşleşmeyen CMS ya da uygulama URL ayarı

Çoğu uygulama kendi kanonik adresini saklar ve bu alan, arkadaş canlısı bir isme sahip bir yönlendirme kuralıdır. Alan adını değiştirin, yeni bir ortama taşıyın ya da başka bir ana bilgisayardan bir veritabanı anlık görüntüsü geri yükleyin, uygulama her isteği geri yönlendiren bir adrese yönlendirmeye başlar. Ayar, web sunucusu yapılandırmanızda değil veritabanında yaşadığı için, az önce yaptığınız yapılandırma denetiminden sağ çıkar; bu da onu bulmayı bu kadar sinir bozucu yapan şeydir.

İmza, mevcut ana bilgisayar adınızdan ayrılan ve ona bir daha hiç dönmeyen bir zincirdir. Saklanan adresi gerçekten sunduğunuz alan adına düzeltin, ardından yanlış olanı yakalamış her uygulama ya da sayfa önbelleğini temizleyin.

Yalnızca oturum açmış kullanıcıları etkileyen çerez ve oturum döngüleri

Burada kurallar masumdur ve durum sorunun kaynağıdır. Bir kapı, kimliği doğrulanmamış ziyaretçileri bir giriş sayfasına yönlendirir, giriş sayfası kimliği doğrulanmış olanları geri yönlendirir ve hedef alan adında okunamayan bir oturum çerezi, her iki tarafı da diğerinin bunu ele alması gerektiğine ikna eder. İzin çerezini ayarlayan yönlendirmenin kendisi engellendiğinde izin banner'ları da aynı şekli oluşturur.

İpucu, önceki bölümdekiyle aynıdır: temiz bir gizli pencere çalışır ya da çerez kavanozu olmayan curl normal şekilde çözülür. Çerezin alan adını ve Path kapsamını, Secure ve SameSite özniteliklerini gerçekten sunduğunuz şemaya göre ve apex'te ayarlanıp www'de okunup okunmadığını kontrol edin.

Zincir ekranda olduğunda yönlendirme döngüleri nadiren gizemlidir, ama izlemek yerine tahmin ettiğinizde bir öğleden sonranızı yer. Yönlendirme katmanıyla tartışmak yerine ona sahip olmayı tercih ediyorsanız, Elido'nun ücretsiz planı size hedefi yeniden yönlendirebileceğiniz tek bir saklanan değer olan ve her sıçraması günlüğe kaydedilen bağlantılar verir.

İkinci bir döngü yaratmadan düzeltin

Onarımın kendisi kısadır ve sıra, sözdiziminden daha önemlidir. Bir kuralı değiştirin, sonra yeniden izleyin. Üçünü değiştirip yeniden yüklemek, hangisinin önemli olduğu konusunda size hiçbir şey söylemez ve bir ekibin, ilk denemede zaten düzelttikleri bir kuralın neden olduğu bir döngüde bu şekilde bir saat harcadığını izledim.

1. Zincirin adlandırdığı iki kuraldan tam olarak birini kaldırın ya da tersine çevirin, böylece bir istek tek bir sıçramada 200e ulaşabilsin.
2. curl -sIL izlemesini yeniden çalıştırın ve zincirin artık en fazla bir yönlendirme olduğunu, tekrarlanan bir ana bilgisayar adı olmadığını doğrulayın.
3. Tarayıcının önbelleğini temizleyin ya da gizli bir pencerede test edin, çünkü daha önce sunduğunuz herhangi bir 301 hâlâ yerel olarak önbelleğe alınmıştır ve artık var olmayan bir başarısızlığı taklit eder.
4. Yalnızca o zaman, zincirin şekli oturduktan sonra geçici yönlendirmeleri kalıcı olanlara yükseltin.

Bu listenin sonunda iki tuzak vardır. HSTS bunlardan biridir: bir ana bilgisayar bir Strict-Transport-Security üstbilgisi gönderdikten sonra tarayıcılar her isteği kendiliğinden HTTPS'e yükseltir, bu yüzden HTTPS'i de zorlayan bir kaynak kuralı artık gereksizdir ve HSTS girişini temizlemeden yeniden üretemeyeceğiniz bir döngüye bir proxy yanlış yapılandırmasını dönüştürebilir. Diğeri ise döngünün önündeki önbelleklemedir. Bir 301'i önbelleğe almış bir CDN, kaynak onu göndermeyi bıraktıktan sonra bile onu sunmaya seve seve devam eder; bu yüzden temizleme, düzeltmeden sonra değil düzeltmenin bir parçası olmalıdır. Hiç döngüye girmeyen uzun zincirleri de aynı geçişte kısaltmaya değer: her ekstra sıçrama, bir sorgu dizesinin düşmesi için bir şans daha demektir ki bu tam olarak UTM parametrelerinin GA4'te kaybolma şeklidir ve kısa bağlantıların SEO'ya zarar vermek zorunda olmamasının nedeninin bir parçasıdır, tabii tek bir sıçrama derinliğinde kaldıkları sürece.

Döngü bir kısa bağlantıdaysa

Kısa bağlantılar, bir döngünün oluşabileceği bir yer daha ekler ve bu, kısaltıcının yönlendirmesi değildir. Kısa bağlantı, saklanan tek bir sıçramadır: slug girer, hedef çıkar. Döngü, hedef geri işaret ettiğinde ortaya çıkar ki bu, kulağa geldiğinden daha sık olur. Biri bir kampanya bağlantısını bir açılış sayfasına işaret edecek şekilde düzenler, açılış sayfasında geçen çeyrekte kanonik paylaşım adresi o olduğu için kısa URL'ye yönlendiren eski bir kural vardır ve şimdi ikisi birbirine sekiyor. Her iki sıçrama da tam olarak yapılandırıldığı gibi davranıyor.

Aynı zincirde iki varyant daha ortaya çıkar. Biri, genellikle hedef sütununun son URL'ler yerine kısa URL'ler içerdiği bir e-tablo içe aktarımından kaynaklanan, toplu bir düzenlemeden sonra birbirine işaret eden bir kısa bağlantı çiftidir. Diğeri, bir bağlantı sorunundan çok bir DNS artığı olan, hâlâ kısaltıcıya geri yönlendiren bir ana bilgisayara çözülen özel bir alan adıdır ve kısa bağlantılar için özel alan adları yazısı kayıtların nasıl görünmesi gerektiğini ele alır. Her üç durumda da düzeltme, hedefi başka bir yönlendirmeye değil son sayfaya ayarlamaktır; bunu, zaten basılmış ya da yayımlanmış hiçbir şeye dokunmadan yapabilirsiniz.

Hedef, URL'nin içine gömülü olmak yerine saklandığı için bunların hiçbiri yeniden basım gerektirmez. Yönetilen bağlantıların bütün gerekçesi budur ve kısa bağlantı çalışmıyor yazısı, belirti özellikle bir döngü olmadığında kullanılacak daha geniş bir triyaj rehberidir.

Bir sonrakinin yayına girmesini engelleyin

Yönlendirme döngüleri bir yapılandırma kayması hatasıdır, bu yüzden kalıcı düzeltmeler sıkıcı olanlardır. Kanonik ana bilgisayar kararını tek bir yerde tutun ve şemaya ya da ana bilgisayar adına dokunan herhangi bir ikinci kuralı görür görmez bir hata olarak ele alın. Biri boş bir sayfa bildirmeden önce değil, yeni yönlendirmeleri duyurmadan önce curl -sIL ile izleyin. Bağlantılar gelir için önemliyse üzerlerine bir kontrol koyun: zincir bir sıçramanın ötesine büyüdüğünde başarısız olan zamanlanmış bir izleme, kaymayı bir müşteri fark etmeden çok önce yakalar ve bağlantı yönlendirmelerini izleme yazısı bunun gerçek uyarıya nasıl bağlandığını gösterir.

Daha geniş alışkanlık, hedefleri denetleyebileceğiniz veriler olarak ele almaktır. Bağlantı çürümesini önleme yazısı, sessizce çözülmeyi durduran bağlantılar için aynı disiplini ele alır ve her iki durumda da aynı haftalık kontroldür. Dürüst olmak gerekirse, gördüğüm çoğu döngü, aynı sorunu bir ay arayla farklı bir katmanda düzelten iki yetkin kişi tarafından yayına sokulmuştu. Kuralı bir kez yazın, döngü mümkün olmaktan çıksın.

Temel yazı dizisini okuyun

Bu yazı mühendislik kümesinde yer alır. Yönlendirme yolunun şeklinin kendisi için yönlendirmelerde p95'i 15ms'nin altına indirme yazısı tek, düzgün davranan bir sıçramanın maliyetini ele alır, URL yönlendirme türleri yazısı ise kuralları üst üste yığmaya başlamadan önce hangi durum kodunun nereye ait olduğunu ele alır.

Blogda ilgili yazılar

• URL yönlendirme türleri: 301, 302, 307, 308 ve daha fazlası
• 301 ile 302 yönlendirmeleri: kısa bağlantılar hangisini kullanmalı
• Kısa bağlantı çalışmıyor mu? Tek bir komutla teşhis edin
• Özel alan adlı kısa bağlantılar: DNS, TLS ve edge
• Açık yönlendirme güvenlik açıkları ve bunları önleme yolları
• Sentry ve Datadog ile kısa bağlantı izleme