把项目从官方 API 切到一个自建或第三方的 LLM 网关时，最容易卡壳的往往不是代码逻辑，而是几个不起眼的细节：base_url 尾部要不要带/v1、密钥放在哪里才安全、超时和重试怎么配才不会一遇网络抖动就报错。这篇以jiekou.vip为例，把这三类坑整理成一份可以照着勾选的清单。

为什么值得单独列一份清单

从官方 API 迁到中转站，本质上是"换个入口地址、换把密钥"，代码主体几乎不用动。但正因为改动小，容易掉以轻心，结果被 base_url 拼接、密钥存放、超时设置这三类问题反复绊倒。逐条核对能把返工概率压下来。下面按接入顺序拆成三块。

第一步：base_url 到底怎么填

这是最高频的报错来源。中转站兼容主流协议，你只需要把原本指向官方的请求地址，换成中转站提供的地址。以 jiekou.vip 为例，两种常见协议的填法是：

• OpenAI 兼容协议：https://api.highwayapi.ai/openai
• Anthropic 原生协议：https://api.highwayapi.ai/anthropic

注意 base_url 的域名是api.highwayapi.ai，而不是 jiekou.vip 这个站点域名，别把浏览器里看到的网址直接抄进代码。

关键的坑在/v1：不同 SDK 和工具对路径的拼接逻辑不一样。有的 SDK 会自动在 base_url 后面补上/v1/chat/completions，这时你就不该再自己写/v1；有的工具则要求你把/v1显式写全。所以：

如果调用返回 404，第一件事就是检查 URL 尾部是否多写或少写了/v1。多了删掉，少了补上，大多数 404 都出在这里。

一个 OpenAI 兼容协议的 Python 示例：

from openai import OpenAI client = OpenAI( api_key="你的中转站密钥", base_url="https://api.highwayapi.ai/openai", ) resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": "你好"}], ) print(resp.choices[0].message.content)

若用的是 Anthropic 原生协议，把 base_url 换成https://api.highwayapi.ai/anthropic，其余照 Anthropic SDK 的常规写法即可。

base_url 自查项：

• 域名写的是api.highwayapi.ai，不是站点域名
• 协议路径对应正确（openai / anthropic）
• 遇到 404 先排查/v1是多写还是少写

第二步：密钥怎么放才安全

密钥是访问中转站的唯一凭证，泄露等于把余额和权限拱手让人。几条底线：

• 绝不把密钥硬编码进源码，更不要提交到 Git 仓库
• 用环境变量或专门的密钥管理服务存放，代码里通过os.environ读取
• 前端页面里绝不出现密钥——浏览器可见即等于公开，需要调用时走自己的后端
• 给不同项目或环境分配不同密钥，一旦某个泄露可单独吊销，互不影响
• 定期在 jiekou.vip 后台轮换密钥，并删除不再使用的旧钥

环境变量读取示例：

import os from openai import OpenAI client = OpenAI( api_key=os.environ["HIGHWAY_API_KEY"], base_url="https://api.highwayapi.ai/openai", )

第三步：超时与重试怎么配

大模型请求耗时天然比普通接口长，网络链路也可能偶发抖动，合理的超时和重试能显著提升稳定性。

• 连接超时设短一些（比如 5-10 秒），连不上就尽快失败
• 读取超时设长一些（比如 60 秒以上），因为模型生成本身就慢，尤其长文本
• 重试次数建议 2-3 次，配合指数退避（第一次等 1 秒，第二次 2 秒，第三次 4 秒），别一失败就疯狂重试把自己也拖垮
• 只对可重试错误重试：超时、429、5xx 可以重试；400 参数错误、401 鉴权失败这类重试也没用，应直接报错
• 流式输出场景下，注意区分"整体超时"和"两个数据块之间的间隔超时"

带超时和重试的示例：

from openai import OpenAI client = OpenAI( api_key=os.environ["HIGHWAY_API_KEY"], base_url="https://api.highwayapi.ai/openai", timeout=60.0, max_retries=3, )

好在成熟的中转站在服务端就做了多线路调度和故障切换，客户端的重试更多是兜底。两边配合，稳定性才有保障。

上线前的最后一遍核对

• 用真实密钥跑通一次最小请求，确认返回正常
• 故意断网或填错模型名，验证超时和错误处理是否符合预期
• 检查日志里没有打印出完整密钥
• 在中转站后台设置好余额预警

小结

接入三方看似只是改个地址，真正决定顺不顺的是三个细节：base_url 的路径（尤其/v1的取舍）、密钥的安全存放、超时与重试的合理配置。照着这份清单逐条勾选，再用 jiekou.vip 跑一遍最小验证，基本就能一次切换到位。