企业官网建设流程全解析

1. 本地 Ollama 为什么需要一个聚合网关

很多人第一次接触本地大模型，都是被 Ollama 的简单打动：一条ollama run命令，模型就跑起来了。但当你真正把它接入日常工具链，问题会立刻冒出来。Ollama 默认监听11434端口，只对局域网开放，接口格式虽然兼容 OpenAI，但缺少鉴权、缺少额度控制、缺少调用日志。你把这套地址填进 Cline、CC Switch 或者自己写的脚本里，一旦换台机器、换个模型，所有客户端都要重新改配置。

更麻烦的是模型来源变多之后。本地跑着 qwen，云端还挂着 DeepSeek、通义千问，每个厂商的 Base URL、Key、模型 ID 都不一样。下游应用每接一个模型，就要维护一套参数。多人共用时，谁用了多少、哪个令牌该限速、哪个该停用，全靠文档记录，很快就会失控。

New-API 解决的正是这个位置的问题。它夹在模型服务和客户端之间，向下对接 Ollama 和各类云端 API，向上统一暴露成 OpenAI 兼容接口。客户端只保存一套服务器地址和令牌，模型映射、渠道轮询、额度限制、调用日志都在后台集中管理。对于已经同时用多个模型、或者要把接口分发给不同应用的人来说，这个中间层几乎是刚需。

我这次把 New-API 部署在刷了飞牛 NAS 的 N1 盒子上，而不是装在跑 Ollama 的 Windows 电脑里。原因是网关和推理环境分开更稳：N1 功耗低、能长期在线，负责鉴权和转发；Windows 电脑负责实际推理，关机或重启不影响网关本身。后续再加局域网 AI 服务器或云端渠道，只改 New-API 后台，不用动所有客户端。

需要提前说清楚前提。New-API 只做聚合和转发，不会提升 Ollama 的推理速度，响应时间仍取决于模型所在电脑的配置、模型大小和网络。Ollama 主机必须持续开机，并允许 N1 通过局域网访问11434端口。如果主机 IP 变化、防火墙拦截，对应渠道就会失效。N1 适合当网关，不适合扛大模型推理。

局域网调通之后，再用 cpolar 把 New-API 的3000端口映射到公网，异地设备和第三方应用就能通过公网地址调用家里的 Ollama。公网访问扩大了使用范围，也意味着令牌管理和后台安全更重要：管理员密码、访问令牌、固定公网地址都不该公开保存，分发接口时给不同用户单独设令牌、额度和有效期，避免多人共用一个长期密钥。

下面按 N1 飞牛 NAS 部署 New-API、初始化后台、安装测试 Ollama、添加渠道、创建令牌、配置 cpolar 公网地址的顺序，把这条链路走完。

2. TaoToken 统一 Key 与 New-API 的接入定位

在讲具体部署之前，先把 TaoToken 在这套架构里的角色说清楚，否则后面配置容易混。TaoToken 提供的是统一的 API 通道和 Key 管理能力，官网入口是https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=，API 地址是https://taotoken.net/api。它和 New-API 不是替代关系，而是可以叠加的两层：New-API 负责把本地 Ollama 和云端模型聚合成一个网关，TaoToken 则提供一套统一的 Key 和通道，让 Cline、CC Switch 这类工具用同一份配置接入多个模型来源。

为什么要在本地网关之外再引入 TaoToken？因为本地 Ollama 有个天然短板：它只在局域网可用，公网访问要靠 cpolar 这类穿透，而穿透地址会变、稳定性依赖家里网络。对于长期编码、Agent 调用这类场景，纯本地链路一旦家里断电或 IP 变动就会断。TaoToken 的 Coding Plan 适合长期编码和 Agent 场景，模型对话入口适合验证模型是否正常，API Keys 和接入文档则用于排障和接入。把本地 New-API 和 TaoToken 通道都配进客户端，等于给工具链上了双保险：本地优先，云端兜底。

具体到客户端配置，Cline、CC Switch、Codex 这类工具通常需要三件套：Base URL、Key、Model ID。以 Cline 为例，它的配置走settings.json，里面要填 API Provider、Base URL、API Key 和模型名。CC Switch 走的是config.toml骨架，需要指定 provider 的 base_url、api_key 和 model。Codex 则用auth.json保存凭据。这三件套无论接本地 New-API 还是接 TaoToken，字段结构是一样的，区别只在 Base URL 和 Key 的来源。

这里要强调一个容易踩的坑：很多人以为把 New-API 部署好、cpolar 穿透完，客户端就能自动连上。实际上客户端不会自己发现你的网关，必须手动把 Base URL 指向 New-API 的地址，把 Key 填成 New-API 里创建的令牌。如果同时用 TaoToken，就要在客户端里配两套 provider，或者用 CC Switch 这类支持多 provider 切换的工具来管理。Claude Code 这类工具如果没有配置步骤，光说“连上后就能用”是没意义的，必须把 Base URL、Key、Model ID 三件套写全。

TaoToken 的 deep link 入口按用途分流：模型对话用于验证模型是否正常，coding-plan 用于长期编码和 Agent，console 用于管理，api-keys 用于创建和查看 Key，doc 用于查接入文档，ClaudeCodeAnthropic 用于 Claude Code 相关接入。排障和接入优先看 API Keys 加接入文档，验证模型走模型对话，长期编码和 Agent 走 Coding Plan。这样分流的好处是，你不会在一个入口里找所有东西，减少配置时的迷茫。

把 TaoToken 和 New-API 放在一起看，整体链路就清晰了：Ollama 提供本地推理，New-API 聚合并暴露成标准接口，cpolar 把接口推到公网，TaoToken 提供统一 Key 和云端通道作为补充，客户端通过三件套配置接入。每一层各司其职，任何一层出问题都能单独排查，而不是一锅粥。

3. Docker 部署 New-API 与可复制配置

这一节直接给可复制的配置，不绕弯。N1 飞牛 NAS 自带 Docker 环境，先确认 Docker 服务已开启，然后在系统设置里启用 SSH。用电脑打开 PowerShell，执行ssh n1@192.168.50.228连上 NAS，其中n1是用户名，IP 换成你自己的。连上后执行sudo -i切到 root，输入密码时不显示是正常的。

接下来用一键脚本部署。执行curl -L https://gitee.com/jun-wan/script/raw/master/new_api_deploy/deploy_sqlite.sh -o deploy_sqlite.sh && ls把脚本下载下来，然后chmod +x deploy_sqlite.sh && bash deploy_sqlite.sh授权并运行。脚本会询问安装位置，如果外接了扩展硬盘，会看到扩展存储选项，选对应编号回车即可。部署完成后浏览器访问 NAS 的3000端口，能看到 New-API 页面就说明成功了。

如果你更习惯用docker-compose.yml管理，下面这份骨架可以直接改。注意把SQL_DSN换成你自己的数据库连接，SESSION_SECRET和CRYPTO_SECRET换成随机字符串，不要用默认值。

version: "3.8" services: new-api: image: calciumion/new-api:latest container_name: new-api restart: always ports: - "3000:3000" environment: - SQL_DSN=root:yourpassword@tcp(mysql:3306)/new-api - REDIS_CONN_STRING=redis://redis:6379 - SESSION_SECRET=replace_with_random_string - CRYPTO_SECRET=replace_with_random_string - TZ=Asia/Shanghai depends_on: - mysql - redis volumes: - ./data:/data mysql: image: mysql:8.0 container_name: new-api-mysql restart: always environment: - MYSQL_ROOT_PASSWORD=yourpassword - MYSQL_DATABASE=new-api volumes: - ./mysql:/var/lib/mysql redis: image: redis:latest container_name: new-api-redis restart: always volumes: - ./redis:/data

部署完成后访问http://192.168.50.228:3000，进入初始化流程。数据库检查页点下一步，创建管理员账号密码，使用模式选自用模式，点初始化系统。如果没自动登录，点右上角登录，输入刚才的账号密码进后台。

接下来配置 Ollama 渠道。先在 Windows 电脑上装 Ollama，PowerShell 执行irm https://ollama.com/install.ps1 | iex，然后ollama --version确认安装。下载模型用ollama run qwen3.5:0.8b，这个模型大概 1G 左右，适合测试。测试 API 服务用Invoke-RestMethod -Method Post -Uri "http://localhost:11434/v1/chat/completions" -ContentType "application/json" -Body '{"model": "qwen3.5:0.8b", "messages": [{"role": "user", "content": "hi"}], "stream": false}'，能返回结果就说明 Ollama 的 OpenAI 兼容接口正常。

回到 New-API 后台，左侧渠道管理点添加渠道。类型选 Ollama，名称自定义，密钥随便填一个（Ollama 默认不校验），API 地址填 Windows 电脑的局域网 IP，比如http://192.168.50.100:11434。不知道 IP 就在 Windows 终端执行ipconfig | findstr "IPv4"。模型部分点获取模型列表，选中qwen3.5:0.8b确定，提交后点测试，出现测试成功就说明渠道通了。

然后创建令牌。左侧令牌管理点添加令牌，填好名称、额度、有效期，提交后复制令牌。用 CMD 测试：

curl http://192.168.50.228:3000/v1/chat/completions ^ -H "Content-Type: application/json" ^ -H "Authorization: Bearer sk-你的令牌" ^ -d "{\"model\": \"qwen3.5:0.8b\", \"messages\": [{\"role\": \"user\", \"content\": \"你好\"}], \"stream\": false}"

返回正常内容，说明局域网链路已经打通。这一步的settings.json骨架可以这样写，供 Cline 这类工具参考：

{ "apiProvider": "openai", "openAiBaseUrl": "http://192.168.50.228:3000/v1", "openAiApiKey": "sk-你的令牌", "openAiModelId": "qwen3.5:0.8b" }

如果同时接 TaoToken，再加一套 provider，Base URL 用https://taotoken.net/api，Key 用 TaoToken 的 API Keys，Model ID 按实际模型填。CC Switch 的config.toml骨架类似：

[[providers]] name = "local-newapi" base_url = "http://192.168.50.228:3000/v1" api_key = "sk-你的令牌" model = "qwen3.5:0.8b" [[providers]] name = "taotoken" base_url = "https://taotoken.net/api" api_key = "你的TaoToken Key" model = "你的模型ID"

Codex 的auth.json则保存凭据字段，结构上同样是 Base URL、Key、Model ID 三件套。把这三件套写全，客户端才能正确路由请求。

4. cpolar 内网穿透与公网验证请求

局域网调通后，接口还只能在家里用。要让异地设备调用，需要把 New-API 的3000端口映射到公网。cpolar 是常用的内网穿透工具，支持 Linux、NAS 等平台，提供一键安装脚本。在 NAS 终端执行sudo curl https://get.cpolar.sh | sh安装，然后sudo systemctl status cpolar查看服务状态，显示正常启动即可。

接着注册 cpolar 账号，浏览器访问 NAS 的9200端口，比如http://192.168.50.228:9200/，用注册好的账号登录后台。左侧隧道管理进隧道列表，默认会有 ssh 和 website 两条隧道。点创建隧道，隧道名称填newapi，本地地址填3000，协议选 http，创建完成后在状态下的在线隧道列表里能看到刚创建的隧道，复制 https 公网地址。

用这个公网地址访问 New-API 页面，加载稍慢是正常的，能打开就说明穿透成功。然后用公网地址测试接口：

curl https://你的cpolar公网地址/v1/chat/completions ^ -H "Content-Type: application/json" ^ -H "Authorization: Bearer sk-你的令牌" ^ -d "{\"model\": \"qwen3.5:0.8b\", \"messages\": [{\"role\": \"user\", \"content\": \"你好\"}], \"stream\": false}"

返回正常内容，说明公网链路也通了。但免费随机域名每 24 小时会变一次，长期用会断。要固定地址，进 cpolar 官网预留页面，选保留二级子域名，填地区、名称、描述，点保留。然后在隧道列表编辑newapi隧道，域名类型改成二级子域名，填刚才保留的子域名，更新。回到在线隧道列表，公网地址就变成固定的二级子域名形式了。

这里有个细节：首页显示的网站地址可以在系统设置里的服务器地址中修改，改成你的固定公网地址，这样后台里展示的地址和实际一致，减少混淆。

验证请求时，如果同时用 TaoToken，可以对比两条链路的返回。TaoToken 的模型对话入口适合快速验证模型是否正常，API Keys 和接入文档用于排障。本地 New-API 链路适合验证 Ollama 是否在线、渠道是否通。两条链路都验证过，客户端配置才有底气。

需要提醒的是，公网暴露 New-API 后台后，管理员密码和令牌安全更重要。不要用弱密码，不要公开分享长期令牌，给不同用户单独建令牌并设额度。cpolar 的固定二级子域名虽然方便，但也要注意不要泄露到公开渠道。

5. 常见报错排查与真实错误对照

配置过程中最容易遇到的几类报错，这里逐个对照。

第一类是401 Unauthorized。这通常出现在客户端调用 New-API 或 TaoToken 时，原因是 Key 不对或没带 Authorization 头。检查settings.json里的openAiApiKey是否和 New-API 令牌管理里复制的一致，注意令牌前缀sk-不要漏。如果接 TaoToken，检查 API Keys 是否有效、是否过期。401 也可能是 Base URL 写错，比如把/v1漏了，或者把https://taotoken.net/api写成了别的路径。

第二类是local proxy failed或连接被拒绝。这通常出现在 New-API 转发到 Ollama 时，原因是 Ollama 主机不可达。检查 Windows 电脑是否开机、Ollama 是否在运行、11434端口是否监听。在 NAS 上执行curl http://192.168.50.100:11434/v1/models测试，如果连不上，检查 Windows 防火墙是否放行11434，以及 IP 是否变化。Ollama 默认只监听127.0.0.1，需要设置OLLAMA_HOST=0.0.0.0才能被局域网访问，这一步很多人会漏。

第三类是reading choices相关错误。这通常出现在客户端解析响应时，原因是返回格式不符合预期。检查 New-API 渠道类型是否选对，Ollama 渠道要用 Ollama 类型，不要选 OpenAI 类型。检查模型 ID 是否和 Ollama 里的模型名完全一致，大小写和标签都要对。如果用了模型映射，确认映射后的名称和客户端请求的一致。

第四类是 OAuth 或认证相关错误。这通常出现在 Claude Code 或 Codex 这类工具有自己的认证流程时。如果工具要求 OAuth 登录，而你想用 API Key 接入，需要在工具配置里切换到 API Key 模式，把 Base URL 指向 New-API 或 TaoToken，Key 填对应令牌。Codex 的auth.json要确保字段名和工具要求的一致，不要自己造字段。

第五类是 cpolar 隧道连不上或地址失效。免费随机域名 24 小时变一次，如果客户端还填着旧地址，就会连不上。解决办法是配置固定二级子域名，或者每次变化后更新客户端配置。如果隧道显示在线但访问超时，检查 NAS 的3000端口是否正常、New-API 容器是否在运行。

排查时建议按链路分段：先测 Ollama 本机11434，再测局域网 New-API3000，再测 cpolar 公网地址，最后测客户端。哪一段断，就查哪一段。不要一上来就改客户端配置，那样容易越改越乱。

6. 统一 Key 接入 AI 工具的长期实践

把本地 Ollama 经 New-API 暴露成公网 API，再叠加 TaoToken 统一 Key，这套组合的价值不在于炫技，而在于让工具链稳定。Cline、CC Switch、Codex 这些工具每天都要调用模型，如果每次换模型都改配置，效率会被拖垮。统一网关加统一 Key 之后，客户端只认一套地址和令牌，模型切换在后台完成。

长期运行时，有几个实践建议。第一，给不同用途建不同令牌，比如 Cline 一个、脚本一个、临时分享一个，各自设额度和有效期，出问题能快速定位和停用。第二，本地链路和 TaoToken 链路都配进客户端，本地优先，云端兜底，家里网络波动时不至于完全断掉。第三，定期看 New-API 的调用日志，了解哪个模型用得多、哪个令牌消耗快，及时调整。

TaoToken 的入口按用途分流：排障和接入看 API Keys 加接入文档，验证模型走模型对话，长期编码和 Agent 走 Coding Plan。这样你不会在一个入口里找所有东西。官网入口是https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=，API 地址是https://taotoken.net/api，配置时注意区分。

最后说一个实际经验：N1 盒子当网关很合适，但不要指望它跑模型。Ollama 主机持续在线是这套方案的前提，如果主机经常关机，公网接口就会时好时坏。把网关和推理分开，各司其职，才是长期稳定的关键。客户端配置里把 Base URL、Key、Model ID 三件套写全，比任何“连上就能用”的空话都实在。