cURL error 28 Hatası Nedir, WordPress'te Nasıl Çözülür?

WordPress'in Araçlar → Site Sağlığı ekranında cURL error 28: Operation timed out after 5000 milliseconds with 0 bytes received satırını gördüyseniz, WordPress bozulmadı; sunucunuz dışarıya çıkamıyor. cURL error 28, PHP'nin dış bir adrese istek gönderdiğini ama verilen süre içinde tek bayt cevap alamadığını söyleyen zaman aşımı kodudur. Aynı hata güncelleme ekranında "Yanıt alınamadı", eklenti kurulumunda "Bağlantı zaman aşımına uğradı", lisans doğrulamada ise sessiz bir başarısızlık olarak da karşınıza çıkar — kaynak hepsinde aynıdır.

Bu yazıda hatanın WordPress ayarlarında değil, neredeyse her zaman sistem katmanında olduğunu göstereceğim. Sırayla dört test yapacağız: sunucudan tek satır curl komutuyla dışarı çıkış, DNS çözümleme, giden 443 trafiğinin güvenlik duvarında kapalı olup olmadığı ve WordPress'in kendi kendine istek atabilmesi anlamına gelen loopback testi. Her testin çıktısını nasıl okuyacağınızı, hangi sonucun hangi nedeni işaret ettiğini ve düzeltmesini adım adım vereceğim. SSH erişiminiz yoksa paylaşımlı hosting için ayrı bir bölüm var; orada aynı teşhisi panel üzerinden yapmanın yolunu bulacaksınız.

cURL error 28 Tam Olarak Ne Diyor#

cURL error 28, kütüphanenin CURLE_OPERATION_TIMEDOUT kodudur ve tek bir şey anlatır: istek gönderildi, ama tanımlı süre içinde beklenen cevap gelmedi. Dikkat edilmesi gereken en önemli ayrım şudur — bu bir bağlantı reddedildi hatası değildir. Reddedilmiş olsaydı cURL error 7 (Couldn't connect to host), DNS çözümlenemeseydi cURL error 6 (Couldn't resolve host), sertifika sorunlu olsaydı cURL error 60 alırdınız. 28 kodu, "hiçbir şey olmadı, bekledim ve bıktım" demektir.

Hata mesajının içindeki milisaniye değeri de bilgi taşır:

cURL error 28: Operation timed out after 5001 milliseconds with 0 bytes received
cURL error 28: Resolving timed out after 5000 milliseconds
cURL error 28: Connection timed out after 10002 milliseconds

Üçü farklı yerde takıldığınızı söyler. Resolving timed out DNS aşamasında, Connection timed out TCP bağlantısı kurulurken, 0 bytes received ise bağlantı kurulup cevap beklenirken zaman aşımına uğrandığını gösterir. Sadece bu tek kelimeye bakarak teşhisin yarısını yapabilirsiniz.

5000 milisaniye değeri de tesadüf değildir: WordPress'in HTTP isteklerinde kullandığı varsayılan zaman aşımı süresi kısa tutulmuştur, çünkü bir dış servisin yavaşlığı yüzünden yönetim panelinin kilitlenmesi istenmez. Yani 5 saniyede cevap gelmeyen her dış çağrı bu hatayı üretir.

Hatanın WordPress'te Nerede Görüldüğü#

Aynı kök neden, WordPress'in farklı ekranlarında farklı yüzlerle çıkar. Hangi ekranda gördüğünüz, hangi adresin engellendiğine dair ipucu verir:

Bu tablonun pratik değeri şudur: hepsi bozuksa sorun sunucunun genel dışarı çıkışındadır. Sadece loopback bozuksa sorun kendi alan adınızın sunucu içinden çözümlenmesindedir. Sadece tek bir servis bozuksa o servisin IP bloğu ya da o servisin kendisi engelliyordur. İlk ayrımı yapmadan yapılan her müdahale kör atıştır.

Site Sağlığı ekranındaki diğer uyarıların ne anlama geldiğini toplu olarak görmek isterseniz WordPress site sağlığı uyarıları yazısı iyi bir tamamlayıcıdır.

Adım 1: Sunucudan Tek Satır curl Testi#

Teşhisin can alıcı noktası burasıdır: hatayı WordPress'in dışında, doğrudan sunucunun kabuğundan yeniden üretmek. SSH ile bağlanıp şu komutu çalıştırın:

curl -o /dev/null -s -w 'kod:%{http_code} dns:%{time_namelookup}s baglanti:%{time_connect}s tls:%{time_appconnect}s toplam:%{time_total}s\n' \
  --max-time 15 https://api.wordpress.org/core/version-check/1.7/

Bu tek satır, sürecin her aşamasının kaç saniye sürdüğünü ayrı ayrı yazdırır. Çıktıyı şöyle okuyun:

kod:200 dns:0.012s baglanti:0.045s tls:0.121s toplam:0.318s

Bu sağlıklı bir çıktıdır — sunucu dışarı çıkabiliyor demektir. Sorunlu çıktılar ise şöyle görünür:

• dns süresi 5 saniyeye yakın veya komut Could not resolve host diyor: DNS çözümlenemiyor. Adım 2'ye geçin.
• dns normal ama baglanti süresi zaman aşımına gidiyor: TCP bağlantısı kurulamıyor; klasik güvenlik duvarı belirtisidir. Adım 3'e geçin.
• baglanti tamam ama tls takılıyor: TLS el sıkışması engelleniyor; araya giren bir denetim cihazı ya da eski bir TLS yapılandırması olabilir.
• Her şey tamam, toplam süre çok yüksek: Karşı taraf yavaş veya sunucunun çıkış bant genişliği tıkanmış.

Komutun WordPress ile aynı koşullarda çalıştığından emin olmak için PHP üzerinden de test edin; bazı durumlarda kabuk kullanıcısı ile web sunucusu kullanıcısının ağ erişimi farklı olabilir:

sudo -u www-data php -r '
$c = curl_init("https://api.wordpress.org/core/version-check/1.7/");
curl_setopt($c, CURLOPT_RETURNTRANSFER, true);
curl_setopt($c, CURLOPT_TIMEOUT, 15);
curl_exec($c);
echo "hata: " . curl_errno($c) . " - " . curl_error($c) . PHP_EOL;
echo "http: " . curl_getinfo($c, CURLINFO_HTTP_CODE) . PHP_EOL;'

hata: 0 görüyorsanız PHP dışarı çıkabiliyordur ve sorun WordPress katmanındadır. hata: 28 görüyorsanız teşhis kesinleşmiştir: sorun sistem katmanındadır ve WordPress'te değiştireceğiniz hiçbir ayar bunu düzeltmez. curl komutunun genel kullanımı için curl ile HTTP istekleri rehberine bakabilirsiniz.

Adım 2: DNS Çözümleniyor mu#

Sunucu bir adı IP'ye çeviremiyorsa dışarıya hiçbir istek gidemez ve sonuç zaman aşımı olur. Önce çözümlemeyi test edin:

getent hosts api.wordpress.org
dig +short api.wordpress.org
dig +short @1.1.1.1 api.wordpress.org

Üç komutun ilki sistemin kendi çözümleyicisini, ikincisi yapılandırılmış DNS sunucusunu, üçüncüsü ise dış bir çözümleyiciyi kullanır. Aradaki fark teşhisi verir:

• Üçü de sonuç veriyor: DNS sağlıklı, Adım 3'e geçin.
• Üçüncü çalışıyor ama ilk ikisi çalışmıyor: Sunucunun tanımlı DNS sunucusu cevap vermiyor demektir. Yapılandırmayı düzeltmeniz gerekir.
• Üçü de çalışmıyor: Giden 53 numaralı port da engellenmiş olabilir; bu, güvenlik duvarı sorunuyla iç içedir.

Tanımlı çözümleyiciyi görmek için:

cat /etc/resolv.conf
resolvectl status | head -20

/etc/resolv.conf içinde ulaşılamayan ya da artık kullanılmayan bir DNS sunucusu yazıyorsa, her isteğin başına birkaç saniyelik bir bekleme eklenir. Bu, cURL error 28'in en sinsi nedenlerinden biridir: site "bazen" çalışır, çünkü çözümleyici bazen ilk sunucudan cevap alamayıp ikinciye düşer ve toplam süre 5 saniyeyi aşar.

Kalıcı düzeltme, sistemin ağ yapılandırmasında güvenilir bir çözümleyici tanımlamaktır. systemd-resolved kullanan bir sistemde /etc/systemd/resolved.conf içindeki DNS= satırını doldurup servisi yeniden başlatmak doğru yoldur; netplan kullanıyorsanız arayüz tanımındaki nameservers bölümüne yazıp netplan apply çalıştırın. /etc/resolv.conf dosyasını doğrudan düzenlemek çoğu modern dağıtımda kalıcı olmaz — dosya her yeniden başlatmada üretilir.

Adım 3: Giden 443 Trafiği Güvenlik Duvarında mı Kapalı#

Türkçe kaynaklarda neredeyse hiç yazılmayan ama vakaların çoğunu açıklayan neden budur: sunucunun giden HTTPS trafiği engellenmiştir. Çoğu güvenlik duvarı şablonu gelen trafiği titizlikle yapılandırır, giden trafiği ise ya varsayılan olarak açık bırakır ya da sıkılaştırma sırasında yanlışlıkla kapatır. Kapatıldığında site normal çalışmaya devam eder — ziyaretçiler siteye ulaşır, çünkü o gelen trafiktir — ama WordPress dışarıyla konuşamaz.

Önce çıplak bir bağlantı testi yapın:

nc -zv -w 5 api.wordpress.org 443
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/api.wordpress.org/443' && echo "acik" || echo "kapali"

Sonra kurallara bakın. Hangi güvenlik duvarını kullandığınıza göre:

# ufw
sudo ufw status verbose

# iptables
sudo iptables -L OUTPUT -n -v --line-numbers

# nftables
sudo nft list ruleset | sed -n '/chain output/,/}/p'

ufw status verbose çıktısında şu satırı arayın:

Default: deny (incoming), deny (outgoing), disabled (routed)

deny (outgoing) yazıyorsa neden bulunmuştur. Giden HTTPS ve DNS trafiğine izin verin:

sudo ufw allow out 443/tcp
sudo ufw allow out 80/tcp
sudo ufw allow out 53
sudo ufw reload

iptables kullanıyorsanız OUTPUT zincirinin varsayılan politikası DROP ise aynı sorun geçerlidir:

sudo iptables -A OUTPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

Kuralları kalıcı hâle getirmeyi unutmayın (iptables-save ya da netfilter-persistent save), aksi hâlde ilk yeniden başlatmada sorun geri gelir. Kural yazımının ayrıntıları için UFW güvenlik duvarı rehberi iyi bir başlangıçtır.

cPanel/WHM sunucularında ek bir katman daha vardır: CSF. Yönetici tarafında /etc/csf/csf.conf dosyasındaki TCP_OUT satırında 443 ve 80'in bulunması gerekir. Bir IP'nin neden engellendiğini görmek için:

sudo csf -g 198.51.100.10

Bir başka yaygın senaryo, sunucunun bulut sağlayıcı tarafındaki ağ güvenlik grubu kurallarıdır. Sunucunun içindeki güvenlik duvarı tertemiz olsa bile, dışarıdaki ağ katmanı giden trafiği kısıtlıyor olabilir. Sunucu içi testler temiz çıkıyor ama bağlantı yine de kurulamıyorsa bu katmanı kontrol edin.

Adım 4: Loopback Testi — Site Kendine Ulaşabiliyor mu#

Site Sağlığı ekranında özellikle "REST API" ve "loopback isteği" uyarıları varsa, sorun dış dünya değil, sunucunun kendi alan adını kendi içinden çözememesidir. WordPress bazı işleri (zamanlanmış görevler, tema/eklenti düzenleyicinin güvenlik kontrolü, blok editörünün bazı istekleri) kendi sitesine HTTP isteği atarak yapar.

Sunucudan kendi sitenize istek atın:

curl -I --max-time 10 https://ornek.com/wp-json/
curl -I --max-time 10 https://ornek.com/wp-cron.php

Bu istek zaman aşımına uğruyorsa nedenler şunlardır:

1. Hairpin NAT eksikliği. Sunucu kendi genel IP'sine bağlanmaya çalışıyor ama ağ bunu kendine geri döndürmüyor. Çözüm, sunucunun /etc/hosts dosyasına alan adını kendi iç IP'siyle eşleyen bir satır eklemektir:

echo "127.0.0.1 ornek.com www.ornek.com" | sudo tee -a /etc/hosts

2. Site bir güvenlik katmanının arkasında ve sunucunun kendi isteği bot sanılıyor. Bazı koruma servisleri sunucunun kendi IP'sinden gelen isteği şüpheli bulup zorlayıcı bir kontrol ekranına düşürür. Sunucunun kendi çıkış IP'sini izin listesine eklemek çözer.
3. Temel kimlik doğrulama (.htpasswd) açık. Site geliştirme aşamasında parola korumasına alınmışsa, loopback isteği 401 alır ve WordPress bunu başarısızlık olarak raporlar.
4. HTTPS zorlaması ile sertifika uyuşmazlığı. Sunucu kendine bağlanırken sertifika doğrulaması takılıyorsa istek bitmez.

WordPress'in zamanlanmış görevlerini loopback üzerinden çalıştırması bu yüzden kırılgandır. Kalıcı ve güvenilir çözüm, WordPress'in kendi tetikleyicisini kapatıp işi sistem cron'una devretmektir:

// wp-config.php
define( 'DISABLE_WP_CRON', true );

# crontab -e
*/5 * * * * cd /var/www/ornek.com && /usr/bin/php wp-cron.php > /dev/null 2>&1

Bu değişiklik, hem loopback sorununu dolaşır hem de yoğun trafikte her ziyaretçinin cron tetiklemesini engelleyerek performansı iyileştirir. REST API'nin nasıl çalıştığını ve hangi uç noktaların hangi işlemlerde kullanıldığını anlamak için WordPress REST API yazısına bakabilirsiniz.

Adım 5: WordPress Tarafındaki Ayarlar ve Eklenti Çakışması#

Sistem katmanı temiz çıktıysa sıra WordPress'e gelir. Burada üç şey kontrol edilir.

Zaman aşımı süresi. Karşı sunucu gerçekten yavaşsa varsayılan 5 saniye yetmeyebilir. Süreyi bir tema fonksiyonu ya da küçük bir eklenti dosyasıyla uzatabilirsiniz:

add_filter( 'http_request_timeout', function ( $timeout ) {
    return 20;
} );

Bunu kalıcı bir çözüm olarak değil, yavaş bir dış servisle yaşamak zorundaysanız bir tampon olarak düşünün. Süreyi 60 saniyeye çıkarmak yönetim panelini kilitler.

Dış istek engelleme sabitleri. wp-config.php içinde geçmişte eklenmiş bir satır tüm dış istekleri kapatıyor olabilir:

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.wordpress.org' );

İlk sabit true ise WordPress, ikinci satırdaki listede olmayan hiçbir adrese istek atmaz. Geliştirme ortamından kopyalanan yapılandırmalarda sık rastlanır ve saatlerce yanlış yerde aranır. wp-config.php dosyasını baştan sona okumadan bu satırların varlığını fark etmek zordur, o yüzden teşhis sırasında dosyayı tümüyle gözden geçirin.

Eklenti çakışması. Bazı güvenlik ve önbellek eklentileri giden istekleri kendi filtrelerinden geçirir ya da vekil sunucu üzerinden yönlendirir. Test için eklentileri toplu devre dışı bırakmak yerine kademeli yöntem kullanın:

wp plugin deactivate --all
# Site Sağlığı'nı kontrol edin, sonra teker teker:
wp plugin activate eklenti-adi

WP-CLI kurulu değilse aynı işi FTP üzerinden wp-content/plugins klasörünü geçici olarak yeniden adlandırarak yapabilirsiniz; klasör adı değiştiğinde WordPress tüm eklentileri devre dışı sayar ve adı geri verdiğinizde ayarlar kaybolmadan geri gelir.

Belirti ile Neden Eşleme Tablosu#

Aşağıdaki tablo, buraya kadar anlatılan tüm testlerin sonuçlarını tek bakışta karara bağlar:

Paylaşımlı Hostingte Ne Yapabilirsiniz#

SSH erişiminiz yoksa yukarıdaki komutların çoğunu çalıştıramazsınız, ama teşhisi yine de yapabilirsiniz. cPanel'de Terminal özelliği açıksa doğrudan aynı curl komutlarını kullanabilirsiniz. Kapalıysa, sitenizin kök dizinine geçici bir PHP dosyası koyup tarayıcıdan çağırın:

<?php
// tani.php — test bitince MUTLAKA silin
header('Content-Type: text/plain; charset=utf-8');
$hedefler = [
    'https://api.wordpress.org/core/version-check/1.7/',
    'https://downloads.wordpress.org/',
];
foreach ($hedefler as $url) {
    $c = curl_init($url);
    curl_setopt($c, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($c, CURLOPT_TIMEOUT, 15);
    curl_setopt($c, CURLOPT_NOBODY, true);
    curl_exec($c);
    printf(
        "%s\n  hata:%d (%s)\n  http:%d dns:%.3fs baglanti:%.3fs toplam:%.3fs\n\n",
        $url,
        curl_errno($c),
        curl_error($c),
        curl_getinfo($c, CURLINFO_HTTP_CODE),
        curl_getinfo($c, CURLINFO_NAMELOOKUP_TIME),
        curl_getinfo($c, CURLINFO_CONNECT_TIME),
        curl_getinfo($c, CURLINFO_TOTAL_TIME)
    );
    curl_close($c);
}

Bu dosyayı tarayıcıdan açtığınızda, sunucunun dışarı çıkışına dair Adım 1'deki bilginin aynısını elde edersiniz. Çıktıda hata:28 görüyorsanız sorun sunucudadır ve çözümü sizin elinizde değildir — destek talebine bu çıktıyı yapıştırmak, sağlayıcının konuyu doğru mühendise yönlendirmesini sağlar. Testi bitirdiğinizde dosyayı mutlaka silin; sunucunun dışarı çıkış davranışını gösteren bir dosyayı açıkta bırakmak gereksiz bir bilgi ifşasıdır.

Paylaşımlı hostingte bir başka olasılık daha vardır: bazı sağlayıcılar giden bağlantıları güvenlik nedeniyle kısıtlar ve yalnızca beyaz listedeki adreslere izin verir. Kullandığınız premium eklentinin lisans sunucusu bu listede değilse, o adresin izin listesine eklenmesini talep etmeniz gerekir.

Kalıcı Önlemler#

Hatayı çözdükten sonra tekrar etmesini önlemek için üç alışkanlık edinin.

1. Güvenlik duvarı sıkılaştırmasını giden trafiği test ederek tamamlayın. Sunucuyu sertleştirdiğiniz her seferde curl -I https://api.wordpress.org/ gibi tek satırlık bir çıkış testi yapın. Bu, sertleştirme kontrol listenizin son maddesi olsun.
2. wp-cron'u sistem cron'una taşıyın. Loopback bağımlılığını ortadan kaldırdığı için hem bu hataya hem de zamanlanmış görevlerin sessizce çalışmamasına karşı koruma sağlar.
3. Site Sağlığı ekranını düzenli kontrol edin. Bu ekran, henüz kullanıcıya yansımamış sorunları erkenden gösterir; ayda bir bakmak, güncellemelerin sessizce durmuş olduğunu aylar sonra fark etmekten iyidir.

Sitenizin genel yavaşlığı da zaman aşımı eşiğini zorlayabildiği için sunucu yükünü düzenli izlemekte fayda var. WordPress'te e-posta gönderiminin bu hataya takılması da özellikle yaygındır: API tabanlı bir e-posta servisi kullanıyorsanız o servisin adresi engellendiğinde siteden hiçbir bildirim çıkmaz ve hata mesajı hiçbir yerde görünmez.

Sıkça Sorulan Sorular#

cURL error 28 hatası sitemi ziyaretçiler için de bozar mı#

Doğrudan bozmaz, çünkü hata sunucunun dışarı çıkışıyla ilgilidir; ziyaretçilerin sitenize gelmesi ise gelen trafiktir ve bu yoldan bağımsızdır. Ancak dolaylı etkileri ciddidir: ödeme geçidi çağrısı, kargo entegrasyonu, e-posta gönderimi veya harici bir API'den veri çeken bir bileşen varsa bunlar çalışmayı durdurur. Ayrıca sayfa yüklenirken yapılan her dış çağrı zaman aşımına kadar bekleyeceği için sayfa açılış süresi belirgin biçimde uzar. Yani ziyaretçi hata görmese bile deneyim bozulur.

WordPress zaman aşımı süresini artırmak sorunu çözer mi#

Yalnızca karşı taraf gerçekten yavaşsa çözer; bağlantı hiç kurulamıyorsa süreyi uzatmak sadece daha uzun beklemenizi sağlar. Ayrımı yapmanın yolu, sunucudan doğrudan curl çalıştırıp bağlantı ve DNS sürelerini ayrı ayrı görmektir. Bağlantı aşamasında takılıyorsanız neden güvenlik duvarı ya da DNS'tir ve süre ayarı hiçbir şey değiştirmez. Süreyi artırmak gerekiyorsa da ölçülü olun; yüksek değerler yönetim panelinin uzun süre yanıtsız kalmasına yol açar.

Site Sağlığı'nda REST API hatası var ama site sorunsuz çalışıyor#

Bu, loopback sorununun tipik görünümüdür ve normaldir. Sunucu kendi alan adına içeriden ulaşamıyor ama dışarıdan gelen ziyaretçiler için hiçbir engel yok. Görünür etkisi genellikle blok editöründe kaydetme sorunları, zamanlanmış görevlerin çalışmaması ve bazı eklentilerin sessizce işlev kaybetmesidir. Çözümü, sunucunun hosts dosyasına kendi alan adını iç IP ile eşleyen bir satır eklemek ve wp-cron'u sistem cron'una taşımaktır.

Hata bazen çıkıp bazen kaybolmasının nedeni ne#

Aralıklı davranışın en yaygın nedeni, sistemde tanımlı DNS sunucularından birinin yanıt vermemesidir. Çözümleyici önce ulaşılamayan sunucuyu dener, zaman aşımını bekler, sonra ikinciye geçer; toplam süre bazen 5 saniyenin altında kalır bazen üstüne çıkar ve hata rastgele görünür. İkinci olasılık, karşı servisin yoğun saatlerde yavaşlamasıdır. Sunucunun DNS yapılandırmasını temizleyip yalnızca güvenilir ve hızlı çözümleyiciler bırakmak bu belirsizliği genellikle tamamen ortadan kaldırır.

Güvenlik duvarında giden trafiği açmak güvenlik riski oluşturur mu#

Giden 443 ve 53 portlarını açmak, sunucuda çalışan meşru yazılımların internetle konuşabilmesi için gereklidir ve tek başına anlamlı bir risk yaratmaz; zaten paket güncellemeleri, sertifika yenileme ve saat senkronizasyonu da bu çıkışa ihtiyaç duyar. Asıl risk, tüm giden trafiği sınırsız açmaktır. Daha titiz bir yaklaşım, giden trafiği kısıtlayıp yalnızca ihtiyaç duyulan portlara izin vermek ve kuralları belgelemektir. Sıkılaştırma yaparken de değişikliğin ardından mutlaka bir çıkış testi çalıştırın.

Paylaşımlı hostingte bu hatayı kendim çözebilir miyim#

Kısmen. Sunucunun güvenlik duvarına ve DNS yapılandırmasına erişemezsiniz, ama sorunun orada olduğunu kanıtlayabilirsiniz. Kök dizine geçici bir tanılama betiği koyup dış adreslere yaptığı isteklerin hata kodlarını görmek yeterlidir; çıktı 28 diyorsa sorun sağlayıcı tarafındadır ve destek talebi açmanız gerekir. Kendi tarafınızda kontrol edebileceğiniz şeyler ise wp-config.php içindeki dış istek engelleme sabitleri, eklenti çakışmaları ve zaman aşımı filtresidir.

Aynı hatayı cURL error 6 veya 7 olarak görüyorum, fark ne#

Üçü de dış bağlantı sorunudur ama farklı aşamalarda takılırlar ve farklı yere bakmanızı söylerler. cURL error 6, adın IP'ye çevrilemediğini yani DNS sorununu; cURL error 7, sunucuya ulaşıldığını ama bağlantının aktif olarak reddedildiğini; cURL error 28 ise hiçbir cevap gelmeden sürenin dolduğunu gösterir. Pratikte 6 kodu DNS yapılandırmasına, 7 kodu karşı taraftaki kapalı porta veya reddeden güvenlik duvarına, 28 kodu ise sessizce paketleri düşüren bir engele işaret eder. Sessizce düşürme, kural yazarken REJECT yerine DROP kullanılmasının tipik sonucudur.

Kapanış#

cURL error 28, adı yüzünden bir WordPress hatası sanılır ama gerçekte bir sistem tanısıdır: sunucunuz dışarı çıkamıyor ya da kendine ulaşamıyordur. Bu yüzden çözümü de WordPress ayarlarında değil, sırayla yapılacak dört testtedir — sunucudan doğrudan curl ile çıkış denemesi, DNS çözümleme kontrolü, giden 443 trafiğinin güvenlik duvarındaki durumu ve loopback testi. Hata mesajının içindeki tek kelime bile (Resolving, Connection, 0 bytes received) hangi testten başlamanız gerektiğini söyler. Bu sırayı izlediğinizde teşhis genellikle beş dakikayı geçmez ve düzeltme tek bir güvenlik duvarı kuralı ya da tek bir DNS satırı kadar basit olur.

Sunucunun güvenlik duvarı, DNS ve cron yapılandırmasını kendiniz yönetmek istemiyorsanız bu işleri devralan bir çözüm hayatınızı kolaylaştırır: WordPress hosting paketlerinde bu katman hazır ve doğru yapılandırılmış gelir, sitenizin güncelleme ve bakım döngüsünü tamamen devretmek isterseniz WordPress bakım hizmeti devreye girer. Kendi kurallarınızı yazmak istiyorsanız tam yetkili bir VDS sunucu doğru tercihtir; sertleştirme ve izlemeyi uzman bir ekibe bırakmak için de sunucu yönetimi hizmetine bakabilirsiniz.