WordPress’te “Takip Ettiğiniz Bağlantının Süresi Doldu” Hatası Nasıl Düzeltilir

WordPress’teki "Takip ettiğiniz bağlantının süresi doldu" hatası, bir dosya yükleme veya form gönderimi bir veya daha fazla PHP çalışma zamanı sınırını aştığında tetiklenir — özellikle upload_max_filesize, post_max_size, max_execution_time veya memory_limit. WordPress bu sunucu tarafı redlerinden düzgün bir şekilde kurtulamaz, bu nedenle belirli bir PHP hatası yerine bu genel mesajı gösterir.

Düzeltme, barındırma ortamınızın sunduğu yapılandırma katmanı aracılığıyla bu PHP direktif değerlerinin yükseltilmesini gerektirir: php.ini, .htaccess, wp-config.php veya bir kontrol paneli arayüzü. Hangi yöntemin işe yarayacağı tamamen sunucu erişim düzeyinize bağlıdır — root SSH erişimi, yönetilen cPanel veya kısıtlı paylaşımlı ortamların her biri farklı bir yaklaşım gerektirir.

Bu Hata Neden Gerçekten Oluşur

Temel nedeni anlamak, yanlış düzeltmeyi uygulamanızı önler. WordPress bir yüklemeyi işlediğinde, tarayıcı wp-admin/async-upload.php veya wp-admin/update.php‘a çok parçalı bir POST isteği gönderir. PHP, WordPress tek bir satır uygulama kodu çalıştırmadan önce isteği dört bağımsız sınıra göre değerlendirir:

• upload_max_filesize — tek bir yüklenen dosya için sabit tavan
• post_max_size — upload_max_filesize‘dan *daha büyük* olması gereken tüm POST gövdesi için tavan
• max_execution_time — bir PHP işleminin çalışabileceği maksimum gerçek zamanlı saniye
• memory_limit — PHP işlemine tahsis edilen RAM; görüntü işleme ve tema kurulumu bellek yoğundur

Bunlardan herhangi biri aşılırsa, PHP isteği sessizce sonlandırır. WordPress boş veya hatalı biçimlendirilmiş bir yanıt alır ve "Takip ettiğiniz bağlantının süresi doldu" mesajını görüntüler. Hata bir WordPress hatası değildir — PHP’nin sunucu politikasını uygulamasıdır.

Pratikte yaygın tetikleyiciler:

• 2 MB varsayılan yükleme sınırına sahip paylaşımlı bir sunucuda premium tema (genellikle 5–30 MB) kurulumu
• WooCommerce ürün CSV içe aktarma dosyası yükleme
• Paketlenmiş varlıklar içeren bir eklenti paketi kurulumu
• WordPress kontrol paneli aracılığıyla bir yedek arşivinden site geri yükleme
• Çalışma süresi tavanına ulaşan uzun süreli bir içe aktarma betiği çalıştırma

PHP Direktifi Hızlı Başvuru Tablosu

Kritik kural: post_max_size her zaman upload_max_filesize‘dan daha yüksek ayarlanmalıdır. upload_max_filesize = 128M ayarlayıp post_max_size = 8M‘ı olduğu gibi bırakırsanız, POST gövde sınırına önce ulaşıldığı için yüklemeler yine başarısız olur.

Yöntem 1: php.ini Düzenleme (VPS ve Dedicated Sunucular için Önerilir)

Bu en güvenilir ve kalıcı yöntemdir. Root veya sudo erişimine sahip olduğunuz bir VPS Hosting veya Dedicated Sunucu ortamında PHP yapılandırmasını doğrudan kontrol edersiniz.

Aktif php.ini dosyasını bulun:

php --ini | grep "Loaded Configuration File"

Veya bir WordPress sitesi içinden geçici bir dosya oluşturun:

<?php phpinfo(); ?>

Çıktıdaki Loaded Configuration File satırını arayın, ardından dosyayı hemen silin.

Direktifleri düzenleyin:

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Kaydettikten sonra değişiklikleri uygulamak için PHP-FPM veya Apache’yi yeniden başlatın:

# For PHP-FPM (most common on modern stacks)
sudo systemctl restart php8.2-fpm

# For Apache with mod_php
sudo systemctl restart apache2

# For Nginx + PHP-FPM
sudo systemctl restart nginx php8.2-fpm

Yeni değerlerin geçerli olduğunu doğrulayın:

php -r "echo ini_get('upload_max_filesize');"

Bilinmesi gereken uç durum: Birden fazla PHP sürümü çalıştıran sunucularda (cPanel’de yaygın bir kurulum), her sürüm için ayrı bir php.ini bulunur. Yanlış olanı düzenlemek hiçbir etkiye sahip olmaz. Düzenlemeden önce WordPress’in hangi PHP sürümünü kullandığını doğrulayın.

Yöntem 2: .htaccess Kullanma (Apache Paylaşımlı Hosting)

Doğrudan php.ini erişimi olmayan paylaşımlı hostingdeyseniz ve sunucunuz mod_php veya suPHP ile Apache çalıştırıyorsa, .htaccess kullanarak PHP direktiflerini dizin bazında geçersiz kılabilirsiniz.

WordPress kök dizininize FTP, SFTP veya hosting dosya yöneticiniz aracılığıyla erişin. .htaccess‘ı açın ve aşağıdaki bloğu ekleyin:

<IfModule mod_php.c>
    php_value upload_max_filesize 128M
    php_value post_max_size 256M
    php_value max_execution_time 300
    php_value max_input_time 300
    php_value memory_limit 256M
</IfModule>

Dosyayı kaydedin ve yükleyin, ardından yüklemenizi test edin.

Önemli uyarılar:

• Bu yöntem PHP-FPM, CGI veya FastCGI çalıştıran sunucularda çalışmaz. Bu yığınlarda, .htaccess‘daki php_value direktifleri 500 Internal Server Error‘a neden olur çünkü PHP’yi işleyen Apache modülü mod_php değildir. Kaydettikten sonra 500 hatası görürseniz, bu satırları hemen kaldırın.
• Nginx sunucularında .htaccess tamamen yok sayılır. Bunun yerine php.ini veya bir php.ini kullanıcı geçersiz kılma dosyası kullanın.
• Bazı yönetilen hostlar PHP direktifleri için AllowOverride‘ı açıkça devre dışı bırakır, bu da yöntemi Apache’de bile etkisiz kılar.

Yöntem 3: wp-config.php‘a Direktif Ekleme

Bu yöntem, direktifleri çalışma zamanında geçersiz kılmak için PHP’nin ini_set() işlevini kullanır. Web sunucusu türünden bağımsız olarak çalışır, ancak hostun open_basedir ve disable_functions kısıtlamalarına tabidir — bazı hostlar güvenlik nedeniyle ini_set()‘ı engeller.

WordPress kökünüzdeki wp-config.php‘ı açın ve aşağıdaki satırları /* That's all, stop editing! Happy publishing. */ yorumundan önce ekleyin:

@ini_set( 'upload_max_size',    '128M' );
@ini_set( 'post_max_size',      '256M' );
@ini_set( 'max_execution_time', '300'  );
@ini_set( 'max_input_time',     '300'  );
@ini_set( 'memory_limit',       '256M' );

@, ini_set() devre dışıysa beyaz ekranı önleyerek hataları bastırır. Ancak host bu değerleri php_admin_value kullanarak sunucu düzeyinde kilitlediyse, ini_set() çağrıları sessizce yok sayılır — değerler değişmez.

Gerçekten işe yarayıp yaramadığını doğrulama:

Ücretsiz Query Monitor eklentisini kurun ve PHP ortamı sekmesini kontrol edin ya da geçici bir phpinfo() çağrısı ekleyin. Değerler hâlâ eski sınırları gösteriyorsa, ini_set() daha yüksek bir düzeyde geçersiz kılınıyor demektir ve farklı bir yöntem kullanmanız gerekir.

Yöntem 4: cPanel’de PHP Ayarlarını Düzenleme

cPanel aracılığıyla yönetilen hosting ortamları için — cPanel ile VPS dahil — herhangi bir dosyaya dokunmadan grafik arayüz üzerinden PHP sınırlarını değiştirebilirsiniz.

Adımlar:

1. cPanel’e giriş yapın.
2. Software bölümüne gidin ve MultiPHP INI Editor‘a tıklayın.
3. Açılır menüden WordPress sitenizin belge kökünü seçin.
4. Aşağıdaki alanları bulun ve güncelleyin:

• upload_max_filesize → 128M
• post_max_size → 256M
• max_execution_time → 300
• memory_limit → 256M

1. Apply‘a tıklayın.

Alternatif olarak, hostunuz CloudLinux kullanıyorsa Select PHP Version (PHP Selector) seçeneğini kullanın. Options sekmesinde aynı direktifler kaydırıcılar veya giriş alanları olarak mevcuttur.

cPanel’in arka planda gerçekte ne yaptığı: Belge kökünüze bir .user.ini dosyası yazar (PHP-FPM için) veya .htaccess‘ı değiştirir (mod_php için). Bu dosyaları daha sonra manuel olarak düzenlerseniz, cPanel’in değişikliklerinin üzerine yazabilirsiniz — bu çakışmaya dikkat edin.

Yöntem 5: .user.ini Dosyası Oluşturma veya Düzenleme (PHP-FPM Ortamları)

Bu, çoğu öğreticinin atladığı yöntemdir, ancak PHP-FPM için doğru yaklaşımdır — Nginx tabanlı ortamlar dahil neredeyse her modern hosting yığınında varsayılan PHP işleyicisidir.

WordPress kök dizininizde aşağıdaki içerikle .user.ini adlı bir dosya oluşturun:

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

wp-config.php ile aynı dizine yükleyin. PHP-FPM, .user.ini dosyalarını periyodik olarak tarar — önbellek TTL’si varsayılan olarak 300 saniye (5 dakika) olan user_ini.cache_ttl tarafından kontrol edilir. Değişiklikler anlık değildir. Anında etki istiyorsanız PHP-FPM’yi yeniden başlatın.

sudo systemctl restart php8.2-fpm

Güvenlik notu: .user.ini dosyası web’den erişilebilir olmamalıdır. Apache kullanıyorsanız bunu .htaccess‘a ekleyin:

<Files ".user.ini">
    Require all denied
</Files>

Nginx’te erişimi engellemek için bir location bloğu ekleyin:

location ~ /.user.ini {
    deny all;
}

Yöntem 6: Hosting Sağlayıcınızla İletişime Geçin

Yukarıdaki yöntemlerin hiçbiri phpinfo() veya Query Monitor ile doğruladığınız PHP değerlerinde bir değişiklik sağlamıyorsa, host sınırları PHP-FPM havuz düzeyinde veya sunucu yapılandırmasındaki php_admin_value direktifleri aracılığıyla uyguluyordur — bunların ikisi de kullanıcı tarafından erişilebilen herhangi bir dosya tarafından geçersiz kılınamaz.

Bu durumda destekle iletişime geçin ve belirli artışlar talep edin. Tam direktif adlarını ve hedef değerleri belirtin. Host reddederse veya gereksinimlerinizi karşılamayan sabit bir tavan uygularsa, PHP yapılandırmasını tamamen kontrol ettiğiniz bir VPS Hosting planına geçmeyi düşünün.

Hangi Sınırın Hatayı Tetiklediğini Teşhis Etme

Tahmin etmek yerine, herhangi bir düzeltme uygulamadan önce şu teşhis adımlarını kullanın:

Komut satırından mevcut PHP sınırlarını kontrol edin:

php -r "echo 'upload_max_filesize: ' . ini_get('upload_max_filesize') . PHP_EOL;
echo 'post_max_size: ' . ini_get('post_max_size') . PHP_EOL;
echo 'max_execution_time: ' . ini_get('max_execution_time') . PHP_EOL;
echo 'memory_limit: ' . ini_get('memory_limit') . PHP_EOL;"

Gerçek hata için PHP hata günlüğünü kontrol edin:

tail -n 50 /var/log/php/error.log
# or
tail -n 50 /var/log/apache2/error.log

Allowed memory size, Maximum execution time veya POST Content-Length içeren satırları arayın. Belirli mesaj, tam olarak hangi direktifi hedeflemeniz gerektiğini söyler.

Yüklediğiniz dosyanın boyutunu mevcut upload_max_filesize ile karşılaştırın. Dosya 45 MB ve sınır 64 MB ise, yükleme sınırı sorun değildir — bunun yerine post_max_size veya memory_limit‘a bakın.

Doğru Yöntemi Seçme: Karar Matrisi

Bu Sorunu Çözülmüş Saymadan Önce Temel Teknik Kontrol Listesi

• post_max_size, upload_max_filesize‘dan daha yüksek ayarlanmıştır — bu en yaygın yanlış yapılandırmadır
• Değişiklikler phpinfo() veya php -r "echo ini_get(...)" ile doğrulanmıştır — yalnızca varsayılmamıştır
• .user.ini veya php.ini doğrudan düzenlendiyse PHP-FPM yeniden başlatılmıştır
• Düzenlenen .user.ini veya php.ini, WordPress sitesine gerçekten hizmet veren PHP sürümüyle eşleşmektedir
• Büyük temalar kuruyorsanız veya görüntü yoğun işlemler yapıyorsanız memory_limit en az 256M’dir
• Sonlandırmaya hangi belirli sınırın neden olduğunu doğrulamak için hata günlüğü kontrol edilmiştir
• Paylaşımlı Web Hosting planındaysanız, hostun sabit tavanı doğrulanmıştır — bazı sağlayıcılar kullanıcı ayarlarından bağımsız olarak upload_max_filesize‘ı 64M ile sınırlar
• Yükleme hatasını düzelttikten sonra, wp-admin’e HTTPS üzerinden erişiyorsanız SSL Sertifikalarınızın geçerli olduğunu doğrulayın; karışık içerik veya sertifika hataları yüzeysel olarak benzer yönlendirme hatalarına neden olabilir

SSS

.htaccess‘da upload_max_filesize‘ı artırdıktan sonra bile neden hata görünüyor?

Sunucu büyük olasılıkla PHP’yi mod_php yerine FastCGI veya PHP-FPM aracılığıyla çalıştırıyor. .htaccess‘daki php_value direktifi yalnızca Apache’nin mod_php işleyicisi tarafından işlenir. PHP-FPM yığınlarında, bunun yerine WordPress kök dizininde bir .user.ini dosyası kullanın.

upload_max_filesize ile post_max_size arasındaki fark nedir ve ikisi neden önemlidir?

upload_max_filesize, çok parçalı bir yüklemedeki her bir dosyanın boyutunu sınırlar. post_max_size, dosya verilerini ve form alanlarını ve sınırları içeren tüm POST istek gövdesinin toplam boyutunu sınırlar. post_max_size, upload_max_filesize‘dan küçükse, POST gövde sınırına önce ulaşılır ve PHP, WordPress dosya boyutunu değerlendiremeden tüm isteği atar.

wp-config.php‘daki ini_set() çağrılarım yok sayılıyor. Neden?

Host, PHP-FPM havuz yapılandırmasında veya Apache sanal sunucu bloğunda php_admin_value kullanıyor. php_admin_value, bir direktifi uygulama perspektifinden salt okunur olarak ayarlar — bu direktifler için ini_set() çağrıları sessizce atılır. Bu şekilde ayarlanan değerleri yalnızca hosting sağlayıcısı değiştirebilir.

PHP yapılandırma değişikliklerimin gerçekten geçerli olduğunu nasıl doğrularım?

WordPress kökünüzde <?php phpinfo(); ?> içeren geçici bir dosya oluşturun, tarayıcıda erişin ve direktif adını arayın. Local Value sütunu o dizin için geçerli değeri gösterir. Kontrol ettikten hemen sonra dosyayı silin — phpinfo() çıktısını kamuya açık bırakmak bir güvenlik riskidir.

Bu hata PHP yükleme sınırları dışında bir şeyden kaynaklanabilir mi?

Evet. Bir WordPress nonce süre sonu aynı mesajı üretebilir. WordPress nonce’ları varsayılan olarak 24 saat geçerlidir. Bir kullanıcı eklenti yükleme sayfasını açar, 24 saatten fazla boşta bırakır ve ardından formu gönderirse, nonce doğrulaması başarısız olur ve WordPress "Takip ettiğiniz bağlantının süresi doldu" mesajını görüntüler. Bu durumda, sayfayı yenilemek yeni bir nonce oluşturur ve yükleme normal şekilde devam eder — PHP yapılandırma değişikliğine gerek yoktur.