Cannot access vScope

Use this guide when the vScope web UI does not load at all — for example the browser times out, shows “connection refused,” or the page never appears, even after restarting the server or the service. This is different from being able to reach the login page but not sign in; for that, see Cannot log in to vScope.

Note

vScope is on-prem software that runs in your own environment — it is not a cloud service hosted by vScope AB. This means the vScope server, its network path, and the ports it uses are all part of your infrastructure, and the checks below need to be run by someone with access to that server and network, not something vScope AB can check remotely on your behalf.

Work through the steps in order, each one rules out a layer, starting from the vScope service itself and working out to the network and browser.

1. Confirm the vScope service is running

1. On the vScope server, open Services (services.msc on Windows) and check the status of vScope Server Service. On Linux, run systemctl status vscope-server.
2. If it is stopped, start it and check whether it stays running or stops again shortly after.
3. If it will not stay running, check Windows Event Viewer (Application log) or the vScope log (see Check the debug log for startup errors) for the reason.
4. From the server itself, open a browser locally and go to http://localhost:<port> (or https://localhost:<port> if HTTPS is enabled), using the configured port. This bypasses the network entirely:
   • Loads successfully → the service and web listener are fine locally; the problem is downstream (wrong port, firewall, or network path — go to Confirm you’re using the right address and port).
   • Fails here too → the problem is with the service/listener itself — continue to Rule out a port conflict and Check the debug log for startup errors.

Note

The Windows service can show as Running even if the internal web listener failed to bind to its port (see Rule out a port conflict). A running service does not always mean the UI is reachable — the localhost check above is what actually confirms it.

2. Confirm the server itself is reachable

1. From another machine, ping the vScope server’s hostname or IP.
2. If you can, RDP/SSH into the server directly to confirm it’s up and responsive.
3. Check that the disk isn’t full — vScope will not start reliably without free disk space. See Disk & Storage.

If the server itself is unreachable, this is an infrastructure/VM issue (server down, network outage, DNS) rather than a vScope-specific problem.

3. Confirm you’re using the right address and port

1. Check exactly what URL you’re using, for example http://vscope.example.local:4444.
2. Confirm this matches the port vScope is actually configured to use. The default is 80 (or 8080 for Docker); this is only different if someone changed it during installation.
3. If the port was changed at some point (as in the case where it was moved to avoid a conflict with another application), double-check that everyone reporting the issue is using that same, current port — old bookmarks or shared links pointing at the previous port will fail.

See Ports used by vScope for defaults.

4. Rule out a port conflict

This is the most common cause when access used to work on a custom port and then silently stops, especially after a server or service restart.

If another application binds to the same port vScope was configured to use, vScope’s own web listener can fail to start on that port — even though the Windows service itself still shows as running. This is easy to miss because nothing in the vScope UI is around to show a service you can’t yet reach.

1. On the vScope server, run:

   netstat -ano | findstr :4321

   (replace 4321 with your configured port)

2. Check what process owns that port (use the PID column with Task Manager’s Details tab, or tasklist /FI "PID eq <pid>").

3. If another process holds the port, either:

   • Stop/reconfigure that other application to free the port, then restart the vScope service, or
   • Change vScope to a different, unused port (see Check firewall rules for the port below for what to update afterward).

Important

The listening port is set at installation time. To change it, re-run the vScope installer, choose Advanced Installation (uncheck “Express Installation”), and set the new port under vScope Core Settings — the same panel used to change RAM allocation. Your existing data is not affected.

5. Check firewall rules for the port

If you changed the port, firewall rules written for the old port (or for the default port) will not automatically apply to the new one.

1. Confirm Windows Firewall (and any network/perimeter firewall) has an inbound allow rule for the current configured port on the vScope server.

2. If you changed the port recently, verify a new rule was actually added — it’s easy to update the vScope setting but forget to update the matching firewall rule.

3. Test from a client machine with a port check, for example:

   Test-NetConnection -ComputerName vscope.example.local -Port 4444

If this fails from the client but the port is confirmed open and listening on the server itself (see Rule out a port conflict), the block is on the network path in between — check any firewalls, VLANs, or security groups between the client and server.

6. Check the debug log for startup errors

The vScope log will usually show directly if the web service failed to bind to its port (for example “Address already in use”) or failed to start for another reason.

• Location: [C/D]:\vScopeData\log\debug.log

See Where do I find log files for debugging? for details, including how to share it with support.

7. Rule out an HTTPS mismatch

If HTTPS was recently enabled, disabled, or reconfigured, that can also make vScope appear completely unreachable (for example, browsing to http:// when only https:// is now accepted, or vice versa).

• Try both http:// and https:// with the correct port.
• See Troubleshoot HTTPS configuration in vScope if HTTPS is in use.

8. Browser-side checks

1. Try a different browser or an incognito/private window to rule out cached redirects or cached DNS.
2. Confirm there isn’t a stale entry in the local hosts file or an internal DNS record pointing at an old IP.
3. If you use a VPN to reach the server, confirm the VPN is connected and routes to the vScope server’s subnet.

When to contact support

Contact support if you’ve been through the steps above and still can’t access vScope. Include:

• The exact URL/port you’re trying to use.
• Output of netstat -ano | findstr :<port> from the vScope server.
• Whether the vScope Server Service shows as running.
• The debug.log from around the time access stopped working.
• Your License Instance ID.

Related

• Cannot log in to vScope
• Ports used by vScope
• Troubleshoot HTTPS configuration in vScope
• Where do I find log files for debugging?