我用 AI 做了一次服务器安全审计，整理了一套适合个人站长的检查清单

最近在折腾 AI API 中转和一些工作流项目，服务器、反代、数据库、上游 API、生图接口都堆在一起之后，我发现一个问题：

很多人用 API 中转站的时候，最先关心的是：

• 价格贵不贵
• 速度快不快
• 模型全不全
• 会不会 502

这些当然重要，但真做了一段时间后，我觉得还有一个更底层的问题：

你的 Key、Prompt、业务数据经过中转站的时候，到底安不安全？

因为中转站的位置其实挺敏感的。

用户的请求会先到中转站，再转发给上游。也就是说，中转层理论上能看到你的请求、模型返回、错误信息，甚至可能影响上下文和工具调用。

如果只是随便聊天，可能感受没那么明显。但如果你拿它做业务，比如客服、合同分析、代码生成、自动化 Agent、客户数据处理，那这个问题就不能只靠一句“我很安全”来解决。

所以我最近拿自己的中转站做了一次安全自查，也顺便发现了一个挺有意思的开源项目，叫 API Relay Audit。

项目地址：
https://github.com/toby-bridges/api-relay-audit

在线说明：
https://toby-bridges.github.io/api-relay-audit/

它不是测速工具，也不是中转站排行榜，更像是一个本地跑的 API relay 安全审计脚本。

我觉得它比较适合两类人：

1. 自己在运营 API 中转站的人，用来做自查
2. 经常使用第三方中转站的人，用来评估风险

一、先别只测 hello

很多人测试中转站，可能就是发一句：

hello

能返回，就觉得这个站能用。

但这其实只能说明最基础的转发是通的，测不出更深的问题。

比如：

• 中转层有没有偷偷加 hidden prompt
• 你的 system prompt 有没有被诱导泄漏
• 长上下文有没有被截断
• 工具调用有没有被改写
• 错误响应里有没有泄漏上游信息
• 流式响应结构是不是完整

这些问题，简单问候基本看不出来。

尤其是错误响应泄漏，我觉得很多中转站运营者都容易忽略。

正常请求没问题，不代表坏参数、异常请求、上游报错的时候也没问题。有时候真正泄漏信息的地方，恰恰是在报错里。

二、我这次主要查了什么

我这次自查不是为了搞什么“安全认证”，主要是想看看自己的中转链路有没有明显问题。

重点看了几类：

1. 有没有隐藏提示词注入

也就是中转层有没有在用户请求外面加一些用户不知道的系统提示词。

比如强行改变模型身份、插入广告、限制回答、加奇怪规则之类。

这个问题比较恶心，因为用户一般看不到中间层做了什么，只能从模型行为里猜。

2. Prompt 会不会泄漏

很多人现在写 Prompt，不只是随便一句话，而是会放业务规则、工作流步骤、内部判断逻辑。

如果这些东西被诱导吐出来，轻则暴露玩法，重则暴露业务信息。

所以 Prompt 泄漏我觉得是 API 中转场景里很值得测的一项。

3. 上下文有没有被截断

这个也挺常见。

用户以为自己发了完整上下文，但中间层可能因为成本、长度限制、实现问题，把一部分内容截掉。

最后接口还能返回，甚至看起来还挺正常，但模型其实已经不是基于完整信息在回答了。

这种问题比直接报错更隐蔽。

4. 工具调用有没有异常

如果只是普通聊天，问题还小一点。

但现在很多人用 AI 做 Agent、代码生成、函数调用、自动化流程，中间层如果把工具调用改写了，风险就不只是“回答不准”。

比如命令、包名、函数参数这些东西被改掉，就可能出比较麻烦的问题。

5. 错误响应有没有泄漏内部信息

这个我觉得中转站自己一定要查。

错误信息里可能带出：

• 上游地址
• 内部路径
• 框架字段
• relay 实现细节
• 上游报错原文
• 甚至某些敏感字段片段

很多站正常请求看着都挺干净，一到异常请求就原形毕露。

三、API Relay Audit 怎么跑

这个项目有个单文件版，用起来比较直接。

大概这样：

curl -sO https://raw.githubusercontent.com/toby-bridges/api-relay-audit/master/audit.py

python audit.py \
  --key sk-xxxx \
  --url https://example.com/v1 \
  --output report.md

如果是 Web3 / 钱包相关场景，还可以跑：

python audit.py \
  --key sk-xxxx \
  --url https://example.com/v1 \
  --profile web3 \
  --output report.md

它最后会生成一份 Markdown 报告，里面会有每一步的结果，也会给一个 LOW / MEDIUM / HIGH 的风险判断。

不过我觉得这个结果不能神化。

LOW 不代表永远安全，只能说明这次探针覆盖范围内没发现明显高风险问题。

MEDIUM 也不一定就是出事了，有时候是某些步骤 inconclusive，需要人工看。

HIGH 就要认真看细项，看看是不是错误泄漏、工具改写、流式异常之类的问题。

四、我为什么觉得这个项目值得推荐

主要是两点。

第一，它是本地跑。

你不用把自己的 API Key 交给另一个网页检测工具。这个很重要，因为你本来就是担心中转站会不会泄漏信息，如果检测工具还要你把 key 填到网页里，就有点套娃了。

第二，它测的方向比较对。

它不是只测速度，也不是只测模型能不能返回，而是去看中转链路里更容易被忽略的东西：

• hidden prompt
• prompt extraction
• instruction override
• context truncation
• tool-call substitution
• error leakage
• stream integrity
• Web3 wallet safety

这些东西可能不是每天都会遇到，但一旦遇到就很麻烦。

五、我的一点感受

做 API 中转站以后，我越来越觉得，这类服务长期拼的不是“能不能转发请求”。

转发请求本身并不难。

真正麻烦的是：

• 上游是否稳定
• 模型是不是真的可用
• 参数兼容性有没有测过
• 错误信息有没有处理干净
• 余额有没有监控
• 用户数据有没有尽量少碰
• 出问题能不能及时排查

安全这块也是一样。

不能只靠一句“放心用”，最好自己先跑一遍，至少知道有没有明显坑。

我这次拿自己的中转站做自查，也是想把这个流程变成日常维护的一部分。以后如果上游、网关、反代、模型路由有变化，也应该重新跑一下。

最后

如果你也在用 API 中转站，或者自己在做 relay / 反代 / NewAPI / OneAPI 这类服务，我觉得可以试试这个项目：

https://github.com/toby-bridges/api-relay-audit

它不能证明一个站永远安全，但至少能帮你发现一些明显不该出现的问题。

对用户来说，用中转站别只看价格和速度。

对运营者来说，也别只测一句 hello 就上线。

中转站本质上卖的是信任，安全自查至少应该是基本动作。