最近聊开发工具无论如何绕不开 VibeCoding、Claude Code 和 Codex 这三张牌用自然语言把需求说清楚剩下的是 AI 生成代码、你负责 review 和取舍。但我的关注点不在它有多神奇而在一个偏冷门却非常刚需的玩法——局域网离线。也就是在不能随便出网或者只有内网可达的环境中照样把 Claude Code、Codex 跑起来代码和日志都不离开内网。这篇文章是我把这套东西从零部署到内网环境的完整复盘涉及请求路径、接入方案、报错排查、安全边界四部分。不管你是刚接触 vibe coding 的新手还是已经在折腾 Codex 接 DeepSeek、CC Switch 配置切换的老手应该都能找到对应的一手经验。1. VibeCoding 走红之后为什么有人非要局域网离线跑1.1 先说清楚 VibeCoding 在解决什么问题VibeCoding 这个词火起来也就是这两年的事它描述的不是某个特定工具而是一种工作方式不再逐行敲代码而是用自然语言描述我想做一个什么功能、遇到什么问题、希望怎么改由 AI 模型直接产出代码 diff人负责验证、取舍、回滚。Claude Code 和 Codex 是这种工作方式目前在终端里最有代表性的两个载体前者由 Anthropic 官方出品后者来自 OpenAI都是命令行界面的编程伴侣。很多人第一次用它们是在公网环境下装好、登录、开聊体验确实顺手。但一旦换到企业内部研发网、实验机房网段、或者干脆是物理上没有外网的开发环境事情就麻烦了默认配置下这两个客户端会把请求发到各自的云服务端点网络不通工具等于废掉。更麻烦的是即便网络能通很多团队的合规要求也不允许把代码片段传出去。于是局域网离线 VibeCoding就成了一个真实存在的需求。1.2 离线/局域网场景的三类刚需我接触到的需求基本归为三类第一类是数据不出内网。这往往是硬约束。代码是核心资产很多团队明文规定任何代码片段、报错堆栈、配置内容都不能传到公共工具或云服务哪怕只是把一段错误信息贴给外部模型都可能踩红线。局域网离线模式下请求只在内网转发日志本地落盘数据边界清清楚楚。第二类是网络不可靠的区域。有些网段能通内网但公网时好时坏上午能用下午断连。在这种环境里必须在线才能用的工具基本被淘汰出局。我自己就在某次现场支持时遇到过——机器能访问内网代码仓库和文档站点但外网超时当时所有云端的编程助手全趴窝。第三类是成本与审计收敛。每个人各自去用云端模型费用散落在个人账号里还难以追溯。统一走内网接入点之后谁在什么时间调了什么模型、产生了多少 token都可以在一个出口汇总后续限流、预算、审计都好办。1.3 一个关键认知所谓离线不是改客户端而是换模型接入点这里必须打破一个常见误解局域网离线 VibeCoding不等于自己要训一个模型也不等于把大模型装到每台开发机上。Claude Code 和 Codex 本质上都是瘦客户端——你的机器负责收集需求、维护上下文、执行工具调用真正的脑力在模型 API 那端。客户端把请求打包发出去再把结果翻译成可执行步骤。所以离线的关键是让这个发出去的请求有一个局域网内可达的收件人。收件人可以是三类东西企业内部自建或采购的兼容网关、本地部署的推理服务、以及你所在网络允许访问的第三方兼容服务。只要把客户端默认的请求地址改到这些收件人上离线就跑通了。后面几节我会先把这两个客户端的请求路径讲透再给出具体的接入方式。2. 动手前的关键先搞懂这两个 CLI 的请求路径2.1 Claude Code一切从 ANTHROPIC_BASE_URL 开始Claude Code 的安装本身很简单Node 18 以上环境执行npm install -g anthropic-ai/claude-code即可Linux、macOS、Windows 通用。安装完默认行为是往 Anthropic 官方 API 发消息地址形如https://api.anthropic.com/v1/messages。但它的请求地址、鉴权方式、模型名都是可以改的核心环境变量就这几个环境变量作用我的备注ANTHROPIC_BASE_URL请求端点基准地址内网接入点主要改它ANTHROPIC_AUTH_TOKEN自定义接入点使用的令牌内网网关常用ANTHROPIC_API_KEY官方 API Key云服务场景用ANTHROPIC_MODEL主模型名必须与网关侧模型对应ANTHROPIC_SMALL_FAST_MODEL_NAME轻量后台模型名用于生成标题等小任务版本间有差异配置途径有几种直接在 shell 里 export通过项目里的.claude/settings.json注入或者放到 CI 环境。我个人习惯是 export 做临时调试settings.json 做团队级别的统一配置。一个细节内网接入点走自定义令牌时通常只需要 ANTHROPIC_AUTH_TOKEN如果同时设置了 ANTHROPIC_API_KEY不同版本的客户端对优先级处理略有差异建议只保留一个避免踩到令牌不能鉴权的怪问题。2.2 Codex CLI配置中心在 ~/.codex/config.tomlCodex 的安装同样是一行命令npm install -g openai/codex。它的默认 provider 是 openai默认请求 OpenAI 官方的 Responses API。与 Claude Code 靠环境变量不同Codex 的持久配置集中在一个文件里~/.codex/config.toml。核心思路是定义 model_providers也就是告诉 Codex你要发请求给谁、用什么鉴权字段、用哪种协议格式。一个典型的局域网配置长这样model Qwen/Qwen3-32B-AWQ model_provider intranet-vllm [model_providers.intranet-vllm] name Intranet vLLM base_url http://10.0.0.8:8000/v1 env_key INTRANET_LLM_KEY wire_api chat这里的 env_key 表示从环境变量 INTRANET_LLM_KEY 读取令牌而不是把令牌明文写进配置文件。base_url 指向内网服务wire_api 指定请求协议格式。此外 Codex 也兼容OPENAI_BASE_URL、OPENAI_API_KEY这一组环境变量适合快速覆盖默认 provider 的场景。2.3 wire_api 是第一个坑/responses 和 /chat/completions 不是一回事很多人配 Codex 时报各种 endpoint 错误根子大多在 wire_api 上。Codex 默认走的是 OpenAI 新版 Responses API请求路径是/responses但局域网里的推理服务vLLM、Ollama、LM Studio和绝大多数第三方兼容服务实现的都是更老也更通用的 Chat Completions API路径是/chat/completions或者严格一点说是/v1/chat/completions。也就是说如果你的 Codex 还在用默认 wire_api 去请求一个只支持 chat 的服务对方根本不知道/responses是什么自然就报 endpoint 相关的错误。解决办法很简单凡是接局域网或第三方兼容服务wire_api 一律写chat。这一行的作用就是切换请求格式别小看它。2.4 配置前的 10 分钟联调先用手头 curl 验端点我的习惯是不管要接哪个服务先用 curl 直接打一发请求确认端点真的活着、协议真能用再回头配客户端。这一步能省掉后面大量为什么配了没反应的排查时间。验证 OpenAI 兼容端点curl -X POST http://10.0.0.8:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer lan-key \ -d {model:qwen3:32b,messages:[{role:user,content:回复 hello}]}验证 Anthropic 兼容端点curl -X POST http://10.0.0.9:8080/v1/messages \ -H Content-Type: application/json \ -H x-api-key: lan-key \ -H anthropic-version: 2023-06-01 \ -d {model:deepseek-chat,max_tokens:1024,messages:[{role:user,content:回复 hello}]}两个请求如果都能拿到正常 JSON 响应说明通道没问题后面配置客户端就是指路而已。我遇到过的装好了却全错的案例几乎都是省略了这一步、直接开配客户端然后对着日志瞎猜。3. 局域网内可用模型服务的三种搭法选型决定后面顺不顺3.1 方案A企业内部 Anthropic/OpenAI 兼容网关如果你的团队已经有一套模型管理平台比如集群里部署的模型网关、统一模型调度平台那最理想的接法就是让它们直接提供 Anthropic 兼容或者 OpenAI 兼容的端点。客户端这边只换 BASE_URL其他什么都不用动。这种方式的好处是能力可以保持旗舰级。网关背后连的可能是团队采购或授权的大模型模型质量远高于你本机能跑的开源模型同时网关统一负责鉴权、限流、审计团队管理成本最低。但有一个前提必须先确认清楚网关是否真的实现了对应协议而不是简单做一层页面转发。特别要注意的是很多企业网关只做了 OpenAI 兼容没做 Anthropic 兼容这种情况下 Claude Code 就无法直连需要额外套一层协议转换。我建议部署前先问清楚网关支持的协议清单别默认都能接。3.2 方案B本地推理服务vLLM / Ollama / LM Studio没有现成网关、且对数据隔离要求最高时就在局域网里自己起推理服务。三个常用选择各有性格vLLM 适合 GPU 集群性能好、吞吐高命令大致是vllm serve 模型名 --host 内网IP --port 8000起来后自带/v1/chat/completions接口。Ollama 是最省事的选择装好后ollama serve默认监听 11434把OLLAMA_HOST设成内网 IP 就能让局域网内其他机器访问路径是http://内网IP:11434/v1。LM Studio 适合 Windows 图形界面用户把一个模型加载起来后开启 Local Server也能提供 OpenAI 兼容接口开发机即服务端。这些本地服务跑的都是开源模型比如 Qwen3、DeepSeek 的蒸馏版本、GLM 系列等。它们的能力取决于你的硬件显存越大、模型越强。一个诚实的提醒VibeCoding 对模型的听话程度要求不低参数太小的模型容易出现氛围写码——看起来在认真写实际上逻辑一塌糊涂。我个人的经验值是至少 32B 级别再低就只适合补全类和简单重构了。3.3 方案C内网可达的第三方兼容服务还有一种情况你的开发网络并不要求物理断网只是通过白名单或专用链路访问特定服务。这时可以选那些同时提供兼容协议的外部模型服务最典型的就是 DeepSeek它既有 OpenAI 兼容端点也有 Anthropic 兼容端点。这也是热议话题里Claude Code 接 DeepSeekCodex 接 DeepSeek为什么能成立的原因——协议兼容客户端认。这类方案的好处是模型能力强、零维护适合个人开发机和普通研发网但它本质上仍是出网请求是否满足合规要求由你的网络策略决定。简单说方案C是数据可以通过受控链路出去但只能去我们允许的地方。3.4 三种方案怎么选一张表讲清楚维度方案A 企业网关方案B 本地推理方案C 第三方兼容服务模型能力取决于网关授权受硬件限制高数据隔离高内网闭环最高完全本地中受控出网部署成本需平台团队需要 GPU/显存最低只需注册密钥维护难度低平台买单中高自己扛低适合场景中大型研发团队涉密网/无外网机房个人开发机/普通研发网3.5 我的选型建议如果只是在自己开发机上想尽快体验方案C最合适十几分钟就能跑通如果环境是真的不能出网、又有合规要求方案B是几乎唯一选择建议直接配一块大显存推理卡如果团队有平台组方案A最理想。现实中不少公司最后都长成 AB 混合默认流量走企业网关敏感项目切到本地推理。这个组合既保体验又守边界我觉得是当前最务实的形态。4. 实操Ubuntu 和 Windows 下把 Claude Code、Codex 接到局域网服务4.1 安装与版本确认先准备基础环境。Node 18 以上版本是硬条件命令行里node -v先看一眼。然后两条 npm 命令npm install -g anthropic-ai/claude-code npm install -g openai/codex装完分别用claude --version和codex --version确认可执行文件能用。Windows 下同样走 npm 全局安装区别主要是 PowerShell 的环境变量语法是$env:NAMEvalue而 Linux/macOS 的 bash 是export NAMEvalue后面配置时我会把两种语法都写出来。4.2 Claude Code 指向内网 Anthropic 兼容端点假设内网有一台兼容 Anthropic Messages 协议的网关地址是http://10.0.0.9:8080令牌是lan-token模型名按网关要求填deepseek-chat。Linux/macOS 下这样启动export ANTHROPIC_BASE_URLhttp://10.0.0.9:8080 export ANTHROPIC_AUTH_TOKENlan-token export ANTHROPIC_MODELdeepseek-chat claudeWindows PowerShell 对应写法$env:ANTHROPIC_BASE_URLhttp://10.0.0.9:8080 $env:ANTHROPIC_AUTH_TOKENlan-token $env:ANTHROPIC_MODELdeepseek-chat claude如果想做成项目级别、大家共用同一套配置可以在项目根目录放一个.claude/settings.json{ env: { ANTHROPIC_BASE_URL: http://10.0.0.9:8080, ANTHROPIC_AUTH_TOKEN: lan-token, ANTHROPIC_MODEL: deepseek-chat } }需要注意两点settings.json 里的 env 会在 Claude Code 启动时注入到进程非常适合团队统一管理但真实令牌放进这个文件就有泄露风险建议令牌还是走 shell 环境变量或本地.envsettings.json 只放地址和模型名。4.3 Codex 指向局域网 OpenAI 兼容服务假设内网有一台 vLLM 服务地址http://10.0.0.8:8000/v1部署的模型叫Qwen/Qwen3-32B-AWQ。编辑~/.codex/config.tomlmodel Qwen/Qwen3-32B-AWQ model_provider intranet-vllm [model_providers.intranet-vllm] name Intranet vLLM base_url http://10.0.0.8:8000/v1 env_key INTRANET_LLM_KEY wire_api chat然后在当前 shell 导出令牌export INTRANET_LLM_KEYlan-key codex注意 model 字段必须和服务端实际部署的模型名完全一致大小写、斜杠路径都不能差。我曾把/Qwen/Qwen3-32B-AWQ写成qwen3-32b服务端直接 404。也可以用环境变量覆盖方式快速验证export OPENAI_BASE_URLhttp://10.0.0.8:8000/v1后再codex能通说明配置思路没问题再固化到 config.toml。4.4 Codex 接 DeepSeek 的具体配置对应热议里Codex 接 DeepSeek配置跟上面几乎一样只是 base_url 换成 DeepSeek 的 OpenAI 兼容端点model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chatClaude Code 接 DeepSeek 则是用它的 Anthropic 兼容端点export ANTHROPIC_BASE_URLhttps://api.deepseek.com/anthropic export ANTHROPIC_AUTH_TOKENsk-xxxx export ANTHROPIC_MODELdeepseek-chat claude同一把密钥在两个工具里通用不需要额外申请。一个实测小坑Anthropic 兼容端点对请求格式有它的脾气Claude Code 会默认带着一堆工具定义过去如果你把模型名写成deepseek-reasoner某些操作会返回 400。我日常写业务代码用deepseek-chat最稳需要推理链的场景才单独切原因模型。4.5 VSCode 里配合使用Claude Code 和 Codex 本质上都是终端程序所以最省事的落地方式就是在 VSCode 的集成终端里跑。打开设置里的 settings.json注入终端环境变量terminal.integrated.env.linux: { ANTHROPIC_BASE_URL: http://10.0.0.9:8080, ANTHROPIC_AUTH_TOKEN: lan-token, ANTHROPIC_MODEL: deepseek-chat }Windows 对应改成terminal.integrated.env.windows。之后 Ctrl打开集成终端直接输入claude或codex 就能在当前项目目录工作。离线内网里扩展市场可能不可用所以我不建议依赖官方 GUI 插件集成终端方案不挑网络、随时可用配合代码文件显示的 diff 上下文体验已经很接近完整 IDE 流程。4.6 验证链路配置完别急着开聊先看日志确认请求真的打到了内网端点。Claude Code 用claude --debug启动会打印每次请求的实际 URL、模型和 token 消耗Codex 用codex --trace。如果日志里显示请求 URL 还是官方的 api.anthropic.com 或 api.openai.com说明环境变量没有真正注入进程——常见原因是 VSCode 集成终端在设置修改后没重启或者 shell 配置文件里 export 写错位置。日志是最直接的证据别对着报错文案猜。5. 局域网离线模式下我踩过的坑热搜报错逐条拆5.1 CC Switch 本地转发报错别急着换工具很多人在用 CC Switch 这类图形化配置切换工具它可以在本机起一条转发链路把某个本地端口的请求再转到目标端点。热词里的报错就是这个场景本地转发链路在处理 Codex 的/responses请求时失败。我的排查经验是这类报错通常来自三处转发链路进程没起来或被安全软件拦截目标端点根本不支持/responses而工具默认去请求了它base_url 缺路径前缀导致拼接出来的地址不是服务端期望的。处理顺序是先用 curl 直连目标端点确认服务本身是好的再把 Codex 配置改成直连 base_url绕过本地转发层如果问题消失说明就是转发层的问题而不是 Codex 的问题。我的建议很简单局域网内能直连就不要加中间转发层。每加一层就多一个不透明的故障点尤其在内网环境里谁都不想在排障时还要同时怀疑工具自身的本地服务。5.2 codex auth token is unavailable这个报错我一开始也见过含义很直白config.toml 里指定的 env_key 所对应的环境变量在当前 shell 里不存在。比如我配置里写了env_key INTRANET_LLM_KEY但新开一个终端忘了 exportCodex 启动时自然拿不到令牌。排查三步先echo $INTRANET_LLM_KEY确认变量名和值再看大小写是否完全一致环境变量名是区分大小写的最后确认服务端要求的是 Bearer 方式还是自定义 header不同兼容服务对鉴权字段的处理不完全一样个别服务要的是 x-api-key 而非 Authorization。经验上用 env_key 方案比把密钥写进 config.toml 安全得多但前提是你要把 export 写进 shell 的配置文件或者用 dotenv 工具统一加载。5.3 model is not supported模型名和服务端对不上Codex 报形如 the ... model is not supported 的错误十有八九是 model 字段与接入点能提供的模型清单不匹配。典型场景你从官网文档复制了一段配置但那段配置里的默认模型名在局域网网关里不存在或者你用的是服务端聚合网关模型名需要写成网关的别名而不是模型原始名。解决方式就是把 model 改成服务端实际部署的名字。怎么确认登录服务端的管理界面看模型清单或者直接 curl 它的/v1/models接口。这里我总结过一个通用原则接入点只是通道模型名才是决定通道里跑什么的开关报错先对齐模型清单不要怪通道。Claude Code 那边同理ANTHROPIC_MODEL 必须与网关侧模型对应否则同样会报 404 或模型不可用。5.4 claude code might not be available in your country 怎么理解这条提示单独拿出来讲因为它被讨论得最多、误解也最多。从技术层面看这是客户端启动时的可用性预检它校验的是当前请求链路对于配置端点的可达性。如果你明明配置了局域网端点却仍然看到这条提示我的处理顺序如下。先确认实际生效的 Base URL用claude --debug启动看日志里请求的真正地址是不是你填的内网地址。很多时候环境变量根本没注入客户端还在按默认路径检查再直接 curl 内网端点确认当前网络确实能访问两端都通了这条预检基本不会再出现。这条提示本质上是网络链路与配置生效性的信号跟模型本身能力强弱没有关系遇到时先检查可达性和配置注入不要盲目更换工具链。5.5 通用排查链路把上面几条报错拉通看我的排查套路其实就六步适用于 90% 的接入问题定层先判断是客户端配置问题还是端点服务问题用 curl 直接打端点看返回的 JSON 是否符合预期打开客户端日志claude --debug / codex --trace看实际请求去哪里了检查环境变量是否真正进入进程用 echo 或 printenv 确认核对协议差异Anthropic Messages 协议还是 OpenAI Chat Completions 协议最后才去怀疑模型能力。这套链路的关键是证据优先。我在内网排障时见过太多人对着一个报错文案反复改配置却从不看一眼日志里请求到底发到了哪里。先看证据再动手比什么都管用。6. 离线 VibeCoding 的安全边界与团队协作经验6.1 推理服务只绑内网 IP别裸奔 0.0.0.0局域网离线不等于绝对安全。很多推理服务默认监听 0.0.0.0意思是网段内任何一台机器都能直接调用你的服务如果这个网段里还有别的团队、其他业务系统甚至有不干净的主机猜测模型消耗还是小事被人把内网服务当跳板才是真麻烦。我的建议是服务启动时显式绑定内网 IP而不是 0.0.0.0。vLLM 用--host指定Ollama 用OLLAMA_HOST内网IP:11434如果可能再在交换机或防火墙上对端口做访问白名单。这一步在团队共享服务时尤其重要千万别图省事。6.2 Token 与配置文件的纪律离线环境里令牌管理反而更容易松懈因为大家觉得反正内网出不去。但内网也有权限边界密钥泄漏的后果在内网往往更严重。几条纪律值得写在团队文档里令牌能进环境变量就不进配置文件能进本地.env就不进仓库.claude/settings.json和 config.toml 里不写真实密钥config.toml 坚持用 env_key 指路密钥文件必须进.gitignore并且定期轮换每个人用自己的令牌不要共用一个管理员令牌方便审计和回收。6.3 让 VibeCoding 在离线环境更顺手的项目规范离线模型有一个天然短板它们没有最新社区知识可以临时查。所以项目自身的上下文文档就变得至关重要。Claude Code 会自动读取项目根目录的 CLAUDE.mdCodex 也有对应的 AGENTS.md。把架构约束、目录约定、命名规范、禁止事项写清楚模型在你项目里接活的准确度会明显提升。我在实际项目里最强的体会就是给模型的项目背景说明比换一个更强的模型更能提升生成质量。很多团队用不好 VibeCoding不是模型不行而是项目里根本没留下可读的上下文。这个工作不需要花太多时间半小时写一版之后每次生成都在受益。6.4 团队共享端点时的限流与审计统一接入点之后要把限流和审计做在前面。团队成员同时发起几个大的代码生成任务本地推理服务很容易被打爆表现就是所有请求排队、延迟暴涨、乃至超时。建议在网关或推理服务层设置并发上限比如 vLLM 的 max-num-seqs 参数或者网关侧限制单 IP 并发同时把请求日志落到独立文件包含时间、用户、模型、token 量方便事后追溯。我见过一个团队因为没有限流某天下午三个人同时让模型重构模块结果服务端卡死半小时所有人以为是局域网故障。限流不是为了限制生产力是为了保证服务可用性这个观念要先统一。6.5 我在实际使用中的体会最后分享一点个人感受。离线 VibeCoding 并不是退而求其次的妥协玩法它更像是把编码伴侣重新拉回自己可控的边界内数据不出门行为可追溯成本可量化。我现在的默认工作流就是普通需求走内网网关涉敏项目切本地推理遇到报错先 curl 再日志最后才是查配置。这套流程磨合下来效率并不比公网体验差反而因为少了网络波动稳定性更好。一个小技巧送给各位把常用接入点组合写成 make 目标或 shell 脚本比如make dev-claude、make dev-codex新同事拿到项目一敲就能用不用每个人考古式地回忆环境变量从哪来。这类小工具能显著降低团队上手成本。总之先让链路通再谈模型强这是我在这件事上最大的收获。