Thank you for testing. Please do not worry, your server is not necessarily the problem.
From your output, the realtime service is running and GoAccess is listening correctly. So this part looks OK:
Active: active (running)
goaccess ... --real-time-html ... --ws-url=wss://zumbo.net:443/vstats/ws/
The remaining problem is probably one of these:
- Nginx is not loading the
/vstats/ws/ proxy include
- The browser is using stale cached
/vstats/ HTML after the realtime service restarted
- The public domain/redirect does not match the WebSocket URL
- A proxy such as Cloudflare is interfering with the WebSocket request
Version v1.0.5 has a better doctor check for this exact issue. Please run:
hestia-goaccess --version
sudo hestia-goaccess status zumbo zumbo.net
sudo hestia-goaccess doctor zumbo zumbo.net
Please send the full output.
Also please try a cache-busted dashboard URL once:
https://zumbo.net/vstats/?fresh=1
If your site redirects to www.zumbo.net, please regenerate realtime with the www host:
sudo hestia-goaccess enable zumbo zumbo.net --mode realtime --ws-url wss://www.zumbo.net:443/vstats/ws/
Then test:
https://www.zumbo.net/vstats/?fresh=1
If your site does not redirect to www, keep the non-www host:
sudo hestia-goaccess enable zumbo zumbo.net --mode realtime --ws-url wss://zumbo.net:443/vstats/ws/
Then test:
https://zumbo.net/vstats/?fresh=1
The browser URL and the WebSocket URL must use the same public host.
If goaccess-static works, you can safely use static mode while we debug realtime:
sudo hestia-goaccess enable zumbo zumbo.net --mode static
Static mode does not use WebSocket.