Claude Managed Agents 병행 타임아웃? Anthropic·워크플로 도메인을 Clash(mihomo)로 분기하는 실측 가이드 (2026)

1. 왜 Managed Agents 트래픽이 "API만"과 다르게 느껴지나

단일 Anthropic API 클라이언트가 길게 스트리밍하는 상황과 달리, Managed Agents는 여러 실행 컨텍스트가 같은 시간대에 살아 있습니다. 한쪽은 대화형 패널, 다른 쪽은 백그라운드 작업·도구 호출, 또 다른 쪽은 상태 동기화를 위한 짧은 제어 요청이 겹칩니다. Code with Claude처럼 제품 표면이 넓어지면 브라우저·네이티브 런타임·터미널 보조 도구가 동시에 붙기 때문에, 사용자 네트워크에선 API 출국이 선형적으로 늘지 않고 "순간적으로 폭발"에 가깝게 튑니다.

이 패턴에서 Clash 분기는 단순히 해외 사이트를 여는 수준이 아니라, 동일 벤더라도 목적이 다른 호스트를 같은 정책 그룹에 묶어 지터와 낙오를 줄이는 작업에 가깝습니다. 지역·DNS 글에서 다룬 fake-ip 불일치가 있으면, 겉으로는 mihomo 로그에 찍힌 정책과 실제 클라이언트가 보는 경로가 달라져 "에이전트만 이상하다"는 체감으로 나타납니다.

2. 동시 출국이 늘 때 생기는 패킷·세션 패턴

병행 수가 늘면 다음이 한꺼번에 일어납니다. 첫째, 짧은 TLS 핸드셰이크가 수십 번 연속으로 열립니다. 둘째, 길게 열린 스트림이 있는 와중에 url-test 기반 그룹이 노드를 바꾸면 중간에 리셋이 끼어듭니다. 셋째, 어떤 프로세스는 HTTP_PROXY를 보고 어떤 프로세스는 무시해, 동일한 api. 호스트라도 출구 ASN이 갈립니다. 넷째, 운영 콘솔·통계·플래그 평가처럼 "부가"로 보이는 호출이 워크플로 가드레일과 겹치며 실패를 증폭합니다.

따라서 첫 진단은 "노드가 죽었나"보다 FQDN 목록을 시간순으로 펼쳐 보는 일이 됩니다. 다중 에이전트 IDE 글과 마찬가지로, 관리형 스택은 호스트 문자열이 늘어날수록 MATCH에 맡기기 어려워집니다. 최소한 api.anthropic.com과 운영·협업에 붙는 console.·claude.ai 계열을 한 블록으로 치는 습관이 안전합니다(팀 정책에 따라 세분화 가능).

3. Anthropic 가족 도메인을 한 덩어리로 묶기

실무에선 우선 다음 축을 표에 적습니다. (가) 모델 호출·스트림: api.anthropic.com 및 문서에 안내된 동일 계열. (나) 웹 제품·협업: claude.ai와 그 하위 리소스. (다) 운영 콘솔·과금·키: console.anthropic.com. (라) 기능 플래그·원격 설정 류로 자주 따라붙는 서브도메인이 있다면 별도 줄로 명시합니다. 팀마다 엔터프라이즈 게이트웨이를 쓰는 경우 커스텀 호스트가 추가되므로, 공유 문서의 FQDN을 그대로 DOMAIN 규칙에 옮깁니다.

여기까지는 Opus 4.7·API 분기와 크게 다르지 않습니다. 차이는 Managed Agents가 같은 사용자 세션에서 위 축을 더 촘촘하게 번갈아 부른다는 점입니다. 그래서 "API만 PROXY, 콘솔은 DIRECT"처럼 출구를 나눈 YAML이 오래돼 있으면, 짧은 제어 요청이 끊기면서 상위 오케스트레이터가 전체를 재시도하고 총 타임아웃에 도달하는 패턴이 납니다. 처음엔 과하게 넓게 묶고, 로그가 안정된 뒤에 보안·감사 이유로 쪼개는 편이 디버깅 비용이 적습니다.

4. Webhook: 인바운드와 개발자 장비의 아웃바운드

Webhook은 네트워크 관점에서 반으로 갈라집니다. 프로바이더가 사용자의 공개 URL로 밀어 넣는 인바운드와, 사용자 장비에서 그 URL로 도달 가능 여부를 확인하거나 헬스 체크를 보내는 아웃바운드입니다. 로컬에서 localhost나 사설 IP를 콜백으로 적어두었다면 Clash와 무관하게 실패할 수 있고, 공인 도메인을 쓰더라도 DNS·증명서·지리적 차단이 겹치면 에이전트 측 검증이 먼저 깨집니다.

따라서 API 출국 규칙만 맞추고 끝내지 말고, 콜백 URL의 HTTPS 경로가 개발자 머신에서 어떤 정책을 타는지도 같이 봅니다. 클라우드 게이트웨이라면 지역별 엔드포인트가 갈라질 수 있어, 패키지·GitHub와 동시에 깨질 때처럼 호스트 단위로 테스트하는 루틴이 필요합니다. 팀이 사내망에만 열어둔 검증 URL을 쓰는 경우엔 DIRECT 고정과 테스트 트래픽만 PROXY 하는 등, YAML 상단의 순서 자체가 운영 정책이 됩니다.

5. DNS·fake-ip·스니퍼로 규칙 매칭 확인하기

fake-ip를 켠 상태에서 스니퍼가 기대한 SNI를 못 잡으면, 화면에 보이는 도메인과 실제 분기 결과가 어긋납니다. Managed 스택은 짧은 연결이 많아 이 불일치가 빈번합니다. mihomo 대시보드나 /logs에서 A·AAAA 응답, 스니퍼 태그, 최종 정책을 같은 타임스탬프로 묶어 보세요.

OS가 DoH를 우회로로 쓰거나, 보안 DNS가 Clash 앞단에서 먼저 응답하면 증상은 "가끔만" 나타납니다. IPv6가 섞인 환경에선 AAAA 우선 붕괴도 흔합니다. 이미 Anthropic·DNS 글을 적용했다면, 이번엔 동시 다발 쿼리 구간만 따로 캡처해 비교하면 원인 분리가 빨라집니다.

6. Clash rules 스니펫 예시

아래는 개념 예시입니다. PROXY 자리는 팀의 select·url-test 그룹 이름으로 바꾸고, 엔터프라이즈 게이트웨이 FQDN이 있으면 맨 위에 두세요.

# Example — replace PROXY; add enterprise hostnames first
rules:
  - DOMAIN,api.anthropic.com,PROXY
  - DOMAIN-SUFFIX,anthropic.com,PROXY
  - DOMAIN-SUFFIX,claude.ai,PROXY
  - DOMAIN,console.anthropic.com,PROXY
  - # Optional: DIRECT for on-prem registry or internal webhooks before MATCH

GEOSITE 편의키를 쓸 수도 있지만, Managed Agents처럼 장애 비용이 큰 세션에선 명시적 DOMAIN이 예측 가능성을 줍니다. rule-providers를 팀 저장소로 버전 관리해, 콘솔 쪽 신규 호스트가 생겼을 때 PR로 추적하는 방식이 운영에 잘 맞습니다.

7. TUN·자식 프로세스·IDE 보조 런타임

IDE가 띄운 런타임은 시스템 프록시를 상속하지 않는 경우가 많습니다. TUN은 이런 프로세스에도 동일한 전송 경로를 강제하는 현실적인 해법이지만, 회사 보안 정책과 충돌할 수 있으니 IT 가이드를 먼저 확인하세요. 대안으로는 에이전트를 실행하는 셸에 HTTP_PROXY·HTTPS_PROXY·ALL_PROXY를 고정하고 NO_PROXY에 사내 레지스트리·콜백 검증용 호스트를 넣는 방법이 있습니다.

Cursor·개발 API 글에서 강조한 것처럼, "브라우저에선 되는데 터미널만 안 된다"는 문제는 출구가 아니라 프로세스 트리 상속에서 자주 시작됩니다. Managed 스택은 트리가 더 깊어지므로, 런타임 실행 스크립트 한 줄만 바꿔도 증상이 바뀌는지 먼저 확인하는 편이 빠릅니다.

8. 로그 기반 실측 런북

첫째, 실패 직후 30초 구간만 로그를 내보내 anthropic·claude 문자열이 포함된 줄만 필터링합니다. 둘째, 각 줄의 정책 이름이 기대한 그룹인지, 예기치 않게 DIRECT로 떨어졌는지 확인합니다. 셋째, 동일 시각대에 Webhook 검증 URL 호출이 있는지 찾습니다. 넷째, 정책 그룹이 url-test라면 전환 이벤트가 스트림 중에 끼었는지 봅니다. 다섯째, DNS 모드를 fake-ip에서 redir-host로 임시 전환해 증상이 사라지는지 A/B 합니다.

이 런북은 Anthropic뿐 아니라 다른 벤더의 코딩 에이전트에도 그대로 이어집니다. 다만 Managed Agents는 호출 밀도가 높아 로그 샘플이 금방 커지므로, 시간창을 좁히는 습관이 필수입니다.

9. 자주 묻는 질문