IDE에서 AWS MCP Server가 타임아웃될 때: 2026 Clash·Mihomo로 안정적인 AWS API 경로 잡기

2026년 AWS MCP Server와 IDE 프록시가 겹치는 지점

AWS MCP Server와 이를 감싸는 Agent Toolkit 계열은 2026년 들어 공식 문서·샘플과 함께 Cursor·Visual Studio Code 같은 편집기에서 바로 붙이기 쉬워졌습니다. 흐름은 단순해 보여도, 실제 네트워크는 sts.amazonaws.com에서 임시 자격 증명을 받고, ec2.ap-northeast-2.amazonaws.com처럼 리전별 호스트로 API를 두드리며, AWS 콘솔 로그인이나 IAM Identity Center(SSO) 리다이렉트가 브라우저·로컬 콜백을 오갈 때 또 다른 도메인 묶음을 엽니다. 한 호스트만 느리거나 DIRECT로 떨어져도 전체 MCP 세션이 끊어져 보일 수 있습니다.

이 글은 범용 MCP·툴체인 분할 가이드를 대체하지 않고, AWS API 분할과 IDE 플러그인 프록시가 만나는 좁은 구간만 깊게 다룹니다. 회사 정책·약관·현지 법에 어긋나는 우회는 다루지 않으며, 이미 허용된 개발 환경에서 연결 품질을 다룹니다.

범용 MCP 글과 무엇이 다른가

npm·GitHub·범용 클라우드 API를 한꺼번에 묶는 설정만으로는 부족한 이유는, AWS가 서비스·리전·엔드포인트 스타일마다 호스트 패턴을 촘촘히 쓰기 때문입니다. 예를 들어 STS는 글로벌 엔드포인트가 기본이고, EC2·Lambda·S3는 리전 접두사가 붙습니다. IAM Identity Center를 쓰면 *.awsapps.com·조직별 로그인 도메인이 추가로 등장합니다. MCP가 “리스트 버킷 한 번”만 호출하는 것이 아니라 체인된 неск 단계 API를 밟으면, 중간 한 레그만 잘못된 전략으로 빠져 전체가 ETIMEDOUT처럼 보일 수 있습니다.

편집기 자체 트래픽은 Cursor·확장 마켓 분할 가이드와 겹칩니다. 그러나 AWS MCP가 띄운 자식 프로세스는 별도로 HTTPS를 열기 때문에, IDE가 시스템 프록시를 따르더라도 환경 변수나 런타임 설정에 따라 프록시 우회가 섞이면 증상이 간헐적으로만 납니다.

증상 세 덩어리로 나누기

현장에서는 다음처럼 나누면 원인 추적이 빨라집니다. 첫째, 자격 증명·호출자 식별(GetCallerIdentity, AssumeRole 계열)만 실패하면 STS·글로벌 IAM 게이트웨이 레그를 의심합니다. 둘째, 특정 리전 작업만 실패하면 해당 리전 amazonaws.com 호스트가 다른 그룹으로 빠졌는지 봅니다. 셋째, 브라우저 로그인 창은 열리는데 MCP 쪽 콜백·토큰 교환이 멈추면 signin.aws.amazon.com·console.aws.amazon.com·SSO 도메인과 로컬 루프백이 섞인 경로를 분리합니다. 이 세 덩어리는 서로 다른 DOMAIN-SUFFIX 규칙 줄로 잡는 편이 로그 해석에 유리합니다.

참고: 실제 호스트 목록은 사용 중인 AWS 서비스·리전·SSO 여부에 따라 달라집니다. 아래는 빈번한 패턴이며, 확정은 항상 Clash 연결 로그와 IDE·MCP 디버그 출력으로 보강하세요.

자주 보는 AWS·로그인 도메인 패턴

AWS API: amazonaws.com과 aws.amazon.com을 포괄하는 접미사 규칙이 기본 축입니다. 리전이 많을수록 *.amazonaws.com 한 줄이 넓게 먹지만, 반대로 회사 정책상 특정 리전만 프록시해야 한다면 DOMAIN-SUFFIX,ec2.ap-northeast-2.amazonaws.com처럼 좁히는 편이 안전합니다. 로그인·콘솔: signin.aws.amazon.com, console.aws.amazon.com은 브라우저와 IDE가 동시에 건드릴 수 있어 별도 그룹으로 두면 “콘솔은 되는데 MCP 인증만 안 된다”를 빠르게 갈라 냅니다.

SSO·파티션: IAM Identity Center를 쓰면 조직 발급 도메인이 추가됩니다. GovCloud·중국 파티션은 호스트 접미사가 달라 같은 RULE-SET을 썼을 때 빈틈이 생길 수 있으니, 실패 로그에 찍힌 FQDN을 그대로 화이트리스트에 올리는 습관이 좋습니다. 패키지 설치: MCP 서버가 Node·Python 의존성을 끌어오면 범용 MCP 글의 레지스트리 줄과 함께 봐야 합니다.

proxy-groups와 rules 축약 예시

아래는 개념 예시입니다. 구독에 있는 실제 proxies 이름으로 바꾸고, 로그에 보인 호스트를 한 줄씩 추가하세요. AWS-API-Core는 지연에 덜 민감한 호출에, AWS-Login은 브라우저 리다이렉트와 쿠키 경로에 맞는 노드풀에 연결하는 식으로 나누는 경우가 많습니다.

YAMLproxy-groups:
  - name: "AWS-STS"
    type: url-test
    url: "https://sts.amazonaws.com"
    interval: 120
    tolerance: 50
    proxies:
      - DIRECT
      # 저지연·안정 노드들 ...

  - name: "AWS-API-Core"
    type: select
    proxies:
      - DIRECT
      # 리전 API용 ...

  - name: "AWS-Login"
    type: select
    proxies:
      - DIRECT
      # 로그인·콘솔 리다이렉트용 ...

rules:
  - DOMAIN-SUFFIX,sts.amazonaws.com,AWS-STS
  - DOMAIN-SUFFIX,signin.aws.amazon.com,AWS-Login
  - DOMAIN-SUFFIX,console.aws.amazon.com,AWS-Login
  - DOMAIN-SUFFIX,amazonaws.com,AWS-API-Core
  - DOMAIN-SUFFIX,aws.amazon.com,AWS-Login
  # GEOIP·MATCH 등 기존 프로필보다 위에 두었는지 최종 확인

amazonaws.com 줄을 너무 아래에 두면, 넓은 GEOIP나 다른 RULE-SET이 먼저 잡아 STS만 다른 정책으로 나가는 일이 생깁니다. 규칙 순서는 규칙 분할 가이드에서 말한 대로 “위에서 아래 첫 일치”가 전부입니다.

실측 절차: 로그부터 TUN까지

이어지는 단계는 그대로 따라 하면 같은 증상을 재현·축소할 때 유리합니다. 각 단계에서 바뀐 호스트명을 메모해 두면 이후 Mihomo 프로필에 반영하기 쉽습니다.

  1. MCP를 실행한 뒤 Clash 로그에서 실패 직전의 목적지 호스트와 매칭된 정책·그룹 이름을 적습니다. GLOBAL이나 의도와 다른 그룹이면 규칙 순서를 의심합니다.
  2. 같은 머신에서 curl -v https://sts.amazonaws.com와 문제가 된 리전 엔드포인트(예: https://ec2.ap-northeast-2.amazonaws.com)를 번갈아 찍어 TLS·지연을 비교합니다. IDE만 실패할 때는 프록시 환경 변수 차이를 봅니다.
  3. enhanced-mode: fake-ip를 쓰면 fake-ip-filter에 STS·콘솔 호스트가 필요한지 점검합니다. 이미 IP로 붙는 클라이언트는 DOMAIN-SUFFIX가 스킵될 수 있습니다.
  4. 시스템 프록시와 Clash mixed-port가 맞는지, VS Code·Cursor가 “프록시 사용” 설정을 따르는지 확인합니다. 터미널에서 MCP를 띄울 때는 HTTPS_PROXY 유무가 브라우저와 다를 수 있습니다.
  5. 여전히 엇갈리면 TUN 모드로 전환해 커널 경로가 일관되게 Clash를 통과하는지 비교합니다. UDP·분할 DNS까지 겹치면 증상이 바뀌는지가 핵심 힌트입니다.

주의: 출처가 불분명한 원격 RULE-SET은 예기치 않은 라우팅을 넣을 수 있습니다. 프로덕션 계정·장기 자격 증명이 있는 머신이라면 신뢰 가능한 구독과 로컬 커스텀 규칙을 우선하세요.

자주 묻는 질문

Q. 브라우저에서는 AWS 콘솔이 되는데 IDE MCP만 타임아웃됩니다. A. 브라우저와 MCP 자식 프로세스의 프록시 경로·DNS가 다르면 같은 계정이라도 서로 다른 정책으로 나갈 수 있습니다. 로그에서 실제 호스트와 매칭 그룹을 확인하고, STS·리전·로그인 줄을 콘솔 트래픽과 분리해 보세요.

Q. Clash Verge에서도 동일한가요? A. Clash Verge는 Mihomo 코어를 쓰는 경우가 많아 proxy-groups와 rules 문법이 같습니다. macOS·Windows에서 시스템 확장·TUN 권한만 맞추면 본문 절차를 그대로 옮길 수 있습니다.

마무리

AWS MCP Server는 IDE 안의 짧은 설정으로 끝나지 않고, 그 뒤에 STS·리전 API·로그인 리다이렉트가 줄줄이 붙습니다. 이 축을 Clash·Mihomo로 나누면 “MCP만 간헐적으로 죽는다”는 증상을 훨씬 빠르게 좁힐 수 있습니다. 한 그룹에 모두 몰면 로그만 길어지고 원인은 흐려집니다.

상용 일체형 VPN·단순 브라우저 전용 확장은 IDE 자식 프로세스와 리전별 AWS 호스트까지 일관되게 다루기 어렵고, 세분화된 호스트 묶음을 표현하기도 까다롭습니다. 반면 ClashSource가 안내하는 Clash·Mihomo 계열 프로필은 DOMAIN-SUFFIX·전략 그룹·DNS를 한 파일에서 묶어 쓸 수 있어, 2026년처럼 IDE 플러그인과 퍼블릭 클라우드 API가 겹치는 환경에 잘 맞습니다. 설명은 짧게 두고 규칙 상호작용을 스스로 보는 연습이 필요하다는 점만 기억하면 됩니다.

설치와 프로필 반영 절차는 문서·튜토리얼을 참고하시고, 분할을 적용할 준비가 되었다면 Clash를 무료로 다운로드한 뒤 본문 예시를 바탕으로 proxy-groups와 rules만 조정해 보시길 바랍니다. AWS MCP가 안정되면 IDE 전체 자동화 흐름이 한결 덜 끊깁니다.