# 如何处理网站分析中突然出现的“其他流量” **URL:** \ **Category:** Support\ **Created:** [2025年八月22日 04:43 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790 "2025-08-22T04:43:48Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Monikas](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/monikas/32/375316_2.png) [@Monikas](https://meta.discourse.org/u/Monikas)\ **Post date:** [2025年八月22日 04:43 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790/1 "2025-08-22T04:43:48Z")
大家好， 我最近注意到我的论坛社区健康页面（Discourse 管理仪表板 → 报告 → 社区健康）上的“其他流量”出现了巨大的增长。 ![IMG_3913](https://global.discourse-cdn.com/meta/original/4X/e/8/b/e8b2019d235f9ee2d637a317a38b1ca60ed4db25.jpeg) 以下是详细信息： - 时期：大约在 2025 年 8 月初 - 每日流量：每天飙升至 100k+ 的“其他流量” - 示例：2025 年 8 月 16 日 - 登录页面浏览量：12,531 - 匿名页面浏览量：2,753 - 已知爬虫：6,865 - 其他流量：102,054（占我总计 124k 的大部分） ![IMG_3912](https://global.discourse-cdn.com/meta/original/4X/7/2/7/7278915c73974d89c82794fdcf32c922ff7412d9.jpeg) 这种“其他流量”似乎很不正常，并且远高于真实用户活动。注册量保持稳定，因此看起来不像真实的增长。 我的问题是： 1. 在 Discourse 中，“其他流量”通常意味着什么？ 2. 这可能是机器人、垃圾邮件或配置错误的反向代理/CDN 吗？ 3. 我该如何减少或过滤这种流量？（例如 Nginx、防火墙、Discourse 设置） 4. 直接忽略是否安全，还是会影响性能/成本？ 任何关于如何妥善处理此类第三方/机器人流量的建议或最佳实践都将非常有帮助。 提前感谢！ ---
**Author:** ![awesomerobot](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/awesomerobot/32/142900_2.png) [@awesomerobot](https://meta.discourse.org/u/awesomerobot)\ **Post date:** [2025年八月25日 19:00 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790/2 "2025-08-25T19:00:57Z")
“其他流量”很可能是机器人或爬虫，更多详细信息请参见 [Understanding pageviews and the site traffic report](https://meta.discourse.org/t/understanding-pageviews-and-the-site-traffic-report/324062/) 您可以在仪表板上查看爬虫报告以了解可能的来源，如果您愿意，可以减慢或阻止它……有关如何执行此操作的更多详细信息，请参见：[Controlling Web Crawlers For a Site](https://meta.discourse.org/t/controlling-web-crawlers-for-a-site/244925) ---
**Author:** ![Canapin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/canapin/32/119591_2.png) [@Canapin](https://meta.discourse.org/u/Canapin)\ **Post date:** [2025年八月26日 20:49 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790/3 "2025-08-26T20:49:20Z")
我七月份收到了大量来自新加坡的请求，遇到了问题。我屏蔽了一个 IP 地址范围，起初奏效了，但八月份问题变得更严重（来自新加坡、香港和墨西哥），导致 CDN 成本高得离谱 😤 我注意到来自 Amazonbot、DataForSeoBot、meta-externalagent、SeekportBot 等的页面浏览量很高…… 这份文档 [Controlling Web Crawlers For a Site](https://meta.discourse.org/t/controlling-web-crawlers-for-a-site/244925?u=canapin) 提到： > [@Discourse](#): > > 要获取不可信的网络爬虫记录，您可以参考此列表：[apache-ultimate-bad-bot-blocker/robots.txt/robots.txt at master · mitchellkrogza/apache-ultimate-bad-bot-blocker · GitHub](https://github.com/mitchellkrogza/apache-ultimate-bad-bot-blocker/blob/master/robots.txt/robots.txt) 此列表不包含我访问量最高的一些爬虫，但我仍然有一个问题。 将整个列表添加到“ **屏蔽的爬虫用户代理** ”设置中是否明智？ 是否有办法从 `.txt` 文件批量添加爬虫名称？ ---
**Author:** ![opcourdis](https://avatars.discourse-cdn.com/v4/letter/o/45deac/32.png) [@opcourdis](https://meta.discourse.org/u/opcourdis)\ **Post date:** [2025年八月26日 21:46 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790/4 "2025-08-26T21:46:40Z")
1. 爬虫程序的目的是将您的网站编入搜索引擎索引，因此来自它们的流量增长应该很小，除非它们是伪装成爬虫程序的机器人。许多论坛不希望被爬虫程序索引，这是实现这一目标的选项：爬虫程序会携带其来源的身份/引用，因此您可以在此处添加任何您想要的名称，以便仅允许该来源进行爬取（哈哈，真是个奇怪的词 🙂 ） 2. 造成流量增加的最可能来源是机器人，您必须检查服务器日志。如果您认识一个只懂最基本 Linux 操作的人，我建议使用这个 2 分钟设置工具来阻止那些以不良机器人声誉而闻名的国家/地区（您可以在网上轻松找到它）。设置好之后，最好让您的社区知道，如果他们碰巧在这些国家/地区度假，可能需要使用 VPN 才能访问您的网站。这是该工具，它很有效，可以减少 80-90% 的不必要服务器请求。您有 2 种模式，必须选择其中一种：允许的国家/地区或禁止的国家/地区。 3. 您也可以使用 [https://meta.discourse.org/t/geo-blocking-plugin/227824，但它只阻止页面浏览，而不能像上述工具那样阻止直接向您的服务器发出的请求。](https://meta.discourse.org/t/geo-blocking-plugin/227824%EF%BC%8C%E4%BD%86%E5%AE%83%E5%8F%AA%E9%98%BB%E6%AD%A2%E9%A1%B5%E9%9D%A2%E6%B5%8F%E8%A7%88%EF%BC%8C%E8%80%8C%E4%B8%8D%E8%83%BD%E5%83%8F%E4%B8%8A%E8%BF%B0%E5%B7%A5%E5%85%B7%E9%82%A3%E6%A0%B7%E9%98%BB%E6%AD%A2%E7%9B%B4%E6%8E%A5%E5%90%91%E6%82%A8%E7%9A%84%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%8F%91%E5%87%BA%E7%9A%84%E8%AF%B7%E6%B1%82%E3%80%82) ---
**Author:** ![Canapin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/canapin/32/119591_2.png) [@Canapin](https://meta.discourse.org/u/Canapin)\ **Post date:** [2025年八月27日 13:46 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790/6 "2025-08-27T13:46:22Z")
> [@Canapin](#): > > 此列表不包含我访问次数最多的某些机器人，但我仍然有一个问题。 > 将此列表全部添加到“ **被阻止的爬虫用户代理** ”设置中是否明智？ > 是否有办法从 `.txt` 文件批量添加机器人名称？ 嗯，我猜这并不能解决我的问题，因为机器人无论如何都会消耗 CDN 带宽。 ---
**Author:** ![Jagster](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jagster/32/192154_2.png) [@Jagster](https://meta.discourse.org/u/Jagster)\ **Post date:** [2025年八月27日 14:58 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790/7 "2025-08-27T14:58:25Z")
> [@opcourdis](#): > > 您也可以使用 [Geo Blocking 插件](https://meta.discourse.org/t/geo-blocking-plugin/227824)，但它只阻止页面视图，而不阻止像上面工具那样直接向您的服务器发出的请求。 您确定吗？因为如果属实，我将立即设置反向代理。 **编辑** AI 也这么说。所以，将使用反向代理。 > **AI 回答** > > Discourse 的 GeoBlock 插件使用 MaxMindDB 数据库，根据用户的 IP 地址确定其国家或网络 (ASN)，但实际的阻止发生在应用程序级别（在 Discourse 应用内部），而不是在服务器或网络/防火墙级别。 > > 实际操作中： > > - 如果访问者的 IP 匹配被阻止的国家或网络，Discourse 应用程序将向访问者返回一个错误页面，而不是论坛内容。 > - 阻止发生在 HTTP 请求到达 Discourse 应用程序之后。换句话说，请求仍然会通过您的 Web 服务器（例如 nginx）和 Docker 容器，并在用户被阻止之前到达 Discourse 软件。 > - 这意味着即使最终被 Discourse 阻止，您仍然会在服务器和代理/nginx 日志中看到这些请求。 > - 如果您需要“硬”阻止（在请求到达 Discourse 应用之前就阻止访问），您需要一个服务器级别的 GeoIP 解决方案（例如 nginx/iptables 级别的阻止或外部工具）。 > > 来源和更多信息： > > - [Geo Blocking 插件 - meta.discourse.org](https://meta.discourse.org/t/geo-blocking-plugin/227824) > - 插件 GitHub 文档：[GitHub - communiteq/discourse-geo-blocking](https://github.com/communiteq/discourse-geo-blocking) > > 总结： > Discourse GeoBlock 插件不在网络/服务器级别阻止请求，而是在 Discourse 应用程序处理请求后才阻止。如果您需要在应用程序看到请求之前阻止任何访问，则必须使用服务器级别的 GeoIP 方法。 > > _我没有使用_ 分享对话\*，因为我用芬兰语提问，你们可能无法理解\* 😜 ---
**Author:** ![opcourdis](https://avatars.discourse-cdn.com/v4/letter/o/45deac/32.png) [@opcourdis](https://meta.discourse.org/u/opcourdis)\ **Post date:** [2025年八月27日 15:13 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790/8 "2025-08-27T15:13:57Z")
![image](https://global.discourse-cdn.com/meta/original/4X/d/8/0/d80c325a176b6d88e7149b5507a6c14e5016cbe6.png) 这意味着您的页面已被访问，因此您比防火墙级别的阻止更接近服务器，但这并不意味着它是一个需要反向代理的安全问题。 我提出的工具已经减少了 80% 的请求，并且 Discourse 是一个安全的应用程序，现在如果您在服务器上托管了其他东西，例如网站，反向代理可能会有用，同时还有其他方法可以阻止声誉不佳的 IP，例如 Crowdsec，询问您的 AI 关于 Crowdsec light 😉 ---
**Author:** ![RGJ](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rgj/32/523185_2.png) [@RGJ](https://meta.discourse.org/u/RGJ)\ **Post date:** [2025年八月28日 21:43 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790/9 "2025-08-28T21:43:02Z")
（地理封锁插件作者在此） 是的，地理封锁插件在应用程序级别停止请求，尽管它在非常早的阶段就完成了。这样做的原因是它被设计为显示用户友好的错误页面，因此它必须能够加载 Discourse 资源并显示该页面。如果配置了，它还会将任何阻止记录到 `/logs`。 这种方法的其他优点是能够从 Discourse 内部配置被阻止的国家和网络，以及不仅能够阻止访问，还能强制进行审核。 如果您担心日志膨胀或 CDN 带宽消耗，该插件不适合您，但说实话，我认为这两件事关系不大。 ---
**Author:** ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)\ **Post date:** [2025年九月27日 21:43 UTC](https://meta.discourse.org/t/how-to-deal-with-sudden-high-other-traffic-in-site-analytics/379790/10 "2025-09-27T21:43:07Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.