VS Code + WSL 下 GitHub 访问不稳定 & Copilot/Codex 一直 Thinking 的完整解决方案(国内平台安全版)

VS Code + WSL 下 GitHub 访问不稳定 & Copilot/Codex 一直 Thinking 的完整解决方案(国内平台安全版)

本文记录一次开发环境排查过程:
从 VS Code + WSL 环境下 GitHub 克隆失败,到 Copilot/Codex 长时间停在 “Thinking…” 的完整解决步骤。

特别说明:

文中提到的 “网络辅助工具”“连接加速端口”“外网连通性优化” 都指代常见的 网络优化方式,用于解决访问境外开发资源时的稳定性问题(GitHub、Copilot 等)。

📌 一、问题概述

使用 VS Code + WSL 进行开发时可能遇到以下问题:

❌ 1. Git clone 失败

fatal: unable to access 'https://github.com/...': Failed to connect to 172.xx.xx.xx port xxxx 

❌ 2. VS Code Copilot / Codex 一直 “Thinking…”

  • 无法生成补全
  • 长时间转圈
  • VS Code 日志提示连接境外服务失败

🔍 二、核心原因(理解网络结构非常重要)

WSL 的网络结构分为 3 层:

层级属于哪里特点
Windows 主机VS Code 本体运行、网络辅助软件运行使用主机网络
WSL LinuxGit、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 

这个地址每次重启电脑可能变化,因此很多网络相关设置会失效。


⚙️ 三、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 

返回 HTTP/2 200 说明已能正常访问。

3️⃣ 如果你使用了“网络辅助工具”

则需要在 WSL 中写入对应的 主机出口地址

exportHTTP_PROXY="http://172.25.176.1:xxxx"exportHTTPS_PROXY="http://172.25.176.1:xxxx"git config --global http.proxy http://172.25.176.1:xxxx git config --global https.proxy http://172.25.176.1:xxxx 

注意:
此处的 xxxx 代表你的“连接中转端口”(常见为 7890/10809 等)。


💡 四、VS Code Copilot/Codex 一直 Thinking 的解决步骤

1️⃣ 修改 VS Code 配置(安全版)

Ctrl + Shift + P → Preferences: Open Settings (JSON) 

写入:

{"http.proxySupport":"on","http.systemProxy":false,"http.proxyStrictSSL":false,"terminal.integrated.env.linux":{"NO_PROXY":"localhost,127.0.0.1,::1,.local"}}
⚠️ 不要在这里写死 "http.proxy",因为主机出口 IP 是会变化的。

VS Code 会自动继承 WSL 环境变量。


🚀 五、永久解决:自动检测并更新 WSL 的网络出口(脚本版)

将下面的脚本保存为:

~/fix_vscode_wsl_proxy.sh 

▶️ 脚本内容(国内安全版,已完全脱敏)

#!/usr/bin/env bashset -e # ==============================# VS Code + WSL 外网连通性一键修复脚本# 可在访问境外开发资源(如 GitHub、Copilot)异常时使用# ==============================PORT="${PORT:-7890}"echo"🔍 正在读取主机出口 IP ..."HOST_IP=$(awk'/^nameserver/ {print $2; exit}' /etc/resolv.conf ||true)if[ -z "$HOST_IP"];thenecho"❌ 未找到 nameserver,请手动检查 /etc/resolv.conf"exit1fiecho"✅ 主机出口 IP: ${HOST_IP}"echo" 使用端口: ${PORT}"exportHTTP_PROXY="http://${HOST_IP}:${PORT}"exportHTTPS_PROXY="http://${HOST_IP}:${PORT}"echoecho"🧪 正在测试 Copilot 连接 ..."set +e curl -I --max-time 5 --proxy "http://${HOST_IP}:${PORT}" https://api.githubcopilot.com set -e echoecho"📝 写入 ~/.bashrc 自动配置 ..."BASHRC="${HOME}/.bashrc"MARK="WSL auto network config"if!grep -q "${MARK}""$BASHRC"2>/dev/null;thencat>>"$BASHRC"<<EOF # === ${MARK} === HOST_IP=\$(awk'/^nameserver/ {print \$2; exit}' /etc/resolv.conf) if [ -n "\$HOST_IP" ]; then export HTTP_PROXY="http://\${HOST_IP}:${PORT}" export HTTPS_PROXY="http://\${HOST_IP}:${PORT}" fi # === End of ${MARK} === EOFecho"✅ 已写入 ~/.bashrc"elseecho"ℹ️ 自动配置已存在"fiecho"🎉 完成,重启 VS Code (Remote WSL) 可立即生效。"

▶️ 使用方法

nano ~/fix_vscode_wsl_proxy.sh chmod +x ~/fix_vscode_wsl_proxy.sh ~/fix_vscode_wsl_proxy.sh source ~/.bashrc 

🧪 六、检查是否成功

  • Git 能正常 clone
  • curl 可以正常访问 GitHub
  • Copilot 能正常返回 200
  • VS Code 不再卡 “Thinking…”
  • 重启电脑后依旧不用手动配置

📦 七、总结

问题根因解决方案
Git clone 失败出口 IP 变化、未正确连接外部服务在 WSL 中更新主机出口 IP
Copilot 卡住VS Code 未继承正确的网络代理VS Code 使用 WSL 环境变量
每次重启都要重新设置主机 IP 每次变化使用自动修复脚本

Read more

记录一下使用llama.cpp过程中遇到的一些问题和解决方法

写在前面: 什么未操作即同意的条款?我写的东西免费分享也不是你能随意搬运的理由啊 特此声明,若该文章被搬运到除ZEEKLOG(www.ZEEKLOG.net)以外的其他社区如2048 AI社区,则视为该社区同意将所有收益无偿捐赠给我所有 此外,我写的所有分享都是免费的,如有VIP文章也是ZEEKLOG干的,请私信我修改成免费 起因:使用LMStudio调用AI模型时发现显存占用率一直不超过80%,询问AI解决办法无果后一怒之下换用llama.cpp,遇到了一堆AI解决不了的问题,遂记录 llama.cpp下载地址如下 https://github.com/ggml-org/llama.cpp/releases 以防万一 我老年痴呆说一下如何使用llama.cpp调用模型,把下面的代码保存成bat,放在和llama-server.exe同目录下,然后运行这个bat(确保模型位置选对,GPU_LAYERS和THREADS根据机器能力) @echo off setlocal set "MODEL_PATH=F:\Models\Yakyu&

llama.cpp加载多模态gguf模型

llama.cpp预编译包还不支持cuda12.6 llama.cpp的编译,也有各种坑 llama.cpp.python的也需要编译 llama.cpp命令行加载多模态模型 llama-mtmd-cli -m Qwen2.5-VL-3B-Instruct-q8_0.gguf --mmproj Qwen2.5-VL-3B-Instruct-mmproj-f16.gguf -p "Describe this image." --image ./car-1.jpg **模型主gguf文件要和mmporj文件从一个库里下载,否则会有兼容问题,建议从ggml的官方库里下载 Multimodal GGUFs官方库 llama.cpp.python加载多模态模型 看官方文档 要使用LlamaChatHandler类,官方已经写好了不少多模态模型的加载类,比如qwen2.5vl的写法: from llama_cpp import Llama

LFM2.5-1.2B-Thinking多场景落地:Ollama支持下的智能写作、代码辅助、学习助手实战

LFM2.5-1.2B-Thinking多场景落地:Ollama支持下的智能写作、代码辅助、学习助手实战 1. 为什么选择LFM2.5-1.2B-Thinking? 如果你正在寻找一个既强大又轻量的AI助手,LFM2.5-1.2B-Thinking绝对值得关注。这个模型虽然只有12亿参数,但性能却能与大得多的模型相媲美,真正实现了"小而美"的设计理念。 最吸引人的是它的部署便利性——通过Ollama平台,你只需要几次点击就能开始使用。不需要复杂的配置,不需要昂贵的硬件,甚至不需要深厚的技术背景。无论你是想提升写作效率、获得编程帮助,还是需要一个随时可用的学习伙伴,这个模型都能提供实实在在的价值。 我亲自测试了这个模型在不同场景下的表现,发现它在保持响应速度的同时,还能提供相当不错的输出质量。内存占用不到1GB,在普通电脑上就能流畅运行,这让我对设备端AI的未来更加期待。 2. 快速上手:Ollama部署指南 2.1 找到模型入口 使用LFM2.5-1.2B-Thinking的第一步是找到正确的入口。打开Ollama平台后,你会看到一个清晰的界面。在模型展示区域,很容易

AI大模型平台图像生成方案选型:从Stable Diffusion到DALL·E的实战对比

快速体验 在开始今天关于 AI大模型平台图像生成方案选型:从Stable Diffusion到DALL·E的实战对比 的探讨之前,我想先分享一个最近让我觉得很有意思的全栈技术挑战。 我们常说 AI 是未来,但作为开发者,如何将大模型(LLM)真正落地为一个低延迟、可交互的实时系统,而不仅仅是调个 API? 这里有一个非常硬核的动手实验:基于火山引擎豆包大模型,从零搭建一个实时语音通话应用。它不是简单的问答,而是需要你亲手打通 ASR(语音识别)→ LLM(大脑思考)→ TTS(语音合成)的完整 WebSocket 链路。对于想要掌握 AI 原生应用架构的同学来说,这是个绝佳的练手项目。 从0到1构建生产级别应用,脱离Demo,点击打开 从0打造个人豆包实时通话AI动手实验 AI大模型平台图像生成方案选型:从Stable Diffusion到DALL·E的实战对比 在AI辅助开发过程中,图像生成已成为高频需求场景。无论是内容创作、产品设计还是营销素材生产,开发者都需要快速获得高质量的生成结果。然而面对众多AI大模型平台提供的图像生成服务,