[Bug]: Move away from using example.com for connectivity test

[khantzawhein]

Application

Outline Client

Describe the bug

The domain used to test the connection "example.com" is down and subsequently Outline is also down.

The example.com has become a single point of failure for Outline. And most importantly, example.com is not intended to be used in production usage. (https://www.iana.org/help/example-domains).

By the time I posted this issue here, that domain has been unstable for at least past 1 hour. (Up and down frequently)

Please take this opportunity to fix this issue in future.

Steps to reproduce

1. Open App
2. Connect
3. Example.com is down
4. Get i/o timeout error

What did you expect to happen?

Normally Connect

What actually happened?

Getting VPNStartFailure or i/o timeout error

Outline Version

All

What operation system are you using?

Android, iOS, Linux, macOS, Windows

Operating System Version

All Clients

Screenshots and Videos

See Comments

[khantzawhein]

Usage in Outline's code "connectivity.go"

[khantzawhein]

[khantzawhein]

This is code in newer version

[sbruens]

I think each platform should specify the website(s) to use for its connectivity check, rather than have a long central list that all platforms share. It would align the connectivity check more with the platform the app is running on.

In other words, the callers of CheckTCPAndUDPConnectivity would pass in a list of websites to check in parallel and allow us to tweak the lists per platform.

Originally posted by @sbruens in #2328 (comment)

[sbruens]

For posterity, there are some more relevant comments in #2328.

[khantzawhein]

Let me add some points to consider when choosing urls for connectivity tests, as I commented in #2328.

• The latency when connected from multiple region across the world. Because that connection check will block the VPN connection until it’s completed.
• Reachability from servers all over the world (especially from most censored countries like Iran, China, Russia etc.)
• Support http (port 80) without forcing https, which can cost unnecessary TCP handshake overheads.