Also open-source and self-hostable: https://github.com/httptoolkit/testserver. Lots of other endpoints too, full docs here: https://testserver.host/
> This is not a service; avoid relying on it for testing and monitoring purposes.
So yeah I would pick something simpler for a network access test probably?
It's a static page that every Apple device relies on saying only:
<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML> ~$ 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 msIt'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).
But even just having an RFC to yell about is great, thank you :)
I caught it in review but thousands of others won't.
That ship has sailed I would say.
I've seen google STUN servers used in production. Folks probably rely on unpkg too much to deliver their JS. Good to consider these failure modes.
If your service runs on AWS, reaching amazon dot com seems somewhat more reasonable an internal health check.
As an example, depending on "man -w" not outputting anything to stderr: https://unix.stackexchange.com/questions/405783/why-does-man...
We removed the version and a few customers complained we broke their stuff.
Our back clapping was interrupted by an angry customer phone call. One of our customers had gotten access to our internal schema and had a massive reporting setup in Access solving most of his needs.
I ended up converting his reports using some internal tools we had. Customers will grab anything to give them.
[The caliber and depth of his reports were such I wish we would have bought them instead of making me spend months building out our own reports.]
Learning from customers is some of the best learning you can do. :)
This is probably an even more important principle in the age of LLMs.
That's an interesting case. Did you consider this a correct result?
On one hand, <foo@example.com> is a valid hypothetical address that can be used strictly in documentation. It is also syntactically valid, which is the best kind of valid. However, <foo@example.com> (and all its permutations) is an obviously invalid actual address if you're trying to send email to it, or manipulate it in any real way on the Internet.
It's a good sanity check, but quite pedantic. I can understand if you are validating some public input form, where people are likely to put fake email addresses, and you don't want someone knowingly filling in <blah@example.com> because you also know, a priori it's a fake, and it will waste your time validating or trying to send to it.
Also as a _long_ list of other specialist TLS endpoint configurations if you're interested, which can be arbitrarily combined, see https://testserver.host/#tls-endpoints.
That gives neat tricks like https://tls-v1-2--expired--incomplete-chain--http2.testserve...: only accepts TLS 1.2, then sends an expired certificate but fails to send the intermediate cert for the chain (so the client must infer it) and then negotiates HTTP/2 for the connection on top. Fun!
If you want to hit it hard, or you just want to avoid any risk of limits in future, it's a one-liner to host it yourself with Docker: `docker run --rm -it -p 3000:3000 httptoolkit/testserver`, then open http://example.localhost:3000/. Advanced config options for CAs etc are in the GitHub README.
The web page at example.com is maintained as a courtesy by IANA in order to explain the purpose of the example.com domain to wayward humans.
In the nomenclature of RFC 2119, one MUST NOT design computer systems that rely on the correct operation of an HTTP server at that domain. [0] Plus, it's _really_ rude to pound on a small-scale service being provided as a courtesy... go hit the home page of a tech megacorp (such as Microsoft or Google) or the status page for a major CDN (such as Cloudflare or Akamai) instead!
[0] I expect that someone here will want to pop up with a "gotcha" where they say something like "Oh, but IANA's email says that automated use is strongly recommended against, rather than prohibited and besides, they can't actually stop me from doing it!". To that, I reply "Sure, and standards-writers can't actually stop implementers that do the profoundly antisocial thing and do the things they MUST NOT. As any adult who's been paying attention to the world around them throughout their lives knows, there's only so much you can do to stop people who are very determined to be enormous assholes.".
Would you settle for any old static page served by Cloudflare? For instance, example.com? https://bgp.tools/dns/example.com
In the nomenclature of RFC 2119, one MUST NOT design computer systems that rely on the correct operation of an HTTP server at [example.com.] Plus, it's *_really_* rude to pound on a small-scale service being provided as a courtesy.Maybe Cloudflare gives them a good rate, or is donating service, but it's also possible or even likely that IANA is just using Cloudflare as a vendor, and therefore is paying for all the traffic, which is why they don't want people relying on it or hammering it all the time
Much too big for metered data, full of ads, and importantly they all mandate HTTPS these days, which breaks my use case of forcing a captive portal on paid/login-gated Wi-Fi to render.
example.com is (unfortunately for the IATA) the almost perfect "can I reach the Internet" service: It's unlikely to go away, supports HTTP, is fairly small, easy to remember, and I don't care if a captive portal poisons my DNS cache with a fake response temporarily.
You'll be pleased to learn that nearly (actually?) all major sites that mandate HTTPS provide an HTTP redirect response when hit on port 80. You can't help but agree that a 30X with no body is way less data than pulling down even just the HTML parts of example.com.
curl -v http://cloudflarestatus.com
* Trying [2600:1901:0:4a3b::]:80...
* Host cloudflarestatus.com:80 was resolved.
* IPv6: 2600:1901:0:4a3b::
* IPv4: 35.201.124.30
* Established connection to cloudflarestatus.com (2600:1901:0:4a3b:: port 80) from [REDACTED] port [REDACTED]
* using HTTP/1.x
> GET / HTTP/1.1
> Host: cloudflarestatus.com
> User-Agent: curl/8.22.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Cache-Control: private
< Location: https://www.cloudflarestatus.com:443/
< Content-Length: 0
< Date: Wed, 07 Oct 2026 08:07:34 GMT
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host cloudflarestatus.com:80 left intact
> ...which breaks my use case of forcing a captive portal on paid/login-gated Wi-Fi to render.
Huh? Captive portals -especially ones that redirect to payment collection systems- are served up by infrastructure that either you control or that you've arranged with someone else to operate. If you're paying IANA to operate your captive portal, and they've made the choice to hit example.com:443, then that's their -odd- choice... but I bet that's not who's operating your captive portal.
If you've designed a captive portal system that depends on a functioning HTTPS server at example.com, you desperately need to go back and redesign it... if for no other reason than to -given your concern about metered data- massively reduce your own bandwidth bills.
My browser (in which I do these ad hoc connectivity tests) does in the end pull down the redirection target including all resources. Not fun on a slow and metered network such as in-flight Wi-Fi.
On top of that, sites like google.com just haven't worked as well for me in the past in these situations. Not sure why, but I suspect they just use all the latest security extensions like HSTS etc., making it hard to access the non-secure version once that's cached. Could also be some heuristics in my browser.
> And in regards to "DNS cache poisoning", approximately no one cares about hitting the status page of a major CDN. ;)
What I mean is the captive portal poisoning my DNS cache, and thereby rendering e.g. google.com unusable for me even after authenticating/purchasing access. I don't really care if example.com redirects me to the in-flight Wi-Fi portal; in fact, that's usually what I want it to do when losing connectivity.
> Huh? Captive portals -especially ones that redirect to payment collection systems- are served up by infrastructure that either you control or that you've arranged with someone else to operate.
I (unfortunately?) don't control the payment systems or captive portal implementation of the airlines I fly with. I'm just sharing my experience in practically mitigating their various deficiencies as a user.
/s