Opening a connection may be the most OS/deployment portable thing you can do to check for Wide Area Network access, but it is probably harder to optimize for network latency and the timeout for establishing connections can be pretty long - seconds even.
Here is a faster idea that might only require a little work to make portable-ish. With ping you can crank the time-to-live (TTL) down and endure just a few hops to test (on Unix ping -c 1 -t 2 1.1.1.1 on Windows ping -n 1 1.1.1.1 -i 2 {untested}). For me, I get down near 1.0 milliseconds since we limit the number of hops to "close by", not "all the way to 1.1.1.1".
You can run external commands in Nim with os.execShellCmd and (on Unix) detect via the exit status if you even made it 2 hops (or however many you like). If you did not, you have no WAN access. You could even exit with a nice message about checking your local net setup. (You'll have to check what Windows ping does Re exit status codes.) If there is no ping or you cannot run it, you could always fail as if there is no network.
You could probably write some Nim code with raw sockets to do an API version of the above idea. The problem here is that this usually needs certain administrative privilege/setuid-programs that may vary in portability across OSes even more than CL options (or the name of the command).
You might be able to set socket options to crank down the timeout on your connect. This may improve things some, but will still always do "all the hops" to the destination" (at least 1 full round trip). So, it will always be order(s) of magnitude slower than my ICMP ping packet suggestion.
Usually you should not try to test if connectivity is available because 1) it introduces a race condition between test and use 2) tests can be unreliable as xigoi pointed out 3) sending out spurious traffic is bad network citizenship 4) it introduces unnecessary complexity and delays.
Hovever, if you specifically need to trigger some activity based on the status of network interfaces it's difficult to do it in a very portable way but perhaps getPrimaryIPAddr might help.