使用海外节点转发 Kiro 访问以获取 Claude 模型权限

一、背景

1、为何在我的Kiro上不能使用Claude模型

AWS re:Post 上有用户反映：从2026年5月后，登录 Kiro 成功后，可选模型却只有 DeepSeek/Qwen 等大模型，看不到 Claude，怀疑是订阅出了问题。如下截图。

以上截图中，可以看到在网站上 AWS 专家给出的答复是：订阅没有问题，当界面不显示 Claude 只给出 DeepSeek、Qwen 等开放权重模型时，限制来自地理位置限制。Anthropic 有严格的支持国家/地区清单。若从不受支持的区域接入，平台会自动隐藏 Claude 以符合服务条款，回退到出口限制更少的模型。建议的解决办法：确认使用 Kiro 计算机在 Anthropic 的支持国家清单内；检查工具的连接设置，使其指向完整支持 Claude 的 AWS 区域。

由此，为满足在 Kiro 上使用 Claude 的需求，需要将访问 Kiro 核心域名的流量牵引到受支持区域的海外节点，从海外节点连接到 Kiro 服务器，可让 Claude 等模型恢复可用。

2、Kiro 转发方案原理

Kiro（CLI 与 IDE）在运行时会访问一组核心服务域名（xxx.kiro.dev），用于模型对话、配置管理、鉴权、遥测、自动更新等。在部分网络环境中，直接从本地出口访问这些海外端点会遇到链路质量不稳定或访问受限的问题。这时候需要每个 Kiro 运行环境启动海外 VPN。但是，由此会给使用者带来诸多不便，开启 VPN 后，大量原有企业内网系统的访问、以及国内网络的访问会不正常。因此需要一种对客户端没有影响的方案。

本方案的关键是：仅让访问 Kiro 相关域名的核心流量从一个稳定的海外 IP 出网，不影响其他域名访问，不修改每台电脑客户端、不必给每台机器装VPN/代理、也不必让全部流量绕行海外。具体设计包括：

客户端零改动：不需要在系统/浏览器里设代理，不安装 VPN，不修改本机网络 DNS 域名解析服务器，什么都不用修改。
选择性牵引：在办公室网络层面，只把 Kiro 真正需要走海外的 kiro.dev 域名牵引出去，登录鉴权、AWS API、系统更新、扩展市场等仍走本地默认互联网出口。
不解密流量：转发节点只做四层透传，客户端与真实服务器端到端校验 TLS 证书，客户端无需安装任何根证书。
合规跨境：跨境链路使用合规的专线 /跨境SD-WAN 承载。

二、方案设计架构

1、整体架构

整个方案由两段拼成：私有 DNS 选择性牵引 把目标域名指向海外转发节点，nginx 做四层转发 在不解密的前提下把流量透传到 Kiro 服务器。如下架构图。

海外节点转发 Kiro 访问架构

2、流量路径和关键组件

方案区分两类流量，走不同路径：

(1) 被牵引的 Kiro 核心域名（kiro.dev 系列）

Kiro 客户端 (CLI / IDE)
  │ ① 解析 xxx.kiro.dev 等多个域名、多级子域名
  ▼
私有 DNS 解析器 ──(命中私有记录)──▶ 返回海外代理私网 IP
  │ ② 向代理 IP:443 发起 TLS（ClientHello 携带 SNI）
  ▼  （经合规跨境专线 / SD-WAN 进入海外 VPC）
海外 EC2 + Nginx ── ssl_preread 读取 SNI（不解密）
  │ ③ 用公网 DNS 解析上游真实公网 IP（防解析环路）
  │ ④ 经 IGW 用自动分配公网 IP 出网
  ▼
真实 *.kiro.dev 服务器（端到端 TLS，代理仅四层透传）

(2) 其余所有域名（登录 IdP、AWS API、更新、S3 等）

Kiro 客户端 ── 办公室本地公网 DNS 正常解析 ──▶ 走本地默认出口 ──▶ 直接访问（不经海外代理）

关键组件说明：

组件	角色	要点
私有 DNS（私有托管区 `kiro.dev`）	选择性牵引	逐条录入子域 A 记录，指向代理私网 IP；未录入域名不受影响
合规跨境专线 / SD-WAN	合规跨境承载	承载牵引到海外的 kiro.dev 流量
海外 EC2 + Nginx（`stream` + `ssl_preread`）	SNI 四层转发	只读 ClientHello 的 SNI，按白名单透传，不做 TLS 终止
IGW + 自动分配公网 IP	出网	仅出向；对公网零入站暴露

为什么用 SNI 四层转发而非常规 HTTP 代理：ssl_preread 只解析 TLS 握手里的 SNI（明文的服务器名），据此连接真实服务器并原样透传字节流，全程不解密。证书链端到端有效，客户端无需信任任何中间证书，对 Kiro 完全透明。

三、Kiro 客户端所在环境配置

1、客户端本机无需配置

本方案客户端侧不安装代理、不改本机 DNS。唯一前提是客户端及其浏览器不得启用加密 DNS（DoH/DoT），否则域名解析会绕过办公网私有 DNS，导致牵引失效（登录会用系统默认浏览器打开 app.kiro.dev，浏览器若开启 DoH 同样会绕过）。

2、客户端所在办公网的 DNS 解析修改要求

客户端所在办公网的 DNS 解析器，能对下表中的 kiro.dev 子域返回海外代理的私网 IP（其余域名照常返回公网真实 IP）。区域以订阅 Kiro 的主区域 us-east-1 为例：

域名	子域名层级	用途
`app.kiro.dev`	3 级	登录门户
`assets.app.kiro.dev`	4 级	应用资源
`runtime.us-east-1.kiro.dev`	4 级	核心服务（模型 / 对话）
`management.us-east-1.kiro.dev`	4 级	配置、访问管理
`telemetry.us-east-1.kiro.dev`	4 级	遥测
`prod.download.desktop.kiro.dev`	5 级	自动更新、Powers 注册表、图标
`prod.us-east-1.auth.desktop.kiro.dev`	6 级	Token 交换、刷新、登出
`prod.us-east-1.telemetry.desktop.kiro.dev`	6 级	遥测
`cli.kiro.dev`	3 级	CLI 安装脚本
`prod.download.cli.kiro.dev`	4 级	CLI 二进制 / manifest 下载

以上清单请随时关注 Kiro 官网，确保域名记录一致为最新。

将以上所有域名，解析到一个远端 AWS 海外云上 VPC 环境内的 EC2 的内网 IP，用于接收 Kiro 流量。

3、是否使用通配符满足 kiro.dev 域名解析要求

以上配置中，设计多个子域名、多层子域名，配置时候需要录入许多条目。这里解释不使用通配符的原因是：一旦把 kiro.dev 整个私有托管区关联到解析域，该区会对 kiro.dev 及其所有子域名权威应答。用 *.kiro.dev 通配会把"未显式列出的子域名"也覆盖上，可能导致部分域名解析不正常。私有区内没有录入的 kiro.dev 子域会返回 NXDOMAIN，不会回落到公网解析。

因此为了正确控制流量，这里不使用通配符，而是逐条设置解析。需要注意，整域托管的代价是：一旦 Kiro 新增任何未录入的 kiro.dev 子域，客户端会因 NXDOMAIN 直接解析失败而中断，而非优雅回落到公网。因此必须主动跟踪官方域名清单的更新，及时补录新子域。

4、不修改DNS解析、继续走本地默认出口的域名清单（无须特殊设置）

以下域名不经过私有 DNS 解析，不经海外代理，继续走公网默认解析与本地默认出口：

域名	用途
`cognito-identity.us-east-1.amazonaws.com`	Kiro 登录联合身份
`.signin.aws` / `portal.sso..amazonaws.com` / `oidc..amazonaws.com` / `.awsapps.com`	Kiro 统一认证与 IAM Identity Center 鉴权
`q.us-east-1.amazonaws.com`	Kiro 服务旧版端点（官方仍要求放行，未来弃用）
`open-vsx.org` / `openvsx.eclipsecontent.org`	Kiro IDE 的扩展应用市场

以上清单不需要在私有 DNS 配置，因为他们默认就能被全球DNS正常解析，正常访问。其中 q.us-east-1.amazonaws.com 是 Kiro 服务的旧版端点，官方文档注明将来弃用但当前仍需放行；因其位于 amazonaws.com 域、不便随 kiro.dev 牵引，本方案让其走本地默认出口。若牵引后 Claude 仍不可用，需排查该端点是否参与了模型可用性判定。

5、本机网络变更注意事项：

如果使用 Kiro 的电脑一直在本地网络上，然后切换到了有私有 DNS 解析的网络环境，此时客户端本机上会有各种 kiro.dev 域名解析的缓存，新的私有 DNS 不会立刻生效。此时可以：

(1) 清空本机的 DNS 缓存：在 Windows 上执行 ipconfig /flushdns，在 Linux 上执行 resolvectl flush-caches，在 MacOS 上执行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder 生效。
(2) 直接简单粗暴的重启电脑。

客户端环境具备了使用条件，现在看云端。

四、海外云上环境部署

1、合规的跨境专线 / 跨境SD-WAN

跨境流量必须使用合规链路承载。可选方案包括云厂商提供的跨境专线、合规的 SD-WAN 服务等。要点：

链路两端连通客户端所在网络与海外 VPC，承载牵引到海外的 kiro.dev 流量。
链路本身加密 / 可信，满足跨境合规要求。
仅承载被牵引的核心流量，非 kiro.dev 流量仍走本地默认出口，跨境带宽占用可控。

专线连接到 AWS 云上时候，可使用 VGW 或者 TGW 方式连接，确保从国内办公网络到 VPC 内网可以 ping 通。

2、云上 EC2 部署

POC 阶段单台 EC2 即可（如 t3.small），单点故障可接受，不做集群 / 双 AZ / NLB。生产环境应使用多个节点，并使用 c 或者 m 系列机型。

操作系统：

推荐 Ubuntu 24.04LTS 版本。

安全组：

入站仅放行来自国内办公区网络客户端的网段的发来的请求，入站允许 TCP 443（如有运维需要可加 22；如需用 ping 探测 MTU 还需放行 ICMP）。
不放行任何公网来源（不放行 0.0.0.0/0 入站），确保对公网零暴露。
出站全放行，不区分域名。

公网IP：

实例用自动分配公网 IP 出网即可，无需绑定 EIP；SourceDestCheck 选项默认状态保持开启，因为本方案是转发特定流量，因此不需要像架设路由器一样调整本选项。

磁盘：

使用 EBS gp3 类型，容量建议 50GB 以上，便于保存日志

3、Nginx 配置

Nginx采用的转发方案是 stream + ssl_preread，仅四层 TCP 协议做 SNI 透传，不解密 HTTPS 流中的请求。

安装 nginx 后，编辑配置文件如下：

stream {
    resolver 8.8.8.8 1.1.1.1 valid=60s;   # 本机作为 Proxy 直接用公网DNS完成请求

    map $ssl_preread_server_name $upstream {
        app.kiro.dev                                $ssl_preread_server_name;
        assets.app.kiro.dev                         $ssl_preread_server_name;
        runtime.us-east-1.kiro.dev                  $ssl_preread_server_name;
        management.us-east-1.kiro.dev               $ssl_preread_server_name;
        telemetry.us-east-1.kiro.dev                $ssl_preread_server_name;
        prod.download.desktop.kiro.dev              $ssl_preread_server_name;
        prod.us-east-1.auth.desktop.kiro.dev        $ssl_preread_server_name;
        prod.us-east-1.telemetry.desktop.kiro.dev   $ssl_preread_server_name;
        cli.kiro.dev                                $ssl_preread_server_name;
        prod.download.cli.kiro.dev                  $ssl_preread_server_name;
        default                                     "";   # 非以上白名单 SNI 的话，拒绝请求
    }

    server {
        listen 443;
        ssl_preread on;                  # 只读 SNI，不解密
        proxy_connect_timeout 5s;
        proxy_pass $upstream:443;        # 按真实 SNI 连接真实服务器
        access_log /var/log/nginx/stream_access.log;
    }
}

配置要点：

ssl_preread on 只解析 ClientHello 的 SNI，不做 TLS 终止，证书链端到端有效。若客户端启用 TLS 1.3 ECH（加密 ClientHello）则读不到 SNI、会命中 default 被拒；目前 Kiro 未启用，属前瞻风险。
map 用精确 FQDN 与 DNS 牵引清单一一对应；$upstream 为空（非白名单）时连接被拒，等效白名单外拒绝。DNS 的 A 记录清单与此 map 白名单须作为同一份清单同步维护，任一方漏配都会导致牵引或转发失败。
resolver 必须指向公网 DNS。避免错误配置本 VPC 的 DNS，用公网 DNS 才能解析到真实上游、避免 DNS 解析的干扰。
部署后用 nginx -t 校验，再 reload。

配置完毕后启动服务。

五、验证测试

按"先解析、再透传、后端到端"的顺序验证：

1、在海外 EC2 代理上自检

执行 ss -lntp 命令可看到 443 监听。

执行如下命令验证请求：

echo | openssl s_client -connect 127.0.0.1:443 \
  -servername runtime.us-east-1.kiro.dev 2>/dev/null \
  | openssl x509 -noout -subject -issuer

可看到如下信息表示工作正常。

subject=CN = runtime.us-east-1.kiro.dev
issuer=C = US, O = Amazon, ...

测试非白名单 SNI 中的域名访问（如 example.com）应取不到证书、且连接被拒。执行命令如下：

echo | openssl s_client -connect 127.0.0.1:443 \
  -servername example.com 2>&1 | head -n 20

此时返回包含 connect:errno、no peer certificate available 等信息，表示拒绝请求。

2、在 Kiro 客户端侧验证

在运行 Kiro 的客户端上，运行如下测试：

测试域名解析正确、流量牵引生效：nslookup runtime.us-east-1.kiro.dev 解析为代理私网 IP。
未牵引的流量不受影响：nslookup baidu.com 解析为真实公网 IP 且可访问。
功能正常：Kiro CLI / IDE 登录与模型调用成功。

六、优化网络连接质量

以下参数可优化 Kiro 用户发起访问时候长连接被中断的问题。

1、修改运行 nginx 进程与连接参数

stream 透传场景下每条客户端连接都会占用一个 worker 连接，需放宽连接数与文件描述符上限，避免 worker_connections are not enough、too many open files。

worker_processes auto;                # 跟随 vCPU 数
worker_rlimit_nofile 65535;           # 提高 worker 可用文件描述符

events {
    worker_connections 16384;         # 单 worker 并发连接上限
}

stream {
    proxy_connect_timeout 5s;
    proxy_timeout 1h;                 # 放宽长连接,默认仅 10m
    proxy_socket_keepalive on;        # 开启到上游的 keepalive
    # ... ssl_preread / map / server 同前
}

同时在 systemd 服务里放开文件描述符上限，否则 worker_rlimit_nofile 不生效：

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
LimitNOFILE=65535

2、Linux OS 系统内核网络参数

放宽连接跟踪表、端口范围、缓冲区与 keepalive，匹配跨境长连接与高并发：

# TCP keepalive,间隔短于链路上最短的空闲超时
sysctl -w net.ipv4.tcp_keepalive_time=60
sysctl -w net.ipv4.tcp_keepalive_intvl=15
sysctl -w net.ipv4.tcp_keepalive_probes=4

# 连接跟踪表与本地端口范围
sysctl -w net.netfilter.nf_conntrack_max=262144
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# 收发缓冲区与等待队列,提升跨境大流量吞吐
sysctl -w net.core.somaxconn=32768
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

# 启用 BBR 拥塞控制,改善跨境高延迟链路吞吐
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

确认无误后写入 /etc/sysctl.d/99-kiro-proxy.conf 持久化，重启后仍生效。

3、其他优化

七、问题排查

使用中如果遇到 Kiro 频繁中断、connection reset 等问题，按"先定位断点、再逐层排查"的顺序处理。绝大多数中断的根因落在前两类：跨境隧道 MTU 黑洞、长连接被中间设备掐断。

1、先用日志定位断点在哪一层

先确认是"客户端→代理"还是"代理→上游"断的，再决定排查方向。

Kiro 客户端：IDE 用命令面板 Kiro: Open Logs，CLI 直接看终端报错，重点看 reset 发生在哪个域名，当然也可能不显示域名，仅显示网络中断。
代理 nginx 服务器：执行 tail -f /var/log/nginx/error.log 看解析失败、upstream 超时、连接耗尽；access log 看是刚连就断还是传一会才断。
日志落盘增加字段：在 nginx 的配置文件中输出日志的部分，参数 access log 之前加上增加字段 $ssl_preread_server_name、$session_time、$bytes_sent 等变量，由此打印的日志将包含更多信息，便于按域名统计连接质量、快速定位异常 SNI。
Kiro 日志看不出域名时，从代理侧的 $ssl_preread_server_name（SNI）定位，这是唯一能同时看到所有被牵引域名与中断时刻的全局视角。实践中绝大多数"对话中断"都落在 runtime.us-east-1.kiro.dev，因为它是长连接流式、流量最大。

2、跨境链路质量、MTU 传输窗口问题

跨境链路质量可能导致跨境单链路的丢包 / 抖动会引起间歇性 reset，用 mtr <真实上游IP> 观察丢包与抖动；链路不稳时联系承载商或启用备用链路。

此外，MTU 配置不当同样会引发 reset 包。跨境隧道会在原始数据包外再加一层封装，从而减小链路实际可用的有效 MTU；当客户端仍按常规 1500 字节发送大包、且 IP 头带有 DF（不可分片）标志时，超出隧道 MTU 的大包既无法被分片，沿途设备回送的 ICMP「需要分片」报文又常被防火墙丢弃，于是形成 PMTUD（路径 MTU 发现）黑洞。典型故障表现为：TLS 握手等小包能正常起步，但数据流里大包一上来就卡死或被 reset。

在 nginx 代理上执行如下命令检查：

# 探测路径可用 MTU,大包不通小包通即为 MTU 问题(需安全组放行 ICMP,否则改用 nping --tcp -p 443 等基于 TCP 的探测)
ping -M do -s 1472 <代理私网IP>      # Linux
ping -D -s 1472 <代理私网IP>         # macOS,1472 逐步减小到 1400 / 1360

# 在 nginx EC2 端点上启用 PLPMTUD,让内核自动探测可用 MSS、绕过黑洞(对黑洞最省心,无需知道确切 MTU)
sysctl -w net.ipv4.tcp_mtu_probing=1
# 必要时再调低 EC2 网卡 MTU,使通告的 MSS 随之减小

注意:本架构的跨境链路由合规的专线服务商提供，AWS 侧网络接口为 VGW/TGW ，因此链路本身的 MTU 参数设置问题需联系专线提供商处理。

3、排查长连接空闲超时导致的连接中断

runtime 域名是长连接流式，链路上任一环（SD-WAN/NAT/有状态防火墙）的空闲超时短于实际需求，就会单边断开，对端再发数据时收到 RST。解法是放宽超时并开启 keepalive。

server {
    listen 443;
    ssl_preread on;
    proxy_timeout 1h;                 # 放宽长连接,默认仅 10m
    proxy_socket_keepalive on;        # 开启 keepalive
    proxy_pass $upstream:443;
}

# 系统 keepalive 间隔设得短于链路上最短的那个空闲超时
sysctl -w net.ipv4.tcp_keepalive_time=60
sysctl -w net.ipv4.tcp_keepalive_intvl=15

4、核查上游 DNS 解析与虚拟机网络上限

排除前两类后，再看上游解析与实例网络规格。

DNS 解析：确认 resolver 指向公网 DNS（8.8.8.8 / 1.1.1.1），避免云上解析错误，执行 grep -i resolver /var/log/nginx/error.log 查解析报错。
实例网络上限：对照云厂商文档核查当前规格的带宽、PPS、CPS、并发连接上限，结合云监控看中断时刻是否触顶；连接跟踪表用 sysctl net.netfilter.nf_conntrack_count / nf_conntrack_max 核查，接近上限则调大或升级实例规格。

5、在 nginx 代理服务器上抓包 RST 来源

在 nginx 代理服务器上进行网络层抓包，确认 RST 是哪个方向的 IP 地址发出的，用于快速排查问题。

tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -w /tmp/rst.pcap

RST 来自 Kiro 服务器 Server 的上游方向：多为 MTU / 超时 / 上游 IP 问题。
RST 来自开发者客户端方向：多为跨境链路 MTU、NAT 超时、EC2 实例网络上限。

八、参考文档

AWS rePost: Why can I use Claude in Kiro

Kiro 防火墙 / 代理 / 数据边界域名清单

Kiro 与接口端点（AWS PrivateLink）

nginx ssl_preread 模块

Route 53 私有托管区

最后修改于 2026-06-16