VS Code + WSL 环境下 GitHub 访问及 Copilot 连接问题解决方案
最近排查了一个典型的开发环境问题:在 VS Code 配合 WSL 时,GitHub 克隆失败,Copilot 和 Codex 长时间卡在 "Thinking..."。这里记录一下完整的排查思路和解决步骤。
一、问题现象
在使用 VS Code + WSL 进行开发时,可能会遇到以下两个核心痛点:
- Git clone 失败
fatal: unable to access 'https://github.com/...': Failed to connect to 172.xx.xx.xx port xxxx - Copilot / Codex 一直 "Thinking…"
- 无法生成代码补全
- 界面长时间转圈
- VS Code 日志提示连接境外服务失败
二、核心原因:理解 WSL 网络结构
要解决这个问题,必须先搞清楚 WSL 的网络层级。WSL 的网络其实分三层:
| 层级 | 归属 | 特点 |
|---|---|---|
| Windows 主机 | VS Code 本体、代理软件运行处 | 使用主机物理网络出口 |
| WSL Linux | Git、curl、Copilot 后台进程 | 127.0.0.1 指的是 WSL 内部 |
| Remote WSL 扩展 | VS Code 与 WSL 的桥梁 | 依赖两端配置同步 |
关键点在于: WSL 中的 127.0.0.1 并不是 Windows 主机,而是 Linux 自身。
当需要访问 GitHub 或 Copilot 等境外服务时,WSL 必须正确转发到主机的网络出口。你可以通过以下命令查询当前 WSL 的主机出口地址:
cat /etc/resolv.conf | grep nameserver
示例输出:
nameserver 172.25.176.1
注意这个地址每次重启电脑可能会变,所以硬编码 IP 的方案很容易失效。
三、Git Clone 不稳定的修复方案
1. 清理错误的代理配置
有时候之前的配置残留会导致冲突,建议先彻底清理:
git config --unset http.proxy
git config --unset https.proxy
git config --global --unset http.proxy
git config --global --unset https.proxy
unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy ALL_PROXY all_proxy
2. 测试直连能力
执行以下命令检查 WSL 是否能直接访问 GitHub:
curl -I https://github.com
如果返回 ,说明直连正常。

