튜토리얼 2026-05-09 · 약 19분

OpenCode CLI와 플러그인 소스가 자주 타임아웃될 때, 2026년 Clash 분류로 터미널·npm·GitHub·MCP 출구 맞추기

2026년에는 에디터 안이 아니라 터미널에서 돌아가는 AI 코딩 흐름이 빠르게 늘고 있고, 그 중 하나가 OpenCode처럼 CLI에 가까운 진입을 전제로 한 도구들입니다. 한편 검색과 실무에서는 “모델 응답이 나쁘다”보다 모델 가중치·플러그인 메타데이터·패키지 tarball을 받는 단계에서 끊기는 불만이 더 크게 보입니다. 터미널 한 줄이 수십 개의 다른 호스트를 밟기 때문입니다. npm 레지스트리와 tarball CDN, GitHub의 API·오브젝트 스토리지·raw 경로, 그리고 Model Context Protocol(MCP)로 붙는 보조 프로세스가 가져오는 원격 JSON까지 합치면, 브라우저만 맞춰 둔 프록시 규칙으로는 커버가 안 됩니다. 이 글은 Clash의 분류 규칙 순서, DNS, TUN·프로세스 관점, 노드 선택을 Claude Code·MCP 분류 글과 나란히 두고 OpenCode 쪽 검색 의도에 맞춰 정리합니다.

왜 “브라우저 프록시만”으로는 부족한가요

많은 개발자가 macOS·Windows에서 시스템 프록시나 브라우저 확장만 켜 둔 채 터미널 작업을 합니다. 그러면 Safari나 Chrome은 잘 나가도, Node·Go·Rust로 빌드된 CLI가 DIRECT로 국내 회선이나 사내망에 그대로 붙습니다. OpenCode 계열은 특히 로컬 프로세스가 HTTPS 클라이언트 역할을 하므로, 웹 전용 가이드와 다른 점검표가 필요합니다. 같은 증상이라도 원인은 “노드 품질”이 아니라 어느 인터페이스로 나가느냐인 경우가 많습니다.

  • 에디터 밖 실행: 터미널 세션·백그라운드 데몬이 별도 프로세스 트리를 가집니다.
  • 동시성: 모델 스트림, 패키지 병렬 다운로드, Git 호출이 한 화면 뒤에서 겹칩니다.
  • MCP: 로컬 stdio 서버는 루프백이지만, 플러그인 목록·버전 확인·템플릿을 원격에서 받으면 호스트가 늘어납니다.

한 줄 요약

브라우저가 잘 된다는 사실은 터미널도 같은 길로 간다는 뜻이 아닙니다. Connections 탭에 찍힌 프로세스 이름·목적지 쌍을 먼저 모으세요.

트래픽을 네 덩어리로 나누기: 모델·npm·GitHub·MCP 주변

규칙을 쓰기 전에, 머릿속에서 트래픽을 나눕니다. 첫째는 모델 제공자나 게이트웨이로 가는 AI API·스트림입니다. 둘째는 npm이나 사내 Verdaccio 같은 패키지 레지스트리와 tarball CDN입니다. 셋째는 GitHub의 웹·API·릴리스 오브젝트·raw 서브도메인입니다. 넷째는 MCP 생태계에서 뜨는 카탈로그·마켓 JSON·서드파티 플러그인 업데이트 URL입니다. 벤더와 조직마다 정확한 호스트 문자열은 다르므로, 추측한 도메인을 그대로 복붙하지 말고 반드시 본인 로그로 교차 확인하세요.

이 네 축은 서로 다른 네트워크 특성을 가집니다. API 스트림은 낮은 지터와 세션 유지가 중요하고, npm은 많은 소용량 파일과 간헐적 대용량 tarball에 민감하며, GitHub API는 출구 IP 안정성과 레이트 리밋 이슈가 얽힙니다. MCP 주변 호스트는 사용하는 서버 번들에 따라 들쭉날쭉하므로, “한 번에 잘 되던 날”과 “플러그인만 실패하는 날”의 차이가 규칙 순서나 노드 전환에서 설명되는지부터 봅니다.

1단계: Connections 로그로 실제 호스트 수집

가장 비용 대비 효과가 큰 작업은 추측을 줄이는 것입니다. Clash 대시보드나 외부 컨트롤러에서 opencode·node·npm·git 등의 프로세스가 치는 SNI를 기록합니다. Windows라면 WSL 안의 Node가 호스트와 다른 경로로 나가는지 WSL2·Clash 글을 함께 읽으며 이중 스택을 점검합니다. Linux 헤드리스라면 systemd 유닛 환경에 프록시가 비어 있지 않은지도 확인합니다.

목록에 자주 포함되는 유형(환경마다 다름)

  • 모델·추론 게이트웨이 문서에 나오는 API 호스트(제품 업데이트 시 재확인).
  • registry.npmjs.org 및 tarball이 뜨는 CDN 호스트 이름.
  • github.com, api.github.com, objects.githubusercontent.com 등 서로 다른 접두사.
  • MCP 마켓·레지스트리를 켠 경우 추가되는 벤더 도메인.

아래 YAML은 설명용 스켈레톤입니다. AI-DEV·PKG-CDN·GITHUB·MCP-META 자리에 구독에 있는 proxy-group 이름을 넣고, 행은 로그로 채우세요.

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

분류 규칙은 위에서 아래로 첫 매칭이 이깁니다. 원격 RULE-SET을 이미 끌고 있다면 그 안에 GITHUB나 npm 행이 있는지 먼저 보고, 로컬 오버라이드가 덮어쓰는 위치인지 합병 규칙을 읽습니다. DOMAIN-KEYWORD,github처럼 넓은 키워드는 다른 트래픽까지 끌고 와 의도치 않은 프록시를 만들 수 있으니 최후 수단으로 두는 편이 안전합니다.

2단계: 장시간 스트림과 “fat download”를 한 노드에 묶지 않기

모델 응답 스트림과 MCP 도구 호출은 한 TCP 세션을 길게 쓰는 패턴이 섞입니다. 반면 npm install은 짧은 요청이 폭발적으로 이어지고 가끔 큰 tarball을 당깁니다. 둘을 동일한 url-test 그룹에 넣고 자동 전환을 공격적으로 돌리면, 스트림 중간에 출구가 바뀌어 재인증·재협상이 일어나 CLI만 끊기는 현상이 나올 수 있습니다. OpenCode에서 “대화는 되는데 플러그인 설치만 간헐 실패” 같은 패턴은 이 구조와 잘 맞습니다.

트래픽 노드에 바라는 성질 자주 생기는 실수
모델 API·SSE 플랩이 적고 RTT가 안정적 속도 테스트 1위 노드만 고집
npm·대용량 에셋 처리량·재시도 친화 API와 같은 큐를 공유
GitHub API 출구 IP가 덜 바뀜 짧은 주기 자동 failover

URL-TEST 주기와 허용 오차를 지나치게 타이트하게 두면, 장시간 작업 중에도 후보 노드가 바뀝니다. AI 전용 그룹은 작업 세션 동안 수동 고정하거나 간격을 보수적으로 잡는 운용이 종종 더 낫습니다.

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

Electron 기반 IDE, 순수 터미널, 시스템 리졸버가 서로 다른 DNS 경로를 쓰면 같은 이름도 다른 애니캐스트 엣지로 갈라집니다. Clash에서 fake-ip를 쓰는 경우, 일부 TLS 스택은 핸드셰이크 직후 끊기는 것처럼 보이기도 합니다. DNS·fake-ip 가이드의 순서대로 한 번에 한 변수만 바꿔 재현해 보세요.

  • IPv6: AAAA가 먼저 잡히면 의도와 다른 회선으로 나가는 사례가 있습니다.
  • Split tunnel: 회사 제로트러스트 VPN과 병행할 때 터미널만 다른 테이블을 타는지 확인합니다.
  • 로컬 캐시: 오래된 TTL이 남아 “방금 규칙을 고쳤는데도” 이전 목적지로 붙는 착시가 납니다.

주의

본문의 도메인 예시는 이해를 돕기 위한 것입니다. 실제 제품명·리전·엔드포인트는 변경될 수 있으니 항상 본인 Connections 로그를 단일 출처로 삼으세요.

4단계: TUN·프로세스 기반 분류와 환경 변수

애플리케이션이 시스템 프록시를 무시하면 TUN이 터미널 CLI에 유리한 경우가 많습니다. 반대로 TUN이 모든 트래픽을 들이밀어 사내 SaaS에 충돌이 나면, 문제가 되는 프로세스만 골라내는 PROCESS-NAME 규칙이나 스플릿 앱 목록을 검토합니다. 범용적으로는 HTTPS_PROXY·HTTP_PROXY·ALL_PROXY를 셸 프로필이나 CI에 넣되, 툴이 이를 존중하는지 확인합니다. Git의 http.proxy만 켜 두고 Node는 빈 손으로 나가면, 증상이 저글링처럼 섞인 것처럼 보입니다.

CLI 전반의 HTTP·Git 프록시 패턴은 터미널·git·프록시 글과 겹치는 부분이 있습니다. OpenCode 맥락에서는 “편집기 한정”이 아니라 모델+npm+GitHub+MCP가 한 작업선이라는 점만 강조해 두면, 같은 원리를 그대로 이식할 수 있습니다.

5단계: MCP 레이어에서 터지는 지점 찾기

MCP는 로컬에서 stdio로 돌더라도, 서버가 원격 레지스트리를 읽거나 브라우저 OAuth 리디렉션을 요구하면 별도 호스트가 추가됩니다. IDE 안 MCP 패널은 정상인데 터미널 OpenCode에서만 실패한다면, 어느 프로세스가 어느 설정 파일을 읽는지부터 나눕니다. Connections에서 해당 MCP 보조 바이너리 이름을 추적하면, 잘못된 MATCH,DIRECT 처리나 낮은 우선순위 규칙에 걸린 흔적이 드러납니다.

  • 카탈로그 JSON: 버전 고정 URL이면 캐시와 충돌 가능.
  • OAuth·브라우저: 루프백 콜백은 로컬이지만 토큰 교환 서버는 원격입니다.
  • 서브프로세스: 플러그인 매니저가 별도 Node 자식을 띄우면 프로세스 필터도 달라집니다.

Claude Code·MCP 분류 글에서 다룬 “웹 Claude와 다른 점”은 OpenCode에도 그대로 이어집니다. 차이는 검색 키워드와 툴체인 브랜딩뿐 아니라, 기본으로 붙는 레지스트리 URL과 번들러가 끌고 오는 바이너리의 출처입니다.

Codex·Cursor 글과 겹치는 곳, 다른 곳

OpenAI Codex 글은 api.openai.com 계열 중심입니다. Cursor·AI 개발 글은 IDE 통째 트래픽을 다룹니다. OpenCode 검색 의도는 그 중간에서 터미널 CLI + npm + GitHub + MCP에 더 가깝습니다. 규칙을 다른 글에서 복붙하지 말고, 로그 패턴을 이식하세요. 그래야 버전 업 직후 바뀐 서브도메인에도 빠르게 따라갈 수 있습니다.

증상별로 의심할 순서

채팅은 되는데 플러그인 목록만 비거나 느림

모델 API와 마켓 메타데이터 호스트가 서로 다른 정책 그룹으로 갈렸거나, 마켓 쪽만 DIRECT로 남은 경우를 의심합니다. CDN이 지리적으로 먼 노드를 탔을 때도 비슷하게 보입니다.

npm는 대부분 되는데 특정 스코프만 실패

tarball이 다른 도메인으로 리다이렉트되면 레지스트리 행만으로는 부족합니다. 실패한 패키지 한 건에 대해 verbose 로그를 켜 실제 URL을 확인하세요.

Git clone은 되는데 API 403·429가 잦음

출구 IP가 자주 바뀌면 레이트 리밋에 반복적으로 걸립니다. API용 그룹의 플랩을 줄이거나 작업 단위로 노드를 고정합니다.

자주 묻는 질문

브라우저는 정상인데 OpenCode만 느립니다. 어디부터 보나요?

터미널 프로세스가 시스템 프록시를 타지 않는 전형적인 패턴입니다. TUN을 켜거나, 해당 셸에 프록시 환경 변수를 주입한 뒤 Connections에서 같은 목적지가 프록시 체인을 통과하는지 확인합니다.

MCP 서버는 로컬 실행인데 외부 호스트가 필요한가요?

서버 구현에 따라 다릅니다. 순수 로컬 도구만 쓰면 외부가 거의 없지만, 마켓에서 플러그인을 고르면 JSON과 tarball을 원격에서 당깁니다. “로컬만 쓴다”는 가정이 어긋나는지 설정 파일을 열어 확인하세요.

규칙을 많이 넣었더니 이전보다 느려졌습니다.

행 수 자체보다 매칭 비용이 큰 패턴과 중복 RULE-SET이 문제인 경우가 많습니다. 먼저 자주 맞는 호스트를 위로 올리고, 넓은 키워드 규칙을 정리합니다.

실무 체크리스트

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

정리와 제품 관점에서의 선택

일부 단일 목적 프록시 도구는 “브라우저만 빠르게”에 최적화되어 있어, 터미널·패키지·Git·MCP가 뒤섞인 개발자 작업선을 한 번에 서술하기 어렵습니다. 규칙을 JSON 한 덩어리로만 노출하거나 DNS 제어가 부족하면, 증상이 간헐적으로만 남아 재현이 힘들어집니다. Clash 계열은 호스트·프로세스·정책 그룹의 분류 규칙을 세밀하게 쌓고, DNS와 TUN을 같은 설정 트리에서 다룰 수 있어 터미널 AI 스택과 잘 맞습니다. 노드 선택을 작업 성격에 맞게 나누면 OpenCode CLI에서 겪는 타임아웃과 플러그인 소스 오류를 출구 단위로 줄이기 쉽습니다.

동일한 고민을 다른 툴 이름으로 검색한다면 Claude Code·MCP 분류 글과 세트로 읽어도 좋습니다. 흐름은 같고 호스트 목록만 갈아 끼우면 됩니다.

Clash를 무료로 내려받아 터미널 출구 정리를 직접 비교해 보세요

OpenCode·CLI 출구 정리

모델·npm·GitHub·MCP를 나누고 개발 전용 정책 그룹에 묶으세요.

Clash 다운로드