项目地址： GitHub - finch-xu/cc-router ｜ 下载客户端 ｜ 官方 Codex 集成文档

cc-switch： Codex 客户端的多供应商切换器，安装入口见上方官方 Codex 集成文档页

工作架构

1
2
3
4
5
6
7

Codex CLI / Codex Desktop      cc-switch              cc-router (本地)             上游 Provider
┌──────────────────────┐    ┌──────────────┐       ┌──────────────────┐         ┌────────────┐
│  发起对话             │───▶│ 供应商切换    │──────▶│ :23456 网关       │────────▶│ Claude     │
│  选择虚拟模型         │    │ (cc-router/  │       │ + 虚拟模型路由     │         │ DeepSeek   │
│                      │    │  OpenAI/...) │       │ + 请求日志         │         │ Kimi / GLM │
└──────────────────────┘    └──────────────┘       └──────────────────┘         │ ...        │
                                                                                  └────────────┘

这条链路里两层职责分得很清：

• cc-switch 负责”我现在让 Codex 走哪个供应商” —— 在 OpenAI 官方账号、cc-router、其他自定义 OpenAI 兼容端点之间一键切换，配置写入 ~/.codex/config.toml
• cc-router 负责”我这条请求最终落到哪家上游” —— 接受 Codex 通过 cc-switch 转过来的 HTTP 请求，按虚拟模型槽位（opus/sonnet/haiku）路由到具体厂商，并处理限流降级

也就是说：在 cc-switch 这一步告诉 Codex “请求发到 cc-router 的本地端口”，在 cc-router 这一步告诉它”opus 槽位用 DeepSeek、sonnet 槽位用 Kimi”，二者合在一起就把整个调度链拉通了。

前置准备

• cc-router 已安装并至少绑定一个虚拟模型（opus / sonnet / haiku 任选其一）。还没装的看 入门文档 或本博客 cc-router 系列前几篇
• cc-switch 已安装。下载入口见 官方 Codex 集成文档
• Codex CLI 或 Codex Desktop 至少装好一个，二者配置共享同一份 ~/.codex/config.toml
• 从 cc-router 设置页提前复制好 API Key（后面要粘进 cc-switch）

步骤一：打开 cc-switch，切到 Codex 供应商

cc-switch 同时管 Claude 和 Codex 两套供应商，第一步先把界面切到 Codex 那一侧。点顶部工具栏的 Codex 图标（GPT 标志），下方面板会切换到当前已配置的 Codex 供应商列表 —— 一般这里会有 OpenAI 官方账号（如果之前登录过）。

步骤二：新增一个自定义 Codex 供应商

cc-router 不在 cc-switch 内置厂商列表里，需要走”自定义配置”入口手动添加。

点右上角的 橙色 + 号 按钮 → 保持在「Codex 供应商」标签页 → 选左上角第一个蓝色 tile 「自定义配置」。

步骤三：填写 cc-router 的接口信息

这一步是全文最关键的一步，填错任何一项都会导致后面 Codex 报 404 或 401。

API 请求地址末尾必须带 /v1。 cc-switch 默认按相对路径在末尾拼接 /responses，如果你填成 http://127.0.0.1:23456（缺 /v1），实际请求路径会变成 /responses，cc-router 找不到这个路由直接返回 404。这是初次接入最容易踩的坑。

模型名映射到 cc-router 的虚拟槽位如下：

模型名用的是 OpenAI 风格的别名，而不是 Anthropic 的 claude-opus-4-7 —— 因为 Codex 那边只认 OpenAI 协议的模型名，cc-router 在网关层做了别名映射。

填完点保存。

步骤四：在 Codex CLI 里验证

cc-switch 保存后会立刻把配置写进 ~/.codex/config.toml，CLI 这边再启动就能读到新供应商。

打开终端跑 codex 进入 CLI，先确认顶部状态栏里的 模型名是刚才填的 gpt-5.5 / gpt-5.4 / gpt-5.4-mini 之一，而不是 OpenAI 官方的 gpt-5 或 o5 这类原始模型名。然后发一条测试消息，比如「你好，请简单介绍下自己，并告诉我你是什么模型」。

正常情况下应该几秒钟内开始流式返回内容，下面这张截图就是 CLI 跑通时的状态。

如果模型回的是 OpenAI 风格的自我介绍，那说明请求其实没走到 cc-router，而是落到了 OpenAI 官方 —— 这种情况回 cc-switch 检查当前激活的供应商是不是「cc-router」那一项。

步骤五：在 Codex Desktop 里验证

Codex Desktop 和 CLI 共享同一份 ~/.codex/config.toml，但有一个坑要注意。

如果你之前登录过 OpenAI 账号，Codex Desktop 进程内会缓存旧的供应商配置，cc-switch 的改动不会立刻生效。 解决办法：完全退出 Codex Desktop（macOS 上 Cmd+Q，不是只关闭窗口），重新打开。

重启后在对话窗口的模型选择器里点开，应该能看到刚才在 cc-switch 里配置的模型名（gpt-5.5 / gpt-5.4 / gpt-5.4-mini），选一个，发条测试消息，成功的样子如下图。

步骤六：回到 cc-router 看请求日志

闭环验证：回到 cc-router 主界面，切到 请求日志 页面，能看到刚才从 Codex CLI / Codex Desktop 发的那两条请求 —— 每条记录会显示：

• 客户端字段：Codex CLI 或 Codex Desktop（说明 cc-router 正确识别了请求来源）
• 请求模型：你在 cc-switch 里填的 gpt-5.5 / gpt-5.4 / gpt-5.4-mini
• 路由到的虚拟槽位：model-opus / model-sonnet / model-haiku
• 真实上游：DeepSeek / Kimi / GLM / Claude 之类（取决于你给虚拟槽位绑了哪家）
• 耗时与 token 数

看到日志里出现刚发的请求，整条链路就跑通了 —— Codex 客户端 → cc-switch 选 cc-router → cc-router 按槽位路由 → 真实上游 provider。

请求链路时序

发完一条消息后整条链路是这样跑的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Codex CLI/Desktop          cc-switch          cc-router :23456            上游 provider
    │                          │                    │                          │
    │ 启动时读 config.toml      │                    │                          │
    ├─────────────────────────▶│                    │                          │
    │ 拿到 base_url = http://  │                    │                          │
    │ 127.0.0.1:23456/v1       │                    │                          │
    │                                               │                          │
    │ POST /v1/responses                            │                          │
    │ Bearer <api-key>                              │                          │
    │ model: gpt-5.4                                │                          │
    ├──────────────────────────────────────────────▶│                          │
    │                                               │ 解析模型名 → sonnet 槽位  │
    │                                               │ 选 provider (权重/健康度) │
    │                                               │ 翻译成上游协议            │
    │                                               ├─────────────────────────▶│
    │                                               │                          │
    │                                               │◀──── stream chunks ──────│
    │◀────────────── stream chunks ─────────────────│                          │
    │                                               │ 写日志：客户端/模型/耗时   │

如果某家 provider 返回 429 或 5xx，cc-router 会自动在同一槽位内 fallback 到下一家，对 Codex 端透明。

排错速查

安全提醒

• API Key 等同于你所有上游 provider 的访问权 —— 泄漏意味着别人能消耗你 Claude、DeepSeek、Kimi 等所有厂商的额度，请勿截图、勿提交到 git、勿粘到聊天群
• ~/.codex/config.toml 里 API Key 是明文存储 —— 用云盘同步或备份系统时注意排除这个文件，或单独加密
• 局域网开放需谨慎 —— :23456 默认只监听 127.0.0.1，跨机器使用前确认你处在受信任的局域网；公网暴露请配反向代理 + IP 白名单 + 鉴权

参考链接

• cc-router GitHub 仓库：finch-xu/cc-router
• 下载客户端：GitHub Releases
• 官方主页：ccrouter.app
• 官方 Codex 集成文档：ccrouter.app/docs/codex-integration
• 入门文档：ccrouter.app/docs/getting-started

项目地址： GitHub - finch-xu/cc-router ｜ 官方主页 ｜ 入门文档

DeepSeek： 开发者平台 ｜ API 文档 ｜ API Keys

为什么是 DeepSeek V4 Pro

DeepSeek 2026 年发布的 V4 系列把模型清单收敛成两个：

• deepseek-v4-pro —— 旗舰，对标 Claude Opus / GPT 顶配，适合放在 cc-router 的 model-opus 槽位
• deepseek-v4-flash —— 轻量低延迟，适合放在 model-haiku 槽位接 subagent 这种高频小请求

老的 deepseek-chat / deepseek-reasoner 在 2026-07-24 弃用，DeepSeek 官方文档里已经标注，新接入直接用 V4 系列即可。

协议上 DeepSeek 走的是 OpenAI Chat Completions 兼容接口，base URL https://api.deepseek.com。cc-router 已经内置了 DeepSeek 这个 provider（在 cc-router 的厂商列表里归类为「按量付费」），不需要走「自定义 OpenAI 兼容」入口，省一步配置。计费形态是预付余额、按 token 计算，没有月度套餐 —— 这点和 Claude / GLM 那种 Token Plan 不同，首次接入记得先充小额测试。

整体连接架构

cc-router 在本地起一个 Anthropic 协议代理（默认 127.0.0.1:23456），向上对接 Claude Code，向下转发到 DeepSeek 官方 API：

1
2
3
4
5
6
7
8
9
10

 claude CLI              cc-router (本地)              DeepSeek 官方
┌──────────┐            ┌─────────────────┐         ┌──────────────────┐
│ HTTP     │──────────▶│ 127.0.0.1:23456 │───────▶ │ api.deepseek.com │
│ Anthropic│            │ 协议翻译         │         │ deepseek-v4-pro  │
│ 协议     │            │ 三槽位虚拟模型   │         │ deepseek-v4-flash│
└──────────┘            └─────────────────┘         └──────────────────┘
       ▲                        │
       │                        └── 请求日志页实时可见
   ~/.claude/settings.json
   注入 env 变量

Claude Code 这边其实什么都不用改，它原本就支持通过环境变量改写 base URL 和模型名，cc-router 接管的正是这两个口子，外加把 Anthropic 协议的 messages / tool_use 翻译成 OpenAI 协议的 messages / tool_calls 转发给 DeepSeek。

步骤一：在 DeepSeek 平台申请 API Key

打开 platform.deepseek.com，注册或登录。

进入 充值 页面预存一点余额。按量计费没有免费额度，必须有余额账号才能调用 API；首次测试充 10 块钱足够跑通整条链路 + 跑几个简单任务。

然后到 API Keys 页面 → Create new API key → 起个名字（比如 cc-router-local）→ 立即复制 生成的 sk-xxxxxxxx 串。关闭对话框后就再也看不到完整 key 了，DeepSeek 平台只在这一次明文展示。复制完粘到密码管理器或者直接进下一步。

如果手抄漏了字符，回这里删掉旧 key 重新生成一个，不要尝试在仪表盘上「找回」。

步骤二：下载并启动 cc-router

cc-router 是 Tauri 写的桌面应用，macOS / Windows / Linux 都有打包好的版本，直接到 GitHub Releases 或 ccrouter.app/download 下载对应平台的 .dmg / .exe / .AppImage / .deb。

装完打开 App，本地代理服务会自动起在 127.0.0.1:23456。

如果 23456 端口被别的进程占了，cc-router 会自动 +1 往后递增（23457、23458……）。所以不要把 23456 硬编码到 settings.json 里，要回到 cc-router 设置页确认实际监听端口再复制 —— 这是踩坑率最高的一项。

步骤三：在 cc-router 里添加 DeepSeek provider

进入 订阅 / Providers 页 → 添加订阅。

厂商列表里找 DeepSeek（按量付费） —— 注意 cc-router 把每家厂商的「按量付费」和「Token Plan」做了区分入口，DeepSeek 这边只有按量付费一种接入方式。

填写界面里要注意：

• Base URL / Endpoint 不需要手动填。这是内置 provider，cc-router 自动用官方接入点 https://api.deepseek.com。
• API Key 字段：粘上一步从 DeepSeek 平台领的 sk-xxx。
• 保存后 cc-router 会自动调用 /v1/models 抓一遍该 key 可用的模型列表，正常情况下你应该在面板里看到 deepseek-v4-pro、deepseek-v4-flash，以及可能存在的过渡模型如 deepseek-chat / deepseek-reasoner（这两个 2026-07-24 弃用，看到了不必绑）。

如果你拉出来的列表是空的，绝大多数情况是 key 拼错或者账户没充值，回上一步确认 DeepSeek 平台显示「余额 > 0」且 key 状态 active。

顺便提一下：cc-router 还提供「自定义 (Anthropic 协议)」和「自定义 (Gemini 兼容)」两个泛用入口，给那些没在内置列表里的小众 provider 用。DeepSeek 是内置 provider，不要走自定义入口，否则你得自己填 base URL、headers、模型映射，纯粹给自己找麻烦。

步骤四：把模型绑到虚拟槽位

cc-router 对外暴露的不是真实模型名，而是三个虚拟槽位 —— model-opus / model-sonnet / model-haiku。Claude Code 请求过来时只认这三个别名，cc-router 根据每个槽位的绑定情况决定打到哪家 provider 的哪个真实模型。

进 模型 / Models 页，对每个虚拟槽位单独配置：

为什么 sonnet 也绑 v4-pro 而不是 flash？Claude Code 把 subagent / Task tool 的默认模型挂在 sonnet 槽位（除非你显式覆盖 CLAUDE_CODE_SUBAGENT_MODEL）。subagent 是要独立干一段子任务的，把它降级到 flash 等于让一个轻量模型独立完成代码搜索、重构判断这种事，结果质量会被拉低，而你在主对话看到的是「subagent 给的总结」，问题会被层层包裹得不容易追溯。两个槽位都绑旗舰，代价是这两个槽位的请求都按 v4-pro 价位计费，但调试体验干净很多。haiku 槽位 Claude Code 用来跑短小的辅助请求（命令生成、文件名建议这类），给 flash 即可。

调度模式 在「同一个槽位绑多家 provider」时才有意义，单家 DeepSeek 直接绑就行。等之后你想加挂第二家厂商做 fallback，再回到这里选：

• Sequential：A 用完或失败才切 B，保留 prompt cache，适合「先榨干主力账号再切备用」
• Round-robin：请求间轮换，真负载均衡，但会破坏单家的 prompt cache 命中率

步骤五：复制 cc-router 的 token 和 base URL

打开 cc-router → 设置 → 代理服务，这一页有两个东西要抄：

1. Base URL：http://127.0.0.1:实际端口，注意是 http:// 不是 https://，端口看实际监听值（可能被 +1）
2. Token / API Key：cc-router 自己生成的一串字符串，Claude Code 用这个鉴权进 cc-router（不是 DeepSeek 那个 sk-xxx）

用页面上的复制按钮，避免手抄漏字符。

⚠️ 这个 token 等同于你所有挂在 cc-router 上的上游订阅的访问权（这里就是你的 DeepSeek 余额）。不要截图、不要 push 到 git、不要发到群里。

步骤六：写入 ~/.claude/settings.json

Claude Code 启动时会读 ~/.claude/settings.json，把 env 字段里的所有键值对当成环境变量注入到自己进程，这是官方支持的扩展点。文件位置三平台都是同一个：

• macOS / Linux：~/.claude/settings.json
• Windows：%USERPROFILE%\.claude\settings.json

文件不存在就新建，已存在就合并 env 字段（其它字段别动）。完整模板：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://127.0.0.1:23456",
    "ANTHROPIC_AUTH_TOKEN": "这里填写cc-router设置里真实token",
    "API_TIMEOUT_MS": "3000000",
    "ANTHROPIC_MODEL": "model-opus",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "model-opus",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "model-sonnet",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "model-haiku",
    "CLAUDE_CODE_SUBAGENT_MODEL": "model-opus",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK": "1",
    "CLAUDE_CODE_ATTRIBUTION_HEADER": "0",
    "CLAUDE_CODE_EFFORT_LEVEL": "max"
  }
}

四个最容易踩坑的字段：

字段全集和每个 env 的细节看用 cc-router 接入 Claude Code，本文不再重复。

步骤七：起 claude，发一条话验证

如果还没装 Claude Code：

1

curl -fsSL https://claude.ai/install.sh | bash

随便进一个目录，运行：

1

claude

进入对话后随便问一句，比如「写一段 Hello World 的 Python 代码」。

切回 cc-router 主界面，进请求日志页 —— 应该能看到刚刚那条请求的记录：哪个虚拟槽位（model-opus）、被路由到哪家上游 provider（DeepSeek）、命中的真实模型（deepseek-v4-pro）、消耗了多少 token、响应耗时多少。如果日志页没动静，说明请求根本没走到 cc-router，回去检查 ANTHROPIC_BASE_URL 的端口对不对、settings.json 是不是合法 JSON、是否完整退出 claude 进程再重开。

DeepSeek V4 Pro 用起来要注意的点

• 看到老模型 ID 别绑。如果 cc-router 抓出来的模型列表里只有 deepseek-chat / deepseek-reasoner 没有 deepseek-v4-pro，说明账号还在旧模型分组里，去 DeepSeek 平台后台切到 V4 系列。两个老模型 2026-07-24 弃用，没必要绑。
• 按量计费 = 没有免费额度。第一次跑 Claude Code 一个简单任务（几次工具调用 + 几千 token 输出）可能消耗几分到几毛钱，正常。盯着 DeepSeek 平台的余额面板，跑大任务前充够。
• 协议翻译在 cc-router 这一层。DeepSeek 用 OpenAI 协议但 Claude Code 发的是 Anthropic 协议，cc-router 在中间做字段映射。如果遇到 tool_use 行为怪异、长 prompt 截断之类的怪现象，先看 cc-router 请求日志页的原始报文，能直接看到「Anthropic 协议进 / OpenAI 协议出」两段，判断是协议翻译的问题还是 DeepSeek 端的问题。
• 单家 provider 不要勾 Round-robin。Round-robin 是给多家 provider 设计的，单挂 DeepSeek 一家时它和 Sequential 没区别，但开了反而会让 cc-router 内部多走一段无意义的轮询逻辑。等真挂了第二家再回来调度模式选项。

排错速查

安全提醒

• DeepSeek 的 sk-xxx 直接控制你的余额。cc-router 把这个 key 存在本地配置目录里，不要把 cc-router 的配置文件夹整体备份到公开仓库或云盘共享链接。
• cc-router 自身的聚合 token 比单一 DeepSeek key 后果更严重 —— 一旦泄漏，攻击者可以消耗你挂在 cc-router 上的所有上游订阅，不只是 DeepSeek 这一家。单独保管，不要和 DeepSeek key 放一起。
• HTTP 监听仅限本机环回。127.0.0.1:23456 默认只对本机可见，不要为了「在另一台机器上用」把端口暴露到公网。跨机器调用走 cc-router 自带的 HTTPS 模式 + 自签 CA，参考相关阅读那篇 Claude Desktop 接入教程。
• DeepSeek 的 ToS 自己遵守。cc-router 是透明代理，不解除任何 provider 端的限制；高频跨账号轮询有被限速或封号风险。

相关阅读

• 用 cc-router 接入 Claude Code：一份 settings.json 把多家订阅塞进 CLI —— settings.json 字段全集和每个 env 的细节
• 用 cc-router 接入 Claude Desktop：一个 Token 调度多家模型订阅 —— HTTPS Gateway + 自签 CA 跨机器方案

参考链接

• cc-router：GitHub 仓库 / 官方主页 / 入门文档 / GitHub Releases 下载
• DeepSeek：开发者平台 / API 文档 / API Keys 申请页

首先按照 https://pidan.dev/20250721/webrtc-livekit-deploy-with-tls/ 这里的部署方式，使用官方的教程创建好各种启动的配置文件。然后我们修改一下这些配置文件，来使用我们自己申请的证书文件。

你也可以直接复制本文的各种配置文件直接启动livekit，不走他的官方启动流程也是没问题的。

设置域名解析

我们配置两个域名都解析到这台公网服务器，并且我们已经下载了他们的ssl证书文件。

• lk.abc.com 此域名为livekit的域名
• lk-turn.abc.com 此域名为livekit内置的turn的域名

你的公网服务器防火墙需要开启的端口：

• 8443/TCP livekit接口 HTTPS and TURN/TLS
• 3478/UDP TURN/UDP 网络线路条件良好的情况下，此端口不开也能使用，但是推荐开。
• 50000-50100/UDP WebRTC over UDP

实测上边的这几个端口是必须开的.

配置caddy

编辑或创建caddy.yaml文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

logging:
  logs:
    default:
      level: INFO
storage:
  "module": "file_system"
  "root": "/data"
apps:
  tls:
    certificates:
      load_files:  # 这里挂载自己的ssl证书，我申请的免费证书，两个域名所以申请两个，你有通配符证书最好了。
        - certificate: "/cert/lk.abc.com_bundle.pem"
          key: "/cert/lk.abc.com.key"
        - certificate: "/cert/lk-turn.abc.com_bundle.pem"
          key: "/cert/lk-turn.abc.com.key"
  layer4:
    servers:
      main:
        listen: [":8443"]   # 这里可以设置443，如果你不能用443，那么设置成别的，这里要和docker-compose里开放的端口对应
        routes:
          - match:
            - tls:
                sni:
                  - "lk-turn.abc.com"   # 修改为自己的域名
            handle:
              - handler: tls
              - handler: proxy
                upstreams:
                  - dial: ["livekit:5349"]  # 这里的livekit为docker-compose定义的服务名
          - match:
              - tls:
                  sni:
                    - "lk.abc.com"    # 修改为自己的域名
            handle:
              - handler: tls
                connection_policies:
                  - alpn: ["http/1.1"]
              - handler: proxy
                upstreams:
                  - dial: ["livekit:7880"]   # 这里的livekit为docker-compose定义的服务名

配置livekit配置文件

编辑或创建livekit.yaml文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

port: 7880
bind_addresses:
    - ""
rtc:
    tcp_port: 7881
    port_range_start: 50000
    port_range_end: 50100    # 这里端口范围不能设置太大，会把机器卡死，比如设置100到1000范围就够用了，自己测试用100就够了。
    use_external_ip: true
    enable_loopback_candidate: false
redis:
    address: lk-redis:6379
    username: ""
    password: ""
    db: 0
    use_tls: false
    sentinel_master_name: ""
    sentinel_username: ""
    sentinel_password: ""
    sentinel_addresses: []
    cluster_addresses: []
    max_redirects: null
turn:
    enabled: true
    domain: lk-turn.abc.com    # 修改为自己的域名
    tls_port: 5349
    udp_port: 3478
    external_tls: true
keys:
    APIVg796bZUscSq: p60ixbfgRFssDXAH8tWJfyxg2ftmfZeIw0QCki53fYZI   # 生成自己的ak sk

修改redis配置

编辑或创建redis.conf文件

1
2
3
4
5

bind 0.0.0.0   # 这里放开
protected-mode no   # 这里关闭
port 6379
timeout 0
tcp-keepalive 300

修改docker compose文件

编辑或创建docker-compose.yaml文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

services:
  lk-caddy:
    image: livekit/caddyl4
    command: run --config /etc/caddy.yaml --adapter yaml
    restart: unless-stopped
    ports:
      - "8443:8443"
    volumes:
      - ./caddy.yaml:/etc/caddy.yaml  # 挂载刚才编辑的配置文件
      - ./caddy_data:/data
      - ./cert:/cert     # 挂载自己的ssl证书文件
    networks:
      - livekit-network
  livekit:
    image: livekit/livekit-server:latest
    command: --config /etc/livekit.yaml
    restart: unless-stopped
    ports:
      - "7880:7880"               # LiveKit HTTP/WebSocket 端口
      - "7881:7881"               # LiveKit RTC 信令端口(如果使用)
      - "5349:5349"               # TURN over TLS 端口
      - "3478:3478/udp"           # TURN UDP 端口
      - "3478:3478/tcp"           # TURN TCP 端口
      - "50000-50100:50000-50100/udp"  # RTC 端口范围，注意和livekit.yaml中配置的端口范围一致
    volumes:
      - ./livekit.yaml:/etc/livekit.yaml
    environment:
      - TZ=Asia/Shanghai
    ulimits:
      nproc: 65535   # 高性能实时服务器需要配置Linux系统参数
      nofile:
        soft: 65535
        hard: 70000
    networks:
      - livekit-network
  lk-redis:
    image: redis:7-alpine
    command: redis-server /etc/redis.conf
    restart: unless-stopped
    volumes:
      - ./redis.conf:/etc/redis.conf
    networks:
      - livekit-network
networks:
  livekit-network:
    driver: bridge

放置ssl证书文件

证书我从腾讯云申请的免费ssl证书文件。

• cloud.tencent.com_bundle.crt 证书文件
• cloud.tencent.com_bundle.pem 证书文件
• cloud.tencent.com.key 私钥文件
• cloud.tencent.com.csr CSR 文件

创建目录并放到./cert目录下。然后设置权限

1
2
3

cd ./cert
chmod 644 *.crt
chmod 600 *.key

启动livekit服务

1
2
3
4
5

docker compose up -d

docker compose down

docker compose logs -f --tail 1000

测试连通性

https://livekit.io/connection-test 使用官方的测试页面进行测试

此时我们的livekit服务接口为wss://lk.abc.com:8443

至于token需要调用官方的sdk生成一下，比如下边是我写的一个livekit go sdk的示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

package main

import (
 "fmt"
 "github.com/livekit/protocol/auth"
 "time"
)

func NewAccessToken(roomName, pID string) (string, error) {

 apiKey := "APIgJX"    // 填写你刚才代码生成的apiKey
 apiSecret := "AXBbhpWBguYelOy6c"    // 填写你刚才代码生成的apiSecret

 at := auth.NewAccessToken(apiKey, apiSecret)
 grant := &auth.VideoGrant{
  RoomJoin: true,
  Room:     roomName,
 }
 at.SetVideoGrant(grant).
  SetIdentity(pID).
  SetName(pID).
  SetValidFor(time.Hour * 24 * 30) // 30天过期

 return at.ToJWT()
}

func main() {
 token, _ := NewAccessToken("room001", "user002")    // 房间名，用户参会者名字
 fmt.Printf(token)
}

参考

https://docs.livekit.io/home/self-hosting/vm/
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/