1. 企业内网离线部署 CodeX 的真实痛点CodeX 是一套面向代码补全与对话的 AI 编程助手支持本地模型推理适合对数据不出内网有硬性要求的企业团队。它的私有化部署形态通常是一个常驻服务进程前端通过 HTTP 与 WebSocket 访问模型权重放在本地磁盘。适合谁适合有独立机房或内网服务器、需要把代码和对话数据完全留在内网、又希望保留接近公网体验的研发团队。但真到内网落地问题往往不在 CodeX 本身而在它周围那一圈基础设施。我见过最典型的场景服务起来了前端页面转圈控制台报 WebSocket 连接失败排查半天发现是反向代理没转发 Upgrade 头。还有模型权重下载卡死、pip 源缺包、内存不够 OOM、证书不被信任导致 HTTPS 回调失败。这些坑单独看都不难叠在一起就够折腾一晚上。这篇按“先解决网络与依赖再配服务最后接统一通道”的顺序走。核心思路是内网机器不直接碰外网所有外部依赖提前离线化模型接入走 TaoToken 统一 Key/API 通道把多模型、多 Key 的管理收敛到一个入口减少内网里散落的配置。下面给到的config.toml和settings.json骨架可以直接抄参数按自己机器改。2. TaoToken 前置统一 Key 与 API 通道内网部署最容易失控的地方是“每个服务一套 Key、一套地址”。CodeX 要调模型别的内部工具也要调模型Key 散落在各台机器的配置文件里轮换一次要改一圈。TaoToken 在这里的角色是统一接入层你拿一个 Key通过统一的 API 地址访问模型能力内网服务只需要认这一个出口。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 这个不加 UTM。注意内网机器如果完全隔离需要由一台能出网的跳板机或代理节点转发到该 API内网 CodeX 只配置指向这个转发地址而不是直连。拿 Key 的路径登录后进控制台在 API Keys 页面创建。控制台地址 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。创建时建议按环境命名比如codex-intranet-prod方便后面审计。注意Key 不要写死在会进 Git 的配置文件里。内网也一样用环境变量或独立的 secrets 文件权限设成 600。如果你后面要做长期编码或 Agent 类任务可以了解 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。模型对话调试用 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。3. 可复制配置config.toml 与 settings.json 骨架先解决依赖离线化。内网 pip 源通常只同步基础包CodeX 依赖的 transformers、torch 版本对不上就报错。在外网机器上把 wheel 拉全指定版本别让 pip 自己去解析。# 外网机器执行指定版本避免内网解析失败 pip download codex1.2.3 -d ./codex_packages --no-deps pip download torch2.0.1 transformers4.30.0 -d ./codex_packages tar czf codex_packages.tar.gz ./codex_packages传到内网后用--no-index安装否则 pip 会尝试连外网索引卡死tar xzf codex_packages.tar.gz pip install --no-index --find-links./codex_packages codex接下来是config.toml骨架。CodeX 服务绑定、模型路径、量化、日志、认证都在这里# config.toml [server] host 0.0.0.0 port 8080 scheme http # 若前置 HTTPS 反代这里仍写 http由反代终结 TLS max_workers 3 # 4 核机器留一核给系统 [model] path /data/models/codex-7b quantize 4bit # 内存紧张时开启14G 降到约 4G max_concurrent 2 # 限制并发防止单用户占满资源 [api] base_url http://10.0.0.20:9000/v1 # 内网转发节点指向 TaoToken API api_key_env CODEX_API_KEY # 从环境变量读不写死 timeout 300 [logging] level WARNING # 调试期改 DEBUG file /var/log/codex/codex.log max_size 100MB backup_count 5 [auth] enabled true token_env CODEX_AUTH_TOKENsettings.json管前端与客户端侧的行为重点是代理和证书信任{ codex.endpoint: http://10.0.0.20:8080, codex.wsEndpoint: ws://10.0.0.20:8080/ws, codex.timeoutMs: 300000, codex.proxy: http://10.0.0.30:3128, codex.tls.rejectUnauthorized: true, codex.tls.caFile: /etc/ssl/certs/intranet-ca.crt, codex.telemetry.enabled: false }内网代理与证书信任这块如果公司有自签 CA把 CA 证书放到系统信任链Node 或 Python 客户端才能校验通过# 把内网 CA 加入系统信任 sudo cp intranet-ca.crt /usr/local/share/ca-certificates/ sudo update-ca-certificates # 若客户端用 Node额外指定 export NODE_EXTRA_CA_CERTS/etc/ssl/certs/intranet-ca.crt反向代理是 WebSocket 失败的高发区。Nginx 默认不转发 Upgrade 头必须显式加location /codex/ { proxy_pass http://127.0.0.1:8080/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 300s; proxy_send_timeout 300s; }proxy_read_timeout默认 60 秒大模型推理经常超过设 300 秒稳妥。4. 验证请求与成功结果配置写完先别急着上生产按顺序验证。第一步确认服务进程和端口codex serve --config config.toml curl -s -o /dev/null -w %{http_code}\n http://127.0.0.1:8080/health # 期望输出 200第二步验证模型是否就绪调一次补全接口curl -s http://127.0.0.1:8080/v1/completions \ -H Authorization: Bearer $CODEX_AUTH_TOKEN \ -H Content-Type: application/json \ -d {prompt:def add(a,b):,max_tokens:32}返回里能看到生成的代码片段说明模型加载和推理链路通了。第三步验证经 TaoToken 统一通道的调用在内网转发节点上执行curl -s http://10.0.0.20:9000/v1/chat/completions \ -H Authorization: Bearer $CODEX_API_KEY \ -H Content-Type: application/json \ -d {model:gpt-4o-mini,messages:[{role:user,content:ping}]}返回 JSON 里带choices字段即成功。第四步验证 WebSocket。用wscat或浏览器控制台连ws://10.0.0.20:8080/ws能收到握手帧就说明反代的 Upgrade 转发正确。实测下来这四步过了前端基本不会再转圈。5. 本篇常见错排查WebSocket 连接失败九成是 Nginx 没配Upgrade和Connection头或者proxy_http_version不是 1.1。对照上面 nginx 片段逐行检查。pip 安装卡死或报找不到包漏了--no-indexpip 在尝试连外网索引。加上--no-index --find-links指向本地目录。模型加载 OOM7B 模型 FP16 约 14G16G 内存机器扛不住。开quantize 4bit或加 swap放 SSD别放机械盘sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstabHTTPS 回调失败 / 证书不受信内网自签 CA 没进信任链。按第 3 节的update-ca-certificates和NODE_EXTRA_CA_CERTS处理。504 超时反代proxy_read_timeout太短改 300s。同时确认 CodeX 的timeout参数也放大。认证 401CODEX_AUTH_TOKEN环境变量没导出或客户端没带Authorization头。用env | grep CODEX确认。并发把 CPU 打满max_workers和max_concurrent没限制。按 CPU 核数减一设max_workersmax_concurrent设 2 到 4。6. 长期运行与统一接入建议内网部署稳定后真正省心的是把模型接入收敛。CodeX 本地推理适合高频、低延迟的补全复杂对话或需要更强模型的场景走 TaoToken 统一通道Key 和地址只维护一份。这样内网里不会出现“这台机器配了 A Key、那台配了 B Key”的混乱。长期编码或 Agent 类任务建议看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入细节和参数说明在文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。Key 管理在 API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。模型调试用模型对话https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后几个实操习惯生产环境别用 master 分支等 release 跑一个月再升日志级别生产用 WARNING调试用 DEBUG写个健康检查脚本挂 cron每 5 分钟调一次/health失败就记日志。内网升级成本高稳定比新功能重要。有 GPU 就优先 GPU没有就量化加限并发别让一个用户把资源占满。