ServBay Web Sunucusu Hata Giderme Rehberi

ServBay, varsayılan web sunucusu olarak Caddy, NGINX ve Apache kullanmanıza izin verir ve esnek bir yerel geliştirme ortamı sunar. Kullanım sürecinde sitenizin erişilememesi, yavaş yüklenmesi veya (örneğin 500 Dahili Sunucu Hatası) gibi hatalarla karşılaşabilirsiniz. Bu rehberde, ServBay ortamında karşılaşılan tipik web sunucusu sorunlarını teşhis edip çözmenize yardımcı olacak adımlar açıklanmıştır.

ServBay Dahili Hata Tanılama Aracının Kullanımı

ServBay, yaygın yapılandırma ve hizmet sorunlarını otomatik olarak tespit edip size bilgi veren güçlü bir hata tanılama aracı içermektedir. Bir sorunla karşılaştığınızda ilk adım olarak bu aracı kullanmanızı şiddetle öneririz.

ServBay uygulamasını açtıktan sonra, sol navigasyondan Hata Tanılama bölümüne tıklayarak ServBay'in kendi tanılama arayüzüne ulaşabilirsiniz.

Bu araç, ServBay'in çekirdek bileşenlerinin durumu, port kullanım durumu, yapılandırma dosyası sözdizimi gibi başlıkları denetler. Size yol gösterici uyarılar ve önerilerde bulunarak sorunun kaynağını hızlıca bulmanızı sağlar.

MAMP veya Laravel Herd’den Geçiş Sonrası Sitenin İlk Erişiminde Yavaşlık

Eğer MAMP veya Laravel Herd'den ServBay'e geçtiyseniz ve siteniz bir süre boşta kaldıktan sonra ilk erişimde 5 saniyeyi aşan gecikmeler yaşıyorsanız, fakat sonrasında hızlandığını fark ediyorsanız; benzer şekilde yine boşta bekledikten sonra ilk erişim tekrar yavaşlıyor olabilir.

Sorun Belirtileri

Chrome tarayıcısında geliştirici araçlarını açın (F12 ya da Cmd+Option+I tuşlarına basın), Ağ (Network) sekmesine geçin, sayfanızı yenileyip isteği seçin ve Zamanlama (Timing) bilgilerini görüntüleyin. DNS Lookup kısmında yaklaşık 5 saniye gibi bir süre görebilirsiniz.

(İllüstrasyon: Chrome geliştirici araçlarında DNS Lookup zamanlaması Network sekmesinde izleniyor)

Sorunun Nedeni

MAMP ve Laravel Herd, kurulum sırasında macOS sistem DNS ayarlarını özel şekilde değiştirerek belli alan adlarını (örneğin *.test, *.local gibi) hedeflemek için DNS çözümleyici yapılandırma dosyaları oluştururlar. Bu dosyalar genellikle /etc/resolver/ klasöründe bulunur.

Bu programları kaldırmış olsanız bile, ilgili DNS çözümleyici dosyaları sistemde kalabilir. Siz .test gibi aynı uzantılı bir web sitesine eriştiğinizde, macOS ilk önce bu eski çözümleyici dosyalarını kullanarak DNS sorgusu yapmaya çalışır; ancak MAMP/Herd DNS hizmetleri artık yok, bu nedenle DNS sorgusu zaman aşımına uğrar (yaklaşık 5 saniye) ve sonunda sistem varsayılan DNS ile çözümlemeye döner.

Çözüm Yöntemi

MAMP veya Laravel Herd tarafından bırakılan DNS yapılandırmalarını tamamen temizlemek için aşağıdaki adımları izleyin:

1. MAMP veya Laravel Herd’i Tamamen Kaldırın

Henüz tam kaldırmadıysanız, resmi kaldırıcı uygulamaları ya da kaldırma scriptlerini kullanın:

MAMP kaldırma:

• MAMP uygulamasının kaldırma fonksiyonunu kullanın
• Ya da /Applications/MAMP dizinini ve ilgili yapılandırmaları manuel silin

Laravel Herd kaldırma:

# Herd’in kaldırma komutunu kullanın
herd uninstall

# Eğer yukarıdaki komut çalışmazsa, Herd uygulamasını ve yapılandırmalarını manuel silin
rm -rf ~/Library/Application\ Support/Herd
rm -rf ~/.config/herd

2. /etc/resolver Klasöründeki Artık Dosyaları Silin

MAMP veya Herd’i doğru şekilde kaldırsanız dahi, /etc/resolver/ klasöründeki DNS çözümleyici dosyalar kalabilir. Bunları elle silmeniz gerekir:

# /etc/resolver dizinindeki dosyaları inceleyin
ls -la /etc/resolver

# Belirli çözümleyici dosyalarını (örneğin test ve local) silin
sudo rm /etc/resolver/test
sudo rm /etc/resolver/local

# Eğer başka MAMP/Herd kaynaklı dosyalar varsa, onları da silin
# Örnek: sudo rm /etc/resolver/herd

MAMP/Herd tarafından en sık oluşturulan resolver dosyaları:

• test - *.test alan adları için
• local - *.local alan adları için
• herd - Laravel Herd için özel dosya

Not: Bu dosyaları silmek için yönetici izni (sudo) gereklidir.

3. *.local Alan Adı Kullanımından Kaçının

macOS, *.local uzantısını yerel ağ (LAN) mDNS (Multicast DNS, Bonjour) servisi için ayırmıştır. .local'ı yerel geliştirmede kullanmak:

• DNS çözümleme çakışmaları
• Yavaş bağlantı
• Beklenmedik ağ davranışları

gibi sorunlara neden olabilir.

Tavsiyemiz: Yerel geliştirme için aşağıdaki alan adı uzantılarını tercih edin:

• .test - test amaçları için ayrılmış
• .localhost - daima yerel loopback adresine yönlenir
• .dev - gerçek bir TLD olup yerel geliştirmede de yaygın
• Ya da ServBay’in önerdiği kendi özel uzantınız

4. DNS Önbelleğini Temizleyin (İsteğe Bağlı)

Yukarıdaki adımları tamamladıktan sonra, değişikliklerin hemen etkin olması için sistem DNS önbelleğini temizleyin:

# macOS Big Sur (11) ve üstü
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# macOS Catalina (10.15) ve öncesi
sudo killall -HUP mDNSResponder

5. Düzeltmeyi Doğrulayın

Tüm temizlik işlemlerinden sonra ServBay web sitenizi yeniden test edin:

1. Tarayıcıyla yerel sitenize gidin
2. Chrome geliştirici araçlarını açın → Ağ (Network) sekmesine geçin
3. Sayfayı yenileyip isteğin Timing kısmına bakın
4. DNS Lookup süresinin normal (genellikle 50 ms’den az) olduğunu doğrulayın

Bu adımlarla MAMP veya Laravel Herd’den geçiş sonrası ilk erişimde yaşanan yavaşlık kesin olarak çözülmelidir. Sorun sürerse, VPN ya da proxy gibi başka üçüncü taraf araçların DNS’e müdahalesini de gözden geçirin.

Web Sunucusu Yapılandırma Dosyasının Kontrolü

Web sunucusu yapılandırma dosyasındaki hatalar sitenizin çalışmamasının temel nedenlerindendir. ServBay, her web sunucusu için özel sözdizimi kontrol araçları sağlar.

Caddyfile Denetimi

Caddy’nin dahili validate komutu ile Caddyfile dosyanızın doğru olup olmadığını doğrulayabilirsiniz.

# macOS
/Applications/ServBay/bin/caddy validate -c /Applications/ServBay/etc/caddy/Caddyfile

# Windows
C:\ServBay\bin\caddy.exe validate -c C:\ServBay\etc\caddy\Caddyfile

Yapılandırmanız doğruysa, komut Valid configuration mesajı döner. Hata varsa türüne göre uyarı verir.

Not: caddy validate komutu çoğunlukla çok sayıda INFO ya da WARN mesajı verebilir. Bunlar genellikle Caddy'nin içsel yükleme sürecine dair bilgiler olup, hata anlamına gelmez. Sonunda Valid configuration çıktısı varsa sözdizimi doğrudur.

Sık Karşılaşılan Caddyfile Hataları:

• Sertifika dosyası eksik hatası:

  # macOS örneği
  2024/12/09 17:24:16.970 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
  ... (diğer INFO/WARN mesajları) ...
  Error: loading http app module: provision http: getting tls app: loading tls app module: provision tls: loading certificates: open /Applications/ServBay/ssl/private/tls-certs/mail.servbay.host/mail.servbay.host.1crt: no such file or directory
  
  # Windows örneği
  2024/12/09 17:24:16.970 INFO using config from file {"file": "C:\\ServBay\\etc\\caddy\\Caddyfile"}
  ... (diğer INFO/WARN mesajları) ...
  Error: loading http app module: provision http: getting tls app: loading tls app module: provision tls: loading certificates: open C:\\ServBay\\ssl\\private\\tls-certs\\mail.servbay.host\\mail.servbay.host.1crt: no such file or directory

  loading certificates: open xxxxx: no such file or directory benzeri bir hata, Caddyfile’daki SSL sertifika yolu yanlış ya da dosya yok demektir. Sitenizin yapılandırmasında belirtilen sertifika (.crt/.cer/.pem) ve anahtar (.key) dosyalarının doğru yerde olup olmadığını kontrol edin. ServBay, manuel sertifika ekleme ve ACME otomatik SSL alınmasını destekler — ilgili ServBay SSL ayarlarına bakın.

• Site kök dizini yolunda (boşluk) hata:

  # macOS örneği
  2024/12/09 17:26:37.371 INFO using config from file {"file": "/Applications/ServBay/etc/caddy/Caddyfile"}
  Error: adapting config using caddyfile: parsing caddyfile tokens for 'root': too many arguments; should only be a matcher and a path, at /Applications/ServBay/etc/caddy/Caddyfile:1388
  
  # Windows örneği
  2024/12/09 17:26:37.371 INFO using config from file {"file": "C:\\ServBay\\etc\\caddy\\Caddyfile"}
  Error: adapting config using caddyfile: parsing caddyfile tokens for 'root': too many arguments; should only be a matcher and a path, at C:\\ServBay\\etc\\caddy\\Caddyfile:1388

  parsing caddyfile tokens for 'root': too many arguments hatası genellikle site kök dizin yolunda boşluk bulunduğunda ortaya çıkar. Örneğin:

  • macOS: root * /Applications/ServBay/www/public web satırındaki public web Caddy tarafından iki argüman olarak algılanır
  • Windows: root * C:\ServBay\www\public web yine iki argüman olarak algılanır

  Doğru kullanımda boşluk olan yol çift tırnak ile parantezlenmelidir:

  • macOS: root * "/Applications/ServBay/www/public web"
  • Windows: root * "C:\ServBay\www\public web"

  Tavsiye: Dosya ve klasör adlarında boşluk ya da özel simgelerden kaçının. Kelime ayırmak için tire - veya altçizgi _ kullanmak daha güvenlidir (public-folder, public_dir vs.).

• Rewrite kuralı hataları:

  Caddyfile içinde, Caddy'nin sözdizimine uymayan yeniden yönlendirme (Rewrite) kuralları örneğin doğrudan NGINX'ten kopyalandıysa, doğrulamada hata alınır. Caddy Rewrite modül belgesine veya ServBay NGINX’ten ServBay’e site taşımak rehberine başvurarak kurallarınızı doğru şekilde yapılandırın.

NGINX Yapılandırma Denetimi

NGINX’in yerleşik -t parametresi ile yapılandırma dosyasının sözdizimi ve doğruluğunu test edin.

# macOS
/Applications/ServBay/bin/nginx -t

# Windows
C:\ServBay\bin\nginx.exe -t

Yapılandırma doğruysa, çıktıda şunlar yazar:

# macOS
nginx: the configuration file /Applications/ServBay/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /Applications/ServBay/etc/nginx/nginx.conf test is successful

# Windows
nginx: the configuration file C:\ServBay\etc\nginx\nginx.conf syntax is ok
nginx: configuration file C:\ServBay\etc\nginx\nginx.conf test is successful

Hata varsa, NGINX size hatanın dosya ve satır bilgisini verir. Yaygın NGINX yapılandırma hataları:

1. Sözdizimi hatası: Örneğin noktalı virgül (;) eksik, parantez (}) uyumsuz gibi.
2. Dosya yolu hatası: include ya da benzeri talimatlarda yol yanlış ya da dosya yok.
3. Port çakışması: Belirtilen port başka uygulama tarafından kullanılıyor.

Apache Yapılandırma Denetimi

Apache’nin apachectl configtest komutu ile yapılandırma dosyasının sözdizimini kontrol edin.

# macOS
/Applications/ServBay/bin/apachectl configtest

# Windows
C:\ServBay\bin\httpd.exe -t

Sağlıklı yapılandırmada Syntax OK mesajı alırsınız; hata varsa ayrıntılı bilgi sunulur. Sık Apache yapılandırma hataları:

1. Modül yükleme hatası: Yapılandırmada etkinleştirilen modül (LoadModule) yok veya yolu hatalı.
2. .htaccess sözdizimi hatası: Site dizinindeki .htaccess dosyasında hata varsa, tüm yapılandırma veya o dizin bozulabilir.
3. Dizin izinleri hatalı: Directory, Files gibi talimatlarda izin (Require, Allow, Deny) yanlışsa siteye erişim engellenir.

500 Dahili Sunucu Hatası Çözümü

500 Internal Server Error, sunucu isteği işlerken beklenmedik bir sorunu gösteren genel bir HTTP durum kodudur. En sık sebep, arka uç betiğin (ör. PHP, Python, Node.js) başarısız çalışmasıdır.

Genel Teşhis Adımları

500 hatasıyla karşılaştığınızda aşağıdaki adımları uygulayın:

1. Web sunucusu hata günlüğünü kontrol edin: Bu ilk adım olmalı. Hata günlüklerinde betik hatası, dosya eksikliği, izin sorunu gibi detaylar olur.

   macOS:

   • Caddy: /Applications/ServBay/var/logs/caddy/error.log
   • NGINX: /Applications/ServBay/var/logs/nginx/error.log
   • Apache: /Applications/ServBay/var/logs/apache/error.log

   Windows:

   • Caddy: C:\ServBay\var\logs\caddy\error.log
   • NGINX: C:\ServBay\var\logs\nginx\error.log
   • Apache: C:\ServBay\var\logs\apache\error.log

   Son günlüklerden error veya critical içeren satırlara bakın.

2. Arka uç hizmetlerinin (örneğin PHP-FPM) çalıştığını doğrulayın: Siteniz PHP’ye bağlıysa PHP-FPM’ın açık olduğuna bakın.

   ps aux | grep php-fpm

   php-fpm: master process veya php-fpm: pool www satırlarını arayın. Görünmüyorsa, PHP-FPM başlatılmamış ya da çökmüş demektir. ServBay UI veya servbayctl ile hizmeti yeniden başlatabilirsiniz.

3. Arka uç betik (örneğin PHP) hata günlüğünü inceleyin: Web sunucusu günlüklerinde FastCGI veya betik hatası işaret ediliyorsa, ilgili dilin hata günlüğüne bakın.

   PHP hata günlüğü konumu:

   • macOS: /Applications/ServBay/var/logs/php/php_error.log
   • Windows: C:\ServBay\var\logs\php\php_error.log

   Özellikle erişmeye çalıştığınız betikle alakalı Fatal error, Parse error, Warning, Notice gibi mesajları inceleyin. Üretim ortamında display_errors kapalı olmalıdır; geliştirme ortamında geçici olarak açıp hataları doğrudan görmek için php.ini'de ayar yapabilirsiniz.

4. Dosya ve klasör izinlerini denetleyin: Web sunucu işlemi belirli bir kullanıcıyla çalışır ve dosya/dizini okuyabilmesi, upload/log için yazabilmesi gerekir.

   macOS:

   ls -la /Applications/ServBay/www/your-site/

   Web sunucu kullanıcısının (ör. _www) site kök dizini ve alt klasörlerinde okuma iznine sahip olduğundan emin olun. Upload ve log için yazma izni de gerekebilir. chmod ve chown ile ayar yapabilirsiniz.

   Windows:

   dir C:\ServBay\www\your-site

   Windows’ta, ServBay’i çalıştıran kullanıcının site klasörüne uygun erişimi olmalı. Dosya özelliklerinden güvenlik sekmesiyle izinleri ayarlayın.

Belirli Web Sunucularında 500 Hata Çözümü

• Caddy:

  1. FastCGI yapılandırması: Caddyfile’daki php_fastcgi veya reverse_proxy komutunun doğru PHP-FPM adresine (genellikle 127.0.0.1:9000 veya unix:/path/to/php-fpm.sock) yönlendiğinden emin olun.
  2. PHP-FPM durumu: ServBay’de ilgili PHP sürümünün ve PHP-FPM servisinin çalıştığını doğrulayın.
  3. Reverse proxy ayarı: Eğer reverse_proxy ile başka bir arka uca (örneğin Node.js) yönlendirme yapılıyorsa, adres ve portun doğru, servisin aktif olduğuna bakın.

• NGINX:

  1. fastcgi_pass ayarı: nginx.conf veya siteye ait yapılandırma dosyasındaki fastcgi_pass komutunun PHP-FPM adresine doğru işaret ettiğinden emin olun.
  2. client_max_body_size: Büyük dosya yüklerken 500 hatası alınıyorsa, bu değer çok düşük olabilir; artırılması gerekebilir.
  3. try_files komutu: try_files ayarının, ilgili index dosyasını bulmaya ya da isteği FastCGI'ya aktarmaya uygun olduğuna bakın.

• Apache:

  1. mod_rewrite modülü: .htaccess ile URL yönlendirme kullanıyorsanız, Apache’de mod_rewrite yüklü ve etkin olmalı.
  2. .htaccess içeriği: .htaccess dosyasındaki yanlış komutlar doğrudan 500 hatası doğurur. Özellikle RewriteRule ve benzeri satırları gözden geçirin.
  3. AllowOverride ayarı: İlgili dizinde .htaccess talimatlarının etkin olabilmesi için yapılandırmada AllowOverride’un doğru şekilde (All ya da en azından FileInfo, Limit) ayarlandığını kontrol edin.

Hizmet Yönetimi

Yapılandırma dosyasını değiştirdikten veya arka uç sorunlarını giderdikten sonra, değişikliklerin uygulanması için web sunucusunu veya ilgili hizmetleri yeniden başlatmak gerekir.

Hizmeti Yeniden Başlatmak

Belirli bir web sunucusunu baştan başlatmak için servbayctl restart komutunu kullanın.

# Caddy hizmetini yeniden başlat
servbayctl restart caddy -all

# NGINX hizmetini yeniden başlat
servbayctl restart nginx -all

# Apache hizmetini yeniden başlat
servbayctl restart apache -all

-all parametresi, web sunucusu ile ilgili ek hizmetleri (örneğin FastCGI yapılandırıldıysa PHP-FPM) de yeniden başlatır.

Hizmet Durumunu Kontrol Etmek

Belirli bir hizmetin çalışma durumunu görebilmek için servbayctl status komutunu kullanın.

# Caddy hizmeti durumunu göster
servbayctl status caddy -all

# NGINX hizmeti durumunu göster
servbayctl status nginx -all

# Apache hizmeti durumunu göster
servbayctl status apache -all

Komut çıktısı hizmetin running (çalışıyor), stopped (durduruldu) veya başka bir durumda olduğunu gösterir. Hizmetin başarıyla çalışıp çalışmadığını anlamak için kontrol edin.

İleri Düzey Sorun Giderme Adımları

Yukarıdaki adımlar çözüm olmadıysa aşağıdaki kapsamlı incelemeleri deneyebilirsiniz:

1. Tarayıcı geliştirici araçlarını kontrol edin: Genellikle F12 tuşuyla açılan araçlarda Konsol (Console) ve Ağ (Network) sekmelerine geçin. Ön uç JavaScript hatası, isteklerin detaylı durum kodu, yanıt başlığı ve gövdesi gibi bilgiler sorunun ön yüzde mi yoksa arka yüzde mi olduğunu gösterir.
2. curl -v komutu ile test edin: Terminalde curl -v your-website.servbay.demo komutunu kullanarak sitenize erişin. -v parametresi istek/yanıt başlıkları, SSL/TLS bağlantı durumu, hata mesajları gibi detayları gösterir. your-website.servbay.demo örneğini kendi ServBay alan adınızla değiştirin.
3. Geçici olarak güvenlik duvarını kapatıp test edin: Yerel (macOS) veya üçüncü taraf güvenlik yazılımı ServBay gelen bağlantıları engelliyor olabilir. Geçici olarak güvenlik duvarını kapatıp test edin; çözülüyorsa ilgili portlara (80, 443 gibi) erişime izin vermelisiniz.
4. Farklı tarayıcı/cihazda test edin: Sorunun herkeste mi yoksa belli cihazda mı olduğunu görmek için başka tarayıcı veya cihazla deneyin. Tarayıcı önbelleği veya cihaz ayarları problemi dışlayabilirsiniz.
5. Yerel DNS veya hosts dosyasını inceleyin: Özel alan adı (ör. localhost veya IP değilse) kullanıyorsanız, hosts dosyası veya yerel DNS ayarınız doğru şekilde 127.0.0.1 veya ::1’e yönlenmiş olmalı.
   • macOS: /etc/hosts
   • Windows: C:\Windows\System32\drivers\etc\hosts

Sonuç

Web sunucusu sorunları yerel geliştirme süreçlerinde sıkça yaşanır. Yapılandırma dosyasını düzgün analiz etmek, hata günlüklerini incelemek, hizmetlerin durumu ve dosya izinlerini kontrol etmek çoğu problemi çözer. ServBay’in dahili hata tanılayıcısı ve servbayctl komut satırı aracı en büyük yardımcılarınızdır. Karmaşık durumlarda ayrıntılı ServBay belgelerini incelemekten veya teknik destek ekibine ulaşmaktan çekinmeyin.