mastodon.world is one of the many independent Mastodon servers you can use to participate in the fediverse.
Generic Mastodon server for anyone to use.

Server stats:

9.1K
active users

#crawler

2 posts2 participants1 post today
Replied in thread

@tdp_org unbelievable! I've set up #nepenthes tarpit in my personal blog and reached over 1 million requests from a #amazon #crawler alone in less than 3 months! Other bots typically gave up after crawling tens of thousands of pages of bulshit. Naturally, my robots.txt informs not to crawl the tarpit ...

Der Druck auf öffentliche und gemeinnützige Infrastrukturen steigt. Ob nun Open-Access-Repositorien oder wie hier im Text #Wikimedia: diff.wikimedia.org/2025/04/01/

Es ist gut, dass die Inhalte in das Training von Künstlicher Intelligenz einbezogen werden, aber bei der unverhältnismäßigen Belastung als Ergebnis von kommerziellen Interessen überlege ich, ob es nicht eigentlich einen Ausgleich braucht.

Diff · How crawlers impact the operations of the Wikimedia projectsSince the beginning of 2024, the demand for the content created by the Wikimedia volunteer community – especially for the 144 million images, videos, and other files on Wikimedia Commons – has grow…

在 LLM crawler 盛行的年代擋 bot...

在「把 wiki 搬回到家裡的機器上」之後,就更容易看出來上面的 loading 了 (因為目前上面只有一個站台)。 這個是 monitorix 的週圖: 這個是月圖: 搬回來後就一直有看到 crawler 的量在上面掃,一開始還沒管太多,後來發現愈來愈嚴重 (幾乎所有的 bot 都會因為你撐的住就加速),還是研究了在 Caddy 上擋 bot 的方案。 這邊採用兩個方案,一個是 IP-based 的,另外一個是 User-Agent-based 的。 IP-based 的部分用的是 caddy-defender 的方案,擋掉所有常見的 bot 網段 (包括了 cloud 以及 VPS 的網段): defender block { ranges aws azurepubliccloud…

blog.gslin.org/archives/2025/0

Gea-Suan Lin's BLOG · 在 LLM crawler 盛行的年代擋 bot...在「把 wiki 搬回到家裡的機器上」之後,就更容易看出來上面的 loading 了 (因為目前上面只有一個站台)。 這個是 monitorix 的週圖: 這個是月圖: 搬回來後就一直有看到 crawler 的量在上面掃,一開始還沒管太多,後來發現愈來愈嚴重 (幾乎所有的 bot 都會因為你撐的住就加速),還是研究了在 Caddy 上擋 bot 的方案。 這邊採用兩個方案,一個是...
#blocker#bot#caddy

Nachdem diverse #ki #ai #crawler besonders respektvoll mit den öffentlichen Ressourcen von Open Source Projekten umgehen, habe ich mich dazu entschlossen eben diese auszusperren. Wir hatten in der Vergangenheit crawls, die im #monitoring als #ddos gewertet wurden.

Diverse AS erfreuen sich nun einem dauerhaften 429, einige wenige die es für alle kaputt machen…

🔗 RE: "Please stop externalizing your costs directly into my face"

AI training is controversial at best. If you say AI is trained fair you're either very blind to the reality of things, or very naive - or both. None of the big AI tools are trained ethically, and this example from SourceHut just shows it.

👉 kevingimbel.de/link-blog/re-ht

kevingimbel.dePlease stop externalizing your costs directly into my face | kevingimbel.de
More from kevin ⁂ (he/him)

Je me demande si je ne vais pas faire ça... Clairement j'ai des pics de trafic venant de HK et SG qui font des recherches sur rss.gayfr.online... Des robots AI, sans aucun doute. Et difficiles à contrer car adresses IP multiples et user agent trompeur.

L'alternative étant de bloquer ces pays, mais la solution ne me plaît pas.

agate.blue/2025/03/27/Pi%C3%A9

Agate Blue · Piéger les robots d’indexation grâce à nginx et iocaineDepuis que les IA génératives et plus spécifiquement les LLM ont gagné en popularité, le trafic web automatisé lié aux activités d’indexation s’est démultiplié, souvent au point d’affecter la stabilité des sites indexés. Que vous souhaitiez saboter l’entrainement de ces LLM ou simplement empêcher ce trafic d’atteindre vos services et site web, il existe différentes techniques. Je vous en présente une dans cet article. Que sont les robots d’indexation ? Pour fonctionner, les LLM ont besoin d’être entrainés sur de très larges quantité de texte. Le web constitue une source de choix, que les éditeurs de LLM tels qu’OpenAI ou Google n’ont aucun scrupule à piller allègrement. SI vous hébergez un site web, il est donc probable qu’à intervalles plus ou moins régulier, des crawlers dédiés à la constitution des corpus d’entrainement indexent votre site afin d’en extraire le contenu. Quels problème posent-ils ? Ces robots posent au moins deux grand problèmes : Un problème éthique : en utilisant le web sans l’accord des auteurs des différents contenus utilisés, les éditeurs de LLM s’approprient purement et simplement le travail d’autres personnes Un problème technique : les robots d’indexation rajoutent une charge plus ou moins lourde sur les opérateurs de services en lignes, qui doivent absorber ce trafic supplémentaire à leurs frais. La charge additionnelle de ce trafic va bien souvent causer des interruptions partielles ou totales de service, comme dans le cas du robot Amazon Au delà de l’activité d’indexation pure, les LLM et l’IA générative sont aussi des désastres écologiques contre lesquels ont peut vouloir lutter, par exemple en perturbant leur fonctionnement. Comment bloquer les robots d’indexation ? Il existe plusieurs approches, plus ou moins complexes et intrusives. Le fichier robots.txt À l’instar des robots d’indexation utilisés par les moteurs de recherche, le fichier robots.txt est théoriquement la solution la plus simple à mettre en place. En utilisant une liste telle que celle établie par ai.robots.txt, vous pouvez créer ou modifier un fichier robots.txt interdisant le trafic des principaux robots utilisés par les LLM : # robots.txt User-agent: Amazonbot User-agent: GPTBot User-agent: PerplexityBot Disallow: / L’exemple précédent, bien que très incomplet, informe les robots Amazonbot, GPTBot et PerplexityBot qu’ils n’ont pas l’autorisation de parcourir le site. Cependant, l’efficacité de cette mesure est très limité. Si certain robots respectent effectivement les instructions présentes dans robots.txt, d’autres les ignorent complètement. Pour réellement bloquer ces robots, d’autres approches s’avèrent nécessaires. Détecter le trafic des robots d’indexation Pour pouvoir faire appliquer nos règles à certains robots, il faut dans un premier temps les identifier. Il existe au moins trois façons de procéder, qui peuvent être combinées : Via l’en-tête HTTP User-Agent : cet en tête est envoyé avec chaque requête HTTP. Les plus gros robots d’indexation documentent normalement la valeur de cet en-tête, par exemple pour OpenAI, les valeurs courantes sont OAI-SearchBot, ChatGPT-User et GPTBot. Le site Dark Visitor maintient une liste détaillée des robots les plus connus et des User-Agent associés. Via l’adresse IP : l’en-tête User-Agent est fourni par le client (dans ce contexte, le robot d’indexation). Un éditeur de LLM malintentionné peut donc fournir une valeur moins évidente pour contourner un éventuel blocage. En utilisant directement une adresse IP (ou, plus généralement, une plage d’adresses IP), on bénéficie à l’inverse d’une donnée fiable, qui n’est pas altérable. Cependant, pour contourner les blocages liés aux adresses IP, certains robots sont configurés pour indexer depuis de très nombreuses adresses IP sans lien évident et donc plus complexes à bloquer Via le comportement du client : plus complexe, cette approche utilise des signaux différents pour déterminer si un visiteur est susceptible d’être un robot ou non. Le projet Anubis, par exemple, s’assure qu’un client utilise un navigateur web récent disposant de certaines fonctionnalités. C’est un fonctionnement similaire à celui de Recaptcha. Ce type d’approche repose sur le fait d’exécuter du code javascript par le client. Dans la suite de cet article, j’utiliserai principalement la première méthode et vous montrerai comment exploiter la seconde si vous le souhaitez. Je laisserai la troisième méthode de côté, car elle pose pour moi problème en terme d’accessibilité. Réagir au trafic des robots d’indexation Une fois que l’on sait détecter le trafic issue de ces robots, on doit décider ce qu’on en fait. Deux options : 1. Bloquer le robot : l’approche la plus simple et la moins couteuse en ressources. Une fois le trafic identifié, on coupe la connexion au niveau du pare-feu ou bien on retourne une réponse HTTP 403 par exemple. 2. Piéger le robot : une approche plus complexe, dans laquelle on va volontairement servir des informations erronées au robot Personnellement, j’ai une nette préférence pour l’approche 2 que je trouve à la fois plus amusante et plus efficace. En effet, un robot bloqué au niveau du pare-feu ou via une réponse 403 risque de réessayer plus tard en dissimulant mieux son identité. De plus, en mentant au robot, on peut potentiellement injecter du contenu de mauvaise qualité dans les LLM et réduire ainsi leur utilité, tout en empêchant l’accès au contenu réel de la page web. Néanmoins, si vous préférez bloquer ce trafic, je fournirai plus loin les instructions pour le faire. Construire le piège Dans la seconde partie de cet article, je présenterai donc une approche basée sur nginx pour la détection et iocaine pour le piège. Je vous liste ci-dessous d’autres projets intéressants qui permettent d’arriver à un résultat similaire : nepenthes quixotic Détecter les robots avec nginx J’utilise nginx comme reverse-proxy sur mon serveur depuis de nombreuses années. Il fait donc sens pour moi d’utiliser cette approche. Si vous utilisez un autre reverse-proxy/serveur web, tel qu’apache ou caddy, les configurations fournies par la suite devront être adaptées. On commence par créer le fichier /etc/nginx/conf.d/bots.conf, dans lequel on place le contenu suivant: map $http_user_agent $bot_user_agent { default 0; # tiré de https://github.com/ai-robots-txt/ai.robots.txt/blob/main/robots.txt ~*amazonbot 1; ~*anthropic-ai 1; ~*applebot 1; ~*applebot-extended 1; ~*brightbot 1; ~*bytespider 1; ~*ccbot 1; ~*chatgpt-user 1; ~*claude-web 1; ~*claudebot 1; ~*cohere-ai 1; ~*cohere-training-data-crawler 1; ~*crawlspace 1; ~*diffbot 1; ~*duckassistbot 1; ~*facebookbot 1; ~*friendlycrawler 1; ~*google-extended 1; ~*googleother 1; ~*googleother-image 1; ~*googleother-video 1; ~*gptbot 1; ~*iaskspider 1; ~*icc-crawler 1; ~*imagesiftbot 1; ~*img2dataset 1; ~*isscyberriskcrawler 1; ~*kangaroo 1; ~*meta-externalagent 1; ~*meta-externalfetcher 1; ~*oai-searchbot 1; ~*omgili 1; ~*omgilibot 1; ~*pangubot 1; ~*perplexitybot 1; ~*petalbot 1; ~*scrapy 1; ~*semrushbot-ocob 1; ~*semrushbot-swa 1; ~*sidetrade 1; ~*timpibot 1; ~*velenpublicwebcrawler 1; ~*webzio-extended 1; ~*youbot 1; # ajoutez vos propres bots/user agents en dessous } geo $bot_ip { default 0; # IPs de Facebook, tiré de https://developers.facebook.com/docs/sharing/webmasters/web-crawlers#identify-5 # 69.63.176.0/21 1; # 69.63.184.0/21 1; # 66.220.144.0/20 1; # 69.63.176.0/20 1; # Ajoutez d'autres IPs ou plages en dessous } Tout fichier placé dans /etc/nginx/conf.d est chargé automatiquement par nginx. Ce fichier-ci n’a aucun effet en tant que tel, à part de rendre disponible la variable bot_user_agent, qui est calculée en utilisant la variable http_user_agent, autrement dit l’en-tête User-Agent envoyé par le client. Par défaut, cette valeur est initialisée à 0 pour chaque requête. Cependant, si la valeur de User-Agent correspond à un des patterns listés, comme GPTBot ou SideTrade (les valeurs ne sont pas sensibles à la casse), elle passe à 1. De la même manière manière, le second bloc initialise une variable bot_ip, basée sur l’adresse IP (module geo de nginx). Cette valeur est à 0 par défaut, et passe à 1 sur les plages d’IP spécifiées. Dans mon exemple, toutes les plages sont commentées car je n’utilise pas les IP pour la détection. Et voilà, tout les mécanismes nécessaires à la détection sont en place. Bloquer les robots Avant d’utiliser iocaine, nous allons valider que notre détection fonctionne en mettant en place un blocage simple utilisant nginx uniquement. Créez le fichier /etc/nginx/snippets/block_bots.conf et placez y le contenu suivant : if ($bot_user_agent) { # renvoyer une erreur 404 si le user agent est considéré comme un bot return 404; } if ($bot_ip) { # renvoyer une erreur 404 si l'IP est considérée comme un bot return 404; } Ces instructions vérifient la valeur des variables bot_user_agent et bot_ip et retourne une réponse HTTP 404 si la valeur est à 1. Si la valeur est à 0, rien ne se passe. J’utilise volontairement une erreur 404 ici plutôt qu’une 403 qui serait sémantiquement plus correcte. En effet, je pars du principe qu’une erreur 403 (accès refusé) risque d’être interprétée par les bots comme un indice qu’un blocage est en place, et les inciter à le contourner. La 404 brouille un peu plus les pistes. Notre snippet étant prêt, il ne nous reste plus qu’à l’utiliser sur un site. Pour cela, il faut l’inclure dans le bloc server {} d’une configuration nginx. Par exemple, dans mon cas, je vais éditer le fichier /etc/nginx/sites-enabled/monsite.conf, et y ajouter une instruction include, comme suit : server { listen 443 ssl; server_name monsite.com; # j'ai ajouté cette ligne include /etc/nginx/snippets/block_bots.conf; # reste de la configuration # ... } À ce stade nous pouvons tester la solution. Entrez les commandes suivantes dans un terminal : # vérifier que la configuration nginx est valide sudo nginx -t # si la commande précédente n'émet aucune erreur # on charge la nouvelle configuration sudo systemctl reload nginx # on fait une requête curl sur une page du site pour vérifier qu'il est toujours # accessible. Cette requête doit répondre correctement avec le contenu # de votre page curl https://monsite # on fait une requête curl avec un user-agent spécifique pour déclencher # le blocage. Cette requête doit renvoyer une réponse 404 curl -H "user-agent: GPTBot" https://monsite Si tout s’exécute correctement et donne les résultats attendus, félicitations, le gros du travail est fait. Vous pouvez sans problème inclure le snippet dans l’ensemble de vos blocs server {} et vous arrêter là, ou bien continuer la lecture pour mettre en place la partie piège. Piéger les robots avec iocaine iocaine est un générateur de contenu qui : Génére un contenu textuel d’apparence plausible pour un robot Génère le même contenu pour une même page visité, ce qui évite la détection par les bots Inclus sur chaque page générée des liens vers d’autres pages également générées Vous pouvez voir à quoi ressemblent les pages générées par iocaine sur la démo. En pratique, pour un robot, le contenu généré par iocaine agit comme un labyrinthe : une fois entré, il y a toujours de nouveaux liens à suivre, donc de pages à indexer. Plus le robot reste longtemps, plus il perd de temps et empoisonne ses données. Déploiement de iocaine La documentation officielle de iocaine est très bien faite, aussi je ne rentrerai pas trop dans les détails. J’ai choisi de déployer en utilisant docker, par simplicité. Tout d’abord, je crée le fichier /srv/iocaine/docker-compose.yml et j’y place le contenu suivant : services: iocaine: image: git.madhouse-project.org/iocaine/iocaine:latest restart: unless-stopped ports: # adresse du labyrinthe - '127.0.0.1:42069:42069' # adresse des métriques - '127.0.0.1:42070:42070' volumes: - ./data:/data environment: - IOCAINE__SERVER__BIND="0.0.0.0:42069" # Liste de mots à utiliser pour générer les liens - IOCAINE__SOURCES__WORDS="/data/mots.txt" # Liste de mots à utiliser pour générer le contenu de la page - IOCAINE__SOURCES__MARKOV=["/data/texte1.txt", "/data/texte2.txt", "/data/texte3.txt"] # activer les métriques - IOCAINE__METRICS__ENABLE=true - IOCAINE__METRICS__BIND="0.0.0.0:42070" - IOCAINE__METRICS__LABELS=["Host","UserAgent"] Ensuite, je télécharge des données textuelles pour que iocaine puisse générer du contenu : cd /srv/iocaine # je créé le dossier qui contiendra les données mkdir -p data # je télécharge une liste de mots en français curl -L \ https://raw.githubusercontent.com/clem9669/wordlists/refs/heads/master/dictionnaire_fr \ -o data/mots.txt # je télécharge quelques livres du domaine public en français depuis le site # du projet Gutemberg # https://www.gutenberg.org/ebooks/bookshelf/313 curl -L https://www.gutenberg.org/cache/epub/19657/pg19657.txt -o data/texte1.txt curl -L https://www.gutenberg.org/cache/epub/57430/pg57430.txt -o data/texte2.txt curl -L https://www.gutenberg.org/cache/epub/13818/pg13818.txt -o data/texte3.txt Notez qu’il vaut mieux utiliser des sources différentes de celles ci pour améliorer la qualité du contenu générer et éviter qu’il y ait trop de ressemblance d’une installation de iocaine à l’autre. Le rayon littérature française du Projet Gutemberg est rempli de références utilisables, assurez vous simplement de bien télécharger les livres en texte brut et pas dans un autre format (EPUB, Web, etc.) À ce stade, iocaine doit être utilisable. Je le lance avec sudo docker compose up -d et je vérifie qu’il répond correctement : curl http://127.0.0.1:42069 Cette commande doit retourner du texte généré par iocaine. Si c’est bien le cas, félicitations, il ne reste plus qu’à brancher iocaine à nginx ! Redirection du trafic nginx vers iocaine C’est très simple, on modifie le fichier /etc/nginx/snippets/block_bots.conf créé un peu plus tôt, et on remplace son contenu par : if ($bot_user_agent) { rewrite ^ /courgette$request_uri; } if ($bot_ip) { rewrite ^ /courgette$request_uri; } location /courgette { proxy_set_header Host $host; proxy_pass http://127.0.0.1:42069; } Au lieu de retourner une erreur 404, nginx transfère maintenant le trafic à iocaine, qui renvoie du contenu généré. J’ai appelé l’emplacement /courgette car ce chemin apparait sur la page générée par iocaine et la valeur /ai proposée dans la documentation me parait un peu trop flagrante. Je vous invite à utiliser un autre emplacement, toujours pour limiter les similarités d’une installation à l’autre, l’essentiel étant qu’elle n’entre pas en collision avec une page qui existe déjà sur un de vos sites. On relance nginx avec sudo nginx -t && sudo systemctl nginx reload et voilà, on peut faire un dernier test : # on fait une requête curl sur une page du site pour vérifier qu'il est toujours # accessible. Cette requête doit répondre correctement avec le contenu # de votre page curl https://monsite # on fait une requête curl avec un user-agent spécifique pour déclencher # le blocage. Cette requête doit renvoyer une réponse générée par iocaine curl -H "user-agent: GPTBot" https://monsite Bonus : métriques iocaine met à disposition un ensemble de métriques pour évaluer l’éfficacité du piège. Elles sont activées dans le fichier docker-compose.yml d’exemple que j’ai fourni un peu plus haut. Pour les consulter en ligne de commande, on effectue une requête curl sur http://127.0.0.1:42070/metrics, comme ceci : curl http://127.0.0.1:42070/metrics Les données renvoyées par iocaine ressemblent à ça : # HELP iocaine_garbage_served Total amount of garbage served (in bytes) # TYPE iocaine_garbage_served counter iocaine_garbage_served{host="agate.blue",user_agent="Mozilla/5.0 (compatible; ImagesiftBot; +imagesift.com)"} 3336 iocaine_garbage_served{host="site1.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.6998.165 Mobile Safari/537.36 (compatible; GoogleOther)"} 881 iocaine_garbage_served{host="site1.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)"} 1608 iocaine_garbage_served{host="site2.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 5.0) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; Bytespider; https://zhanzhang.toutiao.com/)"} 10347 iocaine_garbage_served{host="site2.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)"} 1041333 iocaine_garbage_served{host="site2.agate.blue",user_agent="meta-externalagent/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)"} 17854 # HELP iocaine_maze_depth Maximum explored depth of the maze (in path parts) # TYPE iocaine_maze_depth counter iocaine_maze_depth{host="agate.blue",user_agent="Mozilla/5.0 (compatible; ImagesiftBot; +imagesift.com)"} 4 iocaine_maze_depth{host="site1.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.6998.165 Mobile Safari/537.36 (compatible; GoogleOther)"} 2 iocaine_maze_depth{host="site1.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)"} 3 iocaine_maze_depth{host="site2.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 5.0) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; Bytespider; https://zhanzhang.toutiao.com/)"} 7 iocaine_maze_depth{host="site2.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)"} 11 iocaine_maze_depth{host="site2.agate.blue",user_agent="meta-externalagent/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)"} 5 # HELP iocaine_requests_total Total number of requests served # TYPE iocaine_requests_total counter iocaine_requests_total{host="agate.blue",user_agent="Mozilla/5.0 (compatible; ImagesiftBot; +imagesift.com)"} 2 iocaine_requests_total{host="site1.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.6998.165 Mobile Safari/537.36 (compatible; GoogleOther)"} 1 iocaine_requests_total{host="site1.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)"} 1 iocaine_requests_total{host="site2.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 5.0) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; Bytespider; https://zhanzhang.toutiao.com/)"} 6 iocaine_requests_total{host="site2.agate.blue",user_agent="Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)"} 518 iocaine_requests_total{host="site2.agate.blue",user_agent="meta-externalagent/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)"} 9 Ces données sont relativement peu lisibles telles quelles, il faut plutôt les exploiter via prometheus. La section iocaine_requests_total counter en particulier indique le nombre de requêtes traitées par iocaine pour chaque paire (Hôte, User-Agent). Ainsi, iocaine_requests_total{host="site2.agate.blue",user_agent="Mozilla/5.0 (compatible; PetalBot"} 518 m’indique que le robot PetalBot a effectué 518 requêtes sur le site site2.agate.blue, ce qui en fait pour l’instant et de très loin le bot le plus pénible à interroger mon serveur ;) Mises à jour De nouveaux robots voient le jour régulièrement. Pour les piéger, il vous faut ajouter leur User-Agent ou adresse IP dans le fichier /etc/nginx/conf.d/bots.conf, puis relancer nginx. Je vous invite à vous abonner aux mises à jour de ai.robots.txt et/ou à vous inscrire sur Dark Visitors pour obtenir une copie de leur liste. Vous pouvez également consulter les logs de vos serveurs web et y ajouter les robots qui vous semblent suspects.