8.2 KiB
8.2 KiB
CursorPro 3.0 - MITM 代理方案计划
状态: 规划中 (暂不启动) 优先级: 低 前置条件: 2.0 稳定运行后再考虑
一、目标
实现真正的无感换号 - 请求级别自动切换账号，用户无需重启Cursor
二、当前方案 (2.0) vs 目标方案 (3.0)
| 特性 | 2.0 (当前) | 3.0 (MITM) |
|---|---|---|
| 换号方式 | 写Token到本地 | 请求转发 |
| 需要重启 | 是 | 否 |
| 切换粒度 | 会话级别 | 请求级别 |
| 技术难度 | 低 | 高 |
| 用户感知 | 有感 | 无感 |
| 检测风险 | 低 | 中高 |
三、技术方案
方案A: 本地代理 + Hosts劫持
┌─────────────────────────────────────────────────────────────────┐
│ │
│ [Cursor] ──→ api2.cursor.sh (被hosts指向127.0.0.1) │
│ │ │
│ ▼ │
│ [本地代理服务] (127.0.0.1:443) │
│ │ │
│ ├─── 检查当前账号额度 │
│ ├─── 选择最优账号 │
│ ├─── 替换请求中的Token │
│ │ │
│ ▼ │
│ [真实 api2.cursor.sh] │
│ │ │
│ ▼ │
│ 返回结果给 Cursor │
│ │
└─────────────────────────────────────────────────────────────────┘
实现步骤:
1. 开发本地代理服务 (Node.js/Go)
2. 生成自签名CA证书
3. 修改系统hosts文件
4. 用户安装CA证书到系统信任
优点:
- 完全透明，Cursor无需修改
- 请求级别换号
缺点:
- 需要用户安装CA证书 (用户可能不信任)
- 需要管理员权限修改hosts
- HTTPS证书处理复杂
方案B: Cursor配置修改
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 修改 Cursor 的 API 端点配置 │
│ │
│ 可能的配置位置: │
│ 1. Cursor 安装目录下的配置文件 │
│ 2. Electron app.asar 中的硬编码 │
│ 3. 环境变量 │
│ │
│ 修改后: │
│ 原: https://api2.cursor.sh │
│ 改: https://proxy.ourserver.com │
│ │
└─────────────────────────────────────────────────────────────────┘
需要研究:
1. Cursor 是否有配置文件指定 API 地址
2. 是否可以通过环境变量覆盖
3. 修改 app.asar 的可行性
优点:
- 不需要CA证书
- 不需要修改hosts
缺点:
- Cursor 更新后可能失效
- 需要深入研究 Cursor 内部实现
方案C: 云端代理集群
┌─────────────────────────────────────────────────────────────────┐
│ │
│ [用户Cursor] ──→ [我们的云端代理] ──→ [Cursor官方API] │
│ │ │
│ ├── 负载均衡 │
│ ├── 动态IP池 │
│ ├── 账号池管理 │
│ └── 请求级换号 │
│ │
└─────────────────────────────────────────────────────────────────┘
需要:
1. 多台服务器做代理集群
2. 动态住宅IP代理服务
3. 高并发处理能力
优点:
- 集中管理，用户端改动最小
- 可以做更多优化
缺点:
- 服务器成本高
- 延迟增加
- 需要用户配置代理或修改Cursor
四、Cursor API 端点分析 (待研究)
需要劫持的主要端点:
# 认证相关
POST https://api2.cursor.sh/auth/...
# AI 对话
POST https://api2.cursor.sh/aiserver.v1.AiService/StreamChat
POST https://api2.cursor.sh/aiserver.v1.AiService/...
# 使用量查询
GET https://api2.cursor.sh/usage/...
# 其他
...
研究任务:
- 抓包分析 Cursor 的所有 API 请求
- 确定需要劫持的端点列表
- 分析请求/响应格式
- 确定 Token 在请求中的位置
五、风控规避
Cursor 可能的检测手段
| 检测方式 | 规避方法 |
|---|---|
| IP异常 | 使用住宅代理IP池 |
| 设备指纹 | 同步machineId |
| 请求频率 | 限流 + 分散 |
| Token异常 | 模拟正常使用模式 |
| TLS指纹 | 使用标准TLS库 |
建议策略
- 账号隔离: 一个账号同时只服务一个用户
- 请求限流: 单账号请求频率限制
- IP绑定: 账号绑定固定IP段
- 行为模拟: 模拟正常用户使用模式
六、实施阶段
Phase 1: 研究 (预计2周)
- 抓包分析 Cursor API
- 研究 Cursor 配置文件
- 评估各方案可行性
- 选定最终方案
Phase 2: 原型开发 (预计3周)
- 开发代理服务核心
- Token 替换逻辑
- 账号池调度算法
- 本地测试
Phase 3: 集成测试 (预计2周)
- 与现有后端集成
- 多账号切换测试
- 性能测试
- 稳定性测试
Phase 4: 灰度发布 (预计2周)
- 小范围用户测试
- 收集反馈
- 修复问题
- 正式发布
七、成本预估
| 项目 | 预估成本 |
|---|---|
| 开发人力 | 2人月 |
| 服务器 (代理集群) | $200-500/月 |
| 动态IP代理 | $100-300/月 |
| 域名+SSL | $50/年 |
八、风险评估
| 风险 | 等级 | 应对措施 |
|---|---|---|
| Cursor更新导致失效 | 高 | 预留回滚方案 |
| 被Cursor封禁 | 中 | IP池 + 行为模拟 |
| 用户不愿装证书 | 中 | 提供详细教程 |
| 技术难度超预期 | 中 | 阶段性评估 |
九、决策点
在启动3.0之前需要回答:
-
是否真的需要?
- 2.0 的"重启换号"用户接受度如何？
- 用户对"无感"的需求有多强烈？
-
投入产出比?
- 开发成本 vs 带来的价值
- 维护成本 vs 收益
-
风险是否可控?
- Cursor 的封禁风险
- 法律合规风险
十、参考资料
待收集:
- Cursor 官方 API 文档 (如有)
- 类似项目实现参考
- MITM 代理开发资料
- 动态IP代理服务商对比
本文档仅作为技术方案规划，启动前需要团队评审确认。