Bir site yöneticisi aynı anda HTTPS eklentisini, Apache kuralını ve CDN yönlendirmesini etkinleştiriyor. CDN kaynak sunucuya HTTP ile bağlanırken WordPress iletilen her isteği güvensiz sandığı için trafik HTTP ile HTTPS arasında dönüp duruyor.
Yeni bir yönlendirme eklemek sorunu büyütür. Önce çalışan TLS bağlantısı, tek bir temel adres, tek bir yönlendirme sorumlusu ve proxy ile WordPress arasında güvenilir protokol bilgisi gerekir.
Bu konu ne anlama gelir?
HTTPS zorlaması, sertifika ve şifreli bağlantı düzgün çalıştıktan sonra desteklenen HTTP isteklerini tek bir temel HTTPS adresine yönlendirmektir. Bu kural CDN’de, web sunucusunda veya WordPress’te bulunabilir; aynı kararı birden fazla bileşen vermemelidir.
Proxy kullanılan sistemlerde ziyaretçi HTTPS ile bağlanırken proxy, WordPress’e HTTP üzerinden ulaşabilir. WordPress, iletilen protokol başlıklarına yalnız bilinen proxy’lerden geldiklerinde güvenmelidir. Aksi takdirde yönlendirme döngüsü veya sahte protokol bilgisi oluşabilir.
Gerçekçi bir WordPress örneği
Örnekte CDN ziyaretçiyi HTTPS’ye yönlendiriyor, ancak kaynak sunucu HTTP bağlantısı gördüğü için eklenti yeniden yönlendirme yapıyor. Apache kuralı da host adını değiştirince tek istek birbiriyle çelişen birkaç karardan geçiyor. Webhook’lar ve wp-adminaynı döngüye takılıyor.
Kaynak sunucuda doğrudan HTTPS doğrulandıktan sonra genel yönlendirmeyi yalnız CDN üstleniyor. WordPress güvenilir proxy’den gelen protokol bilgisini doğru yorumluyor; eklenti ve Apache’deki yinelenen kurallar kaldırılıyor. Böylece her adres ve protokol birleşimi temel adrese tek adımda ulaşıyor.
Neden önemlidir ve ne zaman kullanılır?
Tutarlı HTTPS, oturumları ve form verilerini korur; WordPress’in farklı protokollerle adres üretmesini önler. Hatalı sıralanan kurallar ise ziyaretçilerin ve yöneticilerin erişimini kesebilir, API geri çağrılarını bozabilir veya döngüyü CDN önbelleğine taşıyabilir.
HTTPS’yi ancak bütün genel alan adlarında geçerli sertifika bulunduğunda, kaynak sunucuya giden yol anlaşıldığında ve WordPress doğru temel adresleri kullandığında zorlayın. HSTS daha sonra ayrıca değerlendirilmelidir; çünkü tarayıcı bu kuralı sıradan yönlendirmeden daha uzun süre hatırlar.
Yeni başlayanlar için anlaşılır yol
- Desteklenen bütün alan adlarının geçerli sertifikayla doğrudan HTTPS üzerinden açıldığını doğrulayın.
- Mevcut WordPress Adresini, Site Adresini, CDN modunu, web sunucusu kurallarını ve eklenti yönlendirmelerini kaydedin.
- HTTP’den HTTPS’ye yönlendirmeyi tek bir bileşene bırakın ve çakışan kuralları kapatın.
- Güvenilir bir proxy varsa WordPress’in iletilen protokol bilgisini güvenli biçimde tanımasını sağlayın.
- Kuralı kalıcı yapmadan kök alan adı ve
www, HTTP ve HTTPS, giriş, çıkış, parola sıfırlama, formlar, REST istekleri ve webhook’ları sınayın.
İleri teknik yol
Desteklenen host ve protokol birleşimlerini küçük bir tabloda toplayın; her durum kodunu ve Locationbaşlığını çerezsiz inceleyin. Genel HTTP isteği temel HTTPS adresine normalde tek yönlendirmeyle ulaşmalı, doğru bir HTTPS isteği yalnız proxy’nin iç bağlantısı HTTP olduğu için yeniden yönlenmemelidir.
Forwardedve X-Forwarded-Protobaşlıklarının güven sınırını, çoklu site alan eşlemesini, sağlık denetimlerini, OAuth ve ödeme geri çağrılarını, REST ve XML-RPC uçlarını, zamanlanmış istekleri ve yönlendirme saklayan önbellekleri kontrol edin.
Riskler, sık hatalar, yedek ve geri dönüş
Eklenti, sunucu ve CDN kurallarını üst üste bindirmeyin; herhangi bir istemcinin gönderdiği proxy başlığına güvenmeyin. TLS hazır olmadan veritabanı adreslerini değiştirmek, sağlık denetimlerini yönlendirmek, döngüyü önbelleğe almak ve hata ayıklarken HSTS açmak kurtarmayı zorlaştırır.
Kaynak sunucuya veya yönetim paneline ulaşan sınanmış bir yol açık kalmalıdır. Giriş, geri çağrı ya da sağlık denetimi bozulursa eklenen tek kuralı kapatın ve değiştirildiyse önceki WordPress adreslerini geri yükleyin. Yalnız değişiklikten etkilenen yönlendirme önbelleğini temizleyin.
AIOWS nasıl yardımcı olur?
AIOWS SSL Yöneticisi
AIOWS SSL Yöneticisi, WordPress tarafındaki desteklenen HTTPS ayarlarını, yönlendirmeleri ve mixed content durumunu tek yerde gösterir. Bu sorumluluk bilinçli biçimde WordPress’e verildiyse ve diğer katmanlardaki çakışan kurallar kaldırıldıysa yönlendirmeyi yönetebilir.
Etkinleştirmeden önce sertifika ile kaynak sunucu bağlantısını doğrulayın, temel WordPress adreslerini kesinleştirin ve yönetim paneline bir dönüş yolu bırakın. Ardından farklı adres ve protokol seçeneklerini; giriş, form, REST ve geri çağrı işlemleriyle birlikte sınayın.
Modül dış sertifikaları onaramaz, CDN’nin kaynak bağlantısı modunu yapılandıramaz ve web sunucusu kurallarını geçersiz kılamaz. AIOWS’nin doğru protokol bilgisini alması ve ikinci bir yönlendirmeyle çakışmaması için bu katmanlar kendi yöneticileri tarafından uyumlu hâle getirilmelidir.
AIOWS SSL Yöneticisi özelliğini inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Mixed Content Hatası: HTTPS Sorununu Çözme Rehberi
- SSL Sonrası WordPress Güvenli Değil: Tam Çözüm Rehberi
- WordPress'te .htaccess ile HTTP'den HTTPS'ye Yönlendirme
Sonuç ve önerilen yol
Önce güvenilir TLS bağlantısını kurun; ardından tek bir temel adres ve tek bir yönlendirme sorumlusu seçip proxy protokolünü açıkça ele alın. Kuralı kalıcı yapmadan bütün host ve protokol birleşimlerini, yönetim panelini ve geri çağrıları sınayın; HSTS’yi ayrı değerlendirin.
