Skip to content
Tenvo AI · CANLI · v0.16.2 · TLS · Aygıt başına sertifikalar · AGPL-3.0 · ÜCRETSİZ SEVİYE · 30 CİHAZ · KENDİ SUNUCUNDA BARINDIRILABİLİR ALTYAPI · BYO API KEY · MCP CLAUDE & CURSOR İÇİN
Bloga geri dönTutorial

Uzaktan Masaüstü Sürekli Bağlantı Kesiliyorsa Ne Yapmalı

Tenvo Editorial Team10 dk okuma
Uzaktan Masaüstü Sürekli Bağlantı Kesiliyorsa Ne Yapmalı

Bir dosya üzerinde çalışıyorsunuz, imleç birkaç saniye donuyor ve sonra oturum kopuyor — yine. Kesik kesik bağlantılar, işi kesintiye uğrattıkları, yeniden bağlanmaya zaman kaybettirdikleri ve gerçek nedeni gizleyebildikleri için uzak erişimdeki en sinir bozucu sorundur.

Bir dosya üzerinde çalışıyorsunuz, imleç birkaç saniyeliğine donuyor ve sonra oturum yeniden kopuyor — yine. Aralıklı bağlantı kesilmeleri en sinir bozucu uzaktan erişim sorunudur; işi böler, yeniden bağlanmaya zaman kaybettirir ve gerçek nedeni gizleyebilir. Bu kılavuz, uzaktan masaüstünüzün neden sürekli koptuğunu bulmak (ve düzeltmek) için hemen çalıştırabileceğiniz pratik, teknik bir üçleme adımı sunar.

Bu işe nasıl yaklaşmalı: hata alanını daraltın

Problemi kapsamlandırarak başlayın. Rastgele kopmaların birkaç temel nedeni vardır: ağ kararsızlığı, aradaki kutular (NAT, güvenlik duvarları, proxy'ler), ana bilgisayar kaynak veya güç yönetimi veya broker/servis katmanı. En hızlı çözüm yolu üç soruya cevap bulmaktır:

  • Problem tek bir istemcide mi, tek bir host'ta mı yoksa her ikisinde mi oluyor?
  • Sadece yerel LAN'da mı, sadece İnternet üzerinden mi yoksa her iki yerde mi gerçekleşiyor?
  • Her N dakikada tekrar eden bir düzenlilik var mı yoksa gerçekten rastgele mi?

Örnek üçleme sonuçları ve işaret ettikleri:

  • Sadece bir istemci makineden kopmalar — muhtemelen istemci tarafı güç, güvenlik duvarı veya yazılım sorunu.
  • Tüm istemcilerden tek bir host'a kopmalar — muhtemelen host tarafı güç yönetimi, anti-virüs veya ağ adaptörü ayarları.
  • Sadece İnternet üzerinden kopmalar, LAN'da değil — muhtemelen ISS/NAT/yönlendirici veya broker sorunları.

Hızlı kontrol listesi: 15 dakikada elenebilenler

Derin teşhise başlamadan önce bu kısa kontrol listesini çalıştırın. Bu adımlar birçok yaygın nedeni düzeltir ve bir sonraki aşama için faydalı veri toplamanıza yardımcı olur.

  1. Yeniden üretme ve zamanlamayı not etme: kontrollü bir oturum başlatın ve tekrarlanabilir davranışı gözleyin. Oturum X saniye/dakika sonra mı kopuyor?
  2. Ağları değiştirin: istemciyi farklı bir ağa bağlayın (mobil hotspot, kablolu Ethernet) ve problemin istemciye mi taşındığını kontrol edin.
  3. Mümkünse her iki uç için de kablolu Ethernet kullanın — Wi‑Fi sık sık suçludur.
  4. Her iki uçta da güç tasarrufunu geçici olarak devre dışı bırakın (Wi‑Fi güç tasarrufu kapalı, Windows Güç Planı Yüksek Performans).
  5. VPN ve üçüncü taraf güvenlik duvarlarını kısa süreliğine devre dışı bırakıp test edin.
  6. Broker tabanlı bir ürün kullanıyorsanız (TeamViewer, AnyDesk, Tenvo broker), doğrudan LAN bağlantısını deneyin — seçenekler için Port yönlendirmesi olmadan Remote Desktop: nasıl çalışır yazısını inceleyin.

Ağ teşhisi: karıştırmadan önce ölçün

Hızlı kontrol listesi sorunu çözmediyse, ağ sağlığını ölçün. Aradığınızlar gecikme sıçramaları, jitter veya paket kaybıdır — bunların herhangi biri uzak oturumu bozabilir.

Yararlı araçlar ve kontroller (istemci ve host):

  • ping: Windows'ta ping -t <host>, Linux/macOS'ta ping <host> çalıştırın ve sıçramalara veya paket kaybına bakın. Süregelen paket kaybı >1% uyarı işaretidir; >3–5% görünür problemlere veya kopmalara neden olur.
  • mtr veya tracert: mtr <host> (Linux/macOS) veya traceroute/tracert kullanarak kaybın nerede başladığını bulun. Kayıp ağ geçidinizde başlıyorsa yönlendirici veya ISS muhtemel hata kaynağıdır.
  • iperf3: Bilinen sağlam ağlarda iki uç arasında iperf3 çalıştırarak bant genişliği, jitter ve paket kaybını ölçün. Örnek: sunucuda iperf3 -s, istemcide iperf3 -c <server> -t 60.
  • Wi‑Fi teşhisleri: Windows'ta netsh wlan show interfaces ile RSSI'yi kontrol edin. macOS'ta Option tuşuna basıp Wi‑Fi'ye tıklayarak Tx hızları ve gürültüyü görün. AP'ye yaklaşın veya kanal sıkışıklığı yüksekse 5 GHz'e geçin.

Yorumlama rehberi:

  • Gecikme: kısa oturumlar 50 ms'nin altında gecikmeyi tolere edebilir; gecikme tutarlı olarak 100–150 ms'nin üzerinde ise bağlantı fragil hale gelir, özellikle UDP özellikleri veya gerçek zamanlı ekran güncellemeleri için.
  • Paket kaybı: küçük ama sürekli kayıp (1–3%) bile yeniden iletimlere ve donmalara yol açar. Ani kayıp patlamaları (burst) özellikle yıkıcıdır.
  • Jitter: yüksek jitter (değişken gecikme) aralıklı donmalar olarak görünür ve genellikle aşırı yüklü Wi‑Fi, CPU kıtlığı veya yoğun bir uplink nedeniyle olur.

Aradaki kutular ve NAT: en yaygın görünmez suçlular

NAT cihazları, ev/ofis yönlendiricileri ve ISS ekipmanı genellikle boşta kalan UDP veya TCP durumlarını onlarca saniye ila birkaç dakika sonra sonlandırır. Eğer uzak masaüstü protokolünüz UDP kullanıyorsa (birçok modern istemci kullanır), NAT zaman aşımı yolu kesebilir ve yeniden bağlantıya zorlayabilir.

Kontrol edilmesi gerekenler:

  • NAT & TCP zaman aşımı: birçok tüketici yönlendiricisi 30–60 saniye etkin olmayan UDP eşlemelerini düşürür. TCP durum zaman aşımı değişkendir; bazı agresif yönlendiriciler veya güvenlik duvarı cihazları 30–120 saniye arasında boşta TCP'yi kapatabilir. Uygulamanız uzun ömürlü UDP'ye uygulama seviyesinde keepalive göndermiyorsa, her 15–30 saniyede bir gönderin.
  • UPnP ve port yönlendirme: yönlendiriciye erişiminiz varsa host için statik port-yönlendirme ayarlayarak broker'sız, doğrudan bağlantıları mümkün kılabilirsiniz. Yapamıyorsanız, broker tabanlı servisler NAT'leri aşabilir ama kendi relay/broker erişilebilirliklerine bağlıdır. Port yönlendirmesi olmadan Remote Desktop: nasıl çalışır yazısı bu takasları açıklar.
  • Carrier-Grade NAT (CGNAT): mobil ve bazı geniş bant ISS'leri CGNAT kullanır; bu doğrudan gelen bağlantıları engeller. Kopmalar mobil ağlarla veya belirli ISS'lerle ilişkiliyse CGNAT veya asimetrik yönlendirme etkili olabilir.

Pratik testler:

  • İstemciden STUN-benzeri testler yapın (WebRTC tabanlı brokerler için) veya host'un uzak portta doğrudan bir TCP bağlantısına yanıt verip vermediğini kontrol edin (telnet <host> <port> veya nc -vz <host> <port>).
  • Uygulamanızda geçici olarak bir relay veya broker seçeneğini etkinleştirip kararlılığı karşılaştırın. Brokerlı oturumlar stabilken doğrudan oturumlar başarısız oluyorsa sorun büyük olasılıkla NAT/yönlendirici veya ISS seviyesindedir.

Host ve istemci ayarları: güç, sürücüler ve CPU kıtlığı

Ağ sorunları elendikten sonra makinelerin kendilerini kontrol edin. Olağan şüpheliler güç tasarrufu özellikleri, hatalı NIC sürücüleri, CPU veya bellek baskısı ve oturumu etkileyen arka plan yazılımlarıdır.

  • Güç yönetimi: Windows'ta güç planını Yüksek Performans'a ayarlayın ve USB ile Wi‑Fi adaptörü için selective suspend'i devre dışı bırakın (Aygıt Yöneticisi → Network adapters → Properties → Power Management → 'Allow the computer to turn off this device to save power' seçeneğinin işaretini kaldırın). macOS'ta App Nap'i devre dışı bırakın ve oturum sırasında sistemin uyumamasını sağlayın (System Settings → Battery veya Energy Saver).
  • GPU/sürücü sorunları: uzak masaüstü istemcileri sıklıkla GPU kodlama/dekodlama kullanır. GPU sürücülerini (NVIDIA/Intel/AMD) üreticinin en son kararlı sürümüne güncelleyin. GPU kodlama sorunundan şüpheleniyorsanız istemci veya sunucuda donanım hızlandırmayı geçici olarak devre dışı bırakıp test edin.
  • Antivirüs/ağ güvenlik ajanları: kurumsal uç nokta güvenliği sürücüler enjekte edebilir veya trafiği filtreleyebilir. AV'yi duraklatıp geçici olarak bir ağ filtresini kaldırıp test edin. IT'ye yükseltmeniz gerekiyorsa yapılan değişiklikleri belgeleyin.
  • CPU & bellek: host'ta Task Manager (Windows) veya top/htop (Linux) ile ani yüklenmelere bakın. Host CPU ile sınırlanıyorsa ekran yakalama kodlaması gecikebilir ve zaman aşımına neden olabilir.

Protokole özel notlar: RDP, VNC ve broker'lı istemciler

Farklı uzak protokoller baskı altında farklı davranır. Protokole özel birkaç ipucu:

  • RDP (Windows): eski RDP TCP üstünden sıralama bozulmasına karşı dayanıklıdır ama kurtarması yavaştır. Yeni RDP (8.0 sonrası) daha iyi interaktivite için UDP kullanabilir ancak paket kaybına duyarlıdır. RDP kopmaları varsa Grup İlkesi veya sunucu tarafı ayarlarını idle zaman aşımı ve UDP güvenilirliği açısından kontrol edin. Yaygın bir sunucu tarafı ayarı 'Keep-Alive' ve oturumları N dakikadan sonra sonlandıran politikalardır — Remote Desktop Session Host ayarlarınızı doğrulayın.
  • VNC: birçok VNC çeşidi şifrelenmemiş TCP tünelleri kullanır ve NAT zaman aşımına hassastır. VNC'yi bir tünel (SSH) üzerinden kullanıyorsanız tünelin keepalive aralığını kontrol edin.
  • Broker'lı istemciler (TeamViewer, AnyDesk, Tenvo, vb.): bu istemciler NAT'i aşmaya yardımcı olmak için bir broker kullanır. ISP'ler arasında daha stabil olabilirler ama broker'ün çalışma süresine bağımlıdırlar. Ağ genelindeki kesintilerle aynı zamana rastlayan kopmalar görüyorsanız broker'ın durum sayfalarını kontrol edin veya mümkünse doğrudan LAN bağlantısını deneyin. Self-hosted seçenekler için Kendi Barındırılan Uzaktan Masaüstü: Neden ve Nasıl rehberimizi inceleyin.

Yükseltmeden önce yararlı günlükleri toplayın

IT veya satıcı desteğine ihtiyaç duyduğunuzda günlükler ve ölçümler sağlayın — bunlar zaman kazandırır. Toplanacaklar:

  • İstemci ve sunucu günlükleri: uzak istemcinizde ayrıntılı veya hata ayıklama günlüğünü etkinleştirip bir başarısızlığı kapsayan günlükleri toplayın. Konum uygulamaya göre değişir; Tenvo için Help → Show Logs veya yükleme dizinini kontrol edin (zaman damgalarını ekleyin).
  • Ağ izleri: kopma sırasında bir paket izini yakalayın (Wireshark veya tcpdump). Kopmanın ortasına denk gelen 60–120 saniyelik bir yakalama genellikle yeterlidir. Tekrarlayan yeniden iletimleri, ICMP 'destination unreachable' veya ani RST/FIN paketlerini arayın.
  • Ping/MTR günlükleri: mtr -r -c 100 <host> veya ping -D <host> çalıştırıp çıktıyı kaydedin. Yol belirli bir hop'ta kayıp gösteriyorsa bu ayrıntıyı ekleyin.
  • Sistem teşhisleri: CPU/Bellek grafikler, Güç ayarları ekran görüntüleri ve NIC sürücü sürümleri. Windows'ta sürücüleri listelemek için driverquery /v çalıştırın. Linux'ta lsmod ve dmesg faydalıdır.

Sık işe yarayan pratik düzeltmeler

Ölçümleri aldıktan ve günlükleri topladıktan sonra, müdahalesi az olandan kalıcı olana doğru şu düzeltmeleri deneyin:

  • Uygulama seviyesinde keepalive'leri etkinleştirin: uzak istemci veya sunucuyu her 15–30 saniyede bir keepalive gönderecek şekilde yapılandırın. Bu, birçok NAT ve yönlendiricinin eşlemeyi düşürmesini önler.
  • Kablolu Ethernet veya daha az yoğun bir Wi‑Fi bandı (5 GHz) kullanın.
  • Her iki uçta da NIC ve Wi‑Fi adaptörlerinde güç tasarrufu özelliklerini devre dışı bırakın.
  • Ağ sürücülerini ve uzak istemciyi en son kararlı sürüme güncelleyin. Yeni güncelleme sorunla eşzamanlı ise, satıcı gerilemeyi düzeltinceye kadar önceki sürümü deneyin.
  • Taşıma protokolünü değiştirin: bazı istemciler TCP-only zorlamaya veya UDP geri düşmesine izin verir. UDP sorunluyse TCP'yi zorlayın; TCP tıkanıyorsa daha iyi gecikme kurtarması için UDP'yi etkinleştirmeyi deneyin.
  • Ortamınız izin veriyorsa host üzerinde statik port-yönlendirme ayarlayıp doğrudan bağlantılar için sabit bir port kullanın. Bu, broker bağımlı hata modlarını ortadan kaldırır ancak dikkatli güvenlik (güvenlik duvarı + güçlü kimlik doğrulama) gerektirir. Yapılandırma için Port yönlendirmesi olmadan Remote Desktop: nasıl çalışır kılavuzuna bakın.

Self-hosting veya mimari değişikliği ne zaman düşünmeli

Kuruluşunuz tutarlı, profesyonel düzeyde erişilebilirlik gerektiriyorsa ve broker veya ISS kaynaklı sınırlara sıkça takılıyorsanız, self-hosted veya hibrit bir mimariyi düşünün. Broker'ünüzü kendiniz host etmek veya bir on-prem relay seçmek üçüncü taraf kesintilerini azaltır ve NAT geçiş politikaları ile keepalive davranışı üzerinde kontrol sağlar.

Takaslar:

  • Self-hosted broker'lar üçüncü taraf bağımlılığını azaltır ve dahili kullanıcılar için kararlılığı ciddi şekilde iyileştirebilir; fakat sunucu bakımı ve açık bir genel uç noktaya ihtiyaç vardır, eğer iç-dahili bir çözüm kullanmıyorsanız.
  • Hibrit modeller (kurumsal kullanıcılar için self-hosted relay, harici kullanıcılar için broker) esneklik sağlar. Seçenekleri Kendi Barındırılan Uzaktan Masaüstü: Neden ve Nasıl rehberimizde ve Uzaktan Erişimi 60 Saniyede Nasıl Kurulur'da adım adım ele alıyoruz.

Rakipler ve dürüst sınırlar

TeamViewer ve AnyDesk gibi ürünler kolay NAT geçişi ve relay geri-düşmeleri sağlar; broker tabanlı modelleri müşteri ağları arasında daha dirençli olabilir. Bu kolaylık tercih nedeni olabilir. Ancak herhangi bir merkezi broker tek bir bağımlılık noktasıdır — hizmetleri veya bölgesel bir relay düşerse oturumlar kopar. Önceliğiniz öngörülebilirlik ve kontrolse self-hosting veya doğrudan-LAN-öncelikli strateji daha iyidir.

Tenvo esneklik sağlayacak şekilde tasarlanmıştır: kolaylık için brokerlı bağlantıları ve kararlılık/kontrol için doğrudan LAN/self-hosted seçeneklerini destekler. Kritik kullanıcılar için broker bağımlılığını azaltmak istiyorsanız bir self-hosted relay veya doğrudan port-yönlendirmesi düşünün — indirmeler Tenvo'nun /download sayfasında; hosted vs self-hosted değerlendirmesi için /pricing ve Kendi Barındırılan Uzaktan Masaüstü: Neden ve Nasıl rehberimizde daha fazla bilgi bulabilirsiniz.

IT veya satıcı desteğine ne zaman yükseltmeli

Yukarıdaki teşhisleri çalıştırdıysanız ve hâlâ açıklanamayan kopmalar görüyorsanız, topladığınız verilerle yükseltin. Sağlayın:

  • Arızaların tam zaman damgaları ve ilgili ping/mtr günlükleri.
  • İstemci ve sunucu günlük paketleri ve arızayı kapsayan kısa bir paket yakalama (pcap).
  • Ağ topolojisi: ISS'ler, yönlendirici marka/model ve firmware, NAT veya CGNAT olup olmadığı ve kullanıcıların Wi‑Fi mı yoksa kablolu mı olduğu.

Satıcılar bu eserleri arka uç olaylarıyla ilişkilendirmek veya protokol düzeyindeki hataları tespit etmek için ister. Tenvo kullanıyorsanız destek için Help → Show Logs'tan alınan günlükleri ve pcap bağlantısını ekleyin; diğer satıcıları kullanıyorsanız onların destek portalı talimatlarını izleyin. Genel mimari yardımı için Uzaktan Erişimi 60 Saniyede Nasıl Kurulur ve Uzaktan Masaüstü Güvenliği: Bilmeniz Gerekenler makalelerimiz, yükseltmeden önce konuşmayı şekillendirmenize yardımcı olur.

Özet kontrol listesi — şimdi ne denemelisiniz

  1. Çoğaltmak için kablolu veya alternatif ağa geçin.
  2. Güç tasarrufunu devre dışı bırakın ve NIC sürücülerini güncelleyin.
  3. ping/mtr çalıştırıp çıktıyı kaydedin; mümkünse iperf3 çalıştırın.
  4. Keepalive'leri etkinleştirin veya keepalive aralığını 15–30s aralığına düşürün.
  5. Geçici olarak bağlantıyı broker'layın (veya broker'dan çıkarın) ve hangi yolun stabil olduğunu görün.
  6. Günlükleri toplayın (istemci/sunucu/pcap) ve bu verilerle yükseltin.

Aralıklı kopmalar can sıkıcıdır ama genellikle sistematik ölçümler ve birkaç hedefli değişiklikle çözülebilir — çoğunlukla Wi‑Fi, NAT zaman aşımı, güç ayarları veya keepalive yapılandırmasının düzeltilmesi yeterlidir.

Bu üçleme sürecini kolaylaştıran ve hem brokerlı hem de doğrudan LAN/self-hosted modlarını destekleyen bir uzak istemci arıyorsanız Tenvo'yu indirip doğrudan bağlantıyı önce deneyin. Uygulamayı /download adresinden alın; kararlılık için hosted vs self-hosted değerlendiriyorsanız /pricing ve Kendi Barındırılan Uzaktan Masaüstü: Neden ve Nasıl rehberimize bakın.

Tenvo edinin

Kendiniz denemeye hazır mısınız?

30 cihaza kadar ücretsiz, kredi kartı gerekmiyor. İki dakikada kurulur ve bağlanır.