Junie CLI 베타·Clash MCP 안정화

Junie CLI 베타가 네트워크를 까다롭게 만드는 이유

Junie는 JetBrains가 밀고 있는 AI 코딩 흐름의 일환이라, “모델 한 줄”로 끝나지 않습니다. CLI는 로컬에서 Node·JVM·네이티브 바이너리를 통해 HTTPS 클라이언트로 직접 붙고, 같은 세션에서 패키지 설치와 Git 작업이 끼어듭니다. 브라우저의 시스템 프록시는 잘 따라가도, 터미널 프로세스는 기본적으로 DIRECT로 나가는 경우가 많아 “IDE에서는 Junie가 보이는데 CLI만 끊긴다”는 형태로 나타납니다.

JetBrains 배포·플러그인 축: 제품 업데이트, 마켓 메타데이터, 리다이렉터·CDN 등 조직 제품군에서 공통으로 쓰는 호스트가 섞입니다.
모델·클라우드 API: 선택한 제공자에 따라 엔드포인트가 달라지며 베타 기간에는 변경이 잦을 수 있습니다.
패키지·소스: registry.npmjs.org와 스코프 tarball, GitHub 릴리스·raw·API.
MCP 주변: 로컬 stdio 서버는 루프백이지만, 카탈로그·OAuth·원격 레지스트리가 있으면 호스트가 추가됩니다.

한 줄 요약

한 줄 MATCH로 전부 프록시하기보다, 스트림·API와 fat download를 같은 정책 그룹에 몰아넣지 마세요. 베타 CLI는 두 트래픽이 한 화면 뒤에서 동시에 터질 때가 많습니다.

JetBrains·npm·GitHub·MCP 축을 머릿속에서 먼저 나누기

규칙을 쓰기 전에 트래픽을 네 덩어리로 나눕니다. 첫째는 Junie가 실제로 호출하는 모델·인증·텔레메트리 게이트웨이입니다. 둘째는 JetBrains 제품군이 공유하는 리소스·플러그인·캐시 리다이렉션 축입니다. 셋째는 npm과 GitHub 계열입니다. 넷째는 MCP에서 추가로 불러오는 마켓 JSON·서드파티 엔드포인트입니다. 공식 문서와 릴리스 노트가 바뀔 때마다 정확한 FQDN은 달라질 수 있으니, 블로그 예시 도메인을 그대로 신뢰하지 말고 본인 로그로 확인하는 습관이 필요합니다.

각 축은 네트워크 특성이 다릅니다. 모델 스트림은 낮은 지터와 세션 유지가 중요하고, npm은 많은 작은 요청과 가끔 큰 tarball에 민감하며, GitHub API는 출구 IP가 흔들리면 403·429 이야기로 이어집니다. MCP 메타 호스트는 번들·플러그인 조합에 따라 들쭉날쭉해서 “어제는 됐는데 오늘은 MCP만 실패”가 규칙 순서 문제로 설명되기도 합니다.

1단계: Connections 로그로 프로세스별 목적지 적기

가장 먼저 할 일은 추측이 아니라 실제 연결입니다. Clash 대시보드나 외부 컨트롤러에서 junie·java·node·npm·git·MCP 보조 바이너리가 치는 SNI를 시간 순으로 적습니다. Windows라면 WSL 내부 프로세스가 호스트와 다른 경로로 나가는지 WSL2·Clash 글을 함께 보고, Linux 서버라면 systemd 유닛에 프록시 환경이 비어 있지 않은지 확인합니다.

목록에 자주 나오는 유형(본인 환경에서 검증할 것)

JetBrains: plugins.jetbrains.com, resources.jetbrains.com, download.jetbrains.com, cache-redirector.jetbrains.com 등(세트는 시기·제품에 따라 변동).
모델 제공자 문서에 적힌 API 호스트(리전·엔드포인트 변경 시 재확인).
npm: 레지스트리와 실제 tarball을 서빙하는 CDN 도메인(스코프마다 다를 수 있음).
GitHub: 웹·API·오브젝트 스토리지·raw가 서로 다른 접두사.
MCP: 원격 카탈로그·OAuth 토큰 서버 도메인(조직 정책에 따라 추가).

이 단계에서 “브라우저는 빠른데 CLI만 느리다”는 패턴이 보이면, 동일 호스트라도 프로세스가 다른 NIC·DNS 캐시를 쓰는지 의심합니다. 로그 한 페이지만으로 충분하지 않을 때가 많으니, 실패 직전 몇 초를 연속 캡처하는 편이 좋습니다.

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

아래 YAML은 설명용 예시입니다. JB-CDN·AI-DEV·PKG-CDN·GITHUB·MCP-META 자리에는 구독에 있는 proxy-group 이름을 넣고, 실제 행은 Connections에서 확인한 호스트로 교체하세요. example-ai.invalid처럼 자리 표시 줄은 반드시 본인 환경 값으로 바꿉니다.

# Illustrative rules — replace proxy groups; verify hostnames in your logs
rules:
  - DOMAIN-SUFFIX,jetbrains.com,JB-CDN
  - DOMAIN-SUFFIX,intellij.net,JB-CDN
  - 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
  - DOMAIN-SUFFIX,example-ai.invalid,AI-DEV
  - DOMAIN-SUFFIX,example-mcp-catalog.invalid,MCP-META
  - MATCH,DIRECT

규칙 순서는 위에서 아래로 첫 매칭이 이깁니다. 원격 RULE-SET을 이미 끌어왔다면 그 안에 GitHub·npm 행이 있는지 먼저 보고, 로컬 오버라이드가 합쳐질 위치를 확인하세요. DOMAIN-KEYWORD,github처럼 지나치게 넓은 패턴은 다른 SaaS 트래픽까지 끌고 와서 의도치 않은 지연을 만들 수 있으니 최후 수단으로 두는 편이 안전합니다.

JetBrains 도메인을 한 덩어리로 묶을 때도 예외가 있습니다. 회사망에서 특정 서브도메인만 직통이 허용된다면 DIRECT 행을 더 위에 두고 나머지는 프록시로 보내는 식으로 조직 정책을 먼저 반영해야 합니다. 이때 “베타 CLI” 특유의 호스트가 새로 뜨면 목록을 갱신하지 않는 한 다시 타임아웃이 재현됩니다.

3단계: 장시간 스트림과 fat download를 한 노드에 두지 않기

Junie가 대화를 스트리밍하는 동안 MCP 도구가 짧은 HTTP를 연속 호출하고, 백그라운드에서 npm install이 큰 tarball을 당기는 시나리오는 베타에서 특히 흔합니다. 이때 url-test 주기가 짧고 후보 노드가 많으면 장시간 세션 중에 출구가 바뀌어 핸드셰이크 재시도·토큰 재발급이 겹칠 수 있습니다.

트래픽	노드에 바라는 성질	흔한 실수
모델 API·SSE	플랩이 적고 RTT 안정	속도 테스트 상위 노드에 API만 몰기
npm·Git LFS·대용량 릴리스	처리량·재시도 내성	스트림과 같은 큐 점유
GitHub API	출구 IP 변동 최소	짧은 주기 자동 페일오버
JetBrains CDN	지역 엣지 선택이 일관	DNS만 바꾸고 노드는 그대로

작업 단위로 API 전용 그룹을 수동 고정하는 운용은 지루하지만, 베타 CLI 디버깅에서는 오히려 재현 제거에 유리합니다. 반대로 패키지 그룹은 처리량을 위해 다른 후보 풀을 써도 무방한 경우가 많습니다.

4단계: DNS·fake-ip·IPv6를 Node·JVM 스택과 맞추기

Electron·IDE, 순수 터미널, systemd 서비스가 서로 다른 리졸버를 쓰면 같은 이름도 다른 애니캐스트로 갈라집니다. Clash의 fake-ip를 쓰는 경우 일부 TLS 스택은 증상을 “연결 직후 RST”처럼 보이게 만들기도 합니다. DNS·fake-ip 가이드 순서대로 한 번에 한 변수만 바꿔 재현해 보세요.

IPv6: AAAA가 우선되면 의도와 다른 회선으로 나가는 경우가 있습니다.
Split tunnel·제로트러스트: 회사 VPN과 병행 시 터미널만 다른 라우팅 테이블을 타는지 확인합니다.
TTL·캐시: 규칙을 고쳤는데도 예전 IP로 붙는 착시는 종종 로컬 캐시 때문입니다.

주의

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

5단계: TUN·프록시 환경 변수로 CLI가 Clash를 “진짜로” 통과하게 하기

macOS·Linux에서 시스템 프록시가 빈틈이 있으면 Node·git·컨테이너 풀이 그대로 직행합니다. Windows는 호스트와 WSL 포트 전달이 어긋나기 쉽습니다. 실무에서는 TUN으로 스택 전체를 끌어올리거나, 셸 프로필·CI에 HTTPS_PROXY·ALL_PROXY를 주입하는 방법을 병행합니다.

TUN: 앱이 프록시를 무시해도 강제로 경로를 맞출 수 있어 CLI에 유리한 경우가 많습니다.
환경 변수: 에디터가 자식 프로세스에 상속하는지, sudo가 환경을 지우는지 확인합니다.
git: http.proxy만 켜 두고 npm은 비어 있으면 증상이 섞여 보입니다.

터미널 HTTP·Git 패턴을 더 깊게 보고 싶다면 터미널·git·프록시 글을 같이 읽으면 Junie CLI와도 바로 연결됩니다.

6단계: MCP 레이어에서만 터지는지 분리해 보기

MCP는 로컬 stdio로 돌더라도, 서버가 마켓에서 플러그인 목록을 받거나 OAuth 교환을 하면 원격 HTTPS가 추가됩니다. “채팅은 되는데 특정 도구만 실패”할 때 Connections에서 MCP 자식 프로세스 이름을 추적하면, 잘못된 MATCH,DIRECT나 낮은 우선순위 규칙에 걸린 흔적이 드러납니다.

카탈로그 JSON: 버전 고정 URL이면 브라우저 캐시와 충돌하기도 합니다.
OAuth 콜백: 루프백은 로컬이어도 토큰 서버는 원격입니다.
중첩 Node: 플러그인 매니저가 또 다른 Node 자식을 띄우면 프로세스 규칙도 달라집니다.

다른 터미널 AI 글과 어떻게 같이 읽나요

OpenCode CLI 글은 동일한 검색 의도—터미널·npm·GitHub·MCP—에 맞춰 쓰였습니다. Gemini CLI 글은 Google 쪽 게이트웨이 축이 강조되고, Claude Code·MCP 글은 Anthropic API 축이 강조됩니다. Junie CLI에서는 JetBrains 배포 호스트가 추가되므로 그 한 축만 로그에서 보강하면 나머지 패턴은 거의 그대로 이식할 수 있습니다.

규칙 파일을 글에서 통째로 복붙하기보다, 프로세스·호스트·정책 그룹 매핑표를 본인 메모장으로 옮겨 적는 습관이 장기적으로 훨씬 안전합니다. 베타 기간에는 릴리스 노트 한 줄이 새 서브도메인을 추가하기도 합니다.

증상별로 의심할 순서

MCP 도구만 타임아웃하고 모델 채팅은 정상

원격 카탈로그나 OAuth 호스트만 다른 규칙에 걸려 DIRECT로 막혔을 가능성을 의심합니다. Connections에서 MCP 보조 프로세스의 목적지를 따로 필터링해 보세요.

npm만 느리거나 특정 스코프에서만 ECONNRESET

레지스트리 응답과 tarball CDN이 서로 다른 출구로 갈리면 일부 패키지에서만 실패합니다. 실패한 패키지 한 건에 대해 verbose 로그로 실제 URL을 확인하세요.

JetBrains 업데이트·플러그인 목록만 실패

회사 방화벽이 특정 JetBrains 서브도메인만 막는 패턴입니다. 로그에 찍힌 정확한 FQDN을 네트워크 팀과 공유하면 빠르게 좁혀집니다.

자주 묻는 질문

IDE 안 Junie는 되는데 터미널 Junie CLI만 타임아웃이 납니다. 왜 그런가요?

프로세스 트리와 상속 프록시 설정이 다릅니다. IDE는 자체 프록시를 타지만 터미널 셸의 Node 자식은 시스템 프록시를 무시하고 DIRECT로 나가는 경우가 많습니다. Connections에서 junie·node 관련 항목의 목적지와 체인을 확인하고 TUN 또는 HTTPS_PROXY 적용 여부를 점검하세요.

MCP 서버를 로컬에서만 쓰는데도 외부 호스트가 필요한가요?

stdio MCP 자체는 루프백이지만, 서버가 플러그인 목록·버전 메타데이터·OAuth 토큰 교환을 원격에서 가져오면 별도 HTTPS 호스트가 추가됩니다. 설정과 공식 문서의 엔드포인트를 열어 실제로 어떤 URL을 두드리는지 확인한 뒤 규칙에 반영하세요.

npm install은 되는데 GitHub에서만 간헐적으로 실패합니다.

api.github.com과 objects.githubusercontent.com, raw.githubusercontent.com 등 서브도메인이 서로 다른 규칙에 걸리면 일부 작업만 실패합니다. 실패 시점의 URL을 verbose 로그로 확인하고 같은 fat-download 또는 API 안정 그룹으로 묶으세요.

실무 체크리스트

Junie·Node·npm·git·JVM·MCP 보조 프로세스별로 Connections 로그를 모은다.
JetBrains CDN, 모델 게이트웨이, npm·tarball, GitHub 서브도메인, MCP 메타 호스트를 정책 그룹에 매핑할지 결정한다.
DNS 모드·fake-ip·IPv6를 고정한 채 한 번에 한 변수만 바꿔 재현한다.
장시간 스트림용 그룹과 대용량 패키지용 그룹을 분리한다.
TUN 또는 환경 변수로 터미널이 실제로 Clash 출구를 통과하는지 검증한다.

정리와 선택

브라우저 전용 VPN이나 “한 줄 프리셋”형 도구는 빠른 웹 서핑에는 편하지만, Junie CLI 베타처럼 모델·JetBrains CDN·npm·GitHub·MCP가 한 작업선에 섞이는 개발자 트래픽에는 호스트 단위 제어가 부족한 경우가 많습니다. DNS와 출구가 분리되지 않으면 증상이 간헐적으로만 남아 재현이 어렵고, 베타 기간에는 그런 불확실성이 더 커집니다. Clash 계열은 분류 규칙을 세밀히 쌓고 같은 설정 트리에서 DNS·TUN·정책 그룹을 다룰 수 있어 터미널 AI 스택과 잘 맞습니다. 노드를 트래픽 성격에 맞게 나누면 총 타임아웃 빈도를 출구 단위로 줄이기 쉽습니다.

같은 흐름을 다른 제품 이름으로 검색한다면 OpenCode CLI·Claude Code·MCP 글과 세트로 읽고 JetBrains 호스트 행만 덧붙이면 됩니다. 베타 채널은 바뀌기 쉬우니 로그 기반 점검을 반복하는 것이 가장 값진 습관입니다.

필요하다면 Clash를 무료로 내려받아 위 순서대로 터미널 출구를 직접 비교해 보세요

JetBrains Junie CLI 베타에서 모델·MCP·npm·GitHub가 자주 타임아웃될 때, 2026년 Clash 분류로 터미널 출구 맞추기