RustDesk 'Hazır değil' hatası: kendi sunucunuzda çözüm

RustDesk "Hazır değil" mesajı neyi anlatır?

RustDesk'in durum çubuğundaki "Hazır değil. Bağlantınızı kontrol edin" mesajı, sizin istemcinizin ID sunucusuna kaydolamadığını söyler. Karşı bilgisayarın açık ya da kapalı olmasıyla ilgisi yoktur. Kendi VPS'inizde hbbs çalıştırıyorsanız sebep dört yerden birindedir: istemcideki sunucu adresi, hbbs konteynerinin durumu, yoldaki güvenlik duvarları ve alan adının çözüldüğü IP adresi.

Aşağıdaki kontroller en ucuzdan en zahmetliye doğru sıralıdır. İlk kontrol bir dakika sürer. Sonuncusu sağlayıcınızın paneline girmenizi gerektirebilir. Sunucuyu henüz kurmadıysanız önce RustDesk ID ve relay sunucusunu kendi VPS'inize kurma rehberini izleyin. Bu yazı o kurulumu ve oradaki sabitlenmiş Docker imaj etiketini temel alır. Kurulumu burada tekrar etmez.

Bu yazıdaki her komutu siz çalıştırırsınız: bir kısmını VPS'te, bir kısmını RustDesk'in kurulu olduğu bilgisayarda. Yalnızca sunucuya bakarak istemcinin sunucuya ulaşıp ulaşmadığını tam olarak göremezsiniz. Bu yüzden iki tarafa da bakmanız gerekir.

Durum çubuğu hangi bağlantıyı gösteriyor?

RustDesk sunucusu iki programdan oluşur. hbbs, ID sunucusudur. İngilizce belgelerde "rendezvous server", yani buluşma sunucusu olarak geçer. İstemciler ona kendi ID'lerini kaydeder ve bağlanmak istedikleri ID'yi ondan sorar. hbbr ise relay (aktarma) sunucusudur. İki bilgisayar birbirine doğrudan bağlanamadığında trafiği o taşır.

İstemci açık kaldığı sürece hbbs'e düzenli aralıklarla bir kayıt paketi gönderir. Bu paket varsayılan olarak UDP 21116 portuna gider. UDP (User Datagram Protocol, kullanıcı veri birimi protokolü), önce bağlantı kurmadan tek tek paket gönderen bir protokoldür. hbbs her kayıt paketine bir yanıt döner. İstemci yanıtın ne kadar sürede geldiğini ölçer ve bu değeri saklar. Değer sıfırdan büyük olduğu sürece durum çubuğu "Hazır" yazar.

Yanıt art arda birkaç kez gelmezse istemci saklanan değeri 0'a çeker ve durum çubuğu "Bağlanılıyor" yazar. Sessizlik daha uzun sürerse değer -1 olur. Durum çubuğu bu noktada "Hazır değil. Bağlantınızı kontrol edin" yazar. Aynı -1 değeri, arayüz kendi arka plan süreciyle konuşamadığında da oluşur. RustDesk'i tamamen kapatıp yeniden açmak bu ihtimali eler. Bunların hepsini RustDesk'in kaynak kodunda doğruladık: kayıt döngüsü src/rendezvous_mediator.rs dosyasında, durumun arayüze aktarıldığı yer src/ui_interface.rs dosyasındadır.

Sonuç şudur: bu mesaj, sizin bilgisayarınız ile hbbs arasındaki yolda bir sorun olduğunu söyler. Bağlanmak istediğiniz uzak bilgisayar bu yolun parçası değildir. Onu kontrol etmekle vakit kaybetmeyin.

Yanlış Key "Hazır değil" mi gösterir, "Anahtar uyumlu değil" mi?

Yanlış Key "Hazır değil" göstermez. hbbs, kayıt paketinde anahtar kontrolü yapmaz. Key alanı yanlış ya da boş olsa bile istemciniz kaydolur ve durum çubuğu "Hazır" yazar.

Anahtar, bir ID'ye bağlanmak istediğiniz anda kontrol edilir. Bağlantıyı başlatan istemci, karşı ID'yi hbbs'e sorarken Key alanındaki değeri de gönderir. hbbs bu değeri kendi anahtarıyla karşılaştırır. Eşleşmezse isteği reddeder ve istemci bir pencerede "Anahtar uyumlu değil" yazar. İngilizce arayüzde aynı mesaj "Key mismatch" olarak görünür. Güncel hbbs sürümleri bu durumda kendi günlüğüne invalid key ifadesini içeren bir uyarı satırı da yazar.

hbbs varsayılan olarak anahtar ister. Komut satırında -k seçeneği verilmezse kendi anahtar çiftini üretir ve yalnızca aynı genel anahtarı gönderen istemcileri kabul eder. Bu yüzden Key alanını boş bırakmak da bağlantı anında "Anahtar uyumlu değil" ile sonuçlanır.

Ekranda gördüğünüz mesajı şöyle okuyun:

• Hiçbir yere bağlanmaya çalışmadan durum çubuğunda "Hazır değil" görüyorsanız sorun kayıttadır. Aşağıdaki dört kontrolü sırayla yapın.
• Durum çubuğu "Hazır" diyor, bağlan düğmesine bastıktan sonra "Anahtar uyumlu değil" çıkıyorsa sorun Key alanındadır. Ağınız ve güvenlik duvarınız çalışıyor demektir.
• Bağlantı denemesinde "ID bulunamadı" çıkıyorsa sizin hbbs'iniz o ID'yi tanımıyor. Karşı bilgisayar büyük olasılıkla başka bir ID sunucusuna, örneğin RustDesk'in genel sunucularına kayıtlıdır.
• "Uzak masaüstü kapalı" çıkıyorsa hbbs o ID'yi tanıyor, ama karşı bilgisayar bir süredir kayıt göndermiyor. Bu yazıdaki kontrolleri o bilgisayarda yapın.

1. İstemci gerçekten sizin sunucunuzu mu gösteriyor?

En ucuz kontrol budur. RustDesk'te Ayarlar > Ağ bölümünü açın. Alanlar kilitliyse önce "Ağ Ayarlarını Aç" düğmesine basın. Windows bu adımda yönetici onayı isteyebilir. Ardından "ID/Relay Sunucusu" penceresindeki alanlara bakın. Etiketler Ekim 2026 itibarıyla güncel Türkçe arayüzdeki hâliyle yazılmıştır.

• ID Sunucu: VPS'inizin alan adı ya da IP adresi, örneğin rustdesk.ornek.com. Port yazmazsanız istemci 21116 kullanır.
• Relay Sunucu: resmi belgeler açık kaynak sunucu için bu alanı boş bırakmanızı önerir.
• API Sunucu: açık kaynak sunucuda boş kalır.
• Key: sunucunuzun genel anahtarı.

Alan adındaki tek bir harf hatası ya da eski bir IP adresi, tek başına "Hazır değil" mesajına yol açar. Değişikliği "Uygula" ile kaydedin ve durum çubuğunu bir süre izleyin.

Burada çok işe yarayan hızlı bir test var. ID Sunucu alanına alan adı yerine VPS'in IP adresini yazın. IP adresiyle "Hazır" oluyor ama alan adıyla olmuyorsa sorun DNS (Domain Name System, alan adı sistemi) kaydındadır. Doğrudan 4. adıma geçin.

Key değerini sunucudan alın. Resmi compose örneğinde olduğu gibi veri dizinini ./data olarak bağladıysanız, compose dosyasının bulunduğu dizinde şunu çalıştırın:

cat ./data/id_ed25519.pub
docker compose logs hbbs | grep Key

İki komut aynı değeri göstermelidir. İkincisi, hbbs'in açılışta yazdığı Key: satırını bulur. Değerin tamamını kopyalayıp istemcideki Key alanına yapıştırın.

2. hbbs konteyneri çalışıyor mu, sürekli yeniden mi başlıyor?

Compose dosyasının bulunduğu dizinde konteynerlerin durumuna ve hbbs günlüğünün son satırlarına bakın:

docker compose ps
docker compose logs --tail 50 hbbs

Sağlıklı bir hbbs için docker compose ps çıktısındaki STATUS sütunu Up ile başlar, örneğin Up 3 hours. Orada Restarting görüyorsanız program açılıp çöküyor demektir. restart: unless-stopped politikası onu yeniden başlatır ve döngü böyle sürer. Port bu sırada bir açılıp bir kapandığı için istemci çoğu zaman "Hazır değil" gösterir.

Sağlıklı bir açılışta günlükte birkaç tanıdık satır görürsünüz. Biri Listening on tcp/udp ile başlar ve 21116 ile biter. Bir başkası 21115 portunu ve extra port for NAT test ifadesini içerir. NAT (Network Address Translation, ağ adresi çevirisi), modeminizin evdeki cihazları tek bir genel IP arkasında toplamasıdır. RustDesk, NAT türünüzü bu port üzerinden ölçer. Son olarak Key: ile başlayan anahtar satırı gelir. Bu satırlar hiç yoksa ya da birkaç saniyede bir yeniden basılıyorsa hbbs açılamıyor demektir. Sebebi günlüğün son satırları söyler.

Olası sebeplerden biri, portu başka bir sürecin tutmasıdır. Örneğin aynı makinede daha önce elle kurulmuş bir hbbs servisi hâlâ çalışıyor olabilir. Portları kimin dinlediğine bakın:

sudo ss -tulpn | grep -E ':2111[5-8]'

Her port için tek bir dinleyen süreç görmelisiniz. Resmi örnekteki gibi network_mode: "host" kullanıyorsanız süreç adları hbbs ve hbbr olur. Port eşlemeli bir kurulumda docker-proxy görürsünüz. Aynı port için ikinci bir süreç varsa, o süreci durdurmadan hbbs açılamaz.

hbbr'nin durumu "Hazır" yazısını etkilemez, çünkü kayıt yalnızca hbbs ile yapılır. hbbr kapalıysa sorun ancak bir bağlantı relay üzerinden geçmek zorunda kaldığında ortaya çıkar. Yine de docker compose logs --tail 50 hbbr ile ona da bakın. Sunucu yeniden başladıktan sonra konteynerler kalkmıyorsa Docker Compose servislerinin açılışta otomatik başlaması yazısındaki kontrolleri yapın.

3. 21115, 21116 ve 21117 portları güvenlik duvarlarından geçiyor mu?

Kayıt paketi VPS'e ulaşmadan önce sağlayıcının ağ güvenlik duvarından geçer. VPS'e ulaştıktan sonra ise ufw ya da Docker'ın kendi kuralları devreye girer. Hangisinin paketi düşürdüğünü bulmak için önce paketin sunucuya ulaşıp ulaşmadığına bakın.

RustDesk açık kaynak sunucusunun ihtiyaç duyduğu portlar şunlardır:

• TCP 21115: hbbs, NAT türü testi.
• TCP ve UDP 21116: hbbs, ID kaydı ve kalp atışı (heartbeat) paketleri. Kayıt UDP ile gittiği için UDP kuralı eksikse "Hazır değil" görürsünüz.
• TCP 21117: hbbr, relay trafiği.
• TCP 21118 ve 21119: yalnızca web istemcisi için gerekir. Web istemcisini kullanmıyorsanız bunları açmayın.

Paket sunucuya ulaşıyor mu?

VPS'te tcpdump ile 21116 portunu dinleyin:

sudo apt install -y tcpdump
sudo tcpdump -ni any udp port 21116

Bu komut çalışırken istemci bilgisayarda RustDesk'i kapatıp yeniden açın. Çıktıyı şöyle okuyun:

• Hiç satır yoksa paket VPS'e hiç ulaşmıyor. İlk şüpheliler sağlayıcının güvenlik duvarı ve yanlış bir DNS kaydıdır. Kendi yerel ağınız da paketi daha çıkmadan engelliyor olabilir.
• İstemcinizin IP adresinden 21116 portuna gelen satırlar var, ama sunucudan geri giden satır yoksa paket ulaşıyor, yanıt çıkmıyor. Şüpheliler ufw ve hbbs'in kendisidir.
• İki yönde de satırlar varsa kayıt çalışıyor demektir. Bu durumda istemcideki ayarlara ve 4. adıma dönün.

tcpdump, gelen paketleri ağ arayüzünde ufw'den önce yakalar. Bu yüzden ufw'nin düşürdüğü bir paket burada yine de görünür. Çıkmak için Ctrl+C'ye basın.

ufw kuralları (host ağ modu)

Compose dosyanız resmi örnekteki gibi network_mode: "host" kullanıyorsa hbbs doğrudan VPS'in ağ arayüzünü dinler ve gelen paketler ufw'den geçer. Kuralları kontrol edip eksikleri ekleyin:

sudo ufw status verbose
sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp

ufw status verbose çıktısında 21116/udp için ALLOW IN satırı görmelisiniz. TCP kuralı olup UDP kuralı olmayan bir kurulum TCP testlerinden geçer, ama "Hazır değil" göstermeye devam eder. ufw henüz etkin değilse, etkinleştirmeden önce SSH portunu açmayı unutmayın. Kuralların mantığı için VPS'te ufw güvenlik duvarı temelleri yazısına bakın. ufw'nin dışında hangi kuralların etkin olduğunu görmek isterseniz Ubuntu'da etkin güvenlik duvarı kurallarını listeleme rehberi işinizi görür.

Docker port eşlemesi (ports: bölümü)

Host modu yerine ports: ile port yayınladıysanız durum farklıdır. Docker kendi iptables kurallarını yazar ve yayınlanan portlara gelen paketler ufw'nin giriş zincirine hiç uğramaz. Bu yüzden ufw status çıktısı bu portlar hakkında size doğru bilgi vermez. Mekanizmanın ayrıntısı Docker portlarının ufw kurallarını neden atladığı yazısında anlatılıyor.

Bu kurulumda en kolay gözden kaçan şey UDP eşlemesidir. Docker, protokol belirtilmeyen bir port eşlemesini yalnızca TCP olarak yayınlar. "21116:21116" satırı tek başına UDP'yi kapsamaz. hbbs servisinin port listesi en az şunları içermelidir:

    ports:
      - "21115:21115"
      - "21116:21116"
      - "21116:21116/udp"

image: satırına dokunmayın. Kurulum rehberindeki sabit etiket kalsın. Değişikliği docker compose up -d ile uygulayın ve UDP eşlemesini kontrol edin:

docker compose port --protocol udp hbbs 21116

Eşleme varsa komut 0.0.0.0:21116 gibi bir adres yazar.

Sağlayıcının ağ güvenlik duvarı

Birçok VPS sağlayıcısının panelinde, VPS'in içindeki ufw'den ayrı bir ağ güvenlik duvarı bulunur. Bu duvar paketi VPS'e ulaşmadan önce süzer. ufw'de açtığınız port orada kapalıysa, paket yine de içeri girmez. Kuralları TCP ve UDP için ayrı ayrı tanımlayın. tcpdump hiç satır göstermediyse ilk bakacağınız yer burasıdır.

TCP tarafını istemci bilgisayardan da test edebilirsiniz. Windows'ta PowerShell açın:

Test-NetConnection rustdesk.ornek.com -Port 21116

Çıktıda TcpTestSucceeded : True görmelisiniz. Linux ya da macOS'ta aynı testi nc ile yapın:

nc -vz rustdesk.ornek.com 21116

Bu iki test yalnızca TCP'yi doğrular. UDP için güvenilir test, yukarıdaki tcpdump denemesidir. Farklı araçlarla port testinin ayrıntıları Linux'ta bir portun açık olup olmadığını kontrol etme rehberinde var.

4. Alan adı sunucunun güncel IP adresine mi çözülüyor?

VPS'i taşıdıysanız ya da yeniden kurduysanız IP adresi değişmiş olabilir. DNS kaydı eski adresi göstermeye devam ederse istemci, artık size ait olmayan bir makineye kayıt göndermeye çalışır. Önce VPS'te sunucunun gerçek genel IP adresini öğrenin:

curl -4 https://ifconfig.me

Sonra aynı alan adını istemci bilgisayarda çözdürün. Windows'ta nslookup rustdesk.ornek.com komutunu kullanın. Linux ve macOS'ta şu komutu çalıştırın (Ubuntu'da dig yoksa dnsutils paketini kurun):

dig +short rustdesk.ornek.com

İki adres aynı olmalıdır. Farklıysa alan adı sağlayıcınızın panelinde A kaydını güncelleyin. Eski kayıt, TTL (time to live, kaydın önbellekte kalma süresi) dolana kadar bazı bilgisayarlarda yaşamaya devam eder. Windows'ta yerel önbelleği ipconfig /flushdns ile temizleyebilirsiniz.

Alan adınız Cloudflare'deyse bir duruma daha bakın. Kayıt proxy modundaysa, yani panelde turuncu bulut simgesi açıksa, alan adı sizin VPS'inize değil Cloudflare'in sunucularına çözülür. Cloudflare'in proxy'si yalnızca belirli web portlarını taşır. RustDesk'in 21116 portuna giden UDP paketleri oradan geçmez. Bu kayıt için proxy'yi kapatın ve kaydı "DNS only" (yalnızca DNS) moduna alın. Belirtisi şudur: dig çıktısındaki adres, VPS'te curl ile gördüğünüz adresten farklıdır.

Sorun sizin ağınızda mı? Mobil hotspot testi

Sunucu tarafındaki her şey doğru görünüyor ama "Hazır değil" mesajı yalnızca belirli bir ağda çıkıyorsa, sorunu ağ ile sunucu arasında ayırmanın en kolay yolu telefonunuzun mobil erişim noktasıdır (hotspot). Bilgisayarınızı Wi-Fi ağından ayırın, telefonunuzun hotspot'una bağlayın ve RustDesk'i yeniden açın.

• Hotspot'ta "Hazır" oluyorsa sunucunuz sağlamdır. Asıl ağınız 21115 ile 21117 arasındaki portlara giden trafiği engelliyor. Şirket, okul, yurt ve otel ağları standart dışı portlara giden trafiği sıkça kısıtlar. Ağ yöneticinizden giden TCP 21115-21117 ve UDP 21116 trafiğine izin vermesini isteyin.
• Hotspot'ta da "Hazır değil" görüyorsanız sorun sunucu tarafındadır. 3. ve 4. adımlara geri dönün.

Bu test, ağdaki hangi cihazın engellediğini söylemez. Yalnızca sorunun sizin tarafınızda mı, sunucu tarafında mı olduğunu ayırır. İnternet servis sağlayıcınızın RustDesk portlarını engellediğini varsaymadan önce bu testi mutlaka yapın.

Hangi belirti hangi adımı gösterir?

• IP adresiyle "Hazır", alan adıyla "Hazır değil": DNS kaydı ya da Cloudflare proxy'si, 4. adım.
• tcpdump hiç satır göstermiyor: sağlayıcının güvenlik duvarı ya da DNS. Hotspot testiyle yerel ağı da eleyin.
• tcpdump gelen paketleri gösteriyor, yanıt yok: ufw kuralı ya da hbbs'in kendisi, 2. ve 3. adımlar.
• docker compose ps çıktısında Restarting var: hbbs çöküyor, günlüğü okuyun.
• Durum "Hazır", bağlanınca "Anahtar uyumlu değil": Key alanı, 1. adım.
• Yalnızca bir ağda sorun var: hotspot testi.

Sunucunuz kayıtları sağlıklı biçimde aldıktan sonra RustDesk'i başka işler için de kullanabilirsiniz. VPS'in kendisine grafik bir masaüstüyle bağlanmak istiyorsanız Linux VPS üzerinde uzak masaüstü kurma rehberine bakın.

Sık sorulan sorular (FAQ)

RustDesk "Hazır değil" diyor ama karşı bilgisayar açık. Sorun onda mı?

Hayır. "Hazır değil. Bağlantınızı kontrol edin" mesajı, sizin istemcinizin ID sunucusuna (hbbs) kaydolamadığını gösterir. İstemci varsayılan olarak UDP 21116 portuna kayıt paketi gönderir ve bir süre yanıt alamazsa bu mesajı yazar. Karşı bilgisayar bu yolun parçası değildir. İstemcideki ID Sunucu alanını, hbbs konteynerini, 21115 ile 21117 arasındaki portları ve alan adının çözüldüğü IP adresini kontrol edin.

RustDesk'te yanlış Key girersem hangi hatayı görürüm?

Yanlış ya da boş bir Key, durum çubuğunu etkilemez. İstemci yine kaydolur ve "Hazır" yazar. Hata, bir ID'ye bağlanmaya çalıştığınızda bir pencerede "Anahtar uyumlu değil" (İngilizcede "Key mismatch") olarak çıkar, çünkü hbbs anahtarı kayıt sırasında değil bağlantı isteği sırasında kontrol eder. Doğru değeri sunucuda cat ./data/id_ed25519.pub ile ya da hbbs günlüğündeki Key: satırından alın.

RustDesk sunucusu için TCP 21116'yı açmak yeterli mi?

Hayır. hbbs, 21116 portunu hem TCP hem UDP için kullanır ve istemcinin kayıt paketleri varsayılan olarak UDP ile gider. Yalnızca TCP kuralı varsa Test-NetConnection ya da nc testi başarılı görünür, ama istemci "Hazır değil" göstermeye devam eder. ufw'de 21116/udp kuralını ekleyin. Docker'da ports: kullanıyorsanız "21116:21116/udp" satırını ayrıca yazın.

RustDesk evde "Hazır", işyerinde "Hazır değil". Neden?

Sunucunuz evden çalıştığına göre sağlamdır. İşyeri ağı büyük olasılıkla standart dışı portlara giden trafiği kısıtlıyor. Bunu doğrulamak için işyerindeki bilgisayarı telefonunuzun mobil hotspot'una bağlayın. Orada "Hazır" oluyorsa ağ yöneticinizden giden TCP 21115-21117 ve UDP 21116 trafiğine izin vermesini isteyin.