AWS MCP が IDE でタイムアウト？2026、mihomo／Clash で AWS API を安定分流する実測手順

2026 年版：AWS MCP Server と IDE ではなぜ「途中まで通る」のか

2026 年春前後から、モデルコンテキストプロトコル（MCP）経由でクラウド操作を自動化する流れが、個人用のワークフローからチーム開発まで広がっています。とくにAWS が提供するサーバー実装やエージェント向けToolkit一式は、コード補完や IaC の生成だけでなく、実アカウントとの対話まで IDE に近づけており、検索クエリにも「AWS MCP Server」「VS Code MCP」「Cursor」といった単語が結びつきやすくなっています。一方で運用側からは、「ブラウザのコンソールは普通に開けるのに、MCP が IAM 確認で止まる」「STS での短命クレデンシャルだけが読めない」「リージョンをまたいだ ListBuckets や特定サービスの API がタイムアウト」「認証ウィンドウのリダイレクトが別経路になりログインがループする」といった相談が続いています。

こうした現象は、単一ノードの遅延表示だけでは説明しきれません。起因の多くは、(1) 複数ホストに分散した AWS のエンドポイント群が、広い GEOIP／ルールセットに別々の出口へ振り分けられている、(2) DNS（Fake-IP、ブラウザの Secure DNS、OS の名前解決）がプロセスごとに食い違い、ログ上のホストと実 IP の対応が期待とズレる、(3) IDE プロセスだけシステムプロキシや TUN を経由していない、(4) SSO やデバイスフローのブラウザ遷移だけが別 VPN／直経路になり状態が引き継がれない――といった、出口と名前解決の一貫性の問題です。

本記事は点名して AWS MCP Server と IDE を介したクラウド APIにフォーカスし、複製できる検証順で整理します。汎用的な MCP やパッケージレジストリの経路については開発者向け MCP 分流の記事が土台になります。エディタ拡張のホスト設計全般はCursor 向け分流と併読すると IDE 側の前提が揃います。三者は題材が重なるため、自分の構成に応じて「どのページを主」「どこをリンクで補強」するか決めると運用メモとして使いやすくなります。

免責：サービス名・エンドポイント・認証フローは変更され得ます。本稿はネットワーク設計の出発点です。実ログでホストとリージョンを確認し、アカウント権限・利用規約・課金・法令はご自身の契約に従って判断してください。

症状のタイプ：IAM／STS／リージョン API／ブラウザ認証を分ける

MCP と AWS を組み合わせたとき、ユーザーが体感する切断は大きく次の型に分かれます。型ごとに「Clash が効くレイヤー」が違うため、先にラベルを付けるとログの読みが速くなります。

  • 短命クレデンシャルの取得失敗：STSAssumeRole／GetSessionToken／ID プロバイダ連携など、トークンの発券が始まらないまたは途中でタイムアウトする。SDK が *.amazonaws.com あるいはリージョン付き STS ホストへ長めの HTTPS を張る構成が典型です。
  • 特定サービスのコントロールプレーンのみ遅い：ECS、Lambda、CloudFormation など、サービスごとに サービス名.リージョン.amazonaws.com が分岐します。共通の GEOIP でまとめるとホスト単位では速い別ノードが存在するのに一覧ルールには乗らない、という状態が起きやすいです。
  • コンソールやサインインは通るが IDE だけ失敗：ブラウザはシステムプロキシと TUN の効きが良く、Electron／ネイティブプロセス側はプロキシ環境変数未設定というパターン。AWS プラグインは内部で異なるユーザーAgentや TLS 設定を載せることもあり、見かけだけ揃っているように見えても実経路が分かれることがあります。
  • ブラウザの OAuth／SSO だけ別ルート：AWS IAM Identity Center のスタート URL や、組織の IdP が 別ゾーンにある場合、MCP がキックした外部ブラウザだけが迂回していない経路へ落ち、アカウント一覧が空のまま戻ってくる、といった挙動になります。このとき「IDE の設定は正しい」のに復旧しないケースがあります。

いずれの型でも共通するのは、まずどのホスト名で詰まっているかを一次情報として残すことです。Clash Verge／mihomo の接続一覧、IDE の開発者コンソール、SDK の詳細ログ、必要なら HTTPS_PROXY を明示したcurl -v——手段は環境によりますが、SNI と実際のアウトバウンドの対応だけは揃えてから YAML を触ってください。

AWS 側で分流に効きやすいドメインブロック（コピーの出発点）

以下はログで実在を確認したうえでの加算を前提とした、よく並べるDOMAIN-SUFFIXの例です。DESTINATIONはあなたのプロキシグループ名に置き換えてください。

  • サービスエンドポイントの共通背骨：amazonaws.com — STS、多くのサービスコントロールプレーン、一部グローバル API がこのツリーに収まります。VPC エンドポイントやパブリック APIの切り替え構成次第で例外も出るため、詰まるホストだけ後からDOMAINで上書きするのが無難です。
  • マーケティング／ドキュメント／一部サインインフロー：aws.amazon.com — コンソール入口やヘルプ、一部のブラウザ遷移で参照されます。
  • シングルサインオンとアプリ開始 URL：awsapps.com — IAM Identity Center 利用時などに現れやすく、広い GEOIP と同居させないほうが失敗ログが読みやすいです。
  • 外部 IdP と連携させる構成：実環境によりDOMAIN-SUFFIXを増やしてください。広いDOMAIN-KEYWORD,oauthのような書き方は横滑りするため最初からおすすめしません。

注意：amazonaws.comは巨大な名前空間です。社内向け許可リストを作っている場合、この一行で許可／拒否が一気に広がります。mihomo のmixinやプロファイル分離で、AWS 開発専用の YAML に閉じる運用だとレビュアブルになります。

Clash Verge MCP運用での「AWS だけ別出口」グループ設計

開発者検索で「AWS API 分流」と「IDE プラグイン プロキシ」が一緒に語られる理由のひとつは、生活用ブラウザ向けノードとAPI レイテンシ重視ノードの要件が異なるからです。mihomo ではAWS_MCPのような名前の付いた選択型グループをrulesの先頭近くだけが参照する、というレイヤーを切ると次の運用がしやすくなります。(1) 家族や同僚がノード選択を変えても AWS ワークフローが巻き込まれない、(2) 障害調査ログでプロキシ名 → ホストが追いやすい、(3) メンテ画面で明示的に「ここだけ別地域へ寄せる」ができる、という効果があります。

ノード側の評価は、表示上のレイテンシだけでなく長い TLS の切断頻度にも目を向けます。AssumeRole が途中でRSTされると、アプリ側はECONNRESETでも読み込みタイムアウトにも見えるため、mihomo のダッシュボードと IDE ログを同じ時刻軸で並べて見る癖があると復旧が速いです。外部ダッシュボード構成は外部コントローラー一覧が参考になります。

YAML の骨格サンプル（概念）

インデントとキーの互換は利用中コア・GUI に合わせてください。ここではmihomo 互換 YAMLのイメージだけ示します。

proxy-groups:
  - name: AWS_MCP
    type: select
    proxies:
      - 安定系A
      - 安定系B
      - 自動url-test相当

rules:
  - DOMAIN-SUFFIX,amazonaws.com,AWS_MCP
  - DOMAIN-SUFFIX,aws.amazon.com,AWS_MCP
  - DOMAIN-SUFFIX,awsapps.com,AWS_MCP

このあと評価を奪っている巨大ルールセットがないかを確認し、社内向けドメインや国内直行（必要な環境のみ）、最終MATCHまで続けます。リージョンを固定した実験では、同じクエリでも出口が読み替わって挙動が変わるため、グループだけ切り替えて同等の MCP オペレーションを二回試すと効果検証になります。

評価順の落とし穴：DOMAIN より上に IP 側が鎮座している

Clash 系rulesは上から評価が打ち切られます。mihomo ルール運用でも同じであり、広いGEOIP／ASN／巨大RULE-SETが先にあるとあなたのDOMAIN-SUFFIX,amazonaws.comに到達する前に締められている——という構成は現場でありがちです。対策は、(1)具体的なDOMAIN行を抽象的なセットより上に移動、(2) IP 側で先勝ちしないようルールセットの並べ替え、(3)mixinで AWS 開発用フラグメントだけを単体テスト可能にしておく――の三本です。ルール分岐の詳解にある「読み順の筋トレ」を AWS ホストだけ抜き出して練習すると、自分の構成に落とし込みやすくなります。

DNS・Fake-IP：タイムアウトに見える「別の出口」問題

名前解決が Clash 外で済んでしまうと、ダッシュボードのFake-IP タブでは期待したマッチがあるのに実接続は直行、という状態が現れます。AWS SDK は環境によって独自の証明書束やリージョン推論ロジックを持ち、アプリ側の設定と OS の名前解決が食い違うと STS のエンドポイント選択だけが異なるホストになり、タイムアウトだけが目立つこともあります。

ヒント：設定変更のたびに（可能なら）IDE を一度終了してプロセス単位で DNS キャッシュを捨て、同じ MCP ワークフローをもう一回だけ流す。mihomoの DNS クエリログと並べるとずれが即座に見つかります。

TUN とシステムプロキシだけでは拾えないトラフィックがある場合は、TUN モードガイドにある前提（権限、アプリのバイパス、ループバックとの関係）を読み、アプリ側の「プロキシを使わない」リストに自分のワークロードが入っていないかも確認してください。

実測ステップ一覧（step-list）

以下は運用ログを残しやすい順序です。途中で環境依存の選択肢がありますが、(1)→(5)の軸は崩さず進めます。

  1. 失敗再現後すぐ、mihomo／Clash Verge の接続ビューを開き、詰まっているamazonaws.comまたはaws.amazon.com／awsapps.com配下のフルホスト名をコピーする。
  2. 同じウィンドウで選択されたプロキシグループと実ノードが意図と一致しているか確認し、広い自動選択グループへ飲まれていればAWS_MCP側へ明示ルールで寄せる。
  3. YAML で DOMAIN 行が意図した順で評価されているかチェックリスト化し、RULE-PROVIDER が上書き同期で末尾に増殖していないか定期レビューの対象に入れる。
  4. ブラウザの Secure DNS と OS／ルータ側の名前解決を「Clash と二重運用しない」方向に整理し、必要なら TUN と DNS をセットでオンにした状態でもう一度 MCP ワークフローを試す。TUN ガイドと齟齬がある設定は削除する。
  5. 問題が残るときはHTTPS_PROXY=http://127.0.0.1:ポートだけを一時的にIDE子プロセスに渡す実験をし、効くなら「プロセス単位プロキシ未設定」側の是正に絞ってよいと断定する。

VS Code と Cursor でのプラグインレイヤーメモ

両者とも拡張ホスト設計やサンドボックスの違いから、同名の MCP 機能でも外向きプロセスツリーが微妙に異なります。IDE プラグイン プロキシという検索語の裏にあるのは、この差をユーザーが意識せずに済む状態をつくりたい、という欲求です。mihomo 側で AWS を独立グループ化しておけば、アプリ側の差分はログの読みやすさに吸収されます。

MCP がローカルの stdio で完結し、外向きHTTPSさえ張らないテストモードのみを使っている場合、この記事で述べているルール強化で改善しないことがあります。まずamazonaws.comまたはawsapps.comへの実接続ログがあるかだけ切り分けてください——ここまで来て初めてネットワーク層とAWS MCP Serverの話になります。

FAQ：よくある切り分け

Q. amazonaws.cn の中国リージョンは？ — 名前空間が別になります。.comと混ぜたルールセットに依存せず環境ごとに明文化してください。

Q. シングル VPC 内のサービスだけ遅い？ — 経路によっては VPC エンドポイントやクロスアカウント IAM 側の問題で、ワークステーション経由の HTTPS 出口とは無関係です。まず MCP／SDK が amazonaws.com へ外向きしているログがあるか切り分けてください。

まとめと次のアクション

AWS MCP Server が IDE と実アカウントを橋渡しする時代に、体感トラブルの多くは「どれかひとつのノードが悪い」より出口と名前解決の一貫性にあります。DOMAIN-SUFFIXでamazonaws.com・aws.amazon.com・SSO でのawsapps.comなどを明示し、Clash／mihomoの評価順とDNS／TUNを揃えると、「IAM だけ」「STS のみ」のようなピンポイントのタイムアウトが論理的なログの束に読み替えられるようになります。汎用の MCP とパッケージ取得は開発者分流、エディタ全体のモデル依存はCursor ガイドへ役割分担すると迷いません。

コマンドだけのチュートリアル一覧では、プラグインベンダーごとの差分まで追えないことがあり、公式ドキュメントの断片だけだと環境ごとの検証順が抜け落ちやすいです。ClashSource はビルドの取りまとげと構成の複利を意識した記事構成にしており、本稿も複製できるステップ順に寄せました。自分のワークフローに合わせてクライアント一式を試すときはClash クライアント無料ダウンロードページから環境別ビルドを選べば、複数構成の切り替え実験が短時間で済みます。mihomo 前提の細部はリリースごとに差が出ますが名前解決と評価順の骨格だけは長く効くため、ログを残したうえでの段階的なルール増殖がむしろ安全です。このあたりまで踏み込んだいっぽうでは、機能は多くてよいもののセットアップ項目が広く読み込みに時間がかかる統合環境とも対比になります。VPC と IAM の前提を崩さず、IDE 側のワークフローだけを試行錯誤できる状態を優先すると、開発の再現性は段違いに上がります。まだ環境構築の途中ならひとつの安定した構成に寄せてから MCP を足すほうが、因果の線が追いやすく、チームにも説明が通りやすくなります。必要になったタイミングで無料ダウンロードからクライアントを取って試してみてください。