GitHub Copilot 로그인 실패가 Clash에서 자주 발생하는 이유

GitHub Copilot을 VS Code나 JetBrains에서 사용하다 보면 브라우저의 GitHub 페이지는 열리는데 IDE 안에서는 로그인 창이 반복되거나, 인증 코드를 입력한 뒤에도 완료되지 않는 경우가 있습니다. Copilot 로그인 실패, 연결 시간 초과, “Waiting for authentication”, “Network error” 같은 메시지는 서로 다른 문제처럼 보이지만, 실제로는 인증용 호스트와 Copilot API 호스트가 서로 다른 규칙을 적용받는 상황에서 자주 나타납니다.

Clash를 켠 상태에서는 트래픽이 단순히 “프록시를 사용한다”는 한 가지 경로로만 흐르지 않습니다. GitHub 로그인 페이지, 기기 인증 API, Copilot 토큰 발급 서버, 확장 프로그램 업데이트 서버, 실제 자동 완성 요청이 각각 다른 도메인으로 연결됩니다. 이 중 일부만 DIRECT로 빠지거나, 서로 다른 프록시 그룹을 사용하면 브라우저 인증은 성공해도 IDE가 토큰을 받지 못할 수 있습니다. 반대로 모든 트래픽을 무조건 한 노드로 보내면 DNS 지연이나 노드 품질 때문에 로그인 과정이 더 느려질 수도 있습니다.

증상으로 원인 범위 좁히기

문제를 해결하기 전에 어디에서 멈추는지 구분하면 불필요한 설정 변경을 줄일 수 있습니다. 로그인 버튼을 눌러도 아무 반응이 없거나 인증 URL이 열리지 않는다면 IDE가 시스템 브라우저를 호출하지 못했거나 GitHub 인증 도메인이 차단되었을 가능성이 큽니다. 브라우저에서 인증을 끝냈지만 IDE로 돌아온 뒤 계속 로그인 상태가 아니라면 콜백 주소, 토큰 교환 요청, 로컬 확장 프로그램의 프록시 경로를 확인해야 합니다.

• 로그인 창 자체가 열리지 않음: VS Code 또는 JetBrains 확장이 인증 URL을 만들지 못했거나, 기본 브라우저 연결과 로컬 콜백이 차단된 상태일 수 있습니다.
• GitHub 인증은 성공하지만 Copilot이 비활성 상태: GitHub 계정 인증과 Copilot 라이선스 확인은 별도 요청이므로, 토큰·라이선스 API가 다른 규칙으로 나갔는지 살펴봐야 합니다.
• 로그인은 되었지만 자동 완성이 늦거나 멈춤: Copilot API 연결, 프록시 노드의 지연 시간, DNS 응답, IDE 확장 프로세스의 프록시 적용 여부가 핵심입니다.
• 재부팅할 때마다 다시 로그인: 토큰 저장 권한, OS 키체인, IDE의 사용자 데이터 폴더, 보안 프로그램의 파일 격리를 점검해야 합니다.

증상을 확인할 때는 IDE에 표시된 오류 문구만 보지 말고 Clash의 연결 로그를 동시에 열어 두세요. 로그인 버튼을 누른 순간 어떤 도메인이 나타났는지, 매칭된 규칙이 무엇인지, 선택된 프록시 그룹이 무엇인지 기록하면 문제의 범위를 빠르게 줄일 수 있습니다.

1단계: 활성 프로필과 프록시 노드 확인

가장 먼저 Clash의 Profiles 또는 프로필 화면에서 실제로 사용 중인 설정 파일이 활성화되어 있는지 확인합니다. 구독을 새로 가져온 뒤 목록에만 표시하고 활성화하지 않았거나, 이전 프로필이 계속 선택되어 있으면 수정한 규칙이 실제 연결에 반영되지 않습니다. 대시보드의 시스템 프록시 스위치가 켜져 있어도 활성 프로필이 비어 있거나 노드 그룹에 선택된 서버가 없으면 Copilot은 정상적으로 연결되지 않습니다.

1. Clash를 실행하고 현재 활성화된 프로필의 이름과 마지막 업데이트 시간을 확인합니다.
2. Proxies 화면에서 기본 프록시 그룹에 실제 노드가 선택되어 있는지 확인합니다.
3. 선택한 노드의 지연 시간을 측정하고, 시간 초과나 매우 높은 지연이 반복되면 다른 노드로 바꿉니다.
4. Logs 화면을 열어 둔 상태에서 VS Code 또는 JetBrains의 Copilot 로그인을 다시 실행합니다.

노드 변경 후에는 여러 번 연속으로 인증을 시도하지 않는 편이 좋습니다. 짧은 시간 안에 계속 실패하면 확장 프로그램이 만료된 세션이나 중간 인증 상태를 재사용할 수 있기 때문입니다. 한 번 로그아웃한 뒤 IDE를 완전히 종료하고, Clash의 연결 로그를 정리한 다음 새 로그인 흐름을 시작하면 관찰하기가 쉽습니다.

2단계: GitHub와 Copilot 도메인 규칙 점검

Copilot은 단일 서버만 사용하는 서비스가 아닙니다. 일반적인 로그인 과정에서는 github.com, api.github.com, github.com/login/device와 관련된 인증 요청이 보일 수 있습니다. Copilot 기능 확인과 토큰 교환에는 api.githubcopilot.com, copilot-proxy.githubusercontent.com처럼 버전이나 클라이언트에 따라 달라질 수 있는 호스트가 등장할 수 있습니다. 확장 프로그램 업데이트나 릴리스 자산을 내려받는 과정에서는 marketplace.visualstudio.com, vscode.download.prss.microsoft.com, GitHub의 CDN 호스트가 추가될 수 있습니다.

모든 도메인을 미리 넓은 키워드 규칙으로 묶는 것은 권장하지 않습니다. 예를 들어 DOMAIN-KEYWORD,github,Proxy는 관련 없는 GitHub 저장소, 이미지, 회사 내부 미러까지 같은 그룹으로 보내 로그를 복잡하게 만들 수 있습니다. 먼저 실패 순간 로그에 실제로 나타난 FQDN을 확인하고, 필요한 호스트만 전용 그룹에 넣는 방식이 안전합니다.

• 인증 그룹: GitHub 로그인과 계정 인증에 필요한 호스트를 같은 정책으로 처리합니다.
• Copilot API 그룹: 자동 완성 요청과 라이선스 확인 호스트를 안정적인 노드로 보냅니다.
• 개발 도구 그룹: VS Code 마켓플레이스, JetBrains 플러그인 저장소, 확장 업데이트 호스트를 별도로 관리합니다.
• 기타 GitHub 트래픽: 실제 사용 목적에 따라 직접 연결하거나 별도 규칙으로 분리합니다.

로그에서 github.com은 프록시로 나가는데 Copilot 관련 호스트만 DIRECT로 표시된다면 규칙 순서가 원인일 가능성이 높습니다. 넓은 GEOIP, MATCH, 지역별 규칙이 앞에 있으면 뒤에 추가한 호스트 규칙이 실행되지 않을 수 있습니다. 구체적인 DOMAIN 규칙을 위에 배치하고, 마지막에 기본 규칙을 두는 순서로 정리하세요.

VS Code와 JetBrains에서 프록시 적용 여부 확인

시스템 프록시를 켰다고 해서 모든 IDE 프로세스가 같은 방식으로 이를 사용하는 것은 아닙니다. VS Code는 확장 호스트와 메인 애플리케이션이 서로 다른 네트워크 동작을 보일 수 있으며, 일부 확장은 VS Code의 프록시 설정을 따르고 일부는 운영체제 환경 변수를 참조합니다. JetBrains IDE도 내장 HTTP 프록시 설정, JVM 네트워크 옵션, 플러그인별 연결 방식이 겹칠 수 있어 브라우저가 정상이라는 사실만으로 Copilot 연결을 보장할 수 없습니다.

VS Code에서 확인할 항목

VS Code의 설정에서 HTTP Proxy, HTTP Proxy Support, 인증서 검사 관련 항목을 확인합니다. 일반적인 로컬 Clash 포트가 혼합 포트라면 예를 들어 http://127.0.0.1:7890처럼 정확한 주소를 사용해야 합니다. 다만 TUN 모드를 사용 중이라면 애플리케이션별 수동 프록시 설정을 무리하게 추가하면 이중 프록시가 될 수 있으므로, 시스템 프록시 방식과 TUN 방식 중 하나를 기준으로 테스트하세요.

VS Code에서 명령 팔레트를 열고 Developer: Show Logs 또는 Copilot 확장 로그를 확인하면 인증 URL 호출, 토큰 요청, 네트워크 오류가 구분되어 표시됩니다. 확장을 비활성화했다가 다시 켜는 것보다, 로그에서 최초 실패 호스트를 찾는 것이 설정을 망가뜨리지 않는 방법입니다.

JetBrains에서 확인할 항목

JetBrains 제품군은 Settings → Appearance & Behavior → System Settings → HTTP Proxy 경로에서 IDE 자체의 프록시를 설정할 수 있습니다. Clash의 로컬 HTTP 포트와 SOCKS5 포트를 혼동하지 않도록 주의하고, 설정 후 제공되는 연결 테스트가 성공하는지 확인하세요. IDE 프록시와 운영체제 시스템 프록시를 동시에 사용하면 인증은 되지만 플러그인 다운로드만 실패하거나, 반대로 Copilot 요청만 시간 초과되는 경우가 있으므로 한 번에 한 경로만 활성화해 비교하는 것이 좋습니다.

3단계: TUN 모드와 DNS가 만드는 시간 초과

Copilot 확장 프로그램은 브라우저 탭이 아니라 별도의 백그라운드 프로세스에서 동작합니다. 이 프로세스가 시스템 프록시를 무시하면 브라우저 로그인은 성공해도 자동 완성 요청은 직접 연결됩니다. 이런 상황에서는 TUN 모드가 도움이 될 수 있습니다. TUN은 애플리케이션이 프록시를 인식하지 못하더라도 운영체제의 IP 트래픽을 가상 인터페이스로 받아 Clash 규칙에 전달하는 방식입니다.

다만 TUN을 켠 뒤 바로 모든 문제가 해결되는 것은 아닙니다. 기존의 IDE 수동 프록시와 TUN이 동시에 활성화되면 연결이 두 번 변환되고, 특정 앱만 루프백 주소를 예외 처리해 예상과 다른 경로를 사용할 수 있습니다. TUN을 테스트할 때는 IDE의 수동 프록시를 잠시 끄고, Clash 로그에 Copilot 관련 연결이 나타나는지 먼저 확인하세요.

DNS도 중요한 변수입니다. 도메인이 잘못된 IP로 해석되거나, 로컬 DNS가 특정 호스트를 응답하지 않으면 Clash 규칙이 실행되기 전에 연결이 실패할 수 있습니다. fake-ip와 redir-host 중 어떤 모드를 사용할지는 구독 설정과 환경에 따라 달라지므로, 무작정 모드를 바꾸기보다 실패 호스트 하나를 기준으로 비교해야 합니다. DNS 캐시를 지운 뒤에도 같은 호스트에서 반복적으로 시간 초과가 난다면, 노드의 연결 품질과 TLS 핸드셰이크 로그를 함께 확인하세요.

1. IDE를 종료하고 Clash에서 TUN 모드를 켠 뒤 필요한 네트워크 권한을 승인합니다.
2. IDE의 수동 HTTP 또는 SOCKS 프록시를 임시로 해제합니다.
3. DNS 모드를 바꾸기 전에 현재 설정과 로그를 백업하거나 기록합니다.
4. VS Code 또는 JetBrains를 다시 실행하고 Copilot 로그인과 자동 완성을 각각 테스트합니다.
5. 개선되지 않으면 TUN을 끄고 수동 프록시 방식으로 되돌려 두 경로의 결과를 비교합니다.

인증 캐시와 계정 상태 초기화

네트워크 경로를 수정했는데도 로그인 화면이 반복되면 오래된 인증 상태가 남아 있을 수 있습니다. 먼저 GitHub 웹에서 현재 계정으로 Copilot 구독 또는 조직 라이선스가 활성화되어 있는지 확인합니다. 개인 계정과 회사 계정을 동시에 사용하는 경우 IDE가 다른 계정의 토큰을 선택할 수도 있으므로, 사용하지 않는 GitHub 계정 세션을 브라우저에서 로그아웃한 뒤 다시 시도하는 것이 좋습니다.

그 다음 IDE에서 GitHub 계정을 로그아웃하고 애플리케이션을 종료합니다. 운영체제의 자격 증명 관리자나 키체인에 저장된 GitHub 관련 항목을 무조건 전부 삭제하기보다는, 이름과 생성 시점을 확인하여 Copilot 로그인과 관련된 항목만 정리하세요. VS Code는 계정 동기화와 확장 데이터가 분리되어 있을 수 있고, JetBrains는 IDE 버전과 플러그인에 따라 저장 위치가 달라질 수 있습니다. 설정 폴더를 삭제하기 전에는 반드시 내보내기나 백업을 만들어야 합니다.

재로그인할 때는 다음 순서를 지키면 원인 확인이 쉽습니다.

• Clash에서 안정적인 노드를 선택하고 연결 로그를 초기화합니다.
• IDE를 한 개만 실행한 뒤 GitHub 계정 로그인을 시작합니다.
• 브라우저 인증을 끝낸 직후 Clash 로그에서 토큰 교환 호스트를 확인합니다.
• 로그인 완료 후 새 파일을 열어 Copilot 자동 완성이 실제로 응답하는지 테스트합니다.

최종 진단 체크리스트

아래 항목을 순서대로 확인했는데도 문제가 남는다면 설정을 더 복잡하게 만들기보다 실패 지점을 다시 관찰해야 합니다. 노드가 바뀔 때마다 결과가 달라지는지, 브라우저와 IDE에서 같은 호스트가 보이는지, 로그인과 자동 완성 중 어느 단계만 실패하는지 기록하면 지원 요청이나 추가 분석에도 유용합니다.

자주 묻는 질문

브라우저에서는 GitHub 로그인이 되는데 왜 Copilot만 실패하나요?

브라우저의 GitHub 페이지와 Copilot 확장 프로그램은 동일한 프로세스나 동일한 프록시 설정을 사용하지 않을 수 있습니다. 브라우저는 시스템 프록시를 따르지만 IDE 확장은 자체 런타임이나 별도 프록시를 사용할 수 있습니다. Clash 로그에서 IDE 로그인 시 실제로 요청이 발생하는지 확인하고, Copilot 관련 호스트가 DIRECT로 빠지지 않는지 점검하세요.

TUN 모드를 반드시 켜야 하나요?

반드시 필요한 것은 아닙니다. IDE가 Clash의 HTTP 또는 SOCKS5 포트를 정확히 사용한다면 수동 프록시만으로도 충분할 수 있습니다. 다만 확장 프로세스가 프록시 설정을 무시하거나 여러 개발 도구를 동시에 관리해야 한다면 TUN이 더 일관된 경로를 제공할 수 있습니다. 수동 프록시와 TUN을 동시에 켜지 말고 각각 따로 테스트하세요.

Copilot 관련 도메인을 전부 Proxy로 보내면 해결되지 않나요?

일시적으로 해결될 수 있지만 항상 좋은 방법은 아닙니다. 넓은 키워드 규칙은 불필요한 트래픽까지 같은 노드로 보내고, 규칙 충돌이나 지연 원인을 숨길 수 있습니다. 실제 로그에 나타난 호스트를 기준으로 인증과 API를 분리하고, 마지막에만 기본 규칙을 적용하는 편이 유지보수에 유리합니다.

로그인은 성공했는데 “Copilot unavailable”이 계속 표시됩니다.

네트워크 연결과 사용 권한은 별개의 문제입니다. 현재 GitHub 계정에 Copilot 개인 구독이 있는지, 조직 계정이라면 관리자가 라이선스를 할당했는지 확인하세요. 권한이 정상인데도 메시지가 남으면 확장 프로그램을 최신 안정 버전으로 업데이트하고, Clash 로그에서 라이선스 확인 요청이 성공했는지 살펴보면 됩니다.

일부 범용 VPN이나 오래된 프록시 앱은 IDE별 설정이 제각각이고, TUN·DNS·규칙 로그를 한곳에서 확인하기 어려워 GitHub Copilot 로그인 시간 초과의 원인을 찾는 데 시간이 걸릴 수 있습니다. Clash 공식 사이트는 활성 프로필, 노드 상태, 규칙 매칭, TUN과 DNS 경로를 단계별로 확인할 수 있어 VS Code와 JetBrains를 같은 기준으로 진단하기 편하며, 이 글의 순서를 그대로 적용해 설정을 재현하기도 쉽습니다. 지금 Copilot 인증이 막혀 있다면 먼저 필요한 클라이언트와 설정을 확인한 뒤 Clash 공식 사이트를 다운로드해 한 가지 프록시 경로부터 차분히 테스트해 보세요.