Clash에서 GitHub Copilot이 안 될 때 연결 오류 해결법

Clash를 사용한 뒤 GitHub Copilot에 로그인되지 않거나 VS Code의 자동완성이 멈추는 경우가 있습니다. 브라우저에서 GitHub는 열리는데 Copilot만 Failed to connect, Network error, 인증 대기 상태를 반복한다면 단순히 노드 속도만의 문제는 아닙니다. Copilot은 GitHub 로그인, 확장 프로그램 API, 자동완성 서비스, 인증 토큰 갱신 등 여러 HTTPS 연결을 동시에 사용하기 때문입니다. 이 글에서는 Clash에서 GitHub Copilot이 작동하지 않을 때 확인해야 할 프록시 모드, 규칙, DNS, 노드 상태를 정리하고 VS Code와 JetBrains 환경에 맞는 해결 절차를 단계별로 설명합니다.

GitHub Copilot 연결 오류가 발생하는 주요 원인

Copilot 연결 문제를 해결할 때는 먼저 어느 단계에서 실패하는지 구분해야 합니다. GitHub 웹사이트 로그인은 정상인데 Copilot 확장 프로그램만 오류를 표시한다면 계정 자체보다 확장 프로그램이 사용하는 API 연결이나 WebSocket 연결이 차단되었을 가능성이 높습니다. 반대로 GitHub 로그인 페이지도 열리지 않는다면 규칙 또는 노드가 GitHub 도메인을 직접 연결로 보내고 있는지부터 확인해야 합니다.

GitHub 관련 트래픽은 일반적으로 github.com, api.github.com, githubusercontent.com 및 Copilot 서비스 도메인으로 나뉩니다. 사용하는 Copilot 버전과 지역에 따라 실제 연결 대상이 달라질 수 있으므로 특정 도메인 하나만 허용하는 방식보다 GitHub 및 Copilot 관련 도메인을 일관된 프록시 규칙으로 처리하는 편이 안정적입니다. 다만 모든 GitHub 트래픽을 무조건 프록시해야 하는 것은 아니므로, 회사 내부 GitHub Enterprise나 사내 저장소는 별도의 직접 연결 규칙이 필요할 수 있습니다.

Clash 모드와 규칙 순서 확인하기

가장 먼저 Clash Verge, Clash Verge Rev, Clash for Windows, ClashX 또는 Mihomo 클라이언트에서 현재 모드를 확인하세요. Global 모드에서 Copilot이 작동한다면 노드 자체는 정상일 가능성이 높고, Rule 모드의 규칙 매칭이 문제일 가능성이 큽니다. 반대로 Global 모드에서도 실패한다면 선택한 노드, DNS, TLS 연결 또는 로컬 방화벽을 점검해야 합니다.

Rule 모드에서는 규칙이 위에서 아래로 평가됩니다. GitHub 도메인을 프록시 그룹으로 보내는 규칙보다 GEOIP,CN,DIRECT, 넓은 DOMAIN-SUFFIX,github.com,DIRECT, 또는 특정 IP 대역 규칙이 먼저 나오면 Copilot 요청이 직접 연결될 수 있습니다. 특히 설정 파일 하단의 MATCH,DIRECT 자체는 정상적인 마지막 규칙이지만, 그 전에 GitHub와 Copilot을 프록시로 보내는 항목이 없으면 예상과 다른 결과가 발생합니다.

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - DOMAIN-SUFFIX,githubassets.com,Proxy
  - DOMAIN,api.github.com,Proxy
  - DOMAIN-SUFFIX,copilot.githubusercontent.com,Proxy
  - DOMAIN-SUFFIX,githubcopilot.com,Proxy
  - MATCH,DIRECT

위 예제에서 Proxy는 실제 프록시 그룹 이름으로 바꿔야 합니다. 설정에 해당 이름의 그룹이 없으면 규칙은 적용되지 않거나 설정 검증 단계에서 오류가 발생합니다. 구독 설정을 사용하는 경우에는 직접 편집한 규칙이 업데이트 때 사라질 수 있으므로, 클라이언트의 추가 규칙 기능이나 규칙 오버라이드 기능을 이용하는 것이 좋습니다.

실전 점검 절차: VS Code와 JetBrains에서 확인하기

이제 설정을 한 번에 많이 바꾸지 말고 아래 순서대로 테스트하세요. 각 단계가 끝날 때마다 Copilot 로그인이나 간단한 코드 자동완성을 다시 시도하면 원인을 빠르게 좁힐 수 있습니다.

1. Clash 대시보드의 프록시 그룹에서 현재 노드를 바꾸고 노드 테스트를 실행합니다. 핑이 낮더라도 GitHub 연결이 안정적이라는 뜻은 아니므로, 테스트 URL 응답과 실제 HTTPS 연결 성공 여부를 함께 확인하세요.
2. Clash 모드를 잠시 Global로 변경한 뒤 VS Code 또는 JetBrains를 완전히 종료하고 다시 실행합니다. 이 상태에서 정상 작동하면 Rule 모드의 규칙 순서 또는 DNS 기반 매칭을 수정합니다.
3. Clash의 Connections 또는 Logs 화면을 열고 Copilot 로그인 버튼이나 자동완성을 실행합니다. 요청이 기록되지 않으면 IDE가 Clash를 사용하지 않는 것이고, 요청이 기록되지만 실패하면 규칙·노드·TLS를 확인해야 합니다.
4. VS Code에서 View → Output을 열고 출력 패널의 공급자를 GitHub Copilot으로 선택합니다. 인증 오류, 프록시 거부, 인증서 오류, 타임아웃 메시지를 구분해서 기록합니다.
5. JetBrains에서는 Settings → Appearance & Behavior → System Settings → HTTP Proxy로 이동합니다. Clash의 시스템 프록시를 사용할 경우 Auto-detect proxy settings 또는 수동 HTTP 프록시를 선택하고, Clash 포트와 동일한 값을 입력합니다.
6. 인증이 꼬인 경우 IDE에서 GitHub 계정을 로그아웃한 뒤 IDE를 재시작하고 다시 로그인합니다. 브라우저에 남은 오래된 인증 페이지를 재사용하지 말고 새 인증 흐름을 시작하는 것이 좋습니다.

VS Code는 운영체제의 시스템 프록시를 따르는 경우가 많지만, 환경과 실행 방식에 따라 확장 호스트가 별도 네트워크 설정을 사용할 수 있습니다. 수동 프록시가 필요한 환경에서는 VS Code의 설정에서 http.proxy를 지정할 수 있습니다. 단, Clash가 SOCKS 포트만 열어 둔 상태에서 HTTP 프록시 주소로 입력하면 실패하므로 포트 종류를 반드시 구분하세요.

{
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxySupport": "override",
  "http.proxyStrictSSL": true
}

실제 Clash 포트가 7890이 아니라면 자신의 HTTP 포트로 변경하세요. HTTPS 인증서 검증을 끄는 http.proxyStrictSSL: false는 임시 진단 외에는 권장하지 않습니다. 이 값을 끄고 문제가 해결된다면 노드의 인증서 체인, 로컬 보안 프로그램의 HTTPS 검사, 또는 중간 프록시가 인증서를 변조하는지 조사해야 합니다.

DNS와 TUN 모드 점검

Copilot은 도메인 기반 HTTPS 연결을 여러 번 생성하므로 DNS 응답이 잘못되거나 서로 다른 주소를 반환하면 로그인은 되더라도 자동완성이 중단될 수 있습니다. Clash에서 노드 핑은 정상인데 특정 서비스만 타임아웃된다면 redir-host 환경에서 로컬 DNS가 오염되었거나, 운영체제가 Clash DNS가 아닌 다른 리졸버를 사용하고 있을 가능성이 있습니다.

Mihomo 기반 클라이언트에서는 일반적으로 fake-ip 모드와 TUN 모드를 함께 사용하는 구성이 편리합니다. 이 방식은 앱이 요청한 도메인을 Clash가 먼저 확인하고 도메인 규칙을 적용할 수 있게 합니다. 다만 이미 다른 VPN, 보안 소프트웨어, Docker 네트워크가 가상 인터페이스를 사용하고 있다면 TUN의 라우팅 우선순위가 충돌할 수 있으므로 하나씩 비활성화하면서 테스트하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

이 설정은 모든 환경에 그대로 적용하는 완성본이 아니라 원인 분리를 위한 출발점입니다. 기존 설정에 nameserver-policy, fake-ip-filter, DNS 리다이렉트 규칙이 있다면 충돌 여부를 먼저 살펴보세요. 설정을 변경한 뒤에는 Clash의 DNS 캐시를 비우고 클라이언트와 IDE를 재시작해야 이전의 잘못된 IP 매핑이 남지 않습니다.

IDE별 추가 해결 방법과 최종 체크리스트

VS Code에서 확인할 항목

VS Code에서는 확장 프로그램이 최신 상태인지 확인하고, 확장 프로그램 호스트의 로그를 살펴보세요. 회사 네트워크에서 인증서 검사를 수행한다면 시스템에 회사 루트 인증서가 설치되어 있어야 합니다. 반대로 개인 환경에서 보안 프로그램이 HTTPS를 가로채는 경우에는 해당 기능을 잠시 끄고 차이를 비교할 수 있습니다. Copilot 확장 프로그램을 삭제하고 다시 설치하는 것보다 먼저 계정 로그아웃, 창 다시 로드, 출력 로그 확인을 진행하는 편이 원인 파악에 유리합니다.

JetBrains에서 확인할 항목

JetBrains 제품은 IDE 자체의 HTTP Proxy 설정이 운영체제 프록시와 다를 수 있습니다. 수동 프록시를 선택했다면 HTTP 포트와 SOCKS 포트를 혼동하지 말고, 프록시 인증을 요구하지 않는 로컬 Clash 포트를 우선 사용하세요. IDE를 터미널에서 실행할 때 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 환경 변수가 남아 있으면 GUI 설정과 충돌할 수 있으므로 값을 확인해야 합니다.

마지막으로 하나의 노드에서만 Copilot이 실패한다면 설정을 계속 수정하기보다 해당 노드의 서버 지역, TLS 상태, 연결 품질을 의심하는 것이 빠릅니다. 여러 노드에서 동일하게 실패하고 브라우저와 IDE 모두 문제가 있다면 DNS 또는 규칙 문제일 가능성이 높습니다. 반대로 브라우저는 정상이고 IDE만 실패한다면 Clash보다 IDE의 프록시 상속 방식과 인증 토큰을 먼저 확인하세요. 이 순서를 지키면 무작정 설정 파일 전체를 교체하지 않고도 GitHub Copilot 연결 오류의 원인을 안정적으로 좁힐 수 있습니다.