Skip to content
vScope Support Page

Proxy not appearing or listed as disconnected

Problem: A Discovery Proxy never appears in Discovery → Proxies or stays Disconnected/Pending after approval.
Goal: Get the proxy visible and connected to the master vScope.

Checklist

Section titled “Checklist”

  1. Version mismatch
    Master and Proxy versions must match. If they differ, reinstall/upgrade the Proxy to the master’s version. After a master upgrade, older proxies may not reconnect automatically.

  2. Network connectivity
    The Proxy must resolve and reach the master on the configured port. Common causes: wrong DNS, wrong IP, routing/VLAN issues, wrong port.
    Verify: master hostname resolves; port is open and reachable; no recent IP/network changes.

  3. Firewall / security software
    Outbound Proxy → Master on the chosen port must be allowed. Check Windows Firewall, network firewalls, AV, SSL/TLS inspection/DPI.

  4. Proxy service not running
    Ensure the Proxy service is running (e.g., services.msc on Windows). Restart if needed; check Event Viewer or proxy logs for errors.

    • Windows log (default): C:\vScopeProxyData\log\debug.log
    • Linux log (default): /var/log/vscopeproxy/debug.log

  5. Time synchronization
    Large clock drift can break authentication. Sync both Proxy and Master to a reliable NTP source.

After fixes

Section titled “After fixes”
  • Restart the Proxy service.
  • In vScope, go to Discovery → Proxies and click Refresh. Approve again if it reappears under Available.

Inspect container logs

Section titled “Inspect container logs”

If a Docker or Kubernetes proxy does not connect, inspect both the entrypoint output and the Java debug log. Detailed application messages are written to /data/log/debug.log, so an empty container log does not mean the application has logged no errors.

For Docker, replace the container name if needed:

Terminal window
docker logs --tail 100 vscope-proxy
docker exec vscope-proxy tail -n 100 /data/log/debug.log

For Kubernetes, replace default with your namespace:

Terminal window
kubectl -n default logs --tail=100 deployment/vscope-proxy
kubectl -n default exec deployment/vscope-proxy -- tail -n 100 /data/log/debug.log

Check the debug log for connection or configuration errors, then work through the version, network, and firewall checks above. If the container cannot stay running, inspect the startup failure before attempting exec.

Check Kubernetes startup

Section titled “Check Kubernetes startup”

If the pod is pending, restarting, or unable to mount its data volume:

  1. Inspect the pod and PVC events:

    Terminal window
    kubectl -n default describe pods -l app=vscope-proxy
    kubectl -n default describe pvc vscope-proxy-data

  2. Resolve the reported cause: unavailable StorageClass, volume attachment failure, insufficient resources, or image pull failure. The PVC has no app=vscope-proxy label in the example, so look it up by name.

  3. For a restarting container, inspect its previous output:

    Terminal window
    kubectl -n default logs --previous deployment/vscope-proxy

  4. If the last termination reason is OOMKilled, review both the Java heap and container memory limit. Allow memory beyond the heap for JVM overhead.

  5. Apply the corrected manifest with kubectl apply -f vscope-proxy.yaml, then verify that the pod starts and the proxy connects in vScope.

Section titled “Related”