AWS MCP Server GA 之后 Agent 调 AWS 总超时？Clash 分流 API 网关与 MCP 出站域名实测（2026）

1. GA 之后场景变了什么：从 npm MCP 到 IAM 上下文

传统的社区 MCP 服务器常以 Node 发行，readme 里 first step 往往是 npx 或 npm install，所以大家会自然而然先把 registry.npmjs.org、github.com 分好——这在站内另一篇 MCP 与 npm、GitHub 分流里已经展开。官方或半官方的 AWS MCP Server 路径不同：它在进程内要替你完成签名、列举资源、触发自动化，必然要频繁访问 STS 拿短期凭证、再去打 ec2.区域.amazonaws.com、cloudformation.……一长串区域AWS API。换言之，问题从「装包出不去」迁移到「云控制面与数据面 API 是否在同一稳定出口上跑完」，并叠上 IAM 会话时长、分区与账号上下文。

当你在 Cursor 与并行的 IDE 模型与开发者域名分流里已经为「对话模型」配了规则，却不把 AWS 侧主机并入，就会出现「Chat 很顺滑、AWS 工具一执行就红字」这一组割裂症状——这通常不是模型慢，而是子进程走了另一条默认路由。把Coding Agent当成一个会在后台不断重试 AWS API 的自动化客户，比把它当成「只会读网页的插件」更接近真实负载。

若尚未完成基础接入，可先过一遍 订阅导入与连通，再阅读 规则与分流总览，以免在讨论 amazonaws 之前，底层 mixed-port 或策略模式本身未就绪。

2. 为什么先盯 STS 与区域端点，而不是 MCP JSON

STS 负责签发或衔接你在区域服务里使用的临时安全凭证；任何经 IAM Role、OIDC、WebIdentity 跳转的路径，最后都要在 sts.*.amazonaws.com 或全局 sts.amazonaws.com 上握手成功，后续 DescribeInstances 之类调用才会开始计时。若这一个跃点因 DNS 解析到极差路由、或在你的规则集里与 ec2.*.amazonaws.com 不同出口，表现会非常像「整段代码卡死」——尤其是 Agent 并行触发多条工具链时，慢 STS 会被放大成大面积超时。

排障时建议先做主机剥离：在与 Agent 同一用户环境的终端里跑一条最小调用（例如 STS GetCallerIdentity 或针对目标区域的只读 API），再在 mihomo 连接面板里对比命中策略；若这里已经间歇性失败，就不必急着在 MCP JSON 里改参数，而是先把 AWS API 路径收敛。另一种常见噪声是「把 TLS 握手超时时长误读成模型慢」——当你看到日志长期在 ClientTLSHandshake 之前打转，优先怀疑选路与 DNS。

3. 会踩到的 AWS 主机名：网关、STS、boto3 共用

这一张表不是「全家桶抄作业」，而是给你在连接日志里对照时用的锚点；真实业务还会在 CloudFront、S3、内部 API Gateway 上长出额外后缀，仍以当场失败的主机名为准。

当你看到 boto3 报错里混着 Connect timeout on endpoint URL 这类字样，先把同一 Region 与 sts 端点抄进同一策略组试试；这比把 超时阈值无脑调大更能对症下药。若你使用了企业内网出口或拆账号的多网关拓扑，也要确认「CLI 终端」和「IDE 起的子进程」是否落在同一网卡与同一套环境变量。

4. 与站内「MCP 加 npm／GitHub」专栏如何分工

站内已有 以 npm 与 GitHub 为主干 的 MCP 专文：解决的是「装依赖」这条链。本篇刻意不再重复 registry.npmjs.org 表格，而只写 AWS API 与 IAM 会话相关出口。实践上可以把它理解成两条并行规则链：一条继续照管 Node／Git；一条专门承接 amazonaws.com 与 STS，二者可以汇入同一 策略组，但域名集合不要在脑子里混为一谈，避免排障时互相甩锅。

这种拆法也方便检索：读者搜「Model Context Protocol」若其实是 npm 卡，会自然掉进前一篇；若已经定位到 AWS 控制台与 CLI 都慢，再落到本篇的 网关叙述，更贴合真实意图。

5. DNS、Fake-IP 与 TLS：别把 IAM 报错当网速

在启用 fake-ip 的配置里，解析结果与连接日志中的主机名需要对齐，否则规则命中会像抽签。建议对公共后缀 amazonaws.com 使用与团队其它云流量一致的 DNS 出口，并在出现问题时优先对照 mihomo 面板里「真实连接域名」字段而不是只看浏览器地址栏。HTTPS 场景下若嗅探未开或版本组合不兼容，也可能出现 SNI 与路由决策不一致——这与「控制台能打开网页」并不矛盾，因为浏览器路径和 boto3 进程路径未必共享同一内核钩子。

当链路已稳定却仍遇到 IAM 拒绝对象或过期令牌，那才是回到策略文档、aws sts get-credential-* 轮换与最小权限审查的时机；反过来，若网络未稳就急着改 Role trust，很容易陷入「策略越改越宽、问题其实在抖动的 STS」的无效循环。

6. mihomo 规则草稿：把 amazonaws 收敛到同一出口

下面是一段只为说明「把 STS、区域 API 与常见 MCP 网关主机放同一可靠组」的骨架。请将 PROXY_AWS 换成你团队用于云 API 的策略组名称；若要与默认浏览器组拆分，也可以单独建组再用 url-test 或 fallback 保障抖动时的退路。

# Example: route AWS control-plane hosts via one stable outbound group
rules:
  - DOMAIN-KEYWORD,agent.aws,PROXY_AWS
  - DOMAIN-SUFFIX,amazonaws.com,PROXY_AWS
  - DOMAIN-SUFFIX,aws.amazon.com,PROXY_AWS
  - DOMAIN-SUFFIX,console.aws.amazon.com,PROXY_AWS

顺序上应当把更具体的 网关关键字放在前列，再用宽泛后缀收口（与站内强调的规则序一致）。若你明确知道某些 *.amazonaws.com 必须直连（极低概率的内网式例外），用更靠前的 DOMAIN 精确豁免，而不是把整条后缀从表里删掉。对于抖动明显的池子，与其盲目扩大 超时，不如把 DNS、节点组与回落组三件事写进同一页团队文档。

7. boto3、CLI 与 Agent：环境变量和命名空间

Clash 分流只决定包走向；而 HTTP_PROXY／HTTPS_PROXY 决定 boto3 是否愿意先把 TLS 交给本机 mixed-port。若 IDE 拉起的 Coding Agent 子进程没有继承你在 shell profile 里写的变量，而当前模式又不是 TUN 全覆盖，就可能出现「终端里 AWS CLI 秒回、面板里工具一直转圈」的不对称。Windows 与 WSL2 命名空间夹缝中的情形，可对照 WSL2 与 Windows Clash 专文，不要假设 127.0.0.1 在两层世界里语义一致。

另一个少被提及但与IAM联动的开关是 SDK 访问实例元数据的路径：在本地笔记本上通常走公网 AWS API 与密钥，别和 EC2 内访问 169.254.169.254 的叙事混在一起；Agent 若误以为自己跑在实例里，会在错误层级尝试取「角色」，与 Clash 无关却常被误判成网络故障。将「进程到底跑在哪」写清，是区分网关问题与身份问题的分界线。

8. 可勾选排查顺序

9. 常见问题