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
inker
herfra, s� m� de nok komme krypende til meg og sp�rre pent.
Forel�pig er jeg den eneste her.
https://steinar.bang.priv.no";>Steinar Bangs blogg
Historiske sider for Steinar Bang (sider fra
1994-1999)
Bildearkiv fra 1990-tallet
> 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
>>>>> 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 Network
Platform: debian 12.6 "bookworm", amd64
nginx 1.22.1
I have the following in /etc/nginx/sites-available/default:
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
return 444;
}
This succeeds in some requests using just t
