记一次 Cursor 卡死问题的排查过程
最近用 Cursor 写代码，体验极差——问个问题，中间能卡死好几次，严重影响效率。一度怀疑是 Cursor 本身的问题，但问了周围的人，大家都用得好好的，就我这里有问题。
今天终于把原因找到了，记录一下排查过程，说不定能帮到遇到同样问题的人。
表象：关了代理还是在卡
因为访问 GPT 等模型需要代理，所以第一反应是把系统代理关掉试试。关掉之后，卡死问题依然存在。这让我一度陷入怀疑是 Cursor 太垃圾
真正的原因：环境变量里的"幽灵代理"
偶然看了下 clash Party 的流量监控，发现即使我关了系统代理，api请求还是走代理，大概一想就明白了。
我在 iTerm 里通过命令行打开 Cursor，而我的 bash 配置文件里，设置了类似这样的环境变量：
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
这意味着，即使在系统设置里关掉了 Clash Party 的系统代理，从 iTerm 启动的 Cursor 进程依然会通过这个端口走代理流量。系统代理关了，但端口还在监听，流量还是照走不误。
而问题的根源，是 Clash Party 这个代理。
解决方案
换用 Clash Verge 之后，问题立刻消失了。至于 Clash Party 底层为什么会有这个问题，目前还没深究。
当我解决这个问题后，cursor再也没卡死，那就一个爽。
