最近遇到一个比较奇怪的问题：Cursor 里调用模型时，偶尔会提示：

This model provider is not supported in your region

但是我是开了 Surge 的增强模式的，而且之前一直正常。它不是一直报错，而是经常重试十来次又能成功。下一次提问时又可能再次出现。正常:故障大概是 1:10 的样子。刚好最近公司网络设备异常，经常上不去网，我还以为是网络波动的原因，但是今天说修好了，问题依旧，才发现是另一个问题。

首先去看 Surge 面板，其实看过好几次了，点到 Cursor ，或者主机名搜 cursor ，发现代理规则没有一点问题，该分流的也分流了，连接也有。我不仅设置了进程名分流，还设置了域名分流，应该是万无一失的，非常奇怪。于是让 Codex 协助抓包分析才发现问题。

出问题的包长这个样子：

processPath = /Library/SystemExtensions/.../com.kaspersky.kav.sysext
sourceAddress = 198.18.0.1
destination = 174.xxx.xxx.xxx:443
notes = Handled by VIF
notes = TLS Client Hello SNI: api2.cursor.sh
rule = FINAL
originalPolicyName = HK-Smart
policyName = HK 节点

还有类似

TLS Client Hello SNI: repo42.cursor.sh
TLS Client Hello SNI: agentn.global.api5.cursor.sh

也就是说，Surge 其实知道这个 TLS 连接的 SNI 是 Cursor 域名，但这条请求的进程已经不是 Cursor ，而是：

com.kaspersky.kav.sysext

所以原来的进程名分流规则自然匹配不上。

我立马想起来了，前几天在 V 站看见有人用 Mac 中毒了，心里也慌慌的，刚好手里屯了十几年的卡巴斯基激活码，干脆给 Mac 也装了一个卡巴斯基，当时自动打开了网络流量防护功能。罪魁祸首就是这个了。

继续说，这类请求在 Surge 里显示为：

IP:443 (SNI: api2.cursor.sh)

它不是普通 HTTP 代理里那种直接带 host 的请求，而是直接一个 IP ，所以难怪 Surge 面板里面也看不出来，因为这个连接就没有被归类到 Cursor 里面。

而且不是所有的请求都是这样，卡巴斯基似乎有内置的缓存，所以我反复点击重试的时候有概率不接管流量，正常被 Surge 分流。

解决办法：在 Surge 里用 extended-matching 匹配 TLS SNI 。Surge 支持让域名规则使用 TLS SNI / HTTP Host 做扩展匹配。打开之后就好了。我也给卡巴的进程名配置了一个单独的分流。问题解决。

只能说 codex 太好用了，我自己抓包研究估计得一天都不一定能成，codex 几分钟就搞定了。