は最近少し奇妙な問題に直面しました：Cursor内でモデルを呼び出すと、たまに

This model provider is not supported in your region

と表示されます。しかし、私はSurgeの強化モードを有効にしており、以前は問題なく動いていました。問題は常に発生するわけではなく、10回ほど試行してもう一度成功することが多いです。次回は再び発生する可能性があります。正常な場合：問題の発生率はおおよそ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 にマルウェアが感染した人が見かけたのを見たので、心もくじけた。ちょうど10年以上のカバ斯基アクティベーションコードを手に入れていたので、Macにもカバ斯基をインストールした。その時、自動的にネットワークトラフィック保護機能が開いていた。原因はこれだ。

さらに言えば、この種のリクエストは Surge で以下のように表示される：

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

これは普通の HTTP プロキシで直接ホストを含むリクエストではなく、直接 IP なので、Surge のパネルでも見えなかった。なぜなら、この接続は Cursor に分類されなかったからだ。

それに、すべてのリクエストがそうとは限らない。カバ斯基には組み込みのキャッシュがあるようで、繰り返しリトライをクリックしたときに、たまにトラフィックを取りこむことがなく、通常通り Surge で分流される。

解決法：Surge で extended-matching で TLS SNI をマッチングします。Surge はドメインルールに TLS SNI / HTTP Host を拡張マッチングさせることをサポートしています。これを有効にすると解決します。私はカバのプロセス名にも個別のスプリットを設定しました。問題が解決しました。

codex が本当に便利すぎます。自分でパケットキャプチャして調べても、1日かかってもできなかったことが、codex で数分で解決しました。