Clash에서 GitHub Copilot 연결 시간 초과 해결 방법

시간 초과가 발생한 위치부터 구분하기

GitHub Copilot이 Clash를 켰을 때만 작동하지 않는다면 먼저 Copilot 계정이나 확장 프로그램을 재설치하기보다 연결 경로를 나누어 확인해야 합니다. Copilot 요청은 편집기 확장 프로그램에서 시작해 운영체제의 프록시 설정, Clash의 로컬 포트, DNS 조회, 규칙 매칭, 선택된 노드와 원격 GitHub 서비스 순서로 전달됩니다. 이 중 하나라도 직접 연결로 빠지거나 잘못된 정책 그룹으로 들어가면 로그인은 완료되었지만 코드 제안만 멈추거나, “timed out”, “network error”, “failed to connect”와 같은 짧은 메시지가 표시될 수 있습니다.

문제 해결을 시작하기 전에 다음 세 가지 상태를 기록하세요. 첫째, GitHub 웹사이트는 브라우저에서 열리는지 확인합니다. 둘째, Copilot 확장 프로그램의 로그에서 실패한 호스트 이름과 오류 유형을 확인합니다. 셋째, Clash를 완전히 종료했을 때와 실행했을 때의 결과를 비교합니다. Clash를 종료하면 정상이고 실행하면 실패한다면 구독 전체가 고장 난 것이 아니라 규칙, DNS, 노드 또는 로컬 프록시 경로의 문제일 가능성이 높습니다.

증상	우선 의심할 위치	첫 번째 확인 방법
GitHub는 열리지만 Copilot 제안만 시간 초과	Copilot 관련 도메인의 규칙 또는 WebSocket 경로	Clash 연결 로그에서 실패 호스트 확인
로그인 창이 반복해서 나타남	인증 요청 차단, 시스템 시간, 브라우저 콜백	편집기와 브라우저 로그인 상태를 각각 확인
Clash를 끄면 정상, 켜면 실패	DIRECT 규칙, 잘못된 정책 그룹, 노드 품질	규칙 모드와 연결 기록 비교
모든 확장 프로그램의 네트워크 요청이 느림	TUN, DNS, MTU 또는 노드 자체의 품질	브라우저와 터미널의 일반 HTTPS 접속 테스트

로컬 프록시와 GitHub 규칙 점검하기

대부분의 데스크톱 Clash 클라이언트는 mixed-port: 7890과 같은 로컬 포트를 제공합니다. HTTP와 HTTPS 요청을 시스템 프록시로 보내려면 운영체제 또는 편집기가 실제 Clash 포트를 사용해야 합니다. Clash 창이 열려 있다는 사실만으로 VS Code, JetBrains IDE, 터미널이 자동으로 해당 포트를 사용하는 것은 아닙니다. 현재 설정의 mixed-port, port, socks-port를 확인하고, 클라이언트의 시스템 프록시 스위치가 켜져 있는지 살펴보세요.

규칙 모드에서는 대상 도메인이 위에서부터 순서대로 매칭됩니다. GITHUB, GitHub, github.com처럼 서로 다른 이름을 가진 정책 그룹이 여러 개 있으면 실제로 어느 그룹으로 전달되는지 연결 로그에서 확인해야 합니다. GitHub 관련 도메인이 REJECT, 광고 차단 그룹 또는 지연이 큰 자동 선택 그룹으로 들어가면 웹사이트 일부는 열려도 Copilot의 지속적인 요청은 시간 초과될 수 있습니다.

mode: rule
mixed-port: 7890
allow-lan: false

rules:
  - DOMAIN-SUFFIX,github.com,GitHub
  - DOMAIN-SUFFIX,githubusercontent.com,GitHub
  - DOMAIN-SUFFIX,githubcopilot.com,GitHub
  - MATCH,PROXY

위 예시는 구조를 설명하기 위한 기본 형태입니다. 실제 환경에서는 서비스 제공자가 사용하는 호스트가 변경될 수 있으므로 특정 도메인 목록을 무조건 복사하기보다 Copilot 로그에 실제로 표시된 호스트를 기준으로 규칙을 추가하세요. github.com만 프록시로 보내고 다른 GitHub 관련 호스트를 직접 연결하게 만들면 인증, 모델 요청, 확장 프로그램 업데이트가 서로 다른 경로를 사용하게 됩니다.

연결 로그에서 확인할 항목

호스트 이름: 요청이 GitHub 계열 도메인인지, 회사 프록시나 보안 필터 도메인으로 바뀌었는지 확인합니다.
정책 이름: 요청이 원하는 GitHub 또는 PROXY 그룹으로 들어갔는지 확인합니다.
실제 노드: 정책 그룹 안에서 연결에 사용된 서버와 프로토콜을 확인합니다.
연결 결과: timeout, reset, handshake failure, EOF가 반복되는지 구분합니다.
반복 주기: 동일 요청이 짧은 간격으로 반복되면 편집기가 재시도 중일 수 있으므로 노드만 계속 바꾸지 말고 최초 실패 원인을 찾습니다.

연결 로그에 Copilot 관련 요청이 전혀 나타나지 않는다면 편집기가 시스템 프록시를 사용하지 않는 경우가 많습니다. 이때는 Clash 규칙을 수정하기 전에 VS Code의 프록시 설정, 기업용 관리 정책, 터미널에서 실행한 환경 변수와 확장 프로그램의 네트워크 동작을 확인해야 합니다. 반대로 로그에 요청이 나타나지만 DIRECT로 기록된다면 해당 도메인보다 앞에 있는 규칙이 먼저 매칭되는지 살펴보세요.

노드 품질과 HTTPS 연결을 단계별로 테스트하기

Copilot은 단순히 웹페이지 하나를 내려받는 서비스가 아닙니다. 인증 요청, 확장 프로그램의 상태 확인, 코드 제안 요청이 여러 HTTPS 연결로 나뉘며, 일부 환경에서는 장시간 유지되는 연결이나 실시간 응답 흐름이 사용될 수 있습니다. 따라서 브라우저에서 GitHub 첫 화면이 빠르게 열린다는 사실만으로 Copilot 연결이 안정적이라고 판단할 수 없습니다. 지연 시간이 낮아도 패킷 손실, TLS 연결 실패, 중간 프록시의 연결 종료가 있으면 제안 요청이 중단됩니다.

먼저 Clash의 노드 테스트 기능으로 몇 개의 노드를 비교하세요. 한 노드에서만 실패하면 노드 서버의 상태, 해당 서버의 IP 평판, TLS 처리 또는 전송 프로토콜 문제일 수 있습니다. 모든 노드에서 비슷하게 실패하면 규칙, DNS, 로컬 프록시 또는 기업 네트워크 차단을 우선 의심해야 합니다. 자동 선택 그룹의 결과만 보지 말고, 안정적인 TCP 기반 노드를 직접 선택해 비교하는 것이 좋습니다.

curl -I -L --connect-timeout 10 --max-time 30 \
  -x http://127.0.0.1:7890 \
  https://github.com

curl -I -L --connect-timeout 10 --max-time 30 \
  -x http://127.0.0.1:7890 \
  https://api.github.com

위 명령에서 200, 301, 302처럼 서버가 응답했다면 최소한 해당 주소까지 HTTPS 요청이 도달한 것입니다. 인증이 필요한 API에서 401이나 403이 반환되는 것 자체는 네트워크 단절과 같은 의미가 아닙니다. 반면 이름 해석 실패, 연결 시간 초과, TLS handshake 오류, 연결 리셋이 나타나면 노드와 DNS 경로를 계속 확인해야 합니다. 실제 Copilot 요청 주소를 임의로 추측해 테스트하지 말고, 확장 프로그램 로그에 표시된 호스트를 기준으로 판단하세요.

테스트 결과	가능성이 높은 원인	다음 조치
한 노드에서만 실패	노드 서버 또는 전송 품질	다른 지역의 TCP 노드로 비교
모든 노드에서 DNS 오류	로컬 DNS, DNS 정책 또는 TUN DNS	DNS 모드와 실제 조회 결과 확인
HTTPS는 응답하지만 Copilot만 실패	확장 프로그램 프록시 적용, 특정 규칙, 장기 연결	편집기 로그와 Clash 연결 로그를 시간순으로 대조
연결 후 수십 초 뒤 종료	중간 프록시, 패킷 손실, WebSocket 또는 스트리밍 경로	다른 노드와 시스템 프록시/TUN 모드 비교

TUN, DNS와 편집기 프록시 설정 확인하기

시스템 프록시 모드에서는 HTTP 또는 HTTPS 프록시를 읽는 프로그램만 Clash를 통과합니다. 브라우저는 정상인데 편집기 확장 프로그램, 터미널, 업데이트 서비스가 직접 연결되는 이유도 여기에 있습니다. 반대로 TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 트래픽을 더 넓게 가로채므로 시스템 프록시를 지원하지 않는 프로그램을 처리하는 데 유리하지만, 권한, 라우팅, DNS 하이재킹과 MTU 문제가 추가됩니다.

먼저 TUN을 끈 상태에서 시스템 프록시 모드로 Copilot을 테스트하세요. 이 단계에서 정상이라면 TUN 자체가 필요한 문제가 아니라 TUN의 DNS 또는 라우팅 설정이 원인일 수 있습니다. 시스템 프록시에서 실패하지만 TUN에서만 정상이라면 편집기가 프록시 환경 변수를 무시하거나 별도의 네트워크 런타임을 사용하는지 확인해야 합니다.

DNS 모드: 도메인이 로컬 인터넷 DNS로 해석되는지, Clash가 지정한 DNS 서버로 해석되는지 확인합니다.
DNS 하이재킹: TUN에서 DNS 요청이 가상 인터페이스를 우회하면 잘못된 주소나 오래된 캐시가 반환될 수 있습니다.
자동 라우팅: TUN이 활성화되어도 특정 프로세스나 사설 주소가 우회 목록에 포함되면 편집기 요청이 DIRECT로 빠질 수 있습니다.
MTU: 접속은 되지만 TLS 협상이나 응답 스트림이 중간에 멈추면 낮은 MTU로 비교 테스트할 수 있습니다. 값을 크게 바꾸기보다 현재 네트워크에 맞춰 조금씩 조정하세요.
권한: Windows 서비스, macOS 네트워크 확장, Linux의 권한과 가상 인터페이스 상태가 정상인지 확인합니다.

VS Code와 같은 편집기는 자체 프록시 설정이나 운영체제 프록시를 사용할 수 있습니다. Clash의 시스템 프록시를 켠 뒤에도 편집기 설정에 오래된 http.proxy 주소, 잘못된 포트, 인증이 필요한 회사 프록시가 남아 있으면 요청이 다른 경로로 전달됩니다. 편집기 설정에서 프록시 주소를 확인하고, 별도의 회사 프록시를 사용하지 않는다면 중복된 프록시 값을 제거한 뒤 편집기를 완전히 재시작하세요.

재설정이 필요할 때의 안전한 순서

Copilot 확장 프로그램과 편집기를 종료하고 Clash의 연결 로그를 저장합니다.
현재 YAML, 구독 주소, 정책 그룹 선택 상태를 백업합니다.
Clash를 rule 모드로 두고 GitHub 관련 요청이 프록시 그룹으로 전달되는지 확인합니다.
자동 선택 그룹 대신 연결이 안정적인 단일 노드를 선택해 HTTPS 테스트를 실행합니다.
TUN을 끈 시스템 프록시 모드와 TUN 모드를 각각 테스트합니다.
DNS 캐시와 편집기 캐시를 정리한 뒤 편집기를 다시 시작합니다. 계정 로그아웃과 재로그인은 마지막 단계로 미룹니다.

이 순서로도 해결되지 않는다면 회사 방화벽, 보안 프로그램, TLS 검사 프록시 또는 GitHub 측의 일시적인 장애를 확인해야 합니다. 특히 회사 네트워크에서는 외부 프록시가 인증서와 장기 연결을 검사할 수 있으므로 개인 네트워크나 모바일 핫스팟에서 같은 노드와 같은 편집기를 비교하면 원인 범위를 빠르게 좁힐 수 있습니다. 최종적으로는 “Clash가 켜져 있는가”가 아니라 “Copilot 요청이 어느 포트와 어느 정책을 거쳐 어떤 노드로 전달되는가”를 확인해야 합니다.