Improved 444 configuration: replaced the letsencrypt certificate (which
won't work here anyway) with the self signed certificates bundled with
nginx (the more broken, the merrier in this case... confuse the bots!):
server {
listen 80 default_server;
listen [::]:80 default_server;
Ok, found it!
Turned out one of my other configs (the server www.mycompany.com one)
had this
server {
# SSL configuration
#
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate
/etc/letsencrypt/live/www.mycompany.com/fullch
Found something!
If I use https with the IP number and ignore the certificate errors
caused by there being no certificate that matches the IP number, then I
get a 200 OK (or presumably 404 as I've seen for some addresses).
sb@marquez:~$ curl -svk https:///
* Trying :443...
* Connected to () po
> Jeffrey Walton :
> The first two which succeed have a user agent string ("Expanse..." and
> "Mozilla/5.0..."). The third one which fails lacks the user agent
> string ("-").
> I'm not sure if that makes the difference in the behavior you are observing.
> You may be able to test it with cUR
On Sun, Aug 25, 2024 at 6:18 AM Steinar Bang wrote:
>
> > Steinar Bang :
>
> One piece of weirdness in the access.log.
>
> These two IP address requests for "/" returns 200.
>
> > 162.216.149.127 - - [23/Aug/2024:00:51:03 +] ""
> > "GET / HTTP/1.1" 200 467 "-" "Expanse, a Palo Alto Networ
> Steinar Bang :
One piece of weirdness in the access.log.
These two IP address requests for "/" returns 200.
> 162.216.149.127 - - [23/Aug/2024:00:51:03 +] ""
> "GET / HTTP/1.1" 200 467 "-" "Expanse, a Palo Alto Networks company, searches
> across the global IPv4 space multipleer day
