Kiro 的三种代理设置方法：本地、服务端、Remote

作为kiro的骨灰级用户,这篇是我自己折腾 Kiro / Kiro Remote / Ubuntu Server 代理问题后的复盘。
核心不是“怎么配一个代理”，而是先判断：到底是谁在访问外网？
谁访问外网，代理就要配给谁。

0. 先说结论

Kiro 相关代理大概分三类：

最关键的一句话：

Remote 模式里，Windows 只是入口，真正干活的是远程机器上的 Kiro Server。

所以 Windows 能访问 Google、OpenAI，不代表 Kiro Remote 里的插件、模型、扩展下载、OpenVSX、API 请求也能访问。

1. 方法一：本地代理

这个适合：

• Kiro 直接运行在 Windows / Mac 本机
• Codex / Claude Code / OpenCode / Kiro 都在本机启动
• 没有 Remote SSH 到 Ubuntu
• 外网请求由本机进程发出

这时候代理链路很简单：

Kiro 本地进程
    ↓
本机代理端口
    ↓
Clash Verge / Clash / Surge / 其他代理
    ↓
外网

1.1 Clash Verge 常见端口

我这边常见是：

HTTP 代理：127.0.0.1:7897
SOCKS5 代理：127.0.0.1:7898

本机软件如果支持直接填写代理，就填：

HTTP Proxy:  http://127.0.0.1:7897
HTTPS Proxy: http://127.0.0.1:7897
SOCKS5:      socks5://127.0.0.1:7898

1.2 用 Proxifier 接管本地进程

如果 Kiro 或某些子进程不听系统代理，可以用 Proxifier。

大概思路是：

指定进程名
    ↓
强制走 127.0.0.1:7898 SOCKS5

之前看到过类似进程：

codex.exe
opencode.exe
opencode-cli.exe
node.exe
language_server_windows_x64.exe
antigravity.exe

Kiro 本地如果也有对应进程，就可以加规则。

Proxifier 规则可以这样理解：

Application: Kiro.exe / node.exe / 相关 CLI exe
Target Hosts: Any
Target Ports: Any
Action: 127.0.0.1:7898 SOCKS5

注意：

1. 规则顺序很重要，专门规则要放在 Default 前面。
2. Default 可以保持 Direct，避免所有流量都被代理。
3. 如果只想代理某个 SSH 工具，比如 Termius，也可以只给 Termius.exe 加规则。

2. 方法二：服务端代理

这个适合：

• Kiro CLI / Codex / Claude Code / node 程序运行在 Ubuntu Server 上
• 你是 SSH 到服务器里操作
• 真正访问外网的是服务器上的进程

这时不能只看 Windows 能不能访问外网。

链路是：

Ubuntu 上的 Kiro / node / CLI
    ↓
Ubuntu 环境变量里的代理
    ↓
局域网 Windows Clash 代理端口
    ↓
外网

比如我的 Windows 主机 IP 是：

192.168.22.23

Clash Verge HTTP 代理端口是：

7897

那么 Ubuntu 上可以这样临时启动：

HTTP_PROXY=http://192.168.22.23:7897 \
HTTPS_PROXY=http://192.168.22.23:7897 \
ALL_PROXY=http://192.168.22.23:7897 \
NO_PROXY=localhost,127.0.0.1,::1,192.168.22.0/24,.local \
kiro

或者启动其他 CLI：

HTTP_PROXY=http://192.168.22.23:7897 \
HTTPS_PROXY=http://192.168.22.23:7897 \
ALL_PROXY=http://192.168.22.23:7897 \
NO_PROXY=localhost,127.0.0.1,::1,192.168.22.0/24,.local \
codex

如果你现在的局域网代理机是另一个 IP，比如之前也用过：

192.168.0.214:7897

那就替换成：

export HTTP_PROXY=http://192.168.0.214:7897
export HTTPS_PROXY=http://192.168.0.214:7897
export ALL_PROXY=http://192.168.0.214:7897
export NO_PROXY=localhost,127.0.0.1,::1,192.168.0.0/24,.local

2.1 临时设置

只对当前 shell 生效：

export HTTP_PROXY=http://192.168.22.23:7897
export HTTPS_PROXY=http://192.168.22.23:7897
export http_proxy=http://192.168.22.23:7897
export https_proxy=http://192.168.22.23:7897
export ALL_PROXY=http://192.168.22.23:7897
export all_proxy=http://192.168.22.23:7897
export NO_PROXY=localhost,127.0.0.1,::1,192.168.22.0/24,.local
export no_proxy=localhost,127.0.0.1,::1,192.168.22.0/24,.local

测试：

curl -I https://api.openai.com --max-time 10

或者显式指定代理测试：

curl -v -x http://192.168.22.23:7897 https://ipinfo.io/ip

如果这个通了，说明 Ubuntu 能通过 Windows 的 Clash 出去。

2.2 写入 /etc/environment

如果希望所有登录 shell 都能拿到代理，可以写：

sudo nano /etc/environment

加入：

HTTP_PROXY="http://192.168.22.23:7897"
HTTPS_PROXY="http://192.168.22.23:7897"
http_proxy="http://192.168.22.23:7897"
https_proxy="http://192.168.22.23:7897"
ALL_PROXY="http://192.168.22.23:7897"
all_proxy="http://192.168.22.23:7897"
NO_PROXY="localhost,127.0.0.1,::1,192.168.22.0/24,.local"
no_proxy="localhost,127.0.0.1,::1,192.168.22.0/24,.local"

保存后重新登录 SSH。

检查：

env | grep -i proxy

2.3 Clash Verge 必须允许局域网访问

如果 Ubuntu 要访问 Windows 上的 Clash，Windows 里的 Clash Verge 不能只监听 127.0.0.1。

需要打开类似选项：

Allow LAN / 允许局域网连接

否则 Ubuntu 访问：

http://192.168.22.23:7897

可能会连接失败。

可以在 Ubuntu 上测试端口：

curl -v http://192.168.22.23:7897

有响应说明至少端口能连上。

3. 方法三：Kiro Remote 代理

这是最容易卡住的一种。

你以为是：

Windows Kiro
    ↓
Windows 代理
    ↓
外网

但实际 Remote 是：

Windows Kiro 客户端
    ↓ SSH
远程 Ubuntu 上的 Kiro Server
    ↓
远程 Ubuntu 上的 extensionHost / node
    ↓
外网

所以重点是：

Kiro Remote 的外网请求，大概率发生在远程 Ubuntu 的 ~/.kiro-server 进程里。

之前看到过远程进程路径类似：

/home/yuyuyu/.kiro-server/bin/8971b963336635bcb23572df7df5b1193504d739/bin/kiro-server

还有类似启动参数：

--start-server
--host=127.0.0.1
--connection-token-file
--telemetry-level off
--enable-remote-auto-shutdown
--accept-server-license-terms

也看到过 extensionHost 进程类似：

node ... --type=extensionHost --useHostProxy=false

这个 --useHostProxy=false 很关键。

它说明 Remote 里的 extensionHost 不一定会直接使用 Windows 宿主机代理，所以不能只靠 Windows 的 Clash / Proxifier。

3.1 判断 Kiro Remote 进程是否吃到代理

在远程 Ubuntu 上执行：

ps aux | grep -i kiro

或者：

ps aux | grep -i extensionHost

找到进程 PID 后检查环境变量：

tr '\0' '\n' < /proc/<PID>/environ | grep -i proxy

如果能看到：

HTTP_PROXY=http://192.168.22.23:7897
HTTPS_PROXY=http://192.168.22.23:7897
http_proxy=http://192.168.22.23:7897
https_proxy=http://192.168.22.23:7897
NO_PROXY=localhost,127.0.0.1,::1,192.168.22.0/24,.local

说明 Kiro Remote server / extensionHost 进程确实拿到了代理。

如果这里没有代理变量，那 Kiro Remote 很可能还是直连外网，然后就会卡在下载、登录、扩展市场、API 请求上。

3.2 给 Kiro Remote server 配环境变量

最简单做法是先写 /etc/environment，然后重新连接 Remote。

sudo nano /etc/environment

加入：

HTTP_PROXY="http://192.168.22.23:7897"
HTTPS_PROXY="http://192.168.22.23:7897"
http_proxy="http://192.168.22.23:7897"
https_proxy="http://192.168.22.23:7897"
ALL_PROXY="http://192.168.22.23:7897"
all_proxy="http://192.168.22.23:7897"
NO_PROXY="localhost,127.0.0.1,::1,192.168.22.0/24,.local"
no_proxy="localhost,127.0.0.1,::1,192.168.22.0/24,.local"

然后断开 Kiro Remote，重新 SSH / 重新连接远程。

3.3 如果 Kiro Server 已经启动，需要重启它

因为环境变量只会在进程启动时继承。

如果 Kiro Server 已经启动了，你后来才改 /etc/environment，旧进程不会自动更新。

可以在远程 Ubuntu 上先看进程：

ps aux | grep -i kiro

必要时杀掉旧的 Kiro Server：

pkill -f kiro-server
pkill -f extensionHost

然后在本地 Kiro 里重新连接 Remote，让它重新拉起远程 server。

3.4 Remote 安装阶段也可能需要代理

Kiro Remote 第一次连接远程机器时，可能会下载类似：

https://prod.download.desktop.kiro.dev/releases/remotes/.../kiro-reh-linux-x64.tar.gz

如果这个阶段远程 Ubuntu 没代理，就可能出现：

Error resolving authority
Couldn't install vscode server on remote server

所以 Remote 的代理不是连接成功后才需要，而是安装远程 server 的第一步就可能需要。

4. 三种方式的区别

4.1 本地代理

适合本机 Kiro。

Kiro 在 Windows
代理也在 Windows

优点：

• 最简单
• Proxifier 好控制
• 适合本地开发

缺点：

• 对 Remote 模式帮助有限
• 只能管本机进程，管不了远程 Ubuntu 上的 Kiro Server

4.2 服务端代理

适合 CLI / 服务直接跑在 Ubuntu。

Kiro / Codex / Claude Code 在 Ubuntu
Ubuntu 通过 Windows Clash 出口

优点：

• 对服务器上的 CLI、node、Python、curl 都有效
• 适合云服务器 / 内网服务器开发

缺点：

• 依赖 Windows 代理机一直开着
• Clash Verge 必须允许 LAN
• IP 变了要改环境变量

4.3 Remote 代理

适合 Kiro Remote SSH。

Windows Kiro 只是入口
远程 ~/.kiro-server 才是真正执行者

优点：

• 解决 Remote 里插件、扩展、模型、API 不通的问题
• 适合 Windows 写代码 + Ubuntu 跑项目

缺点：

• 容易误判，以为 Windows 能翻墙就够了
• 需要确认远程 Kiro Server 进程是否继承了代理环境变量
• 旧进程需要重启

5. 推荐排查顺序

第一步：确认代理源头可用

在 Windows 上确认 Clash Verge 正常。

然后确认局域网代理打开：

Allow LAN / 允许局域网

第二步：Ubuntu 测试能否连 Windows 代理

在 Ubuntu 上：

curl -v -x http://192.168.22.23:7897 https://ipinfo.io/ip

能返回 IP，说明 Ubuntu 到 Windows Clash 这条链路没问题。

第三步：Ubuntu 环境变量是否正确

env | grep -i proxy

应该能看到：

HTTP_PROXY
HTTPS_PROXY
http_proxy
https_proxy
NO_PROXY

第四步：Kiro Remote 进程是否继承代理

ps aux | grep -i kiro

找到 PID：

tr '\0' '\n' < /proc/<PID>/environ | grep -i proxy

如果没有代理变量，说明 Remote 进程没吃到代理。

第五步：重启 Kiro Server

pkill -f kiro-server
pkill -f extensionHost

然后重新连接 Remote。

6. 我自己的最终理解

这件事最大的坑，不是代理地址填错，而是代理配置对象搞错了。

本地模式下：

我操作的机器 = 发请求的机器

Remote 模式下：

我操作的机器 ≠ 发请求的机器

Windows 上点 Kiro Remote，只是把 UI 和入口放在 Windows。

真正下载 remote server、跑 extensionHost、访问扩展市场、调用某些网络资源的，可能是远程 Ubuntu。

所以判断代理位置的唯一标准是：

哪个进程发请求，就给哪个进程配代理。

这句话比记命令更重要。

7. 一套比较稳的配置模板

假设：

Windows IP: 192.168.22.23
Clash HTTP Port: 7897
Ubuntu 网段: 192.168.22.0/24

Ubuntu 写入：

sudo tee -a /etc/environment > /dev/null <<'EOF'
HTTP_PROXY="http://192.168.22.23:7897"
HTTPS_PROXY="http://192.168.22.23:7897"
http_proxy="http://192.168.22.23:7897"
https_proxy="http://192.168.22.23:7897"
ALL_PROXY="http://192.168.22.23:7897"
all_proxy="http://192.168.22.23:7897"
NO_PROXY="localhost,127.0.0.1,::1,192.168.22.0/24,.local"
no_proxy="localhost,127.0.0.1,::1,192.168.22.0/24,.local"
EOF

重新登录 SSH 后测试：

env | grep -i proxy
curl -v -x http://192.168.22.23:7897 https://ipinfo.io/ip
curl -I https://api.openai.com --max-time 10

然后重启 Kiro Remote server：

pkill -f kiro-server
pkill -f extensionHost

重新用 Kiro 连接 Remote。

最后检查 Kiro 进程是否拿到代理：

ps aux | grep -i kiro
tr '\0' '\n' < /proc/<PID>/environ | grep -i proxy

如果这里能看到代理变量，基本就对了。

8. 最后的判断口诀

本地 Kiro 不通：查 Windows 代理 / Proxifier
Ubuntu CLI 不通：查 Ubuntu 环境变量
Kiro Remote 不通：查 ~/.kiro-server 和 extensionHost 是否继承代理

再压缩成一句：

本地管本地，服务端管服务端，Remote 管远端 Kiro Server。

这就是 Kiro 代理问题的核心。