2026 개발자에게 꼭 필요한 Clash 분류: Cursor·GitHub를 빠르게 쓰는 실측 절차

① 왜 「전부 VPN」보다 Clash 분류가 개발 워크플로에 맞을까

상용 VPN은 편하지만, 모든 앱·모든 목적지를 같은 터널에 넣는 경우가 많습니다. 반면 Clash(Mihomo) 계열은 rules로 목적지를 나누고, proxy-groups로 어떤 노드로 보낼지 고를 수 있습니다. 그래서 국내 뱅킹·사내 VPN·로컬 테스트 서버는 DIRECT로 두고, GitHub와 Cursor 관련 호스트만 PROXY로 보내는 식의 스플릿 라우팅이 가능합니다.

이 접근은 「AI 도구 자체를 설명한다」가 아니라, 에디터·CLI·브라우저가 실제로 붙는 호스트를 기준으로 네트워크를 정리한다는 뜻입니다. 프록시 그룹 설계가 처음이면 프록시 그룹(proxy-groups) 가이드에서 이름 짓기와 중첩부터 맞춰 두면 이후 규칙 추가가 훨씬 수월합니다.

② GitHub·저장소·패키지 레지스트리로 자주 나오는 도메인

실무에서는 단순히 github.com만이 아니라 아래와 같은 호스트가 함께 등장합니다. 지역·ISP에 따라 지연이 크게 달라지므로, 규칙에 넣을 후보로 두고 로그로 실제 매칭을 확인하는 것이 좋습니다.

• 웹·API: github.com, api.github.com, gist.github.com
• Raw·릴리스 자산: raw.githubusercontent.com, objects.githubusercontent.com, codeload.github.com
• 인증·세션: githubusercontent.com 계열(클라이언트가 리다이렉트할 때 따라감)

npm·yarn·pnpm이 패키지 tarball을 가져올 때도 위 호스트 중 하나로 이어지는 경우가 많습니다. 팀 정책상 사내 레지스트리 미러를 쓰면 일부는 국내로 빠지므로, 반드시 프록시가 필요한 호스트만 골라 넣는 편이 대역폭과 지연 모두에 유리합니다.

③ Cursor(에디터) 쪽에서 자주 지목되는 경로

Cursor는 Electron 기반 데스크톱 앱으로 동작하며, 업데이트·라이선스·AI 기능에 따라 전용 호스트로 나갑니다. 정확한 목록은 버전마다 바뀔 수 있으므로, 이 글에서는 고정된 도메인 표 대신 잡는 방법을 우선합니다. 우선 클라이언트 공지·문서에 나온 베이스 도메인(예: cursor.com, cursor.sh 등)을 후보에 넣고, 안 되는 경우 앱 로그·시스템 프록시 로그·Clash 로그에서 실제 요청 호스트를 확인해 규칙을 보강합니다.

Windows와 macOS에서는 프로세스 이름 기반 규칙이 특히 유용합니다. 에디터 전체를 한 그룹으로 묶어 두면, 새로운 서브도메인이 생겨도 앱에서 나가는 연결은 같은 정책을 타는 경우가 많습니다. 다만 터미널에서 돌리는 git·npm은 별도 프로세스이므로, 필요하면 규칙 순서에서 PROCESS-NAME과 DOMAIN을 함께 쓰는 패턴을 검토합니다. 세부 문법은 사용자 정의 규칙 튜토리얼에 정리된 예시와 맞춰 보시면 됩니다.

④ 최소 규칙 세트: 전체 트래픽을 늘리지 않기

목표는 「필요한 곳만 PROXY」입니다. 아래는 개념 예시이며, 실제 프로필의 그룹 이름(PROXY 대신 🚀 선택 등)에 맞게 바꿔 써야 합니다. 주석은 설정 파일 안에서는 영어로 두는 것이 일반적입니다.

rules:
  # Dev tools — send only these through proxy when using a selective policy
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY
  - DOMAIN-SUFFIX,github.io,PROXY
  - DOMAIN-SUFFIX,cursor.com,PROXY
  - DOMAIN-SUFFIX,cursor.sh,PROXY
  # Optional: narrow process-based rules on desktop
  - PROCESS-NAME,Cursor.exe,PROXY
  - PROCESS-NAME,Cursor,PROXY
  # Everything else: do not force through tunnel by default
  - MATCH,DIRECT

위 예시는 맨 아래를 DIRECT로 두는 공격적인 최소화입니다. 만약 DNS 조회만 로컬에서 실패한다면 rules 앞단의 DNS 설정과 fake-ip 모드, 그리고 TUN 모드 심화 글에서 다루는 DNS 라우팅을 함께 봐야 합니다. 반대로 아무 것도 안 열린다면 마지막 규칙을 PROXY로 바꾼 「안전하지만 무거운」 프로필과 비교해 보는 것이 디버깅에 도움이 됩니다.

⑤ TUN과 시스템 프록시: IDE·터미널에서 무엇이 달라지나

시스템 프록시만 켜면, 프록시를 존중하는 앱(많은 GUI 앱·일부 CLI)만 터널을 탑니다. 반면 TUN 모드는 가상 NIC 쪽으로 트래픽을 끌어와 규칙 매칭을 더 일관되게 적용할 수 있습니다. 개발자 입장에서는 Go·Rust 도구·커스텀 바이너리가 시스템 프록시를 무시하는 경우가 있어, 증상에 따라 TUN을 켜고 rules로 DIRECT를 넓게 잡는 편이 낫습니다.

TUN을 켰을 때 사내 VPN·Zero Trust 에이전트와 충돌할 수 있으므로, 회사 기기에서는 IT 정책을 먼저 확인해야 합니다. 충돌이 나면 분할 터널 옵션이나 특정 앱만 예외 같은 OS 측 설정과 Clash 규칙을 함께 조정해야 합니다.

⑥ 실측 절차: 로그로 「맞는 규칙」을 확인하기

1. 베이스 프로필 백업: 편집 전 YAML 또는 클라이언트 내보내기 파일을 저장합니다.
2. 단일 목적지 테스트: 브라우저로 github.com에 접속한 뒤 Clash 로그에서 매칭된 RULE과 체인을 확인합니다.
3. Cursor 실행 후 반복: 에디터를 켠 상태에서 동일하게 로그를 보며, 빠진 DOMAIN-SUFFIX를 추가합니다.
4. CLI 분리 점검: 터미널에서 git clone 또는 패키지 설치를 시도하고, 필요하면 해당 바이너리용 PROCESS-NAME을 추가합니다.
5. 지연 측정: 같은 작업을 DIRECT만 켠 경우·프록시만 켠 경우로 나눠 체감과 로그 타임스탬프를 비교합니다.

이 순서는 추상적인 속도 이야기가 아니라, 독자가 직접 재현할 수 있는 체크리스트입니다. 규칙이 길어질수록 rule-providers로 외부 목록을 쪼개 두면 유지 보수가 쉬워집니다.

⑦ DNS·HTTPS·SNI: API가 간헐적으로 끊길 때

브라우저에서는 되는데 CLI만 실패하거나, 반대로 특정 API만 타임아웃이 난다면 DNS가 흔한 원인입니다. fake-ip를 쓰는 프로필에서는 조회 경로가 기대와 다를 수 있으니, 문제가 지속되면 redir-host 계열과 비교하거나 DNS 서버 목록을 명시적으로 잡습니다. 또한 일부 환경에서는 IPv6 우선으로 나갔다가 막히는 경우가 있어, OS나 Clash 쪽에서 IPv6 처리 방식을 통일하는 것도 점검 항목입니다.

이 단계는 감으로 넘기기보다 TUN·DNS 심화 글의 체크 순서를 따라가면 시간을 덜 씁니다.

⑧ 국내 서비스·캐시·사내 레지스트리는 DIRECT로 두기

개발자라도 모든 해외 SaaS만 쓰는 것은 아닙니다. 사내 npm 미러, 컨테이너 레지스트리, 한국 CDN에 붙는 트래픽은 불필요하게 프록시를 타면 지연만 늘어납니다. 가능하면 도메인 단위로 DIRECT를 명시하고, 나중에 로그로 잘못 분류된 것만 PROXY 쪽으로 옮깁니다.

보안 소프트웨어·엔드포인트 에이전트가 로컬 MITM을 걸면 HTTPS 인증서 오류가 날 수 있습니다. 이때는 프록시 문제가 아니라 신뢰 저장소·기업 루트 인증서 쪽을 먼저 의심해야 합니다.

⑨ Clash와 VPN의 차이를 다시 짚으며

「전부 암호화된 터널」에 가깝게 쓰고 싶다면 상용 VPN이 맞을 수 있고, 호스트·앱 단위로 정책을 쪼개고 싶다면 Clash 쪽이 유리한 경우가 많습니다. 두 접근을 혼동하지 않도록, 개념 비교는 Clash와 VPN의 차이 글을 참고하면 선택 기준이 분명해집니다.

⑩ 정리: 핫한 도구 이름보다 「재현 가능한 분류」가 핵심

이 글은 Cursor나 GitHub라는 이름을 붙인 개발자 네트워크 실전 패턴을 다룹니다. 요약하면, 필요한 도메인·프로세스만 PROXY로 보내고, 나머지는 DIRECT로 두어 대역폭과 정책 부담을 줄이며, 로그로 규칙을 검증하는 것입니다. 처음 Clash를 쓴다면 Clash 입문 튜토리얼에서 프로필 구조를 익힌 뒤 이 글의 순서를 적용하면 설정이 훨씬 덜 어지럽습니다.

장기적으로는 규칙 기반 프록시가 반복 작업마다 같은 정책을 재사용할 수 있어, 일회성 VPN보다 업무 패턴에 맞춘 안정감을 주는 경우가 많습니다. 설치와 최신 클라이언트 안내는 저장소 릴리스만 쫓기보다 사이트의 안내를 따르는 편이 버전 혼선이 적습니다. → Clash를 무료로 내려받고, Cursor·GitHub 위주로 분류 규칙을 맞춰 보세요.