Stingray will attempt to ping its front-end gateway to verify it has external connectivity, and it will attempt to ping some of the back-end nodes; as long as it can ping both the gateway and at least one active node, it will manage traffic normally.
If one of the two tests fails, Stingray will conclude that it has lost network connectivity and it will voluntarily drop any traffic IP addresses or traffic shares. It will also broadcast a 'failed' status in the internal health status messages so that its peers in the cluster know that it has dropped its traffic ip addresses and shares.
You can change or disable the front-end 'gateway' test by configuring an alternative IP address to ping (see the global setting 'flipper!frontend_check_addrs').
You cannot disable the back-end node test, but if none of your nodes are able to respond to ping requests, then you can create a dummy pool that contains a node on localhost (127.0.0.1) - this local IP address should always respond to pings.
Note that if you do disable or work around these connectivity tests, then the Stingray device will be unable to detect front-end or back-end network failures and initiate a failover to a working machine.