大模型 API 中转站怎么选：直连、自建、用现成的，三条路的真实成本
利益披露：本文最后介绍的中转站是我自己在运营的。前面三分之二的取舍分析对任何人都成立， 你完全可以看完分析之后选择另外两条路——那也是这篇文章想说清楚的事。 ...
全部文章
大模型 API 网关、反向代理、小内存服务器运维的实战记录。每篇都基于真实生产环境的实测数据。
Caddy 还是 nginx 给 API 中转做反代：证书自动化是决定性差异
给大模型 API 中转选反向代理，网上的对比文章大多在比性能、比配置语法、比模块生态。这些差异对一个 API 网关来说其实都不重要——真正的分水岭是证书生命周期由谁管理。 ...
大模型 API 中转的超时与重试：一次 504 可能让你双倍计费
nginx 的 proxy_read_timeout 默认是 60 秒，而长上下文或推理模型的单次生成经常超过这个数。超时之后 nginx 返回 504，看起来只是"一次失败"——但真实后果比这严重：上游很可能已经把生成做完并计了费，而客户端 SDK 收到 504 会自动重试，于是上游又生成一次、又计一次费。 ...
给 API 中转站选数据库：SQLite / MySQL / PostgreSQL 在小机器上的取舍
new-api 这类中转程序通常同时支持 SQLite、MySQL 和 PostgreSQL，安装文档也就一句"按需选择"。但在一台 2G 内存的小机器上，这个选择是有真实代价的——光是数据库进程本身就可能吃掉可用内存的四分之一。 ...
API 中转站的限流为什么不能信 X-Forwarded-For
自建大模型 API 中转站几乎一定要做按 IP 限流：防注册刷号、防单账号打满上游配额。而这里有一个安静失效的陷阱——如果你的限流按 X-Forwarded-For 计数，那它等于没做。攻击者每个请求塞一个不同的伪造 IP，计数器永远打不满。 ...
new-api 部署选型：2G 小内存机器上裸二进制比 Docker 省多少
在 2 核 2G 的云主机上部署 new-api，如果这台机器还跑着别的服务，裸二进制方案通常是唯一可行的选择。原因不是 new-api 本身重——它是个 Go 单体，编译出来就一个二进制——而是 Docker 守护进程加上容器化的数据库和缓存，会在系统底噪之上再叠几百 MB 常驻开销，而 2G 机器的可用余量往往只剩 1G 出头。 ...
反代把大模型 API 的 SSE 流式响应缓冲了：五个缓冲点与三层排查法
自建大模型 API 中转后最常见的故障是：后端明明是流式的，经过反向代理就变成一次性返回——客户端等十几秒没有任何输出，然后整段文字一次吐完。首字节延迟几乎等于整个生成时长，流式的意义全部丧失。 ...