现象：Agent Toolkit 或 Bedrock 调用「偶发超时」、凭证链却看似正常

2026 年，Amazon 在 Agent 方向上的工具链持续迭代，「在本地跑 Agent、通过 Amazon Bedrock 调模型」这类工作流越来越常见。你在 VS Code、Cursor 或独立终端里启动示例项目时，日志里可能反复出现 Read timeout、Connection reset、Unable to locate credentials（实则是网络层在取凭证或刷新 Token 时失败），或者流式响应走到一半突然静音。与此同时，浏览器打开 AWS 控制台 似乎又「勉强能用」——于是否开始怀疑：是不是 Bedrock 额度、是不是 Region 配错、是不是 IAM Policy 太严？

这三类问题当然都要排查，但在国内或复杂出口网络下，更隐蔽的一类根因是：同一套进程里，不同步骤访问的是不同的 *.amazonaws.com 主机名，而你的 Clash 规则只命中了其中一部分。例如模型推理走 bedrock-runtime，凭证刷新走 sts 或 SSO/OIDC 域名，遥测与 CloudWatch 再占一批子域；任意一条链路落在直连或错误节点上，都可能表现为「API 超时」而不是明确的 403。本文目标是把这类问题从「猜规则」变成「看日志、补主机名、固定出口」的可重复流程，关键词覆盖 AWS Agent Toolkit、Amazon Bedrock、Clash 分流规则 与 API 超时 的典型搜索场景。

若你还同时在用 OpenAI 兼容端点、Cursor 或命令行里的其他大模型客户端，可交叉阅读《AI 站点分流》、《Cursor IDE 分流》与《Claude Code 分流》：浏览器、桌面 IDE 与 AWS SDK 三类进程的代理继承方式并不相同，不宜用一条「海外通杀」规则敷衍了事。

为什么必须给 Bedrock 与通用「海外站」分开建策略组

Clash 里最常见的误区，是把所有欧美站点丢进同一个 PROXY 组，再依赖 MATCH 兜底。对刷网页或看视频往往够用，但对 长连接、流式响应、区域型 API 来说，这种粗放策略有三个明显副作用。

第一，出口频繁切换会破坏会话一致性。若你对代理组配置了自动测速或故障转移（url-test / fallback），在长请求过程中一旦切换节点，TLS 会话或 CDN 侧的会话粘连可能失效，表现就是「前半段 tokens 正常、后半截突然超时」。Bedrock Converse Stream 等对实时性敏感的接口尤为明显。

第二，错误的核心并不是「翻墙」而是「端到端任一 AWS 主机名没被同一出口稳定送达」。STS 返回的临时凭证若在几十秒内就因为后续请求走了直连而无法续期，你看到的就是扑朔迷离的 intermittent failure。只有把这条链路上的主机名都纳入同一逻辑策略组（或至少稳定的出口优先级），才能把问题收口。

第三，不是所有 amazonaws.com 都适合一刀切代理。有些轻量 STS 呼叫或企业内 Hybrid 环境下的特定端点直连反而更快；简单粗暴的 DOMAIN-SUFFIX .amazonaws.com 若全部走海外节点，有时会放大延迟与计费风险。更可维护的方法是：先有「Bedrock/AWS 核心业务」专属组（下文简称 AWS_BEDROCK），其余 boto3 相关主机名按需追加或通过 rule-provider 维护。

与本站其他「AI 网关」文章的关系

若你的 Toolkit 链路里还接了 OpenAI 兼容网关或自建反向代理（例如经由 API Gateway），除了 AWS 本体域名外，还请把网关域名写入同一稳定策略组或与模型下载/CDN类分流文一样按「服务对象」拆分，避免一段走代理一段直连。

端点分层：从 STS 凭证到 Bedrock 推理这一条链

下面按「 boto3/botocore 实际会发生什么」自下而上拆分常见主机名。AWS 服务端点会随 Region、产品与账户配置变化，下列清单只做排障起点——务必以自己机器上 Clash 连接日志为准做增删。

STS、SSO、IMDS 与凭证链相关

在启用 IAM Role、AssumeRole、IAM Identity Center（SSO）或实例元数据场景时，SDK 会向不同的凭证服务发包。控制台里看起来像「突然无法 refresh token」，有时是这一层被墙或走错出口。

  • sts.*.amazonaws.com——Security Token Service；跨区域时可出现非默认区域的 STS hostname。
  • sso.*.amazonaws.com、oidc.*.amazonaws.com 及 Identity Center Portal 域名（若你使用 SSO 登录流）。
  • 若程序跑在 EC2/容器且走 IMDS，可能涉及 169.254.169.254 等链路——本地开发通常不碰，但若远程 attach 需注意与 TUN/路由的配合。

Bedrock Runtime、Control Plane 与管理面

  • bedrock-runtime.{region}.amazonaws.com——推理与流式输出的主战场，多数「模型调用超时」应在此出现连接记录。
  • bedrock.{region}.amazonaws.com——列举模型 / 配额等控制面调用。
  • 部分账户会用到 Global 或 Inference Profile（跨区域路由）；主机名前缀可能仍为 bedrock-runtime. 但 Region 后缀不同——以日志为准统一纳入 AWS_BEDROCK 组。
  • secretsmanager.{region}.amazonaws.com、kms.{region}.amazonaws.com 等——若你从 Secrets Manager/KMS 取 API Key，同样不要漏写在规则置顶段之前。

控制台、Telemetry、Artifacts 与其它「隐形」域名

  • console.aws.amazon.com 及 CloudShell 等相关子域——若你在浏览器与 CLI 混合验证，建议和日常「控制台分流」保持一致出口以免 Cookie/会话割裂。
  • CloudWatch Logs、X-Ray、CodeGuru Profiler 等产品若默认开启采集，会向各自服务主机名打点；Toolkit 样板间有时默认打开遥测封装，易被忽略却在后台持续重试拖累首包耗时。
  • 若你从 s3.amazonaws.com 或有独立桶域名的前缀拉取 Prompt 模板或大文件，可把 S3 端点归入开发资源一类，思路接近《开发资源分流》而非纯 Bedrock。
不要用「整条 amazonaws」逃避维护

技术上可以写宽泛匹配，但一旦与其他国内仍要直连的云监控、CDN 共存，排障会更痛苦。建议是：先有 Bedrock+STS 核心集，再按需扩张；配合 rule-provider 按周 Review 日志差分。

先让 boto3/SDK 的流量进入 Clash

与 Claude Code、Ollama 等 CLI 同理：规则写得再精确，进程没走 Clash 就全是空谈。两种主路径任选其一。

路径一：HTTPS_PROXY 只影响当前 Shell

在运行 Agent Toolkit、aws CLI 或 Python 脚本的同一个终端会话中导出标准代理变量：

# macOS / Linux
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

# Windows PowerShell
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:HTTP_PROXY  = "http://127.0.0.1:7890"
$env:NO_PROXY    = "localhost,127.0.0.1"

把 7890 替换为你配置文件里的 mixed-port。boto3、大部分主流 HTTP 库与 awscli 都能识别这组变量；若在 IDE「集成终端」里跑，要确保该集成终端继承了环境变量。AWS_CA_BUNDLE、企业自建中间人解密等特例若存在，请参考安全团队文档，不在此展开。

路径二：TUN 接管全进程

不想每个终端手写 export 时，可启用客户端的 TUN 模式，让所有 TCP 出站经虚拟网卡进入内核。注意权限、与其他 VPN/WFP 驱动的冲突排查，详见《TUN 排错》。启用后仍需核对：Toolkit 的流量是否真的显示在 Clash 连接列表中，而不是被「绕过列表」甩出隧道。

Clash 配置示意：AWS_BEDROCK 组与规则置顶

下面是一份仅作结构演示的 YAML，组名与节点占位符请务必替换。请与你现有 Profiles 手动合并后再 reload，勿直接覆盖生产配置。

proxy-groups:
  - name: AWS_BEDROCK
    type: select
    proxies:
      - YOUR-STABLE-NODE
      - AUTO-BEST-LATENCY
      - PROXY

rules:
  # --- AWS Agent Toolkit / Bedrock / STS (put BEFORE GEOIP CN & MATCH) ---
  - DOMAIN-SUFFIX,bedrock-runtime.us-east-1.amazonaws.com,AWS_BEDROCK
  - DOMAIN-SUFFIX,bedrock.us-east-1.amazonaws.com,AWS_BEDROCK
  - DOMAIN-SUFFIX,sts.us-east-1.amazonaws.com,AWS_BEDROCK
  # Add other regions you actually use, e.g. ap-northeast-1, eu-west-1
  - DOMAIN-KEYWORD,bedrock-runtime,AWS_BEDROCK
  - DOMAIN-KEYWORD,bedrock.,AWS_BEDROCK
  - DOMAIN-KEYWORD,sts.,AWS_BEDROCK
  # SSO / OIDC if applicable (verify in logs)
  - DOMAIN-KEYWORD,sso.,AWS_BEDROCK
  - DOMAIN-KEYWORD,oidc.,AWS_BEDROCK
  - DOMAIN-SUFFIX,console.aws.amazon.com,AWS_BEDROCK
  # --- then your domestic / generic rules ---
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

说明要点：

  • 区域必须对齐：AWS_REGION 或代码里指定的 Region 决定实际主机名后缀，「只写 us-east-1、却在 ap-southeast-1 调模型」会绕开所有规则。
  • KEYWORD 规则有泛化风险：示例里用 DOMAIN-KEYWORD,bedrock. 是为覆盖多 Region 的快捷写法；若与内网或无关服务撞名，应改回显式 DOMAIN-SUFFIX 列表。
  • 顺序：Bedrock/STS 相关条目应位于国内直连大段之前，否则请求会在 GEOIP,CN 或错误的直连规则处提前返回。
  • 与 OpenAI 兼容层并存：若你在应用里把 Bedrock 暴露为 OpenAI 兼容 HTTP 端点，除 AWS 主机名外还要给该 HTTP 域名单独策略组，避免混在通用 PROXY 里被 url-test 抖动。

更完整的字段说明、DNS 与 fake-ip-filter 基础，见《Clash YAML 深度解析》。

进阶：用 rule-provider 维护「AWS 开发」清单

当主机名随实验 Region 增加，可把清单放入独立文件或远程规则集，主配置里只保留一行 RULE-SET，方便版本管理与团队共享。思路与 Anthropic、Docker 等专题文一致：把「业务域集合」和「策略组选择」解耦。

rule-providers:
  aws-bedrock-dev:
    type: file
    behavior: domain
    path: ./ruleset/aws-bedrock-dev.yaml
    interval: 86400

rules:
  - RULE-SET,aws-bedrock-dev,AWS_BEDROCK

本地 ruleset/aws-bedrock-dev.yaml 可逐步堆叠你在日志里确认过的 payload 条目；更新后只需触发 Clash reload，不必每次在大文件里翻找插入点。

DNS、Fake-IP 与「能解析却连不上」

SDK 在建立 TLS 前必须先解析服务名。若 Clash 使用 Fake-IP 且某 AWS 子域未加入 fake-ip-filter，少数 HTTP 栈可能出现「解析成功、握手阶段被中间设备干扰」的错觉。遇到仅 CLI 异常、浏览器正常时，可暂时切到 redir-host 或把 *.amazonaws.com 相关解析纳入 filter 观察是否缓解。

另一类问题是 DNS 泄漏导致 SNI 被精准识别：解析走国内公共 DNS，而 TCP 出站走代理——不同地区对此容忍度不一。建议在 Clash 内统一 DNS upstream，或与 TUN「仅域名嗅探 sniff」选项配合时在日志里复核真实目标 SNI。

验证：四步闭环排错清单

我们建议按下列顺序自检，跳过任一步都有可能把「网关超时」误判为代码 Bug。

  1. 连接日志是否存在目标主机名——运行最小 Bedrock Invoke 示例或 Agent Toolkit Hello World；在 Clash 里过滤 bedrock、sts。若完全没有记录，先回到「环境变量 / TUN」而不是改规则。
  2. 命中的策略组与节点是否固定——长耗时场景下短时间自动换节点会引发流式断开；对 AWS_BEDROCK 优先用手动 select 固定一条低丢包线路。
  3. Region 与环境变量对齐——核对 AWS_REGION、AWS_DEFAULT_REGION、配置文件 ~/.aws/config 与代码常量是否一致。
  4. 凭证链单独验证——用 aws sts get-caller-identity（同代理上下文）与服务端报错对比；若 STS 已通过而 Bedrock Runtime 超时，则更可能是节点质量或控制台侧配额，而非密钥本身。
  5. 对照 CloudWatch/SDK 超时参数——适当调高 connect_timeout / read_timeout 可帮助区分「永久性阻断」与「链路抖动」，但不应遮挡代理未生效的问题。

常见问题

问：Inference Profile 或跨区域路由会怎样影响主机名？

答：boto3 可能根据账户启用的 ARN 前缀选择不同于「物理 Region」的 endpoint；请以实际 DNS 解析结果为准，把所有出现过的 Runtime 前缀加入同一策略组或在 rule-provider 中维护别名列表。

问：能在公司 HTTP _PROXY 出站后再套一层 Clash 吗？

答：那叫链式代理，需要在 Clash 的 proxy 定义里单独声明 upstream corporate proxy；混用两套环境变量时很容易形成环路或证书校验失败，建议在网络架构文档里画图确认。

问：boto3 debug 日志要开吗？

答：短时开启 --debug（CLI）或在 Python 里打开 botocore 的 DEBUG，可快速列出「下一次失败前最后一个成功 HTTP 往返」对应的服务名——比盲加规则更高效。

合规与安全

Amazon Bedrock 与 IAM 凭证的使用须遵守你与 AWS 的合同、数据驻留与安全策略；不同地区对产品可用性及模型上架情况可能不同。本文仅讨论客户端侧网络路径优化，不构成绕过服务条款或数据出境合规义务的建议。企业环境请在安全团队指导下配置代理与会话录像。

结语

相比那些把「整条国际流量」粗放进一个策略池、只靠运气碰节点的做法，Clash 的价值在于：把 AWS Agent Toolkit 与 Bedrock 这类长连接 API 的出口变成可读、可调、可按日志演进的对象。当你能明确看到每一条 bedrock-runtime.*.amazonaws.com 与 STS 呼叫落在同一稳定的 AWS_BEDROCK 组上时，大量「玄学超时」会直接消失在网络层——剩下的才是值得交给应用与配额团队处理的真问题。

传统方案往往需要改系统全局代理、手写 iptables，或与各类企业终端安全软件拉锯；而在 Clash 体系里，规则与订阅解耦，策略组可随项目迭代增量维护。当你希望把工作流从试错里解放出来，不妨下载 Clash 客户端，沿用本文的分层思路接上自己的 Agent 工程，再配合连接日志几周滚动优化，就能把 Bedrock API 超时收束到可控范围。