증상부터 짚기: 왜 AI 개발 도구만 자꾸 끊길까

브라우저는 잘 되는데 Cursor IDE나 GitHub Desktop, 혹은 터미널의 git pull만 유난히 느리거나 타임아웃이 난다면, 원인이 반드시 「노드 품질」만은 아닙니다. 최근 워크플로는 로컬 앱 하나가 수십 개의 호스트와 API에 동시에 의존하고, 그중 일부는 지역·회선·DNS 응답에 따라 직접 연결이 빠르고, 또 다른 일부는 안정적인 중계 경로가 필요한 경우가 많습니다.

문제는 많은 사용자가 Clash를 「전부 프록시」 또는 「거의 전부 직접 연결」처럼 단일 기본값에 가깝게 쓰면서, 개발 도구 전용 예외를 두지 않는다는 점입니다. 그 결과 GitHub의 정적 자원은 빠른데 API만 막히거나, 반대로 마켓플레이스는 되는데 Cursor 인증·업데이트 채널만 끊기는 식으로 부분 실패가 반복됩니다.

네트워크 정책과 법규는 국가·기관마다 다릅니다. 본문은 기술적 분류·연결 경로 설명에 한정하며, 허용된 용도와 본인 책임 범위 안에서만 적용하시기 바랍니다. Clash 계열의 기본 흐름은 Clash 사용 문서와 함께 보시면 이해가 빠릅니다.

스플릿 터널 관점: 「전역」 대신 「개발 스택」만 골라 보내기

스플릿 터널은 터널 안으로 넣을 트래픽과 밖으로 둘 트래픽을 나누는 개념입니다. Clash에서는 이를 rules의 매칭 순서와 정책(DIRECT, 특정 proxy-groups 등)으로 구현합니다. 핵심은 「앱 이름」만이 아니라 실제로 붙는 도메인·SNI·IP가 무엇인지 파악하고, 그 목록을 규칙 상단에 두어 먼저 결정되게 하는 것입니다.

개발자에게 특히 중요한 이유는, IDE와 CLI가 HTTP/2·긴 연결·대용량 패키지를 동시에 쓰기 때문에, 잘못된 경로 하나만 걸려도 체감이 「전체가 먹통」처럼 느껴지기 때문입니다. 반대로 GitHub의 raw 미러와 API, Cursor의 업데이트·에이전트 통신을 각각 의도한 그룹으로내면, 나머지 일상 트래픽은 기존 정책을 유지한 채로 안정성만 올릴 수 있습니다.

어떤 호스트를 먼저 적을까: GitHub·마켓·Cursor 계열

정확한 호스트는 제품 업데이트마다 늘거나 바뀔 수 있으므로, 아래는 출발점으로 쓰는 패턴입니다. 운영 중에는 클라이언트 로그나 패킷 캡처로 실제 접속 대상을 한 번씩 확인해 목록을 다듬는 것이 안전합니다.

  • GitHub 본체·API: github.com, api.github.com, objects.githubusercontent.com, codeload.github.com 등은 clone·릴리스·LFS·패키지 다운로드에 자주 등장합니다.
  • 원본·에셋: raw.githubusercontent.com, gist.github.com 등은 스크립트·설정 조각을 가져올 때 필수인 경우가 많습니다.
  • VS Code 확장 생태: Microsoft 마켓(marketplace.visualstudio.com 등)과 Open VSX(open-vsx.org)는 확장 검색·설치 경로가 갈라질 수 있습니다.
  • Cursor 계열: 공식 도메인·업데이트·인증·모델 게이트웨이는 제품 버전에 따라 달라질 수 있어, 증상이 날 때의 로그를 기준으로 DOMAIN-SUFFIX를 추가하는 편이 정확합니다.

한 번에 전부 외우려 하기보다, 실패한 기능 한 가지를 골라 그때의 호스트만 규칙에 올리고 재시험하는 방식이 디버깅 비용을 줄입니다. 외부 RULE-SET을 쓰는 구조는 Rule Provider 가이드에서 다룬 대로 유지보수에 유리합니다.

YAML 스케치: DOMAIN 규칙과 그룹 이름

아래는 이해를 돕기 위한 축약 예시입니다. AI_DEV는 본인 프로필의 proxy-groups 이름으로 바꾸고, 직접 연결이 더 나은 호스트는 DIRECT로 두는 식으로 조정하세요. 코어·GUI에 따라 지원 키워드가 조금씩 다를 수 있습니다.

# Split-tunnel style rules for dev stack (comments in English per project convention)
rules:
  # Put narrow exceptions above broad rules
  - DOMAIN-SUFFIX,open-vsx.org,AI_DEV
  - DOMAIN-SUFFIX,visualstudio.com,AI_DEV
  - DOMAIN-SUFFIX,azureedge.net,AI_DEV
  - DOMAIN-SUFFIX,github.com,AI_DEV
  - DOMAIN-SUFFIX,githubusercontent.com,AI_DEV
  - DOMAIN-SUFFIX,githubassets.com,AI_DEV
  - DOMAIN-KEYWORD,github,AI_DEV
  # Add Cursor-related suffixes you observe in logs, e.g.:
  # - DOMAIN-SUFFIX,cursor.com,AI_DEV
  - MATCH,PROXY_OR_FALLBACK

위 예시에서 MATCH 한 줄은 기존 프로필의 마지막 규칙을 대신하는 자리입니다. 실제 파일에서는 이미 쓰고 있는 GEOIP·RULE-SET·MATCH 순서를 유지한 채, 개발 스택 블록만 위쪽에 끼워 넣는 방식이 안전합니다. 규칙이 길어질수록 순서가 곧 정책이라는 점을 잊지 마세요.

우선순위와 충돌: 위에서 아래로 첫 매칭이 이긴다

Clash 계열은 rules를 위에서 아래로 읽다가 처음 맞는 한 줄에서 결정합니다. 따라서 「GitHub는 프록시」라고 적어 놓았는데 그보다 위에 GEOIP,CN,DIRECT 같은 넓은 규칙이 있으면, 의도와 다른 결과가 나올 수 있습니다. 개발 스택용 규칙은 보통 GEOIP·대형 RULE-SET보다 위에 두되, 광고 차단·사내망·결제 앱 직통 같은 더 좁은 안전 예외는 그보다 또 위에 둡니다.

또 하나의 흔한 함정은 같은 도메인이 CDN 뒤에서 여러 IP로 풀리는 경우입니다. 한 번은 빠르게 열렸다가 다음 요청은 다른 PoP로 가며 느려지는 현상은, 규칙만으로 100% 설명되지 않을 수 있어 DNS 모드와 fake-ip 설정을 함께 봐야 합니다. DNS와 누수 방지는 DNS 누수 방지 가이드에서 단계별로 정리되어 있습니다.

프로세스 규칙: 앱 단위로 더 단단히 묶기

일부 Mihomo(Clash Meta) 환경과 GUI는 프로세스 이름 기반 규칙을 지원합니다. 예를 들어 특정 편집기 실행 파일이나 git·gh CLI만 별도 그룹으로 보내면, 브라우저 기본 정책을 건드리지 않고도 개발 트래픽만 분리할 수 있습니다. 다만 프로세스 규칙은 OS·샌드박스·권한에 민감하고, 자동 업데이트로 실행 파일 경로가 바뀌면 매칭이 깨질 수 있으므로 도메인 규칙과 병행하는 편이 현실적입니다.

TUN 모드나 시스템 프록시를 켠 상태에서는 앱이 시스템 스택을 타는지, 자체 인증서 저장소를 쓰는지에 따라 증상이 달라집니다. Windows에서 TUN·드라이버 이슈가 겹칠 때는 Windows TUN 문제 해결 글의 점검 순서를 참고하세요.

검증 루틴: 로그·지연·재시도 줄이기

규칙을 바꾼 뒤에는 다음 순서로 확인하면 시간을 아낄 수 있습니다. 첫째, 동일한 git fetch나 확장 설치를 반복하며 어느 호스트에서 멈추는지 로그에 남깁니다. 둘째, 문제 호스트만 임시로 다른 그룹이나 DIRECT로 옮겨 한 변수씩 줄입니다. 셋째, url-test·fallback 그룹을 쓰는 경우 지연 임계값이 너무 공격적이면 짧은 끊김이 잦아지므로, 속도 최적화 팁에서 다룬 그룹·DNS 튜닝과 함께 보는 것이 좋습니다.

Copilot·클라우드 에이전트처럼 장시간 스트리밍에 가까운 API는 중간 프록시의 유휴 타임아웃과도 맞물립니다. 이때는 노드 품질만 바꾸기보다, 해당 API 도메인을 안정적인 전용 그룹으로 묶고 keep-alive 친화적인 프로필을 쓰는 쪽이 효과적인 경우가 많습니다.

보안·컴플라이언스 메모

회사망이나 클라우드 계약 하에서는 분할 터널 자체가 정책 위반일 수 있습니다. 또한 규칙 파일·RULE-SET URL은 본질적으로 외부 정책을 가져오는 통로이므로, 출처를 확인하지 않으면 민감한 트래픽이 예기치 않은 경로로 나갈 위험이 있습니다. 팀 단위로 쓸 때는 허용 도메인 목록을 문서화하고, 변경 시 리뷰를 거치는 편이 안전합니다.

오픈 소스 코어의 빌드와 이슈 트래커는 Mihomo GitHub 저장소에서 확인할 수 있습니다. 다만 클라이언트 설치 패키지는 배포 신뢰를 위해 공식 다운로드 페이지를 우선하는 편이 좋습니다.

정리

AI 코딩 도구와 GitHub는 「한 사이트」가 아니라 많은 호스트의 묶음입니다. Clash의 강점은 이 묶음을 도메인·IP·프로세스 단위로 나눠 각각에 맞는 경로를 주는 데 있으므로, 전역 스위치 하나에 의존하기보다 개발 스택 전용 규칙 블록을 설계하는 쪽이 타임아웃과 부분 실패를 줄이는 지름길입니다.

기억할 점: 규칙은 위에서 아래로 첫 매칭이 승리합니다. 목록은 제품 업데이트와 함께 바뀌므로, 로그로 실제 호스트를 확인하며 좁은 예외를 위에 쌓아 가세요.

규칙형 클라이언트는 한번 구조를 잡아 두면 IDE·CLI·브라우저가 섞인 환경에서도 정책을 한눈에 유지하기 쉽습니다. GUI와 코어를 최신에 가깝게 맞춰 두면 파서와 provider 동작도 안정적인 편입니다.

→ Clash를 무료로 내려받아 개발 스택 분류 규칙을 프로필에 반영해 보세요