Cursor 3에서 병렬 에이전트(Agents Window)가 자주 타임아웃될 때: 모델 API·Cursor 도메인을 Clash(mihomo)로 분기해 안정화하기 (2026)

1. 병렬 에이전트가 네트워크에 추가로 걸어오는 부담

단일 채팅과 달리 병렬 에이전트는 파일 읽기·명령 제안·도구 호출·모델 응답을 짧은 시간에 겹쳐 요청합니다. 서로 다른 하위 작업이 다른 서브도메인이나 API 풀을 밟으면, 클라이언트 입장에서는 「한 번에 많이」가 아니라 「서로 다른 출구로 흩어져」 보입니다. Clash에서 GEOIP나 넓은 MATCH가 먼저 승리하면, 어떤 호스트는 DIRECT로, 어떤 호스트는 프록시로 나가 cookies·TLS 세션이 어긋난 것처럼 보이기도 합니다.

또한 장시간 응답을 전제로 하는 스트리밍은 순간적인 패킷 손실·지터에 더 민감합니다. url-test 계열 그룹이 수 분마다 최저 지연 노드를 바꾸는 프로필이면, 첫 에이전트는 빠르게 끝나도 두 번째 작업이 다른 출구로 붙었다가 API 타임아웃으로 끊기는 패턴이 나올 수 있습니다. 문제가 앱 버전만의 이슈처럼 보이기 전에, mihomo 화면의 연결 정보가 같은 작업 단위에서 일관된 아웃바운드를 가리키는지 확인하는 게 1차 관문입니다.

2. 증상: Agents Window만 유독 불안정할 때

흔한 신호는 다음과 비슷합니다. 인라인 완성은 대체로 되는데 에이전트 패널만 반복 실패한다. 첫 작업은 성공하고, 동시에 띄운 두 번째 탭만 API 오류를 낸다. 재시도할 때마다 응답 시간이 크게 달라진다. 이런 경우 계정·쿼터 이슈를 배제한 뒤(조직 정책·결제·모델 가용성), 트랜스포트 층에서 경로 분열을 의심합니다.

특히 Windows·macOS에서 Electron 자식 프로세스·샌드박스 헬퍼가 시스템 프록시를 다르게 물려 받는 환경이라면, 터미널의 curl과 IDE 패널의 결과가 어긋날 수 있습니다. TUN을 켠 구성은 관측이 쉬운 대신, 다른 VPN·보안 제품과 경로가 겹치면 오히려 UDP·ICMP 처리에서 변수가 생깁니다. Windows TUN·UWP 글의 예외 정리를 함께 보시면 재현 조건을 좁히기 쉽습니다.

3. Cursor 서비스 vs 모델 게이트웨이 호스트

실무에서는 두 바구니로 나눠 생각하면 덜 헷갈립니다. 첫째, Cursor 브랜드 인프라: 인증·업데이트·동기화·에디터 본체와 연관된 호스트(예: cursor.com 접미, API 형태의 서브도메인 — 버전에 따라 다름). 둘째, 실제 모델 API 또는 중계: 설정에 따라 api.openai.com, Anthropic 계열, 혹은 다른 호스트로 향합니다. 목록을 외우기보다 실패 순간 로그에 찍힌 이름을 근거로 삼으세요.

공급자별 세부는 기존 가이드를 합성하는 편이 안전합니다. 예를 들어 OpenAI 측 경로는 ChatGPT 라우팅, Anthropic은 Claude·DNS 글의 함정(fake-ip 등)을 참고해 호스트 줄을 확장합니다. OpenRouter 같은 집약형 게이트웨이를 쓰면 호스트 수는 줄지만, 실패 시 원인 후보가 게이트웨이 한 줄로 모이므로 로그 해석이 중요해집니다.

DOMAIN-KEYWORD,cursor처럼 과하게 넓은 규칙은 다른 트래픽을 끌어와 운영 사고를 만듭니다. 접미·로그에 근거한 DOMAIN-SUFFIX부터 올리고, 모호할 때만 키워드를 신중히 추가하세요.

4. 정책 그룹·규칙 순서·동시성

전용 proxy-groups를 하나 두고 이름을 🧠 Cursor+Agents처럼 직관적으로 밝혀 두면, GUI에서 추적하기 쉽습니다. 대화형 코딩에 맞춰 저지연을 택하되, 병렬 작업에서는 노드 고정이 체감 안정성에 더 기여하는 경우가 많습니다. 자동 테스트형 그룹과 페일오버 조합은 url-test·fallback 가이드의 논지를 그대로 가져오되, 헬스체크 URL은 실제로 신뢰하는 엔드포인트를 쓰는 편이 낫습니다.

규칙 순서는 여전히 조용한 살인자입니다. IDE·모델 호스트용 DOMAIN·DOMAIN-SUFFIX 줄을 넓은 지역 분기보다 위에 두지 않으면, 로그상으로는 맞는 것 같은데 실제 매칭은 다른 줄이 가져가는 상황이 반복됩니다. 커뮤니티 규칙 프로바이더를 여러 개 합쳤다면, 같은 호스트를 서로 다른 파일에서 덮어쓰지 않는지도 함께 봐야 합니다.

5. 예시 YAML: 에이전트 친화적 규칙 블록

아래는 illustration입니다. 그룹명·노드명·추가 호스트는 환경에 맞게 바꾸고, 실제 패치 전 라우팅 참고서의 우선순위 설명을 다시 확인하세요.

proxy-groups:
  - name: 🧠 Cursor+Agents
    type: select
    proxies:
      - Stable-01
      - Stable-02
      - DIRECT

rules:
  # Cursor-branded hosts — extend from live logs
  - DOMAIN-SUFFIX,cursor.com,🧠 Cursor+Agents
  - DOMAIN-SUFFIX,cursor.sh,🧠 Cursor+Agents

  # Model gateways — replace with hosts you actually see
  - DOMAIN-SUFFIX,openai.com,🧠 Cursor+Agents
  - DOMAIN-SUFFIX,anthropic.com,🧠 Cursor+Agents
  - DOMAIN-SUFFIX,openrouter.ai,🧠 Cursor+Agents

  # Optional: pin Electron app (binary names differ by OS)
  # - PROCESS-NAME,Cursor,🧠 Cursor+Agents

  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

구독 갱신 시 머지가 꼬이지 않도록 구독 가져오기 문서의 패치 순서를 함께 점검하세요. 에이전트 전용 블록은 가능하면 한 파일에 모아 중복을 피하는 편이 디버깅에 유리합니다.

6. DNS·fake-ip·DoH 정렬

fake-ip를 쓰면 규칙 매칭은 수월해지지만, 시스템·브라우저·앱이 코어 밖에서 별도 DoH로 해석하면 「도메인 줄은 맞는데 트래픽은 다른 IP로 간다」 류의 불일치가 생깁니다. fake-ip 대 redir-host 글의 흐름을 먼저 이해한 뒤, 특정 접미를 정책 리졸버로 보내는 nameserver-policy를 검토하세요.

# Example only — match to your resolvers & privacy policy
dns:
  nameserver-policy:
    "+.cursor.com":
      - https://dns.google/dns-query
    "+.openai.com":
      - https://dns.google/dns-query

7. 연결 로그로 호스트·아웃바운드 확정하기

Agents Window에서 문제가 난 직후, 코어 로그에 기록된 호스트·규칙 타입·선택된 프록시를 한 줄씩 적습니다. 같은 시나리오를 두 번 재현했을 때 아웃바운드 이름이 바뀌면, 그룹 타입·헬스체크·수동 선택 상태를 우선 의심합니다. 반복되는 타임아웃이 특정 호스트에만 붙어 있다면, 그 호스트를 YAML 상단으로 끌어올린 뒤 매칭 여부를 다시 확인하세요.

HTTP 상태 코드가 아니라 소켓 단계에서 멈춘다면, 노드 품질·중간 방화벽·UDP 경로를 보는 편이 맞습니다. 이때 단일 채팅만 테스트하지 말고, 의도적으로 두세 개의 에이전트 작업을 동시에 돌려 연결 수를 늘려 보세요. 병렬 상황에서만 드러나는 협착은 라우팅 문제일 때가 많습니다.

8. 실측 체크리스트

아래 순서로 훑으면 대부분의 「규칙은 맞는 것 같은데」 문제가 걸러집니다. (1) 실패 직후 로그의 호스트 이름을 적는다. (2) 해당 호스트가 의도한 줄에 매칭됐는지 확인한다. (3) Proxies 화면에서 그룹이 바라보는 노드가 세션 중 바뀌지 않는지 본다. (4) 시스템·앱 DoH를 잠시 끄거나 코어와 같은 리졸버로 맞춰 재현성을 비교한다. (5) TUN·다른 VPN을 모두 끈 베이스라인을 만든다.

9. 자주 묻는 질문