HyperView only needs outbound HTTPS from each end, so most connection problems come from a firewall, a proxy or a slow link between one end and the internet. Start with the network requirements, then work through the checks in order.
Network requirements
Give these to your network team before you deploy:
Outbound TCP 443 (HTTPS) to
*.readytech.com, from both ends of the connection: the computer running the browser, and every system running the HyperView Server. For remote support, the computer of the person you're helping needs it too, for DesktopAgent.No inbound ports. Both ends connect out to a venue, so a system doesn't need a public address. See Venues and private venues.
About 250 KB/s (2 Mbps) per session for viewing a system in the browser. Someone watching three systems at once needs about three times that.
The bandwidth figure is typical, not a limit. More or larger screens, and video or animation on the system, use more. The virtual video driver uses less.
Check 1 - Port 443 is open at both ends
On the Systems screen, look at the system's dot. A green dot means the system's end can reach HyperView, so the problem is at the browser's end.
If the dot isn't green, ask the network team for the system's network to confirm the outbound rule for port 443 to
*.readytech.com. For a cloud VM, check the outbound rules on its security group or network ACL as well as any firewall.If the dot is green but the session won't open, ask the same question about the network the browser is on.
NOTE: The rule must cover every name under readytech.com, not just the console's address. Venues have their own names, so a rule for the console alone lets the console load but stops the session connecting.
Check 2 - Nothing is inspecting or holding the traffic
SSL inspection and web proxies can let the console load but break the session's live connection. The session opens and then stalls, or drops after a short time.
Ask your network team to exclude *.readytech.com from SSL inspection, and to let it through the proxy without buffering.
Check 3 - A venue is available
Go to Admin > Account Settings and check whether Private venues only is on.
If it is, go to Admin > Private Venues and make sure at least one of your venues is active and healthy.
With Private venues only on, connections can't fall back to a shared venue. If none of your private venues is reachable, no one can connect. See Venues and private venues.
Check 4 - The system's clock is right
Secure connections can fail when a machine's clock is far out. Check the date, time and time zone on the system, and set it to sync with a time server.
Check 5 - Look at the connection inside the session
If the session connects but feels slow:
Inside the session, open Info > Connection details.
Note the Current venue, the connection type and the latency.
High latency means the path between one end and the venue is slow. A VPN is a common cause: if the browser's computer sends all its traffic through a VPN, ask whether *.readytech.com can go direct instead.
Check 6 - Use less bandwidth
Turn on the virtual video driver. It compresses screen updates, so the session responds faster and uses less bandwidth. See The virtual video driver.
Use a smaller browser window. With the video driver on, the remote desktop resizes to fit, so there is less to send.
Close sessions you aren't using. Each open session uses bandwidth, and session time.
Still stuck?
On the Systems screen, open the system's ⋮ menu and choose Get logs. See Inspect and troubleshoot a system.
Contact support with the system's name, the time the problem happened, and the Current venue from Check 5.