Skip to content
Back to BlogGuide

Samodzielnie hostowany pulpit zdalny: pełny przewodnik 2026 (RustDesk + GoDesk Relay)

GoDesk Editorial Team12 min czytania
Samodzielnie hostowany pulpit zdalny: pełny przewodnik 2026 (RustDesk + GoDesk Relay)

Chcesz pulpit zdalny, w którym ruch nigdy nie przechodzi przez serwery dostawcy? Ten przewodnik pokazuje, jak samodzielnie hostować relay end-to-end na VPS za $5/month — co zainstalować, jak go zabezpieczyć i jak poradzić sobie z trybami awarii, które dokumentacja pomija.

Dla większości użytkowników relay hostowany przez dostawcę (TeamViewer, AnyDesk, GoDesk) jest wystarczający. Szyfrowanie end-to-end oznacza, że relay widzi jedynie szyfrogram — nie może odczytać klatek ekranu, naciśnięć klawiszy ani plików. Ale "wystarczający" nie znaczy "idealny", jeśli masz jedno z poniższych ograniczeń:

  • Zgodność (compliance): branża regulowana, w której dane nie mogą przechodzić przez infrastrukturę stron trzecich (prawo, obronność, niektóre obszary opieki zdrowotnej).
  • Suwerenność: nie chcesz, aby metadane dostępu zdalnego (kto połączył się z czym, kiedy, jak długo) były gromadzone przez kogokolwiek.
  • Koszt w skali: jeśli prowadzisz >100 urządzeń przez relay, opłaty dostawcy rosną — self-hosted relay na VPS za $5/month obsłuży tysiące sesji.
  • Sieci odcięte/ograniczone: relay dostawcy nie jest osiągalny z twojego środowiska.

Jeśli któryś z powyższych Cię dotyczy, ten przewodnik pokazuje, jak samodzielnie hostować relay end-to-end na prostym VPS. Referencyjny stos to hbbs + hbbr z RustDesk, do których mogą łączyć się zarówno klienci GoDesk, jak i RustDesk. Całkowity czas konfiguracji: około 30 minut, wliczając TLS.

Co budujesz

Dwie usługi:

  • hbbs (rendezvous server): obsługuje początkowy handshake. Oba klienty łączą się z nim krótko, by odnaleźć się nawzajem, wymienić klucze publiczne i sprawdzić, czy bezpośrednie P2P jest możliwe. Nasłuchuje na TCP/UDP 21115-21117.
  • hbbr (relay server): jeśli bezpośrednie P2P zawiedzie (NAT, firewall), ruch przechodzi przez relay. Nasłuchuje na TCP 21117 (oraz UDP w niektórych scenariuszach).

Relay włącza się tylko, gdy P2P nie działa — co dotyczy większości scenariuszy konsumenckich z powodu NAT, ale rzadko ma miejsca w sieci lokalnej. Nawet przy self-hosted relay płacisz za przepustowość VPS tylko dla sesji, które jej rzeczywiście potrzebują.

Krok 1: Wybierz VPS

Przepustowość jest głównym zasobem. CPU i RAM są minimalne (relay jedynie przekazuje bajty). Rozsądne wybory w 2026:

  • Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, centra danych w UE) — najlepszy stosunek ceny do przepustowości.
  • DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — dobra użyteczność, regiony US/EU.
  • OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, transfer bez limitu) — najlepsze rozwiązanie dla scenariuszy o dużym zapotrzebowaniu na przepustowość.
  • Hetzner Storage Box — TO NIE JEST VPS; pojawia się tu, bo czytelnicy o to pytają. Nie zadziała dla tego celu; potrzebujesz rzeczywistego serwera.

Wybierz region blisko lokalizacji klientów — ma to znaczenie dla opóźnień, ponieważ ruch przez relay jest ograniczony przez czas w obie strony.

Krok 2: Skonfiguruj serwer

Uruchom świeży VPS z Ubuntu 22.04 lub Debian 12. Zaloguj się przez SSH jako root.

# Update + harden basics
apt update && apt upgrade -y
apt install -y ufw fail2ban docker.io docker-compose-plugin
ufw allow 22/tcp     # SSH
ufw allow 21115:21119/tcp
ufw allow 21115:21119/udp
ufw enable
systemctl enable --now docker

Nie pomijaj firewalla. Domyślna konfiguracja RustDesk otwiera tylko potrzebne porty; resztę należy zablokować.

Krok 3: Uruchom hbbs + hbbr przez Docker

Utwórz plik /opt/godesk-relay/docker-compose.yml:

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"
      - "21116:21116/tcp"
      - "21116:21116/udp"
      - "21118:21118/tcp"
    command: hbbs -r your-server.example.com:21117
    volumes:
      - ./data:/root
  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbr
    restart: unless-stopped
    ports:
      - "21117:21117/tcp"
      - "21119:21119/tcp"
    command: hbbr
    volumes:
      - ./data:/root

Zamień your-server.example.com na rzeczywistą nazwę hosta. Uruchom:

cd /opt/godesk-relay
mkdir -p data
docker compose up -d
docker compose logs --tail 20

Powinieneś zobaczyć, że hbbs wypisuje klucz publiczny przy pierwszym uruchomieniu — zapisz go z logów (id_ed25519.pub w wolumenie data), ponieważ klienci używają go do weryfikacji, że łączą się z TWOIM relay, a nie z atakiem typu MITM.

Krok 4: Skonfiguruj DNS

Wskaż rekord A dla relay.yourdomain.com na adres IP VPS. RustDesk akceptuje też bezpośrednio adres IP, ale nazwa hosta daje większą elastyczność przy migracji.

Krok 5: Skieruj klientów na samodzielnie hostowany relay

To część, którą większość przewodników pomija. Każdy klient potrzebuje trzech wartości konfiguracyjnych:

  • Serwer ID = relay.yourdomain.com:21116
  • Serwer relay = relay.yourdomain.com:21117
  • Klucz publiczny = zawartość pliku data/id_ed25519.pub z Twojego VPS

Na Windows / macOS / Linux:

  1. Otwórz klienta GoDesk lub RustDesk.
  2. Settings → Network → ID/Relay server.
  3. Wprowadź powyższe trzy wartości. Zapisz.
  4. Uruchom ponownie klienta.

Wskaźnik stanu powinien zmienić się na zielony w ciągu kilku sekund, pokazując rejestrację w Twoim relay. Jeśli pozostaje czerwony, sprawdź reguły firewalla i czy klucz publiczny zgadza się dokładnie.

Krok 6: Dodaj TLS (opcjonalne, lecz zalecane)

Domyślny protokół RustDesk jest już szyfrowany na warstwie aplikacji (klucz publiczny, który skopiowałeś, jest częścią tego). Dodanie TLS daje drugą warstwę i chroni przed niektórymi pasywnymi atakami sieciowymi. Konfiguracja wymaga reverse proxy (nginx lub Caddy) przed portami relay.

Wersja z Caddy (prostsza):

relay.yourdomain.com {
    reverse_proxy /ws/* localhost:21118
    reverse_proxy * localhost:21115
}

Caddy automatycznie wystawia certyfikat Let's Encrypt. Zaktualizuj klientów, aby używali portu 443 z włączonym TLS.

Krok 7: Zrób kopię zapasową kluczy

Katalog data/ zawiera parę kluczy serwera rendezvous. Jeśli je utracisz, każdy klient trzeba będzie skonfigurować ponownie z nowym kluczem publicznym. Zrób kopię zapasową:

# Local backup
rsync -avz vps:/opt/godesk-relay/data/ ~/godesk-relay-backup-$(date +%Y%m%d)/
# OR copy the two key files
scp vps:/opt/godesk-relay/data/id_ed25519* ~/godesk-keys/

Przechowuj kopię offline. Jeśli VPS zostanie przejęty, chcesz móc uruchomić nowy z tymi samymi kluczami, żeby istniejący klienci nadal działały bez ponownej konfiguracji.

Tryby awarii, których dokumentacja nie opisuje

Awaria 1: Klienci nie mogą osiągnąć relay. W 90% przypadków to firewall. Sprawdź ufw status, upewnij się, że grupy zabezpieczeń u dostawcy chmury też zezwalają na te same porty, i uruchom nc -vz relay.yourdomain.com 21116 z klienta, aby zweryfikować dostępność.

Awaria 2: P2P zawsze schodzi na relay. Symetryczny NAT lub restrykcyjne firewalle korporacyjne wymuszają przekierowanie wszystkiego przez relay. To normalne — wydajność jest dobra, ale obowiązuje pomiar przepustowości. Użyj relay.yourdomain.com z planem VPS o dużej przepustowości.

Awaria 3: Proces relay pada i się nie restartuje. Dockerowe restart: unless-stopped obsługuje większość przypadków. Dodaj docker compose ps do zadania cron, które powiadomi Cię o brakujących kontenerach.

Awaria 4: Certyfikat SSL wygasa. Jeśli używasz Caddy, to jest automatyczne — odnawia 30 dni przed wygaśnięciem. Jeśli używasz nginx + certbot, skonfiguruj zadanie cron do odnowienia. certbot.eff.org ma oficjalny przewodnik.

Szacunki przepustowości

Jakość ma tu znaczenie. Przybliżone wartości:

  • Niska jakość (praca tekstowa): ~50 KB/s = 180 MB/godzinę
  • Średnia (praca biurowa): ~200 KB/s = 720 MB/godzinę
  • Wysoka (wideo, grafika): ~1 MB/s = 3,6 GB/godzinę

Hetzner CX22 z 20 TB miesięcznie obsłuży w przybliżeniu 5 500 godzin sesji wysokiej jakości miesięcznie — znacznie więcej niż potrzebuje pojedyncza osoba czy mały zespół. Limit 20 TB ma znaczenie dla organizacji z setkami urządzeń.

Opcja gotowa: samodzielnie hostowany relay od GoDesk

Wszystko powyżej opisuje ręczną ścieżkę z użyciem otwartoźródłowego stosu RustDesk. GoDesk publikuje paczkę do self-hostingu tej samej pary hbbs/hbbr z rozsądnymi ustawieniami domyślnymi. Jeśli nie chcesz zarządzać plikami Docker Compose, zobacz nasz przewodnik po self-hostingu — ta sama architektura, z jednolinijkowym skryptem instalacyjnym, który opakowuje powyższe kroki.

Kiedy NIE hostować samodzielnie

Self-hosting dodaje obowiązki operacyjne: monitoring, kopie kluczy, aktualizacje OS, odnowienie certyfikatów. Jeśli Twoim przypadkiem użycia jest „chcę zdalnie połączyć się z domowym PC”, relay hostowany przez dostawcę (darmowy plan GoDesk obsługuje 5 GB/month) to znacznie mniej pracy niż utrzymywanie własnego VPS na stałe.

Hostuj samodzielnie tylko jeśli masz realny powód — zgodność, suwerenność, skala. Pomiń, jeśli jedyną motywacją jest „fajnie by było”; podatek operacyjny szybko Cię dogoni.

Podsumowanie

  1. $5/month VPS w preferowanym regionie.
  2. Docker + UFW + kontenery RustDesk hbbs/hbbr.
  3. Rekord DNS A wskazujący na VPS.
  4. Trzy wartości konfiguracyjne na klientach (Serwer ID, Serwer relay, klucz publiczny).
  5. Zrób kopię zapasową kluczy.
  6. Opcjonalnie: TLS przez Caddy/nginx.

Czas konfiguracji end-to-end: 30 minut. Bieżące utrzymanie: minimalne. Efekt: pulpit zdalny, którego Twój ruch nie przechodzi przez infrastrukturę osób trzecich.

Po więcej informacji po stronie GoDesk — dokumentacja self-hostingu, przegląd otwartoźródłowego krajobrazu lub sam klient.