密钥已经填好，模型也选好了，第一条请求却返回四〇四错误。先别反复更换密钥：这类错误通常表示请求没有命中服务器上的目标资源，但也可能来自中间代理或模型路由。最快的排查起点，是确认客户端最终访问了哪个地址，而不是只看配置框里填了什么。
一、先确认客户端需要主机地址还是版本入口
基础地址并没有一种适用于所有客户端的填写方式。有些工具会自行补齐版本路径和接口路径，有些开发工具包则要求基础地址已经包含版本前缀。把别人的配置直接复制过来，可能恰好多出一层路径，也可能少掉一层。
以 SwiftRelay 为例，同一个服务需要按客户端分别配置：
- 使用 Claude Code 或 Gemini CLI 时，填写裸主机地址：https://api.fastapirelay.com。
- 使用 OpenAI 兼容开发工具包时，基础地址填写：https://api.fastapirelay.com/v1。
先辨认客户端，再决定是否添加版本路径。不要因为某个工具能用，就把相同配置原样复制给另一个工具。
二、把基础地址与接口路径拆开核对
基础地址是请求的起点，不一定是完整接口地址。开发工具包通常还会根据调用的方法，追加聊天、消息或其他接口路径。如果把完整接口地址填进基础地址字段，客户端可能再次追加同一段路径。
检查时，把配置值与客户端追加的路径分开记录，再查看日志中的实际请求地址。重点寻找三类问题：版本前缀重复、接口路径重复、必需的版本前缀缺失。最终发出的地址比手工推算更可靠，因为不同客户端的路径拼接规则可能不同。
三、清除从控制台或教程复制来的多余内容
确认地址来自接口配置说明，而不是浏览器当前打开的控制台页面。控制台、文档站和接口服务可能使用不同主机，页面能够正常打开，并不意味着它可以接收模型请求。
- 删除基础地址中误带的页面路径、查询参数和片段标记。
- 检查复制时是否混入空格、换行、中文引号或中文标点。
- 检查协议、主机名和端口，避免请求被送到本地服务或旧代理。
- 按照客户端文档处理末尾斜杠，不要假设所有客户端都会自动规范化路径。
如果错误响应是一整页网页，而不是预期的接口错误结构，优先检查是否访问了网站入口或中间代理。不过，响应格式只能作为线索，不能单独证明故障来源。
四、确认刚修改的地址确实被程序读取
配置文件改对了，运行中的进程却可能仍在使用旧值。环境变量、项目配置、用户配置和启动参数之间可能存在覆盖关系，具体优先级需要查看所用工具的说明。
先停止当前进程，再从确认过环境变量的终端重新启动。若程序运行在容器或远程开发环境中，还要检查那个环境里的实际配置，而不是只修改本机文件。诊断记录只保留主机和路径，不要输出密钥或完整鉴权请求头。
五、用最小请求锁定错误发生在哪一层
暂时移除插件、工具调用和复杂业务参数，只保留一次普通文本请求，并使用服务当前支持的模型。每次只修改一个变量，例如先修正基础地址，再验证版本路径，避免同时更换模型和调用方式。
记录请求方法、最终主机、最终路径、状态码与错误正文。如果日志显示请求去了错误主机，先处理配置覆盖；如果路径重复，修正基础地址；如果路径看起来正确，但响应明确提示模型不存在，再核对模型名称和可用范围。不要把所有四〇四错误都归因于地址，也不要靠更换密钥解决路径问题。
六、检查代理改写后保存可复用配置
若直连成功、经过自建代理后失败，就检查代理是否删除或重复添加了版本前缀，是否把接口请求转到了网站首页，以及转发规则是否覆盖当前接口。以代理实际收到和转发的路径为依据，不要只看规则名称。
验证通过后，按客户端分别保存配置模板，注明裸主机或带版本前缀，避免下次迁移时再次混用。准备使用 SwiftRelay 的读者可以注册账户，用新账户赠送的小额额度完成首次验证；服务按令牌用量计费。
最后再跑一次同样的最小请求。只有新进程使用预期地址并成功返回结果，才算完成这一圈检查。随后逐项恢复业务参数，保留已验证的基础地址作为排错基线。