# Web sitenizdeki 502 Bad Gateway, 503 ve 504 hatalarını çözün

> 502 Bad Gateway, 503 Service Unavailable ve 504 Gateway Timeout ne anlama gelir; nginx, Apache ve PHP-FPM kayıtları nasıl okunur ve her neden nasıl çözülür.

Zorluk: Orta\
Denendiği sistemler: Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, Debian 12, Debian 13

502, 503 ve 504 hataları uygulamanızın önündeki web sunucusundan veya proxy'den gelir: o çalışıyordur, ama arkasındaki uygulama (PHP-FPM, Node.js, Python veya başka bir arka uç) doğru yanıt vermemiştir. Kayıtlar neredeyse her zaman nedeni söyler. Komutlar Ubuntu ve Debian'da PHP-FPM ile nginx veya Apache içindir; aynı yaklaşım diğer arka uçlarda da işe yarar.

## Başlamadan önce

- Tam kodu ve saati, ayrıca tüm sayfaların mı yoksa yalnızca bazılarının mı hata verdiğini not edin.
- SSH ile giriş yapın. Bir hosting hesabında bunun yerine cPanel veya Plesk'teki hata kaydını açın.
- Diskin dolu olmadığını (`df -h`) ve belleğin yeterli olduğunu (`free -h`) kontrol edin; ikisi de bu hatalara yol açar. Bkz. [disk dolu](/guides/disk-full) ve [yüksek CPU veya bellek kullanımı](/guides/high-cpu-memory).

## 1. adım: Hata kaydını okuyun

```bash
sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/apache2/error.log
```

Hata veren sayfayı yenileyin ve komutu tekrar çalıştırın: en yeni satırlar bu isteği anlatır. Aşağıdaki mesajlar hangi bölümü okumanız gerektiğini gösterir.

## 502 Bad Gateway

Web sunucusu arka uçtan geçerli bir yanıt alamadı. Tipik nginx mesajları:

```text
connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) while connecting to upstream
connect() to unix:/run/php/php8.3-fpm.sock failed (13: Permission denied) while connecting to upstream
upstream prematurely closed connection while reading response header from upstream
```

**Arka uç çalışıyor mu?** PHP-FPM servisini bulun ve kontrol edin; adı PHP sürümünü içerir:

```bash
systemctl list-units 'php*-fpm*'
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50
```

`php8.3-fpm` yerine ilk komuttaki adı yazın. Durmuşsa `sudo systemctl start` ile başlatın ve neden durduğunu okuyun.

**Soket yolu eşleşiyor mu?** nginx sitenizdeki `fastcgi_pass` satırı, PHP-FPM havuzunun dinlediği soketi (`/etc/php/` altındaki havuz dosyasında `listen =`) göstermelidir. Bir PHP yükseltmesinden sonra yoldaki sürüm çoğu zaman değişir.

Sokette **Permission denied**, web sunucusu kullanıcısının onu kullanamadığı anlamına gelir. Havuz dosyasındaki `listen.owner`, `listen.group` ve `listen.mode` ayarlarını kontrol edin.

**Prematurely closed**, PHP sürecinin isteği işlerken çöktüğü veya sonlandırıldığı anlamına gelir: PHP-FPM kaydına ve bellek yetersizliği sonlandırmaları için `journalctl -k` çıktısına bakın.

Değişikliklerden sonra test edip yeniden yükleyin:

```bash
sudo nginx -t
sudo systemctl reload nginx
sudo systemctl restart php8.3-fpm
```

## 503 Service Unavailable

Servis işi reddediyor. Sık nedenler:

- **Tüm PHP işçileri meşgul.** PHP-FPM kaydı `server reached pm.max_children setting` gösterir. Her işçi bellek kullanır; bu yüzden `pm.max_children` değerini yalnızca belleğin elverdiği kadar artırın (kabaca: kullanılabilir bellek bölü bir işçinin kullandığı bellek) ve yavaş istekleri önbellekle azaltın.
- Uygulamanın **bakım modu** (örneğin yarıda kalmış bir güncellemeden sonra). Güncellemeyi tamamlayın veya geri alın.
- nginx'teki **hız sınırları** (`limit_req`) veya bir web uygulaması güvenlik duvarı istekleri reddediyor. Kayıtta sınırlama mesajlarına bakın.
- **Sınırlarına ulaşmış bir hosting hesabı.** Paylaşımlı hostingte kaynak sınırları (CPU, bellek, giriş süreçleri) 503 hatası döndürebilir; kontrol panelinizdeki kaynak kullanımına bakın veya daha büyük bir plana geçin.

## 504 Gateway Timeout

Arka uç zaman aşımı içinde yanıt vermedi. nginx şunu kaydeder:

```text
upstream timed out (110: Connection timed out) while reading response header from upstream
```

Neyin yavaş olduğunu bulun: bir veritabanı sorgusu, bir dış API çağrısı, büyük bir içe aktarma. Veritabanınızın yavaş sorgu kaydı ve uygulamanın kendi kayıtları yardımcı olur. Yalnızca doğası gereği yavaş olan istekler için nginx location bloğundaki zaman aşımlarını artırın, örneğin:

```nginx
fastcgi_read_timeout 120s;
proxy_read_timeout 120s;
```

PHP-FPM için `fastcgi_read_timeout`, `proxy_pass` arkasındaki arka uçlar için `proxy_read_timeout` kullanın. PHP'nin kendi `max_execution_time` ayarı ve havuzdaki `request_terminate_timeout` betiği daha erken durdurabilir; bunları tutarlı tutun.

## Apache

Apache'de `mod_proxy` veya `mod_proxy_fcgi` kaynaklı proxy hataları için `/var/log/apache2/error.log` dosyasına bakın; örneğin arka uca başarısız bağlantılar veya zaman aşımları. Nedenler aynıdır: arka uç durmuştur, soketi veya portu `SetHandler` ya da `ProxyPass` satırıyla eşleşmiyordur ya da çok yavaştır. `ProxyTimeout`, Apache'nin bekleme süresini belirler. `sudo systemctl reload apache2` öncesinde yapılandırmayı `sudo apachectl configtest` ile test edin.

## Cloudflare arkasında

520 ile 526 arasındaki hatalar, sunucunuz Cloudflare'e iyi bir yanıt vermediğinde Cloudflare'den gelir:

| Kod | Anlamı |
|---|---|
| 520 | Bilinmeyen hata: sunucu boş veya geçersiz bir yanıt döndürdü |
| 521 | Web sunucusu bağlantıyı reddetti; örneğin durmuştur veya bir güvenlik duvarı Cloudflare'i engelliyordur |
| 522 | Sunucuya bağlantı zaman aşımına uğradı |
| 524 | Sunucu bağlantıyı kabul etti ama zamanında yanıt vermedi |
| 525 | Sunucuyla TLS el sıkışması başarısız oldu |
| 526 | SSL modu Full (strict) iken sunucunun sertifikası geçersiz |

Sunucuyu Cloudflare'i atlayarak doğrudan `curl -I --resolve example.com:443:203.0.113.10 https://example.com` ile test edin. Bkz. [sitenizin önünde Cloudflare](/guides/cloudflare-proxy-setup).

## Ne zaman destek bildirimi açmalı?

Sunucunun kendisine erişilemiyorsa ya da hatalar sizin tarafınızda hiçbir değişiklik olmadan başlıyor ve kayıtlar bir şey göstermiyorsa hizmeti seçerek; URL'yi, saati saat dilimiyle ve ilgili kayıt satırlarını ekleyerek bir destek bildirimi açın. Hosting planlarında alan adını ve kontrol panelindeki hata kaydından bir alıntıyı ekleyin.

## Sonraki adımlar

- Kaynaklar tükeniyor: [yüksek CPU veya bellek kullanımı](/guides/high-cpu-memory).
- Siteyi uçta koruyun: [sitenizin önünde Cloudflare](/guides/cloudflare-proxy-setup).

## Sık sorulan sorular

### 502, 503 ve 504 arasındaki fark nedir?

502 Bad Gateway: web sunucusu arkasındaki uygulamadan geçerli bir yanıt alamadı. 503 Service Unavailable: servis aşırı yüklü veya bakımda. 504 Gateway Timeout: uygulama zamanında yanıt vermedi.

### Hata kayıtlarını nerede bulurum?

nginx için /var/log/nginx/error.log, Ubuntu ve Debian'da Apache için /var/log/apache2/error.log, PHP-FPM için günlüğünde veya kayıt dosyasında. Hosting hesaplarında cPanel ve Plesk her sitenin hata kaydını gösterir.

### 504 hatalarını çözmek için zaman aşımlarını artırmam yeterli mi?

Yalnızca doğası gereği yavaş olan istekler için, örneğin dışa aktarmalar. Normal sayfalarda önce yavaş sorguyu veya dış çağrıyı bulun; daha uzun bir zaman aşımı sorunu yalnızca gizler ve işçileri meşgul eder.

### Hata sayfası Cloudflare'den bahsediyor. Sunucum kapalı mı?

520 ile 526 arasındaki hatalar, Cloudflare sunucunuzdan iyi bir yanıt alamadığında ondan gelir. Sunucunuzu doğrudan kontrol edin; 521 web sunucusunun bağlantıyı reddettiğini, 522 ve 524 zaman aşımlarını, 525 ve 526 TLS sorunlarını gösterir.

### Hatalar yalnızca yük altında görülüyor. Bu ne anlama gelir?

Uygulama yoğun saatlerde işçilerini veya belleğini tüketiyor. İşçi sayısını kullanılabilir belleğe göre ayarlayın, önbellek ekleyin veya daha büyük bir plana geçin.

---

Kaynak: <https://hyperdc.com/tr/guides/troubleshooting/website-502-503-504>\
Son güncelleme: 2026-10-09