我的腾讯云服务器突然烧掉几百G流量？一场与"代码搬运工"的较量

——一个大学生运维新手，如何从海量监控数据里揪出偷流量的 "真凶"

引子：月初的账单惊魂

这个暑假，我一直在折腾自己的服务器集群：一台腾讯云、一台阿里云，中间用 FRP 隧道打通，再套上域名反代，运行着自己的博客、代码仓库、AI 网关……一切岁月静好，直到有一天我打开腾讯云控制台的流量账单——

"怎么会这样？" 我盯着那行数字愣了半天。

这个月我只有 300G 的出带宽额度，结果才过去几天，就已经消耗了一大半。而监控图表显示，我的服务器出流量像打了鸡血一样，最近几天每天狂飙 7~20GB，带宽被死死顶在 3.3Mbps 的满速线上纹丝不动。

这不是正常业务的曲线。一个普通学生服务器，凭什么每天往外吐这么多数据？

服务器中毒了？还是被人入侵当肉鸡挖矿了？

带着满脑子问号，我决定像侦探一样，把这件事查个水落石出。

第一步：从监控数据里找规律

腾讯云很贴心地提供了监控数据导出功能，我下载了最近这几天的出带宽、出流量、出包量、TCP 连接数等一系列 CSV 数据，用脚本一分析，立刻发现了端倪。

把数据按天一汇总，我看到了一个极其反常的 "三阶段" 模式：

中间那 9 天（8-04 ~ 8-12）几乎没什么流量，这才是服务器 "空闲" 该有的样子。可为什么偏偏在 8 月初和 8-13 之后，会突然爆出这么大的出流量？

更诡异的是，8-13 之后，带宽几乎恒定在 3.3 Mbps 的上限，一点波动都没有——这明显不是正常用户访问（正常应该有波峰波谷），而是有东西在不知疲倦地、持续地往外吐数据。

直觉告诉我：这一定是有异常流量在作祟。

第二步：SSH 上服务器，先排除"中毒"

我登录上腾讯云服务器，第一件事就是看进程、看 Docker、看定时任务。说实话，心里是有点忐忑的——万一是真中了挖矿木马怎么办？

结果排查下来，进程栏里都是熟人：

• YDService —— 腾讯云官方的云镜安全 Agent
• tat_agent —— 腾讯云自动化助手 Agent
• 还有我在跑的 Halo、Gitea、new-api、PostgreSQL 等 Docker 容器

全是我自己部署的服务，没有一个可疑进程。 定时任务里也只有系统自带的 sysstat、ntp 之类的正常任务。

服务器也没有被挖矿、没有后门、没有被人入侵的迹象。但流量到底是怎么跑掉的？

第三步：从容器日志里揪出"流量大户"

既然系统是干净的，那问题一定出在我自己跑的某个服务上。我用了一个很笨但很有效的办法——看各个 Docker 容器的日志体积。

这不看不要紧，一看吓一跳：

-rw-r--r-- 220MB  →  new-api   （AI 网关）
-rw-r--r--  16MB  →  Gitea     （代码仓库）
-rw-r--r--   3MB  →  Halo      （博客）

new-api 的日志竟然有 220MB！比其他所有服务加起来还大得多。我一度以为它就是元凶。

但当我打开 new-api 的日志内容，却发现一个转折：它 8 月每天只有 3000 多次请求，相当平稳，并没有突然暴增。那 220MB 是两个月累积的。看来它常年被各种扫描器骚扰（有 5700 次登录尝试、几千次 401），但因为新账号额度为零、验证码挡着，实际并没有产生大流量。

这时我注意到了另一个看似不起眼的角色——Gitea。

第四步：Gitea 日志里的恐怖数字

Gitea 的日志只有 16MB，但当我按天统计时，一个惊人的数字跳了出来：

这 16MB 日志里，有 5.3 万行全部集中在 8-18 这一天！

也就是说，Gitea 在短短十几个小时里，收到了海量的 HTTP 请求。我继续深挖，锁定了来源：

  46571 个请求返回 200（成功访问到内容）
  50996 个请求（98.6%）来自同一个网段 → 47.123.117.0/24

47.123.117.x —— 这是一个 /24 的子网，里面有几十台机器，在同一时刻、并行地、地毯式地访问我 Gitea 上的代码仓库！

它们访问的路径更是暴露了意图：/src/commit/xxx、/blame/...、/raw/...、/compare/...——这是把我的每个仓库、每个文件的源码逐页抓取下来！它们甚至不挑，连 Gobang-Game、PathEditor、l-language 这些小众项目全都扒。

这根本不是人类浏览，这是机器人扒库——有人想把我的整个 Gitea 镜像走。

第五步：为什么它能进来？一个隐蔽的架构漏洞

查到这一步，一个疑问又冒了出来：我的腾讯云安全组明明只对自家网段开放了 3000 端口，这个 47.123.117.x 是怎么访问到 Gitea 的？

我最初甚至搞错了，以为是端口暴露问题。直到我查看腾讯云控制台导出的防火墙规则，才恍然大悟——安全组配置得其实很好，3000/222/22 都只放行了内网 IP。

真正暴露我 Gitea 的，是这条链路：

外部抓取机器人
   │ 通过公网域名访问
   ▼
阿里云 OpenResty 反代（lhy-git.liuhangyv.top）
   ▼
阿里云 frps（接收 FRP 隧道）
   ▼  ← 关键：FRP 隧道绕过了腾讯云安全组
腾讯云 frpc → 本地 Gitea

原来，我为了 "用阿里云做中转、通过域名访问腾讯云上的应用"，搭建了 FRP 隧道，把腾讯云的 Gitea、Halo 等通过阿里云公网域名暴露了出去。这条路是公网可达的，完全绕过了腾讯云的安全组限制。

而 47.123.117.x 恰好是阿里云某机房网段——攻击者大概率就藏在这些云主机里，从阿里云同一个机房轻轻松松就摸到了你的服务。难怪安全组挡不住它。

第六步：马上止血，改配置！

真凶找到了，接下来就是治。

最稳妥的办法，既不是把所有仓库改成私有（那样太一刀切），而是把 Gitea 的匿名可见关掉——改成只有登录用户才能查看仓库。这样：

• 未登录的抓取机器人 → 直接被登录墙挡在外面
• 我和协会成员正常登录使用 → 不受影响
• 19 个公开仓库 → 依然对登录用户可见

命令很简单，改 app.ini 里的一行配置：

[service]
REQUIRE_SIGNIN_VIEW = true   # 原来这里是 false

改完备份好文件，重启 Gitea 容器，生效！同样的问题在协会的 Gitea 上也存在，索性一并修了。两台 Gitea 几乎是在同一时间段被同一批 IP 盯上的，还好发现得不算太晚。

第七步：验证——流量终于安静了

修复后过了整整一夜，第二天早上我再次导出监控数据，长舒了一口气：

持续一整夜的观察证实：流量稳稳回到了低位，那批持续抓取的机器人被彻底挡在了门外。

复盘：这次排查教会我的几件事

回头看，这次 "流量惊魂" 其实暴露了不少值得反思的地方，也让我积累了宝贵的经验：

1. "监听端口" 不等于 "暴露公网" —— 服务器内部 0.0.0.0 监听，和真正能被公网访问，是两回事，后者要看安全组 / 防火墙。我一开始就被这个误导了。

2. FRP 这类内网穿透工具，是绕开安全组的一扇 "后门" —— 它让内网服务从另一个公网入口暴露出去。用穿透工具时，一定要想清楚：这相当于把服务公开了，对它的认证、鉴权要求只会更高。

3. 查流量大户，日志体积是最好的线索 —— 哪个容器日志突然暴涨，往往就是它被大量访问了。

4. "匿名可见 + 开放注册" 是自找麻烦 —— 这次能成功的原因，是 Gitea 配置了游客可见。改成 "仅登录可见" 是性价比最高的止血手段，既不失灵活性，又能挡掉 99% 的爬虫。

5. 遇事别慌，先看数据 —— 从监控导出、到日志分析、再到定位 IP 网段，每一步都有迹可循。排查异常流量，本质上就是一场基于证据的推理游戏。

现在我的服务器又恢复了往日的平静。如果你也遇到类似 "流量莫名飙高" 的情况，希望这篇文章能给你一些排查的思路——先看监控找异常窗口，再登服务器找可疑进程，最后翻日志锁定真凶。别急着重装系统，很多时候，问题的答案就藏在那一条条日志里。