1 GitHub Copilot만 따로 규칙을 두는 이유
AI 코딩 보조는 2026년에도 여전히 화제이지만, 제품마다 통신 대상이 다릅니다. Cursor는 자체·제휴 모델 호스트와 확장 마켓이 중심이고, ChatGPT 글은 openai.com·chatgpt.com 축입니다. GitHub Copilot은 이름 그대로 GitHub 인프라와 밀접합니다. 로그인·조직 정책·결제·라이선스는 github.com, 메타데이터·REST는 api.github.com, 아티팩트·프록시성 호스트는 *.githubusercontent.com 등으로 갈라집니다. «Git 한 줄 규칙»이나 거대 GEOSITE 한 덩어리에만 기대면, 브라우저는 프록시를 타고 확장 프로세스만 직행하거나 그 반대가 되어 로그인은 되는데 제안만 안 뜨는 식으로 출구가 어긋나기 쉽습니다.
Clash(Mihomo 계열)에서는 DOMAIN-SUFFIX와 Rule Provider로 위 호스트 묶음을 명시하고, 지연에 맞는 프록시 그룹 이름을 규칙에서 참조합니다. 목표는 단순 속도 자랑이 아니라, 연결 로그에 찍힌 호스트마다 기대한 정책이 걸리게 해서 간헐 타임아웃·반쪽 로딩을 줄이는 것입니다. 클라이언트가 없다면 다운로드 페이지에서 GUI를 고른 뒤 아래 조각을 프로파일에 합치면 됩니다.
2 웹 로그인·에디터 확장·API: 세 갈래를 동시에 맞추기
웹: 조직에서 Copilot을 켜거나 라이선스를 확인할 때 github.com과 리다이렉트되는 인증·설정 페이지가 등장합니다. 여기에 정적 자원·분석 스크립트가 붙을 수 있어, «API만» 좁게 프록시하면 UI 일부가 깨지거나 로그인 플로가 중간에 끊길 수 있습니다.
에디터 확장: VS Code·호환 IDE의 Copilot 확장은 백그라운드에서 GitHub API·콘텐츠 호스트에 붙습니다. 시스템 프록시만 켜도 일부 런타임은 프록시를 무시합니다. 이때는 TUN 모드로 커널 라우팅을 통일하거나, IDE·확장이 제공하는 프록시 설정을 Clash 리스닝 주소에 맞추는 편이 안전합니다.
API: 자동화·스크립트·일부 통합은 api.github.com을 향합니다. 터미널의 curl·SDK는 브라우저와 다른 경로를 탈 수 있어, «웹만 정상」 패턴이 자주 납니다. 셸 환경 변수 HTTPS_PROXY와 NO_PROXY에 github.com이 실수로 빠져 있지 않은지 함께 확인하세요.
3 도메인 묶음·DOMAIN-SUFFIX·규칙 순서
실무에서는 최소한 DOMAIN-SUFFIX,github.com과 DOMAIN-SUFFIX,githubusercontent.com으로 양 축을 잡는 것을 권장합니다. github.com 아래에는 웹·설정·일부 API 경로가 포함되고, api.github.com은 접미사 규칙으로 함께 커버되는 경우가 많습니다. 로그에 objects.githubusercontent.com·raw.githubusercontent.com·copilot-proxy.githubusercontent.com 같은 호스트가 보이면 같은 그룹으로 묶였는지 확인하세요. 서비스가 바뀌면 새 서브도메인이 추가될 수 있으므로, 주기적으로 Connections 로그를 스냅샷으로 남기는 습관이 유지보수에 유리합니다.
규칙 순서는 실수하기 쉽습니다. 맨 위의 광범위 MATCH나 «해외 전체» 줄이 GitHub 전용 규칙보다 먼저 나오면 의도와 다른 노드로 흡수되고, 반대로 DIRECT가 너무 앞이면 TLS 단계에서 끊길 수 있습니다. GitHub·Copilot 묶음은 구독이 준 큰 규칙보다 앞쪽에 두고, 디버깅 시 로그에서 github로 필터해 기대한 PROXY_GITHUB 같은 그룹이 찍히는지 확인하세요.
DNS·FakeIP 설계는 DNS 유출 방지 가이드와 맞추는 것이 좋습니다. 이름 해석과 실제 TCP 출구가 어긋나면 가끔만 실패하는 것처럼 보여 원인 추적이 어려워집니다.
4 Rule Provider와 rules: 예시
아래는 개념 스니펫입니다. proxy-groups 이름·노드는 본인 프로파일에 맞추고, rule-providers의 url은 신뢰하는 목록으로 바꾸세요. 원격 집합이 없으면 RULE-SET 줄을 빼고 DOMAIN-SUFFIX만으로도 시작할 수 있습니다.
# Example only — merge with your full profile
proxy-groups:
- name: PROXY_GITHUB
type: select
proxies:
- AUTO-BEST
- DIRECT
rule-providers:
github-stack:
type: http
behavior: classical
url: "https://example.com/rules/github-copilot.txt"
path: ./ruleset/github-copilot.yaml
interval: 86400
rules:
- RULE-SET,github-stack,PROXY_GITHUB
- DOMAIN-SUFFIX,github.com,PROXY_GITHUB
- DOMAIN-SUFFIX,githubusercontent.com,PROXY_GITHUBDOMAIN-KEYWORD,git는 무관한 사이트까지 잡을 수 있습니다. 접미사·검증된 RULE-SET을 우선하고 KEYWORD는 임시 진단용으로만 쓰세요.
5 VS Code·IDE와 시스템 프록시·TUN
Windows·macOS에서 Clash가 시스템 프록시를 켜도, Electron 기반 에디터가 그 설정을 따르지 않는 경우가 있습니다. Copilot 패널만 로딩이 길고 나머지 확장은 정상이면, 트래픽이 OS 프록시 밖으로 새는지 의심해 보세요. TUN으로 전체 트래픽을 규칙 엔진에 넣으면 이런 불일치가 줄어듭니다. 다만 회사 VPN과 이중 터널이 되면 지연이 커질 수 있으니, 업무 정책과 충돌하지 않는 범위에서만 켜세요.
확장 마켓 설치 자체가 막히는 현상은 marketplace.visualstudio.com 등 Microsoft 마켓 호스트가 별도로 등장하는 경우가 있어, Copilot 규칙과 별도 블록으로 두는 편이 설명하기 쉽습니다. 한 접미사에 무리하게 합치면 팀원마다 증상이 달라질 수 있습니다.
6 GitHub CLI·터미널·환경 변수
gh CLI와 Git 자체는 HTTPS 프록시 환경 변수나 Git의 http.proxy 설정에 민감합니다. 브라우저에서 Copilot 설정은 됐는데 터미널에서만 API가 실패하면, 셸 프로파일의 HTTPS_PROXY와 Git 설정을 Clash HTTP 포트에 맞추었는지 확인하세요. SOCKS를 쓰는 경우 도구마다 지원 여부가 다릅니다.
이중·삼중 프록시 체인은 인증서 경고와 타임아웃만 키우는 경우가 많습니다. 가능하면 한 겹의 출구로 단순화하고, 노드 전환 시에는 동일 호스트에 대해 연속으로 세 번 이상 성공하는지 보는 편이 빠릅니다.
7 선택: REST·모델 관련 엔드포인트
Copilot은 제품 업데이트에 따라 백엔드 호스트가 늘거나 바뀔 수 있습니다. 공식 문서·릴리스 노트와 별개로, 실제 환경에서는 Connections 패널에 찍힌 FQDN이 기준입니다. 조직 전용 프록시나 Self-hosted Runner가 있다면, 그 경로가 Clash 규칙과 충돌하지 않는지도 점검하세요.
GitHub의 일반 REST·GraphQL과 Copilot 제안 트래픽을 서로 다른 프록시 그룹으로 나누고 싶다면, RULE-SET을 세분화해야 합니다. 초기에는 하나의 PROXY_GITHUB로 묶고 안정화한 뒤, 로그에 패턴이 보이면 분리하는 점진적 접근이 운영 부담이 적습니다.
8 DNS·로그·문제 해결 순서
«이름은 풀리는데 연결이 안 된다»면 DNS와 TCP·TLS를 분리해 보세요. FakeIP·DoH·fallback이 꼬이면 규칙은 맞는데 세션이 다른 출구로 나가기도 합니다. 노드를 바꿀 때마다 같은 호스트의 지연이 들쭉날쭉하면 회선 품질을 의심하고, 노드를 고정한 채 로그의 호스트 목록을 한 번에 모아 보는 편이 빠릅니다.
스트리밍 형태의 제안 응답이 중간에 끊기면 HTTP/2와 불안정한 회선 조합도 흔한 원인입니다. 브라우저 로그인 확인 → 에디터에서 최소 코드 제안 테스트 → 실무 리포지토리 순으로 좁혀 가면 원인 구간을 빨리 찾을 수 있습니다.
9 계정·토큰·조직 정책
연결이 되어도 401·403·쿼터 오류는 토큰 만료·조직 정책·결제 상태 문제일 수 있습니다. Personal Access Token은 저장소에 커밋하지 말고 비밀 저장소로 관리하세요. 본문은 클라이언트 측 경로 가용성만 다루며, 지역 법규·고용 계약·서비스 약관 해석을 대신하지 않습니다.
10 자주 묻는 질문
- 웹 로그인만 되고 제안이 안 뜸: 확장 프로세스가 프록시를 안 쓰는 경우가 많습니다. TUN 또는 IDE 프록시 설정을 확인하세요.
- github.com만 넣었는데 이상함:
githubusercontent.com과 로그에 보이는 추가 접미사를 더하세요. - ChatGPT·OpenAI 규칙과 충돌? 대상 도메인이 다르므로 순서와 그룹 이름만 분리하면 병행 가능합니다.
- API만 좁히고 싶다: 가능은 하나 웹·확장 호스트를 빼면 다시 로그로 검증해야 합니다.
11 정리
2026년에도 GitHub Copilot을 안정적으로 쓰려면 «전역 스위치 하나»보다 호스트 묶음을 유지보수 가능하게 두는 편이 낫습니다. Clash에서 DOMAIN-SUFFIX·Rule Provider로 github.com·githubusercontent.com 축을 전용 프록시 그룹에 묶고, 웹·에디터·API 프록시 세 갈래를 TUN 또는 환경 변수로 맞추면 개발자 네트워크 전반이 한눈에 디버깅하기 쉬워집니다. 같은 목적의 다른 도구들보다 규칙 가독성과 클라이언트 선택 폭에서 실무에 잘 맞는 경우가 많습니다.
설치 패키지는 공식 다운로드 페이지를 우선하세요. 오픈 소스 저장소·이슈 트래커는 신뢰 형성에 도움이 되지만, 배포물은 사이트 경로를 쓰는 편이 버전 관리에 유리합니다.
