GitHub Copilot 연결 지연, Clash 프록시 문제 해결법

GitHub Copilot 연결 지연이 나타나는 실제 원인

GitHub Copilot 자동완성이 늦거나 로그인 창이 계속 로딩되는 문제는 단순히 “Clash 노드가 느리다”로 끝나지 않는 경우가 많습니다. Copilot은 VS Code 확장, GitHub 로그인 페이지, 토큰 교환 서버, 실제 코드 제안 API를 서로 다른 연결로 사용합니다. 브라우저에서 github.com이 정상적으로 열려도 확장 프로그램이 사용하는 API 요청이 다른 규칙을 타면 자동완성만 지연되거나 Connection timed out 오류가 발생할 수 있습니다.

특히 Clash에서 시스템 프록시만 켜고 애플리케이션별 프록시 적용을 확인하지 않으면 문제가 더 복잡해집니다. VS Code가 운영체제 프록시를 상속하는지, 확장 호스트 프로세스가 별도의 네트워크 설정을 사용하는지, 회사 보안 프로그램이 인증서 연결을 검사하는지에 따라 같은 PC에서도 브라우저와 Copilot의 경로가 달라질 수 있습니다. 따라서 처음부터 노드를 무작정 바꾸기보다 로그인 단계, 확장 연결 단계, 코드 제안 단계를 나누어 확인해야 합니다.

Clash 모드와 시스템 프록시를 기본값부터 점검하기

첫 번째 테스트에서는 구성을 복잡하게 만들지 않는 것이 중요합니다. Clash의 현재 모드를 확인하고, 규칙 모드에서 문제가 발생한다면 잠시 Global 모드로 전환해 Copilot을 다시 실행해 보세요. Global 모드에서 로그인이 성공하고 자동완성도 정상화된다면 노드 자체보다는 규칙 매칭, DNS 응답, 또는 특정 도메인의 DIRECT 처리에 문제가 있을 가능성이 높습니다. 반대로 Global 모드에서도 시간 초과가 반복된다면 선택한 노드의 품질, TLS 연결, 로컬 방화벽을 함께 살펴봐야 합니다.

다음으로 Clash의 System Proxy가 실제로 켜져 있는지 확인합니다. Windows에서는 설정 화면의 시스템 프록시 토글과 운영체제의 프록시 설정이 모두 활성 상태인지 봐야 하며, macOS에서는 네트워크 서비스별 프록시 설정이 다른 인터페이스에 남아 있지 않은지 확인해야 합니다. Clash for Android에서는 일반적인 시스템 프록시가 아니라 VPN 방식으로 트래픽을 처리하므로 데스크톱과 같은 판단을 적용하면 안 됩니다. 클라이언트가 다르면 같은 프로필이라도 적용 계층이 달라질 수 있습니다.

VS Code를 완전히 종료한 뒤 Clash를 먼저 실행하고, 프로필을 불러온 다음 VS Code를 다시 시작하는 순서도 권장합니다. 이미 실행 중인 확장 호스트는 초기 프록시 상태를 계속 유지할 수 있기 때문입니다. 작업 관리자나 활동 모니터에서 남아 있는 Code 프로세스를 모두 종료한 후 다시 실행하면, 단순한 설정 변경보다 재현 결과가 명확해집니다.

GitHub Copilot 도메인 규칙과 DNS 확인

규칙을 추가할 때는 “GitHub 전체를 무조건 하나의 광범위한 규칙으로 묶기”보다 실제 로그에 나타난 호스트를 기준으로 시작하는 편이 안전합니다. 기본적으로 github.com은 로그인과 웹 계정 확인에 관여할 수 있고, api.github.com은 API 요청에 사용될 수 있습니다. Copilot 확장 버전이나 GitHub 측 변경에 따라 인증, 텔레메트리, 제안 요청에 필요한 호스트가 달라질 수 있으므로 오래된 블로그의 도메인 목록을 그대로 복사하지 말고 현재 로그를 우선해야 합니다.

Clash 규칙에서는 구체적인 호스트 규칙이 넓은 규칙보다 위에 있어야 합니다. 예를 들어 특정 DOMAIN 규칙을 넣었는데 그 아래에 이미 해당 트래픽을 DIRECT로 보내는 DOMAIN-SUFFIX,github.com 규칙이 있다면 기대한 정책이 적용되지 않습니다. 규칙 모드에서는 위에서 아래로 먼저 일치하는 항목이 선택되므로, 수정 후 반드시 연결 로그에서 실제 정책 이름을 확인해야 합니다. YAML을 바꾼 뒤 저장만 하고 활성 프로필을 다시 불러오지 않는 실수도 자주 발생합니다.

DNS 모드도 무시하기 어렵습니다. 로컬 DNS가 도메인을 해석하고 Clash가 연결만 중계하는 구성에서는 지역별 응답 차이와 캐시된 주소 때문에 특정 API만 늦어질 수 있습니다. 반대로 가상 IP 방식이 켜져 있을 때는 운영체제나 보안 프로그램이 가상 주소를 비정상 트래픽으로 판단할 수 있습니다. DNS 설정을 한 번에 모두 바꾸기보다 현재 모드, DNS 서버, 실패한 호스트의 해석 결과를 기록한 뒤 한 항목씩 비교하세요.

다음과 같은 최소 규칙 구조를 참고할 수 있습니다. 실제 그룹 이름은 자신의 프로필에 맞게 바꾸고, 광범위한 접미 규칙은 다른 GitHub 서비스에 영향을 줄 수 있으므로 주의해야 합니다.

rules:
  - DOMAIN,github.com,COPILOT
  - DOMAIN,api.github.com,COPILOT
  - MATCH,Proxy

이 예시는 완성된 만능 설정이 아니라 테스트용 출발점입니다. 조직의 GitHub Enterprise 서버를 사용한다면 공개 GitHub 도메인만 추가해서는 부족할 수 있고, 사내 인증서나 보안 게이트웨이가 별도로 개입할 수도 있습니다. 회사 네트워크에서 사용하는 경우에는 관리자 정책을 우선하고, 허가되지 않은 우회 설정을 임의로 적용하지 않아야 합니다.

TUN 모드, VS Code 확장 호스트와 최종 진단 순서

시스템 프록시를 따라가지 않는 프로세스에서 Copilot을 사용한다면 TUN 모드가 해결책이 될 수 있습니다. TUN은 애플리케이션이 프록시 환경 변수를 읽는지에 덜 의존하고 운영체제의 트래픽 계층에서 연결을 처리하므로, VS Code 확장 호스트처럼 별도 프로세스로 동작하는 구성에서 유용합니다. 다만 TUN을 켠다고 모든 문제가 자동으로 해결되는 것은 아닙니다. 권한 승인, 가상 네트워크 인터페이스, DNS 모드, 다른 VPN과의 충돌이 함께 작동해야 합니다.

TUN을 처음 켤 때는 기존 상용 VPN, WireGuard, 다른 Clash 포크의 터널을 잠시 끄고 한 가지 터널만 유지하세요. Windows에서는 관리자 권한과 가상 어댑터 상태를 확인하고, macOS에서는 네트워크 확장 허용 여부를 확인합니다. Android에서는 VPN 알림이 표시되는지, 배터리 절전 기능이 Clash를 종료시키지 않는지 살펴봐야 합니다. TUN을 켠 뒤에도 시스템 프록시와 환경 변수를 동시에 강제로 지정하면 트래픽이 이중으로 전달되어 오히려 지연이 커질 수 있습니다.

진단은 다음 순서로 진행하면 됩니다. 먼저 Copilot 확장에서 로그아웃한 뒤 Clash 로그를 지우고, 브라우저에서 GitHub 로그인 페이지를 열어 로그인 흐름을 기록합니다. 그다음 VS Code를 재시작하고 확장을 활성화한 뒤 로그인과 자동완성을 각각 한 번씩 재현합니다. 각 단계에서 연결이 생성되는 시점, 사용된 정책 그룹, 연결이 닫히는 이유를 기록하세요. timeout이 반복되면 노드의 지연만 보지 말고 TLS 협상 시간과 응답 대기 시간을 구분해야 합니다.

특정 노드에서만 느리다면 같은 지역의 다른 노드로 바꾸어 비교하고, 모든 노드에서 동일하다면 규칙이나 로컬 환경을 의심합니다. 연결은 성공하지만 제안 응답이 오래 걸릴 때는 짧은 웹 요청 속도보다 장시간 스트리밍 안정성이 더 중요합니다. 모바일 핫스팟과 가정용 회선을 번갈아 테스트하면 ISP DNS, 회사 보안 장비, 로컬 방화벽 가운데 어느 계층이 영향을 주는지 빠르게 좁힐 수 있습니다.

결론적으로 단순한 GUI 클라이언트는 시스템 프록시 토글과 기본 규칙만 제공해 VS Code 확장 호스트, TUN 권한, DNS 충돌을 한 화면에서 추적하기 어렵고, 일부 오래된 포크는 최신 Mihomo 코어 옵션이나 로그 표시가 제한적일 수 있습니다. 반면 Clash V.CORE는 규칙 기반 라우팅, 연결 로그 확인, TUN 적용, 정책 그룹 분리를 한 흐름으로 점검하기 좋아 GitHub Copilot처럼 로그인과 API 요청이 나뉘는 환경에서 원인을 좁히기 편합니다. 여러 클라이언트를 번갈아 설치하기보다 이 글의 순서대로 안정적인 프로필을 구성하고 싶다면 Clash V.CORE 다운로드를 확인해 보세요.