症状：Console 似在线，Bedrock／API 却总「半通」

当你在 AWS Management Console 里开通或试用 Amazon Bedrock 上的 Claude 系列模型，或在本地用官方 SDK／示例脚本走区域运行时端点发起推理请求，最先撞墙的不一定是「密钥无效」或「额度用尽」，而是一种更难描述的半通：控制台左侧菜单能点开一半、模型目录列表偶尔空白、Playground 里发送一条消息却长时间 pending；切到终端又能看到 ETIMEDOUT、TLS 握手卡住、或者同一脚本昨天可跑今天失败。社区第一反应常常是换节点、换 Region、轮换访问密钥；但在 mode: rule 的 Clash／Mihomo（例如 Clash Verge、mihomo party 等图形壳）视角里，更高概率的根因是AWS Console、登录跳转、STS／IAM 与各服务后缀 *.amazonaws.com没有稳定落入同一套你可审计的出口策略——于是链路被伪装成「云平台本身不稳」。

本文把「Claude Platform on AWS」落到可观测的路由问题：先用连接日志抓到真实 SNI／Host，再用独立策略组 + 置顶规则把控制台壳层与数据面 API拆开；随后串联HTTPS_PROXY、可选 TUN 与 DNS fake-ip 复核，避免「Chrome 看上去通了，Python／Node SDK 仍在直连」。若你还在并行调用Anthropic API（直连供应商域名而非仅 Bedrock），请同时对照本站《ChatGPT 与 Claude 分流》里关于供应商控制台与 API 域名分桶的思路；两篇关心的主机名集合并不完全重合，但排障顺序高度相似。

合规提示：请遵守所在地法律法规与企业网络 acceptable use 政策。本文仅讨论客户端出站路由与 DNS 观测，不提供绕过雇主安全管控的建议；若组织要求固定国境出口或禁用个人节点，请以安全团队书面策略为准。

为什么是「Console + API」一起出事？

Claude 以托管服务形态出现在 AWS 上时，绝大多数用户路径会同时触碰人机界面与程序化接口：前者驱动你在浏览器里完成模型访问配置、配额视图与账单跳转；后者则在 IDE、流水线或本地实验中发起InvokeModel 一类调用。对边界设备而言，这两种路径并非「同一个域名走到底」，而是一堆并行 TLS 会话——既有 console.aws.amazon.com、*.console.aws.amazon.com 一类控制台入口，也有 signin.aws.amazon.com 及可能的 IAM Identity Center／SSO 跳转；凭证刷新还会牵扯 sts.<region>.amazonaws.com、iam.amazonaws.com 等；真正的推理流量往往落在区域化的 bedrock-runtime.<region>.amazonaws.com，并可能与控制平面主机名（日志里常见的 bedrock.<region>.amazonaws.com 等前缀）交织出现。任意一段若被前置的 GEOIP,CN,DIRECT、过宽的国内域名集或误判的 RULE-SET 截胡，就会把症状投射到上层业务随机超时之上。

检索热度层面，「Claude Platform on AWS」与「Bedrock 控制台卡顿」类长尾在正式商用公告后会快速堆积工单与论坛帖；把分流规则写成可复述的工程步骤，比在群组里反复粘贴「换个节点试试」更能缩短你自己的定位时间——这也是本文刻意点名 AWS Console、Anthropic API 与 Clash Verge 等关键词的原因：它们对应真实用户的检索语句与界面路径。

流量长什么样：一次点击背后是并行握手

可以把典型会话拆成彼此依赖又并行发生的几段，这一段清单应以你的连接日志为准扩展，而非死记硬背：

控制台壳层：console.aws.amazon.com、常见区域的 *.console.aws.amazon.com、文档或营销跳转所用的 aws.amazon.com 子域；若静态脚本域名落在单独 CDN，需在日志里补齐。
登录与联邦：signin.aws.amazon.com 以及企业启用 SSO 时可能出现的 Identity Center 主机名与其它 IdP；这一段最容易表现为无限转圈而非直接的 HTTP 500。
安全令牌与账号维度：sts.<region>.amazonaws.com、iam.amazonaws.com 等；SDK 默认链路与控制台会话刷新都会触碰。
Bedrock 数据面：区域化的 bedrock-runtime.<region>.amazonaws.com；同时留意控制平面相关前缀是否出现在列表或配额页面加载路径中。
并行观测类依赖：CloudWatch、Billing、CloudTrail 面板在排障时常常被低估——当你以为是「模型推理挂了」，实际可能只是某个监控子域未被规则覆盖导致前端超时。

这意味着：仅写一条「把所有海外站丢给 GLOBAL」并不能解释 Bedrock 控制台为啥有时完整有时残缺；你需要的是对齐命名空间的桶与可读的 proxy-group 名称，让下一次失败能用一行日志指回具体策略组。

分桶：Console／OAuth、STS／IAM、amazonaws 数据面

下面是教学分桶起点，实战务必结合企业与区域的真实出站表扩展：

桶 A：控制台与公有门户。至少包含 DOMAIN-SUFFIX,console.aws.amazon.com（若内核版本支持细分也可拆成精确 DOMAIN）、常用 DOMAIN-SUFFIX,aws.amazon.com；若日志出现独立静态资源域，用精确 DOMAIN 置顶更安全。
桶 B：登录链。signin.aws.amazon.com 及 Identity Center／SSO 相关主机名；与企业 IdP 并存时，不要把个人节点策略与公司必需跳转混在同一个难以解释的组里。
桶 C：通用数据面后缀。一行 DOMAIN-SUFFIX,amazonaws.com 往往覆盖绝大多数区域服务端点；若组织要求某些服务只能走专线或合规代理，必须进一步拆分或使用自有 RULE-SET。
桶 D（可选）：Anthropic 直连。当你除了 Bedrock 以外仍调用官方 Anthropic API，应按供应商文档补齐 api.anthropic.com 等域名段，避免遗漏导致的「一半请求走 AWS、一半走供应商」。

拆桶的价值在于二分定位：OAuth 旋圈优先回看桶 B 与 DNS；推理超时优先回看桶 C 是否落入劣质出口或被前置大陆规则抢走。

实测技巧：在 Clash Verge 或内核自带的连接详情里，抓取失败瞬间的第一条命中规则名称与 SNI；先用单行 DOMAIN 置顶验证，再合并进 RULE-SET，可显著降低「导入他人 FULL 却无法解释优先级」的风险。

策略组命名：一年后再打开仍能看懂

建议使用业务可读名称，例如 AWS-Console-OAuth、AWS-API-Bedrock，类型优先 select；长会话推理场景避免过激进的 url-test 周期把出口抖散。合规审计场景下，「稳定但略慢」常常优于「频繁切换节点」。不要把十几个云厂商混在一个名为 GLOBAL_SELECT 的组里——那会直接在工单层面毁掉可追溯性。

与Clash 分流规则相关的讨论若想写得专业，关键词应落在主机名桶而非玄学形容词：AWS Console、amazonaws.com、STS、Bedrock，这些词汇也同时服务于读者的检索意图。

规则顺序：大陆兜底不得压在云服务精细段之上

自上而下命中即止。典型事故是前置写过宽的国内集合，把本应与你信任的出境节点对齐的 *.amazonaws.com 会话送进不稳直连；外在表现正是间歇超时。骨架可参考：私网直连 → 企业确认必须直连的极小集合 → 本文桶 A–D → 其它开发者／AI 规则 → 大陆域名集与 GEOIP → MATCH。若整体范式不熟，请先阅读《规则分流详解》再改动配置文件，避免复制 FULL YAML 时锁死顺序。

`HTTPS_PROXY` 与 SDK：别以为托盘「系统代理」覆盖一切

本地调用 Bedrock 往往来自 Python boto3、Node AWS SDK、IDE 插件或内部脚手架——它们的父进程不一定是浏览器。仅勾选图形客户端里的系统代理，不能保证子进程继承环境变量或被 TUN 覆盖。请在真实启动命令的 shell里导出（端口换成你的混合端口，勿照抄）：

Shellexport 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,10.0.0.0/8,192.168.0.0/16

若你把公司 TLS 解密／自定义 CA 与个人节点方案混在同一台机器，请先处理信任锚与 MITM，不要盲目更换境外节点。AWS 官方工具亦有自己的代理惯例，内部若以固定网关为准请以运维文档为准。

TUN 与 fake-ip：第二现场的 DNS 对齐

启用 dns.enhanced-mode: fake-ip 而缺少合适的 fake-ip-filter 或 nameserver-policy 时，应用解析视图与内核连接面板可能出现短暂不一致，表象同样是超时。请把 DNS 改动与规则改动放在同一轮观测窗口记录，否则一周后工单无法复盘。TUN 能在进程顽固绕开代理变量时兜底接管路由；细节可参考《TUN 模式指南》。

专线／私有接口：若企业架构要求部分 AWS 访问只能经由办公网或批准的转发器，把会话盲送往个人节点会破坏网络分区假设并可能触发审计告警；请先与安全团队对齐允许的出口拓扑，再在 Clash 中用等价语义表达。

与站内「AWS MCP Server IDE」一文如何互补

当你在 Cursor、VS Code 等环境里通过 MCP 频繁触碰 IAM、STS 与泛 AWS API 时，排障切入点会更贴近 IDE 子进程与插件宿主；这与「浏览器里的 Bedrock 控制台 + 本地 SDK」路径共享大量主机名，但触发顺序不同。建议并行阅读《AWS MCP Server IDE 分流》，把两份域名桶合并前手工比对优先级，避免多套 FULL 规则首尾拼接制造冲突。

验证清单（建议逐步勾选）

确认订阅与规则集可更新；若基础链路不通，先按《订阅导入教程》修复。
分别在浏览器控制台与本地 SDK／CLI复现失败动作，导出连接日志里的 SNI／Host 与命中规则。
将控制台／登录与通用 amazonaws.com至少拆成两组策略，便于二分。
把确认的域名以 DOMAIN 精确行置顶，再补充 DOMAIN-SUFFIX,amazonaws.com；核验位置在GEOIP-CN 与国内兜底之前。
在启动 CLI 的 shell 打印 HTTPS_PROXY；为空则用 TUN 复测。
若仍失败，检查 QUIC／IPv6／MTU 等企业网络特性是否与代理交互不良（此类问题常被误判为「Bedrock 挂了」）。
把稳定条目沉淀为注释完善的 YAML 片段，写入变更记录，便于同事接手。

YAML 教学片段（按企业与日志删减）

仅为思想骨架；节点名与远程规则源须来自你信任的提供方：

YAMLproxy-groups:
  - name: "AWS-Console-OAuth"
    type: select
    proxies:
      - "corp-approved"
      - "stable-export"
  - name: "AWS-API-Bedrock"
    type: select
    proxies:
      - "corp-approved"

rules:
  - DOMAIN,console.aws.amazon.com,AWS-Console-OAuth
  - DOMAIN,signin.aws.amazon.com,AWS-Console-OAuth
  - DOMAIN-SUFFIX,console.aws.amazon.com,AWS-Console-OAuth
  - DOMAIN-SUFFIX,aws.amazon.com,AWS-Console-OAuth
  - DOMAIN-SUFFIX,amazonaws.com,AWS-API-Bedrock
  - GEOIP,CN,DIRECT
  - MATCH,GLOBAL

若还需并行覆盖 Anthropic API，请在桶 D 增加供应商域名后再观察日志是否有残留直连。

常见问题（速览）

Q：只写 DOMAIN-SUFFIX,amazonaws.com 够不够？
常常是高性价比基线，但控制台与登录仍有独立主机名；仅用后缀会让 signin／console 在某些版本规则集里排序吃亏，建议显式拆分置顶。

Q：Clash Verge 和普通 Clash 内核结论一致吗？
图形壳主要负责下发配置与展示连接面板；本质仍由 Mihomo／Meta 内核执行规则。关注版本差异与是否启用 Tun／系统代理混杂比纠结应用商店名称更有意义。

Q：能否直接用别人的「AI 全家桶」规则集？
可以起步，但一旦涉及企业与区域锁定，远程集合往往滞后；置顶你从日志确认的 DOMAIN仍然是最便宜的纠错手段。

小结

Claude Platform on AWS并没有把网络形状变简单：它只是把控制台、登录、STS／IAM 与 Bedrock 运行时绑在同一运维语境里，让用户更容易在同一时间轴观察到链路分裂。通过 Clash／Mihomo建立可读策略组、把 AWS Console 相关域与 amazonaws.com 数据面置顶于大陆兜底之前，并联调终端代理或 TUN与 DNS，才能把「玄学超时」还原成哪条规则抢了流量。

市面上不少「一键出海」工具既不提供逐连接的命中解释，也难与多张云厂商规则表并排维护；当故障落在控制台 OAuth 与运行时 API 之间时，这种粒度往往不够用。Clash 官网延续开放分流规则栈的路线：你可以把本文桶与站内 AWS MCP、泛 MCP 开发者分流等专题并排落地，用日志逐项校准，而不是反复重装客户端。Clash Verge用户对连接面板并不陌生——若你需要一款跨平台、对 mihomo 规则友好的壳体走完上述验证，不妨免费下载 Clash 官网，先用一次失败请求的 SNI 对照策略组是否真的落在你命名的出口上。

AWS 服务端点、SKU 名称与控制台路径会迭代；请以控制台即时提示与官方文档为准。若企业策略禁止个人节点出境，请以书面合规要求覆盖本文示例。