Ich habe kürzlich einen enormen Anstieg des „Anderen Traffics“ auf der Community-Gesundheitsseite meines Forums (Discourse Admin Dashboard → Berichte → Community-Gesundheit) bemerkt.
Dieser „Andere Traffic“ scheint abnormal zu sein und ist viel höher als die tatsächliche Benutzeraktivität. Anmeldungen sind stabil, es sieht also nicht nach echtem Wachstum aus.
Meine Fragen sind:
Was bedeutet „Anderer Traffic“ normalerweise in Discourse?
Könnte es sich um Bots, Spam oder eine falsch konfigurierte Reverse-Proxy/CDN handeln?
Wie kann ich diesen Traffic reduzieren oder filtern? (z. B. Nginx, Firewall, Discourse-Einstellungen)
Ist es sicher, ihn einfach zu ignorieren, oder wird er die Leistung/Kosten beeinträchtigen?
Jeder Vorschlag oder jede Best Practice, um diese Art von Drittanbieter-/Bot-Traffic ordnungsgemäß zu handhaben, wäre sehr hilfreich.
„Anderer Traffic“ sind wahrscheinlich Bots oder Crawler, weitere Details hier: Understanding pageviews and the site traffic report
Sie können den Crawler-Bericht auf Ihrem Dashboard nach einer möglichen Quelle überprüfen und ihn bei Bedarf verlangsamen oder blockieren. Weitere Details dazu finden Sie unter: Controlling Web Crawlers For a Site
Ich hatte im Juli Probleme mit unzähligen Anfragen aus Singapur. Ich habe einen IP-Bereich blockiert, was eine Weile funktionierte, aber das Problem kam im August härter zurück (aus Singapur, Hongkong und Mexiko) mit hohen und unerwarteten CDN-Kosten
Ich bemerkte hohe Seitenaufrufe von Amazonbot, DataForSeoBot, meta-externalagent, SeekportBot usw.
Diese Liste enthält einige meiner meistbesuchten Bots nicht, aber ich habe trotzdem eine Frage.
Wäre es ratsam, diese ganze Liste zu den Blockierte Crawler User Agents hinzuzufügen?
Gibt es eine Möglichkeit, Bot-Namen aus einer .txt-Datei in großen Mengen hinzuzufügen?
Crawler kommen mit der Absicht, Ihre Website in Suchmaschinen zu indizieren. Daher sollte der Traffic von ihnen minimal sein, es sei denn, es handelt sich um Bots, die sich als Crawler ausgeben. Viele Foren möchten nicht von Crawlern indiziert werden, und dies ist die Option, dies zu tun: Crawler tragen eine Identität/Referenz zu ihrer Quelle, sodass Sie hier jeden Namen hinzufügen können, der nur diese Quelle für das Crawling zulässt (ahah, ein seltsames Wort )
Die wahrscheinlichste Ursache für Ihre Traffic-Zunahme sind Bots, und Sie müssen die Protokolle Ihres Servers daraufhin überprüfen. Wenn Sie jemanden kennen, der nur die Grundlagen von Linux beherrscht, würde ich dieses 2-minütige Setup-Tool empfehlen, um Länder mit schlechtem Ruf für Bots zu blockieren (Sie können dies leicht online finden). Nach der Einrichtung ist es immer noch gut, Ihre Community wissen zu lassen, dass sie möglicherweise ein VPN benötigen, um Ihre Website zu erreichen, wenn sie in diesen Ländern Urlaub machen. Hier ist das Tool, es ist effizient, es reduziert unnötige Anfragen an Ihren Server um 80-90%. Sie haben 2 Modi und müssen entweder zulässige Länder oder verbotene Länder wählen.
Sie können auch Geo Blocking plugin verwenden, aber dies blockiert nur die Seitenaufrufe, nicht aber die direkten Anfragen an Ihren Server, wie es das obige Tool tut.
[quote=„Canapin, post:3, topic:379790″]
Diese Liste enthält nicht einige meiner meistbesuchten Bots, aber ich habe trotzdem eine Frage.
Wäre es ratsam, diese gesamte Liste zu den Blockierten Crawler-User-Agents hinzuzufügen?
Gibt es eine Möglichkeit, Bot-Namen aus einer .txt-Datei massenhaft hinzuzufügen?
[/quote]
Nun, ich schätze, das würde mein Problem nicht lösen, da die Bots sowieso CDN-Bandbreite verbrauchen werden.
Sind Sie sich da ganz sicher? Denn wenn das stimmt, werde ich sofort einen Reverse-Proxy einrichten.
Bearbeiten
Die KI hat hier dasselbe gesagt. Also wird es ein Reverse-Proxy sein.
Antwort der KI
Das GeoBlock-Plugin für Discourse verwendet die MaxMindDB-Datenbank, um das Land oder Netzwerk (ASN) eines Benutzers anhand seiner IP-Adresse zu ermitteln. Die eigentliche Sperrung erfolgt jedoch auf Anwendungsebene (innerhalb der Discourse-App) und nicht auf Server- oder Netzwerk-/Firewall-Ebene.
In der Praxis:
Wenn die IP eines Besuchers mit einem blockierten Land oder Netzwerk übereinstimmt, gibt die Discourse-Anwendung eine Fehlerseite an den Besucher zurück, anstatt Foreninhalte.
Die Sperrung erfolgt erst, wenn die HTTP-Anfrage die Discourse-Anwendung erreicht. Mit anderen Worten: Anfragen durchlaufen immer noch Ihren Webserver (z. B. nginx) und den Docker-Container und erreichen die Discourse-Software, bevor der Benutzer gesperrt wird.
Das bedeutet, dass Sie diese Anfragen immer noch in Ihren Server- und Proxy-/nginx-Protokollen sehen werden, auch wenn der Benutzer letztendlich von Discourse gesperrt wird.
Wenn Sie eine “harte” Sperrung benötigen (Zugriff verhindern, noch bevor die Anfrage die Discourse-App erreicht), benötigen Sie eine GeoIP-Lösung auf Serverebene (wie z. B. Sperrung auf nginx/iptables-Ebene oder ein externes Tool).
Zusammenfassung:
Das Discourse GeoBlock-Plugin blockiert Anfragen nicht auf Netzwerk-/Serverebene, sondern erst, nachdem die Discourse-Anwendung die Anfrage verarbeitet hat. Wenn Sie jeglichen Zugriff verhindern müssen, bevor Ihre Anwendung die Anfrage sieht, müssen Sie einen GeoIP-Ansatz auf Serverebene verwenden.
Ich habe keine Konversation geteilt, weil ich auf Finnisch gefragt habe und ihr das wahrscheinlich nicht könnt
Impliziert, dass Ihre Seite erreicht wird, also sind Sie auf einer näheren Ebene zum Server als ein Block auf Firewall-Ebene, es bedeutet jedoch nicht, dass es sich um ein Sicherheitsproblem handelt, das einen Reverse-Proxy erfordert.
Das von mir vorgeschlagene Tool reduziert die Anfragen bereits um 80 % und Discourse ist eine sichere App. Wenn Sie andere Dinge auf Ihrem Server gehostet haben, wie z. B. eine Website, kann ein Reverse-Proxy nützlich sein. In der Zwischenzeit gibt es andere Lösungen, um IPs mit schlechtem Ruf zu blockieren, wie z. B. Crowdsec. Fragen Sie Ihre KI nach Crowdsec light
(Autor des Geoblocking-Plugins hier)
Ja, das Geoblocking-Plugin stoppt Anfragen auf Anwendungsebene, obwohl es dies in einer sehr frühen Phase tut. Der Grund dafür ist, dass es so konzipiert wurde, dass es eine benutzerfreundliche Fehlerseite anzeigt, sodass es die Discourse-Assets laden und diese Seite anzeigen können muss. Es protokolliert auch alle Blöcke in /logs, wenn dies konfiguriert ist.
Weitere Vorteile dieses Ansatzes sind die Möglichkeit, die blockierten Länder und Netzwerke innerhalb von Discourse zu konfigurieren, und die Möglichkeit, nicht nur den Zugriff zu blockieren, sondern auch die Moderation zu erzwingen.
Wenn Sie Bedenken hinsichtlich Log-Inflation oder CDN-Bandbreitenverbrauch haben, ist das Plugin nichts für Sie, aber ehrlich gesagt glaube ich nicht, dass diese beiden Dinge eine große Rolle spielen.
)
