1. 왜 GitHub Copilot 트래픽을 호스트 단위로 나눠야 하나
VS Code 안에서 Copilot을 쓰면 브라우저로 여는 github.com 세션과는 별개로, 확장 프로그램이 copilot-proxy.githubusercontent.com 같은 API 게이트웨이와 통신합니다. 동시에 조직 정책·구독 종류에 따라 *.githubcopilot.com 아래의 api.individual·api.business·api.enterprise 호스트로 라우팅이 갈라지기도 합니다. 네트워크 변경 공지가 올라오는 시즌에는 허용 목록을 그대로 두었는데도 클라이언트만 옛 엔드포인트를 물어보는 식의 불일치가 잠깐씩 생길 수 있습니다.
Clash의 분류 규칙은 이런 “한 서비스처럼 보이지만 실제로는 여러 SNI” 문제를 정면으로 다룹니다. 일부 연결만 다른 노드를 타거나 DIRECT로 빠지면 증상은 간헐적 끊김·401 반복·긴 TLS 핸드셰이크처럼 보입니다. 먼저 실패한 요청의 호스트 문자열을 확보하고, 규칙 테이블 위쪽에 구체 규칙을 두는 순서가 디버깅 비용을 줄입니다.
클라이언트 UI 차이는 Windows용 Clash 클라이언트 비교를 참고하고, 공통 문법은 설정 가이드와 함께 읽으면 프로필 수정 속도가 빨라집니다.
2. GitHub 문서에 나오는 Copilot 관련 호스트
GitHub는 Copilot용 방화벽·프록시 허용 목록을 문서로 제공합니다. 요약하면 다음 범주가 반복해서 등장합니다. 정확한 최신 목록은 항상 공식 문서를 따르세요.
- 제안·채팅 백엔드:
copilot-proxy.githubusercontent.com,origin-tracker.githubusercontent.com등*.githubusercontent.com계열 - Copilot API 호스트:
*.githubcopilot.com— 조직·개인·엔터프라이즈 등 플랜에 따라 세부 호스트가 다름 - 일반 GitHub: 웹·REST·일부 모델 기능은
github.com,api.github.com등과 함께 설명되는 경우가 많음
2026년 초·중반 changelog에는 Copilot coding agent의 네트워크 구성 변경이 여러 번 안내되었습니다. 플랜별로 api.business.githubcopilot.com, api.enterprise.githubcopilot.com, api.individual.githubcopilot.com 같은 이름이 강조되고, 레거시 단일 엔드포인트를 허용 목록에서 제거하라는 안내도 함께 나옵니다. 장기적으로는 “Copilot = 한 줄짜리 도메인 규칙”으로 끝내기 어렵다는 뜻입니다.
3. VS Code 업데이트·403 오류와 네트워크 레이어
GitHub Copilot VS Code 확장은 에디터 버전·확장 버전·백엔드 롤아웃이 동시에 움직입니다. 예컨대 changelog에 “Copilot in VS Code” 기능 추가나 동작 변경이 올라오는 날에는 클라이언트가 새 호스트를 두드리기 시작할 수 있습니다. 로컬에서는 업데이트 직후 처음만 실패하고 재시도에 성공하는 패턴도 흔합니다.
HTTP 403이나 인증 오류는 순수 네트워크 문제가 아니라 조직 정책·토큰 만료·계약 상태일 때도 많습니다. 그럼에도 동일 계정이 브라우저에서는 되고 VS Code에서만 실패한다면, 에디터 트래픽이 다른 노드로 나가거나 회사 가상 데스크톱 안에서 시스템 프록시가 비어 있는 경우를 의심할 수 있습니다. Agents(코딩 에이전트)는 장시간 스트리밍과 추가 MCP 호출을 함께 쓰므로 중간 프록시의 유휴 타임아웃에 더 잘 걸립니다.
Windows 전역 라우팅 이슈는 TUN·방화벽 트러블슈팅과 같이 보는 편이 빠릅니다.
4. Clash(Mihomo) 분류 규칙 예시와 순서
RULE 모드에서는 위에서 아래로 첫 매칭만 적용됩니다. GitHub Copilot 전용 그룹 이름(예: GITHUB-COPILOT)을 proxy-groups에 정의한 뒤, 일반 지역 규칙보다 위에 두세요. 아래는 이해를 위한 스켈레톤이며 실제 운영에서는 공식 문서 목록과 본인 로그를 합쳐 수정해야 합니다.
rules:
- DOMAIN-SUFFIX,github.com,GITHUB-COPILOT
- DOMAIN-SUFFIX,api.github.com,GITHUB-COPILOT
- DOMAIN-SUFFIX,githubusercontent.com,GITHUB-COPILOT
- DOMAIN,copilot-proxy.githubusercontent.com,GITHUB-COPILOT
- DOMAIN-SUFFIX,githubcopilot.com,GITHUB-COPILOT
- DOMAIN-KEYWORD,githubcopilot,GITHUB-COPILOT
- MATCH,OthersDOMAIN-KEYWORD는 편하지만 오탐이 생기기 쉬워, 장기적으로는 DOMAIN-SUFFIX와 로그에서 확인한 전체 호스트명(DOMAIN) 위주로 좁히는 것이 좋습니다. 이미 받아 둔 글로벌 규칙 세트가 있다면 “구독 규칙 파일”과 “개발자 한 줄 덮어쓰기”의 include 순서를 점검하세요. 상위에서 DIRECT나 다른 지역으로 빠지면 아래의 Copilot 줄은 실행되지 않습니다.
proxy-groups 설계
GITHUB-COPILOT에는 select를 두고 출구를 수동으로 고정해 두면 A/B 비교가 쉽습니다. 자동 url-test만 믿으면 혼잡 시간대에 계속 같은 불량 노드로 붙는 경우가 있어, 끊김이 잦을 때는 fallback이나 수동 전환을 병행하는 편이 낫습니다.
5. GitHub Models API·에이전트 트래픽을 어떻게 묶을까
GitHub Models API를 호출하는 흐름은 기능 플래그와 계정 설정에 따라 api.github.com 위주일 수도 있고, 별도 게이트웨이가 추가될 수도 있습니다. 원칙은 하나입니다. 실패한 요청의 URL에서 호스트 부분만 떼어 규칙에 넣습니다. Clash는 일반적인 HTTPS 트래픽에서 경로 단위로 세밀하게 나누기 어렵기 때문에 호스트 단위 추상화가 맞습니다.
에이전트 시나리오에서는 한 세션 안에 Copilot 백엔드·Git 저장소·패키지 레지스트리·선택한 MCP 서버가 섞입니다. Copilot 본체 호스트를 안정 노드로 고정해 두어도 MCP만 다른 지역으로 나가면 체감상 “에이전트가 멈춘다”고 느껴질 수 있습니다. 이때는 범용 MCP 가이드와 규칙을 함께 맞춰야 합니다.
6. 노드 선택·DNS·TUN을 함께 보는 이유
노드 선택은 ping 수치만으로 결정하기 어렵습니다. 특정 출구가 GitHub 엣지까지의 라우팅이 안정적일 수도 있고, 반대로 특정 ISP 구간에서 손실이 클 수도 있습니다. Copilot 규칙에 묶인 트래픽만 다른 그룹으로 보내 비교하면 나머지 업무 트래픽에는 영향을 주지 않습니다.
DNS가 흔들리면 프록시가 살아 있어도 애플리케이션은 먼저 실패합니다. fake-ip를 쓰는 프로필이라면 도메인별 예외와 매핑 타이밍을 확인하고, OS 수준 DNS over HTTPS와 충돌하지 않는지 봅니다. 상세 절차는 DNS fallback·fake-ip 글을 참고할 수 있습니다.
TUN 모드에서는 로컬 브리지·split routing 예외가 VS Code 자식 프로세스까지 일관되게 적용되는지 확인해야 합니다. macOS는 시스템 프록시·네트워크 확장 글과 설정이 맞물립니다.
7. Cursor·GitHub 타임아웃 글·MCP 글과 어떻게 구분하나
Cursor와 GitHub 타임아웃 글은 Cursor IDE 생태계와 일반 Git 호스트(objects.githubusercontent.com 등) 쪽 비중이 큽니다. 이번 주제는 공식 GitHub Copilot in VS Code 확장과 그에 수반되는 copilot-proxy·githubcopilot.com 계열에 초점을 맞춘다는 점이 다릅니다. 두 글 모두 “개발자 도구 + GitHub”지만 검색 의도와 규칙 예시가 겹치지 않게 나누었습니다.
원격 MCP 호스트 분류 글은 MCP 서버 URL을 규칙으로 고정하는 보편 패턴을 다룹니다. Copilot 에이전트가 MCP를 붙여도, 인증·모델 라우팅의 상당 부분은 여전히 GitHub 쪽 호스트가 담당하는 경우가 많으므로 두 설정을 동시에 유지하되 중복 매칭과 순서만 정리하면 됩니다.
8. 증상별 점검표
아래는 현장에서 자주 쓰는 우선순위 표입니다. 숫자는 권장 순서입니다.
| 증상 | 먼저 의심할 것 | 조치 |
|---|---|---|
| 브라우저 GitHub는 되는데 Copilot 제안만 안 됨 | copilot-proxy·githubcopilot.com 규칙 누락·하위 매칭 |
호스트 로그 확보 후 규칙 상단에 추가·노드 전환 |
| 로그인 루프·동기화 실패 | github.com·인증 쿠키 경로, 다른 노드 혼선 |
동일 그룹으로 묶기·브라우저 쿠키·SSO 정책 확인 |
| 에이전트만 타임아웃 | 장시간 스트림·MCP·중간 프록시 유휴 타임아웃 | MCP 규칙·fallback 노드·기업 프록시 예외 |
| 간헐적 TLS 오류 | 불안정 출구·SNI 필터·DNS 흔들림 | fallback·DNS 서버 고정·split DNS 검토 |
TLS 관련 일반 논의는 TLS 핸드셰이크 타임아웃 글과 연결해 읽으면 원인 분기가 수월합니다.
9. 자주 묻는 질문
VS Code에서만 http.proxy를 따로 써야 하나요?
환경마다 다릅니다. 시스템 프록시를 켠 Clash와 VS Code 설정이 서로 다른 포트를 가리키면 “일부 창만 실패”가 납니다. http.proxy·http.proxyStrictSSL·NO_PROXY 목록을 Mixed Port와 대조하세요.
GitHub Changelog의 Copilot in VS Code 항목은 어디에 쓰나요?
기능이 추가될 때 어떤 클라이언트 동선이 바뀌는지 힌트를 줍니다. 네트워크 장애 진단과 직결되지 않더라도 “업데이트 직후에만 잠깐 깨졌다”는 보고와 맞물리면 백엔드 롤아웃 가설을 세울 수 있습니다.
Windows에서 git push는 되는데 Copilot 채팅만 불안정합니다.
Git SSH 경로와 HTTPS 확장 트래픽이 다른 규칙에 걸렸을 가능성이 큽니다. 연결 로그에서 각 호스트가 어떤 정책에 매칭됐는지 확인하세요.
규칙을 많이 넣으면 느려지나요?
수천 줄 규모에서도 대부분 무시할 만하지만, 비효율적인 DOMAIN-KEYWORD 남발은 오탐과 디버깅 비용을 키웁니다. provider 파일로 나누고 자주 바꾸는 줄만 로컬에 두는 편이 낫습니다.
10. 요약
GitHub Copilot VS Code는 github.com·copilot-proxy.githubusercontent.com·githubcopilot.com·api.github.com 등 여러 호스트를 오가며 동작합니다. 2026년 changelog에서 강조된 플랜별 API 호스트를 허용 목록과 함께 관리하지 않으면 “왜 이번 주만 자꾸 끊기지?” 같은 증상이 반복됩니다. Clash에서는 이들을 한 분류 규칙 묶음으로 올려 두고 노드·DNS·VS Code 프록시 설정을 한 번에 맞추는 방식이 가장 재현성이 높습니다.
시중 일부 도구는 단순히 “전체 트래픽을 한 출구로”만 보낼 수 있거나 규칙 세밀도가 부족해 개발자 시나리오에 맞추기 어렵습니다. 반면 Clash·Mihomo 계열은 호스트 단위 정책과 구독 규칙 프로바이더를 조합하기 쉬워 Copilot·Git·모델 호출을 같은 프로필 안에서 단계적으로 다듬기 좋습니다. 설치 파일은 공식 다운로드 페이지에서 받는 것이 혼선이 적습니다.
→ Clash를 무료로 내려받아 Copilot·GitHub 트래픽 분류와 노드 정책을 환경에 맞게 조정해 보세요