WSL 中彻底清除代理环境变量：从网络故障到 Hermes 顺利启动的全记录
WSL 中彻底清除代理环境变量：从网络故障到 Hermes 顺利启动的全记录
日期：2026-08-14
环境：Windows 11 + WSL2 Ubuntu 22.04，Node.js 20+，Hermes Agent / Hermes-Web-UI
背景
最近在 WSL 中部署 Hermes 和 hermes-web-ui 时，频频遇到网络问题。无论是 npm install 还是 hermes 自身的 API 调用，总是报出 ECONNREFUSED、ENOENT 或代理连接超时。经过排查，发现问题出在 WSL 环境变量中残留了错误的代理配置，导致所有网络请求都试图通过一个不可达的代理服务器（192.168.101.1:7897），而实际可用的 Windows 主机 IP 应为 10.255.255.254。
本文详细记录了从定位问题到彻底清除代理、成功启动服务的完整过程，希望能为遇到类似困扰的开发者提供参考。
问题现象
1. npm 安装失败
npm install -g hermes-web-ui --registry=https://registry.npmmirror.com
报错：
npm error code ECONNREFUSED npm error syscall connect npm error errno ECONNREFUSED npm error FetchError: request to https://registry.npmmirror.com/hermes-web-ui failed, reason: connect ECONNREFUSED 192.168.101.1:7897
2. hermes 启动后无法访问外部 API
即使成功安装，hermes chat 或 hermes gateway run 也提示代理连接失败，最终 API 调用返回 ECONNRESET 或超时。
3. 环境变量检查
执行 env | grep -i proxy 可看到大量代理变量，且均指向错误的 IP 地址：
https_proxy=http://192.168.101.1:7897
HTTP_PROXY=http://192.168.101.1:7897
ALL_PROXY=http://192.168.101.1:7897
NO_PROXY=localhost,127.0.0.1,10.255.255.254,192.168.101.1
...
而 ping baidu.com 是通的，说明网络本身没问题，只是代理配置有误。
排查过程
1. 临时清除代理验证
执行以下命令，当前终端立即生效：
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY all_proxy NO_PROXY
再检查 env | grep -i proxy 发现输出为空，说明代理变量确实是被环境变量引入的。但新开一个 WSL 终端，代理又会出现，说明变量被写入了配置文件。
2. 定位配置文件
使用 grep 递归搜索常见配置文件：
grep -H -i proxy ~/.bashrc ~/.profile ~/.bash_profile /etc/environment /etc/profile.d/*.sh 2>/dev/null
输出结果：
/root/.bashrc:export HTTP_PROXY="http://$WINIP:7897" /root/.bashrc:export HTTPS_PROXY="http://$WINIP:7897" /root/.bashrc:export ALL_PROXY="http://$WINIP:7897" /root/.bashrc:export NO_PROXY="localhost,127.0.0.1,10.255.255.254,$WINIP" /etc/profile.d/proxy.sh:export HTTP_PROXY="http://$WINIP:7897" /etc/profile.d/proxy.sh:export HTTPS_PROXY="http://$WINIP:7897" /etc/profile.d/proxy.sh:export ALL_PROXY="http://$WINIP:7897" /etc/profile.d/proxy.sh:export NO_PROXY="localhost,127.0.0.1,10.255.255.254,$WINIP"
发现代理定义在 /root/.bashrc 和 /etc/profile.d/proxy.sh 中，且使用了未定义的变量 $WINIP，导致最终解析为空，从而引发连接错误。
解决方案
1. 临时清除（当前终端快速救急）
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY all_proxy NO_PROXY
执行后，当前终端可以正常使用 npm 等命令，适合紧急安装软件。
2. 永久删除（一劳永逸）
备份配置文件（可选）
cp /root/.bashrc /root/.bashrc.bak
cp /etc/profile.d/proxy.sh /etc/profile.d/proxy.sh.bak
删除 /root/.bashrc 中的代理行
sed -i '/^export \(HTTP_PROXY\|HTTPS_PROXY\|ALL_PROXY\|NO_PROXY\)=/d' /root/.bashrc
删除 /etc/profile.d/proxy.sh 中的代理行
sed -i '/^export \(HTTP_PROXY\|HTTPS_PROXY\|ALL_PROXY\|NO_PROXY\)=/d' /etc/profile.d/proxy.sh
如果某些文件不存在，
sed会报错，但忽略即可。
重新加载配置
source /root/.bashrc
或退出终端重新登录。
验证清除效果
env | grep -i proxy
应无任何输出，证明代理已彻底移除。
最终结果
代理清除后，一切恢复正常：
-
npm install -g hermes-web-ui瞬间成功（通过国内镜像直连） -
hermes-web-ui start正常启动，监听8648端口 -
hermes chat也能顺利联网，不再报代理错误 -
后续只需关注 API 密钥和账户余额等业务问题，网络层已无阻碍
经验总结
-
WSL 网络共享机制
WSL 默认共享 Windows 的网络，无需额外代理即可访问外网（尤其是国内镜像源）。我们往往是在 Windows 下使用代理软件，然后手动在 WSL 中设置了环境变量，但一旦 IP 变更或代理服务未启动，就会导致所有请求失败。 -
正确的排查顺序
-
先
ping外网确认基础连通性 -
再检查
env | grep -i proxy是否存在多余变量 -
定位配置文件（
~/.bashrc、/etc/profile.d/*.sh等） -
小心处理，避免误删其他重要内容
-
-
永久与临时结合
临时清除便于快速安装，永久修改则避免重复劳动，建议两者都掌握。 -
后续关注点
网络问题解决后，若遇到 API 调用报错，大概率是密钥、余额或模型配置问题，而非网络层故障。
附：本文涉及的常用命令速查
# 临时清除所有代理变量
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY all_proxy NO_PROXY
# 查看当前代理变量
env | grep -i proxy
# 在配置文件中搜索代理定义
grep -H -i proxy ~/.bashrc ~/.profile ~/.bash_profile /etc/environment /etc/profile.d/*.sh 2>/dev/null
# 删除 bashrc 中的代理 export 行
sed -i '/^export \(HTTP_PROXY\|HTTPS_PROXY\|ALL_PROXY\|NO_PROXY\)=/d' ~/.bashrc
# 重新加载 bashrc
source ~/.bashrc
致谢
感谢 Hermes Agent 官方文档 和社区讨论帖提供的线索，尤其是指出 WSL 中 localhost 代理不可达的问题，帮助我快速定位 10.255.255.254 这一关键 IP。
浙公网安备 33010602011771号