VS Code 插件 Connection error 排查实录：HTTP_PROXY 与 HTTPS_PROXY 端口不一致的隐藏陷阱
引言
同一台 Windows 机器上，终端里的 CLI 工具访问 api.anthropic.com 一切正常，但 VS Code 里跑同一个后端的插件却持续报 API error (attempt 9/11): undefined Connection error，并在日志里刷 Failed to establish a socket connection to proxies: PROXY 127.0.0.1:7890。
这类"命令行能用、IDE 插件不能用"的问题很容易被误判为插件本身损坏、登录态失效或版本兼容问题，进而走上重装插件、清缓存、重新登录的弯路。本文记录一次真实排查过程：最终根因是 Windows 用户环境变量里 HTTP_PROXY 和 HTTPS_PROXY 指向了两个不同端口，其中一个早已停止监听。
一、问题描述
现象很典型：
- VS Code 扩展日志（%APPDATA%\\Code\\logs\\<时间戳>\\window1\\exthost\\<插件ID>\\*.log）里持续出现：
[ERROR] API error (attempt 9/11): undefined Connection error.
[error] Error fetching remote sessions: Error: Failed to establish a socket connection to proxies: PROXY 127.0.0.1:7890
- 重试次数从 1/11 一路打到 9/11、10/11，每次间隔越来越长（典型的指数退避），最终请求全部失败。
- 同一台机器、同一时间，终端里手动执行对应的 CLI 工具却完全正常，能正常收发请求。
这种"CLI 正常、插件异常"的组合是本次排查的关键线索——它排除了网络整体不通、DNS 解析失败、证书问题等会同时影响两者的因素，把范围收窄到了插件进程与终端进程环境差异上。
二、根因分析
直接原因
检查 Windows 用户级环境变量（HKCU\\Environment）发现：
HTTPS_PROXY = http://127.0.0.1:7890
HTTP_PROXY = http://127.0.0.1:10808
两个变量指向了不同端口。逐一验证端口可用性：
netstat -ano | grep "7890"
# TCP 127.0.0.1:xxxxx 127.0.0.1:7890 SYN_SENT <pid>
# 只有一条挂起的 SYN_SENT，没有任何 LISTENING
netstat -ano | grep "10808"
# TCP 127.0.0.1:xxxxx 127.0.0.1:10808 ESTABLISHED <pid>
# 多条 ESTABLISHED，进程正常在跑
再用 curl 分别通过两个端口代理访问目标 API 做交叉验证：
curl -x http://127.0.0.1:7890 -s -o /dev/null -w "code=%{http_code}\\n" \\
–max-time 8 https://api.anthropic.com/v1/messages
# code=000 —— 连接失败
curl -x http://127.0.0.1:10808 -s -o /dev/null -w "code=%{http_code}\\n" \\
–max-time 10 https://api.anthropic.com/v1/messages
# code=405 —— 链路是通的（GET 请求打 /v1/messages 本就该返回 405 Method Not Allowed）
结论明确：7890 端口上的代理进程已经不存在（可能是代理软件换了监听端口、或者旧代理软件已卸载但环境变量残留），而 10808 才是当前真正在跑的代理。
为什么 CLI 正常、插件异常
api.anthropic.com 走的是 HTTPS，命中的正是坏掉的 HTTPS_PROXY=7890，这解释了为什么故障只出现在走 HTTPS 请求的路径上。
真正的谜团在于：为什么同一个环境变量，CLI 读到的是对的，插件读到的是错的？
答案在于进程启动时机与环境变量的生效方式：
- Windows 的 setx / 系统属性面板修改的是注册表里的持久化环境变量，但已经在运行的进程不会感知到变更，只有新启动的进程才会重新读取一份。
- 当前使用的终端会话是较早打开的，此前某次操作曾在该会话内临时 export/覆盖过 HTTPS_PROXY 为 10808（会话级变量优先级高于继承自父进程的注册表值），所以这个终端里看到的值是对的。
- 而 VS Code 是从开始菜单新启动的窗口，直接继承了注册表里那份没更新过的 HTTPS_PROXY=7890，并把它传给了扩展宿主进程和插件后台拉起的子进程，于是所有 HTTPS 请求全部失败。
也就是说，这不是插件的 bug，而是同一台机器上，不同进程各自持有了一份不一致的环境变量快照。这种问题的隐蔽性在于：直接检查系统代理设置面板可能是对的（比如 Windows 的 IE 代理设置里 ProxyEnable=0，看起来"没启用代理"），但环境变量层面的 HTTP_PROXY/HTTPS_PROXY 才是 Node.js、curl 等大量工具实际读取的配置来源，两者是完全独立的两套机制，互不同步。
三、排查思路
按实际操作顺序复盘：
四、错误的"临时止血"方式（不推荐）
排查过程中容易想到但不建议的做法：
- 在插件设置里关闭代理检测 / 强制走直连：如果原本走代理是为了访问某些需要代理才能连通的服务，直连大概率会导致新的连接失败，只是把"代理端口错误"换成了"完全没有代理"，治标不治本。
- 只重装/重新登录插件：由于问题根源在系统环境变量，重装插件不会改变继承到的 HTTPS_PROXY 值，故障会原样复现，容易误导后续排查方向,浪费时间还可能丢失本地会话历史。
- 只改一个变量、不检查另一个是否一致：例如只把 HTTPS_PROXY 改成能用的端口，却没检查 HTTP_PROXY 是否指向同一个代理软件，一旦代理软件对 HTTP/HTTPS 走了不同端口(有些代理工具确实会这样设计)，未来还是会在 HTTP 请求路径上复现同样问题。
五、标准修复方案
方案一：统一环境变量到当前可用端口（根治）
确认好哪个端口对应的代理进程真的在跑之后，用 setx 统一两个变量（Windows 下 setx 写入用户级注册表，对新启动的进程生效）：
setx HTTPS_PROXY "http://127.0.0.1:10808"
setx HTTP_PROXY "http://127.0.0.1:10808"
setx NO_PROXY "localhost,127.0.0.1,::1"
顺手把 NO_PROXY 也配置上，避免本地开发时访问 localhost 服务(比如本地起的 Docker 容器、本地 API 服务)被无意义地转发给代理,既拖慢速度也增加了新的故障点。
关键前提：改完必须完全退出并重启相关进程(包括 VS Code 及其扩展宿主进程),因为环境变量只在进程启动时读取一次。可以用下面的命令确认旧进程是否真的退干净：
tasklist | grep -i "Code.exe"
# 如果还有残留：
taskkill /IM Code.exe /F
最稳妥的方式是从开始菜单重新启动，而不是复用已经打开的终端/资源管理器窗口去拉起新窗口——后者的父进程可能仍持有旧的环境变量。
方案二：在应用配置里显式指定代理（防御性加固）
很多支持代理的桌面应用(包括 VS Code)在代理解析上有自己的优先级链：应用内显式配置 > 环境变量 > 系统代理。与其完全依赖环境变量这种容易被不同进程读到不同值的机制，不如在应用配置文件里显式写死：
{
"http.proxy": "http://127.0.0.1:10808"
}
这样即便未来系统环境变量又被其他工具改乱，这个应用的网络行为也不会受影响，相当于给最关键的开发工具单独上了一道保险。
六、方案对比
| 统一环境变量 | 系统内所有读取环境变量的进程 | 一次修复，全局生效，符合环境变量本身的设计意图 | 需要重启进程才能生效，且未来仍可能被其他工具重新改乱 |
| 应用内显式配置代理 | 仅当前应用 | 不受系统环境变量变化影响，配置可追溯（写在版本可控的配置文件里） | 需要逐个应用单独配置，无法一次性解决所有工具的同类问题 |
两者不是互斥关系，实践中建议同时采用：环境变量保证大多数命令行工具的默认行为正确，关键开发工具（如 IDE）再单独加一层显式配置作为保险。
七、经验总结
结语
代理配置错配是一类典型的"环境问题伪装成软件 bug"的故障——报错信息本身（Connection error）看似指向应用层，但真正的根因藏在进程启动时继承的环境变量里。遇到"同一功能在不同宿主（CLI vs IDE 插件、本地 vs CI）表现不一致"的问题时，与其先怀疑软件逻辑，不如先对比两边的运行环境差异，往往能更快找到真正的根因。
