博客折腾记:AI CLI 的“代理陷阱”与多环境配置实录
昨天被舍友启发,我也感觉网页版的 AI 效果实在不尽如人意。同时大家有鼓吹 Claude Code,便想着自己也尝试一下。
本想着能体验一把超丝滑的代码辅助,结果还没开始,就直接卡在了起跑线上!
这篇文章记录了,我是怎么从 Claude Code 报错,一路折腾到 Gemini CLI 认证失败,最后终于摸索出一套在 WindowsPowerShell、PowerShell 还有 Linux 上都能通用的代理方案。
1. 怎么 Claude Code 就用不了呢?
刚开始运行 Claude Code 的时候,终端一直转圈圈提示连接超时。
我当时的第一个反应是:难道这玩意儿非得充 Pro 账号才能用? 于是我赶紧换了 Gemini CLI 试试,结果还是报错!这时候我才反应过来,根本不是账号的问题,而是我的代理根本没进到命令行里去。
2. 踩坑实录
坑位一:环境变量的“永久”大坑
为了图省事,我一开始用了 setx 想设个永久变量:setx HTTP_PROXY "http://127.0.0.1:7897"
当我关掉梯子想搞本地调试的时候,命令行直接“断网”了!
因为 setx 会把设置写死在注册表里,工具找不到代理服务器就会硬生生地报错,根本不会自动切换到直连状态。
这里千万别用 setx!建议在 Shell 配置文件里写个小函数,随用随开,不用就关。
坑位二:Windows PowerShell vs PowerShell 7
我发现自己在 pwsh (PowerShell 7) 里写好的配置,换到旧版的 Windows PowerShell 竟然没法用,甚至还喷出了一堆莫名其妙的乱码(比如 浠g悊宸插紑鍚)。
原因其实很简单:
- 各走各的路:这两个 Shell 读取的是完全不同的配置文件。
- 编码不和:旧版 PowerShell 对那种不带 BOM 的 UTF-8 文件特别不友好。
- 协议不全:在 Windows 下,如果不配好 **
ALL_PROXY**,很多走 SOCKS5 协议的 AI 工具根本就跑不起来!
坑位三:Gemini 认证
配置 Gemini CLI 的时候,网页端明明说认证成功了,结果命令行里却跳出一个 GOOGLE_CLOUD_PROJECT 找不到的错误。
原因:因为我用的是普通账号,Google 强制要求得关联一个云项目或者使用API,配置起来超级麻烦。
解决办法:直接换成个人 Pro 账号登录!个人账号自带配额,登上去就能用,完美避开了那些复杂的后台设置。
3. 代理方案
为了不让大家(还有未来的我)再掉进这些坑里,我整理了这套配置。
A. Windows:PowerShell 5.1 & pwsh 7
在两个环境里分别输入 notepad $PROFILE,把下面的代码贴进去就行(记得保存的时候选 带有 BOM 的 UTF-8 哦!):
1 | function proxy { |
B. Linux / WSL (Bash/Zsh)
编辑 ~/.bashrc 或者 ~/.zshrc,加上这段:
1 | # Linux 比较挑剔,大小写都要照顾到 |
最后:在 Windows 上折腾代理,要是没配 ALL_PROXY,约等于没做!