Müşteri panelin açılmadığını söylüyor. Sizde açılıyor, herkeste açılıyor, ve izlemeniz 200 gösteriyor. Bunu rahatsız edici yapan şey, düzeltecek bir şey olmadığı hâlde bir şeyi düzeltme dürtüsü: sorun neredeyse hiçbir zaman panel tarafında değildir. «Kırılma tam olarak nerede» sorusuna on dakikada cevap veren bir teşhis sırası ve proxy\'nin ne zaman yardım edip ne zaman hiçbir şey yapmadığına dürüst bir bakış şöyle.
Önce «herkes»i «tek kişi»den ayırın
Bir şeyi değiştirmeden önce ölçeği belirleyin. Üç hızlı kontrol bunu yapar:
- Dış erişilebilirlik kontrolleri. check-host gibi servisler alan adınızı farklı ülkelerdeki onlarca düğümden yoklar. Müşterinin ülkesindeki düğümler dahil hepsi 200 döndürüyorsa panel çalışıyordur ve mesele onun bağlantısıdır.
- DNS. Alan adı doğru adrese çözülmeli. Yeni bir CNAME henüz yayılmamış olabilir, ve eski bir A kaydı önceki barındırıcıdan kalmış olabilir.
- Sunucu günlükleri. En çok hafife alınan kontrol. Erişim günlüğünde ilgili saatte müşterinin IP\'sinden hiçbir istek yoksa, tarayıcısı sunucuya hiç ulaşmamıştır - ve sunucu tarafında hiçbir değişiklik yardım edemez.
Bu teori değil: bir panelde gerçek bir vakada, izleme müşterinin ülkesindekiler dahil bütün düğümlerden 200 döndürdü, oysa sabahın günlüklerinde o ülkeden izleme düğümleri ve bir arama botu dışında hiç istek yoktu. Teşhis, panel kesintisi değil, müşterinin operatöründeki filtrelemeydi.
Müşteriye ne sorulmalı
«Çalışmıyor» işe yaramaz. Dört şey isteyin, gidip gelmeleri çarpıcı biçimde azaltırsınız.
- Tam hata.
ERR_CONNECTION_CLOSED, bir zaman aşımı, bir sertifika uyarısı ve operatörün engelleme sayfası dört farklı sebeptir. - Başka bir ağ. Ev Wi-Fi\'si ile mobil veri. Mobil çalışıyorsa ev operatörü filtreliyordur, tersi de geçerli.
- Başka bir cihaz ve gizli pencere. Bu, tarayıcı eklentilerini ve yerel önbelleği eler.
- HTTPS denetimi yapan antivirüs. O modüller sertifikayı değiştirir ve çoğu zaman bağlantıyı kendileri keser.
Yaygın sebepler, olasılığa göre sıralı
- Müşterinin operatöründe filtreleme. Ev ve mobil hatlardaki filtre donanımı veri merkezlerindekinden katıdır - veri merkezinden yapılan izlemenin siteyi görüp bir insanın görmemesinin sebebi budur.
- Yerel koruma. Antivirüs, kurumsal ağ geçidi, engelleyici bir eklenti.
- Müşterinin DNS\'i. Çözücüsünün önbelleği eski adresi veriyordur; genel bir çözücüye geçmek meseleyi kapatır.
- Sertifika. Verilmemiş ya da yenilenmemiş - ama o zaman hatayı tek kişi değil herkes görür.
- Panelin kendisi. Listede gerçekten sonuncu, ve bu yüzden elle değil otomasyonla önce kontrol edilmeli.
Proxy ne zaman yardım eder, ne zaman etmez
İlk refleks Cloudflare proxy\'sini açıp bir şeylerin gizlenmesini ummaktır. Gerçekte neyin değiştiğini bilmekte fayda var: müşteri sizin sunucunuzun adresi yerine proxy\'nin adresine bağlanır. Yani engel sunucunuzun IP adresini hedefliyorsa yardım eder. Engel alan adını hedefliyorsa proxy hiçbir şey kazandırmaz: ad, bağlantı el sıkışmasıyla birlikte gider ve görünür kalır.
Buradan sıra çıkar: önce engelin niteliğini anlayın, sonra karar verin. Ve proxy\'yi açarsanız, proxy ile sunucu arasındaki şifreleme modu sertifika doğrulamasının yapıldığı katı mod olmalıdır. Gevşek modlar bir yönlendirme döngüsü yaratır, çünkü sunucu istekleri kendisi HTTPS\'e yükseltir, ve otomatik sertifika verilmesiyle panelin herkes için açılmayı bırakacağı kadar kötü çakışırlar.
İşleyen diğer seçenek bir ayna alan adıdır: aynı panel ikinci bir alan adında, bağlantısı e-postalarınızda ve destek yanıtlarınızda tutulur. Altyapı değişikliği gerektirmez ve proxy\'den daha fazla vakayı çözer, çünkü yeni bir ad henüz hiçbir filtreye ulaşmamıştır.
Önceden ne kurulmalı
- Sattığınız ülkelerden dış izleme. Sorunu müşterinizden önce siz duyun diye.
- Sunucu günlüklerine erişim. Onlar olmadan her inceleme tahmine döner.
- Yedek bir iletişim kanalı. Telegram ya da e-posta: panel açılmıyorsa müşteri nereye yazacağını bilmeli.
- Geçmişi olmayan bir alan adı. Filtrelenmiş bir geçmişi olan ucuz alan adı, yenisinden pahalıya gelir.
Toparlarsak
Kural basit: değiştirmeden önce ölçün. Birkaç ülkeden izleme, DNS ve doğru zaman aralığı için erişim günlükleri kırılmanın nerede olduğunu söyler - ve cevap çoğu zaman «panelde» değil «müşterinin bağlantısında»dır. Kiralamanın altyapı tarafı bizde kalır: sertifikalar, erişilebilirlik, günlükler ve istendiğinde teşhis, ayna alan adı yardımı dahil. Üçüncü taraf siparişleri ayda yüzün altında kaldığı sürece bu yine sıfıra gelir, kendi kataloğumuzda ise her hacimde.
