A HTTP request for http://www.msftncsi.com/ncsi.txt returning 200 OK and the text Microsoft NCSI. This is the url windows has been using for decades to determine if the device is online. It is highly reliable.

If they say that it's not intended as a reliable service for testing purposes it can't be that reliable, and they might take it down or change the structure arbitrarily at any time, etc.

So yeah I would pick something simpler for a network access test probably?

If I were to operate a 'service' not intended as a reliable service for testing purposes... I would make sure that it's not reliable - and very unreliable - from the start. So, delayed responses, no responses, garbled responses, duplicate responses, varied responses, ...

Why not ping 8.8.8.8 or 1.1.1.1 or time.windows.com? Things that are actually designed to be highly available services

Is there any reason to believe captive.apple.com is any less "designed to be highly available" than time.windows.com?

It's a static page that every Apple device relies on saying only:

  <HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>

The only risk is that Apple hasn't announced it as being reliable or promised to keep it up or the format the same in any way. They could 100% pull it out from under everyone, with modifications in their OSes prepared for the change

Also some captive portals fake/emulate responses from this service.

1.1 is enough.

  ~$ ping -c1 1.1
  PING 1.1 (1.0.0.1) 56(84) bytes of data.
  64 bytes from 1.0.0.1: icmp_seq=1 ttl=56 time=7.89 ms
  
  --- 1.1 ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 7.888/7.888/7.888/0.000 ms

Thanks! I'd forgotten that 1.1 and 1.1.1 resolve. I'll not infrequently ping 1.1.1.1.1 with overzealous typing. That will, alas, not resolve.

YET!

When did this start working? Did they backport IPv6-style addressing, or did I just never know this?

These pages are unfortunately getting special treatment from quite a few networks these days, among other things to avoid iOS users getting stuck in a loop of trying to connect, and getting disconnected by the OS due to a "non-working connection" for local-only networks like in-flight entertainment systems.

It's a shame that we don't have any standards for the concerns of canonically testing Internet reachability and for authoritatively redirecting network users to a captive payment portal (without having to resort to ugly hacks that often break with TLS).

RFC8910, from 2020: https://www.rfc-editor.org/rfc/rfc8910.html

Woah, amazing! Do you know if any popular network stacks actually support it?

But even just having an RFC to yell about is great, thank you :)

Just don't blame the user and/or their internet service when the service you're relying on inevitably goes down.