為什麼「Claude Platform on AWS」上線後，搜尋議題常指向 AWS，卡住的卻常是控制台與Anthropic API兩種不同路徑？

2026 年 5 月前後，Anthropic 正式把 Claude Platform on AWS 拉到可商用的敘事軸上後，許多組織同時開始在AWS 管理主控台內設定權限、開通模型、對接計費，並讓終端程式或協作工具直接去叫 Anthropic API。這兩條使用者故事看起來都寫「Claude」，對 Clash／mihomo／Clash Verge 使用者而言卻會變成兩種幾乎不相交疊的出口需求：一條是瀏覽器裡的 AWS Console 與身分登入鏈（console.aws.amazon.com、signin.aws.amazon.com、企業 SSO 可能還有中繼域名），大量使用長連線、Cookie 會話一致性與對 amazonaws.com 家族 STS／IAM／區域服務的快速往返；另一條則是直接打在 Anthropic 命名空間的 HTTPS（例如對外公開文件常見的 api.anthropic.com、控制台體驗相關的 anthropic.com／claude.ai 子域視產品綁定而定），以及若在 AWS 上以 Amazon Bedrock Invoke 路線走的 bedrock-runtime.<region>.amazonaws.com 這類區域後綴。

當您只把問題描述成「控制台轉圈」或「API 載入很慢」，其實很難從字面判斷是第一條未完成認證還是第二條 STS／Bedrock／Anthropic 其中一段被 GEOIP／RULE-SET 提前截走。本篇刻意與本站 AWS MCP Server IDE 專文並行對照但不重複：那篇聚焦編輯器內 MCP 工具鏈對 IAM／STS／amazonaws.com 的穩定性；本篇則補齊Anthropic／Claude 對外域名與控制台前端鏈混在一起時，該如何把 分流規則拆開觀察。若你只需要橫向的 ChatGPT／Claude 規則心智模型，可再讀 ChatGPT／Claude 規則專文；若偏終端程式與環境變數，請併讀 Claude Code 終端分流。

合規：Clash／mihomo 與 Clash Verge Rev 等工具僅處理本機轉送與規則，並不提供頻寬／節點服務；請在您所在司法管轄區與公司政策允許的範圍內使用雲端與 AI 服務。本文所列主機為除錯常見範例，實際以官方區域／帳號與瀏覽器／SDK 捕捉到者為準。

症狀拆解：你看到哪一種「慢」或「假性逾時」？

為了不重複無效嘗試，建議進 Anthropic／AWS Console 之前，先把徵兆分箱。第一類是登入未完成或半完成：例如 IAM Identity Center、組織 IdP、或 MFA 視窗卡住，多半是 signin.aws.amazon.com、portal.aws.amazon.com（或企業自定入口）任一條被拒絕、被跳節點、或在 tolerance 很小的 url-test 下反覆換出口，導致 Cookie 對不起來。第二類是主控台殼能打開但某個區域資料永遠轉圈：常見為後端 GraphQL／REST 去不到正確區域 API，請求在日誌中顯示為對 *.amazonaws.com 的長 TLS 卡住，錯誤語意類似請求中止或閘道逾時。第三類則是你自認走 Anthropic API 或 Bedrock Invoke，結果只命中 DIRECT 或掉到毫不相關的群組：瀏覽器可以、CLI 不行的情況幾乎都落在「應用沒進核心」這一側，需要先對照是否改開 TUN 或補環境變數，而不是優先換訂閱。

無論是哪一箱，第一手證據永遠是連線列表裡的真實主機名與規則名稱。許多速成貼複製數十行 DOMAIN，卻沒教讀者在 mode: rule 下檢視「最終合成的 rules 順序」；一旦你訂閱合併器把巨大的 RULE-SET 擺在自建 AWS／Anthropic 細則之前，表面現象就只會剩下「規則寫在檔案裡，但終端通通不會照」。下文會重複這個順序論，是因為在主控台上它往往比換節點更能一次收斂。

AWS Console 與 Anthropic API：為何不建議共用同一個「超大 PROXY bucket」

實務上常見做法是開一個 CLAUDE_AI 或類似名字的群組把所有「看起來與 Claude 相關」字樣的流量都丟進去，短期最省力，但一旦同時要上 AWS 管理主控台、又要打 Anthropic API、又要在企業區網對 Bedrock 做大量批次推理，問題會出在三種對延遲與會話的一致性要求並不相同：主控台通常需要穩定的同一出口地理區域與時間窗口內最少的節點切換，避免 IdP Cookie 異常或 CloudFront／API 對 IP 異常評分；對外Anthropic HTTPS 可能比較吃的是TCP／TLS 來回與 QUIC 競爭在不同節點上的相容性；而純區域 bedrock-runtime.us-west-2.amazonaws.com 這種路線，對離區域資料中心最近的出口往往比「泛泛的美西節點」更吃香。把三者硬塞進單一群組，你只會在日誌裡得到「統計上偶爾看起來都綠」的錯覺。

因此本篇建議至少在策略層拉出兩個可觀測決策：AWS_CONSOLE_STACK（放 signin／console／常見 STS／IAM／您實際啟用之區域 *.<region>.amazonaws.com）與 ANTHROPIC_CLOUD（放 anthropic.com、常見對外 API 主機後綴、以及您是否仍使用 claude.ai／文件站鏈路等）。若要再細分 Invoke 線路，可另加第三個 Bedrock-only 選擇組，對照 區域離節點供應商機房的實際延遲來手選。

規則起點：您該對照哪些hostname 家族？（以日誌為準）

下列清單是觀念的桶，不是保證完備的全球白名單；請永遠以您電腦上 Clash Verge／核心日誌裡跑出來的字串為主補洞。

身分與主控台前門：signin.aws.amazon.com、console.aws.amazon.com、portal.aws.amazon.com（若 SSO 適用）；若企業自定 IdP／中繼，請把 FQDN 單獨 DOMAIN 置前以避免被規則集誤解析。
AWS 身分與權杖服務鏈：sts.amazonaws.com、sts.<region>.amazonaws.com（以您實際區域字面為準）、iam.amazonaws.com；許多控制台「看似前端」請求會被導經 STS 來換臨時憑證。
區域資料面／控制面後綴：*.<region>.amazonaws.com，其中Bedrock 常見字面包含 bedrock-runtime、bedrock 等服務前綴——請在日誌中確認寫法，而不要憑論壇舊片段硬貼。
對外Anthropic／Claude 線：api.anthropic.com、anthropic.com／其企業級子網域、以及您是否仍將 Web 工作流程綁定在 claude.ai——通用命名空間可參見橫向專文，並依產品更新把新字面補進 RULE-SET 或手寫 DOMAIN-SUFFIX。
CDN 與靜態資產噪音：主控台介面會拉大量 CloudFront／第三方分析；這些並非「一定要用海外節點」，但若被錯誤地與對延遲敏感的 API 混在一起，視覺上會像整套服務卡住。若您已確認 SNI，可對明顯的靜態桶另立規則或允許更近的出口。

如果您的組織採 VPC Endpoint、PrivateLink 或區域級 API Gateway，對外公開文件所列主機將完全失效；此時請把方法論複製過去：置前細則＋獨立群組＋日誌驗證，把條目改成內網 DNS 字面。

為何「有加 `amazonaws.com` 規則卻沒效」：分流規則的順序問題

在 Clash Meta／mihomo 家族裡，rules 採自上而下命中即停的策略。對 AWS Console 這種一次頁面可能觸發十數條不同後綴的場景來說，只要前面某條過寬的 RULE-SET 或 GEOIP,<code>,... 先把流量送往錯的出口，你看到的就是載入不完整、只轉圈圈、或請求被取消這類難以歸類的 UI 症狀。建議對照本站國內外分流骨架自查：國內直連對您而言是否包含某些本該對特定區域出海的域名？您是否把整段 Anthropic／AWS bucket 都放在「自動選組」而其 interval／tolerance 設得太激進？

對 Anthropic API 長連線與控制台的多段短請求並存時，url-test 自動切換往往不是朋友；若 STS 請求在您切頁數秒鐘後才失敗回報，而節點同時自動換線，問題會很像「控制台今天特別不喜歡我」——其實是來回延遲變異。此時可先手選單一口岸做 A／B，再回溯 tolerance。

YAML 骨架（將節點名改為您的實際 `proxy` 名稱後再載入）

下方片段示意如何在寬兜底前插入拆分桶；請勿視為對所有帳號都安全的生產範例，並務必將 proxies: [] 換成現有列表。

YAMLproxy-groups:
  - name: "AWS_CONSOLE_STACK"
    type: select
    proxies:
      - "AWS_CONSOLE_AUTO"
      - "HAND_STABLE"
      - DIRECT
  - name: "AWS_CONSOLE_AUTO"
    type: url-test
    proxies: []
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
  - name: "ANTHROPIC_CLOUD"
    type: select
    proxies:
      - "HAND_STABLE"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Keep AWS / Anthropic stacks BEFORE GEOIP-wide / MATCH-wide
  - DOMAIN,signin.aws.amazon.com,AWS_CONSOLE_STACK
  - DOMAIN,console.aws.amazon.com,AWS_CONSOLE_STACK
  - DOMAIN,portal.aws.amazon.com,AWS_CONSOLE_STACK
  - DOMAIN-SUFFIX,amazonaws.com,AWS_CONSOLE_STACK
  - DOMAIN-SUFFIX,amazonaws.com.cn,AWS_CONSOLE_STACK
  - DOMAIN-SUFFIX,aws.amazon.com,AWS_CONSOLE_STACK
  - DOMAIN-SUFFIX,anthropic.com,ANTHROPIC_CLOUD
  - DOMAIN-SUFFIX,claude.ai,ANTHROPIC_CLOUD
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

若您對 DOMAIN-SUFFIX,amazonaws.com 會不會過寬有疑慮，應在日誌中逐條驗證哪些服務可被企業區域策略要求直連後，再加更早的 DIRECT／特定策略覆寫。Anthropic API 若走 Bedrock Invoke，路徑將落在區域字面而非 anthropic.com——此時請以 *bedrock*／實際 SNI 分拆，而不是複製對外Anthropic規則就宣告完成。

Clash Verge、DNS 與 TUN：讓控制台與 API 走同一決策語意

圖形化如 Clash Verge 能顯著降低上手門檻，但它無法自動幫您修「瀏覽器走代理、Python SDK 不走」這類問題。若您發現控制台明明顯示已登入但模型清單始終載入失敗，第一步要在宿主機對 https://sts.amazonaws.com 或日誌中實際出現的字面跑 curl -v／IDE 套件除錯，確認子行程是否真的把流量送進 mihomo 核心；細節可參考只有瀏覽器可走代理時的辨析，以及是否改啟用 TUN。

enhanced-mode: fake-ip 時，請特別確認 Anthropic 與 AWS 相關名稱沒有被 OS 級 DoH 或企業 PAC 規則旁路繞過；若規則看起來正確但在列表中永遠沒對應 TCP，八九不離十還停在 DNS 這一層。Windows 上使用 fake-ip 與 redir-host 的注意事項，可對照本站對應專文分批實驗，避免規則、DNS、節點同時調整而不可回溯。

小抄：若您只求快速驗證是否為規則誤命中，可把 AWS_CONSOLE_STACK 短暫手選到DIRECT與HAND_STABLE對照：Anthropic API 若只在某一口岸復原，問題多半出在節點品質或被目標對 IP 評分；若在兩邊都不行，請回到 STS／DNS／應用未進核心這條鏈。

依序做完這幾件事，就能把「控制台轉圈」收斂到可描述的原因

在復現問題的同一操作中，開啟 Clash Verge 連線或日誌，完整抄下對 AWS Console 與 Anthropic API／Bedrock／STS 的字面 HOST，對照命中規則名稱與出站群組是否與設定檔認知一致。
將含 signin.aws.amazon.com、console.aws.amazon.com 與 *amazonaws.com／anthropic.com／claude.ai／實際日誌字面等細則上移，確保優先級高於會提早終止比對的 RULE-SET、國家／地區級 GEOIP 與兜底 MATCH。
把 AWS_CONSOLE_STACK 設為HAND_STABLE並固定節點重試；若主控台由轉圈變順，將 AWS_CONSOLE_AUTO 的 tolerance 調大或改長 interval，避免頻繁切換會話上下文。
對 Anthropic API 或區域 Invoke 再走一次同樣的「手選對照」，必要時將 Bedrock／STS／對外Anthropic分拆到獨立的 select 群組以利日誌解讀。
確認瀏覽器與 CLI／語言 SDK 對 HTTP(S)_PROXY 與系統代理的一致性；若在 macOS／Windows 上 TUN／延伸權限曾阻擋，請對照對應的 TUN 與安全權限專文，而不是反覆重做同一組 DOMAIN。
將仍漏網的零星主機以 DOMAIN 單筆規則補在桶前後，並把此次除錯寫成小註記，以避免下次換區域或改 IdP 又從頭猜測。Anthropic 與分流規則並非一次寫死的靜態表，而是以日誌驅動的迭代流程。

常見問題

控制台顯示已登入，但模型或配額相關頁面卡在載入，是規則還是帳號權限？

若 CloudTrail／服務側沒有直接錯誤而您只看到瀏覽器側長時間 pending，請先以連線紀錄確認哪一組 API 字面沒有完成 TLS；若對應群組的出口與 STS 請求的出口不一致或頻繁重選，許多徵兆會類似 IAM 問題，但其實是會話割裂。只有當規則層對齊仍失敗時，才把焦點轉移到帳號與區域級配額。

我只要打 Anthropic API，還需要管 AWS Console 規則嗎？

若完全走對外Anthropic HTTPS 且控制台僅偶然使用，可把精力主要放在 ANTHROPIC_CLOUD 桶；但一旦您要在 Claude Platform on AWS 或 Bedrock 內調整 IAM、組織原則、或查詢使用量，控制台鏈會重新變得關鍵。許多使用者把兩種流量硬塞進單一桶後，對外 API 修好而控制台繼續轉圈的案例十分常見——因此在長期配置上仍建議維護可讀的兩個決策語意。

安全：勿在公開頻道張貼含訂閱 token、IAM 使用者名稱、或區域級金鑰的截圖；也不要安裝來源不明的「一鍵全 AI／全AWS」規則包，以免造成不可審的出口或資料外洩風險。

結語與對照本站其他教學的閱讀順序

Claude Platform on AWS把品牌敘述與AWS 管理主控台體驗綁在同一個搜尋意圖下，對實際排錯來說卻必須把Anthropic API、Amazon Bedrock／區域字面、以及身分登入這三種 hostname 類型視為可分拆的對象；若只靠論壇上的一份「Anthropic／AWS 合集」並期待永遠免維護，往往在官方更新子域或企業 SSO 換供應商時整組失真，排錯成本反而高於老老實實依日誌補洞的作法。

相對地，僅強調換節點、卻不提供可重現的規則順序觀念的工具或文章，對需要長期並行使用控制台與程式的進階讀者有明顯不足：問題一回到「載入不完整」這類複合症狀，就會退化成試錯迴圈，難與 IAM／DNS／url-test 變因有清楚對應。Clash 官網 把這些場景收斂在一致的 mihomo 語意下，並與分流規則、Clash Verge 圖形介面拆解主題並陳；當您已照本文完成桶拆分但仍需把 IDE 外掛與 MCP 對齊 STS，可再回到 AWS MCP IDE 分流專文對照細節。若想先把用戶端與基底訂閱跑通，請免費下載 Clash 官網取得整理了安裝與版本索引的資源：通常數分鐘內就能把核心載入並開始用連線紀錄驗證本文的每一段假設。