Comment gérer le trafic "Autre" élevé et soudain dans les analyses de site ?

Salut à tous,

J’ai récemment remarqué une énorme augmentation du trafic « Autre » sur la page de santé de ma communauté de forum (tableau de bord d’administration Discourse → Rapports → Santé de la communauté).

Voici les détails :

  • Période : Autour de début août 2025
  • Trafic quotidien : a grimpé à plus de 100 000 visites « Autre » par jour
  • Exemple : Le 16 août 2025
  • Vues de page connectées : 12 531
  • Vues de page anonymes : 2 753
  • Robots d’exploration connus : 6 865
  • Trafic autre : 102 054 (la majorité de mon total de 124 000)

Ce trafic « Autre » semble anormal et est beaucoup plus élevé que l’activité réelle des utilisateurs. Les inscriptions sont stables, donc cela ne ressemble pas à une croissance réelle.

Mes questions sont les suivantes :

  1. Que signifie généralement le trafic « Autre » dans Discourse ?
  2. Cela pourrait-il être des bots, du spam ou un proxy inverse/CDN mal configuré ?
  3. Comment puis-je réduire ou filtrer ce trafic ? (par exemple, Nginx, pare-feu, paramètres Discourse)
  4. Est-il sûr de l’ignorer, ou cela affectera-t-il les performances/coûts ?

Toutes suggestions ou meilleures pratiques pour gérer correctement ce type de trafic tiers/bots seraient très utiles.

Merci d’avance !

1 « J'aime »

« Autres trafics » sont probablement des robots ou des robots d’exploration, plus de détails ici Understanding pageviews and the site traffic report
Vous pouvez consulter le rapport des robots d’exploration sur votre tableau de bord pour une source possible, et si vous le souhaitez, ralentir ou bloquer les robots… plus de détails à ce sujet dans : Controlling Web Crawlers For a Site

2 « J'aime »

J’ai eu des problèmes en juillet avec une tonne de requêtes provenant de Singapour. J’ai bloqué une plage d’adresses IP, ce qui a fonctionné pendant un certain temps, mais le problème est revenu plus fort en août (depuis Singapour, Hong Kong et le Mexique) avec des coûts CDN élevés et inattendus :face_with_steam_from_nose:

J’ai remarqué un nombre élevé de pages vues provenant d’Amazonbot, DataForSeoBot, meta-externalagent, SeekportBot, etc…

Cette documentation Controlling Web Crawlers For a Site dit :

Cette liste ne contient pas certains de mes robots les plus visités, mais j’ai néanmoins une question.
Serait-il conseillé d’ajouter toute cette liste au paramètre Agents utilisateur de robots bloqués ?
Existe-t-il un moyen d’ajouter en masse des noms de robots à partir d’un fichier .txt ?

1 « J'aime »
  1. Les robots d’exploration viennent dans l’intention d’indexer votre site dans les moteurs de recherche, donc l’augmentation du trafic provenant d’eux devrait être minimale, sauf s’il s’agit de bots qui se cachent en tant que robots d’exploration. De nombreux forums ne veulent pas être indexés par les robots d’exploration et c’est l’option pour le faire : Les robots d’exploration portent une identité/référence à leur source, donc ici vous pouvez ajouter le nom que vous voulez qui n’autorisera que cette source pour l’exploration (ahah, quel mot étrange :slight_smile: )

  2. La source la plus probable responsable de votre augmentation de trafic sont les bots et vous devez vérifier les journaux de votre serveur pour cela. Si vous connaissez quelqu’un qui ne connaît que les bases de Linux, je suggérerais cet outil de configuration de 2 minutes pour bloquer les pays ayant une mauvaise réputation de bots. (vous pouvez trouver cela facilement en ligne). Une fois configuré, il est toujours bon d’informer votre communauté qu’elle pourrait avoir besoin d’un VPN pour accéder à votre site si elle se retrouve en vacances dans ces pays. Voici l’outil, il est efficace, il réduira de 80 à 90 % les requêtes inutiles faites à votre serveur. Vous avez 2 modes et devez choisir l’un ou l’autre : pays autorisés ou pays interdits.

    GitHub - friendly-bits/geoip-shell: User-friendly and versatile geoblocker for Linux

  3. Vous pouvez également utiliser Geo Blocking plugin mais cela ne bloque que la vue de la page, mais pas les requêtes directes faites à votre serveur comme le fait l’outil ci-dessus.

1 « J'aime »

Eh bien, je suppose que cela ne résoudrait pas mon problème, car les robots consommeront de toute façon la bande passante du CDN.

1 « J'aime »

Es-tu totalement sûr de cela ? Parce que si c’est vrai, je vais immédiatement mettre en place un proxy inverse.

Modifier

L’IA a dit la même chose ici. Donc, ce sera un proxy inverse.

Réponse de l'IA

Le plugin GeoBlock pour Discourse utilise la base de données MaxMindDB pour déterminer le pays ou le réseau (ASN) d’un utilisateur en fonction de son adresse IP, mais le blocage réel se produit au niveau de l’application (à l’intérieur de l’application Discourse), et non au niveau du serveur ou du réseau/pare-feu.

En pratique :

  • Si l’IP d’un visiteur correspond à un pays ou un réseau bloqué, l’application Discourse renvoie une page d’erreur au visiteur au lieu du contenu du forum.
  • Le blocage ne se produit que lorsque la requête HTTP atteint l’application Discourse. En d’autres termes, les requêtes passent toujours par votre serveur web (par exemple, nginx) et votre conteneur Docker et atteignent le logiciel Discourse avant que l’utilisateur ne soit bloqué.
  • Cela signifie que vous verrez toujours ces requêtes dans les journaux de votre serveur et de votre proxy/nginx, même si l’utilisateur est finalement bloqué par Discourse.
  • Si vous avez besoin d’un blocage “dur” (empêchant l’accès avant même que la requête n’atteigne l’application Discourse), vous auriez besoin d’une solution GeoIP au niveau du serveur (comme le blocage au niveau nginx/iptables ou un outil externe).

Sources et plus d’informations :

Résumé :
Le plugin Discourse GeoBlock ne bloque pas les requêtes au niveau du réseau/serveur, mais seulement après que l’application Discourse a traité la requête. Si vous avez besoin d’empêcher tout accès avant que votre application ne voie la requête, vous devez utiliser une approche GeoIP au niveau du serveur.

Je n’ai pas utilisé share conversation parce que j’ai posé la question en finnois et que vous ne pouvez probablement pas la comprendre :winking_face_with_tongue:

1 « J'aime »

Implique que votre page est atteinte, donc oui vous êtes sur une couche plus proche du serveur qu’un blocage au niveau du pare-feu, cependant cela ne signifie pas qu’il s’agit d’un problème de sécurité qui nécessite un proxy inverse.
L’outil que j’ai proposé permet déjà de réduire les requêtes de 80 % et Discourse est une application sécurisée, maintenant si vous avez d’autres éléments hébergés sur votre serveur comme un site web, un proxy inverse peut être utile, en attendant il existe d’autres solutions pour bloquer les IP ayant de mauvaises réputations comme Crowdsec, demandez à votre IA à propos de Crowdsec light :wink:

2 « J'aime »

(auteur du plugin de géorepression ici)
Oui, le plugin de géorepression arrête les requêtes au niveau de l’application, bien qu’il le fasse à un stade très précoce. La raison en est qu’il a été conçu pour afficher une page d’erreur conviviale, il doit donc être capable de charger les ressources de Discourse et d’afficher cette page. Il enregistre également tous les blocages dans /logs s’il est configuré pour le faire.

Les autres avantages de cette approche sont la possibilité de configurer les pays et les réseaux bloqués depuis Discourse et la possibilité non seulement de bloquer l’accès, mais aussi de forcer la modération.

Si vous êtes préoccupé par l’inflation des journaux ou la consommation de bande passante CDN, le plugin n’est pas pour vous, mais franchement, je ne pense pas que ces deux choses importent beaucoup.

1 « J'aime »

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.