Sitem Bende Açılıyor Müşterimde Açılmıyor: Neden ve Nasıl Bulunur

Telefon çalıyor: "Sitenize giremiyorum." Siz aynı adresi açıyorsunuz, site pırıl pırıl geliyor. Ofisteki üç kişiye de sordunuz, hepsinde açılıyor. Uptime servisiniz yeşil, sunucu yükü normal, hata kaydı boş. Ama karşı taraf ısrarla giremediğini söylüyor ve bir ekran görüntüsü gönderiyor — orada gerçekten bir hata var.

Bu, "sitem açılmıyor" vakalarının en can sıkıcı türüdür, çünkü elinizdeki bütün araçlar size sitenin çalıştığını söyler. Site tamamen kapalı olsaydı iş kolaydı: sunucuya bakar, servisi kaldırırdınız. Ama kısmi erişilebilirlik bambaşka bir teşhis ağacı gerektirir; sorun tanımı gereği kendi bilgisayarınızdan asla üretilemez. Herkeste kapalı olan bir site için işleyen genel akışı sitem açılmıyor teşhis rehberinde bulabilirsiniz; burada tam olarak onun kapsamadığı durumu ele alıyoruz.

Uzaktan teşhis, karşı taraftan doğru veriyi almakla başlar. Önce ne soracağınızı, sonra gelen cevaba göre hangi katmanı inceleyeceğinizi göstereceğim. Her neden için hem sunucuda çalıştıracağınız komutu hem de kullanıcıya yaptırabileceğiniz tek satırlık doğrulamayı vereceğim — teknik olmayan bir müşteriye üç adımlık talimat verirseniz üçüncü adımın cevabını asla alamazsınız.

Uzaktaki Kullanıcıdan Toplamanız Gereken Üç Bilgi#

Teşhisin tamamı üç sorunun cevabına dayanır. Bunları almadan sunucuya bakmayın; bakarsanız yanlış yere bakarsınız.

1. Ekranda tam olarak ne yazıyor? "Açılmıyor" bilgi değildir. Sayfa hiç mi gelmiyor, gelip hata mı veriyor, tarayıcı mı uyarı çıkarıyor? Ekran görüntüsü isteyin, hata metnini yazdırmayın — kullanıcılar hata metnini yanlış aktarır.

2. Mobil veride de aynı mı? Kullanıcıdan Wi-Fi'ı kapatıp aynı adresi mobil veriyle denemesini isteyin. Bu tek adım, sorunun kullanıcının ağında mı yoksa kimliğinde mi olduğunu ayırır. Mobil veride açılıyorsa sorun o ağın çıkış IP'sinde, modemin DNS'inde veya kurum güvenlik duvarındadır. İkisinde de açılmıyorsa sorun cihazda veya sizin sunucunuzdadır.

3. Hangi şehir, hangi operatör ve hangi çıkış IP'si? Şehir ve operatör GeoIP ile ilgili ipuçlarını verir; çıkış IP'si ise güvenlik duvarı kaydında arayacağınız değerdir. Kullanıcıya karmaşık bir şey anlatmayın, tek adres yeterlidir:

# Kullanıcı tarayıcıya bu adresi yazsın, çıkan sayıyı size göndersin:
# https://api.ipify.org

# Terminali olan bir kullanıcı için:
curl -s https://api.ipify.org; echo

Üç cevabı aldığınızda vakaların çoğunda hangi bölüme gideceğiniz bellidir.

Hata Metni Hangi Katmanı Gösterir#

Tarayıcının verdiği metin, sorunun hangi katmanda takıldığını neredeyse kesin biçimde söyler. Aşağıdaki tabloyu kullanıcının gönderdiği ekran görüntüsüyle karşılaştırın.

En kritik satır ilk ikisidir. Zaman aşımı ile bağlantı reddedildi aynı şey değildir: zaman aşımında paket sessizce düşürülmüştür, bu tipik bir güvenlik duvarı DROP davranışıdır; bağlantı reddedildiğinde ise makineye ulaşılmış ve aktif olarak "kapalı" cevabı alınmıştır.

İlk Ayrım: İstek Sunucuya Hiç Ulaştı mı#

Bütün teşhis ağacını ikiye bölen tek soru budur ve cevabı erişim kayıtlarında yatar. Kullanıcının IP'sini elinize aldıktan sonra sunucuda arayın:

# cPanel sunucuda alan adının erişim kaydı
grep '203.0.113.45' /home/musterikullanicisi/access-logs/ornek.com | tail -20

# Ham nginx/Apache kurulumunda
grep '203.0.113.45' /var/log/nginx/access.log | tail -20
grep '203.0.113.45' /var/log/apache2/access.log | tail -20

Çıktıya göre yol ikiye ayrılır:

• Hiç satır yok. İstek web sunucusuna ulaşmamıştır. Sorun güvenlik duvarı, DNS veya ağ katmanındadır. Doğrudan IP banı ve DNS bölümlerine gidin; sitenin kodunda, .htaccess dosyasında veya WordPress eklentisinde arama yapmak zaman kaybıdır.
• Satır var, durum kodu 403/406/503. İstek ulaşmış, sunucu reddetmiştir. Sorun uygulama veya WAF katmanındadır; ModSecurity bölümüne gidin.
• Satır var, durum kodu 200. Sunucu sayfayı teslim etmiştir. Bu durumda sorun kullanıcı tarafındadır: önbellek, eklenti, kurum proxy'si veya sertifika.

Burada bir tuzak var. Siteniz Cloudflare gibi bir proxy arkasındaysa kayıtta ziyaretçinin değil proxy'nin IP'si görünür; aradığınız IP'yi bulamaz ve yanlışlıkla "istek ulaşmadı" dersiniz. Bu kurulumda ya gerçek IP geri kazanımını (mod_remoteip veya nginx real_ip) yapılandırın, ya da Cloudflare panelindeki Security → Events ekranından filtreleyin — engel çoğu zaman zaten oradadır.

Müşterinin IP'si Güvenlik Duvarında Yasaklıysa#

Kısmi erişilebilirliğin en yaygın nedeni budur ve genellikle masum bir olaydan doğar: müşterinin ofisindeki bir çalışan webmail şifresini üst üste yanlış girmiştir, brute force koruması o IP'yi yasaklamıştır ve ofis aynı NAT çıkışını paylaştığı için on beş kişi birden siteye giremez olmuştur. Belirti zaman aşımıdır; sizin tarafınızda hiçbir hata görünmez. Üç ayrı mekanizma aynı sonucu üretir, üçünü de ayrı kontrol edin.

CSF ve lfd#

CSF, bir IP'nin hangi kural yüzünden ve ne zaman engellendiğini tek komutla söyler:

# IP'yi tüm kural setinde ara (kalıcı + geçici + iptables)
csf -g 203.0.113.45

# Engelin gerekçesini gör
grep '203.0.113.45' /var/log/lfd.log | tail -20

# Geçici engeli kaldır
csf -tr 203.0.113.45

# Kalıcı engeli kaldır
csf -dr 203.0.113.45

# Bir daha yasaklanmasın (müşterinin sabit ofis IP'si için)
csf -a 203.0.113.45 "Musteri ofis cikis IP"

csf -a ile csf -tr arasındaki farkı atlamayın: banı kaldırırsanız aynı tetikleyici bir saat sonra IP'yi yeniden yasaklar ve müşteri ertesi gün tekrar arar. Kurumsal müşterinin sabit çıkış IP'si biliniyorsa kalıcı olarak beyaz listeye almak doğru hamledir. CSF'in çalışma mantığı ve beyaz liste dosyalarının farkı için CSF firewall kurulum rehberine bakabilirsiniz.

cPHulk#

cPHulk sık karıştırılır: varsayılan olarak yalnızca kimlik doğrulama servislerini korur — cPanel, WHM, webmail, FTP ve mail girişleri. Yani cPHulk banı, müşterinin siteye değil webmail'e girememesini açıklar. Ancak WHM'deki "Block IP addresses at the firewall level" seçeneği açıksa engel güvenlik duvarına yazılır ve 80/443 dahil her şey kapanır; bu ayarı bilmeden cPHulk'u listeden çıkarmayın.

# cPHulk kayıtlarını bu IP için temizle (root ile)
whmapi1 flush_cphulk_login_history_for_ips ip=203.0.113.45

Fail2ban#

CSF kullanmayan sunucularda aynı işi fail2ban yapar:

fail2ban-client status
fail2ban-client status sshd
fail2ban-client unban 203.0.113.45

fail2ban-client unban komutu IP'yi bütün hapislerden çıkarır; tek bir hapisle sınırlamak isterseniz fail2ban-client set HAPISADI unbanip 203.0.113.45 biçimini kullanın.

Kullanıcıya Yaptıracağınız Tek Adım#

Banı doğrulamak için kullanıcıya şu komutu verin. Windows'ta PowerShell açıp yapıştırması yeterlidir:

# Windows PowerShell
Test-NetConnection ornek.com -Port 443

# macOS / Linux
nc -vz -w 5 ornek.com 443

Cevap "TcpTestSucceeded : False" veya bağlantı zaman aşımıysa ve aynı komut sizde başarılı dönüyorsa, o IP ile sunucu arasında bir engel var demektir.

ISS DNS Önbelleği Eski Kaydı Tutuyorsa#

Alan adının IP'sini yakın zamanda değiştirdiyseniz, bazı kullanıcılar yeni sunucuyu görürken bazıları eskisini görmeye devam eder. Bu, propagasyonun tanımı gereği böyledir: her resolver kaydı kendi TTL süresince tutar ve bazı Türk internet servis sağlayıcılarının resolver'ları TTL'i olduğundan uzun süre saklar.

Belirti karakteristiktir: kullanıcı siteye giriyor ama eski içeriği görüyor, ya da eski sunucu artık kapalıysa zaman aşımı alıyor. Sizde her şey normaldir, çünkü sizin resolver'ınız kaydı çoktan yenilemiştir.

Doğrulama, aynı sorguyu farklı resolver'lara sormaktır:

# Aynı soru, üç ayrı resolver
dig +short ornek.com @8.8.8.8
dig +short ornek.com @1.1.1.1
dig +short ornek.com @195.175.39.39

# Kalan TTL'i gör (parantez içindeki saniye)
dig ornek.com | grep -A1 'ANSWER SECTION'

Üç cevap farklıysa propagasyon hâlâ sürmektedir. Kullanıcıya yaptıracağınız tek adım Windows'ta şudur:

nslookup ornek.com
nslookup ornek.com 1.1.1.1

İki çıktı farklı IP veriyorsa kullanıcının resolver'ı eski kaydı tutuyor demektir. Geçici çözüm kullanıcının DNS'ini 1.1.1.1 veya 8.8.8.8 yapmasıdır; kalıcı çözüm ise beklemektir. Kendi tarafınızdaki önbellekleri temizlemek propagasyonu hızlandırmaz — bu yaygın yanlış anlamanın ayrıntısı DNS önbelleği temizleme yazısında ele alınıyor.

Bir de sessiz senaryo var: kayıtları düzenlerken TTL'i düşürmeyi unuttuysanız ve TTL 86400 ise, bazı kullanıcılar geçişi tam bir gün boyunca göremez. Sunucu değişikliği planlarken TTL'i işlemden en az bir gün önce 300 saniyeye indirmek bu vakayı tamamen ortadan kaldırır.

AAAA Kaydı Var ama IPv6 Yolu Kırıksa#

Bu neden listede en az akla gelenidir ama Türkiye'de mobil operatörlerin IPv6 kullanımı arttıkça giderek yaygınlaşıyor. Belirtisi de tanınabilir: sayfa çok uzun sürüyor, sonra bazen açılıyor bazen açılmıyor ve genellikle tek bir operatörün abonelerinde görülüyor.

Mekanizma şudur. Alan adınızın bir AAAA kaydı vardır — çoğu zaman siz eklememişsinizdir, hosting paneli veya CDN otomatik eklemiştir. IPv6 destekli bir cihaz önce IPv6 yolunu dener. Sunucu o adreste dinlemiyorsa ya da ip6tables tarafında 80/443 açılmamışsa paket sessizce düşer, tarayıcı zaman aşımını bekleyip IPv4'e döner. Kullanıcı bunu "site çok yavaş" veya "bazen açılıyor" diye tarif eder.

Sunucuda üç şeyi kontrol edin:

# 1. Alan adının IPv6 kaydı var mı
dig +short AAAA ornek.com

# 2. Web sunucusu IPv6 üzerinde gerçekten dinliyor mu ([::] görmelisiniz)
ss -tlnp | grep -E ':(80|443)'

# 3. IPv6 güvenlik duvarı 80/443'e izin veriyor mu
ip6tables -L INPUT -n --line-numbers | head -30

nginx kullanıyorsanız IPv6 dinlemesi ayrı bir satırdır ve unutulması çok kolaydır:

server {
    listen 80;
    listen [::]:80;

    listen 443 ssl;
    listen [::]:443 ssl;

    server_name ornek.com www.ornek.com;
}

Karar basittir: IPv6'yı ya tam çalıştırın ya da AAAA kaydını kaldırın. Yarım yapılandırılmış IPv6, hiç olmamasından kötüdür; yalnızca IPv6 istemcilerini etkiler ve sizde hiç görünmez. İkili yığın kurulumu AAAA kaydı ve IPv6 yapılandırması yazısında.

Kullanıcıya yaptıracağınız doğrulama tek komutluk:

curl -4 -sI --max-time 10 https://ornek.com | head -1
curl -6 -sI --max-time 10 https://ornek.com | head -1

İlk satır HTTP/2 200 dönüp ikincisi zaman aşımına uğruyorsa teşhis kesindir.

GeoIP ve Ülke Bazlı Kural Kendi Müşterinizi Kesiyorsa#

Yurt dışı saldırı trafiğini azaltmak için ülke bazlı engelleme koyduysanız, o kural bazen kendi kullanıcınızı da keser. İki tipik senaryo vardır ve ikisi de sık yaşanır.

Birincisi, yurt dışındaki müşteriniz veya seyahatteki çalışanınızdır; kural amaçlandığı gibi çalışmış, sadece yanlış kişiyi yakalamıştır. İkincisi daha sinsidir: bazı mobil operatör IP blokları GeoIP veritabanlarında yanlış ülkeye kayıtlıdır veya operatör CGNAT havuzunu yurt dışında tescilli bir bloktan verir. Kullanıcı Ankara'dadır, IP'si Hollanda görünür, kural onu keser. "Müşterim Türkiye'de, GeoIP olamaz" varsayımı bu yüzden güvenilir değildir.

Kontrol edilecek yerler kurulumunuza göre değişir:

# CSF ülke kuralları
grep -E '^CC_(DENY|ALLOW|IGNORE)' /etc/csf/csf.conf

# Şikâyet eden IP hangi ülkeye kayıtlı görünüyor
whois 203.0.113.45 | grep -iE 'country|netname|descr' | head

Cloudflare kullanıyorsanız kural WAF tarafındadır ve sunucuda hiçbir izi yoktur; Security → Events ekranını o IP ile filtreleyin, engelleyen kuralın adı doğrudan görünür. Ülke engellemenin katman seçimi, arama motoru botlarını yanlışlıkla kesme riski ve VPN gerçeği GeoIP ile ülke bazlı engelleme yazısında ayrıntılı.

ModSecurity Belirli Tarayıcıyı veya İçeriği Engelliyorsa#

Erişim kaydında kullanıcının IP'si var ve durum kodu 403 ya da 406 ise sorun ağda değil, WAF katmanındadır. Bunun kullanıcıya özel olmasının nedeni, kuralın kişiyi değil davranışı yakalamasıdır: gönderdiği form içeriği, tarayıcı eklentisinin eklediği bir başlık, kurum proxy'sinin yazdığı User-Agent, ya da yorum alanına yapıştırdığı bir bağlantı.

Belirtiyi tanıyın: kullanıcı ana sayfayı açabiliyor ama iletişim formunu gönderemiyor, ya da yalnızca belirli bir sayfada 403 alıyor. Bu, ağ engelinden farklıdır — ağ engeli seçici davranmaz.

# cPanel sunucuda ModSecurity denetim kaydında IP'yi ara
grep -B5 -A20 '203.0.113.45' /usr/local/apache/logs/modsec_audit.log | tail -60

# Ham Apache kurulumunda
grep -B5 -A20 '203.0.113.45' /var/log/apache2/modsec_audit.log | tail -60

Çıktıdaki [id "942100"] biçimindeki kural kimliği aradığınız şeydir; WHM'de aynı bilgi ModSecurity Tools → Hits List ekranında IP filtresiyle durur. Doğru çözüm WAF'ı kapatmak değil, yalnızca o kuralı o dizin için muaf tutmaktır: sözdizimi ModSecurity 403 ve 406 hatası çözümü yazısında.

Ara Sertifika Eksikse Sizde Yeşil, Onda Kırmızı Görünür#

Bu, "bende açılıyor onda açılmıyor" vakalarının en yanıltıcı örneğidir, çünkü sunucuda hiçbir hata yoktur ve sizin tarayıcınız siteyi kusursuz açar.

Sertifika kurulurken ara sertifika (intermediate) zinciri eksik bırakılmışsa tarayıcıların davranışı ayrışır. Masaüstü Chrome ve Windows, daha önce başka sitelerden gördüğü ara sertifikaları önbellekte tutar veya sertifikadaki AIA alanından indirir; zincir eksik olsa bile sayfayı yeşil açar. Firefox, eski Android sürümleri, Java istemcileri ve pek çok mobil uygulama bunu yapmaz ve "Bağlantınız gizli değil" uyarısı verir. Yönetici testi geçer, müşterinin telefonunda site açılmaz.

Kendi tarayıcınız burada geçersiz tanıktır; doğrulamayı zinciri önbelleklemeyen bir araçla yapın:

# Sunucunun gönderdiği zinciri olduğu gibi listele
openssl s_client -connect ornek.com:443 -servername ornek.com -showcerts </dev/null 2>/dev/null | grep -E 's:|i:'

# Zincir tam mı, doğrulama sonucu ne
openssl s_client -connect ornek.com:443 -servername ornek.com </dev/null 2>/dev/null | grep 'Verify return code'

Verify return code: 0 (ok) görmüyorsanız veya çıktıda yalnızca tek bir sertifika varsa zincir eksiktir. Çözüm, sağlayıcının verdiği CA bundle dosyasını sunucu yapılandırmasına eklemektir. Konunun tamamı ara sertifika hatası yazısında.

Kullanıcının Kendi Tarafındaki Üç Klasik#

Yukarıdaki hiçbir madde tutmuyorsa sorun büyük ihtimalle karşı taraftadır ve üç yerden birindedir.

Modem veya kurum DNS'i. Bazı modemler önbelleği haftalarca tutar, bazı kurum ağları ise iç DNS sunucusunda alan adınız için elle yazılmış eski bir kayıt taşır. Modem yeniden başlatılınca düzelen her sorun bu kategoridedir.

Hosts dosyası. Site taşırken test için satır ekleyip silmeyi unutan biri aylarca eski sunucuya gitmeye devam eder. Kullanıcıya C:\Windows\System32\drivers\etc\hosts dosyasını Not Defteri ile açıp alan adınızı aratmasını söyleyin; yöntemin doğru kullanımı hosts dosyası ile site test etme yazısında.

HSTS ve tarayıcı önbelleği. Sertifikanızın bozuk olduğu bir dönemde siteyi ziyaret eden tarayıcı HSTS kaydını tutar ve sertifika düzeldikten sonra bile uyarıyı geçirmez; Chrome'da chrome://net-internals/#hsts ekranından kaydı silmek çözer. Gizli sekmede açılıyorsa suçlu eklenti, çerez veya önbellektir.

Belirti, Neden ve Doğrulama Özeti#

Sırayı koruyun: önce erişim kaydında istek var mı, sonra güvenlik duvarı, sonra DNS, sonra IPv6, en son uygulama katmanı. Ters yönden başlayıp kod ya da eklenti aramak, paketin sunucuya hiç ulaşmadığı vakalarda saatler yakar. Kısmi erişim sorunları tekrarlar; hangi müşterinin hangi çıkış IP'siyle bağlandığını not ederseniz ikinci çağrı beş dakikada kapanır.

Sıkça Sorulan Sorular#

Site sadece bir kullanıcıda açılmıyorsa sunucuda bir sorun var mıdır?#

Genellikle vardır, ama sizin göremediğiniz bir yerde. Sunucu servisi çalışıyor olabilir ve aynı anda güvenlik duvarı belirli bir IP'yi düşürüyor, GeoIP kuralı belirli bir ülkeyi kesiyor ya da ModSecurity belirli bir isteği reddediyor olabilir. Bunların hiçbiri sunucu izleme araçlarında arıza olarak görünmez. Bu yüzden teşhis, kullanıcının çıkış IP'sini alıp o IP'yi sunucu kayıtlarında aramakla başlar.

Müşterinin IP'sini beyaz listeye almak güvenli mi?#

Sabit ve bilinen bir kurumsal çıkış IP'si için güvenlidir ve tekrarlayan banları kalıcı olarak bitirir. Ancak dinamik ev IP'lerini veya mobil operatörlerin paylaşımlı CGNAT adreslerini beyaz listeye almayın: o adres yarın bambaşka birine düşer ve siz farkında olmadan bir saldırgana muafiyet tanımış olursunuz. Kural olarak yalnızca müşterinin size yazılı olarak bildirdiği sabit IP'leri kalıcı listeye alın.

Kullanıcı mobil veride açabiliyorsa sorun kesinlikle kendi ağında mıdır?#

Neredeyse her zaman öyledir, ama iki istisna vardır. Birincisi, sorun ağın çıkış IP'sinin sizin güvenlik duvarınızda yasaklı olmasıdır — bu kullanıcının ağıyla ilgilidir ama düzeltme sizin tarafınızdadır. İkincisi, ev ağının IPv6 kullanıp mobil bağlantının kullanmamasıdır; bu durumda suçlu sizin eksik IPv6 yapılandırmanızdır. İkisini ayırmak için ağın çıkış IP'sini alıp güvenlik duvarında aratın.

DNS önbelleğini temizlemek propagasyonu hızlandırır mı?#

Hayır. Temizlemek yalnızca sizin cihazınızdaki veya modeminizdeki kopyayı siler; internet servis sağlayıcısının resolver'ı kaydı kendi TTL süresince tutmaya devam eder ve sizin komutunuz oraya ulaşmaz. Propagasyonu gerçekten kısaltan tek yöntem, değişiklikten önce TTL değerini düşürmektir. Değişiklik yapıldıktan sonra TTL'i indirmek geç kalmış bir hamledir; eski değer zaten dağıtılmıştır.

Erişim kaydında kullanıcının IP'sini hiç bulamıyorum, ne anlama gelir?#

İki anlamı olabilir. Ya istek web sunucusuna hiç ulaşmamıştır — bu durumda engel güvenlik duvarı, ağ veya DNS katmanındadır. Ya da siteniz bir proxy veya CDN arkasındadır ve kayıtlarda ziyaretçinin değil proxy'nin IP'si yazılıdır. İkinciyi elemek için kayıt biçiminizi kontrol edin; gerçek IP geri kazanımı yapılandırılmamışsa engeli CDN panelinin güvenlik olayları ekranından aramanız gerekir.

403 hatası ile zaman aşımı arasındaki fark neden bu kadar önemli?#

Çünkü ikisi tamamen farklı katmanlara işaret eder. 403, isteğin sunucuya ulaştığını ve bir yazılımın onu bilinçli olarak reddettiğini gösterir; suçlu ModSecurity, .htaccess kuralı veya uygulama içi bir kısıttır. Zaman aşımı ise paketin cevapsız kaldığını, yani muhtemelen bir güvenlik duvarı tarafından sessizce düşürüldüğünü gösterir. Bu ayrım yapılmadan başlanan teşhis neredeyse her zaman yanlış katmanda saatler harcar.