cPanel 500 hatası nasıl çözülür? (Internal Server Error)
Siteniz açılırken 500 Internal Server Error görüyorsanız sunucu, o isteği tamamlayamamıştır. Ekrandaki kısa mesaj nedenini söylemez. Son yapılan değişiklikle aynı saate ait hata kaydını birlikte incelemek, doğru dosyaya veya ayara ulaşmanızı sağlar.
Bu rehber cPanel hosting hesabı kullanan müşteriler içindir. .htaccess hatası, PHP kod hatası ve PHP bellek sınırı sorununu birbirinden ayırarak ilerler. Başlamak için DCHost müşteri portalından cPanel'e giriş yapın.
1. Önce gerçekten 500 yanıtı aldığınızı kontrol edin
Hatanın görüldüğü tam sayfa adresini, saati ve son yaptığınız değişikliği not edin. Ana sayfa açılırken yalnız bir form veya alt sayfa hata verebilir; kontrol edeceğiniz adres, sorun çıkan adres olmalıdır.
- Tarayıcıda geliştirici araçlarını açın; Chrome ve Edge'de F12 → Network yolunu kullanabilirsiniz.
- Sorunlu sayfayı bir kez yeniden açın. Gönderilmiş ödeme veya sipariş formunu tekrar tekrar göndermeyin.
- Listede ilgili sayfa isteğini seçin. Status Code değerini okuyun.
- Sayfada “500” yazmasıyla sunucunun gerçekten
500yanıt kodu vermesini ayırın. Özel hata sayfaları farklı kodla dönebilir.
Ekranlardaki örnekler, çalışan site dosyalarından ayrı bir deneme klasöründe hazırlandı. İlk örnekte .htaccess içindeki geçersiz komut, isteğin HTTP 500 dönmesine neden oldu. Düzeltmeden sonra aynı adresi yeniden kontrol edeceğiz.
Örnekte sunucu isteği tamamlayamadığını bildiriyor.
1. adım: Hata metnini başlangıç noktası olarak kullanın
- Hata metnini başlangıç noktası olarak kullanın
Internal Server Error başlığı tek başına hangi dosyanın bozuk olduğunu söylemez. Aynı isteğin yanıt kodunu Network ekranında doğrulayın, saati not edin ve ilgili hata günlüğüne geçin.
Bu ekran .htaccess denemesindeki ilk hata durumudur. Sayfa metni, HTTP yanıt başlığının yerine geçmez.
| Kod | Ne anlama gelir? | İlk bakılacak yer |
|---|---|---|
| 500 Internal Server Error | Sunucu beklenmeyen bir durum nedeniyle isteği tamamlayamadı. | Aynı isteğin web/PHP hata kaydı ve son değişiklik |
| 502 Bad Gateway | Aradaki ağ geçidi veya vekil, arka sunucudan geçerli yanıt alamadı. | Varsa CDN/vekil ile uygulama veya PHP servisi arasındaki bağlantı |
| 503 Service Unavailable | Hizmet geçici yoğunluk veya bakım gibi bir nedenle isteği karşılayamıyor. | Hizmet durumu, bakım ve kaynak kullanımı |
| 504 Gateway Timeout | Ağ geçidi veya vekil, arka sunucudan zamanında yanıt alamadı. | Geciken uygulama isteği, servis ve zaman aşımı kayıtları |
Bu kodların hepsine aynı .htaccess düzenlemesini uygulamayın. Sertifika uyarısı veya alan adı çözülememesi de ayrı sorunlardır; gerekiyorsa HTTPS kontrol rehberini kullanın. cPanel'in açılması, aynı hesaptaki web uygulamasının çalıştığını tek başına göstermez.
Gerçek yanıt kodu 403 Forbidden ise 403 hatası rehberindeki site klasörü, index dosyası, izin ve erişim kuralı kontrolleriyle ilerleyin.
2. Doğru site klasörünü ve geri dönüş kopyasını hazırlayın
Domains → Domains bölümünde ilgili alan adının Document Root bilgisini bulun. Sonra Files → File Manager ile o klasörü açın. Her sitenin dosyalarının public_html kökünde olduğunu varsaymayın.
Değişiklikten önce:
- Düzenleyeceğiniz dosyanın mevcut kopyasını Download ile bilgisayarınıza alın veya web kökü dışındaki özel bir klasöre kopyalayın.
- Son çalışan sürümü biliyorsanız mevcut hatalı kopyadan ayrı saklayın. Hatalı dosyanın yedeğini almak, çalışan sürüme sahip olduğunuz anlamına gelmez.
- Dosyanın tam yolunu, değiştireceğiniz satırı ve zamanı not edin.
- Aynı anda bir neden üzerinde çalışın. PHP sürümü,
.htaccessve uygulama kodunu birlikte değiştirmeyin.
Parola veya özel ayar içeren .bak, .old ve ZIP dosyalarını web kökünde bırakmayın. Projeniz Git veya başka bir dağıtım sistemiyle yönetiliyorsa düzeltmeyi o iş akışına da dahil edin; sonraki dağıtım panelden yaptığınız değişikliği silebilir. Ayrıntılı kullanım için cPanel Dosya Yöneticisi rehberine bakın.
Örnek: dosyayı web kökü dışına kopyalama
Bu çalışmada .htaccess dosyası File Manager → Copy ile, hesap ana dizinindeki web kökü dışında bulunan error-guide-private klasörüne htaccess-before.txt adıyla kopyalandı. Copy ekranındaki hedef /error-guide-private/htaccess-before.txt idi. Bu, düzenleme öncesindeki dosyanın kopyasıdır; henüz hatalı satırı da içerir.
Kendi hesabınızda webden erişilemeyen uygun bir hedef seçin. Örnekteki klasörün her hosting hesabında hazır bulunduğunu varsaymayın.
.htaccess dosyasını seçip Copy penceresini açın.
1. adım: Özel hedef klasörünü seçin
- Özel hedef klasörünü seçin
Copy alanındaki yol hesabınızın ana dizinine göre yazılır. Önceden oluşturduğunuz, public_html dışında kalan özel klasörü kullanın; yedeği webden indirilebilir bir yere koymayın.
- Copy Files ile kopyayı oluşturun
Copy Files düğmesine basın; hedef klasöre giderek dosyanın oluştuğunu kontrol edin. Görsel, işlemin onayından önceki ekranı gösterir.
Mevcut hatalı dosyanın kopyasıyla son çalışan sürümü ayrı saklayın; bunlar aynı yedek değildir.
3. Hata kaydını bulun ve doğru satırı okuyun
Önce Metrics → Errors ekranını açın
cPanel → Metrics → Errors, web sunucusunun en yeni 300'e kadar hata kaydını, yeniler üstte olacak şekilde gösterir. Sorunu yaşadığınız saate ve ilgili dosyaya ait satırı bulun. Eski bir hata satırının görünmesi, son yaptığınız düzeltmenin başarısız olduğu anlamına gelmez.
Bu örneğin .htaccess hatası aşağıdaki kayıtla görünüyor. Komutun tanınmadığını söyleyen kısma bakın:
Invalid command 'InvalidDirectiveForGuide'
Hata metnini, dosya yolunu ve deneme saatini birlikte okuyun.
1. adım: Invalid command kaydını inceleyin
- Invalid command kaydını inceleyin
Örnekte Invalid command 'InvalidDirectiveForGuide' kaydı .htaccess dosyasını işaret ediyor. Bu satırın saatiyle sorunlu isteğin saatini eşleştirin; eski bir kayıt son denemenin sonucunu göstermez.
Kaynak IP ve hesap adı gizlidir. Bu log ekranı tek başına HTTP yanıt kodunu göstermez.
Bir satırda şu bilgileri birlikte okuyun:
| Bilgi | Nasıl kullanılır? |
|---|---|
| Tarih ve saat | Tarayıcıdaki hatayla eşleştirin; sunucu ile bilgisayarınızın saat dilimi farklı olabilir. |
| Hata metni | Invalid command, Parse error veya Allowed memory size gibi asıl nedeni gösteren kısmı bulun. |
| Dosya yolu | Hatanın hangi siteye ve dosyaya ait olduğunu ayırır. |
| Satır numarası | Kod incelemesine nereden başlanacağını gösterir; asıl hata bazen bir önceki satırdadır. |
Errors boşsa PHP günlüğünü de kontrol edin
PHP-FPM ve uygulamanız, hatalarını ayrı bir dosyaya yazabilir. Errors ekranı bütün PHP ve uygulama günlüklerinin birleşimi değildir.
Önce ilgili alan adının etkin PHP hata günlüğünü belirleyin. Dosya adı ve konumu yapılandırmaya göre değişir. Erişebildiğiniz dosyayı File Manager → View ile okuyun; günlük görünmüyorsa destek ekibinden etkin konumu kontrol etmesini isteyin.
Bu örnekte kayıt, File Manager → hesap ana dizini (Home) → logs altında, ilgili alan adına ait ve adı .php.error.log ile biten dosyadaydı. Uygulama içindeki ini_set('error_log', ...) denemesi, PHP-FPM’in yönetici günlük ayarını değiştirmedi. Bu nedenle başka bir dosyanın boş kalması, PHP hatasının kaydedilmediğini göstermedi; hata etkin günlükte bulundu.
Bu hesapta PHP-FPM hataları Home altındaki logs klasörüne yazılıyor.
1. adım: Home altındaki logs klasörünü bulun
- Home altındaki logs klasörünü bulun
File Manager içindeki Home alanına dönüp logs klasörünü açın. Bu konum public_html altında değildir; günlükleri ziyaretçilere açık klasöre taşımayın.
- İlgili .php.error.log dosyasını görüntüleyin
Alan adına ait .php.error.log dosyasını seçip üstteki View düğmesine basın. Dosya adının özel kısmı gizlidir. Farklı hesaplarda konum değişebilir; güncel isteğin gerçekten bu dosyaya yazıldığını doğrulayın.
Uygulamada error_log yolunu değiştirmek PHP-FPM tarafından zorlanan ayarı her zaman geçersiz kılmaz. Etkin günlük konumunu esas alın.
Aşağıdaki PHP kodu örneğinde, bu dosyadaki hata satırını okuyacağız. logs konumunu ve dosya adını bütün cPanel hesapları için sabit bir kural olarak kullanmayın.
| Günlükteki örnek ifade | Olası neden | İlgili bölüm |
|---|---|---|
Invalid command / not allowed here | .htaccess içindeki komut tanınmıyor veya o konumda kullanılamıyor. | .htaccess kontrolü |
PHP Parse error / syntax error | PHP dosyasında sözdizimi hatası var. | PHP kodunu kontrol etme |
PHP Fatal error / Uncaught Error | PHP çalışması bir hata nedeniyle durdu. | PHP kodunu kontrol etme |
Allowed memory size … exhausted | O PHP çalışması izin verilen bellek sınırına ulaştı. | Bellek sınırını inceleme |
Permission denied | Dosya sahipliği veya erişim izni işlemi engelliyor olabilir. | Dosya izinleri |
Tablodaki ifadeler yaygın hata türlerini tanımak içindir. Kendi günlüğünüzdeki tam hata, dosya ve saati esas alın. Her PHP warning veya notice kaydı 500 yanıtı oluşturmaz; eski ya da ilgisiz bir uyarıyı son hatanın nedeni saymayın.
4. .htaccess değişikliğinden sonra başlayan 500 hatasını giderin
.htaccess, bulunduğu klasör ve alt klasörler için web sunucusu kuralları içerebilir. Yönlendirme, erişim kısıtlaması ve uygulama kuralları aynı dosyada bulunabilir. Hatalı bir satır, o kapsamdaki isteğin uygulamaya ulaşmadan durmasına neden olabilir.
Hata sayfasının sonunda Additionally … ErrorDocument … yazıyorsa sunucu, hatayı göstermek için kullanacağı sayfayı da işleyememiştir. Aynı .htaccess sorunu bu ek mesajı tetikleyebilir; bunu otomatik olarak ikinci, bağımsız bir arıza saymayın. Önce günlükteki asıl hatayı bulun.
- Hata günlüğünde adı geçen klasörü File Manager ile açın.
- Dosya görünmüyorsa Settings → Show Hidden Files (dotfiles) → Save yolunu izleyin.
.htaccessdosyasını seçin; mevcut kopyasını indirin veya özel yedekleme adımındaki gibi web kökü dışına kopyalayın. Ardından Edit ile açın.- Günlüğün işaret ettiği komutu son değişiklikle karşılaştırın. Hatalı satırı, bildiğiniz çalışan hâline döndürün; başka kuralları değiştirmeyin.
- Save Changes ile kaydedin. Aynı sayfayı yeniden açın ve yeni hata kaydı oluşup oluşmadığına bakın.
File Manager içinde Settings ile Preferences penceresini açın.
- Show Hidden Files seçeneğini açın
Show Hidden Files (dotfiles) kutusunu işaretleyin. Noktayla başlayan .htaccess gibi dosyalar böyle görünür.
- Save ile görünüm ayarını kaydedin
Save düğmesine basın, ardından hata günlüğünde belirtilen klasörde .htaccess dosyasını bulun.
Bu ayar dosyanın görünmesini sağlar; içindeki hatalı kuralı değiştirmez.
Örnek: yalnız son eklenen hatalı satırı kaldırma
Ayrı test klasörünün .htaccess dosyasına, senaryoyu göstermek için InvalidDirectiveForGuide adlı geçersiz bir komut eklenmişti. Apache günlüğündeki komut adı ile editördeki son eklenen satır eşleştirildi.
Edit ekranında yalnızca hata günlüğünün işaret ettiği dosyayı inceleyin.
1. adım: Hatalı satırı günlükle eşleştirin
- Hatalı satırı günlükle eşleştirin
Dördüncü satırdaki InvalidDirectiveForGuide On, Errors ekranındaki Invalid command kaydıyla eşleşiyor. Bu satır rehber için bilerek hatalı yazılmıştır; kendi sitenize eklemeyin.
Bu, düzeltmeden önceki dosyadır. Gerçek dosyanızda hatalı kural ve satır numarası farklı olabilir.
Düzenleme öncesi kopya alındıktan sonra Edit ekranında yalnız bu eklenen satır kaldırıldı. Dosyanın diğer kuralları korundu. Save Changes ile kaydedildiğinde Success! onayı göründü.
Ardından aynı adres yeniden açıldığında HTTP yanıtı 500'den 200'e döndü ve beklenen sayfa açıldı. Siz de kaydetme onayından sonra sayfanın çalıştığını ayrıca kontrol edin.
Düzeltmeden sonra beklenen örnek sayfa içeriği açılıyor.
1. adım: Beklenen içeriği doğrulayın
- Beklenen içeriği doğrulayın
Daha önce hata veren adresi yeniden açın. Burada Örnek sayfa açılıyor başlığı ve sayfa metni görünüyor. Kendi sitenizde doğru sayfanın ve işlevlerin çalıştığını kontrol edin.
Bu görsel sayfa içeriğini gösterir; sayısal HTTP kodu görünmez. Yanıt kodunu tarayıcının Network ekranında ayrıca kontrol edin.
Bütün dosyayı silmeyin veya rastgele yeniden adlandırmayın. Bu işlem parola korumasını, erişim kısıtlarını, HTTPS yönlendirmesini ve uygulamanın adres kurallarını devre dışı bırakabilir. Yalnız yeni eklenen hatalı satır belliyse onu geri alın. Hangi satırın gerekli olduğunu bilmiyorsanız kayıtla birlikte destek isteyin.
not allowed here mesajı her zaman yazım hatası değildir. Komut bulunduğu konumda yasak olabilir veya sunucu o özelliği hesabınıza açmamış olabilir. Müşteri cPanel hesabında bunu düzeltmek için sunucunun genel Apache izinlerini değiştirmeye çalışmayın.
PHP-FPM'de .htaccess içine php_value yazmak neden hata verebilir?
İnternetten kopyalanan php_value veya php_flag satırları her PHP çalışma biçiminde kullanılmaz. PHP-FPM, .htaccess içindeki bu satırları PHP ayarı yapmanın genel yolu olarak kullanmaz. Apache komutu tanımıyorsa Invalid command 'php_value' gibi bir kayıtla 500 yanıtı oluşabilir.
PHP ayarı için hesabınızdaki Software → MultiPHP INI Editor aracını ve hizmetin desteklediği yöntemi kullanın. cPanel'in oluşturduğu PHP handler veya LSAPI bloklarını topluca silmeyin; bazı başka çalışma biçimlerinde bu blokların görevi vardır. MultiPHP Manager sürüm/çalışma biçimini gösterir; her 500 hatasında PHP-FPM'i kapatmanız gerekmez.
5. PHP sözdizimi ve fatal hatasını düzeltin
PHP Parse error veya syntax error, PHP'nin kodu okuyamadığını belirtir. Eksik noktalı virgül, kapanmayan tırnak/parantez veya desteklenmeyen sözdizimi neden olabilir. PHP Fatal error daha geniş bir gruptur; örneğin bulunamayan bir işlev veya yakalanmamış hata PHP çalışmasını durdurabilir.
- Günlükteki dosya yolunu ve satır numarasını not edin.
- Doğru dosyayı File Manager → Edit ile açın. Hatanın işaret ettiği satırla birlikte hemen öncesini inceleyin.
- Dosyayı son çalışan sürümle karşılaştırın. Hata son düzenlemeden sonra başladıysa yalnız o değişikliği geri alın veya düzeltilmiş sürümü yükleyin.
- Kaydettikten sonra aynı isteği yeniden deneyin. Günlükte eski kayıt kalabilir; yeni saatte aynı hatanın tekrarlanıp tekrarlanmadığını kontrol edin.
Örnek: hata bir sonraki satırı gösterebilir
Bu ayrı testte, değişken atamasının bulunduğu 2. satırın sonundaki noktalı virgül eksikti. Tarayıcı isteği HTTP 500 verdi. Alan adının etkin PHP günlüğünde şu kayıt oluştu; hesap adı burada gizlenmiştir:
PHP Parse error: syntax error, unexpected token "echo" in /home/[account]/public_html/error-guide/php/app.php on line 3
Günlük, beklenmeyen echo ifadesini ve app.php dosyasının üçüncü satırını işaret ediyor.
1. adım: Mesajı dosya ve satırla birlikte okuyun
- Mesajı dosya ve satırla birlikte okuyun
PHP Parse error: syntax error, unexpected token "echo" kaydı app.php on line 3 ile bitiyor. Üçüncü satırı ve hemen öncesini inceleyin; bu örnekte eksik noktalı virgül ikinci satırdadır.
Günlüğün zaman damgasını son denemeyle eşleştirin. Eski satırların dosyada kalması, düzeltmenin başarısız olduğunu göstermez.
Günlük 3. satırdaki echo ifadesini bildiriyor. İnceleme, hemen önceki atama satırının ; ile bitmediğini gösterdi. Bu yüzden yalnız hata mesajında yazan satırı değil, önceki satırı da okuyun.
Bu dosya da değişiklikten önce File Manager → Copy ile yedeklendi. Edit ekranında 2. satırdaki atamanın sonuna eksik ; eklendi; başka bir PHP ayarı değiştirilmedi. Save Changes sonrasında Success! mesajı görüldü.
Örnekte yalnızca ikinci satırın sonuna noktalı virgül eklendi.
1. adım: Atamanın doğru biçimde bittiğini kontrol edin
- Atamanın doğru biçimde bittiğini kontrol edin
İkinci satır artık noktalı virgülle bitiyor; üçüncü satırdaki echo ifadesi korunuyor. Bu değişiklik, günlükte doğrulanan bu sözdizimi hatasını giderir.
- Save Changes ile kaydedin
Save Changes düğmesine basıp aynı PHP adresini yeniden açın. Beklenen çıktıyı, yanıt kodunu ve denemeden sonra yeni hata kaydı oluşup oluşmadığını kontrol edin.
Bir noktalı virgül eklemek her PHP hatasının çözümü değildir; düzeltme gerçek hata mesajına dayanmalıdır.
Aynı adres yeniden açıldığında HTTP 200 döndü ve “PHP örneği yeniden çalışıyor” metni görüntülendi.
Dosyada Türkçe karakterler bozuk görünüyorsa kaydetmeden çıkın ve karakter kodlamasını kontrol edin. Uygulamanın ürettiği veya dağıtımla gelen bir dosyayı rastgele düzenlemek yerine projenin güncel çalışan sürümünü kullanın.
Hata PHP sürümü değişince başladıysa Software → MultiPHP Manager altında yalnız ilgili alan adının sürümünü kontrol edin. Uygulamanızın desteklediği sürüm ve uzantıları esas alın. Bulunamayan bir işlev, yazım hatasından da eksik bir uzantıdan da kaynaklanabilir; bütün uzantıları kurmak veya en eski PHP'ye dönmek genel çözüm değildir. PHP ayarları rehberi bu kontrolü ayrıntılandırır.
WordPress “Sitenizde kritik bir hata oluştu” mesajı veya beyaz ekran gösteriyorsa WordPress kritik hata rehberindeki kurtarma modu ve eklenti kontrollerini izleyin. Yönetim paneli de açılmıyorsa cPanel’den sorunlu eklentiyi kapatma adımlarıyla ilerleyin. Günlükte adı geçen bileşenin kendi düzeltme/geri dönüş yöntemini kullanın; bütün WordPress dosyalarını değiştirmek veya veritabanını sıfırlamak gerekmez.
6. Ayrıntılı hatayı ziyaretçiye göstermeden kaydedin
Canlı sitede hedef, hata ayrıntılarını ekrana basmak yerine inceleyebileceğiniz bir günlüğe yazmaktır:
| Ayar | Canlı sitede hedef | Ne yapar? |
|---|---|---|
display_errors | Off | PHP hata ayrıntılarının ziyaretçiye gösterilmesini kapatır. |
log_errors | On | Yapılandırılan PHP hata günlüğüne kayıt yazılmasını sağlar. |
error_log | Hizmetin kullandığı, webden erişilmeyen yazılabilir konum | Hatanın nereye yazıldığını belirler; erişim ve üst düzey FPM ayarları da geçerlidir. |
Software → MultiPHP INI Editor → Basic Mode içinde ilgili alan adını seçin. Tek siteyi incelerken Home Directory ile hesabın tüm sitelerine değişiklik uygulamayın. Sunulan ayarları kontrol edin; değiştirmeniz gerekiyorsa önceki değerleri kaydedip Apply kullanın.
Aşağıdaki ekranda, seçili alan adının display_errors ayarı Disabled, log_errors ayarı Enabled görünüyor. Değerler uygunsa değiştirmeden çıkabilirsiniz; bu örnekte ayarlar yalnız kontrol edildi, Apply kullanılmadı.
MultiPHP INI Editor içinde doğru alan adını seçerek mevcut ayarları kontrol edin.
1. adım: display_errors için Disabled durumunu doğrulayın
- display_errors için Disabled durumunu doğrulayın
display_errors satırında Disabled görünüyor. Canlı sitede ayrıntılı PHP hatalarının ziyaretçiye gösterilmemesi, dosya yolları ve uygulama ayrıntılarının açığa çıkmasını önler.
- log_errors için Enabled durumunu doğrulayın
log_errors satırında Enabled görünüyor. Hataları incelemek için etkin günlük dosyasını kullanın; PHP-FPM ayarları, bu ekrandaki error_log alanından farklı bir konumu zorlayabilir.
Bu ekranda yalnızca mevcut değerler kontrol edildi; Apply ile değişiklik yapılmadı. Alan adı, hesap yolu ve form girdileri gizlenmiştir.
Aradığınız ayar görünmüyorsa veya kaydettiğiniz değer web uygulamasında etkili olmuyorsa destek isteyin. PHP-FPM havuzunun yönetici ayarları bazı değerleri kısıtlayabilir. .user.ini kullanılan yapılandırmalarda değişikliklerin yeniden okunması da hemen olmayabilir. Ayarın kaydedildiği mesajı, PHP isteğinin yeni değerle çalıştığını tek başına göstermez.
Bir dosyanın başına ini_set() eklemek, o dosyanın sözdizimi hatasını mutlaka görünür yapmaz: PHP dosyayı çalıştırmaya başlayamıyorsa bu satır da çalışmaz. Günlük yapılandırmasını doğru katmanda kontrol edin. Herkese açık phpinfo() sayfası veya ayrıntılı hata çıktısı bırakmayın.
7. Allowed memory size exhausted hatasını inceleyin
Allowed memory size … bytes exhausted mesajı, o PHP çalışmasının izin verilen bellek sınırına ulaştığını söyler. Bu değer, hosting paketinizin toplam RAM'iyle aynı değildir. memory_limit artırmak sunucuya fiziksel bellek eklemez.
Önce şu soruları yanıtlayın:
- Hata hangi işlemde çıktı: büyük dosya işleme, rapor hazırlama, veri içe aktarma veya normal sayfa açılışı mı?
- Son değişiklik gereğinden fazla veriyi tek seferde belleğe alıyor ya da aynı işlemi sürekli tekrarlıyor olabilir mi?
- Uygulamanın bu PHP isteğinde kullandığı gerçek sınır nedir? Önceden çalışan ayar yanlışlıkla düşürülmüş mü?
- Uygulamanın belgelenmiş ihtiyacı ve hosting hizmetinin izin verdiği sınır nedir?
Örnek: bellek sınırını değiştirmeden büyük ayırmayı kaldırma
Bu çalışma için hazırlanan ayrı PHP isteğinde memory_limit değeri 16M olarak belirlendi ve tek seferde 32 MiB veri ayıran işlem denendi. İstek HTTP 500 verdi. Bu sınır yalnız deneme isteğine aitti; alan adının PHP-FPM veya genel INI ayarları değiştirilmedi.
Etkin PHP günlüğü, app.php dosyasının 3. satırı için şu hatayı kaydetti:
Allowed memory size of 16777216 bytes exhausted (tried to allocate 33554464 bytes)
Son kayıtlar, app.php dosyasının üçüncü satırında PHP bellek sınırının aşıldığını gösteriyor.
1. adım: İzin verilen 16 MiB sınırını bulun
- İzin verilen 16 MiB sınırını bulun
Allowed memory size of 16777216 bölümü izin verilen 16 MiB sınırını gösteriyor. Satırdaki exhausted ifadesi bu sınırın aşıldığını bildiriyor; deneme saatine ait kaydı esas alın.
- Ayırma isteğini sınırla karşılaştırın
tried to allocate 33554464 bytes bölümü, yaklaşık 32 MiB ek ayırma denemesini gösteriyor. Bu isteği 16 MiB sınırıyla karşılaştırarak hangi kodun büyük veriyi belleğe almaya çalıştığını araştırın.
Bu hata fiziksel sunucu belleğinin tamamen bittiğini tek başına göstermez. PHP sınırını ve uygulamanın bellek kullanımını birlikte inceleyin.
16777216 bayt 16 MiB sınırıdır. Ayrılmak istenen 32 MiB veriye PHP’nin bellek ayırma ek yükü de eklendiği için günlükteki deneme 33554464 bayt görünür; veri boyutu ise 33554432 bayttır.
Dosya File Manager → Copy ile yedeklendi. Ardından Edit ekranında büyük ayırma kaldırıldı: kod artık tek bir 256 KiB (256 × 1024 bayt) metin oluşturup uzunluğunu 128 kez topluyor. Aynı küçük metin bellekte tutuluyor. memory_limit değeri 16M olarak kaldı; PHP-FPM veya genel INI ayarı değiştirilmedi. Save Changes ile kaydedildi.
Örnekte bellek sınırı 16M olarak korunuyor; tek büyük ayırma yerine küçük bir parça kullanılıyor.
1. adım: 256 KiB dize ayırmasını kontrol edin
- 256 KiB dize ayırmasını kontrol edin
Üçüncü satırda 256 KiB dize oluşturuluyor. Döngü aynı dizenin strlen sonucunu 128 kez toplayıp 33554432 sayacını hesaplıyor; ayrı 32 MiB verinin işlendiğini veya içe aktarıldığını göstermiyor.
- Save Changes ile değişikliği kaydedin
Save Changes düğmesine basın. Aynı adresi tekrar açarak beklenen sonucu ve yeni hata kaydı oluşup oluşmadığını kontrol edin; gerçek işlemin ürettiği veriyi de doğrulayın.
Bu, bellek kullanımını azaltmayı anlatan kontrollü bir örnektir. Her uygulama aynı kodla düzeltilemez; bellek sınırı yükseltmek otomatik çözüm değildir.
Aynı adres normal tarayıcıda yeniden açıldığında HTTP 200 döndü ve şu çıktı görüldü:
İşlem tamamlandı: 33554432 bayt
Bellek sınırı: 16M
Örnek çıktı, döngünün hesapladığı sayacı ve işlem için geçerli 16M değerini birlikte gösteriyor.
1. adım: Çıktının anlamını iki satırla kontrol edin
- Çıktının anlamını iki satırla kontrol edin
Ekrandaki İşlem tamamlandı: 33554432 bayt satırı, aynı dizenin uzunluğunun tekrar tekrar toplanmasıyla hesaplanan sayaçtır. Bellek sınırı: 16M satırı korunan sınırı gösterir. Bu örnek ayrı 32 MiB verinin işlendiğini kanıtlamaz.
Sayısal HTTP kodu bu görselde görünmez. Network ekranındaki yanıtı ve son denemeden sonra yeni hata kaydı oluşmadığını ayrıca kontrol edin.
Çıktıdaki 33554432, aynı metnin uzunluğunun 128 kez toplanmasıyla oluşan sayaçtır; dışarıdan alınmış 32 MiB farklı verinin işlendiğini göstermez. Bu küçük örnek, büyük bellek ayırması kaldırıldığında isteğin aynı 16M sınırında tamamlanabildiğini gösterir. Dosya içe aktarma, WordPress performansı veya mağaza kapasitesi ölçümü değildir. Kendi uygulamanızda parçalı işlemenin desteklendiğini ve üretilen sonucun doğru olduğunu ayrıca kontrol edin.
Önce gereksiz bellek tüketimini veya yanlışlıkla düşürülen ayarı düzeltin. Kaynak ihtiyacı doğrulanmışsa MultiPHP INI Editor içinde yalnız ilgili alan adının memory_limit değerini, hizmetin izin verdiği uygun değere getirin; önceki değeri kaydedin. Ardından aynı işlemi tekrar deneyip yeni günlük kaydını kontrol edin.
memory_limit = -1 ile sınırı kaldırmak veya büyük bir sayıyı denemek genel çözüm değildir. Aynı anda çalışan PHP istekleri ayrı ayrı bellek tüketir. Daha yüksek limit, diğer sitelerin veya veritabanının kaynak ihtiyacını ortadan kaldırmaz. Kaynak kullanımı rehberi ve destek ekibiyle gerçek ihtiyacı değerlendirin.
8. Düzeltmenin sonucunu aynı istekte doğrulayın
Beklenen sonuç: Daha önce 500 veren aynı sayfa doğru içeriği üretir; Network ekranında uygun başarı kodu görülür ve aynı hatanın yeni kaydı oluşmaz. Normal bir sayfa için bu genellikle 200 olur. Uygulamanın beklenen yönlendirmeleri varsa son ulaşılan sayfayı da kontrol edin.
- Düzeltmeden önceki adresi yeniden açın; yalnız ana sayfanın çalışmasına bakmayın.
- Tarayıcının eski hata kopyasını göstermediğini kontrol edin. CDN varsa yalnız ilgili sayfanın önbellek durumunu da değerlendirin.
- Sayfanın doğru içeriği gösterdiğini ve gereken uygulama işlevinin çalıştığını doğrulayın. Hata metnini
200koduyla döndürmek çözüm değildir. - Hata günlüğünü son denemenin saatine göre yeniden okuyun. Eski satırları “ekran temizlensin” diye silmeyin.
- Test için eklediğiniz teşhis dosyalarını ve geçici ayarları kaldırın; özel yedekleri güvenli yerde saklayın.
Üç ayrı denemenin sonucu
| Ayrı deneme | Önce | İlgili hata | Yapılan düzeltme | Aynı adresin sonucu |
|---|---|---|---|---|
.htaccess komutu | HTTP 500 | Invalid command 'InvalidDirectiveForGuide' | Yalnız eklenen geçersiz satır kaldırıldı; Save Changes sonrası Success! görüldü. | HTTP 200; beklenen sayfa açıldı. |
| PHP sözdizimi | HTTP 500 | unexpected token "echo" — 3. satır | 2. satırdaki atamanın sonuna ; eklendi; Save Changes sonrası Success! görüldü. | HTTP 200; “PHP örneği yeniden çalışıyor” metni görüntülendi. |
| PHP bellek kullanımı | HTTP 500 | 16777216 bytes exhausted | Aynı 256 KiB metnin uzunluğu 128 kez toplandı; 16M sınırı korundu. | HTTP 200; sayaç 33554432, bellek sınırı 16M. |
Bir düzeltme yeni sorun oluşturduysa kaydettiğiniz önceki duruma dönün ve destek isteyin. Bir dosyanın geri alınması, aynı anda yapılmış veritabanı değişikliklerini geri almaz. Daha geniş geri dönüş için yedek doğrulama rehberini kullanın.
Ne zaman destek talebi açmalısınız?
Hata birden fazla sitede aynı anda başladıysa, ilgili günlüğe erişemiyorsanız, dosya sahipliği sorunu görünüyorsa veya ayarlar sunucu düzeyinde kısıtlıysa destek talebi oluşturun.
Talebe şunları ekleyin:
- Hizmetiniz, sorunlu sayfanın adresi ve hata saati; mümkünse saat dilimi.
- Görülen gerçek HTTP kodu ve sorunun hangi işlemde oluştuğu.
- Son değişiklik ve geri aldığınız adım.
- İlgili birkaç günlük satırı; dosya ve hata kısmı anlaşılır kalacak şekilde özel bilgileri gizleyin.
Parola, oturum bağlantısı, veritabanı ayar dosyası veya tüm yedek arşivini mesaja koymayın. Günlükte erişim anahtarı veya kullanıcı verisi varsa paylaşmadan önce çıkarın.
Sık sorulan sorular
500 hatası hosting paketimin yetersiz olduğu anlamına mı gelir?
Tek başına gelmez. Bir .htaccess yazım hatası veya PHP sözdizimi hatası, boş bir sunucuda da 500 oluşturabilir. Paket yükseltmeden önce günlükteki nedeni belirleyin. Kaynak sınırı gerçekten aşılıyorsa uygulama tüketimini ve hizmet kapasitesini birlikte değerlendirin.
.htaccess dosyasını silersem sorun çözülür mü?
Hatalı kural devre dışı kalabilir, fakat doğru çalışan yönlendirme ve erişim korumaları da kaybolabilir. Önce dosyanın kopyasını alın; günlükte belirtilen ve son değiştirdiğiniz satırı düzeltin. Tüm dosyayı silmeyi ilk adım olarak kullanmayın.
cPanel Errors boş ama site 500 veriyor; neden?
PHP-FPM veya uygulama başka bir günlüğe yazıyor olabilir. Doğru alan adını, hata saatini ve etkin PHP hata günlüğünü kontrol edin. Errors ekranının boş olması, uygulamanın hatasız çalıştığını göstermez.
PHP bellek limitini artırdım ama hata değişmedi; ne yapmalıyım?
Önce hata hâlâ Allowed memory size mı, yoksa başka bir hata mı kontrol edin. Seçtiğiniz alan adını ve isteğin etkin ayarını doğrulayın. FPM kısıtları veya ayarın okunma zamanı etkili olabilir; .htaccess ya da kod sözdizimi hatası bellek artırılarak düzelmez.
İlgili rehberler
- Hosting yönetimi ve cPanel'e giriş
- cPanel dosya yönetimi ve yedek
- PHP sürümü, PHP-FPM ve performans ayarları
- Veritabanı bağlantısı ve cron günlükleri
- SSL ve HTTPS sorunları
- Destek talebi hazırlama
Resmî kaynaklar
Kaynaklar 15 Ekim 2026'da kontrol edildi. Menülerin görünümü ve hesabınıza sunulan ayarlar sürüme ve hizmet kapsamına göre değişebilir.