Just to round this up, the idea of checking internet connectivity with a request is implemented all over the place in many ways.
1) How Windows decides about your Internet connection, described by Raymond Chen:
Looking for special servers.
devblogs.microsoft.com
2) InternetCheckConnectionA:
https://learn.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetcheckconnectiona
But see Remarks:
Remarks
InternetCheckConnection is deprecated. InternetCheckConnection does not work in environments that use a web proxy server to access the Internet.
Besides the point of deprecation it takes a URL to test as parameter, so the test like in 1) is based on getting a request done.
3. InternetGetConnectedState:
https://learn.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetgetconnectedstate
Besides the note it's not recommended and instead something else (4) should be used, the remarks describe that it's not a general indicator for internet connectivity:
Remarks
A return value of TRUE from InternetGetConnectedState indicates that at least one connection to the Internet is available. It does not guarantee that a connection to a specific host can be established
4. GetConnectivity:
https://learn.microsoft.com/en-us/w...etlistmgr-inetworklistmanager-getconnectivity
Returns a pointer on a structure that has several logical flags indicating what type of network connectivity exists, including Internet over ipc4 or ipv6.
It seems the most appropriate functionality, I personally doubt it's free of the problem I outlined in my earlier post: false positives or false negatives.
5. The same problem in the perspective of JS running in a browser is discussed here:
https://stackoverflow.com/questions/189430/detect-if-the-internet-connection-is-offline
Browser seem to provide a simple logical flag window.navigator online. If you read the discussion you see true may not mean an internet connection, just connection "to some network at best".
All in all seeing the code you use, I don't need to convince you making a request and getting a response is a valid approach, the only downside of that is if you don't get a response it desn't necessarily mean your internet connection is down, it could just be the server is down - or the URL is not valid.
There are a gazillion ways to make a http request and using inetctls.inet is surely not the first I have on my mind. So in regard of the aspect of your question whether there is anything newer. inetctls.inet is surely not the latest at all. Without using OLE at all you could make a request by URLDownloadToFile:
https://learn.microsoft.com/en-us/p.../ie-developer/platform-apis/ms775123(v=vs.85)
With "is there something new on this?" You may refer to an old thrad, but I don't find one you posted about it.
As siad, error handling will catch the error of inetctls.inet and if you experience your monitoring application stops working it seems you don't know about error handling, if that trips you already. But I would replace that method by anything else anyway, the simplest base could really be URLDownloadToFile.
I already mentioned Msxml2.ServerXMLHTTP which has the advantage over inetctls.ine that it needs no installation in setups. It has one option URLDownloadToFile does not have: You cannot only make a GET request that gets the full response, you can also make a HEAD request that only needs to receive the head of the get request. On the other side, as mentioned in 1) the content of the response can be used to verify you don't just get a response, but it delivers the expected content.
There's one more even simpler way: ping. Not pinging a LAN IP address, obviously, but pinging some internet server. Anyway, I'd perhaps research a bit more to see whether URLDownloadToFile could give you false positives by downloading cached content whereas the actual internet connection is down, but otherwise it seems the best candidate considering the additional validation of the content of the downoaded file to be as expected. It requires to be able to rely on such a static content, though. The two Microsoft txt URLs still work, but are http URLs. Request them over https and a browse will show you a possible security risk. And I wonder whether the short content the two texts have really give a good insight of what went wrong, if you get some crumbled other text instead.
Anyway, you may stick to your code, just add error handling and you're done.