Claude Code 在 Windows / PowerShell 连不上？先按这 5 层排查

很多人在 Windows 上装 Claude Code，第一反应是：“浏览器明明能上网，为什么终端里的 Claude Code 连不上？”

这个问题不要一上来就怀疑节点、账号、模型服务。Windows 里最常见的情况是：浏览器走的是一套代理链路，PowerShell / Git Bash / WSL 里的 CLI 工具走的是另一套环境变量。

我更建议按下面这个顺序排查。

先判断是不是命令本身的问题

第一步先跑：

claude --version

如果这一步都不通，优先级不是网络，而是安装和 PATH：

• Claude Code 可能没有装好
• 当前终端没有刷新 PATH
• 你打开的不是实际会运行 Claude Code 的终端环境

这时候不要先折腾代理。先关掉当前 PowerShell，重新打开一个新的终端，再跑一次：

claude --version

如果仍然提示找不到命令，就回到安装路径和 PATH 层面处理。

再看当前终端有没有代理变量

确认命令可用后，再看当前会话有没有代理变量：

echo $env:HTTP_PROXY
echo $env:HTTPS_PROXY
echo $env:NO_PROXY

如果 HTTP_PROXY 和 HTTPS_PROXY 是空的，就很可能出现这种情况：

• 浏览器能上网
• 系统代理看起来也开着
• 但当前 PowerShell 会话没有把代理传给 CLI
• Claude Code 这类命令行工具自然还是连不上

这也是 Windows 用户最容易误判的地方。浏览器能用，不等于 CLI 一定能用。

代理 场景下，先试 HTTP 代理端口

如果你用的是 代理，不要一上来猜一堆端口。先确认本地 HTTP 代理端口，然后在当前 PowerShell 会话里显式设置。

常见示例：

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:NO_PROXY="localhost,127.0.0.1"

然后重新测试：

claude --version
claude

这里的重点不是马上永久配置，而是先验证问题是不是出在“当前终端没有拿到代理变量”。

如果这样能通，说明方向基本对了。后面再决定要不要把代理变量写进 PowerShell profile、系统环境变量，或者改用更稳定的终端工作流。

不要混着用 PowerShell、Git Bash、WSL 排障

另一个常见坑是：一会儿在 PowerShell 设置代理，一会儿去 Git Bash 测试，一会儿又进 WSL。

这样很容易把问题放大，因为三者的环境变量、PATH、命令路径都可能不同。

排障时先固定一条线：

1. 只在当前 PowerShell 里测试
2. 确认 claude --version 能跑
3. 确认 HTTP_PROXY / HTTPS_PROXY 有值
4. 再测试 Claude Code 是否能正常启动

如果你长期做 CLI 开发，再考虑切到 Git Bash 或 WSL。不要在还没定位问题前来回切。

我自己的排障顺序

可以按这个顺序来：

1. 跑 claude --version
2. 如果命令不存在，先修安装和 PATH
3. 如果命令存在，检查当前会话的 HTTP_PROXY / HTTPS_PROXY
4. 在当前会话里临时写入 HTTP 代理
5. 重新运行 claude --version 和 claude
6. 固定一个终端环境继续排查
7. 最后再怀疑节点、域名、系统网络或更底层问题

最容易浪费时间的做法是：命令都还没通，就开始换节点、改系统代理、换终端、重装工具。这样最后很难知道到底是哪一步生效了。

更完整的版本

我把 Windows、PowerShell、代理、PATH、HTTP 代理变量这些情况整理成了一份更完整的排障清单：

Claude Code Windows 代理与 PowerShell 排障指南

如果你正在处理 Claude Code 在 Windows 里“浏览器能联网但 CLI 连不上”的问题，可以按这份顺序一层一层排，不要一开始就把问题想复杂。