copilot在wsl中无法工作

copilot在wsl中无法工作

copilot 在 wsl 中无法工作——vscode remote develop 代理设置

通过本文,你可以了解:

  1. 如何解决 copilot 在 wsl 中无法使用的问题
  2. wsl和宿主机之间的网络通信
  3. vscode 的 remote develop 代理设置

问题表现

如果你有以下问题之一:

image-20251023112557124
  1. 对话没有输出
image-20251023112627748
  1. 显示 fetch failed
image-20251023112927595
  1. 模型名称不显示
image-20251023113136431

问题分析

查看 copilot chat 的 output 显示:

image-20251023115601077
image-20251023113051902

如果显示 proxies 相关问题,可以确定是 WSL 中运行的 vscode 调用了宿主机的 proxy 设置的问题。

image-20251023113614436

**这个选项似乎是默认开启的,会在 vscode 远程连接 wsl 开发中继承宿主机的 proxy 本地设置。**问题就出在这里,如果你使用的是宿主机本机运行的代理程序,那么proxy的ip就会设置为 127.0.0.1,但是在 wsl 中想要访问宿主机的代理端口,ip并不是 127.0.0.1(这会访问到 wsl 自己),而是需要通过如下方式查询宿主机 ip,然后访问到宿主机上的代理端口:

hostip=$(ip route show |grep -i default |awk'{ print $3}')echo$hostip

我的输出:

172.25.48.1 

因此 wsl 中要通过 172.25.48.1 ip 来访问宿主机上的端口。

WSL 2 / VS Code RemoteWindows Host (宿主机)Listens on Port XListens on Port XReturns 172.25.48.1Default Proxy: 127.0.0.1X Connection Refused (Self)✅ Correct Proxy: 172.25.48.1:Port XTraffic ForwardedWSL ApplicationLoopback: 127.0.0.1Query: ip route show | awk '{ print $3}'Proxy AppHost IP: 172.25.48.1Loopback: 127.0.0.1

问题解决

  1. 如果可以通过网络直连,直接关闭 http: Use Local Proxy Configuration.
  2. 如果依然需要设置代理,完成1后,修改如下设置:
image-20251023122228413
你可能见过这个方案:github - Copilot is not working is WSL remote connection? - Stack Overflow

这个方案确实可以成功,但是带来的副作用是 copilot 无法修改 WSL 中的文件,agent模式将称为摆设,因为你设置 copilot 完全工作在宿主机上(即设置的 "GitHub.copilot": [ "ui" ]

WSL和宿主机网络互访

上面已经说明了如何在WSL命令行中访问宿主机程序,那么我们可以将之应用到代理设置上,以下脚本解决了一个问题——在 wsl 命令行中如何利用宿主机代理软件?

#!/bin/shhostip=$(ip route show |grep -i default |awk'{ print $3}')wslip=$(hostname -I |awk'{print $1}')port=7890PROXY_HTTP="http://${hostip}:${port}"PROXY_SOCKS5="socks5://${hostip}:${port}"set_proxy(){exporthttp_proxy="${PROXY_HTTP}"exportHTTP_PROXY="${PROXY_HTTP}"exporthttps_proxy="${PROXY_HTTP}"exportHTTPS_proxy="${PROXY_HTTP}"exportALL_PROXY="${PROXY_SOCKS5}"exportall_proxy=${PROXY_SOCKS5}git config --global http.https://github.com.proxy ${PROXY_HTTP}git config --global https.https://github.com.proxy ${PROXY_HTTP}echo"Proxy has been opened."}unset_proxy(){unset http_proxy unset HTTP_PROXY unset https_proxy unset HTTPS_PROXY unset ALL_PROXY unset all_proxy git config --global --unset http.https://github.com.proxy git config --global --unset https.https://github.com.proxy echo"Proxy has been closed."}test_setting(){echo"Host IP:"${hostip}echo"WSL IP:"${wslip}echo"Try to connect to Google..."resp=$(curl -I -s --connect-timeout 5 -m 5 -w "%{http_code}" -o /dev/null www.google.com)if[${resp}=200];thenecho"Proxy setup succeeded!"elseecho"Proxy setup failed!"fi}if["$1"="set"]then set_proxy elif["$1"="unset"]then unset_proxy elif["$1"="test"]then test_setting elseecho"Unsupported arguments."fi

这个脚本自动获取宿主机的 ip,并利用宿主机上的本地代理软件来代理wsl中的网络请求,可以通过参数控制行为:

source proxy.sh set# 开启代理,设置代理变量source proxy.sh set# 用 google.com 测试代理是否成功source proxy.sh unset# 关闭代理,清楚代理变量设置

参考

WSL2与Windows间的网络互访 - 简书

WSL2 访问 Clash 网络代理 | 极客开发

Read more

智能车竞赛实战:如何用地瓜机器人打造智慧医疗解决方案(附完整代码)

智能车竞赛实战:基于地瓜机器人的智慧医疗系统开发指南 在当今技术驱动的医疗创新浪潮中,智能车竞赛为大学生创客提供了绝佳的实践平台。地瓜机器人作为一款开源硬件平台,其灵活的可扩展性和丰富的传感器生态,使其成为开发智慧医疗解决方案的理想选择。本文将深入探讨如何从零开始构建一套完整的智慧医疗系统,涵盖硬件选型、算法设计到实战优化的全流程。 1. 硬件架构设计与环境搭建 构建智慧医疗系统的第一步是搭建可靠的硬件基础。地瓜机器人平台的核心优势在于其模块化设计,允许开发者根据具体需求灵活配置传感器和执行机构。 1.1 核心硬件选型建议 对于医疗应用场景,我们需要特别关注数据的准确性和系统的稳定性。以下是经过实战验证的硬件配置方案: * 主控单元:推荐使用地瓜机器人V3.2开发板,其搭载的STM32H743芯片提供充足的算力资源 * 环境传感器: * 温湿度:SHT31高精度数字传感器(±1.5%RH精度) * 空气质量:SGP30 VOC传感器 * 医疗监测模块: * 红外测温:MLX90614非接触式传感器 * 心率血氧:MAX30102光电传感器

手把手用ROS实现Ego-Planner动态避障:无人机撞树问题终结方案

手把手用ROS实现Ego-Planner动态避障:无人机撞树问题终结方案 你是否曾满怀期待地启动无人机,看着它在仿真环境中流畅起飞,却在下一秒“砰”地一声撞上突然出现的障碍物,仿真画面定格,留下一串令人沮丧的报错信息?在复杂、非结构化的真实飞行场景中,比如在枝叶交错的林间穿行,或在有行人、车辆移动的城区执行任务,传统的全局规划器往往显得力不从心。它们规划的路径可能全局最优,但面对瞬息万变的局部环境,反应速度跟不上变化,导致“撞树”成了家常便饭。今天,我们不谈空洞的理论对比,而是聚焦于一个能真正解决这个痛点的方案——Ego-Planner,并带你一步步在ROS和Gazebo搭建的仿真世界里,亲手实现一个能“眼观六路、随机应变”的无人机大脑。 本文面向的是已经具备一定ROS和无人机仿真基础,正被动态避障问题困扰的开发者、研究者或高级爱好者。我们将彻底抛开宏观的算法优劣论述,直接深入到代码配置、参数调优和实战排错层面。你将看到的不是“Ego-Planner实时性更好”这样的结论,而是“如何设置距离场梯度计算的网格分辨率”、“碰撞反作用力系数调到多少能让无人机既灵活又稳定”的具体操作。我们

VRM4U插件完整指南:在Unreal Engine 5中高效处理VRM模型

VRM4U插件完整指南:在Unreal Engine 5中高效处理VRM模型 【免费下载链接】VRM4URuntime VRM loader for UnrealEngine4 项目地址: https://gitcode.com/gh_mirrors/vr/VRM4U 还在为Unreal Engine 5中VRM模型导入的各种技术问题而烦恼吗?今天我要为你详细介绍一款能够彻底优化VRM工作流程的专业工具——VRM4U插件!这款专为UE5设计的VRM文件导入解决方案,让你能够专注于创意实现,而不是技术细节。 项目核心价值:为什么VRM4U是你的最佳选择 VRM4U插件不仅仅是一个格式转换器,它是一套完整的3D角色处理生态系统。通过智能化的技术实现,它解决了VRM模型在UE5环境中面临的多重挑战。 核心问题解决方案: * 自动化的材质系统转换 * 完整的骨骼结构映射 * 动画数据的无缝衔接 * 跨平台性能优化 快速入门:5分钟完成插件配置 获取插件资源 首先需要下载VRM4U插件,使用以下命令获取完整代码库: git clone https://gitcode

OFA-VE在AR内容生成中的应用:实时验证虚拟物体与现实图像逻辑关系

OFA-VE在AR内容生成中的应用:实时验证虚拟物体与现实图像逻辑关系 1. 引言:当虚拟遇见现实,如何确保它们“合情合理”? 想象一下,你正在开发一款增强现实(AR)应用,用户可以通过手机摄像头,在自家的客厅里“放置”一个虚拟的沙发。听起来很酷,对吧?但问题来了:如果用户家的客厅里已经摆满了家具,这个虚拟沙发应该放在哪里才显得真实、不突兀?是悬浮在半空,还是稳稳地落在地板上?它会不会和现实中的茶几“穿模”? 这就是AR内容生成中一个核心且棘手的挑战:逻辑一致性。虚拟物体不仅要“看起来”在现实场景中,更要“在逻辑上”与现实场景融为一体。传统方法往往依赖复杂的3D场景重建和物理引擎计算,过程繁琐且对硬件要求高。 今天,我们要介绍一个能优雅解决这个问题的“智能裁判”——OFA-VE。它不是一个AR开发工具,而是一个尖端的多模态推理系统。它的核心能力是进行“视觉蕴含”分析,简单来说,就是判断一段文字描述是否符合一张图片所展现的事实。 我们将深入探讨,如何利用OFA-VE的这种能力,为AR内容生成流程注入“逻辑验证”