This episode covers the client side: getting to know TigerVNC Viewer, Remmina, Vinagre, and RealVNC, understanding the host:display versus host:port format, making the first connection to a VNC server, and step-by-step diagnosis when the connection fails.

The last two episodes focused on the server: x11vnc and TigerVNC are now running on your machine. Episode 6 shifts the perspective to the client side. A great server is worthless without a viewer that can connect — and most remote desktop failures actually happen at the first connection stage.
This episode introduces you to the main viewers (TigerVNC Viewer, Remmina, Vinagre, RealVNC), explains the host:display versus host:port address format that often confuses beginners, then walks you through making the first connection and diagnosing failures systematically.
Each viewer has its own character. You should master at least two:
vncviewer) — a lightweight command-line viewer, available on all platforms, and well suited for scripts and tunnels. The focus of this episode.Install any viewers you don't have yet:
sudo apt install tigervnc-viewer remmina vinagreThe apt install tigervnc-viewer remmina vinagre command installs three viewers at once so you can try each one and pick your favorite.
The number one source of confusion for beginners is the two ways of writing a VNC address. Both are valid and point to the same place:
host:1 — the server computes 5900 + display, so this points to port 5901.host:5901 — points directly to the explicit port.server:1 == server:5901
192.168.1.20:2 == 192.168.1.20:5902The formula is simple: port equals 5900 plus the display number. If the server uses display :1, the address can be written as host:1 or host:5901 — they're identical.
Now let's connect to the server you created in episode 5:
vncviewer localhost:1The vncviewer localhost:1 command connects to the VNC server on localhost display :1. You'll be asked for the password (created with vncpasswd), then the Xfce or KDE desktop configured in xstartup will appear.
For a server on another machine, replace localhost with its IP address:
vncviewer 192.168.1.10:5901The vncviewer 192.168.1.10:5901 command connects to IP 192.168.1.10 on port 5901. Change it to match your server's address — and make sure the server firewall allows that port in (episodes 0 and 12).
When a connection fails, don't guess. Run checks in sequence, from the network layer to the server layer:
ping -c 3 192.168.1.10
nc -zv 192.168.1.10 5901If ping fails, the problem is the network. If ping succeeds but nc -zv fails, the port isn't open — check the VNC server and firewall. The nc -zv command tells you whether the port accepts TCP connections, before you bother checking the password.
Here's a map of the most frequent errors:
vncserver -list on the server.vncpasswd.ss -tulpn and the firewall rules.~/.vnc/.vncserver -list
ss -tulpn | grep 590vncserver -list shows the active sessions; ss -tulpn | grep 590 confirms the port is really listening. These two commands answer 80 percent of "why can't I connect" questions.
Tip
Test the connection with nc -zv before opening the viewer. A single command separates network problems from authentication problems — and saves dozens of minutes of troubleshooting.
Episode 6 completed the first bridge between server and client: you got to know the four main viewers, understood the equivalent host:display and host:port address formats, made your first connection to display :1, and performed sequential diagnosis when the connection fails.
Key takeaways:
host:display and host:port are equivalent: :1 means port 5901.vncviewer localhost:1 for local testing; replace with the IP for remote use.nc -zv separates network problems from authentication problems.~/.vnc/xstartup.In the next episode, episode 7, we level up to VNC configuration and customization — preparing ~/.vnc/xstartup for GNOME, Xfce, and KDE, setting geometry and depth, running several servers at once with separate users and displays, and closing sessions with vncserver -kill. See you in the next episode!