Custom WireGuard configurations forcibly disconnected if checkip.windscribe.com is blocked (e.g., in Russia)

[grold]

When using a Custom WireGuard configuration in the Windscribe Android app, the application successfully establishes the WireGuard tunnel but immediately tears it down after 15 seconds.

This happens because the app mandates a "connectivity test" to https://checkip.windscribe.com (and an internal API at 10.255.255.1:19800) to verify tunnel health. In regions where checkip.windscribe.com is blocked at the ISP/State level (such as Russia), this health check times out. After 3 failed attempts, the app assumes the tunnel is broken and forces a disconnection, even though the custom WireGuard tunnel itself is fully functional and successfully routing traffic to the custom endpoint.

Steps to Reproduce

1. Setup VPN serverin a network where checkip.windscribe.com is blocked (e.g., inside Russia).
2. Import a valid Custom WireGuard configuration (e.g., connecting to a personal server).
3. Attempt to connect to the custom profile.
4. Observe that the VPN connects briefly, but automatically disconnects after ~15 seconds.

Expected Behavior

When using a Custom Config, the app should not rely on Windscribe-specific infrastructure (checkip.windscribe.com or internal 10.255.x.x IPs) to validate tunnel health. If the WireGuard handshake is successful, the connection should remain active, or at the very least, fallback to a neutral connectivity check (e.g., checking 1.1.1.1 or 8.8.8.8).

Log Output Evidence

The app logs clearly show the tunnel coming UP, followed by the hardcoded tests timing out, resulting in the app intentionally destroying the tunnel:

    1 // Tunnel establishes successfully
    2 {"lvl":"info","mod":"vpn_backend","msg":"WireGuard tunnel state changed to UP"}
    3 {"lvl":"info","mod":"tunnel-health-check","msg":"Starting tunnel health monitoring for endpoint: <my_custom_server>"}
    4 {"lvl":"info","mod":"vpn_backend","msg":"Starting connectivity test."}
    6 // App tries to hit Windscribe IPs through the custom tunnel
    7 {"lvl":"debug","mod":"wsnet-wrapper","msg":"New curl request : https://10.255.255.1:19800/v1/token"}
    8 {"lvl":"debug","mod":"wsnet-wrapper","msg":"New curl request : https://checkip.windscribe.com/?platform=android&app_version=4.0.2214"}
    10 // Tests fail due to censorship block / unroutable internal IP
   11 {"lvl":"debug","mod":"wsnet-wrapper","msg":"Curl request error: Timeout was reached"}
   12 {"lvl":"info","mod":"vpn_backend","msg":"Failed Attempt: 1 - WSNet: Network failed to connect to server."}
   14 // After 3 attempts, the app kills the working tunnel
   15 {"lvl":"info","mod":"vpn_backend","msg":"Failed Attempt: 3 - Timed out waiting for 15000 ms"}
   16 {"lvl":"error","mod":"vpn_backend","msg":"Connectivity test failed after 3 attempts"}
   17 {"lvl":"info","mod":"vpn_backend","msg":"Stopping WireGuard service."}
   18 {"lvl":"info","mod":"vpn","msg":"VPN state changed to Disconnected"}

Proposed Solution

1. Disable Windscribe-specific health checks for Custom Configs: Do not ping checkip.windscribe.com or 10.255.255.1 if the user is connected to a Custom WireGuard profile, as personal servers cannot resolve internal Windscribe APIs.
2. Neutral Fallback: Use a reliable, neutral endpoint (like 1.1.1.1 or 8.8.8.8) for connectivity tests when using Custom Configs, or rely purely on the WireGuard handshake status.

[ltguillaume]

Use a reliable, neutral endpoint (like 1.1.1.1 or 8.8.8.8)

I wouldn't consider Google or Cloudflare neutral, but I'd figure ControlD, or maybe Cloud9 or DNS4EU would likely work in Russia etc., too.