配置 TLS 检查代理
Cherri Bot 桌面应用会从每位成员的设备连接到两个目标：一是 Cherri Code 的 API (*.cursor.sh) ，用于聊天、登录和批准；二是成员的托管计算机，其主机名为多级形式的 *.*.cursorvm.com，用于计算机设置、屏幕和 shell。检查 TLS 的安全网页网关往往放行前者却阻断后者。此时桌面应用会在计算机设置过程中卡住或报错；在某些环境下，聊天照常可用，计算机却始终连不上。Zscaler 是最常见的例子，本页面以它为例进行具体说明；相同的步骤同样适用于任何会重新签发 TLS 或缓冲响应的网关。本页面面向负责运维网关的 IT 团队。通用域名列表和流式测试见企业版网络配置；本页面仅说明 Cherri Bot 额外涉及的内容。
症状
- 计算机设置卡住或失败。 应用始终无法完成与 computer 的连接。聊天 可能仍然正常，因为它可以访问
api2.cursor.sh，也可能一同卡住；无论哪种情况，computer 的连接都需要cursorvm.com。 - 在热点或个人设备上正常，但在企业网络中或网关客户端运行时失败。
- 在办公室正常，在家失败。 例外规则仅对办公室所在位置生效。参见应用到每个配置文件。
- 登录或 聊天 同样卡住。
cursor.sh上的 TLS 检查或响应缓冲仍处于启用状态。
允许这些域名模式
请在网关和所有 DNS 过滤中放行以下全部条目。建议使用通配符，而不是逐一列举主机名；计算机主机名是按每台计算机生成的。
| 模式 | 用途 |
|---|---|
*.cursor.sh | 聊天、登录、批准以及其他 Cherri Code API |
*.cursor-cdn.com | 静态资源 |
*.cursorapi.com | 扩展市场及相关 API |
*.cursorvm.com | 托管计算机及其控制平面 |
*.*.cursorvm.com | 同上，但深一级。必需。 |
cursor.com、downloads.cursor.com | 安装和更新桌面应用 |
两个 cursorvm.com 模式都要添加。计算机主机名在 cursorvm.com
之下有两级标签，形式为 <computer>.<cluster>.cursorvm.com，而单级通配符只能匹配一级。只配置
*.cursorvm.com 的网关看起来没问题，但计算机仍然无法访问。这正是在已放行 cursor.sh
的网络中计算机设置失败的常见原因。
将这些域名同样排除在 TLS 检查和缓冲之外
仅放行流量还不够。对上述每个域名：
- 跳过 TLS (SSL) 检查。 当网关用自有证书重新签发连接时，即使主机名已放行，计算机设置握手仍会失败。Cherri Code 的连接本身已是端到端加密。
- 关闭响应缓冲。 聊天和计算机连接均采用流式传输。如果网关要等响应完整后才放行，应用就会一直等待永远不会到达的输出。
如果贵方策略要求检查全部流量，网关必须满足 SSL 检查与 DLP 中的要求：支持 HTTP/2 或 Cherri Code 的 HTTP/1.1 回退、无缓冲的 Server-Sent Events 透传，以及不强制超时的长连接。
应用到每个配置文件，包括离网场景
设备离开办公室后，Zscaler Client Connector 仍会继续运行，并转而应用自己的离网配置文件。只添加到办公地点或单个策略中的例外，不会随设备一起生效到家中。请将允许规则、TLS 检查豁免以及所有 DNS 例外应用到 Cherri Bot 成员所属的每一个位置、配置文件和策略群组，包括漫游和离网场景。其他为在网和离网设置了独立策略的网关，也需要做同样的处理。
典型迹象：同一台笔记本电脑上，Cherri Bot 在办公室能正常使用，在家却用不了，而网关客户端始终在运行。
从成员设备上验证
在 IT 完成更改后，在运行着网关客户端的成员设备上执行以下操作。
检查证书由谁颁发
curl -v # |& grep -C1 issuer:颁发方应为 Amazon RSA。如果显示的是 Zscaler 或你的网关厂商，说明该设备的
配置文件仍对 cursor.sh 启用了 TLS 检查。
检查计算机主机名能否解析
nslookup test.us9.cursorvm.com应当能返回地址。如果解析失败，请尝试
nslookup test.us9.cursorvm.com 1.1.1.1。如果公共解析器能返回结果
而默认解析器不能，说明拦截来自设备的 DNS 或网关配置文件，
且其中缺少嵌套的 *.*.cursorvm.com 例外。
测试流式传输
运行 测试代理连通性 中的 HTTP/1.1 与 HTTP/2 流式测试。输出应逐行到达，而不是一次性全部返回。
在应用中重试
在同一台设备上打开 Cherri Bot 桌面应用并连接到该计算机。如果仍然失败， 请从该设备重复上述检查；若热点网络可用而企业网络失败，即可确认问题出在 网络上。
适用范围
以下三项控制容易混淆：
| 你的需求 | 使用 |
|---|---|
| 让成员设备通过你的网关访问 Cherri Code 及其 托管计算机 | 本页 |
| 限制 托管计算机 可访问的目标 | 网络策略，仅限企业版 |
| 将托管计算机的流量路由经过某台成员设备 | 通过你的桌面端路由流量 |
| 在每台托管计算机上安装网络客户端 | Team Setup，仅限企业版 |
默认情况下，托管计算机 自身的流量从 Cherri Code 的共享静态出口 IP 地址发出，不会经过成员设备上的网关。当成员启用 Route traffic through this computer 后，被路由的流量将使用该设备的网络，并受其网关策略约束。
FAQ
通常有两个原因。一是缺少嵌套的 *.*.cursorvm.com 模式，导致 computer 的
主机名 无法匹配；二是该域名虽已放行，但仍被 TLS 检查，网关证书会导致
设置阶段的 握手 失败。请添加嵌套 模式，并将两个 模式 都排除在检查之外，
然后运行检查。
两者使用的 主机名 不同。聊天、登录和批准都走 api2.cursor.sh，
大多数网关默认已放行；而 computer 连接走的是嵌套的 cursorvm.com 主机名，
需要单独的允许规则和检查豁免。这也是为什么在某些网络中 聊天 可以正常使用，
而 computer 始终无法连接。
在家时网关客户端仍在运行，而它使用的离网配置文件并未包含这些例外规则。 请将例外同样应用到漫游配置文件和离网配置文件。
那么网关必须原样放行流式传输流量。相关要求参见 SSL 检查与 DLP。 豁免 Cherri Code 的域名是最可靠的做法；Cherri Code 的 连接 本身已是端到端加密。
是的，它与企业版网络配置中的列表相同。
编辑器的 聊天 和 Tab 功能不依赖 cursorvm.com 模式 也能正常使用，
因此对编辑器没问题的网关，仍可能导致 Cherri Bot 无法使用。
相关页面
需要网关配置方面的帮助？
联系我们的团队，获取部署协助与优先支持。