Nginx – Saviorhost İnternet Hizmetleri

500 Internal Server Error: Neden Olur, Nasıl Çözülür? (cPanel, WordPress, Nginx/Apache Rehberi)

admincim — Wed, 15 Apr 2026 07:19:43 +0000

Sitenizde aniden beliren “500 Internal Server Error” hatası, tarayıcınızın veya internetinizin değil; doğrudan sunucunun bir şeyleri işleyemediğinin çığlığıdır. Hatalı .htaccess kuralları, yanlış dosya izinleri veya yetersiz PHP bellek limitleri en yaygın yazılımsal nedenlerdir. Ancak sorun kodlarınızda değilse, sunucunuzun işlemci (CPU) darboğazına girmiş veya PHP Worker limitlerini doldurmuş olma ihtimali çok yüksektir. Bu devasa rehberde, 500 hatasını sıradan bir kullanıcı gibi değil, bir Sistem Yöneticisi (SysAdmin) gibi nasıl teşhis edip çözeceğinizi adım adım anlatıyoruz.

Web sitenizde gezinirken, yeni bir içerik yayımlamaya çalışırken veya en kötüsü kritik bir e-ticaret (WooCommerce) ödemesi sırasında aniden karşınıza çıkan bembeyaz bir sayfadaki “500 Internal Server Error” yazısı, bir webmaster’ın en büyük kabusudur. E-ticaret siteleri için bu hata sadece teknik bir sorun değil, doğrudan ciro ve itibar kaybıdır.

Çoğu kaynak bu hatayı çözmek için size “Tüm eklentilerinizi kapatın, temanızı değiştirin ve tek tek açarak test edin” gibi saatler sürecek, amatörce tavsiyeler verir. Oysa bir sunucu mimarisini anlayan teknik bir uzman gibi yaklaşırsanız, sorunun kaynağını dakikalar içinde bulabilirsiniz. SaviorHost mühendislik ekibi olarak, 500 hatasının arka planındaki mimariyi, gizli kalmış tetikleyicileri ve kesin çözüm yollarını masaya yatırıyoruz.

1. Karanlıkta El Yordamıyla Aramayı Bırakın: Hata Loglarını (Error Logs) Okuyun

500 hatası aslında “Genel (Catch-all)” bir koddur. Sunucu, güvenlik nedeniyle hatanın gerçek nedenini (örneğin hangi veritabanı tablosunun çöktüğünü) doğrudan ekrana yazdırarak ziyaretçiye (ve olası saldırganlara) göstermez. Gerçek nedeni bulmanın tek yolu Error Logs (Hata Günlükleri) dosyasına bakmaktır.

Sunucu Panelinden Kontrol: Kontrol panelinizden (KeyHelp, cPanel, Plesk) “Error Log” veya “Hata Kayıtları” bölümüne girin. Burada Apache veya Nginx’in tuttuğu son 300 hatayı saniyesi saniyesine görebilirsiniz.
WordPress Debug Modu: Eğer WordPress kullanıyorsanız, FTP üzerinden wp-config.php dosyasına girip aşağıdaki satırları bularak “true” olarak değiştirin (veya yoksa ekleyin):
PHP
```
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
```
Bu işlemden sonra, /wp-content/ klasörünüzün içinde debug.log adında bir dosya oluşacaktır. Bu dosyayı açtığınızda hatanın hangi eklentinin hangi satırından koptuğunu net bir şekilde görebilirsiniz. Sorunu çözdükten sonra bu değerleri tekrar false yapmayı unutmayın.

2. En Yaygın Fail: Bozuk veya Şişmiş `.htaccess` Dosyası

500 hatalarının %70’inden fazlası Apache veya LiteSpeed sunucularında yanlış yapılandırılmış bir .htaccess dosyasından kaynaklanır. Yeni bir SEO eklentisi kurduğunuzda, önbellek (Cache) temizliği yaptığınızda veya SSL (HTTP’den HTTPS’ye) yönlendirmesi eklediğinizde, bu dosyaya hatalı bir noktalı virgül (;) veya geçersiz bir RewriteRule eklenmiş olabilir.

Kesin Çözüm Yöntemi:

FTP veya Dosya Yöneticisi üzerinden sitenizin kök dizinine (public_html veya httpdocs) bağlanın.
Gizli dosyaları göster seçeneğinin açık olduğundan emin olun ve .htaccess dosyasını bulun.
Dosyanın adını .htaccess_yedek olarak değiştirerek devre dışı bırakın.
Sitenizi yenileyin. Eğer siteniz sorunsuz açılıyorsa (alt sayfalar 404 verebilir, normaldir), sorun kesinlikle bu dosyadadır.
WordPress panelinize girin, Ayarlar > Kalıcı Bağlantılar (Permalinks) sekmesine gidin ve hiçbir değişiklik yapmadan doğrudan “Değişiklikleri Kaydet” butonuna basın. WordPress sizin için tertemiz, hatasız ve orijinal bir .htaccess dosyası üretecektir.

3. Yanlış Dosya İzinleri (Permissions) ve Sahiplik (Ownership/Chown) Krizleri

Linux işletim sistemlerinde güvenlik ve izolasyon en üst düzeydedir. Eğer bir PHP dosyasının veya klasörün okuma/yazma izni yanlış ayarlanmışsa (özellikle 777 gibi tehlikeli izinler verilmişse), sunucunun güvenlik mekanizmaları (suPHP veya PHP-FPM yapılandırmaları) bu dosyayı çalıştırmayı reddeder ve anında 500 hatası fırlatır.

İdeal Linux İzin Yapılandırması Şöyle Olmalıdır:

Tüm klasörler (Directories) 755 yetkisine sahip olmalıdır.
Tüm dosyalar (Files) 644 yetkisine sahip olmalıdır.
wp-config.php gibi kritik veritabanı şifrelerini barındıran dosyalar ekstra güvenlik için 440 veya 400 yapılabilir.

Sahiplik (Ownership) Sorunu: Bazen dosyaların izinleri doğru olsa bile, dosyayı oluşturan kullanıcı (Owner) yanlıştır. Dosyalar root kullanıcısına aitse ve web sunucusu (örneğin www-data veya kendi kullanıcı adınız) bunu okumaya çalışırsa 500 hatası alırsınız. Bu durumu hosting firmanızın destek ekibine “Chown (Sahiplik) yetkilerimi sıfırlayabilir misiniz?” diyerek saniyeler içinde çözdürebilirsiniz.

4. PHP Memory Limit (Bellek) Yetersizliği ve Max Execution Time Darboğazı

Ağır bir e-ticaret siteniz, çok fazla varyasyona sahip ürünleriniz veya Elementor/WPBakery gibi çok kaynak tüketen sayfa yapılandırıcılarınız varsa, PHP’nin tek bir işlemi tamamlamak için ihtiyaç duyduğu RAM (Bellek) miktarı sunucunuzun size ayırdığı limiti aşabilir. Bu durumda PHP işlemi aniden çöker (Fatal Error: Allowed memory size exhausted) ve ekrana 500 hatası yansır.

Benzer şekilde, bir işlem çok uzun sürerse (örneğin XML ürün içe aktarma), max_execution_time (maksimum çalışma süresi) sınırı dolar ve işlem yarıda kesilir.

Nasıl Çözülür? wp-config.php dosyanıza şu satırları ekleyerek limitleri artırmayı deneyin:

PHP 

define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '1024M');

Ayrıca .htaccess dosyanıza veya kontrol panelinizdeki MultiPHP INI düzenleyicisine şu satırları ekleyebilirsiniz: php_value max_execution_time 300

Önemli Not: Eğer bu kodları eklemenize rağmen hata devam ediyorsa, hosting firmanız arka planda (CloudLinux vb. üzerinden) donanımsal bir tavan limit koymuş ve sizin bunu aşmanıza izin vermiyor demektir.

5. ModSecurity (WAF) Yanlış Pozitif Engellemeleri

Sunucularda sitenizi siber saldırılardan korumak için Web Application Firewall (WAF) veya ModSecurity adı verilen güvenlik duvarları bulunur. Bazen tamamen masum bir işlem; örneğin uzun bir makale kaydetmek, karmaşık bir SQL sorgusu çalıştırmak veya tema ayarlarında çok fazla parametre kaydetmek, ModSecurity tarafından “SQL Injection Saldırısı” olarak algılanır. Sistem anında isteği keser ve sizi 500 veya 403 hatasıyla cezalandırır.

Eğer belirli bir sayfayı kaydederken hep aynı hatayı alıyorsanız, kontrol panelinizden geçici olarak ModSecurity’i kapatıp işlemi tekrar deneyin. İşlem başarılı olursa, sorunun bir “False Positive” (Yanlış Alarm) olduğunu anlarsınız.

6. Acı Gerçek: Sorun Kodlarınızda Değil, Sunucunuzun Gücündedir!

Yazılımsal tüm testleri yaptınız, .htaccess tertemiz, eklentiler güncel, RAM limitleri en üstte ama siteniz biraz trafik aldığında veya bir kampanya döneminde hala 500 (veya 503/508) hataları veriyorsa, sorun arka plandaki hantal sunucu mimarisindedir.

Standart hosting altyapılarında şu darboğazlar yaşanır:

PHP Worker Yetersizliği: Ucuz hostinglerde size genellikle sadece 10-20 arası PHP işçisi (Worker) tahsis edilir. Anlık 30 kişi sitenize girip sepete ürün eklediğinde veya arama yaptığında, PHP kuyruğu tıkanır. İşçiler yetişemediği için sistem yeni gelen müşterilere 500/503 hatası gösterir.
Hantal Panellerin RAM Sömürüsü: Arka planda sunucu kaynaklarını ağırlaştıran paneller (eski nesil CWP veya cPanel yapıları), sitenize kalması gereken RAM’i kendi servislerini ayakta tutmak için kullanır.

SaviorHost ile Darboğazlara Veda Edin

Biz SaviorHost olarak 500 hatalarını eklenti kapatarak veya ziyaretçi sayınızı kısıtlayarak değil, saf mühendislik ve ham donanım gücüyle çözüyoruz:

AMD Ryzen™ 9 7900 İşlemci Gücü: Eski nesil standart işlemcilerin kuyrukta beklettiği PHP sorgularını, inanılmaz tek çekirdek (IPC) gücü sayesinde milisaniyeler içinde işliyoruz.
50 PHP Worker Ayrıcalığı: Yoğun trafikli siteleriniz ve e-ticaret operasyonlarınız için rakiplerin sunmadığı düzeyde geniş bir PHP işlemci havuzu sağlıyoruz. Siteniz yoğun anlarda bile nefes alıyor.
KeyHelp ile Özgür Bırakılan RAM: Sunucu kaynaklarını sömürmeyen Alman mimarisi KeyHelp paneli sayesinde, tüm RAM kapasitesi ve 7GB/s NVMe okuma hızı doğrudan web sitenize tahsis ediliyor.

Sürekli hata logları okumaktan, “Sitem neden çöktü?” diye düşünmekten ve yavaşlık yüzünden müşteri kaybetmekten sıkıldıysanız; gerçek performansla tanışmanın vakti gelmiştir. Sorunsuz altyapımız için Premium Linux Web Hosting paketlerimizi 15 Gün İade Garantisiyle hemen inceleyin, farkı kendi gözlerinizle görün.

Web Sitelerinde Spam Trafiğini Engelleme (2025 Rehberi)

admincim — Wed, 22 Oct 2025 13:31:44 +0000

Neden “bot” ≠ tek tip? (Tehdit modelini oturt)

Spam trafiği; credential stuffing, carding, scraping, brute force, form spam, API kötüye kullanımı gibi farklı otomasyon davranışlarından oluşur. OWASP’ın Automated Threats to Web Applications (OAT) sınıflandırması, hangi uç noktalar için hangi saldırıların tipik olduğuna dair ortak bir dil sağlar; savunmayı tek bir CAPTCHA’ya indirgemek yerine tehdit odaklı düşünmeyi kolaylaştırır. owasp.org+1

Ana savunma katmanları (özet strateji)

WAF + kural setleri: ModSecurity ile OWASP Core Rule Set (CRS) başlangıç bariyeri sağlar; SQLi/XSS gibi klasik istismarlara ek olarak brute force ve hız sınırlamaya yardımcı kurallar içerir. owasp.org+1
Oran sınırlama (rate limit) / bağlantı kotası: Nginx’in limit_req ve limit_conn modülleri IP ya da özel anahtarlar (örn. IP+username) üzerinden istek hızını düşürür; leaky-bucket algoritması kullanır. nginx.org+1
Risk skorlu doğrulama: Cloudflare Turnstile gibi “sessiz” tarayıcı sinyali tabanlı çözümler; düşük güven hâlinde hafif challenge göstererek sürtünmeyi azaltır. Google reCAPTCHA (Enterprise), OAT kategorilerine göre akış bazlı öneriler sunar. Cloudflare Docs+2Cloudflare Docs+2
Honeypot/decoy taktikleri: Görünmeyen form alanları, sahte endpoint’ler ve (Cloudflare tarafında) AI Labyrinth gibi “yönlendirip oyalayan” çözümlemeler, robots.txt’ye uymayan yeni nesil tarayıcılara karşı etkili bir ek katmandır. The Cloudflare Blog
Scraper ekosistemi ve robots.txt gerçekliği: 2024–2025’te yayıncılar ve altyapı sağlayıcıları, robots.txt’yi yok sayan ve kimliğini gizleyen AI tarayıcılarına karşı (örn. varsayılan engelleme, “Pay Per Crawl” gibi) daha agresif önlemler duyurdu; robots.txt tek başına yeterli değil. The Verge+2Reuters+2
Ölçüm temizliği: Başarıyı ölçmek için GA4’te internal ve developer trafiğini filtrele; aksi hâlde bot azaltma etkisini göremezsin. Google Yardım
API’lere özel sıkılaştırma: 2024’te web saldırıları %33 artarken API’ler birincil hedef hâline geldi; rate limit + kimlik doğrulama + davranışsal sinyaller şart. vmblog.com+1

Uygulanabilir kontrol listesi (Hızlı başlangıç)

Kritik uçları çıkar: /login, /signup, ödeme/form akışları, /search, ürün beslemeleri ve API uçları; her birini OAT kategorisiyle eşleştir. owasp.org
WAF/CRS’i aç ve tuning yap: Hatalı pozitifleri azaltmak için istisna kuralları tanımla. CRS Project
Oran sınırla: Nginx ile IP ve akışa özgü anahtarlarla rate limiting uygula. nginx.org
Riskli akışlarda challenge: Turnstile/reCAPTCHA’yı login, kayıt ve ödeme gibi yüksek riskli akışlarda puan/karar mekanizmasıyla devreye al. Cloudflare Docs+1
Honeypot/decoy ekle: Form honeypot’ları + (Cloudflare kullanıyorsan) AI Labyrinth. The Cloudflare Blog
Scraper yönetimi: ASN/ülke/UA sinyalleriyle kurallar, hız limitleri, JSON/Feed uçlarına Accept/Referer hijyeni.
Ölçüm temizliği: GA4 iç/developer trafiğini dışla. Google Yardım
Sürekli gözlem: 429/5xx oranları, çerezsiz istek patlamaları, belirli ASN/ülkelerden ani sıçramalar için alarmlar kur.
Trendleri izle: Akamai’nin yıllık/çeyreklik SOTI raporları API/bot eğilimlerini takip için iyi bir referans. Akamai

Uygulama Taslağı (kopyala–uyarla)

A) Nginx: Oran sınırlama ve basit işaretler

Login akışı için IP + kullanıcı adı birleşik anahtar:

# X-Real-IP varsa onu kullan

map $http_x_real_ip $client_ip { default $remote_addr; }

# IP + username kombinasyonu (query/body'den 'username' geldiğini varsayalım)

map "$client_ip:$arg_username" $login_key { default $request_uri; }
# Limit alanları

limit_req_zone $client_ip zone=perip:20m   rate=10r/m;

limit_req_zone $login_key zone=peruser:20m rate=5r/m;

limit_conn_zone $client_ip zone=ipconn:10m;
server {

  location = /login {

    limit_req zone=perip burst=20 nodelay;

    limit_req zone=peruser burst=5;

    limit_conn ipconn 20;

# Basit bot işaretleri (örnek) if ($http_user_agent ~* "(curl|wget|bot|spider)") { return 429; } proxy_pass http://app_upstream; } }

Nginx’in limit_req modülü leaky-bucket yöntemiyle çalışır; anahtar seçiminde IP’nin NAT arkasında paylaşılıyor olabileceğini unutma. nginx.org+1

Form spam için honeypot + hız limiti:

Sık kazınan uçlar (search/feed/sitemap) için dar boğaz:

B) Cloudflare: Turnstile + WAF mantığı + AI Labyrinth

Turnstile entegrasyonu (özet):

Sunucuda (ör. Node) doğrularken token’ı /siteverify ile kontrol et; puan düşükse ek doğrulama iste. Turnstile, Cloudflare CDN’i kullanmasan bile gömülebilir; önce sessiz sinyaller toplar, gerekirse hafif bir challenge gösterir. Cloudflare Docs+1

AI Labyrinth (decoy sayfalarla oyalama): robots.txt’ye uymayan/bilinen AI tarayıcılarına karşı botu “labirente” sokarak kaynaklarını tüketen yeni savunma; Cloudflare üzerinde ücretsiz/opt-in sunuluyor. The Cloudflare Blog

Güncel bağlam: Cloudflare 2025’te AI crawler’ları varsayılan engelleme ve Pay Per Crawl seçeneklerini duyurdu; robots.txt’yi yok sayan botlara karşı altyapı seviyesinde kontrol sağlıyor. The Verge+1

C) AWS WAF: Bot Control + yönetilen kurallar

AWS WAF Bot Control: Bilinen bot kategorilerini (iyi/kötü) ayıran yönetilen kurallar; özel kurallarla birleştirilebilir. docs.aws.amazon.com+1

Örnek (IP başına /login rate limit + Bot Control):

[

  {

    "Name": "AllowPartners",

    "Priority": 0,

    "Statement": { "IPSetReferenceStatement": { "ARN": "arn:aws:wafv2:...:ipset/partners" } },

    "Action": { "Allow": {} },

    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AllowPartners" }

  },

  {

    "Name": "AWSBotControl",

    "Priority": 1,

    "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesBotControlRuleSet" } },

    "OverrideAction": { "None": {} },

    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "BotControl" }

  },

  {

    "Name": "RateLimitLoginPerIP",

    "Priority": 10,

    "Statement": {

      "RateBasedStatement": {

        "Limit": 300,

        "AggregateKeyType": "IP",

        "ScopeDownStatement": {

          "ByteMatchStatement": {

            "SearchString": "/login",

            "FieldToMatch": { "UriPath": {} },

            "TextTransformations": [{ "Type": "NONE", "Priority": 0 }],

            "PositionalConstraint": "STARTS_WITH"

          }

        }

      }

    },

    "Action": { "Block": {} },

    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "RateLogin" }

  }

]

D) Google reCAPTCHA (Enterprise): OAT uyumlu mimari

Google’ın OAT tehditlerine göre en iyi uygulamalar kılavuzu, kart dolandırıcılığı, credential stuffing vb. senaryolarda puan tabanlı karar akışları ve “ek doğrulama” önerir. Uygulamada, skor/bağlama göre “izin ver / MFA iste / insan doğrulaması iste / reddet” kuralı tanımla. Google Cloud+1

E) GA4: İç/developer trafiğini dışla (ölçüm temizliği)

Internal traffic: IP’leri “Define internal traffic” ile tanımla, ardından Data Filters’ta Exclude olarak aktif et. Google Yardım
(İpucu) GA4, iç trafikten gelen vuruşlara tt=internal işareti koyar; validasyonu kolaylaştırır. selnekovic.com

F) İzleme & alarm fikirleri

429/5xx oranı ve endpoint başına z-skor sapmaları.
Cookie-less istek oranı, ASN/ülke bazlı patlamalar.
Decoy/honeypot isabetleri metriki (AI Labyrinth/honeypot sayfalarına giriş).
API saldırı trendleri için Akamai’nin SOTI raporlarını periyodik takip. vmblog.com

Neden robots.txt tek başına yetmiyor?

Son 1 yılda; kimliğini gizleyen, robots.txt’yi görmezden gelen ya da UA/başlık taklidi yapan AI tarayıcılarına dair çok sayıda bulgu paylaşıldı. Bu yüzden altyapı seviyesinde engelleme (WAF/ASN/UA/Rate limit/Decoy) gereklidir. arstechnica.com+1

Kullanıcı deneyimi: “kademeli sürtünme” prensibi

Herkese CAPTCHA göstermek yerine, risk skorlu ve kademeli zorlaştırma kullanın: düşük riskli akışlarda sürtünme yok; risk yükseldikçe MFA / challenge / manuel inceleme. Turnstile ve reCAPTCHA bu modeli destekler. Cloudflare Docs+1

Ek: Somut “kural seti” taslağı (özet)

Nginx: /login için IP+username anahtarıyla limit_req; form uçlarına honeypot + saatlik limit; “sıcak” scraping uçlarına 1 r/s sınırı. nginx.org
Cloudflare: Turnstile’ı yalnızca login/signup/ödeme gibi riskli akışlara yerleştir; AI Labyrinth’i aç; bilinen AI UA’ları ve “şüpheli oran” için WAF’ta Managed Challenge uygula. Cloudflare Docs+1
AWS WAF: Önde Allowlist → Bot Control → Common Rule Set → akışa özel rate limit. docs.aws.amazon.com
GA4: Internal/Developer filtreleri Active; bot benzeri oturumlar için ayrı segment oluştur. Google Yardım
Sürekli iyileştirme: Hatalı pozitif vakalarını toplayıp istisnalar yaz; eşikleri haftalık gözden geçir.
Trend takibi: API saldırıları ve scraper davranışlarına dair Akamai SOTI raporlarını takip et. Akamai

500 Plesk\Exception\Database Hatası (SQLSTATE 2002) – Kesin Çözüm Rehberi

admincim — Tue, 14 Oct 2025 13:56:40 +0000

“500 Plesk\Exception\Database” tipik olarak Plesk’in kendi veritabanına (psa) ya da alttaki MySQL/MariaDB/Plesk SQL Server hizmetine bağlanamamasıyla oluşur. Nedeni çoğunlukla servis kapalı, disk dolu, socket/port hatası, bozulmuş psa tabloları veya geçici “repair” işlemleridir. Plesk’in resmi Repair Utility aracı çoğu olayı tek komutla tespit ve onarır. docs.plesk.com+1

İlk Teşhis: Günlükleri (Log) ve Servis Durumunu Kontrol Edin

Plesk arayüzü erişilemiyorsa, sunucuya SSH ile bağlanın ve MariaDB/MySQL durumuna bakın:

systemctl status mariadb journalctl -u mariadb -n 200 --no-pager

(Windows’ta Olay Görüntüleyici ve Plesk SQL Server servisini kontrol edin.) support.plesk.com
Geçmiş boot loglarını inceleyin (özellikle beklenmedik yeniden başlatma sonrası):

journalctl --boot=-1 -n 5000

(Forumda doğrulanan pratik bir yaklaşım.) Plesk Forum
Disk doluluk:

df -h du -sh /var/lib/mysql/* | sort -h

Diskin dolması, MySQL’in başlamasını engeller ve 500 hatasına yol açar. Plesk Forum

Hızlı Onarım: Plesk Repair Utility (Önerilen)

Çalıştırın:

Bu komut Plesk veritabanı tutarlılığını denetler, gerekirse otomatik yedek (dump) alır ve onarım dener. Linux/Windows’ta kullanılabilir. Ek seçenek gerekmez. docs.plesk.com+2plesk.com+2

Not – Geçici 500 Hatası: plesk repair installation gibi geniş onarım çalışırken Plesk kısa süre erişilemez ve 500 hatası görülebilir; bu, bilinen bir Repair Kit davranışı/bug’ıdır ve işlem bitince kaybolur. support.plesk.com

Senaryo A: SQLSTATE[HY000][2002] Connection refused

Belirti:

Neden: MariaDB/MySQL servisinin down olması veya başlayamaması.
Çözüm:

Servisi başlatın/yeniden başlatın:

systemctl restart mariadb systemctl status mariadb
Loglardaki temel sebebi giderin (ör. yapılandırma, port çakışması, izinler).
Ardından plesk repair db çalıştırın.
Kaynak ve aynı hatanın resmi analizi: support.plesk.com

Senaryo B: SQLSTATE[HY000][2002] No such file or directory

Belirti:

Neden: MySQL socket dosyası yok/yanlış yol, servis kapalı veya disk taşması sonucunda soket oluşmuyor.
Çözüm:

Servisi yeniden başlatın; /etc/my.cnf içindeki socket yolunu ve /var/lib/mysql/mysql.sock varlığını doğrulayın.
Disk doluysa alan açın (bkz. Senaryo D).
Gerekirse /tmp izinlerini ve AppArmor/SELinux kısıtlarını kontrol edin.
Doğrulama: Plesk Forum+1

Senaryo C: Plesk SQL Server Error 1053 (Windows) / Port Çakışması

Belirti: 1053; Event Viewer’da “Bind on TCP/IP port 3306… already in use”.
Neden: Plesk SQL Server servis yapılandırması hatalı ya da 3306 portunu başka bir mysqld kullanıyor.
Çözüm:

Hizmetin “Path to executable” ayarını doğru my.ini bilgisiyle güncelleyin.
Port çakışması varsa bağlanan diğer MySQL örneğini kapatın/portu değiştirin.
Kaynak: support.plesk.com

Senaryo D: Disk Dolu (No space left on device)

Belirti: MySQL başlatılamıyor; günlüklerde “No space left on device”.
Çözüm:

df -h ile dolu diskleri tespit edin, gereksiz log/backupları temizleyin.
MariaDB’yi yeniden başlatın, ardından plesk repair db.
Resmi Plesk çözüm makalesi: Plesk Forum

Senaryo E: **Bozulmuş Plesk Sistem Veritabanları (psa vb.)**

Belirti: psa tabloları “crashed”/tutarsız; Plesk arayüzü 500 veriyor.
Çözüm (önce yedek alın):

Repair Utility:

plesk repair db
Gerekirse günlük yedekten geri yükleme (Plesk’in otomatik dump’ları):
Plesk günlük/pre-upgrade dump’tan psa’yı geri yükleme adımları resmi rehberde anlatılır. (Örnek komutlar ve değiştirme notları rehberde mevcut.) plesk.com
Alternatif CLI restore notları (ilerseviye): dump’tan apsc/psa geri yükleme pratikleri. (Topluluk deneyimi; dikkatle uygulayın.) The WP Guru

Uyarı: Manuel mysqlcheck --repair veya innodb_force_recovery gibi adımlar verinizi riske sokabilir; önce resmi repair ve resmi geri yükleme yollarını deneyin. docs.plesk.com+1

Senaryo F: Geçici — Repair Çalışırken Plesk İnaccessible

Belirti: plesk repair installation sırasında panel 500 hatası döner.
Çözüm: İşlem tamamlanınca düzelir; bilinen bir davranış/bug kaydı mevcuttur. support.plesk.com

Senaryo G: Eksik/Silinmiş Dosya veya Antivirüs Karantinası (Windows)

Belirti: “500 Internal Server Error – Failed opening required …”
Çözüm: Eksik dosyayı aynı sürüm çalışan bir Plesk’ten geri getirin; antivirüse %plesk_dir% için istisna ekleyin. support.plesk.com

Adım Adım Standart Düzeltme Akışı (Önerilen Playbook)

Servisleri kontrol et: systemctl status mariadb → hata varsa log oku. support.plesk.com
Disk alanı: df -h → doluysa temizle. Plesk Forum
Repair Utility çalıştır: plesk repair db (Linux/Windows). docs.plesk.com+1
Socket/Port doğrula: mysql.sock yolu ve 3306 çakışması. (Windows’ta hizmet yapılandırması.) support.plesk.com+1
Hâlâ sorun var mı? Plesk sistem DB’lerini dump’tan geri yükle (örn. psa). plesk.com
Geçici 500 mi? Repair esnasında oluştuysa görmezden gelebilirsiniz; işlem bitince panel geri gelir. support.plesk.com

SSS

Bu hata neden “genel” gözüküyor?
“500 Plesk\Exception\Database” şemsiye bir hatadır; somut sebep loglarda çıkar. Plesk Forum

Plesk’te veritabanını GUI’den de onarabilir miyim?
Evet; “Websites & Domains → Databases → Check and Repair”. (Sürümünüze göre görünüm değişebilir.) lets-rebuild.com

Repair sırasında 500 görürsem?
Bu beklenen bir davranış olabilir; repair bitince panel geri gelir (EXTPLESK-3451). support.plesk.com

İleri Düzey Notlar ve İpuçları

Komutları üretimde uygulamadan önce snapshot/backup alın.
Plesk Repair Utility, tutarsızlık bulursa otomatik dump alıp onarım dener; bu nedenle ilk başvuru aracınız olmalı. docs.plesk.com
Hata No such file or directory ise socket yolunu ve /tmp izinlerini kontrol edin; Connection refused ise servis gerçekten çalışmıyor demektir. support.plesk.com+1

WordPress CPU Kullanımı Masterclass: Sunucunuzun Nefesini Kesen Sorunlara Derinlemesine Bakış ve Kanıtlanmış Çözüm Yöntemleri

admincim — Fri, 10 Oct 2025 12:19:05 +0000

Bu rehber, sitenizin neden yavaşladığını sadece anlamanızı değil, aynı zamanda bilinçli ve kalıcı çözümler uygulamanızı sağlayacak teknik bilgileri de içermektedir.

Bölüm 1: Sorunun Kök Nedenleri (Teknik Analiz)

Yüksek CPU kullanımının ardındaki mekanizmaları daha detaylı inceleyelim.

1. Verimsiz Veritabanı Sorguları: CPU’nun En Büyük Düşmanı

Detay: Bir WordPress sayfası yüklendiğinde, arka planda onlarca SQL sorgusu çalışır. Bu sorgular, yazıları, yorumları, ayarları, eklenti verilerini veritabanından çeker. Sorun, bu sorguların “verimsiz” olmasıyla başlar.

Döngü İçindeki Sorgular (Queries in Loops): Bir eklenti veya tema, sayfanızdaki her bir yazı için ayrı ayrı veritabanına sorgu gönderiyorsa (örneğin, her yazı için özel bir meta bilgisi çekmek), bu durum CPU üzerinde katlanarak artan bir yük yaratır. 20 yazının olduğu bir sayfada bu, 1 yerine 20+ sorgu anlamına gelebilir.
JOIN ve Karmaşık Sorgular: Özellikle “İlişkili Yazılar” (Related Posts) gibi özellikler sunan eklentiler, birden fazla tabloyu birleştiren (JOIN) ve metin analizi yapan karmaşık sorgular kullanır. Bu sorgular, basit bir veri çekme işlemine göre CPU’yu çok daha fazla meşgul eder.
Optimize Edilmemiş Meta Sorguları: wp_postmeta ve wp_usermeta tablolarında arama yapmak, doğru “indekslenmemişse” son derece yavaş olabilir. WordPress bu konuda esnektir ancak bu esneklik, kötü kodlanmış bir eklentinin tüm veritabanını taramasına neden olabilir.

Doğrulama: Bu durumu teşhis etmek için Query Monitor eklentisi en iyi araçtır. Sitenizin her sayfasında çalışan tüm SQL sorgularını, ne kadar sürdüklerini ve hangi eklenti/tema tarafından tetiklendiklerini size gösterir. Eğer bir eklentinin 0.5 saniyeden uzun süren sorgular yaptığını görürseniz, suçluyu buldunuz demektir.

2. WordPress Heartbeat API: Sessiz CPU Tüketicisi

Detay: WordPress yönetici paneline girdiğinizde, tarayıcınız ile sunucunuz arasında düzenli bir iletişim kurulur. Bu iletişim, “Heartbeat API” aracılığıyla gerçekleşir. Her 15-60 saniyede bir, sunucuya küçük AJAX istekleri gönderilir. Bu ne işe yarar?

Yazı yazarken otomatik taslak kaydı yapar.
Başka bir yazarın aynı yazıyı düzenleyip düzenlemediğini kontrol eder.
Panodaki eklenti bildirimlerini günceller.

Sorun: Yönetici panelinde birden fazla sekme açık olduğunda veya birden fazla editör aynı anda çalıştığında, bu küçük istekler birleşerek sunucuya sürekli bir “ping” seli gönderir. Her ping, admin-ajax.php dosyasını çalıştırır ve bu da bir PHP sürecini tetikleyerek CPU kullanır. Bu durum, “admin-ajax.php yüksek CPU kullanımı” sorununun temel nedenidir.

Doğrulama: Hosting firmanızın kaynak kullanım raporlarında admin-ajax.php dosyasının sürekli en üst sıralarda olduğunu görüyorsanız, Heartbeat API’nin kontrolsüz çalıştığına emin olabilirsiniz.

3. WP-Cron: Ziyaretçi Tetiklemeli Zaman Bombası

Detay: WP-Cron, gerçek bir “cron job” (sunucunun belirli zamanlarda otomatik çalıştırdığı görev) değildir. Bu bir “pseudo-cron” yani sahte cron’dur. Çalışması için sitenize bir ziyaretçinin gelmesi gerekir. Ziyaretçi geldiğinde WP-Cron tetiklenir ve “Zamanı gelmiş bir görev var mı?” diye kontrol eder.

Sorun: Yüksek trafikli bir sitede, saniyede onlarca ziyaretçi gelebilir. Bu, WP-Cron’un saniyede onlarca kez tetiklenmesi demektir. Eğer zamanlanmış ağır bir görev varsa (örneğin, büyük bir yedekleme eklentisinin veritabanını taraması), birden fazla süreç aynı anda bu görevi çalıştırmaya çalışabilir. Bu “yarış durumu” (race condition), CPU’yu anında %100’e kilitleyebilir.

Doğrulama: Sunucu erişim loglarınızı (access.log) incelediğinizde, wp-cron.php dosyasına yapılan isteklerin (POST requests) çok sık olduğunu görürseniz, bu durumun sitenizi olumsuz etkilediği doğrulanmış olur.

4. Şişirilmiş `wp_options` Tablosu ve “Autoloaded Data”

Detay: WordPress’teki wp_options tablosu, sitenizin tüm ayarlarını, eklenti konfigürasyonlarını ve geçici verileri (transients) tutar. Bu tablodaki bazı veriler “autoload” (otomatik yükleme) olarak işaretlenir. Bu, WordPress’in her sayfa yüklemesinde bu verileri otomatik olarak belleğe yüklemesi anlamına gelir.

Sorun: Kullandığınız ve daha sonra sildiğiniz eklentiler, geride yüzlerce gereksiz satır bırakabilir. Zamanla, otomatik yüklenen veri miktarı 1 MB’ı aşıp 5-10 MB’lara çıkabilir. Her bir ziyaretçi için bu kadar büyük verinin sürekli belleğe yüklenmesi, hem bellek (RAM) hem de CPU kullanımını artırır.

Doğrulama: phpMyAdmin gibi bir veritabanı yönetim aracından aşağıdaki SQL sorgusunu çalıştırarak otomatik yüklenen verinin boyutunu görebilirsiniz:

SQL

SELECT SUM(LENGTH(option_value)) / 1024 / 1024 FROM wp_options WHERE autoload = 'yes';

Eğer sonuç 1-2 MB’ın üzerindeyse, bu tabloda optimizasyon yapmanız gerektiği doğrulanır.

Bölüm 2: Kapsamlı ve Uygulamalı Çözüm Stratejileri

Artık sorunun teknik kökenlerini bildiğimize göre, her birini hedef alan çözümlere geçebiliriz.

1. Önbellekleme (Caching) Masterclass: Sadece Kurmak Yetmez

Önbellekleme, CPU kullanımını düşürmenin en etkili yoludur. Mekanizmayı daha iyi anlayalım:

Sayfa Önbellekleme (Page Caching): Bu en temel ve en etkili türdür. Ziyaretçiye sunulan dinamik PHP sayfasının tamamen statik bir HTML kopyasını oluşturur. Sunucu, PHP’yi çalıştırmak ve veritabanı sorguları yapmak yerine, bu hazır HTML dosyasını doğrudan sunar. Bu, CPU kullanımını %80-90 oranında azaltabilir.
- Araçlar: WP Rocket (premium, en kolayı), LiteSpeed Cache (LiteSpeed sunucularda en iyisi), W3 Total Cache (gelişmiş, çok ayar gerektirir).
Nesne Önbellekleme (Object Caching): Bu daha ileri bir tekniktir. Sık kullanılan ve tekrar tekrar çalıştırılan veritabanı sorgularının sonuçlarını, disk yerine doğrudan sunucunun belleğinde (RAM) tutar. Redis veya Memcached gibi teknolojilerle çalışır. Bir sorgunun sonucu bellekte varsa, WordPress veritabanına hiç gitmez. Bu, özellikle karmaşık sorgular yapan siteler ve WooCommerce gibi dinamik platformlar için CPU ve veritabanı yükünü ciddi anlamda azaltır.
- Uygulama: Hosting firmanızın Redis veya Memcached desteği sunması gerekir. Ardından, ilgili eklenti (örn. “Redis Object Cache”) ile WordPress’e entegre edilir.
Veritabanı Önbellekleme: W3 Total Cache gibi eklentiler, sorgu sonuçlarını diskte saklayarak bir tür nesne önbellekleme simülasyonu yapar, ancak Redis/Memcached kadar etkili değildir.

2. Gerçek Cron Job Kurulumu (Adım Adım)

WP-Cron’un yarattığı CPU artışlarını tamamen ortadan kaldırmak için:

WP-Cron’u Devre Dışı Bırakın: Sitenizin kök dizinindeki wp-config.php dosyasını açın ve /* That's all, stop editing! */ satırından önce şu kodu ekleyin:
PHP
```
define('DISABLE_WP_CRON', true);
```
Sunucudan Cron Job Ayarlayın: Hosting panelinize (cPanel, Plesk vb.) girin ve “Cron Jobs” bölümünü bulun.
Yeni Bir Cron Job Oluşturun: Belirli aralıklarla (örneğin saatte iki kez, yani her 30 dakikada bir) çalışacak şekilde ayarlayın. Çalıştırılacak komut alanına şunu yazın (siteniz.com’u kendi alan adınızla değiştirin):
Bash
```
wget -q -O - https://siteniz.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
```
Bu komut, sunucunuzun kendisinin, belirlediğiniz aralıklarla wp-cron.php dosyasını tetiklemesini sağlar. Bu sayede zamanlanmış görevleriniz ziyaretçi trafiğinden bağımsız, düzenli ve kontrollü bir şekilde çalışır.

3. Heartbeat API’yi Kontrol Altına Almak

Bu API’yi tamamen kapatmak bazı işlevleri bozabilir. En iyi çözüm, çalışma aralığını uzatmaktır.

Eklenti ile Çözüm: Heartbeat Control by WP Rocket gibi bir eklenti kurun. Bu eklenti, Heartbeat API’nin yönetici panelinde, site ön yüzünde ve yazı düzenleyicide hangi sıklıkla çalışacağını (örneğin 15 saniye yerine 120 saniyeye çıkarmak) veya tamamen devre dışı bırakılacağını ayarlamanıza olanak tanır. Genellikle aralığı 60-120 saniyeye çıkarmak çoğu site için güvenli ve etkilidir.

4. Gelişmiş Veritabanı Optimizasyonu

wp_options Temizliği: “Advanced Database Cleaner” gibi eklentiler, wp_options tablonuzdaki “yetim” kalmış (artık bir eklentiye ait olmayan) satırları bulmanıza yardımcı olur.
Autoload Verilerini Yönetin: Aynı eklentilerle veya SELECT option_name, LENGTH(option_value) FROM wp_options WHERE autoload = 'yes' ORDER BY LENGTH(option_value) DESC; sorgusuyla en büyük autoload verilerini tespit edip, gereksiz olanları (autoload='no' olarak) değiştirebilirsiniz. Uyarı: Bu ileri düzey bir işlemdir ve sitenizi bozabilir. Ne yaptığınızdan emin değilseniz bir uzmana danışın.
Veritabanı Tablolarını Optimize Edin: phpMyAdmin üzerinden tüm tabloları seçip “Onar” (Repair) ve “Optimize Et” (Optimize) komutlarını çalıştırmak, tablo verimliliğini artırabilir. WP-Optimize eklentisi bunu sizin için otomatik yapar.

5. Hosting ve Altyapısal İyileştirmeler

PHP Sürümünün Önemi: PHP 7.4’ten PHP 8.1’e geçmek, aynı donanımda saniyede işlenebilen istek sayısını neredeyse iki katına çıkarabilir. Çünkü PHP 8.x sürümleri, JIT (Just-In-Time) compiler gibi verimliliği artıran devrimsel teknolojiler içerir. Bu, CPU’nun aynı işi daha az “düşünerek” yapmasını sağlar. Hosting panelinizden tek tıkla PHP sürümünüzü yükseltebilirsiniz.
Doğru Hosting Seçimi: Paylaşımlı hosting, bir apartman dairesi gibidir; komşunuzun (aynı sunucudaki başka bir site) yarattığı gürültü (yüksek CPU kullanımı) sizi de etkiler. VPS (Virtual Private Server) ise size özel kaynaklar (garantili CPU çekirdeği ve RAM) sunan bir dubleks daire gibidir. Siteniz iş yapıyor ve düzenli trafik alıyorsa, bu yatırım kaçınılmazdır.

Sonuç ve Eylem Planı

Yüksek CPU kullanımı, tek bir butona basarak çözülecek bir sorun değil, bir dizi optimizasyon ve doğru altyapı seçiminin sonucudur.

Acil Durum (İlk 1 Saat): Bir önbellekleme eklentisi (WP Rocket veya LiteSpeed Cache) kurup temel ayarlarını yapın. Bu, kanamayı durdurmak gibidir.
Teşhis (İlk Gün): Query Monitor kurarak yavaş sorguları ve sorunlu eklentileri tespit edin. Heartbeat Control ile AJAX isteklerini yavaşlatın.
Kalıcı İyileştirme (İlk Hafta): WP-Cron’u devre dışı bırakıp gerçek cron job kurun. Veritabanınızı WP-Optimize ile temizleyin. PHP sürümünüzü güncelleyin.
Geleceğe Yatırım (İlk Ay): Eğer sorunlar devam ediyorsa, trafiğiniz ve ihtiyaçlarınız mevcut hosting paketinizi aşmış demektir. VPS’e geçişi ve Redis gibi bir nesne önbellekleme sistemini planlayın.

Bu detaylı ve doğrulanmış adımları izleyerek, sunucunuzun “beynini” rahatlatabilir, sitenizi hızlandırabilir ve ziyaretçilerinize kesintisiz bir deneyim sunabilirsiniz.

Hosting’te En Sık Hatalar ve Çözüm Akışları (cPanel • Plesk • CWP)

admincim — Wed, 08 Oct 2025 10:05:59 +0000

Özet (TL;DR): İlk 5 dakikada logları kontrol et → DNS kayıtlarını doğrula (A/AAAA, MX) → AutoSSL/Let’s Encrypt’i yenile → PHP limitlerini (upload/post/execution) güncelle → e-posta doğrulamalarını (SPF/DKIM/DMARC) tamamla. Plesk’te tıkanırsan plesk repair all; CWP’de AutoSSL ve PHP loglarını birlikte izle.

İlk 5 Dakikalık Teşhis

Hata kayıtları: cPanel: Metrics → Errors; Plesk: alan adında Logs; CWP: HTTPD/Nginx, PHP, AutoSSL ve servis log’ları.
DNS kontrolü: A/AAAA, MX, TXT (SPF/DKIM/DMARC)
SSL/AutoSSL: Let’s Encrypt’i yenile; 80/TCP erişilebilir olmalı (HTTP-01 doğrulaması).
PHP limitleri: upload_max_filesize + post_max_size + max_execution_time
Mail teslimi: SPF/DKIM/DMARC + rDNS(PTR)

DNS / Alan Adı Hataları

Belirti: Site bazı bölgelerde açılıyor/hiç açılmıyor, e-postalar gelmiyor.

Panel yolları: cPanel: Domains → Zone Editor; Plesk: Websites & Domains → DNS Settings; CWP: DNS Functions.

dig +short example.com A
dig +short example.com AAAA
dig +short example.com MX
dig +short NS example.com

Not: NS değişiminde TTL/propagasyon 24–48 saat sürebilir.

SSL/TLS (HTTPS) ve AutoSSL

Belirti: “Not secure”, “expired”, “hostname mismatch”, LE başarısız.
Kritik: Let’s Encrypt HTTP-01 yalnızca 80/TCP’ten doğrular.

cPanel/WHM: AutoSSL (sağlayıcı: Let’s Encrypt)
Plesk: Let’s Encrypt / SSL It! (site + mail + Plesk arayüzü)
CWP: Loglar → /var/log/cwp/autossl.log, /root/.acme.sh/acme.sh.log

Öneri: HTTP→HTTPS yönlendirmesi kalsın; fakat .well-known/acme-challenge dosyalarına 80’den erişim bozulmasın.

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Web Sunucusu & Uygulama Hataları (500/502/503/504)

İzlenecek yol: cPanel Errors → ip

🛡️ Paylaşımlı (Shared) Hosting Kullananlar İçin Pratik Güvenlik Rehberi

admincim — Tue, 07 Oct 2025 10:36:06 +0000

10 adımda daha güvenli site + cPanel ve WordPress üzerinden uygulanabilir çözümler

Kime göre? Yeni–orta seviye kullanıcı, WordPress ağırlıklı, paylaşımlı hosting kullananlar.
Amaç: Hızlı uygulanan, hatayı çözen, arama niyeti yüksek konularla organik trafik toplamak.

🔍 Neden paylaşımlı hostta güvenlik kritik?

Aynı fiziksel sunucuda birçok site bir aradadır. İzolasyon zafiyetleri, log dosyaları üzerinden bilgi sızdırma (log snooping) ve log zehirleme (log poisoning) gibi saldırı yüzeyleri doğurabilir. Bu yüzden temel korumalar + doğru yapılandırma şarttır. arXiv+1

1) 🧱 ModSecurity (WAF) açık mı? (cPanel → Security → ModSecurity)

Ne sağlar? HTTP isteklerini imza/kurallarla filtreleyip yaygın web saldırılarını kırpar. cPanel’de her domain için aç/kapat yapılabilir; erişemiyorsan sağlayıcından etkinleştirmesini iste. Kurallar için en yaygın set OWASP Core Rule Set (CRS)’tir. cPanel & WHM Documentation+1

İpucu: WAF bazen yanlış pozitif üretebilir. Gerekirse alan adına özel kural istisnası veya geçici kapatma ile test edebilirsin (kalıcı kapatma önerilmez). cPanel & WHM Documentation

2) 🔒 HTTPS zorunlu + (mümkünse) HSTS

Trafiği şifreleyen HTTPS hem güvenlik hem de SEO tarafında onaylı bir sinyaldir. Sertifikan yoksa kur; varsa HTTP→HTTPS yönlendirmesini zorunlu kıl ve HSTS değerlendir. Google for Developers

3) 🧰 Dosya/klasör izinlerini düzelt (WordPress)

Genel pratik:

Dosyalar: 644
Klasörler: 755
Bu kombinasyon, çoğu WordPress kurulumunda güvenli/çalışır denge sunar. Ayrıntılı izin rehberi için resmi geliştirici dokümantasyonuna bak. WordPress Developer Resources

4) 🧾 .htaccess ile hızlı korumalar

a) Dizin listelemeyi kapat

Bu, klasör içeriğinin listelenmesini durdurur; uygulanabilirliği AllowOverride ayarına bağlıdır. Apache HTTP Server

b) Hassas dosyaları web’den gizle

Apache 2.4’te Require all denied ile eşleşen dosyalar doğrudan sunulmaz. (Yine AllowOverride önemli.) Apache HTTP Server

Not: .htaccess her ortamda her direktifi çalıştırmayabilir; sunucu yapılandırması belirleyicidir. (Apache, .htaccess’in nasıl ve ne zaman kullanılması gerektiğini resmi kılavuzda anlatır.) Apache HTTP Server

5) 🔐 SFTP/SSH kullan; FTP’yi bırak

FTP veriyi ve parolaları şifrelemeden taşır. SFTP/SSH ile güvenli kanaldan aktarım yap. WordPress güvenlik kılavuzları da SSH/SFTP’yi önerir. WordPress Developer Resources+1

6) 🧩 PHP tarafında “sınırlandırma” (mümkün olan yerde)

open_basedir: PHP’nin erişebileceği dizinleri sınırlar (siteler arası dolaşmayı önlemeye yardım eder). Etkinleştirme şekli hosting ortamına göre değişir. php.net
disable_functions: exec, shell_exec, system gibi riskli fonksiyonları devre dışı bırakır (destek/etki PHP sürümü ve handler’a bağlıdır). php.net

cPanel’de nereden bakarım? MultiPHP INI Editor üzerinden alan adına tanımlı, panelin izin verdiği yönergeleri düzenleyebilirsin. (Bazı direktifler paylaşımlı hostta kilitli olabilir.) cPanel & WHM Documentation

7) 💾 Yedeklemeyi otomatiğe bağla + geri yüklemeyi test et

cPanel Backup Wizard ile tam veya kısmi yedek alabilir, ihtiyaçta geri yükleyebilirsin. Gerçekten işe yarayıp yaramadığını en az bir kez küçük bir geri yükleme testiyle doğrula. cPanel & WHM Documentation

8) 🚀 CDN ekle (temel hız + saldırı yüzeyi azaltma)

CDN; içeriği kullanıcıya yakın POP’lardan ileterek performans ve erişilebilirlik kazandırır; çoğu CDN aynı zamanda temel DDoS/WAF katmanı da sunar. Başlangıç planları genelde yeterlidir. (Seçim marka bağımsız.) (Genel ilkedir; ürün isimleri değişebilir.)

9) 🧹 Eklenti/tema hijyeni (WordPress)

Sadece güvenilir kaynaklardan tema/eklenti.
Güncellemeleri geciktirme (major öncesinde mutlaka yedek).
Kullanmadıklarını sil (pasif bırakma).
Bu tavsiyeler WordPress güvenlik kılavuzlarında temel başlıklardır. WordPress Developer Resources

10) 👀 İzleme ve log bilinci

Erişim/hatâ loglarını düzenli kontrol et (403, 404 patlamaları, sıra dışı POST istekleri). Paylaşımlı hostta log izolasyonu yoksa risk büyür; sağlayıcından her alan adının loglarının ayrıldığını teyit et. arXiv

✅ 30 Dakikalık Hızlı Kontrol Listesi

ModSecurity: cPanel → Security → ModSecurity → On. (Her domaini kontrol et.) cPanel & WHM Documentation
HTTPS: Sertifika kurulu mu? HTTP→HTTPS yönlendirme aktif mi? (SEO + güvenlik) Google for Developers
.htaccess:
- Options -Indexes ekle. Apache HTTP Server
- FilesMatch ile .env/.ini/.log vb. engelle. Apache HTTP Server
İzinler: Dosyalar 644, klasörler 755 mi? (WordPress resmî kaynak) WordPress Developer Resources
SFTP: FTP yerine SFTP/SSH kullan. wordfence.com
PHP sınırları: (Varsa) open_basedir ve disable_functions durumunu incele. php.net+1
Yedek: cPanel Backup Wizard ile kısmi yedek al; küçük bir geri yükleme testi yap. cPanel & WHM Documentation

🧪 Sık karşılaşılan mini sorunlar & hızlı çözümler

“Dizinlerim listeleniyor, herkes görüyor!”
.htaccess dosyana Options -Indexes ekle; sonuç görmüyorsan sunucuda AllowOverride kısıtlı olabilir (destekle kontrol et). Apache HTTP Server

“WAF kapatınca hızlanır mıyım?”
Genelde kapatma; ModSecurity + OWASP CRS yaygın saldırıları daha başta kırpar. Hata yaşıyorsan kural istisnası veya domain bazlı ince ayar yap. cPanel & WHM Documentation+1

“FTP güvenli mi?”
Hayır, parolalar şifresiz gider. SFTP/SSH kullan. wordfence.com

📎 Kod şablonları (kopyala–yapıştır)

.htaccess – Dizin listelemeyi kapat + hassas dosyaları engelle

(Apache 2.4 söz dizimi; AllowOverride = All değilse çalışmayabilir.) Apache HTTP Server

wp-content/uploads için örnek izinler

Klasörler: 755
Dosyalar: 644 WordPress Developer Resources

📚 Kaynaklar (Güvenilir dokümantasyon)

cPanel – ModSecurity (kullanıcı arayüzü & WHM kurulumu notları) cPanel & WHM Documentation
OWASP Core Rule Set (CRS) – proje sayfası owasp.org
Google – “HTTPS bir sıralama sinyali” duyurusu (resmî) Google for Developers
WordPress Developer – Dosya izinleri WordPress Developer Resources
cPanel – Backup Wizard cPanel & WHM Documentation
WordPress Hardening (SSH/SFTP önerileri dahil) WordPress Developer Resources
Apache – .htaccess ve yapılandırma bölümleri Apache HTTP Server+1
Akademik – Paylaşımlı hosting’te log saldırıları (snooping/poisoning) arXiv+1

yum update –nobest: Linux Sunucularda Güncelleme Sorunlarına Pratik Çözüm

admincim — Thu, 04 Sep 2025 08:56:11 +0000

`yum update --nobest` Nedir?

Linux sistemlerinde paket yönetimi sırasında bazen güncelleme hatalarıyla karşılaşabilirsiniz. Özellikle CentOS, AlmaLinux, Rocky Linux gibi RHEL tabanlı dağıtımlarda kullanılan yum paket yöneticisi, en güncel sürümleri yüklemek ister. Ancak bu her zaman mümkün olmaz.

İşte bu durumda yum update --nobest, uyumlu sürümlere güncelleme yaparak hataları aşmanıza yardımcı olur.

Normal `yum update` Neden Hata Verebilir?

Standart güncelleme komutu:

Bu komut en güncel paketleri kurmaya çalışır. Ancak bazı durumlarda:

Bağımlılık sorunları (dependency conflicts) yaşanabilir.
Yeni sürüm uyumsuz olabilir.
Üretim ortamında stabilite bozulabilir.

Örnek hata çıktısı:

`yum update --nobest` ile Çözüm

Komut:

Bu parametre sayesinde:

En güncel sürüm zorunlu tutulmaz.
Uyumlu olan en uygun sürüm seçilir.
Güncellemeler tamamen kesilmez.

Kullanım Senaryoları

1. Üretim Sunucularında

En güncel sürüm bağımlılık hatası verirse, --nobest sayesinde bir alt ama stabil sürüm kullanılabilir.

2. Geliştirme Ortamında

Yeni teknolojiler denerken tüm sistem güncellemeleri sırasında çıkabilecek hatalar --nobest ile aşılabilir.

Avantajları

✅ Güncellemeler tamamen engellenmez.
✅ Daha esnek güncelleme sağlar.
✅ Bağımlılık hatalarını azaltır.

Dezavantajları

⚠️ Sistem her zaman en güncel olmayabilir.
⚠️ Güvenlik yamaları gecikebilir.
⚠️ Uzun vadede uyumluluk sorunları çıkabilir.

Sonuç

yum update --nobest, Linux güncellemelerinde bağımlılık hatalarını çözmek için pratik bir yöntemdir. Ancak güvenlik ve uzun vadeli uyumluluk açısından dikkatli kullanılmalıdır.

CentOS Web Panel için Nginx ile HTTP/3 ve QUIC Nasıl Aktif Edilir?

admincim — Wed, 25 Sep 2024 08:23:12 +0000

HTTP/3, internet bağlantı hızını artıran QUIC protokolü ile birlikte gelir. CentOS Web Panel kullanarak Nginx 1.26.1 üzerinde tüm sitelerinizde HTTP/3 ve QUIC’i etkinleştirebilir ve aynı zamanda birden fazla siteyi yönetmek için virtualhost özelliğini ekleyebilirsiniz. Bu makalede, bu adımları detaylı bir şekilde açıklıyoruz.

1. Gereksinimler ve Ön Hazırlık

CentOS 7/8 kullanıyor olmanız.
Nginx 1.26.1 kaynağı.
SSL sertifikaları (örneğin Let’s Encrypt).
Virtualhost ile birden fazla siteyi yönetmek için DNS ayarlarının yapılmış olması.

2. Nginx 1.26.1’i QUIC Desteği ile Derleme

Varsayılan Nginx sürümünde QUIC ve HTTP/3 desteği bulunmaz. Bu yüzden Nginx’i yeniden derleyeceğiz.

Gerekli uygulamaları Kurun:

yum install gcc pcre-devel zlib-devel openssl-devel libatomic_ops-devel cmake

Open SSL Kütüphanesini İndirin:

rm -rf openssl*

wget https://www.openssl.org/source/openssl-3.0.12.tar.gz -O openssl.tar.gz

tar -xf openssl.tar.gz

rm -rf openssl.tar.gz

mv openssl-* openssl

./config --prefix=/usr/local/opensslso --openssldir=/usr/local/opensslso zlib shared

make && make install

Nginx 1.26.1 Kaynak Kodunu İndirin ve Derleyin:

wget https://nginx.org/download/nginx-1.26.1.tar.gz



tar -zxvf nginx-1.26.1.tar.gz

cd nginx-1.26.1/

./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --user=nginx --group=nginx --build=CentOS --builddir=nginx-custom --with-select_module --with-poll_module --with-threads --with-file-aio --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_auth_request_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --with-mail=dynamic --with-mail_ssl_module --with-stream=dynamic --with-stream_ssl_module --with-stream_realip_module --with-stream_geoip_module=dynamic --with-stream_ssl_preread_module --with-compat --with-pcre=/usr/local/src/pcre-8.45 --with-pcre-jit --with-zlib=/usr/local/src/zlib --with-openssl=/usr/local/src/openssl --with-openssl-opt=no-nextprotoneg --with-debug --with-http_v3_module --build="quiche-$(git --git-dir=../quiche/.git rev-parse --short HEAD)"

make

make install

3. Nginx VirtualHost Yapılandırması ve HTTP/3 Etkinleştirme

Her bir site için virtualhost yapılandırması oluşturup, HTTP/3 desteğini ekleyeceğiz.

Nginx Ana Yapılandırma Dosyasını Düzenleyin:

nano /etc/nginx/nginx.conf

Yapılandırma dosyasına şu satırları ekleyin:

http {



include       mime.types;

default_type  application/octet-stream;

sendfile        on;

keepalive_timeout  65;

include /etc/nginx/conf.d/*.conf;

}

VirtualHost Yapılandırmasını Ekleyin:

CWP Panel üzerinden webserver conf editör bölümüne gelip /etc/nginx/conf.d/vhosts/ bölümüne gelip ilgili domainde değişikliği yapabilirsiniz.

nano /etc/nginx/conf.d/yourdomain.com.conf

Aşağıdaki yapılandırmayı ekleyin:

server {

listen 127.0.0.1:443 ssl;

Ip adresi sizden değişiklik gösterir. Altına ya da üstüne ;



listen 168.119.80.200:443 quic;

Şu kodu bulun;

}

location @backend {

internal;

proxy_pass http://168.119.80.200:8181;

include proxy.inc;

Hemen üstüne şu kodu girin;

# used to advertise the availability of HTTP/3
add_header Alt-Svc 'h3=":443"; ma=86400';

Güvenlik Duvarı Ayarları:

QUIC UDP üzerinden çalıştığı için aşağıdaki komutlarla 443 UDP portunu açın:

firewall-cmd --permanent --add-port=443/udp

firewall-cmd --reload

Nginx’i Yeniden Başlatın:

nginx -t



systemctl restart nginx

4. HTTP/3 ve QUIC Doğrulaması

HTTP/3’ün etkin olduğunu doğrulamak için şu komutu kullanabilirsiniz:

curl -I -s --http3 https://saviorhost.com

Tarayıcı geliştirici araçlarını kullanarak Alt-Svc başlıklarını kontrol ederek de HTTP/3’ün etkin olup olmadığını görebilirsiniz.

Sonuç

Bu adımlarla CentOS Web Panel üzerinde Nginx 1.26.1’i HTTP/3 ve QUIC desteği ile derleyip, virtualhost’larla tüm sitelerde etkinleştirdiniz. Bu yapılandırma, sitelerinizin hız ve performansını önemli ölçüde artıracaktır.

Nginx – Saviorhost İnternet Hizmetleri

500 Internal Server Error: Neden Olur, Nasıl Çözülür? (cPanel, WordPress, Nginx/Apache Rehberi)

1. Karanlıkta El Yordamıyla Aramayı Bırakın: Hata Loglarını (Error Logs) Okuyun

2. En Yaygın Fail: Bozuk veya Şişmiş .htaccess Dosyası

3. Yanlış Dosya İzinleri (Permissions) ve Sahiplik (Ownership/Chown) Krizleri

4. PHP Memory Limit (Bellek) Yetersizliği ve Max Execution Time Darboğazı

5. ModSecurity (WAF) Yanlış Pozitif Engellemeleri

6. Acı Gerçek: Sorun Kodlarınızda Değil, Sunucunuzun Gücündedir!

SaviorHost ile Darboğazlara Veda Edin

Web Sitelerinde Spam Trafiğini Engelleme (2025 Rehberi)

Neden “bot” ≠ tek tip? (Tehdit modelini oturt)

Ana savunma katmanları (özet strateji)

Uygulanabilir kontrol listesi (Hızlı başlangıç)

Uygulama Taslağı (kopyala–uyarla)

A) Nginx: Oran sınırlama ve basit işaretler

B) Cloudflare: Turnstile + WAF mantığı + AI Labyrinth

C) AWS WAF: Bot Control + yönetilen kurallar

D) Google reCAPTCHA (Enterprise): OAT uyumlu mimari

E) GA4: İç/developer trafiğini dışla (ölçüm temizliği)

F) İzleme & alarm fikirleri

Neden robots.txt tek başına yetmiyor?

Kullanıcı deneyimi: “kademeli sürtünme” prensibi

Ek: Somut “kural seti” taslağı (özet)

500 Plesk\Exception\Database Hatası (SQLSTATE 2002) – Kesin Çözüm Rehberi

İlk Teşhis: Günlükleri (Log) ve Servis Durumunu Kontrol Edin

Hızlı Onarım: Plesk Repair Utility (Önerilen)

Senaryo A: SQLSTATE[HY000][2002] Connection refused

Senaryo B: SQLSTATE[HY000][2002] No such file or directory

Senaryo C: Plesk SQL Server Error 1053 (Windows) / Port Çakışması

Senaryo D: Disk Dolu (No space left on device)

Senaryo E: Bozulmuş Plesk Sistem Veritabanları (psa vb.)

Senaryo F: Geçici — Repair Çalışırken Plesk İnaccessible

Senaryo G: Eksik/Silinmiş Dosya veya Antivirüs Karantinası (Windows)

Adım Adım Standart Düzeltme Akışı (Önerilen Playbook)

SSS

İleri Düzey Notlar ve İpuçları

WordPress CPU Kullanımı Masterclass: Sunucunuzun Nefesini Kesen Sorunlara Derinlemesine Bakış ve Kanıtlanmış Çözüm Yöntemleri

Bölüm 1: Sorunun Kök Nedenleri (Teknik Analiz)

1. Verimsiz Veritabanı Sorguları: CPU’nun En Büyük Düşmanı

2. WordPress Heartbeat API: Sessiz CPU Tüketicisi

3. WP-Cron: Ziyaretçi Tetiklemeli Zaman Bombası

4. Şişirilmiş wp_options Tablosu ve “Autoloaded Data”

Bölüm 2: Kapsamlı ve Uygulamalı Çözüm Stratejileri

1. Önbellekleme (Caching) Masterclass: Sadece Kurmak Yetmez

2. Gerçek Cron Job Kurulumu (Adım Adım)

3. Heartbeat API’yi Kontrol Altına Almak

4. Gelişmiş Veritabanı Optimizasyonu

5. Hosting ve Altyapısal İyileştirmeler

Sonuç ve Eylem Planı

Hosting’te En Sık Hatalar ve Çözüm Akışları (cPanel • Plesk • CWP)

İlk 5 Dakikalık Teşhis

DNS / Alan Adı Hataları

SSL/TLS (HTTPS) ve AutoSSL

Web Sunucusu & Uygulama Hataları (500/502/503/504)

🛡️ Paylaşımlı (Shared) Hosting Kullananlar İçin Pratik Güvenlik Rehberi

🔍 Neden paylaşımlı hostta güvenlik kritik?

1) 🧱 ModSecurity (WAF) açık mı? (cPanel → Security → ModSecurity)

2) 🔒 HTTPS zorunlu + (mümkünse) HSTS

3) 🧰 Dosya/klasör izinlerini düzelt (WordPress)

4) 🧾 .htaccess ile hızlı korumalar

5) 🔐 SFTP/SSH kullan; FTP’yi bırak

6) 🧩 PHP tarafında “sınırlandırma” (mümkün olan yerde)

7) 💾 Yedeklemeyi otomatiğe bağla + geri yüklemeyi test et

8) 🚀 CDN ekle (temel hız + saldırı yüzeyi azaltma)

9) 🧹 Eklenti/tema hijyeni (WordPress)

10) 👀 İzleme ve log bilinci

✅ 30 Dakikalık Hızlı Kontrol Listesi

🧪 Sık karşılaşılan mini sorunlar & hızlı çözümler

📎 Kod şablonları (kopyala–yapıştır)

📚 Kaynaklar (Güvenilir dokümantasyon)

yum update –nobest: Linux Sunucularda Güncelleme Sorunlarına Pratik Çözüm

yum update --nobest Nedir?

Normal yum update Neden Hata Verebilir?

yum update --nobest ile Çözüm

Kullanım Senaryoları

1. Üretim Sunucularında

2. Geliştirme Ortamında

Avantajları

Dezavantajları

Sonuç

2. En Yaygın Fail: Bozuk veya Şişmiş `.htaccess` Dosyası

Senaryo E: **Bozulmuş Plesk Sistem Veritabanları (psa vb.)**

4. Şişirilmiş `wp_options` Tablosu ve “Autoloaded Data”

`yum update --nobest` Nedir?

Normal `yum update` Neden Hata Verebilir?

`yum update --nobest` ile Çözüm