NGINX Teknik Rehberi

NGINX Çok Fazla Yönlendirme ve Internal Redirect Cycle Hatası

Yönlendirme döngüsü, tarayıcıda URL’ler arasında tekrarlanan 301/302 zinciri veya NGINX içinde aynı URI’nin yeniden işlenmesi şeklinde ortaya çıkar. HTTPS, www, reverse proxy, uygulama URL’si ve rewrite bayrakları birlikte incelenmelidir.

ERR_TOO_MANY_REDIRECTSRewrite CycleHTTPSX-Forwarded-ProtoCloudflare

Hızlı Teşhis NGINX Desteği

root@sunucu:~SSH

2026/07/17 04:11:31 [error] 2418#2418: *1411 rewrite or internal redirection cycle while internally redirecting to "/index.php"
HTTP/2 301
location: https://example.com/

İstek akışıİstemci, NGINX ve backend arasındaki kopma noktası

YapılandırmaEtkin server ve location bloklarının doğrulanması

Canlı teşhisLog, socket, port ve servis kontrolleri

Güvenli uygulamaTest, kontrollü reload ve sonuç doğrulaması

Teknik açıklama

NGINX yönlendirme döngüsü ne anlama gelir?

Tarayıcı redirect loop’unda istemci ardışık 3xx cevaplarla URL’ler arasında gidip gelir. Internal redirection cycle ise NGINX’in location/rewrite işlemleri içinde aynı URI’yi tekrar eşlemesidir.

HTTP→HTTPS ve www→non-www gibi kanonik yönlendirmeler tek bir açık kuralla yapılmalıdır. Bir server bloğu www’ye, uygulama non-www’ye döndürürse sonsuz döngü oluşur.

Reverse proxy arkasında uygulama gerçek istemci şemasını görmeyebilir. X-Forwarded-Proto doğru aktarılmazsa uygulama HTTPS isteğini HTTP sanıp tekrar HTTPS’e yönlendirebilir.

Cloudflare Flexible SSL, ziyaretçi ile Cloudflare arasında HTTPS fakat Cloudflare ile origin arasında HTTP kullanır. Origin zorunlu HTTPS yönlendirmesi yapıyorsa döngü oluşabilir.

NGINX rewrite modülü URI değiştiğinde location aramasını tekrarlar ve döngü sınırlıdır. Yanlış last, try_files veya error_page hedefi sonunda 500 internal cycle hatası verebilir.

301 cevapları tarayıcı ve CDN tarafından cache’lenebilir; düzeltme testlerinde önce curl ile zinciri görün, gerektiğinde geçici 302 kullanın.

Log mesajları ve anlamları

Redirect loop ve internal cycle mesajları

E-postada, tarayıcıda veya SSH günlüğünde gördüğünüz ifadeyi aratın. Her kartta anlam, muhtemel neden ve güvenli ilk işlem bulunur.

8 kayıt

01kritik

ERR_TOO_MANY_REDIRECTS

Anlamı: Tarayıcı çok sayıda dış yönlendirme takip etti.

Muhtemel neden: HTTP/HTTPS, www, uygulama veya proxy kuralları çakışıyor.

curl -IL ile Location zincirini çıkarın.

02kritik

rewrite or internal redirection cycle

Anlamı: NGINX aynı URI’yi iç yönlendirmede tekrar tekrar işliyor.

Muhtemel neden: Yanlış rewrite last, try_files veya error_page hedefi.

Logdaki hedef URI ve ilgili location bloklarını inceleyin.

03uyari

redirected you too many times

Anlamı: Tarayıcı genel redirect loop mesajıdır.

Muhtemel neden: Sunucu, uygulama, CDN veya cookie bazlı yönlendirme.

Cookiesiz curl ile server-side zinciri doğrulayın.

04uyari

301 Moved Permanently loop

Anlamı: Kalıcı yönlendirme karşılıklı iki URL üretir.

Muhtemel neden: www/non-www veya slash politikası çakışması.

Her adımın Location değerini kaydedin.

05uyari

HTTP to HTTPS redirect loop

Anlamı: Origin ve proxy şema bilgisi uyuşmuyor.

Muhtemel neden: X-Forwarded-Proto eksik veya Flexible SSL.

Origin’e gelen header’ları ve CDN SSL modunu kontrol edin.

06bilgi

cycle while processing error page

Anlamı: Hata sayfası kendisi aynı hatayı yeniden üretiyor.

Muhtemel neden: error_page hedefi erişilemez veya aynı location’a dönüyor.

Error page URI’sini bağımsız test edin.

07bilgi

WordPress too many redirects

Anlamı: WordPress home/siteurl ile NGINX kanoniği farklı.

Muhtemel neden: HTTP/HTTPS veya www uyumsuzluğu.

Veritabanı URL’leri ve proxy header’larını karşılaştırın.

08bilgi

HSTS nedeniyle sürekli HTTPS

Anlamı: Tarayıcı NGINX’e ulaşmadan HTTP’yi HTTPS’e yükseltir.

Muhtemel neden: Önceden gönderilmiş HSTS politikası.

curl ve farklı hostname ile sunucu davranışını izole edin.

Bu ifadeyle eşleşen kayıt bulunamadı.

Güvenli ilk inceleme

SSH teşhis komutları ve hangi çıktıya bakılmalı?

Komutlar root erişimi içindir. Önce yalnızca durum ve log toplayın; nedeni görmeden kalıcı ayar değiştirmeyin.

Yönlendirme zinciri

curl -skIL --max-redirs 15 https://example.com/ | grep -Ei 'HTTP/|location:'

Her 3xx adımını ve hedef URL’yi gösterir.

Rewrite ve return kuralları

nginx -T | grep -nE 'server_name|return 30[1278]|rewrite |try_files|error_page|X-Forwarded-Proto'

Döngü oluşturabilecek etkin yönergeleri listeler.

Origin/proxy karşılaştırması

curl -skI https://example.com/
curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/

CDN veya reverse proxy katmanını ayırır.

Rewrite logu

grep -R 'rewrite or internal redirection cycle' /var/log/nginx 2>/dev/null | tail -n 50

Internal cycle hedefini ve isteği bulur.

WordPress URL kontrolü

wp option get home --path=/var/www/example
wp option get siteurl --path=/var/www/example

Uygulama kanonik URL’sini NGINX ile karşılaştırır.

Test ve reload

nginx -t && systemctl reload nginx
curl -skIL --max-redirs 10 https://example.com/

Düzeltme sonrası zincirin sonlandığını doğrular.

Barındırma ortamına göre

Ubuntu/Debian, AlmaLinux/CloudLinux ve Plesk kontrolleri

NGINX hatasının temel nedeni aynı olsa da paket yolları, servis adları, güvenlik katmanları ve sanal host yönetimi kullanılan Linux dağıtımına veya Plesk altyapısına göre değişir.

Ubuntu / Debian

NGINX Too Many Redirects için systemd, paket yolu ve journald kontrolleri.

Önce etkin NGINX yapılandırmasını ve servis durumunu doğrulayın.
Domain error logu ile systemd günlüğünü aynı zaman aralığında karşılaştırın.
Değişiklikten önce nginx -t, ardından kesintisiz reload uygulayın.

curl -skIL --max-redirs 15 https://example.com/
nginx -T | grep -nE 'return 30|rewrite |X-Forwarded-Proto'

AlmaLinux / CloudLinux

NGINX Too Many Redirects için SELinux, PHP-FPM pool ve RHEL tabanlı servis kontrolleri.

NGINX ve ilgili backend servislerinin aktif durumunu kontrol edin.
SELinux AVC kayıtlarını ve güvenlik katmanlarını gözden geçirin.
Konfigürasyon testi geçmeden servisi yeniden başlatmayın.

curl -skIL --max-redirs 15 https://example.com/
nginx -T | grep -nE 'return 30|rewrite |X-Forwarded-Proto'

Plesk Obsidian

Plesk tarafından üretilen NGINX sanal host dosyalarında nginx too many redirects kontrolü.

Domains > Apache & nginx Settings bölümündeki ek direktifleri inceleyin.
Elle oluşturulan ve Plesk tarafından üretilen dosyaları birbirinden ayırın.
Gerekirse yalnız ilgili domain için web yapılandırmasını yeniden oluşturun.

grep -R 'return 30\|rewrite ' /var/www/vhosts/system/example.com/conf 2>/dev/null
plesk repair web example.com -n

Güvenli çözüm sırası

NGINX redirect loop çözüm sırası

Dış 3xx zinciri ile NGINX internal cycle sorununu ayırıp tek kanonik URL ve doğru proxy şeması oluşturun.

Location zincirini çıkarın

Her 301/302’nin kaynak ve hedef URL’sini kaydedin.

curl -skIL --max-redirs 15 https://example.com/ | grep -Ei 'HTTP/|location:'

CDN/proxy katmanını ayırın

Origin IP’ye doğrudan istek göndererek döngünün nerede başladığını bulun.

curl -skIL --resolve example.com:443:ORIGIN_IP https://example.com/

Tek kanonik şema ve host seçin

HTTPS ve www tercihini yalnız bir açık server bloğunda uygulayın.

nginx -T | grep -nE 'server_name|return 30'

Forwarded proto bilgisini doğrulayın

Backend uygulama gerçek istemci şemasını doğru görmelidir.

nginx -T | grep -n 'X-Forwarded-Proto'

Internal cycle kurallarını inceleyin

try_files, error_page ve rewrite last hedeflerinin aynı location’a dönmediğini doğrulayın.

grep 'redirection cycle' /var/log/nginx/error.log | tail -n 20

Cache etkisini kaldırıp tekrar test edin

Curl, gizli pencere ve gerektiğinde CDN cache purge ile zinciri doğrulayın.

nginx -t && systemctl reload nginx
curl -skIL --max-redirs 10 https://example.com/

Belirtiye göre ayrım

Özel senaryolar ve karar ağacı

HTTP ile HTTPS arasında döngü

Origin şeması ve X-Forwarded-Proto uyuşmuyor olabilir.

curl -sIL http://example.com/; curl -skIL https://example.com/

www ve non-www döngüsü

NGINX ile uygulama farklı kanonik host seçiyor olabilir.

curl -skI https://www.example.com/; curl -skI https://example.com/

Cloudflare Flexible SSL

Origin HTTPS zorluyorsa Full/Strict moda geçiş ve sertifika kontrolü gerekir.

Origin ve Cloudflare isteklerinin Location değerlerini karşılaştırın.

WordPress giriş döngüsü

home/siteurl, SSL proxy header ve cookie domain kontrol edilir.

wp option get home; wp option get siteurl

Internal redirection cycle

rewrite last, try_files veya error_page aynı URI’yi yeniden eşliyor.

grep 'redirection cycle' /var/log/nginx/error.log | tail

Slash ekleme/çıkarma döngüsü

Uygulama ile NGINX’in trailing slash politikası çakışıyor olabilir.

curl -skIL https://example.com/yol; curl -skIL https://example.com/yol/

Kesinlikle yapmayın

Kalıcı 301’i doğrulamadan production’a uygulamayın.
Cloudflare Flexible SSL kullanırken origin HTTPS döngüsünü göz ardı etmeyin.
if yönergelerini karmaşık yönlendirme zincirleri için rastgele kullanmayın.
Uygulama ve NGINX’in aynı kanonik kuralı iki kez uygulamasına izin vermeyin.
Tarayıcı cache’ini temizleyip curl ile zinciri ölçmeden sonuç çıkarmayın.

Çözüm sonrası doğrulama

HTTP/HTTPS ve www tercihi tek adımda kanonik URL’ye gider.
curl zinciri maksimum birkaç adımda 2xx/3xx sonuca ulaşır.
NGINX logunda yeni internal redirection cycle yoktur.
Uygulama gerçek istemci şemasını doğru algılar.
Gerçek 404 ve error_page hedefleri döngü üretmez.

Resmî teknik kaynaklar

NGINX ve ilgili bileşenlerin resmî dokümantasyonu

NGINX Rewrite Modulereturn, rewrite, if, last ve break çalışma mantığı

NGINX HTTP Core Moduleİstek gövdesi, header buffer, root, alias ve try_files yönergeleri

NGINX Proxy ModuleReverse proxy, timeout, header ve buffering yönergeleri

NGINX Beginner’s GuideYapılandırma testi, sinyaller, reload ve temel çalışma modeli

İç SEO içerik kümesi

İlgili NGINX hata çözümleri

NGINX Hata KodlarıTüm NGINX hata ve çözüm rehberleri

→

502 Bad GatewayPHP-FPM, proxy_pass ve upstream bağlantı sorunları

→

504 Gateway TimeoutProxy ve FastCGI zaman aşımı sorunları

→

403 Forbiddenİzin, sahiplik ve erişim kuralları

→

413 Request Entity Too LargeDosya ve istek gövdesi yükleme limiti

→

404 Not Found ve try_filesDocument root, location ve front-controller sorunları

→

Sık sorulan sorular

NGINX Too Many Redirects hakkında merak edilenler

NGINX ERR_TOO_MANY_REDIRECTS neden olur?

HTTP/HTTPS, www/non-www, CDN, reverse proxy veya uygulama yönlendirmelerinin birbirine geri dönmesiyle oluşur.

Internal redirection cycle ile tarayıcı döngüsü aynı mı?

Hayır. Internal cycle NGINX içinde URI tekrar işlenmesidir; tarayıcı loop ise ardışık 3xx cevaplarla istemci tarafında görülür.

Cloudflare neden redirect loop yapar?

Flexible SSL ile origin HTTP görürken origin HTTPS’e yönlendirirse Cloudflare tekrar HTTP ile bağlanır ve döngü oluşabilir.

X-Forwarded-Proto ne işe yarar?

Reverse proxy, istemcinin asıl HTTP/HTTPS şemasını backend uygulamaya iletir; yanlışsa uygulama gereksiz HTTPS redirect üretebilir.

301 cache nasıl test edilir?

curl ile header zincirini inceleyin, gizli pencere kullanın ve gerekiyorsa CDN cache’ini temizleyin. Test aşamasında geçici 302 daha güvenlidir.

WordPress too many redirects nasıl çözülür?

home/siteurl, proxy SSL header, www tercihi ve NGINX HTTPS yönlendirmesi aynı kanonik URL’ye uyarlanmalıdır.

rewrite last ne zaman döngü yapar?

URI değişip aynı location ve rewrite kuralına yeniden eşleştiğinde tekrar döngüsü oluşabilir; break veya return daha uygun olabilir.

EKA YAZILIM VE BİLİŞİM SİSTEMLERİ

Sunucunuzdaki hatayı kalıcı olarak çözelim

cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim ve güvenlik katmanlarını birlikte analiz ederek yalnızca servisi kaldırmak yerine arızanın temel nedenini gideriyoruz.

Sunucu Desteği Al WhatsApp

Dedizierte Server-Dienste

Standardserver