Hizmetler Hosting & Sunucu Araçlar Blog Ara Kurumsal EnglishEN
Teklif Alın

“IHS güvenilir mi?” sorusu, Türkiye'deki hosting forumlarının ve şikayet platformlarının en sık karşılaşılan başlıklarından biri. Cevabı tek kelimeyle “evet” ya da “hayır” diyerek vermek mümkün değil; çünkü güvenilirlik soyut bir sıfat değil, ölçülebilir bir özellikler kümesidir: uptime SLA, destek yanıt süresi, fatura şeffaflığı, panel erişimi, yedekleme ritmi, sözleşmesel tahkim hakları, transfer kolaylığı ve gerçek müşteri kayıtlarındaki örüntüler. Bu rehber, IHS Telekom (ihs.com.tr) özelinde söz konusu kriterleri tek tek inceleyip, vendor-neutral bir karar çerçevesi sunuyor.

İlgili rehberler: Hosting türleri ve seçim rehberi · VPS ve VDS farkı · Alan adı ve WHOIS sorgulama · DNS ayarları değiştirme · Let's Encrypt SSL kurulumu · cPanel ile site yönetimi

Yazıda kullandığımız tüm fiyat aralıkları, uptime rakamları ve destek metrikleri açık kaynaklı (resmi site, bağımsız inceleme siteleri, şikayet platformları, forum tartışmaları) verilerden 2026 başı itibariyla derlenmiştir. Yaklaşık değerlerdir, sağlayıcının kampanyasına ve paketine göre değişebilir. Karar verirken kendi senaryonuza (kurumsal site, e-ticaret, yüksek trafikli blog, geliştirici test ortamı) göre tartmak gerektiğini akılda tutun.

IHS Telekom Kimdir? Kuruluş, Yetkilendirmeler ve Müşteri Tabanı

IHS Telekom, 1999'dan beri faaliyet gösteren Türkiye merkezli bir alan adı tescil ve barındırma sağlayıcısıdır. Resmi sitesinde verdikleri bilgilere göre 100.000+ bireysel ve binlerce kurumsal müşteriye hizmet veriyorlar; data center lokasyonu olarak İstanbul'u öne çıkarıyorlar. Türkiye'deki sayılı akredite.tr alan adı tescil operatörlerinden biri olmaları, kurumsal pazardaki paylarının önemli bir kısmını domain tarafından kazanmalarını sağladı.

Kurumsal müşteri referansları arasında büyük perakende zincirleri, bankacılık altyapı çözüm sağlayıcıları, geleneksel medya kuruluşları ve kamu projeleri bulunuyor. Ölçek anlamında Türkiye'nin en büyük üç hosting firmasından biri olduğunu söylemek mümkün; ancak “büyük olmak”, “güvenilir olmak” ile aynı şey değildir. İncelememizin geri kalanı bu ikisini birbirinden ayırmaya odaklanıyor.

Hizmet Yelpazesi

  • Domain:.com,.net,.org,.com.tr,.tr,.biz.tr,.info,.co,.io,.xyz ve onlarca yeni TLD
  • Paylaşımlı hosting: Linux ve Windows; cPanel, Plesk veya kendi geliştirdikleri panellerde
  • WordPress hosting: LSCache + LiteSpeed entegrasyonlu paketler
  • VPS: KVM tabanlı, NVMe SSD diskli, aylık 3-25 USD aralığında konfigürasyonlar
  • VDS / dedicated server: Daha yüksek izolasyon ve garantili kaynak isteyen kurumsal müşteriler için
  • Reseller hosting: WHM altında alt kullanıcı satışı yapanlar için
  • SSL sertifikaları: RapidSSL, GeoTrust, DigiCert; ayrıca Let's Encrypt entegrasyonu
  • Kurumsal e-posta: SmarterMail veya MailEnable tabanlı çözümler

Bu yelpaze, “tek noktadan tüm web altyapısı” isteyen küçük ve orta ölçekli işletmelerin (KOBİ) ihtiyacını karşılayacak genişliktedir. Geniş yelpaze aynı zamanda hem güçlü yanıdır (tek bir fatura, tek bir panel) hem de zayıflığı (uzmanlaşma odağı dağılır).

“Güvenilirlik” Tanımı: Pazarlama Değil, Ölçülebilir Kriterler

Hosting bağlamında güvenilirlik, en az altı boyutta değerlendirilmesi gereken bileşik bir niteliktir. Bunları aklınızdan tutarsanız, herhangi bir sağlayıcıyı (sadece IHS'i değil) objektif ölçebilirsiniz.

  • Teknik güvenilirlik: Sözleşmedeki uptime SLA, gerçek ölçülen uptime, planlı/plansız bakım pencereleri, yedekleme ritmi, RTO/RPO değerleri
  • Operasyonel güvenilirlik: Destek yanıt süresi (ilk yanıt + çözüm), 7/24 erişilebilirlik, ticket eskalasyon yolu, dil desteği
  • Ticari güvenilirlik: Fatura şeffaflığı, otomatik yenileme politikası, iade koşulları, gizli ücretlerin yokluğu
  • Hukuki güvenilirlik: KVKK uyumu, veri saklama yargı yetkisi, sözleşmesel sorumluluk sınırları, tahkim ve mahkeme prosedürleri
  • Müşteri kontrolü: Tam panel erişimi, root SSH (VPS/VDS için), DNS yönetimi, e-posta yönetimi, transfer kolaylığı (esir alma yok)
  • İtibar / reputasyon: Şikayet platformlarındaki çözüm oranı, forumlardaki uzun vadeli kullanıcı yorumları, bağımsız inceleme siteleri

Bir sağlayıcı bu altı boyutun beşinde mükemmel ama altıncısında zayıfsa, tek bir kötü ay tüm itibarını silebilir. IHS özelinde her boyutu sırayla inceleyelim.

Boyut 1 — Teknik Güvenilirlik: Uptime, Bakım, Yedekleme

Bağımsız inceleme sitelerinin (websiteplanet, hostadvice gibi) ve kullanıcı paylaşımlarının ortalamasına göre IHS shared hosting paketlerinde haftalık %99.94 uptime seviyesi ölçülüyor. Bu rakam yıllığa çevrildiğinde yaklaşık 5 saat 16 dakikaya denk geliyor — kurumsal sözleşmelerde sıkça hedeflenen %99.95 (4.4 saat / yıl) eşiğinin biraz altında, ancak %99.9 (8.7 saat / yıl) eşiğinin üstünde. Bu, “çoğu zaman erişilebilir, ama yıl içinde birkaç fark edilebilir kesinti yaşanması beklenir” seviyesidir.

Şikayet platformlarındaki kayıtlar bu istatistiksel ortalamanın etrafında uç vakaları da gösteriyor: bazı kullanıcılar “günde yaklaşık 8 saat hizmet alamadık”, “sitelerimiz bir gündür açılmıyor”, “5 dakika up, 5 dakika down örüntüsü” gibi paternleri raporluyor. Bu tarz olaylar her büyük sağlayıcıda zaman zaman görülür; önemli olan şirketin bu olayları şeffaf raporlayıp raporlamadığı, post-mortem yayınlayıp yayınlamadığı ve müşterilere RFO (Reason For Outage) belgesi sunup sunmadığıdır.

Uptime'ı Bağımsız Olarak Nasıl Doğrularsınız?

Sağlayıcının size söylediği uptime'a güvenmek zorunda değilsiniz. Prometheus ve Grafana ile sunucu izleme rehberimizdeki tekniklere ek olarak, üçüncü taraf araçlarla bağımsız ölçüm yapın.

# Basit blackbox check — UptimeRobot, Pingdom, StatusCake, Better Stack
# Kendi makinenizden hızlı bir cron-uptime testi:
*/1 * * * * curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
 https://siteniz.com/ >> /var/log/uptime.log 2>&1

# Pratik bir 5-dakikalık availability raporu (son 24 saat)
awk 'BEGIN{ok=0;fail=0}
 $1=="200"{ok++}
 $1!="200"{fail++}
 END{printf "Uptime: %.4f%% (%d/%d)\n", ok/(ok+fail)*100, ok, ok+fail}' \
 /var/log/uptime.log

# DNS ve TCP düzeyinde de test edin (HTTP yanıt veriyor olabilir,
# ama TLS handshake veya DNS kırılmış olabilir):
dig +short A siteniz.com @1.1.1.1
openssl s_client -connect siteniz.com:443 -servername siteniz.com \
 -tls1_3 < /dev/null 2>&1 | grep -E 'subject|issuer|Verify return'

İdeal olarak en az iki bağımsız bölgeden (örneğin Frankfurt + İstanbul + ABD) ölçüm yapan bir uptime servisi kullanın; tek bölge ölçümü, ISP veya BGP rotalama sorunlarını sağlayıcının suçu gibi gösterebilir. DNS sorgulama aracımız ile kayıtların tutarlılığını çapraz doğrulayabilirsiniz.

Yedekleme Politikası

IHS shared hosting paketlerinde varsayılan olarak haftalık yedek alındığı, ancak bu yedeklerin sunucu üzerinde tutulduğu ve müşteriye self-service indirilebilir bir export sunulmadığı bildiriliyor. Bu önemli bir nokta: yedek varsa bile, fiziksel sunucu çökerse aynı diskte tutulan yedek de kaybolabilir. Profesyonel kullanım için off-site yedeklemeyi siz yapın: 3-2-1 yedekleme kuralı rehberimizde anlattığımız gibi en az iki farklı medyada, biri off-site olacak şekilde.

# cPanel hesabından otomatik off-site yedek (S3 uyumlu hedefe)
#!/usr/bin/env bash
set -euo pipefail

HOST="siteniz.com"
USER="cpaneluser"
DATE=$(date +%Y%m%d-%H%M)
LOCAL="/tmp/${USER}-${DATE}.tar.gz"
REMOTE="s3://my-backup-bucket/${HOST}/"

# 1) cPanel API ile full backup tetikle
curl -s -u "${USER}:${CPANEL_TOKEN}" \
 "https://${HOST}:2083/execute/Backup/fullbackup_to_homedir" -o /dev/null

# 2) FTP/SFTP ile yerele indir
sftp ${USER}@${HOST}:public_html/backup-*.tar.gz ${LOCAL}

# 3) S3'e yükle (Hetzner Object Storage, Backblaze B2, Cloudflare R2 hepsi uyumlu)
aws s3 cp "${LOCAL}" "${REMOTE}" --storage-class STANDARD_IA

# 4) Yerel kopyayı temizle
rm -f "${LOCAL}"

# 5) 90 günden eski uzak yedekleri sil (lifecycle policy ile de yapılabilir)
aws s3 ls "${REMOTE}" | awk '$1 < "'"$(date -d '90 days ago' +%Y-%m-%d)"'"{print $4}' \
 | xargs -I{} aws s3 rm "${REMOTE}{}"

Bu betiği nightly cron olarak çalıştırırsanız, sağlayıcınızdan bağımsız bir RTO 4 saat / RPO 24 saat seviyesini garanti altına alırsınız.

Boyut 2 — Operasyonel Güvenilirlik: Destek Yanıt Süresi

Müşteri desteği, hosting değerlendirmesinin en sübjektif ama bir o kadar belirleyici bileşenidir. IHS'in resmi açıklamalarına göre canlı destek hafta içi 09:00-18:00, cumartesi 11:00-15:00 saatleri arasında çalışıyor; e-ticket sistemi 7/24 açık ve ortalama yanıt süresi yaklaşık 30 dakika olarak vurgulanıyor. Bağımsız inceleme sitesi WebsitePlanet'in raporu ise canlı sohbette ~15 dakika, ticket'larda ~1 saat ortalama yanıt süresinden bahsediyor.

Şikayet platformlarındaki örüntü ise farklı bir tablo çiziyor: özellikle hafta sonları ve gece saatlerinde, kritik kesinti durumlarında ulaşılamamak en sık dile getirilen konulardan biri. Bu, mantıklı bir denge: bir sağlayıcının yıllık 50 USD'lik shared hosting paketi için 7/24 mühendis bulundurması ekonomik olarak imkansızdır. Mission-critical bir sistem işletiyorsanız (örneğin ödeme akışı, B2B API), shared hosting'in destek modeli zaten size göre değildir; managed VPS veya kurumsal sözleşmeli bir hosting tercih etmelisiniz.

Destek Kalitesini Test Etmenin Yolu

Yıllık ödeme yapmadan önce, 30 günlük iade hakkı varsa şu testleri yapın:

  • Hafta sonu 23:00'te bir non-critical ticket açın; ne kadar sürede yanıt geldiğine bakın
  • Bilinçli olarak çözümü olmayan, mantıksız bir teknik soru sorun (örn. “sunucumda Redis modülü etkinleştirin” shared'da imkansızsa); cevap edilen netliği ölçün
  • Yedek alma talebi gibi self-service yapılması gereken bir konuyu ticket'a açın; sizi self-service'e yönlendirip yönlendirmediklerini gözleyin
  • Phishing taklidi bir e-posta forwarding talep edin; güvenlik bilinçleri ne kadar yüksek?
  • Domain transfer kodu (auth code / EPP) talep edin; ne kadar sürede ve ne kadar sürtünmeyle veriliyor?

Bu testlerin sonucu size sağlayıcının operasyonel güvenilirliği hakkında 30 günlük bir kanıt verir. KEYDAL ekibi kendi audit servisinde bu protokolü her sağlayıcı için uygular.

Boyut 3 — Ticari Güvenilirlik: Fatura, Yenileme, İade

IHS resmi sitesinde 30 gün koşulsuz para iadesi ve yıllık paketlerde 2 ay bedava promosyonu açıkça duyuruluyor. Bu, sektör standardının iyi tarafında. Ancak şikayet platformlarındaki kayıtlarda dikkat çeken iki örüntü var:

  • Yenileme fiyat farkı: İlk yıl promosyon fiyatından alınıp ikinci yıl liste fiyatından otomatik yenilenmesi. Bu büyük tüm hosting firmalarında olağan ama Türkçe sözleşmelerde her zaman net belirtilmiyor
  • Domain otomatik tahsisi: Satın alımdan sonra panele yansımayan, manuel destek talebi gerektiren durumlar
  • Transfer ücretleri: Bazı TLD'lerde transfer ile yenileme arasındaki fiyat farkına dair şikayetler

Bu sorunların çözümü genellikle ticket'a yansıdığında çözülmüş olsa da, müşterinin proaktif takip etmesi gerekiyor demek. Kurumsal bir muhasebe sürecinde bu, ekstra kontrol kalemine dönüşür.

Otomatik Yenilemeyi Yönetmek İçin

  • Domain'inizin son kullanma tarihinden 30 gün önce takvim hatırlatıcısı kurun
  • Otomatik yenilemenin her ürün için ayrı ayarlandığını kontrol edin (hosting otomatik açıkken domain kapalı olabilir)
  • Yenileme öncesi paneldeki “teklif edilen fiyat”ı transfer fiyatlarıyla karşılaştırın
  • Faturanın PDF kopyasını arşivleyin; sonradan KDV iadesi vs. için gerekebilir
  • 30 gün önce yenilemezseniz ne olacağını sözleşmede arayın (grace period, redemption period)

WHOIS sorgulama aracımız ile domain'inizin son kullanma tarihini ve registrar'ını her zaman çapraz kontrol edebilirsiniz.

Boyut 4 — Hukuki Güvenilirlik: KVKK, Yargı Yetkisi, Sözleşme

Türkiye'de faaliyet gösteren bir hosting firması, müşteri verilerini Türkiye'de barındırıyorsa KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) uyumu zorunludur. IHS, sunucularını İstanbul'da tutmasıyla bu konuda öne çıkıyor; KVKK kapsamına giren sağlık, finans, kamu projeleri için bu kritik bir avantaj. OWASP Top 10 2026 rehberimizde uygulama katmanı güvenliğine; HTTPS ve TLS 1.3 rehberinde de aktarım katmanına dair detayları ele alıyoruz.

Hukuki olarak dikkat etmeniz gereken üç şey:

  • Veri saklama yargı yetkisi: Yedeklerin nerede tutulduğu (Türkiye, KKTC, AB, ABD) sözleşmede açık olmalı. KKTC üzerinden hizmet veren bazı firmaların KDV faturası kesmediği biliniyor
  • Sorumluluk sınırı: Çoğu hosting sözleşmesi tazminatı son 12 ay ücretiyle sınırlar. Yıllık 200 TL ödediğiniz bir paket için iş kaybınız 50.000 TL olsa bile geri alacağınız 200 TL'dir
  • Kabul edilebilir kullanım politikası: Spam mail, kripto madencilik, telif ihlali gibi durumlarda hesabın anında askıya alınma hakkı saklı tutulur. Müşterinin haberdar edilme süresi sözleşmede aranmalı

Yıllık 1.000 TL'nin üzerinde harcadığınız bir hosting paketi için özel sözleşme talep etmekte tereddüt etmeyin. Standart şartlar ortalama bir KOBİ için yeterlidir, ama yüksek riskli iş yükleri (finansal, sağlık, e-ticaret peak dönemleri) için müzakere etmeye değer.

Boyut 5 — Müşteri Kontrolü: Panel, SSH, Transfer

Bir hosting sağlayıcısının size verdiği kontrol seviyesi, “esir alınmama” seviyenizi belirler. IHS, paket türüne göre üç farklı kontrol seviyesi sunuyor:

  • En düşük (Nano gibi entry-level shared): Kendi geliştirdikleri panelde sınırlı arayüz, FTP yok ya da kısıtlı, veritabanı erişimi olmayabilir
  • Orta (cPanel/Plesk paylaşımlı): Standart cPanel/Plesk arayüzü, FTP/SFTP, MySQL, e-posta yönetimi, SSH genelde devre dışı
  • Üst (VPS/VDS): Tam root erişim, kendi OS seçiminiz, kendi panel kurulumu (cPanel/Plesk/Hestia/no-panel)

Mantıklı bir genel kural: cPanel veya Plesk olmayan paketten uzak durun. Çünkü bu paneller endüstri standardıdır; ileride başka bir sağlayıcıya geçtiğinizde aynı interface ve tek tıkla migration tools (örn. cPanel WHM Transfer Tool) sayesinde geçiş günlerce sürmek yerine bir akşamda biter. Sağlayıcıya özel paneller, geçişi cehenneme çevirir.

Transfer Hazırlığı: Bir Akşamda Çıkış Planı

Bir sağlayıcıyla yıllık sözleşme imzalamadan önce, oradan çıkış maliyetinizi tahmin edin. Şu betik, bir cPanel hesabınızı tam yedek + DNS export + e-posta export olarak başka bir sunucuya hazır hale getirir.

#!/usr/bin/env bash
# Hosting değişimi öncesi tam yedek senaryosu
set -euo pipefail

OLD="old-host.com"
NEW="new-host.com"
USER="siteuser"
WORK="/tmp/migrate-$(date +%s)"
mkdir -p "$WORK" && cd "$WORK"

# 1) Tam dosya seti (FTP/SFTP)
rsync -avz --progress \
 "${USER}@${OLD}:public_html/"./public_html/

# 2) Tüm MySQL veritabanları
mysqldump -h "$OLD" -u "$USER" -p \
 --single-transaction --quick --routines --triggers \
 --all-databases > all-dbs.sql

# 3) DNS zone'unu zone file olarak export
dig @"$OLD" siteniz.com AXFR > zone-export.txt 2>/dev/null || \
 echo "AXFR kapalı — panelden manuel export alın"

# 4) E-posta hesaplarını mbox formatında çek (IMAP üzerinden)
for mailbox in info admin satis; do
 imapsync --host1 "mail.${OLD}" --user1 "${mailbox}@siteniz.com" \
 --host2 "mail.${NEW}" --user2 "${mailbox}@siteniz.com" \
 --automap || true
done

# 5) Sıkıştır ve şifrele (uzak yedek için)
tar czf - public_html/ all-dbs.sql zone-export.txt | \
 gpg -c --cipher-algo AES256 -o "site-migrate-$(date +%Y%m%d).tar.gz.gpg"

echo "Migration package hazır: $WORK"
ls -lh "$WORK"

Bu betiği yıllık sözleşme imzalamadan önce dry-run olarak çalıştırın. Eğer sağlayıcınız mysqldump'a, rsync'e ya da imapsync'e izin vermiyorsa, esir alınma riskiniz yüksek demektir.

Domain Transfer Kodu (Auth Code / EPP) Almak

.com /.net /.org gibi gTLD'lerde 60 gün önce alıp registrar lock'ı açtırmanız yeterli..tr alan adlarında süreç biraz farklıdır; Domain ve WHOIS rehberinde detaylandırdık.

# IHS panelinden auth code çekme adımları (tipik akış)
1. https://panel.ihs.com.tr → Login
2. Domainlerim → ilgili domain → Yönet
3. "Transfer Kodu Al" / "EPP Code" butonu
4. Onay e-postası: 5-15 dakika içinde
5. Yeni registrar'a kodu gir + WHOIS e-postasından onayla

# Eğer butonu bulamazsanız:
→ Ticket aç: "Domain transfer kodu (EPP) talep ediyorum"
→ KVKK gereği kimlik doğrulama isteyebilirler
→ Yasal olarak 5 iş gününde vermek zorundadırlar (ICANN politikası)

Boyut 6 — Reputasyon: Şikayet Platformlarının Doğru Okunması

Şikayetvar, Ekşi Sözlük, Technopat, R10, Eksisi gibi platformlar kıymetli — ama hatalı okunduklarında yanıltıcı. Bir hosting firması ne kadar büyükse, mutlak şikayet sayısı da o kadar yüksektir; oran önemlidir. IHS özelinde:

  • Toplam ölçek: 100.000+ bireysel + binlerce kurumsal müşteri
  • Şikayetvar'da toplam şikayet: ~91 (tüm zaman, tüm kategoriler)
  • Hosting kategorisinde: ~38
  • Domain kategorisinde: ~19
  • Şikayet/müşteri oranı: kabaca binde bir altında
  • Ortalama puan: 7 değerlendirme üzerinden orta seviyede

Bu rakamlar, sağlayıcı için “felaket” göstergeleri değildir; sektör ortalamasının altında veya yakınındadır. Önemli olan tekrarlayan örüntülerdir:

  • Aynı şikayet birden fazla kullanıcıdan, aylar boyunca tekrarlanıyor mu?
  • Şirket ne kadar sürede ve ne tonda yanıt veriyor?
  • Çözüm gerçekten çözüm mü, yoksa boilerplate mi?
  • “Çözüldü” işaretli şikayetler gerçekten kapatılmış mı?

IHS özelinde tekrarlayan örüntüler şunlar: hafta sonu ve gece destek erişimi, ölü hesap şüphesi (otomatik aktivasyon yapılmaması), hosting + e-posta birlikte aşağı düşmesi, domain otomatik yenilemede fiyat sürprizleri. Bunlar “fatal flaws” değil, ama operasyonel zayıflık alanları.

Performans Karşılaştırması: IHS ve Sektör Benchmark'ı

WebsitePlanet'in 2026 ölçümlerine göre IHS shared hosting ortalama sayfa yükleme süresi 1.7 saniye, PageSpeed skoru 67. Bu rakamlar Türkiye lokasyonu için makul; ancak küresel CDN olmadan AB veya ABD ziyaretçileri için %30-50 daha yavaştır. Core Web Vitals 2026 hedefleriniz LCP < 2.5s ise, basit bir Cloudflare entegrasyonu zorunludur.

Aşağıdaki tablo Türkiye'deki lider yerel sağlayıcıların kabaca konumlandırmasını gösteriyor (vendor-neutral, sırasız):

  • IHS Telekom: 1999'dan beri, geniş ürün yelpazesi,.tr akredite, İstanbul DC, orta-üst fiyat
  • Natro: Eski oyuncu, KOBİ pazarına hakim, cPanel/Plesk standardı
  • Turhost (Doruk Net): Kurumsal odaklı, premium fiyatlandırma, görece daha sıkı SLA
  • Hostinger Türkiye: Düşük fiyat, hPanel (kendi paneli), küresel altyapı
  • İsimTescil: Domain ağırlıklı, hosting ikincil
  • Veriteknik / Radore / Sayfa.com.tr: Niş kurumsal segment
  • Yurtdışı opsiyonu: Hetzner, OVH, DigitalOcean, Linode, Contabo — yöneticilik gerektirir

Hangisi “en iyi”dir sorusunun cevabı kullanım senaryonuza bağlıdır. KVKK uyumu kritikse Türkiye konumlu, geliştirici esnekliği kritikse yurtdışı VPS, fiyat duyarlıysanız küresel low-cost player'lar mantıklıdır.

IHS'in Güçlü Yanları

  • .tr akreditasyonu:.com.tr,.org.tr,.gov.tr gibi domainlerde direkt registrar erişimi (ara katman olmadan)
  • Türkiye lokasyonu: KVKK uyumu, düşük yerli ping (~5-15ms)
  • Yerleşik ölçek: 25 yıllık operasyon, finansal sürdürülebilirlik (sağlayıcı kapanma riski düşük)
  • Geniş ürün yelpazesi: domain'den dedicated server'a tek faturada
  • Türkçe dokümantasyon ve destek: Yerel müşteri için iletişim engeli minimum
  • Promosyonel giriş fiyatı: Yıllık paketlerde 2 ay bedava + uygun başlangıç
  • Para iade garantisi: 30 gün koşulsuz
  • SSL sertifikaları: Hem ücretli (RapidSSL/GeoTrust/DigiCert) hem ücretsiz (Let's Encrypt) entegrasyonu

IHS'in Zayıf / Tartışmalı Yanları

  • Hafta sonu / gece destek: Mission-critical sistemler için yetersiz
  • Entry-level paketlerde panel kısıtlaması: cPanel/Plesk olmaması taşınabilirliği zorlaştırır
  • Yedekleme self-service değil: Off-site yedekleme müşterinin sorumluluğunda
  • Otomatik yenileme fiyat farkı: İkinci yıl liste fiyatına geçiş şikayet konusu
  • İlk aktivasyon takılmaları: Bazı kullanıcılar manuel müdahale gerektiren teslim sorunları yaşıyor
  • Küresel CDN yok: Yurtdışı ziyaretçi için ek katman (Cloudflare vb.) lazım
  • “Sınırsız” paketlerde gizli limitler: 200.000 dosya limiti gibi inode kısıtlamaları
  • Bazı paketlerde SSH erişimi kapalı: Geliştirici için kısıtlayıcı

Karar Matrisi: Hangi Senaryoya IHS Uygun, Hangisine Değil?

Aşağıdaki senaryolar için IHS makul bir seçimdir:

  • KVKK uyumu zorunlu, Türkiye lokasyonu istenen küçük-orta ölçekli kurumsal site
  • Yerel ziyaretçinin ağırlıklı olduğu blog veya kurumsal tanıtım sitesi
  • .tr alan adı tescili gereken projeler
  • Yıllık trafik 100K-500K visitor aralığında olan WordPress siteleri
  • Dedicated/VDS gereksinimi olan, fiziksel sunucuyu Türkiye'de istemek zorunda olan müşteriler

Aşağıdaki senaryolarda başka seçenekleri değerlendirin:

  • 7/24 mission-critical iş yükleri (ödeme akışı, B2B API, SaaS uptime contract'lı)
  • Yüksek geliştirici esnekliği gerektiren modern stack (Docker, Kubernetes, custom runtime)
  • Aylık 1M+ visitor traffic, küresel CDN gerektiren e-ticaret
  • Aşırı düşük bütçeli kişisel projeler (yurtdışı low-cost VPS daha mantıklı olabilir)
  • Bare-metal performans gerektiren kompüt-yoğun iş yükleri (ML training, video encoding)

Sözleşme Öncesi Checklist: 15 Maddede Due Diligence

  • Uptime SLA sözleşmede yazılı mı? (sözlü değil)
  • SLA ihlali halinde tazminat / kredi mekanizması net mi?
  • Yedekleme sıklığı, retention süresi, restore prosedürü dokümanlanmış mı?
  • Off-site yedek alma serbest mi? (rsync, mysqldump, SFTP vs. açık mı)
  • cPanel veya Plesk standart paneli kullanılıyor mu?
  • SSH erişimi (jailed olsa bile) açılabiliyor mu?
  • Cron job sınırı kaç adet ve ne sıklıkta?
  • SMTP / IP reputation: kullanılan IP bloğu blacklist'te mi? (mxtoolbox.com'dan kontrol)
  • E-posta için SPF/DKIM/DMARC kayıtlarını kendi DNS'inizden ekleme imkanı var mı?
  • DNS yönetimi panelden serbest mi yoksa sadece NS değişikliği mi?
  • KVKK uyumluluğu için aydınlatma metni veya VERBIS kaydı paylaşılıyor mu?
  • KDV'li fatura kesiliyor mu? (KKTC merkezli sağlayıcılarda olmayabilir)
  • Otomatik yenileme fiyatı promosyonel fiyattan mı liste fiyatından mı?
  • 30 gün iade hakkı kullanma prosedürü dokümanlanmış mı?
  • Domain auth code self-service mi yoksa ticket'a bağımlı mı?

Bu 15 maddeye yazılı yanıt almadan yıllık sözleşme imzalamayın. Cevapların bir kısmı sözleşmede, bir kısmı SSS'te, bir kısmı destek ticket'ında olacaktır; her biri sonradan delil olarak kullanılabilecek belgelerdir.

Pratik Sağlık Kontrolü: Mevcut Hosting'inizi Test Edin

Halihazırda IHS veya başka bir Türk hosting kullanıyorsunuz ve “güvenilir mi” sorusunu kendi sunucunuz için test etmek istiyorsanız, şu komut seti size hızlı bir tablo verir.

# 1. DNS sağlığı
dig +short A siteniz.com
dig +short MX siteniz.com
dig TXT siteniz.com | grep -E 'spf1|DKIM|dmarc'

# 2. TLS / sertifika sağlığı
echo | openssl s_client -servername siteniz.com -connect siteniz.com:443 2>/dev/null \
 | openssl x509 -noout -dates -subject -issuer

# 3. HTTP cevap süresi (5 ardışık ölçüm)
for i in 1 2 3 4 5; do
 curl -o /dev/null -s -w "$i: %{http_code} | dns: %{time_namelookup}s | conn: %{time_connect}s | tls: %{time_appconnect}s | total: %{time_total}s\n" https://siteniz.com
done

# 4. HTTP/2 ve HTTP/3 desteği
curl -sI --http2 https://siteniz.com | head -1
curl -sI --http3 https://siteniz.com | head -1 # curl 7.66+ ve HTTP/3 build gerekir

# 5. Güvenlik header'ları
curl -sI https://siteniz.com | grep -iE 'strict-transport|content-security|x-frame|x-content-type|referrer'

# 6. SSL Labs benzeri hızlı tarama (testssl.sh)
./testssl.sh --severity HIGH https://siteniz.com

# 7. Mail IP reputation (PTR + RBL kontrol)
MAIL_IP=$(dig +short A mail.siteniz.com)
dig +short -x "$MAIL_IP"
for rbl in zen.spamhaus.org bl.spamcop.net dnsbl.sorbs.net; do
 REVERSED=$(echo "$MAIL_IP" | awk -F. '{print $4"."$3"."$2"."$1}')
 echo -n "$rbl: "
 dig +short "$REVERSED.$rbl" || echo "clean"
done

Bu çıktının tamamı temizse (200 yanıtlar, geçerli sertifika, SPF/DKIM/DMARC mevcut, RBL'de temiz, total time < 800ms, HTTP/2 var) sağlayıcınız işini yapıyor demektir. Tersine, çıktıda 5xx hata, expired sertifika, RBL'de listelenmiş IP veya total time > 3s görüyorsanız sorunu sağlayıcınız ile açın; çözmüyorlarsa kapsamlı bir performans audit'i sırası gelmiştir.

WordPress Özelinde IHS Performans İpuçları

IHS'in Türkiye'deki en yaygın kullanım alanı WordPress siteleridir. Eğer halihazırda IHS WP hosting kullanıyorsanız, paketin fiziksel kapasitesini en iyi kullanmanın birkaç yolu var:

  • LSCache pluginini etkinleştirin: LiteSpeed sunucu kullanılıyorsa server-level cache ücretsiz, tek tıkla aktif. LSCache rehberimiz
  • Cloudflare ücretsiz planını ekleyin: NS değişikliği ile Türkiye dışı ziyaretçi LCP'si yarıya iner
  • Görselleri WebP/AVIF'e çevirin: Plugin yerine sunucu tarafı toplu dönüşüm CPU'yu yormaz
  • Kullanmadığınız plugin'leri silin (devre dışı bırakmak yetmez): Her plugin DB query'si demektir
  • Object cache: Redis varsa redis-object-cache plugini ile aktif edin
  • Image lazy loading: Native HTML loading="lazy" ile JS plugin gerek yok
  • Optimize edilmiş tema: GeneratePress, Astra, Kadence — bloated tema PHP'yi öldürür

Bu 7 maddeyle bir IHS shared paketinde rahatlıkla 50K-100K aylık ziyaretçi taşınabilir.

VPS / VDS Senaryosunda Sertleştirme

IHS'ten VPS/VDS aldıysanız, varsayılan kurulum çıplaktır — sertleştirme tamamen size kalmıştır. VPS güvenlik sertleştirme rehberimizdeki komutları öncelik sıralaması ile uygulayın:

#!/usr/bin/env bash
# Yeni VPS — ilk 30 dakika sertleştirme menüsü
set -euo pipefail

# 1) Sistem güncelle
apt update && apt upgrade -y
apt install -y unattended-upgrades fail2ban ufw curl wget vim
dpkg-reconfigure -plow unattended-upgrades

# 2) Kullanıcı ekle, root SSH kapat
adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh && chmod 700 /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh

sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#*Port 22/Port 22022/' /etc/ssh/sshd_config
systemctl restart sshd

# 3) Firewall — UFW
ufw default deny incoming
ufw default allow outgoing
ufw allow 22022/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable

# 4) Fail2ban — SSH brute-force koruması
cat > /etc/fail2ban/jail.local <<'EOF'
[sshd]
enabled = true
port = 22022
bantime = 24h
findtime = 10m
maxretry = 3
EOF
systemctl restart fail2ban

# 5) Otomatik güvenlik güncellemeleri
cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
EOF

echo "Temel sertleştirme bitti. Sıradaki: TLS, monitoring, log shipping."

Bu temel sertleştirme tamamlandıktan sonra Fail2ban detay yapılandırması, Let's Encrypt SSL, Nginx reverse proxy ve Prometheus + Grafana izleme ile sunucunuzu üretime hazır hale getirebilirsiniz.

Domain Tarafı: IHS'ten Çıkış vs. Kalış Hesabı

Domain'inizi başka bir registrar'a transfer etmeli misiniz? Cevap, IHS özelinde ne olduğuna değil, registrar fiyatlama / hizmet matrisine bağlı. Şu hesabı yapın:

  • IHS yenileme fiyatı: ~8-15 USD.com için (kampanyaya göre)
  • Cloudflare Registrar: Wholesale fiyat ($9.77.com) — kâr eklemez ama hosting satmaz
  • Porkbun: ~$10.50.com, free WHOIS privacy
  • Namecheap: ~$13.com, ilk yıl ucuz
  • Gandi: ~$18.com, premium destek
  • .tr alan adları için yerel zorunluluk: ICANN değil TRABIS yönetiyor;.tr'yi yurtdışı registrar'a taşıyamazsınız

Eğer.com /.net gibi gTLD bir domain'iniz varsa ve hosting'iniz farklı bir sağlayıcıdaysa, domain'i Cloudflare Registrar'a taşımak (DNS'i de Cloudflare'de tutarak) genellikle en ucuz ve en performanslı kombinasyondur.

DNS'i Cloudflare'e Taşımak

# Mevcut zone dosyasını export edin (panelinizden veya dig ile)
dig @ns1.eskidns.com siteniz.com ANY
dig @ns1.eskidns.com siteniz.com AXFR # genelde kapalı

# Cloudflare CLI (cloudflared) ile import
cloudflared tunnel login
cloudflared zone create siteniz.com
cloudflared zone import siteniz.com zone-export.txt

# NS değişikliğini panelden yapın:
# Eski: ns1.eskidns.com, ns2.eskidns.com
# Yeni: ada.ns.cloudflare.com, bob.ns.cloudflare.com

# Yayılma süresi 5 dk - 48 saat. Sırasında çift NS bırakın.
watch -n 30 'dig +short NS siteniz.com'

DNS'i Cloudflare'de tutmak, hostingden bağımsız olarak ücretsiz CDN, DDoS koruma ve TLS yönetimi getirir — sağlayıcınız ne olursa olsun ileri kazançtır.

E-posta: IHS'in En Tartışmalı Bileşeni

Şikayet platformlarında en sık tekrarlanan tema “e-posta erişim sorunları”. Bunun mimari nedeni var: paylaşımlı hostingde e-posta da paylaşımlı IP'den çıkar. Aynı IP'den spam atan başka bir müşteri, IP'yi blacklist'e düşürdüğünde sizin teslimat oranınız da çakılır. Bu yüzden kurumsal e-posta için ayrı bir sağlayıcı kullanın:

  • Google Workspace: Kişi başı ~$6/ay, sektör standardı
  • Microsoft 365 Business: Office paketi dahil, ~$6-12/ay
  • Zoho Mail: Ücretsiz tier mevcut, küçük takımlar için cazip
  • Fastmail: $5/ay, gizlilik öncelikli, sade arayüz
  • Self-host: Mailcow / Mail-in-a-Box: Kontrol için, ama IP reputation savaşına hazırlıklı olun

Hosting'inizin DNS'inde MX kayıtlarını yeni e-posta sağlayıcısına yönlendirmek 5 dakikada biter. Hosting paketi içindeki ücretsiz e-posta servisi, kurumsal güvenilirlik için yetersizdir.

Yedekleme + Disaster Recovery: 30 Dakikalık Plan

Hosting sağlayıcınızın güvenilirliğine dair tüm endişenizi tek bir adımla çözebilirsiniz: her gece off-site yedekle. Sağlayıcınız yarın iflas etse, tüm veri merkezi yansa, IP'niz blacklist'e düşse bile siz iki saatte yeniden yayında olursunuz.

#!/usr/bin/env bash
# /etc/cron.daily/site-backup — basit, sağlam yedek
set -euo pipefail

SITE="siteniz.com"
ROOT="/var/www/${SITE}"
DB_USER="wp_user"
DB_NAME="wp_db"
BACKUP_DIR="/var/backups/${SITE}"
DATE=$(date +%Y%m%d)
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# 1) DB dump
mysqldump --single-transaction --quick --routines \
 -u"$DB_USER" -p"$MYSQL_PWD" "$DB_NAME" \
 | gzip > "${BACKUP_DIR}/db-${DATE}.sql.gz"

# 2) Dosya tarball
tar -czf "${BACKUP_DIR}/files-${DATE}.tar.gz" \
 --exclude='*/cache/*' --exclude='*/wp-content/uploads/large/*' \
 -C "$ROOT".

# 3) Off-site upload (Hetzner Storage Box / Backblaze B2 / Cloudflare R2)
rclone copy "${BACKUP_DIR}/db-${DATE}.sql.gz" "remote:backups/${SITE}/db/"
rclone copy "${BACKUP_DIR}/files-${DATE}.tar.gz" "remote:backups/${SITE}/files/"

# 4) Yerelden eski yedekleri temizle
find "$BACKUP_DIR" -name '*.gz' -mtime +${RETENTION_DAYS} -delete

# 5) Sağlık check'i — bir gün yedek alınmadıysa alarm
LATEST=$(find "$BACKUP_DIR" -name 'db-*.sql.gz' -mtime -1 | wc -l)
if [ "$LATEST" -lt 1 ]; then
 curl -s -X POST "$WEBHOOK_URL" -d "text=ALARM: ${SITE} yedeği bugün alınamadı"
fi

Bu betiği chmod +x ile çalıştırılabilir yapıp /etc/cron.daily/ dizinine atın. Hetzner Storage Box ayda 3.5 EUR'dan başlar; 1 TB hedef için yıllık 42 EUR — herhangi bir hosting fiyatından çok daha ucuz bir “sigorta”.

Topluluk Doğrulaması: Kendi Çevreniz

Şikayet sitelerini değil, gerçek kullanıcı tabanını dinleyin. Türkiye'deki hosting müşterilerinin %80'i WordPress geliştiricisi, ajans, KOBİ sahibi veya küçük e-ticaret operatörüdür. Bu çevreden referans toplamak çok değerlidir:

  • WP Türkiye Facebook grubu: 30K+ üye, sürekli hosting tartışması
  • r/Turkey (Reddit): teknik konularda dürüst yorumlar
  • Twitter (X) #hosting #wordpress: anlık problem raporları
  • Discord — geliştirici sunucuları: KEYDAL Discord (discord.gg/keydal) dahil, hızlı feedback
  • Eski şirket arkadaşlarınız: Yıllarca aynı sağlayıcıyı kullanmış birinin hikayesi tek başına 100 yorum kadar değer taşır

Bir hosting kararını imzalamadan önce en az 3 farklı kanaldan, 3 farklı yıl deneyimli kullanıcıdan görüş alın.

SLA Görüşmesi: Standart Sözleşme Yetmediğinde

Yıllık 5.000 TL+ harcayacaksanız standart sözleşme yetmez. Şu maddeleri özel ekleme olarak isteyin:

  • Garantili uptime %99.95+: ihlalde aylık ücretin %10'u kadar pro-rata kredi
  • Garantili ilk yanıt süresi: P1 (kritik) için 30 dakika, P2 (yüksek) için 4 saat
  • Aylık raporlama: uptime, ticket istatistiği, planlı bakım takvimi
  • RFO (Reason For Outage): 30 dk üzeri her kesintide 24 saat içinde yazılı post-mortem
  • Backup retention: günlük 7 gün, haftalık 4 hafta, aylık 12 ay
  • Off-site backup access: kendi S3 kovanınıza otomatik kopya hakkı
  • Termination clause: 30 günlük yazılı bildirimle taraflı fesih, kullanılmayan döneme orantılı iade
  • Data portability: feshde 30 gün boyunca yedek indirme erişimi
  • Subprocessor list: kullanılan üçüncü taraflar (CDN, e-posta, log) açık liste
  • Veri ihlali bildirim süresi: 24 saat (KVKK 72 saat hedefinden öne)

Bu maddeler büyük sağlayıcıların müşteri segmentinde rutindir; talep ettiğinizde kabul ederler. Talep etmezseniz kimse kendiliğinden teklif etmez.

Geçiş Senaryosu: IHS'ten Başka Bir Sağlayıcıya

Diyelim karar verdiniz, çıkıyorsunuz. Süreci minimum kesintiyle nasıl yürütürsünüz?

  • Hafta 1 — Hazırlık: yeni sağlayıcıda hesap aç, paneli tanı, yedek aldın mı kontrol et
  • Hafta 2 — Ayna kurulum: yeni sunucuya site dosyalarını ve DB'yi kopyala, hosts dosyası ile test et
  • Hafta 3 — DNS TTL düşür: TTL'yi 86400'den 300'e indir (yayılma için 24 saat bekle)
  • Hafta 4 — Cutover: DNS A kaydını yeni IP'ye yönlendir, e-posta MX'i kontrol et
  • Hafta 5 — Bekleme + temizlik: 30 gün eski hosting'i tut (DNS yayılması yetkin tarafa kadar); sonra fesih
# DNS TTL düşürme (cutover öncesi 24 saat)
# Eski (önce bunu uygula, 24 saat bekle):
siteniz.com. 86400 IN A 1.2.3.4

# Yeni (TTL = 300, yayılma hızlanır):
siteniz.com. 300 IN A 1.2.3.4

# Sonra cutover anında IP'yi değiştir:
siteniz.com. 300 IN A 5.6.7.8

# 24 saat sonra normal TTL'e geri dön:
siteniz.com. 3600 IN A 5.6.7.8

# Cutover sonrası test
for ns in 1.1.1.1 8.8.8.8 9.9.9.9; do
 echo -n "$ns: "
 dig @$ns +short A siteniz.com
done

# Eski IP'ye giden trafiği logla — kim hala eski cache'e bakıyor?
tcpdump -i eth0 'host 1.2.3.4 and dst port 443'

Doğru yapılan bir cutover'da kullanıcı tarafında sıfır kesinti hissedilir. Çünkü hem eski hem yeni sunucu aynı içeriği serve eder; DNS yayılması bittiğinde herkes yeni sunucuya gelmiş olur. Sonra eski hesabı kapatabilirsiniz.

Sıkça Sorulan Sorular

IHS.tr domain almak için zorunlu mu?

Hayır..tr alan adları artık ICANN değil TRABIS tarafından yönetiliyor ve Türkiye'de akredite onlarca registrar var. IHS bu listenin başlarında olsa da tek seçenek değil. Karşılaştırmalı registrar fiyatlarını WHOIS aracımızdan kontrol edebilirsiniz.

Shared hosting paketinde yıllık kaç ziyaretçi taşıyabilirim?

Statik ya da iyi optimize edilmiş bir WordPress için aylık 50.000-100.000 ziyaretçi rahattır. Üzeri için VPS veya managed WP hosting'e geçiş düşünün. Optimizasyon rehberimizdeki ilkeleri uygulayarak shared paketinizden çok daha fazla performans alabilirsiniz.

E-postam IHS'ten kayboldu, geri alabilir miyim?

E-posta sağlayıcı tarafında IMAP siliniyorsa hayır. Cihazınızda halen mbox / pst dosyası varsa kurtarılabilir. Bu yüzden kurumsal e-postayı her zaman ayrı sağlayıcıda + IMAP aynalama ile birlikte tutmanızı öneriyoruz.

Bu kadar şikayet varken neden hala büyük müşteriler kullanıyor?

Çünkü mutlak şikayet sayısı müşteri sayısının küçük bir yüzdesidir. Aynı zamanda kurumsal müşteriler özel sözleşmelerle çalışır — kamuya açık şikayet platformlarındaki örüntü, premium kurumsal müşterinin deneyimi olmayabilir. Yine de kişisel deneyiminizi kendi metriklerinizle ölçmenizi öneriyoruz.

Türkiye'de tek sağlayıcı yerine multi-cloud mantıklı mı?

Mission-critical sistemler için evet. DNS'i Cloudflare'de, primary hosting'i Türkiye'de, yedeklemeyi AB / ABD storage'da tutmak akıllıca bir dağıtımdır. Tek bir failure point'in tüm sistemi düşürmemesi için.

Sonuç: “IHS Güvenilir mi?” Sorusunun Net Cevabı

Sonuç şu: IHS Telekom orta ölçek KOBİ ve kurumsal Türkiye odaklı projeler için makul, kabul edilebilir bir sağlayıcıdır — ama mission-critical, yüksek trafikli veya 7/24 destek gerektiren iş yükleri için ek katmanlar (CDN, off-site backup, ayrı e-posta sağlayıcısı, premium SLA sözleşmesi) olmadan yeterli değildir. Yıllık 25 yıllık sektör tecrübesi,.tr akreditasyonu ve İstanbul lokasyonu gerçek artılardır; hafta sonu/gece destek yetersizliği ve self-service yedekleme eksikliği ise gerçek eksilerdir.

Karar matrisi olarak şu iki cümle yeter: “Türkiye lokasyonu zorunluysa, KVKK uyumu kritikse ve KOBİ ölçeğindeyseniz IHS makul bir tercih. 24/7 mission-critical bir sistem işletiyorsanız ya managed kurumsal sözleşme imzalayın ya da yurtdışı tier-1 sağlayıcısına yönelin.”

Her durumda, sağlayıcı bağımsız bir yedekleme stratejiniz, bağımsız bir DNS yöneticiniz (Cloudflare gibi) ve bağımsız bir e-posta sağlayıcınız olsun. Bu üç katman, hangi hosting şirketini seçerseniz seçin sizi büyük çoğunluk operasyonel riskten korur.

Kaynaklar ve İleri Okuma

Hosting kararınızı tarafsız bir uzmana danışmak ister misiniz?

Mevcut sağlayıcınız için bağımsız bir audit, geçiş planı, yedekleme mimarisi veya özel SLA müzakeresi konusunda KEYDAL ekibiyle iletişime geçin

WhatsApp