VPS Nedir? Paylaşımlı Hostingden Ne Zaman Geçmelisiniz?

Barındırmanın dar geldiğini çoğu zaman bir sorun yaşayınca anlıyorsunuz: Sayfalar yoğun saatte geç açılıyor, kurmak istediğiniz bir yazılım için izin çıkmıyor ya da hatanın kaynağını görebileceğiniz ayarlara erişemiyorsunuz. O noktada sorulan soru hep aynı: Paylaşımlı hostingden VPS sunucuya geçmeli miyim? Barındırmanın temel tanımını hosting sözlük maddesinde verdim. Bu yazı bir adım ilerisini anlatıyor.

16 Eylül 2026'da kendi sitemi, internetdedektifi.com'u, yeni bir sunucuya taşıdım. Yazının bir bölümünde o taşımada ölçtüklerimi ve yaptığım hatayı paylaşıyorum. Geri kalanı, sanal sunucuya geçmeyi düşünen herkes için: farklar, geçiş işaretleri, seçim ölçütleri ve taşıma sırası.

Sanal sunucu nedir, VPS'te kaynaklar nasıl bölünür?

Sanal sunucu, fiziksel bir makinenin üzerinde yazılımla oluşturulan ve kendi işletim sistemiyle bağımsız bir bilgisayar gibi çalışan ortam. Bölmeyi hipervizör denen yazılım yapıyor. AWS'in tanımıyla hipervizör, tek bir fiziksel makinede birden fazla sanal makine çalıştırmayı sağlıyor ve işlemci, bellek gibi kaynakları bu makinelere dağıtıyor.

VPS (virtual private server, sanal özel sunucu) bu sanal makinelerden biri. IBM'in anlatımıyla VPS'ler aynı hipervizörü ve donanımı paylaşsa da her biri kendi işletim sistemini ve kendi uygulamalarını çalıştırıyor. AWS ise VPS'in fiziksel sunucunun yalnız bir kısmını kullandığını, o donanımdaki payınızın size ayrıldığını vurguluyor.

Burada sağlayıcı seçerken işinize yarayacak bir ayrım var. DigitalOcean'ın plan belgesi bunu açıkça yazıyor:

• Bellek, disk ve ağ bant genişliği her planda size ayrılmış.
• Paylaşımlı işlemcili planda size verilen iş parçacığı başka sanal sunucularla paylaşılabiliyor. Yük arttığında hipervizör daha fazlasını veriyor ama tam iş parçacığı garanti değil.
• Ayrılmış işlemcili planda tam iş parçacığına her an erişim garanti.

Yani "VPS" etiketi tek başına işlemcinin size ait olduğunu söylemiyor. Teklifte paylaşımlı vCPU mu, ayrılmış vCPU mu yazdığına bakın.

Paylaşımlı hosting ile VPS arasında ne fark var?

Kısa cevap: kontrol ve kaynak güvencesi. AWS'e göre paylaşımlı hostingde bütün siteler aynı fiziksel sunucuyu kullanıyor ve bellek, disk, işlemci gücü için birbiriyle yarışıyor. IBM bu durumu "gürültülü komşu" diye anlatıyor: Bir kiracının uygulaması payından fazlasını tüketince diğerlerinin performansı düşüyor.

Konu	Paylaşımlı hosting	VPS	Fiziksel (dedicated) sunucu
Donanım	Herkesle ortak	Ortak donanım, size ayrılmış sanal pay	Tamamı sizin
İşletim sistemi	Barındırıcının	Her VPS'in kendi işletim sistemi	Sizin
Yönetici (root) erişimi	Genellikle yok	Plana göre tam root	Var
Büyüme	Paketin sınırında kalıyor	Üç modelin en esneği	Yeni donanım kurulmasını gerektiriyor
Maliyet	En düşük	İkisinin arasında	En yüksek

Tablodaki büyüme ve maliyet satırları IBM'in karşılaştırmasından. Root erişimi, sunucudaki en üst yönetici yetkisi; IBM'e göre VPS'te bu yetkinin size verilip verilmediği sağlayıcıya ve plana bağlı.

Paylaşımlı hosting kötü bir seçim değil. IBM de onu az trafikli, teknik ihtiyacı düşük siteler için ideal sayıyor. Ayda birkaç kez güncellenen bir tanıtım sitesi için VPS çoğu zaman gereksiz bir yük.

VDS nedir, VPS'ten farkı ne?

VDS (virtual dedicated server, sanal ayrılmış sunucu) için herkesin kabul ettiği bir tanım yok. Okuduğum AWS, IBM ve DigitalOcean sayfalarında bu terim hiç geçmiyor; daha çok barındırma firmalarının paket adlarında karşınıza çıkıyor.

Firmalar da onu farklı anlamlarda kullanıyor. Cherry Servers, karşılaştırma yazısında VDS'i ayrılmış işlemci ve bellekle çalışan sanal sunucu diye tanımlıyor; birçok firmanın VPS ile VDS'i birbirinin yerine geçen pazarlama terimleri olarak kullandığını da kendisi yazıyor. Cloud4Y ise farkı sanallaştırma katmanına bağlıyor: Ona göre VPS işletim sistemi düzeyinde, VDS donanım düzeyinde sanallaştırma.

Etikete değil, teklifteki üç satıra bakmanızı öneririm:

• vCPU paylaşımlı mı, ayrılmış mı?
• Bellek garanti mi, yoksa yoğunlukta kısılabilir mi?
• Sanallaştırma türü ne: tam sanal makine mi, kapsayıcı tabanlı mı?

Cloud sunucu nereye oturuyor?

"Cloud sunucu" adı da benzer bir bulanıklık taşıyor. IBM, VPS'i çoğu genel bulut sağlayıcısının sunduğu sanal makinelerin en yakın akrabası olarak tanımlıyor. Bulut sağlayıcısının sanal makinesi ile barındırma firmasının VPS'i aynı temelden geliyor; aralarındaki seçimi yine kaynak garantisi, yönetim düzeyi ve destek belirliyor.

Hangi işaretler VPS'e geçme zamanını gösterir?

Bir sitenin sunucusunu değiştirmek için "daha güçlü olsun" yeterli bir sebep değil. Benim baktığım işaretler şunlar:

• Sorunun kaynağını görmek için sunucu günlüklerine ya da güvenlik duvarına bakmanız gerekiyor, ama hesabınız buna izin vermiyor.
• Uygulamanız her dakika çalışan zamanlanmış görevler, sürekli açık bir arka plan işi ya da belirli bir PHP sürümü istiyor.
• Kendi kontrol panelinizi ya da sunucuya özel bir yazılımı kurmak istiyorsunuz. Bunun için çoğu zaman root yetkisi gerekiyor ve paylaşımlı hesaplar bu yetkiyi genellikle vermiyor.
• Ölçüm, yavaşlığın sayfadan değil sunucudan geldiğini gösteriyor. İlk bayt süresi (TTFB) burada en açık göstergelerden biri.
• Arama motorlarının ya da SEO araçlarının botları, sizin koymadığınız bir kuralla geri çevriliyor.

Bunların hiçbiri yoksa önce mevcut sitenin hızına bakın. Yavaşlık sunucudan da sayfanın kendisinden de gelebilir; Core Web Vitals ölçümleri hangisinden geldiğini ayırt etmenize yardım ediyor.

VPS seçerken nelere bakmalısınız?

Paket karşılaştırmasında çekirdek ve bellek rakamları öne çıkıyor. Oysa günlük hayatta sizi en çok etkileyecek karar, sunucunun bakımını kimin yapacağı.

Yönetimli mi, yönetimsiz mi?

AWS üç türü şöyle ayırıyor: Yönetimsiz VPS'te sunucunun bütün sorumluluğu ve bakımı sizde. Yönetimli VPS'te sağlayıcı güncellemeleri, bakımı ve yazılım kurulumunu üstleniyor. Yarı yönetimli planda temel hizmete ek olarak temel yazılım kurulumu ve destek geliyor. Güvenlik güncellemelerini düzenli yapacak birini gösteremiyorsanız yönetimsiz planı seçmeyin.

İşlemci paylaşımlı mı, ayrılmış mı?

DigitalOcean, paylaşımlı işlemcili planları çoğunlukla düşük ve orta yükte çalışan, ara sıra kısa süreli sıçrama yapan uygulamalar için uygun buluyor. Değişken performansa tahammülü olmayan üretim işleri için ise ayrılmış işlemciyi öneriyor. Sitenizin hangi gruba girdiğini, yoğun saatteki işlemci kullanımına bakarak anlayabilirsiniz.

İşletim sistemi ve panel hangisi olacak?

Panel, sunucuyu komut satırına girmeden yönetmenizi sağlıyor. Panel seçimini işletim sisteminden önce yapın, çünkü her panel yalnız belirli sistemleri ve sürümleri destekliyor. Kendi sitemde kullandığım paneli ve gereksinimlerini aşağıdaki taşıma bölümünde yazdım.

Konum, yedek ve destek nasıl?

Veri merkezinin ziyaretçilerinize uzaklığına, yedeğin kimde durduğuna ve bir sorun anında kime, hangi kanaldan ulaşacağınıza bakın. Sağlayıcının yedeği varsa yedekten geri yüklemeyi bir kez deneyin; denenmemiş yedeğe güvenmeyin.

Hosting fiyatlarında maliyeti ne belirler?

Burada rakam vermiyorum; paketler ve kur sık değişiyor, bugün yazdığım fiyat yarın yanıltıcı olur. Hosting fiyatlarını karşılaştırırken bunun yerine şu kalemleri yan yana koyun:

• İşlemci: çekirdek sayısı ve paylaşımlı mı, ayrılmış mı olduğu.
• Bellek ve disk: miktar ve disk türü.
• Trafik: aylık aktarım sınırı ya da bağlantı hızı.
• Yönetim: Yönetimli planda bakım işçiliği fiyatın içinde.
• Panel lisansı: Ticari bir panel ayrı lisans ücreti isteyebiliyor; açık kaynak panelde bu kalem yok.
• Ek hizmetler: yedekleme, ek IP adresi, destek seviyesi.

Ucuz bir yönetimsiz VPS, güncellemeleri yapacak kimse yoksa pahalıya patlayabilir. Maliyeti hesaplarken sunucunun bakımına ayıracağınız saati de yazın.

Kendi sitemi taşırken neler gördüm?

16 Eylül 2026'da internetdedektifi.com'u Plesk panelli eski barındırma hesabından HestiaCP panelli yeni bir sunucuya taşıdım. Yeni sunucuda nginx, PHP-FPM 8.5 ve MySQL 8.0 çalışıyor; eskisinde veritabanı MariaDB 10.6 idi.

HestiaCP, GPLv3 lisanslı, açık kaynak bir panel; belgesine göre Debian 12 ve 13 ile Ubuntu 22.04, 24.04 ve 26.04 sürümlerini destekliyor. Paneli kendiniz kuracaksanız aynı belge root yetkisi ve temiz kurulmuş bir işletim sistemi şart koşuyor. Aşağıda anlattıklarım sunucunun türünden bağımsız; her sunucu değişikliğinde karşınıza çıkabilir.

Taşımaya neden karar verdim?

15-16 Eylül 2026 ölçümlerimde, bir CDN ve vekil hizmeti olan Cloudflare üzerinden gelen isteklerin yüzde 15-35'i 522 hatası alıyordu. İlk ölçüm turunda, aynı saniyelerde doğrudan sunucuya giden istekler 58'de 58 başarılıydı. Cloudflare'in belgesine göre 522, kaynak sunucuya bağlanırken zaman aşımına uğrandığını gösteriyor; en sık sebep de barındırıcının Cloudflare IP aralıklarına izin vermemesi.

Benim durumumda istekler web sunucusunun günlüğüne hiç düşmüyordu. Yani bağlantı web sunucusuna ulaşmadan kesiliyordu. Eski hesapta sunucunun güvenlik duvarını göremiyor ve değiştiremiyordum; çözüm barındırıcının elindeydi. Yeni sunucuda Cloudflare vekilini henüz açmadım; 522'nin bittiğini bu yüzden ölçmüş değilim. Bu dönemde Search Console da bir sayfa için "Robots.txt erişilemiyor" hatası verdi. Bu tür satırları nasıl okuduğumu Search Console dizine ekleme raporu yazısında anlattım.

Bir bulgu daha vardı. 1 Eylül 2026 denetiminde eski sunucu YandexBot, AhrefsBot, SemrushBot, DotBot (Moz) ve MJ12bot (Majestic) için 406 yanıtı veriyordu; Googlebot ve Bingbot geçiyordu. Taşımadan sonra bu botların hepsi 200 aldı. Sunucunuzun YandexBot'a ne döndürdüğünü nasıl sınayacağınızı Yandex Webmaster yazımda adım adım yazdım.

Taşıma günü hangi hatayı yaptım?

DNS kaydını, dosyalar yeni sunucuya konmadan çevirdim. Site yaklaşık bir saat boyunca her adreste yeni panelin 404 sayfasını gösterdi. Ders net: önce dosya ve veritabanı, sonra test, en son DNS.

Yeni sunucuda neyi elle kurmam gerekti?

Yeni panelde alan adı Laravel şablonuyla açılmıştı ve web kökü public klasörüydü. Nginx .htaccess dosyasını okumadığı için eski dosyadaki kuralı, yani www'siz adresten www'li adrese 301 yönlendirmesini, koda taşımam gerekti. Zamanlanmış görevi (cron) de yeni sunucuda ayrıca kurdum; o kurulmadan sitenin zamanlanmış işleri hiç çalışmıyor.

Hız ne kadar değişti?

16 Eylül 2026'da 8 sayfayı 5 tur boyunca, eski ve yeni sunucuya doğrudan ve dönüşümlü istek atarak ölçtüm:

İlk bayt süresi (TTFB)	Eski sunucu	Yeni sunucu
Önbellekli sayfa, ortanca	474 ms	149 ms
Önbelleksiz sayfa (sayfayı PHP oluşturuyor), ortanca	724 ms	280 ms
En kötü değer	1.079 ms	386 ms

Bu farkı tek bir sebebe bağlamıyorum. Donanım, ağ, web sunucusu, veritabanı ve PHP sürümü aynı anda değişti; hangisinin ne kadar katkı sağladığını bu ölçüm ayırt etmiyor.

Taşıma sırasında erişim ve sıralama nasıl korunur?

Adresleriniz değişmese bile sunucu taşıması sitenin bir süre erişilemez kalmasına yol açabilir. Benim artık izlediğim sıra şu:

1. Taşımadan birkaç gün önce DNS kayıtlarının TTL değerini düşürün. Cloudflare'in belgesine göre TTL, kaydın ne kadar süre önbellekte tutulacağını ve dolayısıyla değişikliğin kullanıcılara ne kadar sürede ulaşacağını belirliyor.
2. Dosyaları ve veritabanını yeni sunucuya kopyalayın. Veritabanı motoru değişiyorsa (benim durumumda MariaDB'den MySQL'e) içe aktarmayı mutlaka deneyin.
3. Web kökünü doğru klasöre bağlayın. Laravel belgesi bütün isteklerin public/index.php dosyasına yönlenmesini istiyor ve proje kökünden yayın yapmanın hassas yapılandırma dosyalarını açığa çıkarabileceğini yazıyor.
4. 301 yönlendirmelerini taşıyın. Yeni sunucu nginx ise nginx'in belgesi, .htaccess kurallarının nginx yapılandırmasına nasıl çevrileceğini örneklerle gösteriyor.
5. Zamanlanmış görevleri kurun. Laravel'de tek bir cron kaydı yetiyor; zamanlayıcıyı her dakika çalıştırıyor.
6. SSL/TLS sertifikasını planlayın: Let's Encrypt kullanıyorsanız sertifika çoğu zaman DNS çevrildikten sonra alınabiliyor; kesintisiz geçiş için mevcut sertifikayı taşıyın ya da sertifikayı DNS doğrulamasıyla alın.
7. Siteyi DNS'i çevirmeden test edin: Bilgisayarınızın hosts dosyasına yeni IP adresini yazıp sayfaları gezin.
8. DNS'i çevirin ve ilk günlerde robots.txt, site haritası ve önemli sayfaların yanıt kodlarını izleyin.

Taşımayla birlikte adresler ya da tasarım da değişiyorsa iş büyüyor; o durumu web sitesi yenilerken sıralamayı korumak yazısında ayrıca anlattım. Sunucu tarafındaki kontrollerin geniş listesi için teknik SEO rehberime bakabilirsiniz. Sitenizi yeni bir sunucuya taşırken ya da baştan kurarken destek isterseniz web tasarım hizmetimize göz atın.

Sık Sorulan Sorular

VPS'e geçmek sitemi Google'da yükseltir mi?

Tek başına hayır. Daha hızlı ve kesintisiz bir sunucu, sayfaların taranmasını ve açılmasını kolaylaştırıyor; sıralamayı ise içerik ve sitenin geneli belirliyor. Benim sunucu taşımamda ilk bayt süresi düştü, ama bunu bir sıralama vaadi olarak okumuyorum.

Teknik bilgim yoksa yönetimsiz VPS kullanabilir miyim?

Önermiyorum. AWS de yönetimsiz VPS'in teknik uzmanlık ya da şirket içinde bu işe ayrılmış kaynak gerektirdiğini yazıyor. Güncellemeleri ve yedeği yapacak biri yoksa yönetimli plan daha güvenli.

522 hatası alıyorsam sorun Cloudflare'de mi?

Çoğu zaman sorun kaynak sunucu tarafında. Cloudflare'in belgesi 522'nin en sık sebebi olarak barındırıcının Cloudflare IP aralıklarını engellemesini gösteriyor. Barındırıcınızdan bu aralıklara izin verildiğini yazılı olarak teyit etmesini isteyin.

Sunucu değiştirirken site kapanır mı?

Sırayı doğru kurarsanız kesinti çok kısa kalabiliyor. Benim yaklaşık bir saatlik kesintim sunucudan değil, DNS'i dosyalardan önce çevirmemden geldi. Yeni sunucuyu hosts dosyasıyla test etmeden DNS'e dokunmayın.

Faydalı Kaynaklar

• AWS: VPS nedir, yönetimli ve yönetimsiz VPS
• IBM: Paylaşımlı, VPS ve fiziksel sunucu karşılaştırması
• DigitalOcean: Paylaşımlı ve ayrılmış işlemci farkı
• Cloudflare: 522 hatası ve sebepleri
• Cloudflare: DNS kayıtlarında TTL