증상 패턴 · 콘솔은 열리는데 에이전트 도구만 끊길 때
검색 의도를 한 줄로 요약하면, “AWS에서 제공하는 MCP 관련 관리 화면이나 Agent Toolkit 흐름을 쓰는데 브라우저나 터미널 쪽 연결 시간 초과가 난다”는 절차를 발견했다가 원인을 더 좁히고 싶은 경우입니다. 실사용에서는 console.aws.amazon.com 본문은 빠른데 특정 서브 메뉴만 흰 화면에 머무르거나, 설명 문서에 나온 예시 REST 호출만 TLS 핸드셰이크에서 멈추는 식으로 갈라집니다. IAM·STS·리전별 제어 플레인 엔드포인트는 이름이 길고 파편화되어 있어, 한 줄짜리 RULE-SET이 모든 하위 호스트를 포괄하지 못했다가 DIRECT로 빠지는 일이 잦습니다. 사용자 입장에서는 “대시보드 타임아웃” 한 단어로 몰아 적지만, 실제 패널 로그에는 서로 다른 FQDN이 연속으로 찍히는 경우가 대부분입니다.
또 Model Context Protocol 클라이언트는 로컬 프로세스가 서버에 붙는 경로가 IDE·런타임·언어별로 달라서, 웹과 동일한 프록시 전제를 공유하지 않을 수 있습니다. 여기에 브라우저 Secure DNS·운영체제 DNS·코어 FakeIP가 동시에 개입하면 “규칙은 맞는데 시간만 오래 걸린다”는 착시가 생깁니다. TUN 모드로 패킷을 커널 한 축으로 모은 뒤 관측한 호스트 묶음을 규칙 블록 상단에 두는 방식이 가장 재현성이 높습니다. 기초 절차는 Clash Verge Rev TUN 가이드와, 스택 선택은 gvisor와 system 비교 글을 같은 주차에 읽어 두면 변수가 줄어듭니다.
AWS MCP Server·Agent Toolkit 맥락에서 무엇이 동시에 움직이는지
AWS Agent Toolkit은 문서·샘플·CLI 래퍼·IDE 확장이 한 번에 등장하는 흐름이라, 첫날부터 콘솔 자바스크립트 번들과 로컬 명령행 도구가 같은 계정 권한 스코프를 두드립니다. AWS MCP Server처럼 호스티드 형태로 제공되는 MCP 게이트는 게이트웨이 URL·인증 흐름·세션 갱신 호스트가 문서 시기마다 조정될 수 있습니다. 따라서 글에 적힌 문자열을 그대로 복사하기보다, 본인 장비에서 실패한 시각의 네트워크 탭과 Clash 연결 패널에 나온 이름을 채집하는 습관이 더 안전합니다. 제품 기능 비교·가격·지원 SLA는 공식 공지를 따르고, 이 문서는 순수하게 경로 정렬만 다룹니다.
범위와 준수 사항(조직 정책·규제)
기업 계정에서는 프록시 우회 자체가 정책 위반이 될 수 있고, API 키·세션 토큰을 외부에 노출하면 즉시 사고로 이어집니다. 이 글은 개인 학습·허가된 테스트 계정을 전제로 하며, 로그를 공유할 때는 식별자를 마스킹해야 합니다. 클라우드 제공자가 제시하는 데이터 처리 위치·규정 준수 가이드는 사용자 책무입니다. 네트워크 경로를 바꾸기 전에 보안·네트워크 팀 승인을 받으세요.
11단계: 실패 순간 호스트 목록 만들기
먼저 “실패한 한 순간의 타임라인”을 만듭니다. 브라우저 개발자 도구 네트워크 탭에서 지연·실패한 요청의 호스트를 복사하고, 동일 시각 Clash 연결 목록에 같은 이름이 있는지 확인합니다. 터미널에서는 AWS CLI나 예제 스크립트의 --debug 출력에서 엔드포인트 문자열을 따로 적습니다. IAM 콘솔 로그인 직후에만 보이는 리디렉션 체인도 별도 행으로 남기세요. 이렇게 모은 목록이 이후 분류 규칙의 근거가 됩니다.
# Example — replace host; verbose TLS helps compare with panel timeline
curl -v -m 25 https://console.aws.amazon.com/
출력의 TCP·TLS 구간 시간을 메모해 두면 DNS만 바꿨을 때와 규칙 순서만 바꿨을 때 차이를 분리하기 쉽습니다. 로그 읽기 흐름은 connection reset 시간축 분석을 참고하세요.
22단계: Clash TUN 켜기 — 브라우저·CLI 동시 수용
TUN 모드는 애플리케이션이 시스템 프록시를 인식하지 못하더라도 동일한 라우팅 절차를 밟게 해 줍니다. Agent Toolkit 예제가 내부적으로 gRPC·HTTP/2·HTTP/3를 섞어 쓰는 경우, 특정 프로토콜만 규칙 밖으로 새는 증상이 감소합니다. 사내 VPN과 충돌하면 TUN을 켤 수 없을 수도 있는데, 이때는 보안 팀이 허용한 범위 안에서 예외 대역과 순서를 재정리해야 합니다.
Windows 초기 설치부터 다시 밟고 싶다면 Clash Verge Rev Windows 설치 글과 함께 변수를 줄이세요.
33단계: AWS·인증 호스트 묶음을 분류 규칙 상단에
아래는 개념 스케치입니다. 실제 프로파일에는 더 많은 RULE-SET이 있으므로, 관측 목록을 별도 YAML 조각으로 떼어 Mixin 병합으로 얹고 트리 상단에서 먼저 매칭되게 하는 편이 안전합니다. 무작정 amazonaws.com 전체를 한 그룹에 넣으면 내부 전용 엔드포인트까지 같이 끌려와 문제가 될 수 있으니, 관측된 호스트 기준으로 시작하세요.
# Sketch — replace PROXY_AWS; verify order vs RULE-SET / MATCH
rules:
- DOMAIN-SUFFIX,console.aws.amazon.com,PROXY_AWS
- DOMAIN-SUFFIX,signin.aws.amazon.com,PROXY_AWS
- DOMAIN-SUFFIX,amazonaws.com,PROXY_AWS
- DOMAIN-KEYWORD,cloudfront,PROXY_AWS
- MATCH,DIRECT
참고: 마지막 줄 MATCH와 조직 정책 충돌이 없는지 확인하세요. 내부망 전용 호스트가 같은 접미사 공유 대역에 있으면 예외를 fake-ip-filter나 더 구체 규칙으로 분리합니다.
콘솔 호스트와 API 클라이언트 호스트를 나눌지
초기 디버깅에서는 관측 목록 전체를 한 정책 그룹에 묶는 편이 빠릅니다. 이후 컴플라이언스 때문에 웹 UI만 다른 노드를 써야 한다면 도메인을 분리하되, 결제·계정 전환 리디렉션이 새 호스트를 끌고 오는지 다시 패널로 검증하세요. 다른 벤더의 웹·API 분리 패턴은 Anthropic 웹·API 분할 글과 같은 축으로 읽을 수 있습니다.
44단계: DNS·FakeIP·DoH·스니퍼 한 축으로
브라우저 DoH와 Mihomo DNS가 동시에 켜지면, 화면에는 같은 문자열이 보여도 패널 첫 줄과 실제 IP 대역이 달라집니다. fake-ip-filter·redir-host·HTTPS 스니퍼는 한 번에 하나만 바꾸고 로그 블록을 끊어 가며 비교하세요. 이론 정리는 Meta 코어 DNS 유출 방지와 스니퍼 가이드 순이 효율적입니다.
리전을 잘못 고른 채로 이름만 바로 잡아도 체감 지연이 크게 줄어드는 경우가 있어, DNS 결과와 선택한 리전 엔드포인트가 같은지 콘솔 상단 리전 표시와 교차 확인하세요. 지리적으로 먼 리전을 고정해 둔 상태에서 Agent Toolkit 샘플을 돌리면 패널에만 정상처럼 보이고 실제 왕복 시간은 길어질 수 있습니다.
55단계: url-test·노드 전환과 장시간 세션
긴 스트리밍 응답이나 여러 단계 OAuth 리디렉션은 짧은 지터에도 사용자 설정 읽기 시간 상한과 맞닿습니다. url-test가 지나치게 자주 최선 노드를 바꾸면 세션이 끊긴 것처럼 보이기도 하니, 문제를 좁히는 동안 selector로 단일 노드를 고정하세요. 전환 정책 자체를 손보고 싶다면 url-test·fallback 글을 대조합니다.
AWS CLI·언어 SDK·IDE 확장까지 동일 시나리오로
로컬 머신·CI·원격 개발 컨테이너마다 HTTPS_PROXY 유무와 기본 라우팅이 달라 똑같은 스크립트가 다른 경로를 탑니다. 각 환경에서 TUN 켠 경우와 끈 경우만 대조해 보고, 동일하게 맞춰야 할 것은 DNS 응답인지 규칙 첫 매칭인지 순서대로 확인하세요. 레지스트리·패키지 설치까지 겹친다면 Google Agents CLI의 npm·uv 타임아웃 글이 같은 맥락입니다.
Model Context Protocol 클라이언트와 호스티드 MCP 간 DNS 일치
로컬에서 돌아가는 MCP 클라이언트가 터널 끝의 게이트웨이 이름을 재귀적으로 풀 때, 브라우저와 다른 캐시·다른 DoH 업스트림을 타면 첫 연결만 실패하는 패턴이 나옵니다. 이때는 IDE에서 띄운 내장 터미널과 외부 터미널 앱이 동일한 네트워크 네임스페이스를 쓰는지, 컨테이너 내부에서 호스트 DNS가 무엇인지까지 확인하는 편이 낫습니다. MCP 일반론은 MCP·Clash 분류·DNS 글에 더 길게 정리되어 있습니다.
체크리스트 — 대시보드 타임아웃처럼 보일 때
- 실패 로그와 패널에 나온 호스트를 한 목록으로 모았다.
- 각 호스트의 첫 분류 결과가 패널 시간축과 일치한다.
- TUN·VPN·제로 트러스트 순서 충돌을 제거했다.
- 브라우저 DoH, OS DNS, 코어 DNS 교차 간섭을 줄였다.
- 리전·엔드포인트 선택이 DNS 결과와 맞다.
- 디버깅 중에는 url-test 과도 전환 대신 selector 고정을 썼다.
자주 묻는 질문
콘솔만 열리고 Agent Toolkit API만 타임아웃처럼 보여요
화면마다 다른 하위 호스트가 순서대로 호출되고, 그중 일부만 DIRECT로 빠지거나 DNS 응답만 달라질 때 흔합니다. 터미널 클라이언트는 시스템 프록시를 무시하는 경우도 있어 API만 끊긴 것처럼 느껴질 수 있습니다. 연결 패널에서 호스트별 첫 줄과 QUIC(HTTP/3) UDP 줄을 함께 보세요.
TUN을 켰는데도 IAM·계정 전환 화면만 간헐적으로 끊겨요
리디렉션 체인 중 일부만 다른 출구를 타면 쿠키 도메인이 엇갈립니다. 관측한 리디렉션 호스트 전부를 같은 정책 그룹으로 올리고 다시 시도하세요.
브라우저 Secure DNS와 패널 이름이 안 맞아요
브라우저 전용 이름 해석 줄을 끄거나 코어와 동일 업스트림으로 맞추고, fake-ip-filter를 순서대로 재조정하세요.
RULE-SET에 이미 클라우드 도메인이 있는데도 안 먹어요
사용자 블록이 아래에 묻히거나 더 앞선 RULE-SET이 다른 출구를 먼저 잡는 경우입니다. 트리 전체를 텍스트로 스냅샷 찍고 순서를 재배치하세요.
준수: 액세스 키·세션 토큰·샘플 응답 본문은 공개 채널에 붙여 넣지 마세요. 회사 보안·로깅 정책을 위반하면 안 됩니다.
맺음말
AWS MCP Server와 AWS Agent Toolkit은 Model Context Protocol·에이전트 빌드를 한 번에 소개하지만, 네트워크 레이어에서는 여전히 콘솔 자바스크립트·제어 플레인 API·로컬 런타임이 서로 다른 호스트 묶음을 밟습니다. “대시보드만 느리다”는 체감도 패킷 로그를 펼치면 대부분 DNS·분류 순서·프록시 인식 불일치의 조합으로 설명됩니다. TUN으로 경로를 통일하고 관측 목록을 규칙 상단에 고정한 뒤 DoH·FakeIP·스니퍼를 한 축에서 맞추면 재현성이 크게 올라갑니다.
범용 프록시 도구 중에는 YAML을 매번 손으로 길게 편집하거나 프로그램마다 환경 변수를 따로 두어야 해 실수 여지가 큽니다. Clash 계열 클라이언트는 GUI에서 프로파일과 규칙 트리를 바로 열람하면서 Mihomo 기능과 결합해 TUN, DNS, 필요 시 PROCESS 분기까지 한 제품군에서 실험할 수 있어, 클라우드 콘솔과 로컬 에이전트 도구를 동시에 왕복 테스트하는 흐름에 시간을 아껴 줍니다. 아직 사용해 보지 않았다면 Clash 클라이언트를 무료로 받아 위 순서대로 AWS 관련 화면과 툴킷 호출을 다시 돌려 보고, 동일 계정에서 응답 곡선이 정렬되는지 비교해 보시길 권합니다.