BŁĄD • DIAGNOSTYKA • ROZWIĄZANIA

UltraVNC Viewer nie łączy się – przyczyny i rozwiązania

Problem „UltraVNC Viewer nie łączy” oznacza, że klient nie potrafi zestawić sesji z hostem, dlatego pojawia się timeout, refused albo brak odpowiedzi. Często winny jest adres IP lub DNS, natomiast równie często blokuje port 5900 w zaporze albo na routerze. W tym poradniku przejdziesz przez diagnostykę po stronie Windows i sieci, w efekcie szybko ustalisz, gdzie znika ruch i co poprawić.

Pobierz UltraVNC Port 5900: test i otwarcie Zabezpiecz UltraVNC
Objawy Przyczyny Naprawa Checklist FAQ

Szybka odpowiedź

Jeśli UltraVNC viewer nie łączy, zacznij od tych 3 kroków.
Najczęściej działa: test IP → test portu 5900 → firewall/usługa
  1. Na początku łącz się po IP (nie po DNS), ponieważ błędna nazwa często maskuje problem sieciowy.
  2. W kolejnym kroku sprawdź, czy host nasłuchuje na 5900/TCP i czy port jest osiągalny, w efekcie wykluczysz blokadę po drodze.
  3. Na końcu zweryfikuj Windows Firewall, router i usługę UltraVNC Server, dlatego ruch zacznie docierać do aplikacji.

Objawy

Po tym poznasz, że masz problem „UltraVNC viewer nie łączy”.
  • Po kliknięciu Connect pojawia się timeout, dlatego sesja nie dochodzi do etapu logowania.
  • Komunikat „connection refused” występuje, natomiast host bywa wyłączony albo nie nasłuchuje na porcie.
  • Połączenie działa w LAN, a przez Internet nie działa, w efekcie podejrzany jest router lub CGNAT.
  • Po aktualizacji Windows lub polityk bezpieczeństwa problem wraca, ponadto czasem blokuje go EDR.

Najczęstsze przyczyny

Zwykle winny jest jeden z poniższych elementów.
Adres IP lub DNS jest błędny Viewer trafia w zły host lub w zły adres, dlatego połączenie kończy się timeoutem. Wskazówka: test po IP, potem DNS
Port 5900/TCP jest zablokowany Firewall lub router filtruje ruch, natomiast port nie jest przekierowany z WAN do hosta. Wskazówka: inbound rule, NAT/forward
Usługa UltraVNC Server nie działa Host nie nasłuchuje, ponieważ usługa nie startuje lub została zatrzymana. Wskazówka: services.msc, autostart

Naprawa krok po kroku

Idź kolejno – po każdym kroku sprawdź połączenie.
  1. Krok 1: Zweryfikuj IP i DNS (bez zgadywania)
    Na początku ustal poprawny adres IP hosta w LAN, a następnie łącz się z Viewer po IP, ponieważ DNS potrafi wskazywać stary rekord. Jeśli musisz używać nazwy, sprawdź rozwiązywanie: ping i nslookup. Gdy DNS jest błędny, popraw rekord, w efekcie Viewer trafi do właściwej maszyny.
  2. Krok 2: Sprawdź, czy host nasłuchuje na 5900/TCP
    W kolejnym etapie potwierdź stan usługi UltraVNC Server w services.msc, natomiast po zmianach zrób restart usługi. Następnie zweryfikuj nasłuch portu na hoście (np. narzędziami systemowymi), ponieważ bez nasłuchu zawsze dostaniesz refused. Jeśli port jest inny niż 5900, dopasuj go w Viewer, dlatego parametry będą spójne.
  3. Krok 3: Odblokuj Windows Firewall i EDR
    Następnie sprawdź reguły przychodzące w Windows Firewall i dodaj wyjątek dla 5900/TCP, ponieważ to najczęstsza blokada po aktualizacji. Jeśli używasz EDR/AV, dodaj kontrolowane wyjątki dla procesu UltraVNC Server, natomiast rób to tylko dla zaufanych hostów. Po zmianach przetestuj ponownie, w efekcie zobaczysz, czy blokada była lokalna.
  4. Krok 4: Router, NAT i dostęp z Internetu
    Na końcu zweryfikuj przekierowanie portu 5900 na routerze, ponieważ bez port-forwarding ruch z WAN nie dotrze do hosta. Sprawdź też, czy masz publiczny adres IP; przy CGNAT połączenie z zewnątrz nie zadziała, dlatego potrzebujesz VPN lub tunelu. Po poprawkach wykonaj test portu z zewnątrz, w efekcie potwierdzisz działanie ścieżki WAN.
→ Port 5900: jak przetestować i otworzyć → Bezpieczeństwo: VPN, whitelist IP i hasła

Checklist

Szybka lista kontrolna do odhaczenia.
  • Połączenie testowane po IP, natomiast DNS sprawdzony dopiero po potwierdzeniu trasy.
  • Usługa UltraVNC Server działa i restart po zmianach został wykonany.
  • Host nasłuchuje na 5900/TCP, dlatego Viewer nie trafia w „pusty” port.
  • Windows Firewall ma regułę przychodzącą, ponadto EDR nie blokuje procesu.
  • Router ma poprawny port-forward, a dostęp z WAN został potwierdzony testem.

FAQ

Najczęstsze pytania użytkowników.
Czym różni się „timeout” od „connection refused” w UltraVNC Viewer?
Timeout oznacza, że pakiety nie wracają, dlatego zwykle blokuje je firewall, router albo ISP. Natomiast „refused” sugeruje, że host odpowiada, ale port nie nasłuchuje lub usługa nie działa. W efekcie diagnoza zaczyna się od portu i usługi, a dopiero potem od NAT.
Dlaczego połączenie działa w LAN, a z Internetu nie działa?
W LAN omijasz router i translację, natomiast z WAN potrzebujesz przekierowania portu i publicznego IP. Jeśli masz CGNAT, połączenie przychodzące nie dojdzie, dlatego rozwiązaniem jest VPN lub zdalny tunel. W efekcie nie musisz wystawiać VNC publicznie.
Czy mogę zmienić port 5900 na inny?
Tak, natomiast musisz zmienić port po stronie Server oraz dopasować go w Viewer. Ponadto pamiętaj o regule zapory i przekierowaniu na routerze, dlatego cały łańcuch musi być spójny. W efekcie unikniesz kolizji i prostych skanów portu 5900.