İlk 5 Dakikalık Teşhis

1. Hata kayıtları: cPanel: Metrics → Errors; Plesk: alan adında Logs; CWP: HTTPD/Nginx, PHP, AutoSSL ve servis log’ları.
2. DNS kontrolü: A/AAAA, MX, TXT (SPF/DKIM/DMARC)
3. SSL/AutoSSL: Let’s Encrypt’i yenile; 80/TCP erişilebilir olmalı (HTTP-01 doğrulaması).
4. PHP limitleri: upload_max_filesize + post_max_size + max_execution_time
5. 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

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

1. ModSecurity: cPanel → Security → ModSecurity → On. (Her domaini kontrol et.) cPanel & WHM Documentation

2. HTTPS: Sertifika kurulu mu? HTTP→HTTPS yönlendirme aktif mi? (SEO + güvenlik) Google for Developers

3. .htaccess:

   • Options -Indexes ekle. Apache HTTP Server

   • FilesMatch ile .env/.ini/.log vb. engelle. Apache HTTP Server

4. İzinler: Dosyalar 644, klasörler 755 mi? (WordPress resmî kaynak) WordPress Developer Resources

5. SFTP: FTP yerine SFTP/SSH kullan. wordfence.com

6. PHP sınırları: (Varsa) open_basedir ve disable_functions durumunu incele. php.net+1

7. 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

Hata Nasıl Görünür?

Sunucu Sorunu: STATUS: Internal error occurred. Refer to server log for more information.
(host linux.saviorhost.com[private/dovecot-lmtp] said: 451 4.2.0 Internal error occurred (in reply to end of DATA command))

Bu mesaj, Postfix’in Dovecot LMTP’ye mesajı teslim etmeye çalıştığını, ancak Dovecot’un “internal error” ile yanıt verdiğini gösterir.

Olası Nedenler

• Mailbox izin ya da bozulma: Maildir dizini sahiplik / izin hataları veya bozuk indekler.
• Disk doluluğu ya da kota problemi: Mesaj teslim edilemiyor çünkü yeterli alan yok.
• LMTP / Postfix entegrasyon hatası: Dovecot’un `private/dovecot-lmtp` soketi ya da `mailbox_transport` tanımı yanlış.
• Roundcube SMTP ayarları tutarsız: Yanlış SMTP sunucusu, port ya da bağlantı türü.

Adım Adım Çözüm Rehberi

1. Logları İnceleyin

sudo tail -n 200 /var/log/dovecot.log
sudo tail -n 200 /var/log/maillog
sudo journalctl -u dovecot -u postfix --since "today"

Loglar, hatanın tam nedenini “Permission denied”, “No space left on device”, “lmtp” gibi ifadeleri içererek gösterir.

2. Mailbox İzin/Sahiplik Kontrolü & Onarımı

sudo ls -ld /home/vmail/example.com/iletisim
sudo chown -R vmail:vmail /home/vmail/example.com/iletisim
sudo chmod -R 700 /home/vmail/example.com/iletisim

# Bozuk kutuları yeniden senkronize et
sudo doveadm force-resync -u iletisim@example.com INBOX
sudo doveadm force-resync -u iletisim@example.com '*'

3. Disk Alanı ve Kota Kontrolü

df -h
sudo du -xh /var /home | sort -h | tail -n 20

Kota ya da depolama limiti aşıldıysa, gereksiz dosyaları temizleyin veya kullanıcı kotasını artırın.

4. Postfix → Dovecot LMTP Yapılandırması

Postfix (main.cf):

mailbox_transport = lmtp:unix:private/dovecot-lmtp

Dovecot (10-master.conf):

service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
  process_min_avail = 5
}
protocol lmtp {
  # lmtp_rcpt_check_quota = yes  (Gerekirse aktif edin)
}

5. Roundcube SMTP Ayarları

6. Servisleri Yeniden Başlatın & Test Edin

sudo systemctl restart dovecot
sudo systemctl restart postfix

# Kuyrukta bekleyen mailleri kontrol et
postqueue -p

# Logları yeniden izleyin
sudo tail -n 100 /var/log/maillog

Kontrol Listesi

• Loglarda ilgili saat/dakika ile hata satırlarını buldum.
• Mailbox izinleri (`vmail:vmail`, `700`) doğru.
• Disk alanı/kota kontrolü yapıldı, sorun yok.
• Postfix → LMTP yapılandırması uygun.
• Roundcube SMTP ayarları doğrulandı.
• Gerekirse `doveadm force-resync` ile onarım yapıldı.

SSS – Kısa Sorular & Yanıtlar

“451 4.2.0 neden geçici hata?”

4.x kodları SMTP protokolünde “geçici” hatadır. Sorun giderilirse mail yeniden teslim edilebilir.

Sadece bir kullanıcıda mı hata var?

Muhtemelen o kullanıcının mailbox’ında bozulma ya da izin sorunu vardır. Onarıp tekrar test edin.

Sonuç

“451 4.2.0 Internal Error Occurred (LMTP)” hatası genellikle **izin, LMTP entegrasyonu veya posta kutusu bozulması** kaynaklıdır. Yukarıdaki rehberi adım adım uygulayarak sorunu kalıcı şekilde çözebilirsiniz. Her adımda logları takip etmeyi unutmayın.

Kaynaklar

• Dovecot – Postfix LMTP Entegrasyonu
• Doveadm Force-Resync Komutu
• Dovecot Quota / Kota Eklentisi
• Roundcube Yapılandırma Rehberi

Bu yazıda cPanel ve CWP’yi lisans, güvenlik, performans, e-posta altyapısı ve reseller yönetimi gibi başlıklarda karşılaştırıyor; kendi kullanım deneyimlerimizle harmanlanmış, güncel bir değerlendirme sunuyoruz.

Lisanslama ve Maliyet

• cPanel: Hesap bazlı lisanslama modeli ile yıllar içinde ciddi fiyat artışları yaşandı. Çok sayıda site barındıran firmalar için toplam maliyet yüksek olabiliyor.

• CWP: Temel sürümü ücretsiz, CWPpro ise oldukça düşük maliyetli. Güvenlik güncellemeleri ve gelişmiş özelliklere erişim için Pro sürümü tercih ediliyor.

👉 Sonuç: Maliyet önceliğiniz varsa CWP, kurumsal destek ve geniş entegrasyon ağı istiyorsanız cPanel.

İşletim Sistemi Desteği

• cPanel: AlmaLinux, Rocky Linux ve Ubuntu LTS sürümlerini destekliyor.

• CWP: CentOS 7/8/9, AlmaLinux 8/9 ve Rocky Linux 8/9 ile çalışıyor. Ancak CentOS 7 artık EOL olduğundan, yeni kurulumlarda AlmaLinux 8/9 öneriliyor.

👉 Sonuç: Uzun vadeli projelerde her iki panel de AlmaLinux/Rocky tabanlı çözümlerle güvenle kullanılabilir.

E-posta ve Webmail Altyapısı

• cPanel: v108’den itibaren sadece Roundcube webmail istemcisi var. Sunucu tarafında Exim + Dovecot kullanıyor.

• CWP: Postfix + Dovecot + Roundcube kombinasyonunu paket halinde sunuyor. SPF, DKIM ve SpamAssassin entegrasyonu da mevcut.

👉 Sonuç: Her iki panelde de Roundcube varsayılan. Daha ileri seviye posta trafiği yönetimi isteyenler için cPanel biraz daha esnek.

Reseller Yönetimi

• cPanel: WHM üzerinden gelişmiş reseller araçları sunuyor. Disk, trafik, paket yönetimi ve askıya alma gibi işlevler çok olgun.

• CWP: Reseller modülü ile bayi hesapları oluşturulabiliyor. Pro sürümle birlikte bu modül daha pratik hale geliyor.

👉 Sonuç: Büyük bayi ağları için cPanel, küçük ölçekli reseller senaryoları için CWP yeterli.

Güvenlik

• cPanel: cPHulk brute-force koruması, AutoSSL (Let’s Encrypt), EasyApache 4 ile düzenli güvenlik güncellemeleri.

• CWP: CSF/LFD firewall, ModSecurity (OWASP/Comodo kural setleri), AutoSSL, Fail2Ban entegrasyonu. Ayrıca manuel sertleştirme ile ciddi maliyet avantajı sağlanabiliyor.

👉 Sonuç: CWP’de güvenlik için biraz teknik bilgiye ihtiyaç var, ama maliyet avantajı çok yüksek. cPanel ise daha “kutudan çıkan” güvenlik sunuyor.

Performans ve Sunucu Yığınları

• cPanel: Apache tabanlı, NGINX reverse proxy entegrasyonu ve LiteSpeed (lisanslı) desteği mevcut.

• CWP: Apache, Nginx, PHP-FPM, Varnish ve hatta LiteSpeed kombinasyonlarını esnek şekilde yönetmenize imkân veriyor.

👉 Sonuç: Küçük ve orta ölçekli VPS projelerinde CWP’nin kaynak verimliliği dikkat çekiyor.

Otomatik Kurulumlar

• cPanel: Softaculous entegrasyonu yaygın, resmi destekli.

• CWP: Softaculous kurulabiliyor, ayrıca kendi dahili App Installer’ı mevcut.

Yedekleme ve Migrasyon

• cPanel: WHM üzerinden esnek yedekleme seçenekleri; JetBackup gibi popüler 3. parti araçlarla genişletilebiliyor.

• CWP: Yerleşik yedekleme yöneticisi var. Ayrıca cPanel’den CWP’ye geçiş için resmi migrasyon araçları mevcut.

Genel Değerlendirme

• cPanel, kurumsal düzeyde destek ve uzun yıllara dayanan stabilite isteyenler için hâlâ lider konumda.

• CWP, teknik bilgiye sahip kullanıcıların manuel sertleştirmeyle maliyetleri ciddi oranda düşürmesine olanak sağlıyor.

Öneri:

• Çoklu reseller, geniş entegrasyon ağı ve resmi SLA isteyen firmalar için cPanel.

• Maliyet odaklı, esnek, performanslı ve teknik kontrol isteyen kullanıcılar için CWP.

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.

E-posta yönetimi bir sunucu panelinin omurgasıdır. CentOS Web Panel (CWP) üzerinde eski Roundcube sürümleri güvenlik riski oluşturabilir. Bu rehberde, Roundcube 1.5.11 sürümüne adım adım ve güvenle yükseltmeyi anlatıyoruz. 🚀

🔒 Neden 1.5.11?

CWP’nin varsayılan Roundcube sürümü çoğu kurulumda eski kalabiliyor. 1.5.x serisi; güvenlik yamaları, uyumluluk ve daha iyi eklenti desteğiyle öne çıkıyor.
1.5.11, 1.5 hattındaki en güncel ve kararlı sürümlerden biri olduğu için tavsiye edilir. ✅

🧭 Aşamalar – Adım Adım Kurulum

1) INTL PHP Eklentisini Kur (Gerekirse) 🧩

Sunucunda intl eklentisi yoksa, aşağıdaki komutlarla (EL7/EL8) kurulumu tamamlayabilirsin:

CentOS 7 / EL7:

CentOS 8 / EL8:

Kaldırma:

2) Roundcube 1.5.11 Paketini İndir ⬇️

3) Paketi Aç ve Kurulum Script’ini Çalıştır 🛠️

Kurulum sırasında ekranda şunu göreceksiniz:

Burada y tuşuna basarak devam edin. Ardından şu çıktılar gelecek:

4) Temizlik 🧹

ℹ️ Çoğu sistemde dosya izinleri CWP tarafından otomatik ayarlanır; ayrıca chown veya chmod girmenize gerek kalmayabilir.

5) Test Et ve Servisi Yeniden Başlat 🔁

Çıktı şu şekilde olacaktır:

🧪 Komut Özeti

✅ Sonuç

• CWP üzerinde mevcut Roundcube sürümü genellikle 1.4.x gibi eski.

• 1.5.11, en güncel güvenlik yamalarını içerir.

• Kurulum sırasında y onayını vermeyi unutmazsanız süreç sorunsuz ilerler.

• Olası hatalarda restart_cwpsrv komutu çoğu zaman çözüm sağlar. ✨

ℹ️ 1) Giriş

CentOS Web Panel (CWP) üzerinde PHP-FPM ile çalışan WHMCS sitelerinde
sıkça “503 Service Unavailable” hatası görülebilir.
Bu hata çoğunlukla process_control_timeout değerinin düşük olmasından kaynaklanır.

💡 Çözüm: Her PHP-FPM sürümünde bu değeri 30s yapmak ve servisi yeniden başlatmaktır.

🛠️ 2) Genel Yol Haritası

1. 🔑 CWP’ye root hesabıyla giriş yapın.
2. 📂 Sol Menü → PHP Selector → PHP-FPM Selector yolunu izleyin.
3. 📌 Düzenlemek istediğiniz sürümü seçin (örnek: php-fpm74).
4. ✏️ Config Edit butonuna tıklayın.
5. 📝 Açılan php-fpm.conf dosyasına şu satırı ekleyin:

   process_control_timeout = 30s

6. 💾 Kaydedin.
7. 🔄 Değişikliklerin aktif olması için PHP-FPM servisini yeniden başlatın:
   • 🖥️ CWP Panel: “Restart PHP-FPM” butonuna tıklayın.
   • 💻 SSH:

     systemctl restart php-fpmXX

     (XX → sürüm numarası, örn. 74, 80, 81…)

⚡ 3) PHP Sürümlerine Göre Uygulama

🔹 PHP-FPM 7.4

• Menüden php-fpm74 seçin.
• Config Edit → ekleyin:

  process_control_timeout = 30s

• Restart edin:

  systemctl restart php-fpm74

🔹 PHP-FPM 8.0

• php-fpm80 seçin.
• Config Edit → ekleyin:

  process_control_timeout = 30s

• Restart:

  systemctl restart php-fpm80

🔹 PHP-FPM 8.1

• php-fpm81 seçin.
• Config Edit → ekleyin:

  process_control_timeout = 30s

• Restart:

  systemctl restart php-fpm81

🔹 PHP-FPM 8.2

• php-fpm82 seçin.
• Config Edit → ekleyin:

  process_control_timeout = 30s

• Restart:

  systemctl restart php-fpm82

🔹 PHP-FPM 8.3

• php-fpm83 seçin.
• Config Edit → ekleyin:

  process_control_timeout = 30s

• Restart:

  systemctl restart php-fpm83

🔹 PHP-FPM 8.4

• php-fpm84 seçin.
• Config Edit → ekleyin:

  process_control_timeout = 30s

• Restart:

  systemctl restart php-fpm84

🔍 4) Test ve Doğrulama

• ✅ WHMCS üzerinde hesap oluşturma / askıya alma işlemini test edin.
• ❌ Hata devam ederse süreyi 40s yapın.
• 📜 Apache hata loglarını izleyin:

  tail -f /usr/local/apache/logs/error_log

🏁 5) Sonuç

👉 CWP üzerinde PHP 7.4’ten 8.4’e kadar tüm sürümlerde
process_control_timeout = 30s ayarı yapılıp servisler yeniden başlatıldığında,
WHMCS’deki “503 Service Unavailable” hataları büyük ölçüde çözülür.

1. CWP’nin Log Temizleme Scriptini Kullanma

CWP, kendi dahili temizleme scriptine sahiptir. Bu script, log dosyalarını hızlıca temizlemek için kullanılabilir. SSH üzerinden root olarak giriş yapın ve şu komutu çalıştırın:

Bu komut, gereksiz log dosyalarını temizleyecek ve disk alanı açacaktır.

2. Bash Script ile Hızlı Log Temizleme

Eğer kendi scriptinizi oluşturmak istiyorsanız, bash kullanarak basit bir script yazabilirsiniz. SSH terminaline bağlanarak şu adımları izleyin:

Bir bash script oluşturun:

İçine aşağıdaki kodları ekleyin:

Scripti çalıştırılabilir hale getirin:

Scripti çalıştırmak için:

3. Cron Job ile Otomatik Temizleme

Disk alanını düzenli olarak temizlemek için cron job oluşturabilirsiniz. Böylece belirlediğiniz periyotlarda loglar otomatik olarak temizlenir. SSH terminalinde cron job eklemek için:

Şu satırı ekleyin (her gece 3:00’te log temizleme için):

Bu yöntemlerle disk alanınızı optimize edebilir, log dosyalarını temizleyerek sunucu performansını artırabilirsiniz.

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:

Open SSL Kütüphanesini İndirin:

Nginx 1.26.1 Kaynak Kodunu İndirin ve Derleyin:

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:

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

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.

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

Güvenlik Duvarı Ayarları:

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

Nginx’i Yeniden Başlatın:

4. HTTP/3 ve QUIC Doğrulaması

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

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.