Yanlış olduğunu düşündüğünüz bir kesinti uyarısı

Bir sitenin kesintide olduğunu söyleyen bir uyarı alırsınız, siteyi tarayıcınızda açarsınız ve mükemmel şekilde yüklenir. Bu, gerçek açıklamaları olan gerçek bir durumdur ve neredeyse hepsi şu ikisinden biridir: sitenin önündeki bir şey özellikle “bizi” reddetti, ya da site bir tarayıcının hoş gördüğü ama bir izleyicinin görmediği bir şekilde yanıt verdi. Bu sayfa hangisinin olduğunu nasıl anlayacağınızı anlatır.

Siteyle değil, nedenle başlayın

Her olay, kontrolün neden başarısız olduğunu kaydeder. Sitenin Uptime sekmesini açın ve olay satırındaki nedeni okuyun:

• Site bir hata durumu döndürdü — 4xx veya 5xx ile yanıt verdi. Buradaki bir 403 ya da 429, klasik “özellikle bizi engelledi” imzasıdır.
• Site zaman aşımına uğradı — zamanında yanıt vermedi.
• Bağlantı reddedildi ya da Ağ hatası — hiçbir şey bağlantıyı kabul etmedi.
• DNS çözümlenmedi — isim bir adrese çevrilemedi.
• TLS sertifika hatası — sertifika doğrulanamadı.
• Anahtar kelime kontrolü başarısız oldu — sayfa sorunsuz yanıt verdi, ama kendi anahtar kelime kuralınız karşılanmadı.
• Bir WordPress kritik hatası ya da boş bir sayfa — site 200 yanıtı verdi ve gövde çalışan bir site değildi.

Neden, aşağıdaki listeyi bir ya da iki adaya daraltır. Bir 403 ile bir zaman aşımı tamamen farklı sorunlardır ve yalnızca biri hızla ilgilidir.

Bu hiçbir zaman tek bir başarısız istek değildi

Uyarının aceleyle verildiğini varsaymadan önce: bir kontrolün art arda iki kez başarısız olması gerekir, ardından hemen bir doğrulama kontrolü yapılır. Yalnızca bu üçüncü istek de başarısız olursa bir olay açılır ve bir uyarı gönderilir. Anlık bir sorun size ulaşmaz.

Yani “site zaten sürekli çalışıyordu” ile “art arda üç istek başarısız oldu” ifadeleri, kulağa geldiğinden daha sık ikisi de doğru olur — aşağıdaki liste tam olarak bunu açıklıyor.

En yaygın açıklama: bir şey adresimizi engelliyor

Tüm trafik bizden sitenize gelir — eklenti asla WP Safer’ı çağırmaz — ve yaptığımız her istek tek bir IPv4 adresinden çıkar:

65.21.186.173

Uptime kontrolleri ayrıca kendilerini WPSafer Monitor kullanıcı ajanıyla tanıtır. Tarayıcınızda açılan bir site yine de o adrese kapalı olabilir: güvenlik duvarları IP’ye göre engeller ve yalnızca bize sunulan bir doğrulama sayfası ya da bir 403, bizim açımızdan tam olarak kesinti gibi görünür.

Olay nedeni bir hata durumuysa, başka türlü hızlı olan bir sitede bir zaman aşımıysa ya da güvenlikle ilgili bir şeyi kurduğunuzda veya yeniden yapılandırdığınızda başlayan ani bir başarısızlık dizisiyse, sitenin filtrelendiği her yerde adresimize izin verin:

• Cloudflare — Security → Security rules → Create rule → IP access rules: yukarıdaki adres, işlem Allow, bu web sitesiyle sınırlı. Bir uyarı: bir IP izin kuralı Bot Fight Mode veya Browser Integrity Check’i kapatmaz. Bunlar ayrı anahtarlardır ve bizi kendi başlarına engelleyebilirler.
• Wordfence — Firewall → Blocking → Allowlisted Services, izin verilen IP adresleri altında.
• Jetpack — Protect → Firewall: adresi güvenilir IP listesine ekleyin ve listenin açık olduğundan emin olun.
• Sucuri — Sucuri Firewall panelinde, Security → Access Control → Whitelist IP Address.
• Bir barındırma güvenlik duvarı (Imunify360, ModSecurity, sağlayıcının kendi WAF’ı) — bu WordPress’in içinde değildir ve genellikle ona ulaşamazsınız. Barındırma sağlayıcınıza tek bir satır gönderin: lütfen alan adım için 65.21.186.173 IP adresine izin verin.

Bazı güvenlik eklentileriyle bir kısayol vardır: WP Safer eklentisi yeterince güncel olan bir sitede, o sitenin kendi wp-admin’i içindeki WP Safer ekranı, izni sizin yerinize yazan bir Allow WP Safer düğmesi sunar. Siz basana kadar hiçbir şey yazılmaz ve daha sonra aynı yerden geri çekebilirsiniz.

Aynı engelleme, yalnızca uptime kontrolünü değil, o sitedeki yedekleri, güncellemeleri ve taramaları da durdurur — bu nedenle yanlış uyarıyla yaşamaya razıysanız bile bunu düzeltmeye değer.

Site yanıt verdi, ama çok yavaş

Bir bağlantı için 10 saniye, toplamda ise 15 saniye bekleriz. Oluşması 20 saniye süren bir sayfa, beklemeye ve bir yükleme animasyonu izlemeye razı olduğunuz bir tarayıcıda yüklenir; burada ise bir zaman aşımı olarak kaydedilir.

Bu sizin nedenizse, Uptime sekmesindeki yanıt süresi grafiği ve — Pro ve Agency planlarında — DNS / TCP / TLS / sunucu dökümü, isteğin hangi kısmının zamanı yediğini gösterir. Normalde 400 ms’de yanıt veren ve saat 3’te zaman aşımına uğrayan bir site genellikle zamanlanmış bir görev, bir yedekleme ya da aynı sunucudaki bir komşudur, bir WP Safer sorunu değildir.

Sertifika tarayıcınızda sorunsuz, bizim için değil

TLS’yi doğru şekilde doğrularız ve istisna yapmayız. İki yapılandırma bir tarayıcıda geçer ama burada başarısız olur: ara sertifikası eksik bir sertifika zinciri — masaüstü tarayıcılar bunu genellikle önbellekten tamamlar, biz tamamlamayız — ve henüz yenilenmiş ama yeniden başlatılmamış bir sunucuda sunulan, hâlâ eskisinin sunulduğu bir sertifika.

Uyarının yanlış olduğu sonucuna varmadan önce siteyi harici bir SSL testiyle kontrol edin. Eksik bir ara sertifika, bazı telefonlarda gerçek ziyaretçileri de bozar.

Yönlendirmeler

En fazla beş yönlendirmeyi takip ederiz. Bir yönlendirme döngüsü ya da beş adımdan uzun bir zincir, başarısız bir kontrol olarak sonuçlanır. Tarayıcılar daha fazlasına izin verir, bu yüzden http → https → www → sondaki eğik çizgi → dil öneki gibi bir zincir sizin için görünmez, bizim için ise nihai olabilir.

Anahtar kelime kuralı çok katıydı

Pro veya Agency’de bir anahtar kelime ayarladıysanız, neyle karşılaştırıldığını unutmayın: sunucunun döndürdüğü HTML. JavaScript çalıştırmayız. Bir betiğin oraya yazdığı için ekranda görünen bir kelime, o HTML’de yoktur ve sayfa size mükemmel görünürken kural her kontrolde başarısız olur.

Gerçekten kaynak kodda olan bir şey seçin — altbilginin bir parçası, bir başlık, site adı — ve izlediğiniz sayfanın yazımını ve dilini kontrol edin. Bir çerez bandırolu, kişiselleştirilmiş bir blok ya da ülkeye göre değişen bir sayfa tarafından oluşturulan bir kelime, aynı nedenle zayıf bir kuraldır.

Yine de kesinti saydığımız HTTP 200 yanıtları

Ücretli planlarda gövdeyi okuruz, çünkü bir WordPress ölümcül hatası 200 ile yanıt verir ve yalnızca ping yapan bir izleyici o siteyi sağlıklı sayardı. Gövde bir WordPress hata sayfası, bir veritabanı bağlantı hatası ya da sayfaya sızan bir PHP ölümcül hatası içerdiğinde, ya da pratikte boşsa — içinde metin olmayan yaklaşık yarım kilobaytın altındaysa — bir 200 kesinti olarak kaydedilir.

Buradaki tek dürüst yanlış pozitif, ana sayfası her şey daha sonra JavaScript tarafından çizildiği için gerçekten neredeyse boş HTML olan bir sitedir. Mimariniz buysa, gördüğünüz şey tam olarak budur.

Kritik hata cümlesinden bahseden bir sayfa — diyelim ki onu nasıl düzelteceğinizi anlatan bir makale — işaretlenmez: metin belirteçleri yalnızca 8 KB’ın altındaki gövdelere uygulanır, gerçek bir hata ekranının küçük olacağı, onun hakkındaki bir makalenin ise olmayacağı varsayımıyla.

Uyarı gibi görünen ama kesinti olmayan şeyler

Uptime sekmesindeki, “kesinti değil” olarak işaretlenmiş Monitoring notices altında, geride kalan WP-Cron’u, sessizleşen WP Safer eklentisini, değişen DNS kayıtlarını, değişen ad sunucularını ve süresi dolmaya yaklaşan bir alan adını bulursunuz. Bunlar hiçbir zaman uptime yüzdenizde görünmez ve hiçbir zaman bir olay açmaz. Aldığınız mesaj bunlardan biriyse, site kesintide olarak bildirilmemiştir.

Yapamayacağınız şey, ve sonrasında ne olur

“Şimdi tekrar kontrol et” düğmesi yoktur ve bu kasıtlıdır — ikinci bir görüş isteyebileceğiniz bir izleyici, geçmişini şekillendirebileceğiniz bir izleyicidir. Bir sonraki zamanlanmış kontrol, ilk başarıda olayı kendiliğinden kapatır ve kaydedilen kesinti, uyarıldığınız andan değil, ilk başarısız kontrolden o kurtarmaya kadar sürer.

Kontroller tek bir konumdan, Finlandiya’daki düğümümüzden yapılır. Bunu filo sayfasında ve genel durum sayfasının altbilgisinde belirtiyoruz ve yukarıdakilerin hepsinin dürüst sınırı budur: bir siteye ulaşamadığımızda, bu onu göremediğimiz anlamına gelir — kimsenin göremeyeceği anlamına değil.

Neden buradakilerden hiçbiriyle eşleşmiyorsa, site adı, olayın saati ve olay satırında gösterilen nedenle birlikte info@wpsafer.com adresine yazın. Bu üç şey, kendi kayıtlarımızda tam isteği bulmamız için yeterlidir.