最近遇到一個比較奇怪的问题：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 几分钟就搞定了。