[T]Cursor IDE 与 v2rayN（V7.19.5）日常网络指南

代理模式、路由选型与排障：TUN / 系统代理 / PAC / 绕过大陆 的组合语义、常见日志解读与 Git 终端实践

摘要

本文面向在 Windows 下日常使用 Cursor IDE（基于 VS Code）并配合 v2rayN V7.19.x（sing-box / 多路由方案） 的用户，梳理 TUN、系统代理（清除/自动/PAC/不改变）、路由方案（绕过大陆 Whitelist、黑名单、全局、自定义「私网直连」） 各自的职责与常见误用，解释 Git 终端、SSH、HTTPS 与上述机制的关系，并给出 典型故障日志（如私网地址 direct 却 i/o timeout、ssh -T git@github.com 被断开）的原因与可选对策。文末提供 选型决策要点 与 可复用的排障清单。文中不依赖特定节点与密钥，便于长期维护。

1. 为什么「Cursor + 代理」值得单独成篇

Cursor 内置终端、扩展宿主、Git、语言服务器等进程的网络行为并不一致：

• 有的流量走 WinHTTP / 系统代理 / PAC；
• 有的在未配置时 直连；
• TUN 则在更底层改变系统路由，使「本来直连」的流量也进入 sing-box / xray 路由链。

因此，同一台机器、同一套 v2rayN 节点，在 「只开 PAC」 与 「开 TUN」 下，Cursor 里 git push 成败可能完全不同。这不是 Cursor 缺陷，而是 OS 网络栈 + 应用代理感知 + 路由规则 共同作用的结果。

2. v2rayN 的三层控制：先建立心智模型

可将 v2rayN 理解为三层（自顶向下）：

层次	典型选项	作用对象
A. 系统代理 / PAC	清除系统代理、自动配置系统代理、不改变系统代理、PAC 模式	主要影响 尊重系统代理 的应用（如多数浏览器、Git HTTPS 等）
B. TUN	启用 / 关闭	系统级虚拟网卡与路由，影响面最广；不依赖应用是否「认代理」
C. 路由方案	V4-绕过大陆（Whitelist）、黑名单、全局、自定义（如「私网直连」规则集）	决定匹配到的流量走 proxy / direct / block 等 outbound

关键原则：三层会叠加或互相替代——例如 TUN 已接管大量流量时，再叠 PAC + 自动系统代理，容易出现「部分流量绕两次」或「规则难排查」的现象。

3. 系统代理四种模式：各自解决什么问题

3.1 清除系统代理

• 含义：把 Windows「HTTP 代理」等系统级代理设置清掉。
• 常见用途：启用 TUN 时，减少与 系统代理 的双重干预，让分流主要由 TUN + 路由完成。
• 副作用：依赖系统代理但未走 TUN 的应用，可能暂时「感觉没代理」。

3.2 自动配置系统代理

• 含义：由 v2rayN 把系统代理指向本机入站（HTTP/SOCKS 等，以实际版本为准）。
• 常见用途：不开 TUN 时，让浏览器、部分 WinHTTP 应用走代理。
• 与 TUN：同时开启时需谨慎——易出现重复路径或难预期的出口。

3.3 不改变系统代理

• 含义：不动系统里已有代理配置。
• 常见用途：你手动维护代理，或仅把 v2rayN 当「本地 SOCKS 入口」由其它软件指向。

3.4 PAC 模式

• 含义：通过 PAC 脚本决定哪些目标走代理、哪些直连。
• 常见用途：不开 TUN 时，对 浏览器 + 认 PAC/系统代理的 Git（常为 HTTPS） 较友好。
• 局限：原生 SSH（22） 往往不走 PAC；若 Git 远端是 git@github.com:...，PAC 未必能修复 SSH 路径（除非另有 ProxyCommand 等配置）。

4. 路由方案：Whitelist / 黑名单 / 全局 / 自定义

4.1 V4-绕过大陆（Whitelist）

• 大意：与「中国大陆」强相关的目标多走 直连；境外站点走 代理。
• 日常写作 + GitHub：通常作为 默认主方案。

4.2 V4-黑名单（Blacklist）

• 大意：名单内走代理，其余直连。
• 适用：与 Whitelist 相反的策略空间；若未维护好名单，易出现「该代理的没代理」。

4.3 V4-全局

• 大意：倾向 大量流量走代理。
• 代价：更慢、更费节点、更易误伤国内站点；不建议作为日常默认。

4.4 自定义方案（例如「私网直连」）

在 v2rayN GUI「路由规则详细设置」 中，常见字段包括 outboundTag、IP 或 IP CIDR、规则类型 等。

• 若方案里只有「私网 CIDR → direct」而缺少「境外 → proxy、大陆 → direct」等主干规则： 单独选用该方案可能不完整，GitHub 等仍可能异常。
• 推荐做法：在 Whitelist 主方案中，把 私网直连规则置顶（排序数字最小 / 规则列表最前），或按 v2rayN 文档将自定义规则合并进当前启用的方案。

私网 CIDR 示例（单条规则内多行）：

127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
100.64.0.0/10

对应 GUI：outboundTag = direct，IP 或 IP CIDR 填入上表；Domain / 进程 可留空；port / protocol / inboundTag 多数场景可留空表示「不额外限制」。

说明：172.17.0.0/16（Docker 默认桥） 已包含在 172.16.0.0/12 中，一般无需再写一行。

5. 典型组合与选型建议

5.1 组合 A：TUN 开 + 清除系统代理 + V4-绕过大陆（理论上的「全能型」）

项	设置
TUN	开
系统代理	清除系统代理
路由	V4-绕过大陆，且 私网 → direct 规则置顶

优点：终端、不认代理的应用也可被路由。 风险：TUN 下若 私网 / Docker / 局域网 未正确 direct 或 TUN 排除前缀 未配好，日志中易出现 outbound/direct 访问 172.17.x.x、192.168.x.x 却 i/o timeout——本质是 被核心劫持后直连路径不通 或 误匹配。

5.2 组合 B：TUN 关 + PAC + V4-绕过大陆（实践中最省心的一类）

项	设置
TUN	关
系统代理	PAC 模式（或与你的版本等价的「由 PAC 驱动系统代理」项）
路由	V4-绕过大陆

优点：Cursor Bash 里 git push 到 GitHub 在不少环境下可 稳定成功（尤其当远端为 HTTPS 时，与系统代理链路契合）。 代价：不认代理的进程 仍可能无法出境；若必须用 SSH:22，需单独评估（见 §7）。

5.3 不建议的长期组合（除非你很清楚在做什么）

• TUN + PAC + 自动配置系统代理 全开：层叠多、排障难。
• 路由选「全局」作日常：成本高、副作用大。

6. 常见问题与日志解读

6.1 git push / ssh -T git@github.com：Connection closed by ... port 22

• 含义：SSH（22） 在握手或传输阶段被关闭。
• 与 v2rayN：可能是 路径未稳定走代理、中间网络重置、或 TUN 路由与 DNS 异常 的叠加。
• 对策方向：
  • 关 TUN，改 PAC + Whitelist 验证（许多用户由此恢复）；
  • 或将远端改为 HTTPS + 明确 http.proxy/https.proxy（见 Git 文档）；
  • 或 SSH over SOCKS（~/.ssh/config + ProxyCommand），显式走本地 SOCKS 入站。

6.2 日志：dial tcp 172.17.0.2:... / 192.168.x.x:... outbound/direct i/o timeout

• 含义：核心尝试以 直连 访问 Docker 网桥 / 局域网，但 五秒内建连失败。
• 常见原因：TUN 劫持了本应 由操作系统正常直连 的私网会话，或 路由顺序 导致误走 direct。
• 对策：§4.4 的 私网 CIDR → direct 置顶；若客户端支持 TUN 排除地址，可将 RFC1918 等前缀加入排除列表（以 sing-box / v2rayN 文档字段名为准）。

6.3 日志：accepted tcp:... [proxy-relay-ss -> proxy]

• 含义：该会话 已走代理链，本身不一定是错误。
• 排障：需与 同时间段 的 ERROR 行对照，区分「代理成功」与「直连失败」。

6.4 Cursor 提示 “No text editor active”

• 含义：部分扩展命令需要 编辑器获得焦点；与代理未必同源。
• 处理：点击 .qmd / .R 编辑区后再执行命令。

7. Git：HTTPS 与 SSH 与代理的关系（简表）

远端 URL 形式	典型端口	与 PAC / 系统代理	与 TUN
https://github.com/...	443	较易 走系统代理 / PAC	由路由决定
git@github.com:org/repo.git（SSH）	22	常不走 PAC	由 TUN 路由或需 ProxyCommand

实践建议：若以 「关 TUN + PAC + Whitelist」 已能稳定推送，可 git remote -v 确认当前是 HTTPS 还是 SSH；日后排障时先明确这一点，可少走弯路。

8. 排障清单（可打印）

1. 目标：仅浏览器？还是 含 Cursor 终端 / Git？后者在 不开 TUN 时更依赖 HTTPS / 系统代理。
2. 当前组合：TUN 开/关、系统代理四项之一、路由方案名称。
3. 看 v2rayN 日志：同一时刻 ERROR 是 direct 超时 还是 proxy 失败？
4. 私网/Docker：是否已 置顶 direct + 正确 CIDR？
5. Git：git remote -v → HTTPS vs SSH；必要时 GIT_CURL_VERBOSE=1 辅助看 HTTPS 代理链（按需）。
6. 每次大改后：重启 v2rayN 或 开关 TUN 一次，避免旧 sing-box 配置残留。

9. 安全与仓库卫生（与代理并列的重要习惯）

Warning密钥与令牌

项目根目录 .Renviron、.Rprofile 中若写入 API 密钥、GitHub PAT、云厂商令牌，存在 误提交、备份泄露、截图外泄 风险。代理排障与截图分享前，应 脱敏；已泄露的密钥应 轮换。

10. 结论与维护说明

• v2rayN 不是「开一个开关就万能」：需同时理解 系统代理/PAC、TUN、路由方案 三层。
• TUN 适合「全覆盖」，但务必处理好 私网直连 / 排除，否则 Docker 与局域网日志会充斥 direct 超时。
• PAC + Whitelist + 关 TUN 对 Cursor 终端 Git（尤其 HTTPS） 往往 足够稳，可作为日常默认，待确有需求再精调 TUN。

版本与界面：本文以 v2rayN 7.19.x 量级描述；小版本菜单译名可能变化，以你安装版本界面与官方发行说明为准。若官方后续调整 TUN 实现（sing-box 合并方式等），请在升级后 复查路由顺序与日志。

与本书其它技术文的关系：本文聚焦 IDE 与代理；关于 R Language Server / renv / callr 超时 的排障，见同目录下的 cursor-r-renv-languageserver-troubleshooting.qmd。

附录：参考链接（便于日后查阅）

• v2rayN（2dust）：https://github.com/2dust/v2rayN
• sing-box 文档：https://sing-box.sagernet.org/
• Git 代理说明（官方手册）：https://git-scm.com/docs/git-config（检索 http.proxy）

链接所涉内容以各项目当前版本为准；若链接变更，请从仓库主页导航至文档区。