APIKeyRotator 轻量级 API KEY 管理和代理解决方案

在互联网浸泡久了，手上肯定有不少网站的 API KEY，而且很多时候还不止一个（懂得都懂），之前管理起来就很麻烦，可能就随便弄到笔记里面记下来，后面找起来也麻烦。而且在代码中使用也很麻烦，像我以前就是硬编码写个随机函数来调用，麻烦至极。

然后最近就在想，有没有相关的工具能够方便去管理这些网站的 API KEY 呢。于是接触到像 ONE API 和基于它二开的 NEW API，但是它们好像都偏向于管理 AI大模型 的，而且感觉这两个项目都有点重，不太合适我这种小虾米的需求：轻量级，通过一个统一的代理入口，实现密钥的自动轮询、负载均衡和安全隔离。

于是，我自己就开始着手来做这个事情，大概用了5天的时间，最终写了这个项目 APIKeyRotator

项目介绍

简单介绍一下这个项目，这里面有分为前端配置后台和后端接口两个部分。

前端配置后台

就是一个很简单的配置代理和管理KEY的后台。

创建服务 里面，是分为 通用API 和 LLM API ，主要区分通用的网站 API 和 AI 模型的代理。

通用API

在 通用API 中，一般密钥的位置都是通过 Query 参数的方式传递，像 天气 API，官方的授权密钥参数为 access_key，所以最终的配置信息如下：

然后相应的为这个代理请求配置号池，点击 管理Key，并在面板中添加自己的官方 key 即可。

LLM API

在 LLM API 中，一般密钥的位置都是通过 Header 参数的方式传递，像 OpenRouter，官方的授权密钥通过 Authorization 的方式传递，所以最终的配置信息如下：

由于系统这边已经针对不同的 API 格式 做了适配，所以下面的密钥位置 和 密钥名称 可以为空，如果有特殊情况的可以按实际填写。

最后相应的为这个代理请求配置号池，点击 管理Key，并在面板中添加自己的官方 key 即可。

后端接口

后端接口这块，一开始我是使用 Python 写的，后面在我的小鸡上部署的时候发现占用的内存有点大，最终又用 Go 重构了一次（当然是用 AI 写的，所以调试用了不少时间）。

使用示例

通用 API

以下是一个使用 Python requests 库调用 天气 API 的示例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
import requests

# 配置代理参数
proxy_url = "http://PROXY_PUBLIC_BASE_URL/proxy/weather/current"
proxy_key = "<GLOBAL_PROXY_KEY>"

# 查询参数
params = {
    "query": "London"
    # 在代理请求转发至目标 API 时，系统会轮询后台配置的真实 API 密钥，并将其拼接到原始授权参数 access_key（该参数由后台配置）中。
）中
}

# 设置请求头
headers = {
    "X-Proxy-Key": proxy_key
}

# 发起请求
response = requests.get(proxy_url, params=params, headers=headers)

# 处理响应
if response.status_code == 200:
    data = response.json()
    print(f"天气信息: {data}")
else:
    print(f"请求失败，状态码: {response.status_code}")

在这个示例中：

weather 是在管理界面配置的服务标识 (Slug)
current 是目标 API 的路径
PROXY_PUBLIC_BASE_URL 是代理服务地址
<GLOBAL_PROXY_KEY> 是配置的全局代理密钥，通过环境变量 .env 设置

代理会自动将请求转发到配置的目标URL，并将路径和查询参数附加到目标地址上。

LLM API 代理

以 openai Python SDK 为例，结合使用 OpenRouter 模型，可以通过修改 base_url 来使用本项目的代理服务。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
from openai import OpenAI

client = OpenAI(
  # 格式为 http://<PROXY_PUBLIC_BASE_URL>/llm/<服务标识 (Slug)>
  base_url="http://PROXY_PUBLIC_BASE_URL/llm/openrouter-api",
  api_key="<GLOBAL_PROXY_KEY>",
)

completion = client.chat.completions.create(
  # 模型名称请参考具体提供商的文档
  model="openai/gpt-4o",
  messages=[
    {
      "role": "user",
      "content": "What is the meaning of life?"
    }
  ]
)

print(completion.choices[0].message.content)

其中 PROXY_PUBLIC_BASE_URL 和 GLOBAL_PROXY_KEY 是在 .env 文件中配置的环境变量。

写在最后

有些 API 它会监控同一IP，或者像大模型，它会监控上下文，所以这种轮询密钥的方式也是有一定的风险，不过感觉搞 2-3个 Key 应该问题不大。反正有些 API 我也使用了一段时间，暂时没问题哈。

感觉目前这版已经够我个人用了，像再加上一些 KEY 控制限流什么的，感觉就开始往 NEW API 项目那边靠了，如果大家有一些其他的需求，可以 fork 项目进行二开哈。