How do I point Claude Code at a different API base URL?

所谓把 Claude Code 指到另一个接口地址，是指不再走默认的官方入口，而是让它的请求发往你指定的网关或兼容服务。改的不是模型本身，而是请求先到哪里：地址换了，认证、模型名和计费规则往往也要跟着换。只改地址、不对齐其余几项，是这类配置最常见的翻车方式。本文先讲地址到底由哪几项决定，再按步骤讲怎么改、怎么验，帮你在动手之前先把对照关系理清楚。

地址由哪几项共同决定？

接口地址从来不是单独一个字符串，而是地址、密钥、模型名三项拼在一起才生效。地址决定请求发往哪里，密钥决定对方认不认你，模型名决定对方按哪个模型处理。三项里任何一项对不上，都会表现为同一种报错，让人误以为只是地址写错了。动手之前先把三项写下来：新地址、配套密钥、对方清单里的模型名，缺一项就先别改。还有一个容易被忽略的第四项：地址末尾的路径段。有的服务要求地址本身就含版本段，有的则由客户端自动补，重复或缺失都会导致找不到入口。改之前先读对方文档里给的示例地址，照抄它的结构，不要凭印象补路径。

应该先在哪里改，全局还是项目内？

改动位置决定影响范围，选错位置会带来两种麻烦。改在全局配置里，之后所有项目都走新地址，适合你已经决定长期换服务的情况。改在项目内，只影响当前这一个项目，适合先拿一个不重要的项目试水。试水阶段建议只改项目内，确认稳定后再决定要不要推广到全局。两种位置如果同时写了不同的地址，项目内的通常会优先，排查时要先确认到底是哪一处在生效，而不是只看自己最后改的那一处。另外要注意，环境变量和配置文件也可能同时存在，环境变量往往优先于文件，排查时要把两边都列出来比对。

具体步骤是怎样的？

第一步，先在新服务侧拿到三样东西：接口地址、密钥、模型清单里的模型名，缺一不可。第二步，打开配置位置，填入地址和密钥，并把模型名设为对方清单里的名字，不要沿用旧服务的模型名。第三步，保存后先不要直接跑大任务，而是发一个极短的测试问题，确认能通、返回内容正常、计费记录里出现的是新模型。第四步，确认测试通过后，再把日常任务切过来，并把旧配置的备份留好，写明改动日期和改回的方法。第五步，跑完第一个真实任务后回头核对一次：返回里标注的模型是不是你设的那一个，账单或用量记录里是不是新服务在计费。五步里最容易被跳过的是第三步和第五步，而恰恰是这两步在替你确认“地址真的换过去了”。

怎么确认请求真的走了新地址？

只看“能出结果”是不够的，因为配置没生效时，工具可能悄悄走了旧地址，照样能出结果。可靠的确认办法有三层。第一层看返回：有的服务会在返回里标注实际服务的模型，核对它是不是你设的名字。第二层看用量：登录新服务的用量或账单页，确认刚才那次测试确实记在新服务名下。第三层看旧服务：旧服务的用量在测试时间段内没有新增，才说明旧入口真的没再被走。三层里任何一层对不上，都要停下来排查，而不是继续跑任务。还有一个辅助信号是延迟和报错风格：不同服务的延迟分布和报错文案往往不同，突然变得和以前完全一样，反而值得怀疑。

地址写对了还是报错，先查哪几处？

报错时按固定顺序排查，不要同时改好几处。先查地址结构：末尾有没有多余的斜杠、路径段有没有重复、是不是把网页控制台的地址当成了接口地址。再查密钥：是不是拿错了另一服务的密钥、密钥有没有多余空格、有没有被轮换过。接着查模型名：是不是用了旧服务的模型名、大小写和连字符有没有抄错。最后查网络：是不是需要代理、代理有没有放行新域名、公司网络有没有拦截。每次只改一处、改完测一次，改动记录写下来。最忌讳的做法是地址、密钥、模型名一起换，好了也不知道是哪一处起的作用，下次再出问题又要从头猜。

密钥和地址分开管理有什么好处？

把密钥直接写进和地址同一处、又随项目到处复制，是最常见的泄露路径。更好的做法是密钥只放在环境变量或系统钥匙串里，配置文件里只写地址和模型名，密钥由运行环境注入。这样做的好处有三点：分享配置给同事时不会顺手把密钥发出去了；轮换密钥时只改一处；排查时能分清“地址问题”还是“密钥问题”。另外要养成两个习惯：不同服务用不同的密钥，不要一把密钥到处复用；测试用的密钥和正式用的密钥分开，测试密钥泄露了也只影响测试用量。密钥一旦怀疑泄露，先吊销再排查，不要先找原因。

换地址之后，模型名要注意什么？

模型名是新服务清单里的名字，不是你心里对模型的叫法。同一类模型在不同服务里的名字可能不同，有的带厂商前缀，有的只写简称，抄错一个字符就会被判定为不存在。还有一种情况：新服务清单里根本没有你原来用的那个模型，这时要先选一个清单里确实有的替代模型，而不是强行沿用旧名字。选替代模型之前，先确认它支持你需要的功能，例如长上下文、工具调用或代码编辑，缺了关键能力，地址通了任务也跑不好。最后要把“旧模型名到新模型名”的对照写下来，团队里其他人接手时才不用重新猜。

多个项目共用一个新地址时怎么管？

多个项目共用新地址时，最怕的是改了一个项目、以为全改了，或者改了全局、把不该换的项目也带走了。管理办法是分层：公共部分放在全局，只写地址和默认模型；每个项目只写自己特殊的部分，例如某个项目必须用另一个模型。定期做一次盘点：列出所有项目实际生效的地址，发现漂移就收敛。盘点时顺便检查两件事：有没有项目还在用已经停用的旧地址，有没有测试项目占用了正式密钥。共用地址还意味着用量是汇总的，某个项目失控会拖累所有项目，必要时给重点项目单独配密钥和限额，把风险隔离开。

这篇教程有哪些局限？

本文只讲了换地址的通用方法，没有针对任何一家具体服务写配置，因为各家服务的地址结构、模型名和认证方式会随版本变化，今天写对的示例明天可能就过时。界面路径和配置项名称在不同版本里也可能改动，动手时要以你所用版本的官方文档为准，本文的步骤是核对清单、不是逐键操作指南。另外，本文没有讨论自托管服务的部署和内网穿透，那是另一类工作，不在换地址的范围内。涉及生产数据的项目换地址之前，建议先在测试项目里完整走一遍五步，再切生产。

简而言之，怎样换地址才稳？

稳妥的换地址办法是三项对齐、项目内先试、小请求先验、三层确认再切生产：地址、密钥、模型名三项缺一不可，试水只改一个项目，测试通过后用返回标注、用量记录和旧服务用量三层确认真的走了新地址。任何一层对不上就停下来按顺序排查，每次只改一处。换过去之后把对照关系和改回方法写下来，下次再换或出问题时，就不用从头猜起。先立对照、再做实测，让新服务用返回和账单证明自己，而不是用“能出结果”自我安慰。

来源与延伸阅读：FreeModel 关于页：它是什么、不是什么、FreeModel、Claude Code 官方文档、Claude Code 产品页、实测免费网关对比、十四家网关公开模型清单实读。