[Ana Sayfa](https://servhidden.com/tr) / [Gizlilik Barındırma Rehberler](https://servhidden.com/tr/guides) / Web Sitesini Offshore Hosting'e Kesintisiz Taşıma Operasyonlar # Offshore Hosting'e Kesintisiz Geçiş Acı verici hemen hemen her taşıma işlemi teknik değil, sıralama hatasıdır — iki gün önce yerine geceleyin düşürülen bir TTL, DNS değişikliğinden önce değil sonra çıkarılan bir sertifika, artık yetkili olmayan bir sunucuda etkin bırakılmış bir cron işi. Bu, kesinti penceresini tamamen ortadan kaldıran sıralamadır, artı genel rehberlerin atladığı kısım: taşımanın hakkınızda kalıcı olarak neyi kaydettiği ve bu konuda hâlâ ne yapabileceğiniz. [Rehberi oku](#guide-body) [SSS](#guide-faq) ## Bu sayfada - [Rehber](#guide-body) - [SSS](#guide-faq) - [İlgili rehberler](#guide-related) - [Önerilen sayfalar](#guide-cta) KYC yok Yalnızca Kripto Log Yok DMCA Göz Ardı Edilir Tam Root NVMe SSD 19 dakika okuma Aug 2026 tarihinde güncellendi Bu sayfada [01“Sıfır kesinti” gerçekte ne anlama gelir](#sıfır-kesinti-gerçekte-ne-anlama-gelir) [02DNS TTL'yi taşımayı planladığınız günden günler önce düşürün](#dns-ttlyi-taşımayı-planladığınız-günden-günler-önce-düşürün) [03Hafızanızdakini değil, gerçekte taşıdığınızı envanterleyin](#hafızanızdakini-değil-gerçekte-taşıdığınızı-envanterleyin) [04Önce yeni sunucuyu kurun, üzerinde bir şey barındırmadan önce sıkılaştırın](#Önce-yeni-sunucuyu-kurun-üzerinde-bir-şey-barındırmadan-önce) [05Veriyi iki kez kopyalayın: önce yavaş bir geçiş, sonra hızlı bir geçiş](#veriyi-iki-kez-kopyalayın-önce-yavaş-bir-geçiş-sonra-hızlı-b) [06DNS varlığını öğrenmeden önce yeni sunucuyu test edin](#dns-varlığını-öğrenmeden-önce-yeni-sunucuyu-test-edin) [07Geçiş, sırasıyla](#geçiş-sırasıyla) [08Taşımanın geride bıraktıkları](#taşımanın-geride-bıraktıkları) [09Alan adı sorusu: birlikte mi taşınsın, yoksa sıfırdan mı başlansın?](#alan-adı-sorusu-birlikte-mi-taşınsın-yoksa-sıfırdan-mı-başla) [10Eski sunucuyu doğru şekilde devre dışı bırakın](#eski-sunucuyu-doğru-şekilde-devre-dışı-bırakın) [11Tüm sıralama tek sayfada](#tüm-sıralama-tek-sayfada) [FAQCommon sorular](#guide-faq) [→Önerilen sayfalar](#guide-cta) Hiç kimse canlı bir siteyi eğlence olsun diye taşımaz. Bunun nedeni, mevcut sağlayıcının aniden pasaportunuzun bir fotoğrafını istemesi, yirmi dört saatlik bir süre tanıyan bir şikayeti size iletmesi ya da veri merkezinin bulunduğu ülkenin artık verinizi tutmak için makul bir yer gibi görünmemesidir. Sizi iten sebep ne olursa olsun, taşınmanın kendisi tehlikeli olan kısımdır — sitenin karanlığa gömülebileceği tek an odur, ve dikkatsiz bir adımın yeni sunucuyu geride bırakmaya çalıştığınız kimliğe zımbalayabileceği tek andır. İki riskin de tedavisi aynıdır ve bu bir araç değildir. Sıralamadır. Doğru sırayla yürütülen bir taşıma işleminde sitenin erişilemez olduğu bir pencere yoktur, çünkü iki sunucu da aynı anda çalışır durumdadır ve DNS taşınan en son şeydir. Yanlış sırayla yürütülen bir taşıma işlemi ise aynı anda hem bir kesinti hem de bir iz üretir. Aşağıdaki sıralama, iki ana akım sağlayıcı arasında geçiş yapmak yerine offshore, KYC'siz bir sağlayıcıya taşınan biri için yazılmıştır — mekanik aynıdır, ama sonrasındaki temizlik aynı değildir. ## “Sıfır kesinti” gerçekte ne anlama gelir Bu ifade gelişigüzel kullanılıyor ve insanların canı da tam bu gevşeklik yüzünden yanıyor. İki makineden aynı anda HTTP sunmak kolaydır. İki makine aynı anda hizmet verirken *durumu* tutarlı tutmak ise zor olan kısımdır ve veri kaybına yol açabilecek tek kısım da budur. Bu yüzden herhangi bir şey planlamadan önce, gerçekte hangisini işlettiğinize karar verin, çünkü cevap tüm gecenin şeklini belirler. | Taşıdığınız şey | Asıl ısıran kısım | Plan ne olmalı | | --- | --- | --- | | Statik site, tanıtım sitesi, üretilmiş çıktı | Hiçbir şey. Bölünecek bir durum yok | Kopyala, doğrula, geçiş yap. Gerçek anlamda sıfır kesinti | | Veritabanlı bir CMS — WordPress, Ghost, bir forum | Yorumların, girişlerin ve gönderilerin aynı anda iki veritabanına düşmesi | **Dakikalar** ile ölçülen, salt okunur bir dondurma, en sessiz saatinizde | | Bir mağaza, ya da sipariş alan herhangi bir şey | Split brain, ödenmiş siparişleri sessizce kaybeder | Kısa bir bakım penceresi alın. Bu, uzlaştırmadan daha ucuzdur | | Cron işleri veya arka plan worker'ları olan her şey | Aynı işin her iki sunucuda birden tetiklenmesi — çift e-posta, çift ücretlendirme | Eskisindeki zamanlamayı yenisi başlamadan *önce* devre dışı bırakın | | Aynı alan adındaki mail | MX kayıtları önbelleklerden kendi saatine göre düşer, A kaydınızla ilgisi yoktur | Maili ayrı bir gecede taşıyın ve eski MX'i bir hafta boyunca kabul eder halde bırakın | Yalnızca ilk satırın gerçekten bedava olduğuna dikkat edin. Diğer her yerde “sıfır kesinti”, “kimsenin bilet açmayacağı kadar kısa bir yazma dondurması” anlamına gelir. Saat 04:00'te iki dakikalık salt okunurluk bir yuvarlama hatasıdır; iki veritabanı arasında iki saatlik bölünmüş yazma ise bir hafta sonu süren uzlaştırma demektir. Dondurmayı seçin. İki sunucu da aynı anda çalışır ve DNS en son taşınır — doğru sıralanmış bir geçişin hiçbir penceresi olmamasının sebebi budur. ## DNS TTL'yi taşımayı planladığınız günden günler önce düşürün Bu, kendine özgü bir hazırlık süresi olan tek adımdır; bu yüzden hem ilk sırada gelir hem de insanların atladığı adımdır. TTL'niz — yaşam süresi — internetteki her resolver'a kaydınızı tekrar sormadan önce ne kadar süre önbellekte tutabileceğini söyler. A kaydınızın TTL'si 86400 ise, kaydı bir saat önce sorgulamış bir resolver, kayıt şirketinde ne değiştirirseniz değiştirin eski IP'yi bir yirmi üç saat daha vermeye devam eder. Kritik ayrıntı şudur: TTL'yi düşürmenin kendisi de eski TTL'ye tabidir. Resolver'lar yeni, daha kısa değeri ancak önbellekteki eski kopyanın süresi dolduğunda öğrenir. Bu yüzden TTL'yi **geçiş yapmadan en az bir tam eski-TTL süresi önce** 300 saniyeye düşürün — bir günlük bir TTL için bu, işlemi 24 ila 48 saat önceden yapmak anlamına gelir. O zaman dünya, değişiklikten sonraki beş dakika içinde yeni kaydınızda birleşir ve geçiş, gerilimli bir olay olmaktan çıkar. Taşımadan birkaç gün sonra TTL'yi yine makul bir değere geri çıkarın. 300 saniyelik bir TTL iyi bir araçtır ama zayıf bir kalıcı ayardır: sorgu hacminizi katlar ve DNS sağlayıcınızı çok daha keskin bir tek arıza noktasına dönüştürür. ## Hafızanızdakini değil, gerçekte taşıdığınızı envanterleyin Başarısız her taşıma işleminin ölüm-sonrası raporu aynıdır: kimsenin listelemediği bir şey kopyalanmamıştır. Web kök dizini ve veritabanı herkesin hatırladığı iki şeydir; aşağıdaki liste geri kalanıdır ve hafızadan değil, gerçekten madde madde gezmeye değer. - **Zamanlanmış işler.** Her kullanıcı için crontab -l, ayrıca systemd timer'ları. Yenileme hook'ları ve gecelik işler burada saklanır. - **Servis tanımları.** Özel systemd unit'leri, web sunucusu vhost'ları, PHP-FPM havuzları, herhangi bir supervisor yapılandırması. - **Sırlar ve ortam.** .env dosyaları, API anahtarları, veritabanı parolaları, uygulama salt'ları — ve bunların yalnızca kopyalanması değil, döndürülmesi gerektiğini unutmayın. - **TLS materyali.** Sertifikalar ve, daha da önemlisi, ACME hesabı ve yenileme yapılandırması. - **Mail kimliği.** DKIM özel anahtarları, SPF ve DMARC kayıtları. Buradaki bir uyumsuzluk gürültülü şekilde bozulmaz; sessizce mailinizi spam'e gönderir. - **Yüklenmiş medya.** Sık sık web kök dizininin dışındadır, sık sık sahip olduğunuz en büyük şeydir. - **IP'nize güvenen dışarıdaki her şey.** Ödeme ağ geçidi izin listeleri, webhook hedefleri, veritabanı güvenlik duvarları, IP kısıtlaması olan üçüncü taraf API'ler. Saat 03:00'te “site çalışıyor ama ödeme sayfası bozuk” durumunun bir numaralı sebebi budur. - **Paket listesi.** dpkg --get-selections ya da eşdeğeri, böylece yeni makinede neredeyse aynı değil, tam olarak aynı eklentiler ve kütüphaneler olur. Kopyalamaya başlamadan önce listeyi yazın. Envanter aynı zamanda daha sonraki test planınızdır — üzerindeki her satır, DNS onun varlığını öğrenmeden önce yeni sunucuda doğrulanması gereken bir şeydir. ## Önce yeni sunucuyu kurun, üzerinde bir şey barındırmadan önce sıkılaştırın Hedef sunucuyu erkenden sipariş edin ve bir iki gün boş, çalışır halde bırakın. Bu örtüşmenin bir maliyeti yoktur — küçük bir offshore VPS ayda birkaç dolardır — ve kurulumu, dondurulmuş bir veritabanı beklerken zaman baskısı altında yapmamanın büyük bir değeri vardır. Eski ortamı bilinçli olarak eşleştirin: aynı dağıtım ve ana sürüm, aynı PHP, Node veya Python ana sürümü, aynı veritabanı ana sürümü. İşin içindeyken modernleştirme isteği çok büyüktür ve buna tamamen direnilmelidir. Site geçişten sonra bozulursa, değişmiş olanın tam olarak tek bir değişken olmasını istersiniz. Yığını iki hafta sonra, sıradan bir öğleden sonra, geri dönme imkanınız varken yükseltin. Sunucu hâlâ boşken sıkılaştırın. Yalnızca anahtarla SSH, varsayılan olarak reddeden bir güvenlik duvarı, otomatik güvenlik güncellemeleri — [ilk saat sıkılaştırma kontrol listesi](https://servhidden.com/tr/guides/first-hour-vps-hardening-checklist) tam olarak bu listedir ve üzerinde hiçbir şey olmayan bir makineye uygulamak çok daha kolaydır. Veri, yargı alanı değiştirecek kadar hassassa, [bekleme halinde şifrelemeye](https://servhidden.com/tr/guides/full-disk-encryption-on-a-vps) karar vermek için de doğru an tam olarak budur, çünkü bunu sonradan eklemek başka bir taşıma işlemi demektir. ## Veriyi iki kez kopyalayın: önce yavaş bir geçiş, sonra hızlı bir geçiş İçgüdü, her şeyi bakım penceresi sırasında kopyalamaktır. Tam tersini yapın. Eski site memnuniyetle trafik sunarken günler öncesinden tam bir kopya çalıştırın, sonra geçiş anında yalnızca değişeni taşıyan ikinci bir geçiş yapın. İlk geçiş altı saat sürebilir ve kimse fark etmez. İkincisi doksan saniye sürer ve tüm kesinti bütçeniz de budur. Dosyalar için rsync -aHAX --numeric-ids izinleri, sahipliği, hard link'leri ve genişletilmiş öznitelikleri korur; --numeric-ids bayrağı önemlidir çünkü UID'ler yeni kurulmuş iki makine arasında nadiren örtüşür. Bunu bir kez erkenden, sonra geçişten hemen önce aynı argümanlarla tekrar çalıştırın — ikinci çalıştırma yalnızca farkı (delta) aktarır. Veritabanları aynı iki aşamalı muameleyi ister ama farklı araçlarla. Bir mysqldump --single-transaction ya da pg_dump, üzerinde kurulum yapıp test edebileceğiniz tutarlı, erken bir anlık görüntü verir. Geçiş anında ya kısa yazma dondurmanız sırasında ikinci bir döküm alın, ya da — kısa bir dondurmanın bile canını yaktığı büyük bir veritabanı için — yeni sunucuyu günler öncesinden eskisinin bir replikası olarak kurun, yakalamasına izin verin, sonra terfi ettirin. Replikasyon, dondurmayı saniyelere indirir. Ama aynı zamanda iki saatlik bir taşıma işlemini iki günlük bir projeye dönüştürür, bu yüzden yalnızca boyut bunu gerçekten gerektirdiğinde kullanın. **Push değil pull yapın, ve asla laptopunuz üzerinden değil.** Kopyalamayı yeni sunucudan başlatın, böylece aktarım sunucudan sunucuya, veri merkezi hızında çalışır. Gigabaytları ev bağlantınız üzerinden yönlendirmek yavaştır ve ev IP'nizi her iki makinenin de erişim loglarına yerleştirir — ki bu, gizlilik güdümlü bir taşımanın tam olarak kaçınmak için var olduğu bağlantıdır. Eski sağlayıcının yeni IP'nizi öğrenmesi bile kabul edilemezse, doğrudan hiç kopyalamayın: bunun yerine yeni sunucuyu kendi [site dışı şifreli yedeğinizden](https://servhidden.com/tr/guides/vps-backup-strategy) geri yükleyin, böylece iki makine hiçbir zaman birbiriyle konuşmaz. ## DNS varlığını öğrenmeden önce yeni sunucuyu test edin Gerçek ana bilgisayar adını tek bir genel kaydı bile değiştirmeden yeni IP'den sunabilirsiniz, ve bunu yapmalısınız da — geçişi olaysız kılan şey budur. Yerel /etc/hosts dosyanıza alan adını yeni IP'ye yönlendiren bir satır ekleyin, ya da bunu atlayıp curl'e tek bir istek için bunu yaptırın: curl -I --resolve example.com:443:203.0.113.10 https://example.com/ Şimdi envanteri gezin. Ana sayfayı ve üç derin sayfayı yükleyin. Giriş yapın. Bir form gönderin. Bir dosya yükleyin. Veritabanı bağlantısının yeni, yerel olan bağlantı olduğunu ve hâlâ internet üzerinden eski sunucuya işaret etmediğini kontrol edin — eski sunucuyu iptal edene kadar kusursuz çalışan bir hata türüdür bu. Cron işlerini elle çalıştırın ve çıktılarını okuyun. Yönlendirmeleri ve eksik bir URL'nin hâlâ 200 değil 404 döndürdüğünü doğrulayın. TLS sertifikasını şimdi, geçişten önce çıkarın, sonra değil. Bir DNS-01 challenge kullanın; bu, alan adı kontrolünü bir TXT kaydı üzerinden kanıtlar ve bu yüzden A kaydı hâlâ eski sunucuya işaret ederken de çalışır. DNS değişikliğinden sonra HTTP-01 doğrulamasını beklerseniz, bu aradaki her erken ziyaretçi bir sertifika uyarısı alır — tam olarak korumaya çalıştığınız pencerede kendi kendine verilmiş bir kesinti. ## Geçiş, sırasıyla Bu noktada yeni sunucu kurulmuş, sıkılaştırılmış, doldurulmuş, gerçek ana bilgisayar adı altında test edilmiş ve geçerli bir sertifika tutuyor durumdadır. Geçişin kendisi artık kısa, sıkıcı bir listedir — hedeflenen de tam olarak budur. - Siteye başka birileri bağımlıysa pencereyi duyurun, sonra eski siteyi salt okunur ya da bakım moduna alın. - **Eski sunucudaki cron'u ve arka plan worker'larını devre dışı bırakın.** Bunu yenisinde başlatmadan önce yapın, asla sonra değil. - Son rsync fark geçişini ve son veritabanı dökümünü çalıştırın, sonra içe aktarın. - Uygulamayı yeni sunucuda başlatın ve smoke testlerinizi son veriye karşı --resolve üzerinden tekrar çalıştırın. - A ve AAAA kayıtlarını yeni IP'ye değiştirin. 300 saniyelik bir TTL ile dünya beş dakika içinde bunu takip eder. - Yeni sunucuda cron'u ve worker'ları etkinleştirin. - Her iki erişim logunu da yan yana izleyin. Trafik eski sunucudan boşalır ve yenisinde belirir; eskisi sessizleştiğinde geçiş tamamlanmış demektir. - Eski sunucuyu bir hafta boyunca çalışır, hizmet verir ve dokunulmamış halde bırakın. Bu sizin geri dönüş planınızdır. Sekizinci adım insanların kestiği adımdır ve listedeki en ucuz sigortadır. Birkaç dolar karşılığında, emin olana kadar DNS'i geriye çevirme yeteneğini — beş dakikalık bir kurtarma — elinizde tutarsınız. ## Taşımanın geride bıraktıkları İşte genel taşıma rehberlerinin atladığı kısım, ve fiyat için değil de gizlilik için taşındıysanız en önemli olan kısım. Bir siteyi taşımak onun geçmişini silmez. Eski düzenlemenin birkaç kamusal ve yarı kamusal kaydı, taşınmadan sağ çıkıp kalıcı olarak yaşamaya devam eder ve hangilerinin sağ kaldığını bilmek, temiz bir kopuş ile onun sahte bir hissi arasındaki farktır. | Taşımayı ne kaydeder | Bunu kim okuyabilir | Gerçekte ne yapabilirsiniz | | --- | --- | --- | | Pasif DNS — geçmiş A kayıtları | Ticari geçmiş servisleri aracılığıyla herkes | **Hiçbir şey.** Eski IP, isimle kalıcı olarak ilişkilendirilmiştir. Sanki genel erişime açıkmış gibi planlayın, çünkü öyledir | | Certificate Transparency logları | Herkes, kalıcı olarak, alan adına göre aranabilir şekilde | Bugüne kadar çıkarılmış her sertifika listelenir — unuttuğunuz, kulağa iç kullanıma özel gelen alt alan adları dahil. Açıklayıcı isimler yerine bir wildcard tercih edin | | Eski sağlayıcının hesap kayıtları | Eski sağlayıcı, ve onları buna zorlayabilecek herkes | Kart bilgileri, kayıt e-postası, giriş IP'leri. KYC'siz bir hedef geleceği korur, geçmişi değil | | WHOIS geçmişi | Ticari WHOIS-geçmişi arşivleri | Alan adı bir kez bile gerçek bilgilerle kaydedildiyse, o anlık görüntü yakalanmıştır. Sonradan uygulanan gizlilik onu geri çekmez | | Analitik ve reklam kimlikleri | Tedarikçi, ve sayfa kaynağınızı okuyan herkes | Aynı izleme kimliğini taşımak iki siteyi kesin olarak birbirine bağlar. Yeni bir tane çıkarın, ya da tamamen bırakın | | Eski diskte bırakılan dökümler ve yedekler | O depolama alanı sırada kime tahsis edilirse | İptal etmeden önce silin ve üzerine yazın. Paylaşımlı depolamada, silmenin bir garanti değil bir ipucu olduğunu varsayın | | Gönderilen mailde Received: başlıkları | Her alıcı, sonsuza dek | Geriye dönük hiçbir şey yok. Yalnızca taşımadan sonra gönderdiğiniz mail yeni yolu taşır | | Kopyalama sırasındaki kendi bağlantılarınız | İnternet sağlayıcınız, ve her iki sunucunun erişim logları | Bu, tamamen sizin kontrolünüzdedir. Sizi tanımlayan bir IP'den iki makineden hiçbirine asla dokunmayın | Dürüst özet şudur: bir taşıma işlemi geçmişi yeniden yazamaz — yalnızca ona yenisini eklemeyi durdurabilir. Bu yine de büyük bir değer taşır, ama kararı değiştirir: tehdit modeliniz hiçbir gözlemcinin yeni siteyi eskisine bağlayamamasını gerektiriyorsa, aynı alan adını yeni bir sağlayıcıya taşımak bunu başaramaz, ve geçiş sırasında ne kadar özen gösterirseniz gösterin de başaramaz. O durum yeni bir isim ve temiz bir başlangıç gerektirir; bir sonraki bölümde ele alınıyor. Bunun yerine amacınız bugünden itibaren kimlik belirleyici kayıt üretmeyi durdurmak ve yasal ağırlık merkezini seçtiğiniz bir yargı alanına taşımaksa, taşıma işlemi tam olarak bunu yapar. [Sunucu OpSec rehberimiz](https://servhidden.com/tr/guides/server-opsec-staying-anonymous), sonrasında bunu temiz tutan alışkanlıkları ele alır. ## Alan adı sorusu: birlikte mi taşınsın, yoksa sıfırdan mı başlansın? Site ve alan adı birbirinden bağımsız kararlardır, ve bunları birbirine karıştırmak yaygındır. Hosting'i bugün taşıyabilir ve kayıt şirketine sonsuza dek dokunmayabilirsiniz; sunucu değişikliğinin hiçbir yanı alan adına dokunmayı gerektirmez. Bunu yapmanız *gerekip gerekmediği* ise tamamen alan adının sizin hakkınızda şimdiden ne bildiğine bağlıdır. - **Alan adını koruyun, kayıt şirketini değiştirin.** Alan adının bir değeri olduğunda — bağlantılar, sıralamalar, insanların yazdığı bir isim — mantıklıdır. WHOIS kaydının geleceğini düzeltir, geçmişini değil, ve her sıralama sinyalini olduğu gibi korur. Çoğu ticari site için doğru cevap budur. - **Alan adını koruyun, yalnızca sunucuyu değiştirin.** Anonimlik yerine yargı alanı, çalışma süresi ya da DMCA tutumu için taşındıysanız tamamen makuldür. Mümkün olan en basit taşıma, sıfır SEO riski. - **Yeni alan adı, eskisini yönlendir.** Sıralamaları korur, ve iki ismi kamuya açık ve kalıcı olarak birbirine bağlar. Bunu süreklilik için seçin, gizlilik için asla — yönlendirmenin kendisi o bağlantıdır. - **Yeni alan adı, temiz kopuş.** Bağlantıyı gerçek anlamda kesen tek seçenektir, ve sahip olduğunuz her sıralamaya ve gelen bağlantıya mal olur. Baştan itibaren gizli şekilde kaydedin, çünkü bir alan adı ancak ilk kaydı kadar anonimdir. [Kripto ile anonim alan adı kaydı](https://servhidden.com/tr/guides/anonymous-domain-registration-with-crypto) rehberimiz bunu doğru şekilde yapmayı ele alır. Bilinçli seçin, ve geçiş sırasında değil öncesinde seçin. Alan adı hakkında DNS taşındıktan sonra fikir değiştirmek, hassas kısmı iki kez yapmak demektir. ## Eski sunucuyu doğru şekilde devre dışı bırakın Geçişten bir iki hafta sonra, yeni sunucunun logları sıkıcı ve eskisinin logları boşken, eski hesabı kapatma zamanı gelmiştir. Bunu bu sırayla yapın, çünkü cazip kısayol — doğrudan iptale basmak — verinizi başkasının diskinde bırakan kısayoldur. - Hiçbir şeyin hâlâ eski IP'ye işaret etmediğini doğrulayın: üçüncü taraf webhook'larda, izin listelerinde, izlemede sabit kodlanmış adresleri ve unuttuğunuz, örneğin başıboş bir mail ya da cpanel alt alan adı gibi herhangi bir DNS kaydını kontrol edin. - O makinede yaşamış her sırrı döndürün — veritabanı parolaları, API anahtarları, uygulama salt'ları, DKIM anahtarları, SSH anahtarları. Bunları ileri taşımayın. - SSH açık anahtarlarınızı ve destek erişimini eski sunucudan kaldırın. - Uygulamayı, dökümleri ve yedekleri silin, sonra boş alanın üzerine yazın; böylece geri dönüştürülen birimin gelişigüzel bir okuması hiçbir şey vermez. - Ancak o zaman servisi sonlandırın ve eski hesaptan kayıtlı ödeme yöntemini kaldırın. **Artık kontrolünüzde olmayan bir donanımda yaşamış her şey, tanım gereği ele geçirilmiş sayılır.** Eski sağlayıcınız kötü niyetli olduğu için değil, o disk bir havuza geri döneceği ve silme işleminden neyin sağ çıktığını asla bilemeyeceğiniz için. Bir veritabanı parolasını döndürmek iki dakika sürer. Aylar sonra, devre dışı bırakılmış bir sunucudan kalan bir anahtarın hâlâ bir şeyi açtığını keşfetmek çok daha uzun sürer. ## Tüm sıralama tek sayfada Gerekçeleri çıkarırsanız bir sunucu taşıma işlemi dokuz adımdır, ve bunlardan yalnızca ikisinin aciliyeti vardır: - **İki gün önce:** DNS TTL'yi 300 saniyeye düşürün. - **İki gün önce:** hedef sunucuyu sipariş edin ve sıkılaştırın, eski yığınla sürüm sürüme eşleştirerek. - **Günler önce:** envanteri yazın — cron, sırlar, TLS, mail anahtarları, medya, IP izin listeleri, paketler. - **Günler önce:** sunucudan sunucuya ilk tam veri kopyasını çalıştırın. - **Pencereden önce:** sertifikayı DNS-01 ile çıkarın ve her şeyi --resolve üzerinden test edin. - **Pencere (dakikalar):** yazmaları dondurun, eski cron'u devre dışı bırakın, fark kopyasını ve son dökümü çalıştırın, yeni uygulamayı başlatın. - **Pencere (saniyeler):** A kaydını değiştirin, sonra yeni sunucuda cron'u etkinleştirin. - **Takip eden hafta:** eski sunucuyu bir geri dönüş planı olarak canlı tutun, her iki log dosyasını da izleyin, sonra TTL'yi yeniden yükseltin. - **Sonrasında:** sırları döndürün, silin, iptal edin — ve taşımanın silemediği şeyi hatırlayın. O listede zor olan hiçbir şey yok. Acı veren her adım, sırasından çıkarılmış bir adımdır — geceleyin düşürülen bir TTL, DNS değişikliğinden sonra çıkarılan bir sertifika, artık yetkili olmayan bir makinede etkin bırakılmış bir cron işi. Sıralamayı doğru yapın, ve bir taşıma işlemindeki ilginç kısım sunucuyu nereye koyacağınızı seçmek olur, taşınmanın kendisi değil. Bunu henüz karara bağlamadıysanız, başlanacak yer [yargı alanı rehberidir](https://servhidden.com/tr/guides/choosing-an-offshore-jurisdiction). SSS ## Sunucu taşıma — sık sorulan sorular ### 01 Gerçekte ne kadar kesinti beklemeliyim? Statik bir site için hiç — iki sunucu da aynı içeriği aynı anda sunabilir, bu yüzden DNS değişikliği görünmez bile olmaz. Veritabanı olan her şey için kesintiniz tam olarak yazma dondurmanızın uzunluğu kadardır; bu da önceden tam bir veri kopyası çalıştırdıysanız genellikle iki ile on dakika arasıdır. Önemli olan sayı DNS'in ne kadar hızlı taşındığı değildir; pencere sırasında ne kadar kopyaladığınızdır. Neredeyse her şeyi günler öncesinden kopyalayın, pencere de farkın boyutuna küçülsün. ### 02 DNS yayılması ne kadar sürer? Aslında bir “yayılma” yoktur — bu kelime gerçekleşmeyen bir şeyi tarif eder. Resolver'lar kaydınızı yalnızca TTL'nin söylediği süre kadar önbellekte tutar ve süresi dolunca tekrar sorar. Geçerli olan TTL 86400 ise, bazı resolver'lar eski IP'yi daha 24 saat boyunca sunmaya devam eder. TTL'yi geçişten en az bir tam eski-TTL süresi önce 300 saniyeye düşürün, internetin tamamı değişikliğinizi beş dakika içinde takip etsin. ### 03 Alan adımı da taşımam gerekir mi? Hayır. Kayıt şirketi ve sunucu tamamen birbirinden bağımsızdır, siteyi taşırken alan adını tam olduğu yerde bırakmak kusursuz şekilde çalışır. Taşımanız gerekip gerekmediği, taşınma sebebinize bağlıdır: sebep yargı alanı, fiyat ya da DMCA tutumuysa alan adına dokunmayın. Sebep anonimlikse, alan adının kendine ait ayrı bir geçmiş taşıdığını unutmayın — WHOIS arşivleri ilk hangi bilgilerle kaydedildiyse onu saklar, ve hosting değişiklikleri buna dokunmaz. ### 04 Eski sağlayıcı nereye gittiğimi öğrenmeden taşınabilir miyim? İki makine arasında doğrudan kopyalarsanız hayır — bir uç diğerine bağlanır ve her iki erişim logu da bunu kaydeder. Bu bağlantı tehdit modelinizde gerçekten önemliyse, hiç sunucudan sunucuya kopyalamayın: yeni sunucuyu kendi site dışı şifreli yedeğinizden geri yükleyin, böylece iki sağlayıcı hiçbir zaman paket alışverişi yapmaz. Ne olursa olsun, aktarımı sizi tanımlayan bir bağlantıdan asla başlatmayın ve hedefi eski sağlayıcıyla açtığınız herhangi bir destek talebinin dışında tutun. ### 05 İşletim sistemini ya da yazılım yığınını aynı anda yükseltmeli miyim? Hayır, ve bu en yaygın kendi kendine verilen taşıma hasarıdır. Tek bir şeyi değiştirin. Site geçişten sonra tuhaf davranırsa, yeni makine, yeni PHP sürümü ve yeni veritabanı ana sürümü arasında seçim yapmak yerine tek bir aday açıklama istersiniz. Eski ortamı sürüm sürüme eşleştirin, taşımayı tamamlayın, bir haftalık temiz logları doğrulayın, sonra geri dönme imkanınız varken ayrı olarak yükseltin. ### 06 Taşınmak arama sıralamalarıma zarar verir mi? Alan adı, URL'ler ve içerik aynı kaldığı sürece anlamlı bir zarar görmezsiniz — Google IP adreslerini değil URL'leri indeksler ve tek başına bir sunucu değişikliği bir sıralama sinyali değildir. URL yapısını aynen koruyun, aynı durum kodlarını döndürün ve taşımayı bir yeniden tasarımla ya da URL şeması değişikliğiyle birleştirmeyin. Bunun yerine yeni bir alan adına taşınıyorsanız, doğru 301 yönlendirmelerle bile geçici bir düşüş bekleyin ve bu yönlendirmelerin iki ismi de kamuya açık şekilde birbirine bağladığını bilin. ### 07 TLS sertifikalarını yeniden çıkarmam gerekir mi? Evet — yeni sunucunun kendi sertifikasına ve özel anahtarına ihtiyacı vardır, eski anahtarı ileri taşımak teknik olarak çalışsa bile kötü bir alışkanlıktır. Bunu geçişten önce, bir TXT kaydı üzerinden doğrulayan ve bu yüzden A kaydı hâlâ eski sunucuya işaret ederken de başarılı olan bir DNS-01 challenge kullanarak çıkarın. DNS değişikliğinden sonra HTTP-01'i beklemek, tam olarak korumaya çalıştığınız pencerede bir dizi sertifika uyarısını garantiler. ### 08 Eski sunucuyu iptal etmek ne zaman güvenlidir? Eski makinede logların sessizleştiği ve yenisinde temiz logların olduğu bir iki haftanın ardından — bu gecikme sizin geri dönüş planınızdır ve birkaç dolara mal olur. İptal etmeden önce, dışarıdan hiçbir şeyin hâlâ eski IP'ye işaret etmediğini kontrol edin, üzerinde yaşamış her sırrı döndürün, sonra verinizi silin ve boş alanın üzerine yazın. İptali en sona bırakın. Önce sonlandırmaya basmak, veritabanınızı artık kontrol etmediğiniz bir diskte bırakır. İlgili rehberler ## Okumaya devam edin [### How için Seçin an Offshore Barındırma Yargı Alanı içinde 2026 Satın alma Offshore yargı alanı seçimi için pratik bir karar çerçevesi: veri saklama yasası, MLAT maruziyeti, DMCA tutumu, mahkeme hızı ve gerçek dünyadaki uygulama — ülke ülke. 6-soru FAQ](https://servhidden.com/tr/guides/choosing-an-offshore-jurisdiction) [### Gizlilik Açısından Kritik İş Yükleri için VPS vs Dedicated Sunucu Satın alma VPS'in yeterli olduğu, paylaşımlı kiracılığın bir zaafa dönüştüğü ve bare metal'in tek dürüst yanıt olduğu durumlar. Donanım yalıtımı, hypervisor riski ve tehdit modeline karşı maliyet. 6-soru FAQ](https://servhidden.com/tr/guides/vps-vs-dedicated-for-privacy) [### KYC'siz VPS Üzerinde Kendi Barındırmalı VPN: WireGuard vs OpenVPN Operasyonlar Kendi barındırmalı bir VPN neden ticari sağlayıcıları geride bırakır ve 2026'da WireGuard ile OpenVPN gizlilik, performans ve operasyonel risk açısından gerçekte nasıl karşılaştırılır. 6-soru FAQ](https://servhidden.com/tr/guides/self-hosted-vpn-wireguard-vs-openvpn) [### AI Çıkarımı için RTX 4090 vs H100 SXM5 (ve RTX 5090'ın Yeri) Satın alma Satın alma rehberi: 2026'da kendi barındırmalı LLM, görüntü, video, ses ve ince ayar iş yükleri için hangi NVIDIA GPU? RTX 4090 vs RTX 5090 vs H100 SXM5 vs çift H100 — VRAM, verim, $/token ve her birinin kazandığı durumlar. 6-soru FAQ](https://servhidden.com/tr/guides/rtx-4090-vs-h100-for-ai-inference) [### MT4 / MT5 / cTrader Forex İşlemleri için Offshore Windows RDP Operasyonlar Eksiksiz rehber: Forex ticareti için neden Windows RDP, düşük gecikmeli offshore yargı alanı nasıl seçilir, MT4 / MT5 / cTrader / Expert Advisor kurulumu, broker sunucularına gecikme ve KYC'siz ödeme akışı. 6-soru FAQ](https://servhidden.com/tr/guides/offshore-windows-rdp-for-forex-trading) [### DMCA-Görmezden Gelen Hosting Açıklandı: 2026'da Bu Gerçekte Ne Anlama Geliyor Satın alma "DMCA görmezden gelinen" hosting'in size gerçekte ne kazandırdığı, hangi yetki alanlarının bunu fiilen desteklediği, bu tür barındırmaya ihtiyaç duyan iş yükleri ve bu terimin kapsamadığı telif hakkı tuzakları. 6-soru FAQ](https://servhidden.com/tr/guides/dmca-ignored-hosting-explained) [### Kripto ile Anonim Alan Adı Kaydı: 2026'da WHOIS Gizliliği Gizlilik Kimliğinizi açıklamadan alan adı kaydetmeye yönelik 2026 pratik rehberi: TLD'ye göre WHOIS rejimleri, kayıt kuruluşu seçimi, kripto ödeme seçenekleri ve sizi ele veren operasyonel hatalar. 6-soru FAQ](https://servhidden.com/tr/guides/anonymous-domain-registration-with-crypto) [### Barındırma için Kripto Ödemeler: Monero vs Bitcoin vs USDT Gizlilik Ödeme coini, sağlayıcınızın hakkınızda ne öğrendiğini nasıl etkiler? XMR, BTC ve USDT için gizlilik, ücretler, kesinlik ve zincir analizi maruziyeti — net bir öneriyle. 6-soru FAQ](https://servhidden.com/tr/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Offshore Barındırma Gerçekten Anonim mi? Dürüst Bir Cevap Gizlilik KYC'siz offshore barındırma, normal bir sağlayıcının topladığı kimliği ortadan kaldırır — ancak „anonimlik” ödeme yönteminize, sağlayıcının tuttuğu loglara ve kendi opsec'inize bağlıdır. Gerçekte neyin izlenebilir olduğunu burada bulacaksınız. 6-soru FAQ](https://servhidden.com/tr/guides/is-offshore-hosting-truly-anonymous) [### VPS Sertleştirmenin İlk Saati: Bir Kontrol Listesi Operasyonlar Yeni bir VPS'i bir saatten kısa sürede güvenli hale getirmek için somut, sıralı bir kontrol listesi: SSH anahtarları, bir güvenlik duvarı, fail2ban, otomatik güncellemeler ve fırsatçı saldırıların çoğunu durduran saldırı yüzeyi küçültme. 6-soru FAQ](https://servhidden.com/tr/guides/first-hour-vps-hardening-checklist) [### KYC'siz Hosting Nedir? Tanım, Yasal Durum ve Nasıl Çalışır Gizlilik KYC'siz hosting, sıfır kimlik doğrulamasıyla — isim, e-posta veya kimlik belgesi olmaksızın — sunucu kiralamanıza olanak tanır. Bu terimin tam olarak ne anlama geldiğini, teknik olarak nasıl çalıştığını, yasal durumunu ve gerçek bir sağlayıcıyı nasıl seçeceğinizi burada bulabilirsiniz. 6-soru FAQ](https://servhidden.com/tr/guides/what-is-no-kyc-hosting) [### Offshore Hosting Yasal mı? 2026'nın Dürüst Cevabı Satın alma Offshore hosting yasaldır — hem sizin hem de sağlayıcının açısından. Bu terimin gerçekte ne anlama geldiğini, yasal sınırın tam olarak nerede çizildiğini, çürütülmesi gereken mitleri ve bu hizmeti sorumlu biçimde nasıl kullanacağınızı burada bulabilirsiniz. 6-soru FAQ](https://servhidden.com/tr/guides/is-offshore-hosting-legal) [### Monero (XMR) ile Hosting Nasıl Ödenir — Adım Adım Gizlilik Monero (XMR) ile VPS veya özel sunucu ödemesi yapmak için adım adım rehber: XMR neden en gizli ödeme seçeneğidir, nasıl edinilir ve ödeme süreci nasıl işler — faturadan birkaç dakika içinde çalışan bir sunucuya. 6-soru FAQ](https://servhidden.com/tr/guides/how-to-pay-for-hosting-with-monero) [### Bir Web Sitesini Anonim Olarak Nasıl Barındırırsınız — Pratik 2026 Rehberi Gizlilik Kimliğinizi açığa çıkarmadan bir web sitesi barındırmaya yönelik katmanlı, pratik bir rehber: hesap, ödeme, alan adı, yetki alanı, bağlantı ve içerik — her katman ayrı ayrı açıklanıyor. 6-soru FAQ](https://servhidden.com/tr/guides/how-to-host-a-website-anonymously) [### VPS Üzerinde WireGuard VPN Nasıl Kurulur — Adım Adım Rehber Operasyonlar WireGuard ile VPS'inizde kendi özel VPN'inizi kurun: kendi barındırdığınız bir VPN'in ticari alternatiflere neden üstün olduğunu, kurulumdan bağlı bir istemciye kadar tüm adımları ve nasıl güçlendireceğinizi öğrenin. 6-soru FAQ](https://servhidden.com/tr/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### GPU Sunucusunda LLM Kendi Kendine Nasıl Barındırılır — 2026 Rehberi Operasyonlar Kiralık bir GPU sunucusunda kendi büyük dil modelinizi çalıştırın: kendi kendine barındırmanın API'ye neden üstün olduğu, hangi GPU ve modeli seçeceğiniz, Ollama veya vLLM ile kurulum ve gerçek maliyetler. 6-soru FAQ](https://servhidden.com/tr/guides/self-host-an-llm-on-a-gpu-server) [### Bulletproof Hosting ve Offshore Hosting — Fark Nedir? Satın alma Bulletproof hosting ile offshore hosting sürekli birbiriyle karıştırılıyor — oysa aynı şey değiller. İşte gerçek fark, bu farkın neden önemli olduğu ve hangisini gerçekten istediğiniz. 6-soru FAQ](https://servhidden.com/tr/guides/bulletproof-vs-offshore-hosting) [### Bitcoin ile VPS Nasıl Satın Alınır — Adım Adım Rehber (2026) Satın alma Bitcoin ile VPS satın almaya yeni başlayanlar için hazırlanmış kapsamlı bir rehber: BTC edinme, plan seçme, faturayı ödeme ve ne elde edeceğiniz — kart ve kimlik bilgisi gerekmeden çalışan bir sunucu. 6-soru FAQ](https://servhidden.com/tr/guides/how-to-buy-a-vps-with-bitcoin) [### DMCA Dikkate Alınmayan Hosting İçin En İyi Ülkeler (2026) Satın alma ABD tarzı kaldırma taleplerinin kolayca ulaşamayacağı sunucularda barındırma yapmak isteyenler için: işe yarayan yargı bölgeleri, DMCA'nın görmezden gelinmesinin gerçekte ne anlama geldiği ve nasıl seçim yapılacağı. 6-soru FAQ](https://servhidden.com/tr/guides/best-countries-for-dmca-ignored-hosting) [### Tor Gizli Servisi (.onion Sitesi) Nasıl Barındırılır — 2026 Rehberi Operasyonlar VPS üzerinde bir Tor onion servisi kurun: gizli servis nedir, neden en güçlü anonim barındırma biçimidir, kurulumun tamamı ve gerçekten anonim kalmasını nasıl sağlarsınız. 6-soru FAQ](https://servhidden.com/tr/guides/how-to-host-a-tor-hidden-service) [### Offshore Posta Sunucusu Kurulumu — 2026'da Kendi Özel E-postanızı Barındırın Operasyonlar Offshore bir VPS üzerinde kendi özel posta sunucunuzu çalıştırın: neden e-postanızı kendiniz barındırmalısınız, ne gerekir, hepsi bir arada posta altyapısıyla gerçekçi kurulum ve iletilirliği nasıl sağlarsınız. 6-soru FAQ](https://servhidden.com/tr/guides/offshore-mail-server-setup) [### Kripto Node Barındırma Rehberi — VPS Üzerinde Bir Blokzincir Node'u Çalıştırın Operasyonlar Bir sunucuda blokzincir node'u nasıl barındırılır: kendi node'unuzu çalıştırmanın neden önemli olduğu, Bitcoin, Ethereum, Monero ve diğerleri için sunucu boyutlandırması, kurulum süreci ve gizliliği korumanın yolları. 6-soru FAQ](https://servhidden.com/tr/guides/crypto-node-hosting-guide) [### Stable Diffusion için GPU Hosting — Kendi Görsel Sunucunuzu Çalıştırın Operasyonlar Stable Diffusion'ı kendi GPU sunucunuzda çalıştırın: görsel üretimini neden kendiniz barındırmalısınız, hangi GPU'yu seçmelisiniz, web arayüzüyle kurulum ve barındırılan bir hizmete kıyasla maliyetler. 6-soru FAQ](https://servhidden.com/tr/guides/gpu-hosting-for-stable-diffusion) [### Sunucu OpSec — Sunucu İşletirken Anonim Kalma Gizlilik Anonim sunucu işleten herkes için operasyonel güvenlik: kimliği ifşa eden hatalar, bunları önleyen alışkanlıklar ve kimlikleri gerçek anlamda ayrı tutmanın yolları. 6-soru FAQ](https://servhidden.com/tr/guides/server-opsec-staying-anonymous) [### Seedbox Kurulum Rehberi — 2026'da Kendi Özel Seedbox'ınızı Oluşturun Operasyonlar Bir sunucuya kendi seedbox'ınızı nasıl kuracağınız: seedbox nedir, boyutlandırma, web arayüzlü torrent istemcisi kurulumu ve gizliliğinizi ile güvenliğinizi nasıl koruyacağınız. 6-soru FAQ](https://servhidden.com/tr/guides/seedbox-setup-guide) [### Kendi VPS'inizle DPI Sansürü Nasıl Aşılır (2026 Rehberi) Gizlilik VPN'iniz çalışmamaya mı başladı? Kendi VPS'inizle DPI sansürünü aşma rehberi: derin paket incelemesinin gerçekte ne tespit ettiği, 2026'nın beş protokolünden hangisinin hangi engellemeyi aştığı ve eksiksiz bir VLESS+REALITY kurulum anlatımı. 6-soru FAQ](https://servhidden.com/tr/guides/bypass-dpi-censorship-with-your-own-vps) [### VPS'te Tam Disk Şifreleme: LUKS Kurulumu ve Gerçekte Ne Koruduğu Operasyonlar VPS'i LUKS ile şifreleme: şifreli veri birimleri, SSH üzerinden uzaktan kilit açmalı tam kök şifreleme, küçük sunucularda önemli olan ayarlar ve disk şifrelemesinin gerçekte neyi durdurduğuna dair dürüst bir bakış. 8-soru FAQ](https://servhidden.com/tr/guides/full-disk-encryption-on-a-vps) [### Kaynak Sunucu IP'nizi Gizlemek: CDN, Ters Proxy ve Sızan Noktalar Gizlilik Offshore bir sunucunun önüne CDN koymalı mısınız: bunun neyi gizlediği, devraldığınız şikayet masası, kaynak IP'nin sızdığı altı yol ve sunucunuzu nasıl denetleyeceğiniz. 8-soru FAQ](https://servhidden.com/tr/guides/hiding-your-origin-server-ip) [### VPS Yedekleme Stratejisi: Şifreli, Uzak Sunucuda, Gerçekten Geri Yüklenebilir Operasyonlar Sağlayıcınız yedek tutmaz. Sunucuları gerçekte ne yok eder, push yedekler neden sunucuyla birlikte ölür, restic mi BorgBackup mı ve bir geri yüklemeyi nasıl test edersiniz. 8-soru FAQ](https://servhidden.com/tr/guides/vps-backup-strategy) [### Kendi Matrix Sunucunuzu Kurmak: Federasyon ve Metaveri Gerçeği Operasyonlar Kendi Matrix homeserver'ınızın gerçekte ne sağladığını öğrenin: Synapse mi Conduit mi, asla değiştiremeyeceğiniz server_name kararı ve diski dolduran medya. 8-soru FAQ](https://servhidden.com/tr/guides/self-host-a-matrix-server) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operasyonlar Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8-soru FAQ](https://servhidden.com/tr/guides/self-host-a-crypto-payment-gateway) ## Taşımaya inecek bir yer verin Yedi yargı alanında, aylık 7,50 $'dan başlayan, tam root erişimi, NVMe depolama ve ölçümsüz bant genişliğine sahip offshore KVM sunucular; bir kripto ödemesi onaylandığında beş dakikadan kısa sürede devreye alınır. Hedefi erkenden ayağa kaldırın, kendi hızınızda kopyalayın ve hazır olduğunda geçiş yapın. [VPS Paketlerini Gör](https://servhidden.com/tr/vps) [Offshore Barındırma](https://servhidden.com/tr/offshore-hosting) [All Lokasyonlar](https://servhidden.com/tr/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "7 offshore yargı alanında offshore VPS ve dedicated sunucular. KYC yok, log yok, yalnızca kripto. Gizlilik mimariyle sağlanır.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Web Sitesini Offshore Hosting'e Kesintisiz Taşıma", "description": "Bir sunucu taşımasını sıkıcı hale getiren sıralama: DNS TTL'yi günler önceden düşürün, iki sunucuyu paralel çalıştırın, yazmaları saatler değil dakikalar için dondurun — ve taşımanın geride bıraktığı pasif DNS, Certificate Transparency ve WHOIS izini temizleyin.", "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-29T00:00:00+00:00", "dateModified": "2026-08-29T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting", "inLanguage": "tr", "keywords": "web sitesi offshore hosting'e taşıma, kesintisiz sunucu taşıma, hosting sağlayıcısı değiştirme, VPS'i yeni sunucuya taşıma, DNS TTL geçişi, KYC'siz sunucuya taşınma, web sitesi taşıma kontrol listesi, rsync ile sunucu taşıma", "articleSection": "Operasyonlar", "wordCount": 3714 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Gerçekte ne kadar kesinti beklemeliyim?", "acceptedAnswer": { "@type": "Answer", "text": "Statik bir site için hiç — iki sunucu da aynı içeriği aynı anda sunabilir, bu yüzden DNS değişikliği görünmez bile olmaz. Veritabanı olan her şey için kesintiniz tam olarak yazma dondurmanızın uzunluğu kadardır; bu da önceden tam bir veri kopyası çalıştırdıysanız genellikle iki ile on dakika arasıdır. Önemli olan sayı DNS'in ne kadar hızlı taşındığı değildir; pencere sırasında ne kadar kopyaladığınızdır. Neredeyse her şeyi günler öncesinden kopyalayın, pencere de farkın boyutuna küçülsün." } }, { "@type": "Question", "name": "DNS yayılması ne kadar sürer?", "acceptedAnswer": { "@type": "Answer", "text": "Aslında bir “yayılma” yoktur — bu kelime gerçekleşmeyen bir şeyi tarif eder. Resolver'lar kaydınızı yalnızca TTL'nin söylediği süre kadar önbellekte tutar ve süresi dolunca tekrar sorar. Geçerli olan TTL 86400 ise, bazı resolver'lar eski IP'yi daha 24 saat boyunca sunmaya devam eder. TTL'yi geçişten en az bir tam eski-TTL süresi önce 300 saniyeye düşürün, internetin tamamı değişikliğinizi beş dakika içinde takip etsin." } }, { "@type": "Question", "name": "Alan adımı da taşımam gerekir mi?", "acceptedAnswer": { "@type": "Answer", "text": "Hayır. Kayıt şirketi ve sunucu tamamen birbirinden bağımsızdır, siteyi taşırken alan adını tam olduğu yerde bırakmak kusursuz şekilde çalışır. Taşımanız gerekip gerekmediği, taşınma sebebinize bağlıdır: sebep yargı alanı, fiyat ya da DMCA tutumuysa alan adına dokunmayın. Sebep anonimlikse, alan adının kendine ait ayrı bir geçmiş taşıdığını unutmayın — WHOIS arşivleri ilk hangi bilgilerle kaydedildiyse onu saklar, ve hosting değişiklikleri buna dokunmaz." } }, { "@type": "Question", "name": "Eski sağlayıcı nereye gittiğimi öğrenmeden taşınabilir miyim?", "acceptedAnswer": { "@type": "Answer", "text": "İki makine arasında doğrudan kopyalarsanız hayır — bir uç diğerine bağlanır ve her iki erişim logu da bunu kaydeder. Bu bağlantı tehdit modelinizde gerçekten önemliyse, hiç sunucudan sunucuya kopyalamayın: yeni sunucuyu kendi site dışı şifreli yedeğinizden geri yükleyin, böylece iki sağlayıcı hiçbir zaman paket alışverişi yapmaz. Ne olursa olsun, aktarımı sizi tanımlayan bir bağlantıdan asla başlatmayın ve hedefi eski sağlayıcıyla açtığınız herhangi bir destek talebinin dışında tutun." } }, { "@type": "Question", "name": "İşletim sistemini ya da yazılım yığınını aynı anda yükseltmeli miyim?", "acceptedAnswer": { "@type": "Answer", "text": "Hayır, ve bu en yaygın kendi kendine verilen taşıma hasarıdır. Tek bir şeyi değiştirin. Site geçişten sonra tuhaf davranırsa, yeni makine, yeni PHP sürümü ve yeni veritabanı ana sürümü arasında seçim yapmak yerine tek bir aday açıklama istersiniz. Eski ortamı sürüm sürüme eşleştirin, taşımayı tamamlayın, bir haftalık temiz logları doğrulayın, sonra geri dönme imkanınız varken ayrı olarak yükseltin." } }, { "@type": "Question", "name": "Taşınmak arama sıralamalarıma zarar verir mi?", "acceptedAnswer": { "@type": "Answer", "text": "Alan adı, URL'ler ve içerik aynı kaldığı sürece anlamlı bir zarar görmezsiniz — Google IP adreslerini değil URL'leri indeksler ve tek başına bir sunucu değişikliği bir sıralama sinyali değildir. URL yapısını aynen koruyun, aynı durum kodlarını döndürün ve taşımayı bir yeniden tasarımla ya da URL şeması değişikliğiyle birleştirmeyin. Bunun yerine yeni bir alan adına taşınıyorsanız, doğru 301 yönlendirmelerle bile geçici bir düşüş bekleyin ve bu yönlendirmelerin iki ismi de kamuya açık şekilde birbirine bağladığını bilin." } }, { "@type": "Question", "name": "TLS sertifikalarını yeniden çıkarmam gerekir mi?", "acceptedAnswer": { "@type": "Answer", "text": "Evet — yeni sunucunun kendi sertifikasına ve özel anahtarına ihtiyacı vardır, eski anahtarı ileri taşımak teknik olarak çalışsa bile kötü bir alışkanlıktır. Bunu geçişten önce, bir TXT kaydı üzerinden doğrulayan ve bu yüzden A kaydı hâlâ eski sunucuya işaret ederken de başarılı olan bir DNS-01 challenge kullanarak çıkarın. DNS değişikliğinden sonra HTTP-01'i beklemek, tam olarak korumaya çalıştığınız pencerede bir dizi sertifika uyarısını garantiler." } }, { "@type": "Question", "name": "Eski sunucuyu iptal etmek ne zaman güvenlidir?", "acceptedAnswer": { "@type": "Answer", "text": "Eski makinede logların sessizleştiği ve yenisinde temiz logların olduğu bir iki haftanın ardından — bu gecikme sizin geri dönüş planınızdır ve birkaç dolara mal olur. İptal etmeden önce, dışarıdan hiçbir şeyin hâlâ eski IP'ye işaret etmediğini kontrol edin, üzerinde yaşamış her sırrı döndürün, sonra verinizi silin ve boş alanın üzerine yazın. İptali en sona bırakın. Önce sonlandırmaya basmak, veritabanınızı artık kontrol etmediğiniz bir diskte bırakır." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Ana Sayfa", "item": "https://servhidden.com/tr/" }, { "@type": "ListItem", "position": 2, "name": "Gizlilik Barındırma Rehberler", "item": "https://servhidden.com/tr/guides" }, { "@type": "ListItem", "position": 3, "name": "Web Sitesini Offshore Hosting'e Kesintisiz Taşıma", "item": "https://servhidden.com/tr/guides/migrate-website-to-offshore-hosting" } ] } ```