왜 브라우저와 IDE·패키지 매니저를 나누나요?
웹 서핑은 «보이는 탭» 안에서 끝나지만, Cursor 같은 편집기는 백그라운드에서 인덱싱, 모델 호출, 확장·런타임 업데이트, 원격 SSH·컨테이너 연동까지 동시에 돌아갑니다. npm과 pnpm은 registry.npmjs.org뿐 아니라 Git 호스팅·바이너리 미러·감사(audit) 엔드포인트로 요청이 갈라집니다. 모든 트래픽을 한 노드에 몰면 회사 VPN·클라우드 콘솔·국내 API까지 같은 지연을 겪고, 반대로 해외 직결만 켜 두면 레지스트리와 IDE 업데이트 서버만 단독으로 막히는 패턴이 반복됩니다.
Clash의 규칙 모드에서는 «이 접미사는 이 정책 그룹»만 맞추면 되므로, 개발자 프록시가 필요한 호스트만 DEV 같은 그룹으로 보내고, 나머지는 DIRECT나 일반 해외 프록시 그룹에 두는 식으로 정리할 수 있습니다. 이미 ChatGPT·OpenAI API 분기 글에서 다룬 것처럼 생성형 AI 웹·API용 묶음이 있다면, 본 글의 «IDE·패키지·Git» 묶음은 그 옆에 두고 역할만 나누면 프로필이 길어지지 않고도 목적이 분명해집니다.
개발 트래픽에 자주 쓰는 도메인·접미사
DOMAIN-SUFFIX로 묶을 때는 실제 실패 로그에 찍힌 호스트를 기준으로 추가·삭제하는 것이 가장 안전합니다. 다만 처음 프로필을 잡을 때 참고할 만한 묶음은 다음과 같습니다.
- registry.npmjs.org — 공식 npm 레지스트리. pnpm도 기본적으로 동일 계열을 씁니다.
- npmjs.com — 웹·리다이렉트·문서 요청에 섞여 들어오는 경우가 있습니다.
- github.com, objects.githubusercontent.com 등 — 의존성 tarball·릴리스 자산이 자주 이쪽으로 붙습니다.
- cursor.com, cursorapi.com 등 — IDE 브랜드·업데이트·서비스 호스트는 시기에 따라 바뀌므로, 클라이언트 로그의 실제 이름을 우선하세요.
- openvsx.org / marketplace.visualstudio.com — VS Code 호환 확장 마켓을 쓰는 흐름에서 등장할 수 있습니다.
사내 Verdaccio·Artifactory·프라이빗 Git을 쓰면 위 목록 대신 자사 도메인 접미사를 DEV 또는 오히려 DIRECT로 두는 편이 맞습니다. «해외 프록시를 태워야 빠른 호스트»와 «사내 망에만 있는 레지스트리»를 한 프로필에서 섞으면 pnpm 설치가 한 패키지마다 다른 경로로 나가며 타임아웃처럼 보이기도 합니다.
DOMAIN-KEYWORD는 개발 도구에서 특히 조심
DOMAIN-KEYWORD,git처럼 짧게 쓰면 편하지만, 전혀 다른 서비스 도메인에 같은 문자열이 들어가면 의도하지 않은 트래픽까지 프록시로 갈 수 있습니다. 가능하면 DOMAIN-SUFFIX로 서비스 경계를 맞추고, 정말 필요할 때만 키워드 규칙을 쓰는 것을 권장합니다.
정책 그룹 설계: DEV·BROWSE·DIRECT
분기 규칙이 가리키는 끝은 «어떤 노드 묶음으로 나갈지»입니다. 실무에서는 (1) 국내·사설·LAN은 DIRECT, (2) 일상 해외 웹은 PROXY 또는 select, (3) IDE·레지스트리·대용량 tarball만 DEV처럼 저지연·특정 지역 노드를 고르게 하는 삼단 구조를 자주 씁니다. DEV 안에는 url-test로 응답이 빠른 노드를 고정하거나, 회사 정책상 특정 국가 노드만 넣기도 합니다.
UI에서 그룹 이름을 바꿨다면 rules 쪽 인자도 같은 문자열로 맞춰야 합니다. 오타 한 글자로 코어가 기동 실패하거나 해당 줄만 무시되는 경우가 있으니, 편집 후에는 클라이언트의 프로필 검증·로그 확인을 권장합니다. 정책 그룹 유형별 차이는 YAML 규칙 분기 가이드의 proxy-groups 절을 참고하세요.
rules 예시: 레지스트리·Git·IDE를 DEV로
아래는 개념을 보여 주는 최소 예시입니다. 앞쪽에 사설 IP·LAN·국내 직결 규칙이 있다고 가정하고, npm·GitHub·Cursor 관련 접미사만 DEV로 보냅니다. 프로젝트마다 그룹 이름·순서는 다르므로, 자신의 프로필에 맞게 이름만 통일하면 됩니다.
rules: - DOMAIN-SUFFIX,registry.npmjs.org,DEV - DOMAIN-SUFFIX,npmjs.com,DEV - DOMAIN-SUFFIX,github.com,DEV - DOMAIN-SUFFIX,githubusercontent.com,DEV - DOMAIN-SUFFIX,cursor.com,DEV # ... GEOIP, MATCH 등 기존 규칙
DEV는 proxy-groups에 반드시 정의되어 있어야 합니다. 같은 요청에 두 줄이 해당해도 Clash는 위쪽 한 줄만 적용하고 멈추므로, 넓은 GEOIP나 MATCH가 위에 있으면 의도와 다른 아웃바운드로 나갈 수 있습니다. 서비스별 예외 줄을 포괄 규칙보다 위에 두는 습관이 필요합니다.
TUN·시스템 프록시와 루프백·사내망: 오탐을 줄이는 순서
TUN 모드는 OS 전체 트래픽을 가로채므로 편하지만, 127.0.0.1·localhost로 뜨는 로컬 서버·핫 리로드·컨테이너 포트 포워딩까지 건드리면 «페이지는 뜨는데 API만 실패» 같은 증상이 납니다. 일반적으로는 (1) 루프백 대역, (2) RFC1918 사설 대역, (3) 링크 로컬, (4) 도커 브리지 등을 규칙 최상단에서 DIRECT로 두고, 그다음에 개발자 프록시용 DOMAIN-SUFFIX를 넣는 순서가 안전합니다.
시스템 프록시만 켠 환경에서는 터미널의 npm·pnpm이 프록시 환경 변수를 따르지 않는 경우가 많습니다. 이때는 셸 프로필에 HTTPS_PROXY를 맞추거나, 해당 터미널만 Clash의 포트를 바라보게 정리해야 합니다. «IDE는 되는데 터미널만 안 된다»면 앱마다 프록시 적용 경로가 다르다는 신호입니다.
사내망에서 사설 DNS를 쓰는 경우, fake-ip 모드와 맞물려 규칙에 넣은 도메인이 다른 IP로 해석되면 분기가 어긋납니다. 문제가 반복되면 해당 호스트에 어떤 DNS가 쓰였는지, 결과 IP가 IP-CIDR 규칙에 먼저 걸리지 않는지 함께 확인하세요.
흔한 끊김: IDE 업데이트, 확장, 패키지 설치가 느릴 때
아래 증상은 모두 «프록시가 틀렸다»만이 아니라 DNS·TLS·노드 지역·미러 설정이 겹칠 때도 비슷하게 보입니다.
1) Cursor만 업데이트·동기화가 멈춘다
정적 자원은 직결되고 서비스 호스트만 다른 경로로 가야 하는데, 한쪽만 프록시를 탄 경우입니다. 개발자 도구·코어 로그에서 실패한 요청의 호스트를 확인하고, 해당 접미사를 DOMAIN-SUFFIX 목록에 추가합니다.
2) npm·pnpm은 되는데 브라우저의 패키지 페이지만 느리다
웹과 CLI가 서로 다른 DNS·프록시를 쓰는 경우입니다. 브라우저 확장·보안 소프트웨어가 HTTPS를 가로채면 TLS 오류와 비슷한 메시지가 나기도 합니다.
3) GitHub tarball만 타임아웃에 가깝다
github.com과 objects.githubusercontent.com이 서로 다른 규칙에 걸리거나, 한쪽만 느린 노드로 나가는 경우입니다. 두 접미사를 같은 정책 그룹에 두고 노드를 맞추면 안정되는 경우가 많습니다.
4) 로컬 API는 되는데 컨테이너 안에서만 실패한다
Docker Desktop 등에서 host.docker.internal·브리지 IP가 TUN 규칙과 충돌할 수 있습니다. 컨테이너 네트워크 모드·추가 사설 대역을 DIRECT 목록에 넣었는지 확인하세요.
ChatGPT·OpenAI 분기 글과 어떻게 짝을 이루나요?
이전 글 ChatGPT·OpenAI API 분기는 생성형 AI 웹·API 호스트 묶음에 초점을 맞췄습니다. 본 글은 Cursor·npm·pnpm·Git 호스팅처럼 일상 개발 도구 체인에 가깝습니다. 두 묶음을 각각 AI와 DEV로 나누면, 노드 선택과 장애 대응을 용도별로 나누기 쉽습니다. 코어 교체·프로토콜 활성화는 미호모 코어 업그레이드 가이드와 연결해 읽으면 설정 흐름이 자연스럽습니다.
마무리
2026년에도 프론트엔드·Node 생태는 패키지 설치와 IDE 업데이트가 겹치는 순간에 네트워크 병목이 드러납니다. Clash에서는 분기 규칙으로 레지스트리·Git·IDE 관련 접미사를 정하고, 정책 그룹으로 그 묶음이 쓸 아웃바운드를 고르게 만들면, 일상 브라우징과 개발 트래픽을 한 프로필 안에서 정리할 수 있습니다. 증상이 남으면 규칙만 의심하기보다 DNS·노드·TUN 예외·터미널 프록시 설정을 함께 보는 것이 중요합니다.
같은 Clash 계열도 GUI와 머지 방식은 제품마다 다르지만, 최종적으로 코어가 읽는 YAML 한 장을 기준으로 생각하면 디버깅이 빨라집니다. 검증된 클라이언트에서 프로필을 한 번 맞춰 두면 장기적으로는 수동 편집보다 편한 경우가 많습니다.