Recently encountered a rather strange issue: When calling the model inside the Cursor, it occasionally prompts:

This model provider is not supported in your region

But I have Surge's enhanced mode enabled, and it has been working fine so far. It doesn't always report errors; instead, it often retries a dozen times before succeeding. The next time I ask, it might happen again. The normal ratio is roughly 1:10 for failures. Coincidentally, our company's network equipment has been malfunctioning lately, and we often can't get online. I initially thought it was due to network fluctuations, but when they said it was fixed today, the problem persisted, and I realized it's something else.

First, check the Surge panel. I've actually visited it several times. Clicking on Cursor, or searching for "cursor" by hostname, revealed no issues with the proxy rules—everything was being routed correctly, and the connections were present. I had set up both process name routing and domain routing, so it should have been foolproof. It was very strange. Eventually, Codex helped with packet capture analysis to identify the problem.

The problematic package looks like this:

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 节点

And also similar

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

That is to say, Surge actually knows that the SNI of this TLS connection is the Cursor domain, but the process of this request is no longer Cursor, but:

com.kaspersky.kav.sysext

So the original process name diversion rules naturally don't match.

I immediately remembered, a few days ago I saw someone get infected with malware on a Mac on Bilibili, and I felt quite anxious. Fortunately, I had been stockpiling Kaspersky activation codes for over a decade, so I decided to install Kaspersky on my Mac as well. At the time, the network traffic protection feature was automatically enabled. This was the culprit.

Continue, this type of request is displayed as:

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

It's not the kind of request with a host directly included in a regular HTTP proxy, but rather a direct IP address, which is why it's not visible in the Surge panel either, as this connection hasn't been categorized under Cursor.

Moreover, not all requests are like this. Kaspersky seems to have built-in caching, so when I repeatedly click to retry, there's a chance it doesn't take over the traffic and is normally routed by Surge.

Solution: Use extended-matching to match TLS SNI in Surge. Surge supports using TLS SNI / HTTP Host for extended matching of domain rules. After enabling it, it should work. I also set up a separate split for the process name of Kaspersky. The issue is resolved.

All I can say is that codex is too good. It would have taken me about a day to capture packets and study it myself, but codex finished it in just a few minutes.