NoVNC is a pure JavaScript VNC client that runs in any browser — no plugin, no app download, just open a tab and you're looking at a remote desktop. It works by pairing a VNC server (TigerVNC, TightVNC, x11vnc) with websockify, a WebSocket proxy that bridges browser WebSocket connections to the native VNC TCP protocol. Proxmox VE uses it for VM console access, Docker setups use it for container desktops, and sysadmins use it for headless Linux server management. But the NoVNC access chain has three links that can break independently: the websockify HTTP server, the WebSocket proxy, and the VNC server itself. Vigilmon monitors all three, plus SSL certificates for secured deployments, and can verify the full WebSocket→VNC handshake with a heartbeat.
What You'll Set Up
- HTTP monitor for the NoVNC web client page (port 6080)
- TCP probe for the websockify WebSocket server (port 6080)
- TCP probe for the backend VNC server (port 5900/5901)
- SSL certificate alert for HTTPS-proxied NoVNC deployments
- Heartbeat for the full WebSocket→VNC protocol chain
Prerequisites
- NoVNC + websockify running and accessible on your server
- A VNC server (TigerVNC, TightVNC, or x11vnc) on the same host or reachable network
- A free Vigilmon account
Step 1: Monitor the NoVNC Web Client
The NoVNC HTML5 client files are served by websockify's built-in HTTP server. A 200 response with the keyword noVNC confirms websockify is running and the NoVNC JavaScript files are being served correctly.
- Log in to vigilmon.online and click Add Monitor.
- Set Type to
HTTP / HTTPS. - Enter:
http://your-server-ip:6080/vnc.html - Set Check interval to
1 minute. - Set Expected HTTP status to
200. - Under Keyword match, enter
noVNCto confirm the NoVNC application page is loading. - Click Save.
Test the endpoint:
curl -s http://localhost:6080/vnc.html | grep -c "noVNC"
# Should return 1 or more
If websockify crashes, this monitor will alert immediately — before any user tries to open a VNC session.
Step 2: TCP Probe for the WebSocket Server
The web page check confirms HTTP is working, but Vigilmon can also confirm the TCP port itself is open and accepting connections. This is faster and catches scenarios where the HTTP server returns errors but the port is still bound:
- Click Add Monitor → TCP Port.
- Enter your server IP/hostname and port
6080. - Set Check interval to
1 minute. - Click Save.
Run websockify with the --web flag pointing to the NoVNC directory:
websockify --web /usr/share/novnc 6080 localhost:5900
For production deployments using a systemd service:
[Unit]
Description=NoVNC WebSocket Proxy
After=network.target
[Service]
ExecStart=/usr/bin/websockify --web /usr/share/novnc 6080 localhost:5900
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
The TCP probe catches port 6080 going down immediately — even before an HTTP check would timeout.
Step 3: TCP Probe for the Backend VNC Server
The websockify proxy can be running perfectly while the VNC server it proxies to is down. This causes browser-side connection failures that are invisible to an HTTP check on port 6080. Add a TCP probe directly to the VNC server port:
- Click Add Monitor → TCP Port.
- Enter your server IP/hostname and port
5900(or5901for display :1). - Set Check interval to
1 minute. - Click Save.
Standard VNC port assignments:
| VNC Display | Port |
|---|---|
| :0 (primary) | 5900 |
| :1 | 5901 |
| :2 | 5902 |
For x11vnc on a headless server:
x11vnc -display :0 -auth /run/user/1000/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.passwd -rfbport 5900 -shared
For TigerVNC:
vncserver :1 -geometry 1920x1080 -depth 24
A failure on the VNC port with websockify still running means sessions will fail to establish at the protocol level — users see the NoVNC canvas briefly connect then immediately disconnect.
Step 4: SSL Certificate Alert for HTTPS-Proxied Deployments
When NoVNC is proxied behind nginx or Caddy with SSL, the HTTPS domain gets a real certificate. Monitor it:
server {
listen 443 ssl;
server_name vnc.yourdomain.com;
ssl_certificate /etc/letsencrypt/live/vnc.yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vnc.yourdomain.com/privkey.pem;
location / {
proxy_pass http://localhost:6080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
Add an SSL monitor:
- Create an HTTP / HTTPS monitor for
https://vnc.yourdomain.com/vnc.html. - Enable Monitor SSL certificate.
- Set Alert when certificate expires in less than
21 days. - Click Save.
An expired certificate blocks the entire VNC web client — browsers refuse WebSocket connections over HTTPS with an invalid certificate, breaking NoVNC completely.
Step 5: Heartbeat for Full VNC Protocol Chain Health
The HTTP and TCP checks confirm that servers are listening, but they do not verify that the full browser→WebSocket→VNC chain actually works. Set up a heartbeat using a script that performs the WebSocket handshake and receives the VNC server ProtocolVersion message:
- In Vigilmon, click Add Monitor → Cron Heartbeat.
- Set the expected ping interval to
5 minutes. - Copy the heartbeat URL (e.g.
https://vigilmon.online/heartbeat/abc123). - Create a script at
/usr/local/bin/novnc-chain-check.sh:
#!/bin/bash
# Verify the full NoVNC → websockify → VNC chain by checking VNC protocol version
HEARTBEAT_URL="https://vigilmon.online/heartbeat/abc123"
VNC_HOST="localhost"
VNC_PORT="5900"
# Connect to VNC port and read the protocol version string
version=$(timeout 5 bash -c "exec 3<>/dev/tcp/$VNC_HOST/$VNC_PORT; head -c 12 <&3" 2>/dev/null)
# VNC servers announce "RFB 003.008\n" or similar
if echo "$version" | grep -q "^RFB"; then
curl -s "$HEARTBEAT_URL" > /dev/null
fi
- Make it executable and schedule it:
chmod +x /usr/local/bin/novnc-chain-check.sh
echo "*/5 * * * * /usr/local/bin/novnc-chain-check.sh" | crontab -
The script connects directly to the VNC port, reads the first 12 bytes, and checks for the RFB protocol version prefix. A healthy VNC server always sends this immediately upon TCP connection. If the VNC server is up but accepting no connections, the heartbeat stops and Vigilmon alerts.
For a more complete chain test that goes through websockify's WebSocket proxy:
#!/usr/bin/env python3
import urllib.request
import websocket # pip install websocket-client
HEARTBEAT_URL = "https://vigilmon.online/heartbeat/abc123"
try:
ws = websocket.create_connection(
"ws://localhost:6080/websockify",
timeout=5,
subprotocols=["binary", "base64"]
)
data = ws.recv()
ws.close()
# VNC ProtocolVersion starts with "RFB"
if b"RFB" in data:
urllib.request.urlopen(HEARTBEAT_URL, timeout=5)
except Exception:
pass # heartbeat not sent → Vigilmon alerts
Step 6: Configure Alert Channels
- Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
- Set Consecutive failures before alert to
1on the VNC port TCP probe — a VNC server crash needs immediate attention as all active sessions are already dead. - Set consecutive failures to
2on the HTTP and websockify TCP monitors — brief restarts resolve quickly. - Group the three monitors for the same NoVNC deployment into a monitor group in Vigilmon so correlated failures are visible in a single status view.
Summary
| Monitor | Target | What It Catches |
|---|---|---|
| HTTP check | http://host:6080/vnc.html | websockify HTTP server down |
| TCP probe | Port 6080 | websockify process crashed |
| TCP probe | Port 5900/5901 | VNC server down |
| SSL certificate | HTTPS proxy domain | Certificate expiry |
| Cron heartbeat | WebSocket→VNC handshake | Protocol-level failure in the full chain |
NoVNC's elegance — VNC in a browser tab — relies on three cooperating processes. With Vigilmon watching each link in the chain independently, you know immediately whether it's the websockify proxy, the VNC server, or the nginx SSL terminator that broke, which makes debugging a 30-second diagnosis instead of a 30-minute investigation.