开源前必须解决：后端无限流保护，并发 2~3 即崩溃

[TeddyCzy]

问题

对后端 API /api/interview 做梯度压测，发现并发超过 2~3 就大面积失败，且没有任何限流保护。开源后所有人都能调用，这会直接导致体验崩溃和账单风险。

压测结果

单次调用正常（约 5 秒返回），但并发上升后迅速崩溃：

并发	成功	失败 (5xx)
1	1	0
5	2	3
10	2	8
20	0	20
40	0	40

关键发现

1. 扛不住并发：单人使用没问题，但几个人同时用就大面积报错。
2. 崩的是上游 AI，不是 Worker：失败响应为 502 {"error":"Interview service request failed"}，这是 Worker 在上游 AI 调用失败时返回的。真正瓶颈是 AI API Key 的速率限制被打满。「双模型草拟 + 综合」一次请求要调多次 AI，更容易触顶。
3. 完全没有限流保护：全程 0 个 429。不是「主动保护自己」，而是「被动崩溃」。
4. API 完全开放：CORS 只限制了浏览器来源（ainancool.github.io），但脚本/curl 可无视 CORS 直接调用——已用伪造 Origin 验证成功返回。任何人可无限调用，成本由维护者承担。

复现

curl -s -X POST "https://<worker-domain>/api/interview" \
  -H "Content-Type: application/json" \
  -d '{"mode":"start","config":{"company":"测试","position":"测试","jd":"测试","roundInfo":"","persona":"formal"},"history":[]}'

并发发起 5+ 个上述请求即可观察到 502。

建议（均需 Worker 代码权限）

• 省钱防刷：加人机验证（如 Cloudflare Turnstile）+ 基于 IP 的限流，超限返回 429 而非崩溃。
• 扛并发：对上游 AI 调用加排队 / 重试 / 退避，或更换更高配额的 Key。
• 收紧 CORS + 服务端校验：CORS 仅浏览器有效，需在 Worker 端做真正的来源/凭证校验。

前置阻塞

以上均需修改 Cloudflare Worker 代码。

[TeddyCzy]

补充几个和限流相关、但性质不太一样的点。上次只测了并发,这次看了下鉴权和请求体。

---

1. CORS 只是响应头,服务端不校验来源

响应里有:

access-control-allow-origin: https://ainancool.github.io

但这是个写死的常量,服务端并不检查请求的 Origin。不带任何头直接 POST:

$ curl -s -X POST https://interview-prep-api.mishibuzhaowo.workers.dev/api/interview \
       -H 'Content-Type: application/json' -d '{}'
HTTP/2 400
{"error":"Missing interview configuration"}

返回的是参数校验错误,不是 403 —— 说明请求已经穿透到业务逻辑了,只是 body 不合法。带 Origin: https://evil.example.com 也一样能拿到 200。

CORS 是浏览器的同源策略机制,只能拦住网页里的 fetch,拦不住 curl / Python / 任何服务端脚本。所以现在这个 endpoint 实际上是对全网开放的。

修的话得在 Worker 里真的判断:

const ALLOWED = new Set([env.ALLOWED_ORIGIN]);
const origin = request.headers.get("Origin");
if (!origin || !ALLOWED.has(origin)) {
  return new Response("Forbidden", { status: 403 });
}

注意是 return 403,不是只改响应头。

2. 请求体没有大小上限

jd 字段填到 105 KB(大概 25k tokens)照样返回 200,没有 413 也没有 400。配合上一条,单个请求就能塞满上下文,把 token 成本打上去。

建议加硬上限,超了直接拒:

• jd / roundInfo 各 ≤ 4 KB
• history ≤ 30 轮,每条 ≤ 2 KB
• 整个 body ≤ 64 KB

3. history 由前端完全控制,可以伪造 assistant 轮次

index.html:658:

history: history.filter(m => !m.hidden).map(m => ({ role: m.role, text: m.text }))

原样上传,服务端照单全收。构造几条 role: "assistant" 的伪造对话发过去是能通的(我试的那次模型自己拒绝了明显改用途的请求,但那是模型行为,不是服务端约束,换个措辞或换个模型版本就不一定了)。

服务端加个 schema 校验就行:role 只允许 user / assistant、轮数上限、单条长度上限。

---

另外一件事:现在 fork 出去是跑不起来的

这个和上面是同一个地方的问题,顺便提一下。

config.js 里的 apiBaseUrl 指向你的 Worker,而 Worker 的 CORS 白名单又钉死在 https://ainancool.github.io。别人 fork 之后部署到 https://someone.github.io/interview_queen/,浏览器预检直接失败,前端只会显示「出错了:Failed to fetch」。

而 Worker 的源码不在仓库里,所以想自建也没法自建。

这有两个后果:一是别人 fork 了用不了;二是有人为了让它跑起来,会把 CORS 改成回显 Origin 或者 * —— 那就等于把你的代理变成完全开放的了。

建议:

• Worker 源码加进仓库(比如 worker/ 目录,含 wrangler.toml),白名单改成环境变量 ALLOWED_ORIGIN
• config.js 改成 config.example.js,apiBaseUrl 填 https://YOUR_WORKER.workers.dev(index.html:645 已经有 API_BASE_URL.includes("YOUR_WORKER") 的检查,看起来本来就是照这个思路设计的),真实的 config.js 加进 .gitignore
• README 写清楚部署三步:wrangler secret put → wrangler deploy → 改 config.js

顺带,仓库现在没有 .gitignore。

---

以上都实际发过请求验证,但只发了少量,没有再压测。