병렬 세션 지연? Clash CLI 안정 2026

Agent View·병렬 세션이 네트워크를 다르게 만드는 이유

Agent View는 이름 그대로 에이전트 중심으로 화면과 로그 스트림을 묶어 보여 줍니다. 개발자 입장에서는 편하지만 네트워크 입장에서는 “한 사용자의 단일 세션”이 아니라 여러 독립적인 대화 컨텍스트가 동시에 살아 있는 상태에 가깝습니다. 각 컨텍스트가 도구 호출을 넣으면 짧은 HTTPS 요청이 연속으로 이어지고, 긴 응답은 스트림으로 유지됩니다. 여기에 로컬 레포에서 돌아가는 npm install이나 릴리스 아카이브 다운로드가 겹치면, 표면적으로는 “UI가 멈춘다”로 보이지만 실제로는 단일 노드의 큐 길이와 TCP 창 한계가 UI 스레드와 무관하게 증상을 키우는 경우가 많습니다.

병렬 세션은 또 다른 의미에서도 부담을 줍니다. 클라이언트 구현이 세션마다 별도의 연결 풀을 갖거나 핸드셰이크를 반복하면, 동일한 API 호스트라도 동시간대에 여러 TLS 세션이 열립니다. 회선이 좁거나 노드가 혼잡하면 체감 지연은 선형이 아니라 폭발적으로 늘어납니다. 그래서 “웹 Claude·Anthropic 라우팅 글에서 넣은 규칙을 그대로 복사했는데도 Agent View에서는 통하지 않는다”는 경험이 나옵니다. 웹 세션은 탭 전환과 사용자 입력 템포가 완충 역할을 하지만, 에이전트는 사람 손이 끼어들기 전에 연속 호출을 밀어 넣기 때문입니다.

동시 스트림: 여러 패널에서 장시간 응답을 유지하면 단일 노드의 장기 연결 수가 빠르게 올라갑니다.
도구 호출 버스트: 파일 검색·테스트 실행 같은 도구가 짧은 요청을 한꺼번에 만들면 RTT 지터에 민감해집니다.
외부 의존성: 같은 작업 안에서 registry.npmjs.org와 GitHub 오브젝트 스토리지가 섞이면 서로 다른 최적 노드가 필요합니다.
터미널 경로: 에디터 UI는 시스템 프록시를 따르지만 CLI 자식 프로세스는 DIRECT로 새는 경우가 반복됩니다.

한 줄 요약

병렬 세션은 트래픽을 “겹치게” 만듭니다. 한 줄 MATCH로 모든 호스트를 같은 노드에 몰면 스트림과 fat download가 서로 발목을 잡습니다. 목적지 목적에 따라 그룹을 나누세요.

MCP 중심 글과 무엇이 다른가요

Claude Code·MCP 글은 Model Context Protocol 서버·카탈로그·OAuth처럼 도구 레이어 주변 호스트를 정확히 짚는 데 유리합니다. 반면 이 글은 UI 패턴인 Agent View와 병렬 세션이 만드는 동시 연결 폭증과 그에 따른 노드 운용을 설명합니다. 두 글은 배타적이 아니라 같은 규칙 파일 위에서 서로 다른 변수를 조명합니다. MCP 호스트가 추가되면 MCP 글의 체크리스트를 덧붙이고, 동시에 패널을 여러 개 켠 상태에서만 증상이 커지면 이 글의 경합·큐 관점을 우선 의심하면 됩니다.

1단계: Connections 로그로 병렬 세션의 목적지를 시간축에 적기

추측으로 규칙을 쓰기 전에 실측 로그가 필요합니다. Agent View에서 재현되는 순간을 정해 두고, Clash 대시보드나 외부 컨트롤러의 Connections 화면을 열어 둡니다. 패널을 하나씩 늘리며 같은 동작을 반복하면 “두 번째 패널부터 특정 호스트가 폭증한다”는 패턴이 보이기도 하고, 반대로 패널 수와 무관하게 항상 같은 서브도메인에서 실패한다면 단일 세션에서도 터지는 규칙 공백일 가능성이 큽니다.

Windows와 WSL을 함께 쓰면 호스트 OS의 Clash와 WSL 안의 node가 서로 다른 라우팅을 탈 수 있습니다. 이 경우 WSL2·Clash 글을 같이 읽고 포트·환경 변수를 먼저 맞추는 편이 빠릅니다. macOS나 Linux라면 LaunchAgent·systemd 서비스로 띄운 보조 프로세스가 상속하지 않는 프록시 설정을 따로 갖고 있는지 확인합니다.

목록에 자주 등장하는 유형(본인 환경에서 재확인)

Anthropic 문서에 명시된 API 호스트(리전·제품 업데이트에 따라 변동 가능).
registry.npmjs.org와 스코프 tarball CDN.
GitHub: api.github.com, objects.githubusercontent.com, raw.githubusercontent.com 등 서로 다른 접두사.
에디터·확장이 호출하는 설정 동기화나 텔레메트리 호스트(조직마다 상이).

로그를 적을 때는 가능하면 프로세스 이름과 목적지, 체인을 함께 적습니다. 병렬 세션에서는 프로세스 이름이 같아 보여도 PID가 다르면 완전히 다른 연결 풀일 수 있습니다. 실패 직전 몇 초를 따로 캡처해 두면 나중에 규칙 변경 전후를 비교하기 쉽습니다.

2단계: 분류 규칙 스켈레톤을 로그에 맞춰 채우기

아래 YAML은 설명용 예시입니다. AI-DEV·PKG-CDN·GITHUB 자리에는 구독에 있는 proxy-group 이름을 넣고, 실제 행은 Connections에서 확인한 호스트로 교체하세요. Anthropic이 새 엔드포인트를 추가하면 예시 그대로 두면 안 됩니다.

# Illustrative rules — replace proxy groups; verify hostnames in your logs
rules:
  - DOMAIN-SUFFIX,api.anthropic.com,AI-DEV
  - DOMAIN-SUFFIX,anthropic.com,AI-DEV
  - DOMAIN-SUFFIX,registry.npmjs.org,PKG-CDN
  - DOMAIN-SUFFIX,npmjs.org,PKG-CDN
  - DOMAIN-SUFFIX,github.com,GITHUB
  - DOMAIN-SUFFIX,githubusercontent.com,GITHUB
  - DOMAIN-SUFFIX,githubassets.com,GITHUB
  - MATCH,DIRECT

분류 규칙 순서는 위에서 아래로 첫 매칭이 승리합니다. 원격 RULE-SET을 이미 끌어왔다면 내부에 GitHub나 npm 행이 있는지 확인하고, 로컬 오버라이드가 의도한 위치에 합쳐지는지 봅니다. DOMAIN-KEYWORD,anthropic처럼 지나치게 넓은 패턴은 다른 SaaS까지 끌어와 지연을 숨기기 때문에 최후 수단으로 두는 편이 안전합니다.

병렬 세션 환경에서는 “규칙이 맞는데도 가끔 DIRECT로 새는” 현상이 종종 보고됩니다. 이때는 규칙 자체보다 애플리케이션이 프록시 메타데이터를 무시하는 경로를 의심해야 합니다. 규칙을 더 늘리기 전에 TUN이나 환경 변수로 스택 전체를 Clash 쪽으로 접어 넣었는지 확인하세요.

3단계: 병렬 세션에서 큐 경합을 줄이는 노드 설계

여러 Agent 패널이 동시에 살아 있으면 단일 URL-TEST 그룹에서 후보 노드를 빠르게 순환하는 것이 오히려 독이 됩니다. 장시간 스트림이 걸린 상태에서 출구가 바뀌면 클라이언트가 재시도를 넣고, 사용자에게는 “한 번에 모든 패널이 동시에 끊긴다”처럼 보입니다. 실무에서는 API 전용 그룹을 작업 세션 동안 수동 고정하거나, 테스트 주기를 보수적으로 잡는 편이 병렬 UI와 잘 맞습니다.

트래픽	병렬 세션에서 특히 민감한 점	피하고 싶은 설정
Anthropic API·스트림	동시 장기 연결 수와 플랩	지연 한두 번만 보고 즉시 노드 스위칭
npm·대용량 tarball	처리량·재전송	스트림과 같은 혼잡 노드 공유
GitHub API	출구 IP 변동과 레이트 리밋	후보가 많은 자동 선택만 의존

노드를 나눌 때 이름만 바꾸고 후보 서버 풀이 완전히 같으면 효과가 거의 없습니다. 가능하면 상이한 업링크 특성을 가진 후보를 스트림 그룹과 다운로드 그룹에 각각 배치합니다. 같은 데이터센터 브랜드를 서로 다른 그룹 이름으로만 나누는 것은 심리적 안정감만 줄 뿐 체감 개선이 적은 경우가 많습니다.

4단계: DNS·fake-ip·IPv6를 터미널 스택과 맞추기

Electron 기반 에디터, 네이티브 터미널, 순수 셸의 Node 런타임이 서로 다른 리졸버를 쓰면 같은 FQDN도 다른 애니캐스트 엣지로 갈라집니다. 병렬 세션은 이런 분기가 동시에 일어나 증상을 증폭합니다. Clash에서 fake-ip를 쓰는 경우 일부 스택은 TLS 실패를 “연결 즉시 끊김”으로 보고하기도 합니다.

한 번에 한 변수: DNS 모드를 고정한 채 노드만 바꾸거나, 노드를 고정한 채 fake-ip만 바꿔 재현합니다.
IPv6: AAAA 우선 환경에서는 의도와 다른 회선으로 나가 패널마다 속도 차가 크게 납니다.
캐시: 규칙을 고쳤는데도 예전 IP로 붙는 착시는 로컬 DNS 캐시 때문인 경우가 많습니다.

점검 순서는 DNS·fake-ip 가이드를 따르면 충분합니다. Agent View처럼 UI가 무거운 상황에서는 네트워크 패널만 보지 말고 동일 시각의 DNS 로그도 함께 저장해 두면 나중에 회귀 분석이 쉬워집니다.

주의

본문의 도메인은 이해를 돕기 위한 예시입니다. Anthropic·GitHub·npm은 호스트가 늘거나 리전별로 달라질 수 있으니 항상 본인 Connections 로그를 기준으로 규칙을 만드세요.

5단계: TUN 또는 프록시 환경 변수로 CLI 경로를 통째로 맞추기

시스템 프록시만 켜 두면 터미널의 자식 프로세스가 빠져나가는 경우가 반복됩니다. Agent View는 그 프로세스들을 동시에 많이 띄우므로 증상이 크게 드러납니다. macOS·Linux에서는 TUN 모드로 스택 전체를 Clash 쪽으로 올리는 방법이 CLI에 유리한 경우가 많고, CI나 원격 서버라면 셸 프로필에 HTTPS_PROXY·ALL_PROXY를 명시적으로 넣는 편이 재현성이 높습니다.

TUN: 프록시를 무시하는 바이너리도 강제로 같은 라우팅 테이블을 타게 할 수 있습니다.
환경 변수: 에디터가 터미널 통합 창에 무엇을 상속하는지, sudo가 환경을 지우는지 확인합니다.
git·컨테이너: 호스트와 다른 네임스페이스에서는 localhost 포트가 달라집니다.

보다 일반적인 터미널 패턴은 터미널·git·프록시 글에 정리되어 있습니다. 에디터 전반의 AI 트래픽을 함께 보고 싶다면 Cursor·AI 개발 글과 교차 참고하면 Agent View와의 차이도 빠르게 정리됩니다.

증상별로 의심할 순서

패널을 두 개 이상 열 때만 전부 느려집니다

단일 노드 큐나 동일 정책 그룹에서 스트림과 다운로드가 동시에 경쟁하는 패턴을 의심합니다. 노드를 분리했는지, URL-TEST 주기가 너무 공격적인지 확인하세요.

UI 스트림은 되는데 터미널 명령만 간헐 실패합니다

터미널 경로가 시스템 프록시를 타지 않는 경우가 많습니다. TUN 또는 환경 변수 적용 여부를 우선 점검합니다.

Anthropic만 간헐적으로 끊기고 npm은 멀쩡합니다

API 호스트의 서브경로나 스트림 전용 엔드포인트가 다른 규칙에 걸려 DIRECT로 새거나, 노드 플랩으로 세션이 재협상되는 경우를 의심합니다.

자주 묻는 질문

Agent View만 열면 멀쩡한데 병렬 세션을 켜면 전부 느려집니다. 네트워크 문제인가요?

동시에 열린 각 패널이 독립적인 HTTPS 세션과 도구 호출을 만들면 단일 노드 큐나 동일 정책 그룹에서 경쟁이 생깁니다. Connections에서 동시간대 목적지와 처리량을 보고 스트림 전용 그룹과 패키지 CDN 그룹을 분리하세요.

브라우저 Claude는 빠른데 Claude Code CLI만 타임아웃합니다.

브라우저는 시스템 프록시를 따르지만 터미널의 Node 자식은 DIRECT로 나가는 경우가 많습니다. TUN 적용 여부와 HTTPS_PROXY 상속, WSL 환경이라면 호스트 Clash 포트 전달을 함께 확인하세요.

Anthropic API 규칙은 넣었는데 여전히 간헐적으로 끊깁니다.

API 호스트만 프록시하고 스트림 중 재협상되는 서브도메인·CDN이 DIRECT로 빠지거나, url-test 주기가 짧아 출구가 바뀌면 세션이 끊긴 것처럼 보입니다. 로그로 실패 직전 호스트를 확인하고 노드 플랩을 줄이세요.

실무 체크리스트

병렬 세션을 재현한 채 Connections 로그에서 프로세스·목적지·체인을 시간 순으로 모은다.
Anthropic API, npm·tarball, GitHub 서브도메인을 각각 정책 그룹에 매핑할지 결정한다.
DNS 모드·fake-ip·IPv6를 고정한 상태에서 한 번에 한 변수만 바꿔 재현한다.
장시간 스트림용 그룹과 대용량 다운로드용 그룹을 분리하고 병렬 패널에서 큐가 겹치지 않게 한다.
TUN 또는 환경 변수로 터미널이 실제로 Clash 출구를 통과하는지 검증한다.

정리와 선택

원클릭형 브라우저 VPN이나 규칙이 거의 없는 범용 클라이언트는 일상 웹 서핑에는 편하지만, Agent View처럼 병렬 세션과 CLI 패널이 동시에 붙는 개발자 네트워크에서는 호스트 단위 통제와 DNS·출구 일관성이 부족해 증상이 남기 쉽습니다. 특히 한 줄 MATCH로 모든 트래픽을 단일 노드에 몰면 스트림과 대용량 전송이 서로 발목을 잡아 “패널만 추가했을 뿐인데 전체가 버벅인다”는 체감으로 나타납니다.

Clash 계열은 세분화된 분류 규칙과 정책 그룹, DNS 설정, TUN·환경 변수까지 같은 설정 트리 안에서 다룰 수 있어 터미널 중심 AI 워크플로와 잘 맞습니다. Anthropic API를 안정적으로 유지하면서도 npm·GitHub처럼 성격이 다른 트래픽에는 다른 노드 선택 전략을 적용할 수 있다는 점이 실무에서 특히 큽니다.

위 순서를 직접 비교해 보고 싶다면 Clash를 무료로 내려받아 병렬 세션 부하가 줄었는지 확인해 보세요

2026년 Claude Code Agent View와 병렬 터미널 세션이 버벅일 때, Clash 분류와 노드 전략으로 CLI·Anthropic API 안정화하기