Reverse proxy TLS bağlantısını sonlandırıp WordPress’e HTTP ile bağlandığında ziyaretçi HTTPS kullanmasına rağmen uygulama isteği güvensiz sanabilir. Bunun sonucunda yönlendirme döngüsü, HTTP canonical URL’ler, Secure olmayan çerezler veya hatalı callback adresleri oluşabilir.
İstemcinin kullandığı protokolü ve HTTPS durumunu WordPress’e doğru iletmek gerekir; ancak istemcinin gönderdiği her forwarded başlığına güvenilmemelidir. Güven yalnız bilinen proxy sınırında kurulmalıdır.
Proxy arkasında HTTPS nasıl işler?
Ziyaretçi ile proxy arasındaki ve proxy ile origin arasındaki bağlantılar ayrı olabilir. WordPress, istemcinin kullandığı protokolü ve istediği hostu proxy’nin güvenilir biçimde düzenlediği başlıklardan öğrenmelidir. Aksi hâlde URL, çerez ve yönlendirme üretimi iç bağlantıya göre yapılır.
Gerçekçi bir WordPress örneği
Load balancer HTTPS isteğini kabul eder, origin’e HTTP gönderir ve X-Forwarded-Proto: httpsekler. WordPress bu bilgiyi kullanmadığı için wp-administeğini yeniden HTTPS’ye yönlendirir. Aynı proxy isteği yine HTTP ile origin’e ilettiğinden döngü oluşur.
Başka bir yapılandırmada proxy istemcinin mevcut başlığını ezmek yerine sonuna ekler. WordPress belirsiz değeri yanlış yorumlayabilir veya saldırgan sahte HTTPS bilgisi gönderebilir.
Neden önemlidir?
WordPress özgün isteğin HTTP mi HTTPS mi kullandığını yanlış belirlediğinde giriş oturumları, REST kimlik doğrulaması, cron çağrıları, OAuth ve ödeme webhook’ları etkilenir. Yalnız ana sayfanın açılması bütün uygulama yollarının doğru olduğu anlamına gelmez.
Temel çözüm adımları
- CDN, load balancer, ingress ve origin dahil proxy zincirini çıkarın.
- TLS’nin hangi katmanda sonlandığını ve proxy’nin origin’e hangi protokolle bağlandığını kaydedin.
- Proxy’nin istemcinin kullandığı protokol ve host bilgisini güvenilir başlıklarla iletmesini sağlayın.
- WordPress başlamadan önce yalnız bilinen proxy’den gelen HTTPS bilgisini normalleştirin.
- Yönlendirmeyi tek katmanda yönetin ve doğrudan origin erişimini kısıtlayın.
- Giriş, REST, form, callback ve Secure çerezleri gerçek isteklerle sınayın.
İleri teknik kontroller
Geçerli, eksik ve sahte forwarded başlıklarla edge ve yetkili origin davranışını karşılaştırın. Forwarded, X-Forwarded-Proto, host ve istemci IP zincirinin hangi proxy tarafından yazıldığını belgeleyin. Birden fazla proxy varsa güvenilir hop sayısını ve adres aralığını açıkça belirleyin.
Canonical, site haritası, REST URL’leri, parola sıfırlama ve OAuth callback çıktılarını kontrol edin. Proxy sağlık denetiminin kullanıcı trafiğinden farklı bir host veya protokolle yönlendirme oluşturmadığını doğrulayın.
Riskler ve geri alma
Her X-Forwarded-Protodeğerine güvenmek istemcinin güvenlik durumunu taklit etmesine izin verir. Yalnız WordPress URL’lerini değiştirmek çalışma zamanındaki algıyı düzeltmez; her katmana yönlendirme eklemek de döngü oluşturur. Değişiklikten önce proxy ve WordPress yapılandırmasını kaydedin; giriş veya callback bozulursa son güvenilir başlık politikasına dönün.
AIOWS nasıl yardımcı olur?
AIOWS SSL Yöneticisi
Reverse proxy güven ilişkisi yapılandırıldıktan sonra AIOWS SSL Yöneticisi, WordPress’in dış isteği HTTPS olarak algıladığını ve doğru adresleri ürettiğini denetlemeye yardımcı olur.
Modül load balancer veya CDN’nin güven politikasını kendi başına değiştirmez. Forwarded başlıkların kaynağı, origin erişimi ve TLS sonlandırma modeli altyapı tarafında doğru kurulmalıdır. Sonrasında WordPress girişini, REST API’yi, formları ve callback yollarını sınayın.
Başlık sahteciliği, yönlendirme döngüsü veya Secure çerez sorunu sürüyorsa yeni HTTPS ayarları eklemeyin. Proxy zincirini ve güvenilen adresleri yeniden inceleyip son çalışan yapılandırmayı koruyun.
AIOWS SSL Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- Cloudflare Flexible SSL WordPress’te Neden Yönlendirme Döngüsü Oluşturur?
- WordPress’te WWW ve WWW Olmayan HTTPS Yönlendirmeleri
- WordPress SSL Sertifikası ve HTTPS Sağlığı Nasıl Kontrol Edilir?
Sonuç ve önerilen yol
İstemcinin HTTPS kullandığı bilgisini yalnız güvenilir proxy zincirinden alın, doğrudan origin erişimini sınırlandırın ve yönlendirmeyi tek katmanda yönetin. WordPress’i ancak giriş, REST ve callback yolları doğru HTTPS üretince sağlıklı sayın.
