확장 마켓·GitHub·MS가 한 앱처럼 보이지만 트래픽은 갈라진다

Visual Studio Code에서 확장을 설치하거나 GitHub Copilot을 켤 때 사용자는 「한 앱 안의 한 흐름」으로 느끼지만, 실제 HTTPS는 여러 상표·CDN·API 엔드포인트로 나뉩니다. 마켓 메타데이터와 VSIX 패키지는 marketplace.visualstudio.com·*.vscode-cdn.net 계열로 갈 수 있고, 저장소·이슈·일부 인증은 github.com과 api.github.com로 갈라집니다. Microsoft 계정 로그인·토큰·일부 Copilot 관련 호출은 login.microsoftonline.com·login.live.com·microsoft.com 트리 아래 다른 서브도메인으로 이어집니다. Clash 규칙이 이 중 일부만 의도한 정책 그룹을 타고 나머지는 DIRECT나 느린 출구에 남으면, UI는 반쯤 열린 채 다운로드만 멈추거나 API 타임아웃만 로그에 남는 패턴이 됩니다.

연결은 위에서 아래로 규칙을 맞출 때마다 출구가 결정됩니다. 한 번의 「Copilot 켜기」에 필요한 모든 호스트가 같은 라우팅 의도(예: 모두 안정 출구, 또는 모두 직접)를 타지 않으면 TLS·HTTP 단계에서 지연이 겹칩니다. 해결은 대역폭만 늘리는 것이 아니라 도메인 분류를 실제 DevTools·Clash 로그에 나온 이름에 맞추고, DNS가 그 판단과 어긋나지 않게 맞추는 일입니다. Microsoft와 GitHub는 배포 변경이 잦으므로 커뮤니티의 고정 목록만 복붙하기보다 관측을 먼저 하세요.

ℹ 증거 먼저: VS Code에서 개발자 도구를 연 뒤 네트워크 탭에 나온 호스트명을 적고, Clash 라이브 연결 화면의 정책 적중과 대조합니다. 실패한 URL이 vscode-cdn인지 github인지 microsoftonline인지에 따라 고칠 규칙이 달라집니다.

세 덩어리: 마켓·CDN, GitHub API, MS 계정·Copilot 백엔드

운영 관점에서는 세 묶음으로 나누면 설계가 단순해집니다. (1) VS Code 확장 마켓플레이스·CDN — 검색·메타데이터·VSIX 다운로드에 쓰이는 marketplace.visualstudio.com, *.vscode-cdn.net 등. (2) GitHub·GitHub API — 웹·Git·일부 OAuth·api.github.com·raw.githubusercontent.com 등 저장소와 연동 호스트. (3) Microsoft 계정·Copilot 백엔드 — login.microsoftonline.com, login.live.com, microsoft.com 하위의 인증·제품 API·Copilot 관련 엔드포인트(환경·시기에 따라 서브도메인이 바뀔 수 있음). 한 묶음만 프록시에 잘 붙고 다른 묶음만 직행하면 「로그인만 안 됨」「확장만 받기 실패」처럼 증상이 쪼개져 보입니다.

각 묶음에 대해 직접(DIRECT)이 나은지 특정 정책 그룹(PROXY)이 나은지는 회선·지역·회사 정책에 따라 다릅니다. 중요한 것은 세 묶음이 서로 다른 의도로 섞이지 않게 YAML에 이름을 붙이고, 변경 시 주석으로 이유를 남기는 것입니다. 규칙 가독성은 규칙 분류 모범 사례와 함께 보는 것이 좋습니다.

Cursor 전용 글과 무엇이 다른가

이 사이트에는 Cursor·ChatGPT·Claude 등 다른 AI 도구용 분류 글이 이미 있습니다. Cursor 개발자 글은 OAuth·에디터 자식 프로세스·장시간 API 세션에 초점을 둡니다. 본문은 Microsoft가 운영하는 VS Code 마켓플레이스·GitHub·Copilot 이름 공간에 맞춘 도메인 분류를 다루므로, Cursor 글과 보완 관계이지 동일 복붙이 아닙니다. OpenAI·Anthropic 등 다른 벤더 분류가 필요하면 각각 전용 글을 참고하세요.

규칙을 다른 제품에서 가져올 때는 호스트 접미사를 그대로 믿지 말고, 본인 환경에서 나온 이름으로 다시 적습니다.

정책 그룹으로 출구 의도를 한 줄씩 고정하기

실무에서는 예를 들어 VS_MARKET·GITHUB_STACK·MS_AUTH처럼 정책 그룹 이름을 세고, 각 그룹 뒤에 붙는 프록시 선택기(select·url-test 등)를 분리합니다. VSIX 대용량 다운로드에 견디는 노드와, 짧은 핸드셰이크가 중요한 API용 노드를 같이 쓰고 싶다면 그룹을 나누되, 문서화해 두지 않으면 몇 달 뒤 자신이 왜 나눴는지 잊기 쉽습니다. 국내 쇼핑·뱅킹·사내 Git은 DIRECT에 두고 문제 이름 공간만 프록시로 보내는 구성이 흔합니다.

Microsoft 로그인은 리다이렉트 체인이 길어 login.microsoftonline.com만 맞추고 다른 하위 호스트는 빠뜨리는 경우가 있습니다. OAuth가 끼면 브라우저 창과 VS Code 내장 웹뷰가 서로 다른 출구를 탈 수 있으니, 인증에 등장하는 호스트를 로그로 모아 같은 의도로 묶였는지 확인합니다. 클라이언트 UI가 연결 로그를 잘 보여 주는지는 클라이언트 선택에서도 다룹니다.

정책 그룹은 뒤의 노드만큼만 안정적입니다. 규칙이 완벽해도 출구가 불안정하면 TLS 지연이 남습니다. 그때는 연결 로그의 timeout·TLS로 노드 건강을 먼저 의심하고, 그다음에 도메인 구멍을 좁히세요.

관측 우선·예시 DOMAIN-SUFFIX YAML

아래는 형태를 보여 주는 예시입니다. 실제 CDN·인증 호스트는 시기와 빌드에 따라 달라질 수 있으므로, 반드시 본인 환경의 DevTools·Clash 로그에서 확인한 이름을 추가하세요. DOMAIN-SUFFIX,github.com,GITHUB_STACK는 api.github.com 등 다수의 GitHub 호스트를 같은 출구로 묶는 데 자주 쓰입니다. 마켓 쪽은 DOMAIN-SUFFIX,visualstudio.com,VS_MARKET·DOMAIN-SUFFIX,vscode-cdn.net,VS_MARKET처럼 확장 배포·CDN을 한 그룹으로 묶는 패턴이 흔합니다. Microsoft 인증은 DOMAIN-SUFFIX,microsoftonline.com,MS_AUTH·DOMAIN-SUFFIX,live.com,MS_AUTH 등으로 시작해, 관측된 추가 호스트를 좁은 DOMAIN 규칙으로 보강합니다. DOMAIN-SUFFIX,microsoft.com,MS_AUTH처럼 지나치게 넓은 접미사는 다른 Microsoft 트래픽까지 끌어올 수 있어 팀 정책과 함께 검토하세요.

DOMAIN-SUFFIX가 DOMAIN-KEYWORD보다 예측 가능합니다. 키워드는 임시로만 쓰고, 확인된 접미사로 옮기세요.

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,visualstudio.com,VS_MARKET
  - DOMAIN-SUFFIX,vscode-cdn.net,VS_MARKET
  - DOMAIN-SUFFIX,github.com,GITHUB_STACK
  - DOMAIN-SUFFIX,githubusercontent.com,GITHUB_STACK
  - DOMAIN-SUFFIX,microsoftonline.com,MS_AUTH
  - DOMAIN-SUFFIX,live.com,MS_AUTH
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

MATCH가 DIRECT인 프로필에서는 목록에 없는 새 엔드포인트가 직행하다가 그 경로만 막히면 「마켓만 실패」처럼 보일 수 있습니다. 대응은 전역 프록시가 아니라 관측 기반 규칙 보강과 규칙 세트 갱신입니다.

시스템 프록시·TUN·Electron: 적용 순서와 누락

VS Code는 Electron 기반이라, OS의 시스템 프록시를 따르는 경로와 Chromium이 직접 소켓을 여는 경로가 섞일 수 있습니다. Clash 클라이언트가 「시스템 프록시 켜기」만 하면 브라우저는 잘 나가는데 VS Code 자식 프로세스·확장 호스트만 예외인 경우가 있습니다. 이때 TUN 모드는 커널 라우팅으로 트래픽을 한 레이어에서 모아, 애플리케이션이 프록시 환경 변수를 무시해도 같은 출구를 타게 하는 편이 확실합니다. 반면 기업 VPN·제로트러스트·다른 가상 어댑터와 우선순위가 겹치면 TUN이 기대대로 안 잡히기도 하니, 「시스템 프록시만」「TUN만」을 번갈아 시험해 어느 쪽이 실제로 VS Code 트래픽을 덮는지 로그로 확인하세요.

우선순위를 한 줄로 말하면, 대개 TUN(전역 라우팅) > 앱이 명시한 프록시 > 시스템 프록시 > 직접처럼 보이지만 OS·클라이언트 구현마다 다릅니다. 중요한 것은 「문서의 이론」이 아니라 Clash 연결 로그에 찍힌 정책 적중입니다. Copilot 라이선스·조직 정책 오류와 착각하지 않도록, 동일 호스트에 대해 기대한 그룹이 맞는지 먼저 확인합니다.

원격 규칙 세트·갱신·신뢰 경계

엔드포인트 변화가 빠르면 손으로 YAML만 유지하기 어렵습니다. Clash의 규칙 공급자로 원격 규칙 세트를 주기적으로 받아오면 복붙 부담을 줄일 수 있습니다. 다만 공급자는 신뢰 자산이며, 과하게 넓은 포획은 다른 트래픽까지 잡거나 직접 넣은 세부 규칙을 가릴 수 있습니다. RULE-SET을 쓸 때는 목록이 규칙 테이블의 어느 높이에 놓이는지, 넓은 차단·지오 규칙보다 위인지 아래인지를 함께 설계하세요.

구독 URL·규칙 갱신도 DIRECT나 안정 출구가 필요합니다. 갱신만 실패하면 노드 목록이 낡아 모든 사이트가 동시에 나빠 보입니다. 운영 체크는 구독·노드 유지보수 글과 같은 맥락입니다.

DNS·fake-ip와 규칙이 같이 가야 하는 이유

브라우저가 이름을 풀고 Clash가 경로를 고르는 과정이 어긋나면, 「DNS는 빨리 풀렸는데 TCP는 안 붙는다」는 패턴이 납니다. fake-ip 모드를 쓰면 로컬 해석이 단순해지지만, DOMAIN 규칙 커버리지와 스니핑·클라이언트 동작을 함께 맞출 필요가 있습니다. OS·브라우저 DoH·다른 VPN 스택을 겹치면 우선순위 싸움이 나서 증상만 복잡해집니다. FAQ에서 DNS·연결성을 먼저 정리한 뒤 규칙을 손대면 시행착오가 줄어듭니다.

VS Code 확장 호스트는 백그라운드에서 추가 요청을 열 수 있어, 한 번의 설치에도 *.blob.core.windows.net 같은 스토리지 호스트가 끼는 환경이 있습니다. 로그에 새 이름이 보이면 YAML에 DOMAIN 한 줄을 더하는 편이 안전합니다. Copilot 기능은 제품 업데이트로 엔드포인트가 바뀔 수 있으므로, 분기마다 DevTools로 샘플링하는 습관이 유지보수 비용을 줄입니다.

git·gh CLI·CI 스크립트는 VS Code UI와 다른 경로를 탈 수 있습니다. 터미널이 시스템 프록시를 무시하면 api.github.com만 DIRECT에 남아 Pull이 느려지고, IDE 안의 Copilot은 정상인 것처럼 보이는 불일치가 납니다. 동일 호스트에 대해 터미널과 IDE가 같은 정책 적중을 보는지 함께 확인하세요.

규칙 순서·광범위 RULE-SET·MATCH

위에서 아래로 먼저 맞은 규칙이 이깁니다. 광고·추적 차단용 원격 목록이 지나치게 위에 있으면 웹앱이 기다리는 분석·실험 엔드포인트를 막아 멈춘 UI를 만들 수 있습니다. 지오·IP 기반 규칙이 github.com·visualstudio.com 접미사보다 먼저 걸리면 VS Code·Copilot 트래픽이 의도와 다른 출구로 나갑니다. 원격 세트를 갱신한 뒤 깨졌다면 이전 리비전과 diff해 한 단계씩 되돌려 보세요.

MATCH는 잡히지 않은 흐름의 최종 승자입니다. 기본이 DIRECT인 구성은 국내 트래픽에 유리하지만, 벤더가 새 호스트를 빨리 추가하면 커버리지를 따라잡는 운영이 필요합니다. 모든 것을 프록시로 보내는 MATCH는 다른 목적의 트래픽까지 끌어와 부작용이 크므로, 제품별 명시 규칙과 보수적 기본값의 균형이 안전합니다.

검증: VS Code 개발자 도구·Clash 로그

재현 절차를 고정하세요. VS Code에서 확장 설치·Copilot 로그인을 시도한 뒤, 개발자 도구 네트워크 탭의 호스트명과 Clash 라이브 연결 화면의 정책 적중을 대조합니다. marketplace.visualstudio.com·vscode-cdn.net·api.github.com·login.microsoftonline.com 등이 각각 기대한 VS_MARKET·GITHUB_STACK·MS_AUTH(또는 동등 이름)인지 확인합니다. 기대와 다르면 규칙을 고치고, 정책이 맞는데도 실패하면 TLS·TCP 타임아웃 로그로 내려갑니다.

변경 이력을 한 줄이라도 남기면 미래의 자신에게 큰 도움이 됩니다. 「2026-04-11, DevTools에서 호스트 A를 확인해 vscode-cdn 또는 microsoftonline 관련 접미사 B를 추가」처럼 적으면 기기 간 프로필을 맞출 때도 실수가 줄어듭니다.

준수·서비스 약관·직장·학교 네트워크

⚠ 준수 알림: 현지 법령·서비스 약관·고용주·교육기관의 허용 사용 정책을 준수하세요. 본문은 허용된 네트워크에서의 라우팅 위생을 설명하며, 무단 접근·계정 공유·정당한 보안 통제 우회를 조장하지 않습니다.

기업·캠퍼스는 분할 터널, 강제 DNS, SSL 검사를 둘 수 있어 YAML만으로는 동일하게 재현되지 않을 수 있습니다. 기술적 경로 설계가 정책 면제를 뜻하지 않으니, 제한이 있으면 IT·관리 부서 절차를 따르는 것이 안전합니다.

맺음말: 개발자 스택은 도메인 지도가 있어야 안정한다

GitHub Copilot과 VS Code 확장 마켓은 단일 호스트 앱이 아닙니다. github.com·microsoft.com 트리와 마켓 CDN이 한 화면 경험으로 묶일 뿐이며, Clash는 그 흐름을 정책 그룹·도메인 규칙·규칙 세트로 서술하게 해 줍니다. 서술이 실제 트래픽과 다르면 사용자는 「확장 서버가 느리다」보다 먼저 API 타임아웃·반쪽 설치를 보게 되고, 원인은 종종 라우팅 불일치입니다.

생산적인 대응은 관측 기반으로 마켓·GitHub·Microsoft 인증 호스트를 덮는 규칙을 키우고, DNS를 그 결정과 정렬하며, 시스템 프록시와 TUN 중 실제로 VS Code가 따르는 쪽을 로그로 확정하고, 원격 규칙을 신뢰 경계 안에서 갱신하는 것입니다. Cursor·ChatGPT 등 다른 글과 달리 이 글은 Copilot·VS Code 마켓플레이스 생태에 맞춘 분기점을 분명히 했습니다.

→ Clash를 무료로 다운로드하고, Copilot·확장 설치가 막힐 때 호스트별 출구를 빠르게 맞춰 보세요.