• 作者: 作者
  • 时间:
  • 分类: 文章

最近在检查服务器日志的时候，突然发现了一堆奇怪的请求代理日志，让人看着有点心里发毛：全是尝试调用大模型接口的记录，但内容却非常诡异——不是生成代码，也不是写文章，全是“你是谁”、“帮我算个 13+27”、“计算几个大数的乘积”这种简单指令。

更让人膈应的是，这些请求返回的全是 HTTP 401 错误（Unauthorized）。这不禁让人怀疑：我的 API Key 是不是泄露了？我的 CPA (Cloudflare Proxy AI) 是不是被谁“蹭”了？

如果你也遇到了类似情况，别慌，这极大概率是互联网上的自动化脚本在进行全网“地毯式”扫描。今天我们就以此为例，拆解一下如何从日志分析入手，确认风险，并用简单几步把恶意流量拒之门外。

一、 透过日志看本质：是“黑产”还是“脚本”

先看一眼问题日志的关键部分。这位博主的日志显示，虽然调用的模型在变（一会儿是 Gemini，一会儿是 Claude），但请求 Payload（载荷）的模式高度相似。

典型的请求体是这样的：

{"contents": [{"parts": [{"text": "你是谁 是谁开发的你。另外请计算 27 + 66 等于多少..."}]}]}

或者在另一个针对 Claude 的请求中，Prompt 被进行了 Unicode 转义，解码后更直观：

“先用一句话说明你是谁...然后展示完整的逐步推理过程(chain-of-thought):计算 17 × 23 × 29 × 31 的乘积...”

这里有几个非常明显的特征：

  1. 数学题随时间变化：加数或乘积的数字会变，说明不是死循环请求，而是脚本在随机生成参数，试图探测不同的响应。
  2. 简单的身份验证：询问“你是谁”、“谁开发的”，这是攻击者在探测后端到底是哪个厂家的模型接口。
  3. User-Agent 极其普通：日志里显示的是标准的 Chrome/138.0...，没有任何黑客工具的特征，这叫拟态，试图绕过基于 UA 的简单过滤。
  4. 状态码 401：这是关键！服务器返回了 Invalid API key（无效的 API Key）。

结论： 既然返回的是 401，说明传入的 Key 是错的。这意味着你的 Key 并没有真的泄露，或者攻击者手里有一个过期的 Key 库，正在盲目尝试撞库。这就像有人拿着一把生锈的万能钥匙去试你家的锁，虽然没开，但试锁的过程让人很不爽，且消耗服务器资源。

二、 第一步：自查 API Key 安全

虽然大概率是撞库，但防人之心不可无。确认安全的第一步是排查自身：

  1. 检查服务商后台：登录 Google AI Studio 或 Anthropic 控制台，查看 Usage（用量）记录。如果有奇怪的扣费或非你操作的调用记录，那才是真的泄漏了，必须立刻吊销相关 Key。
  2. 审计环境变量：检查你的 Docker 容器环境变量、.env 文件或 Nginx 配置文件。切忌将 Key 硬编码在代码里提交到 GitHub。
  3. 确认代理暴露面：如果你的 CPA 也就是代理服务是直接挂载在公网 IP 上的（比如 http://1.2.3.4:8080），那被扫是迟早的事。一定要设置域名并开启 HTTP 认证或 IP 白名单。

三、 进阶防御：给服务器装上“防盗门”

既然确定是恶意扫描，我们总不能让它一直这么骚扰。这里有三个层级的防御策略，从简单到彻底。

1. Nginx 层面直接拦截（最推荐）

如果请求经过 Nginx 反向代理，我们可以在配置文件中加几行规则，直接封禁包含特定特征（比如那些奇怪的“你是谁”Prompt）的请求，或者限制非正常来源的访问。

开启 Nginx 的 request limit 限制：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
    # 每个 IP 每秒只允许 10 个请求，防止脚本高频扫描

    server {
        # ... 其他配置
        limit_req zone=one burst=20 nodelay;

        # 如果你知道扫描者的 IP 段，可以直接封
        # deny 1.2.3.0/24;
    }
}

2. 应用层防火墙

如果你使用的是 CPA（Cloudflare Proxy AI）这类开源项目，现在很多版本支持基础的路由鉴权。务必修改默认端口号（不要用 80/443 或默认的 3000），并且在前面加一层 Basic Auth（HTTP 基本认证）。

哪怕只是在 Nginx 加一层简单的密码认证，也能挡住 99% 的低级自动化脚本，因为脚本通常不会处理 401 认证弹窗逻辑。

Nginx Basic Auth 配置示例：

auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;

3. 针对 CPA 的特殊处理：隐藏版本信息

注意看返回的 Response Header，日志里有这些信息： X-Server-Version, X-CPA-Version, X-Server-Build-Date...

这就像是你的房子大门上贴了张条子，写着“我家锁是 B 品牌，生产日期是 2026 年”。这给扫描者提供了极大的便利（虽然这里的例子用了未来的时间戳 timestamp 2026，有点趣）。建议在代理配置中，尽量把这些暴露版本信息的 Header 给抹除掉。

在 Nginx 中可以这样做：

proxy_hide_header X-CPA-VERSION;
proxy_hide_header X-Server-Version;
# 隐藏所有不必要的 Header

四、 总结

遇到这种情况，心态要稳。

  • 看状态码：401 就是防御成功，没让你亏钱。
  • 查日志：分析请求特征，确认是随机扫描还是定向攻击。
  • 做加固：Nginx 限流 + Basic Auth + 隐藏版本信息，这三板斧下去，绝大多数脚本都会因为超时或认证失败而去骚扰别人了。

在这个 AI 爆发的年代，接口资源就是金钱。把自己的代理服务保护好，不仅能省心，更能避免因为被恶意刷爆余额而产生的“天价账单”。如果你有更好的防扫经验，欢迎在评论区交流！

标签: none

评论已关闭