무료 Clash 노드는 사용해도 안전한가요?

무료 노드는 운영자와 데이터 처리 방침을 확인하기 어렵고, 속도와 수명이 불안정할 수 있습니다. 민감한 계정이나 업무 트래픽에는 신뢰할 수 있는 서비스와 최소 권한 사용을 권장합니다.

유료 Clash 구독은 비쌀수록 좋은가요?

가격만으로 품질을 판단할 수 없습니다. 노드 위치, 피크 시간 성능, 트래픽 정책, 업데이트 이력, 환불 조건과 고객 지원을 함께 비교해야 합니다.

Clash 구독 URL을 다른 사람에게 공유해도 되나요?

구독 URL에는 인증 토큰이 포함되는 경우가 많으므로 공유하지 않는 것이 좋습니다. 노출되었다면 제공업체 대시보드에서 링크를 재발급하거나 폐기하세요.

GitHub Copilot 연결 안 될 때 Clash 타임아웃 해결법

GitHub Copilot 연결 안 될 때 나타나는 증상과 원인

Clash를 켠 상태에서 GitHub Copilot이 작동하지 않으면 먼저 노드가 완전히 끊겼다고 생각하기 쉽습니다. 그러나 실제로는 프록시 서버 자체보다 VS Code가 Clash의 프록시 포트를 사용하지 않는 문제, Copilot 관련 도메인이 잘못된 규칙에 매칭되는 문제, DNS 해석이 직접 연결로 빠지는 문제가 더 자주 발생합니다. 브라우저에서는 GitHub가 열리는데 VS Code의 자동완성만 멈추거나, 로그인 창은 표시되지만 인증이 끝나지 않는 경우도 같은 범주에 속합니다.

Copilot은 단순히 github.com 하나만 접속하는 서비스가 아닙니다. VS Code 확장 프로그램은 로그인과 토큰 발급, Copilot API 요청, 자동완성 스트리밍, 상태 확인을 위해 여러 호스트에 연결합니다. 따라서 GitHub 메인 페이지가 정상적으로 열려도 Copilot API 도메인이나 인증 관련 요청이 타임아웃될 수 있습니다. Clash 로그에는 timeout, context deadline exceeded, EOF, connection reset 같은 메시지가 남을 수 있으며, 각각의 의미를 구분하면서 점검해야 합니다.

이 글에서는 특정 노드만 반복해서 바꾸는 방식보다, 연결 경로를 단계별로 나누어 원인을 좁히는 순서를 설명합니다. 먼저 VS Code의 프록시 사용 여부를 확인하고, 그다음 Clash 모드와 규칙 매칭, DNS, 인증 캐시 순서로 점검하면 불필요한 설정 변경을 크게 줄일 수 있습니다.

1단계: VS Code가 Clash 프록시를 실제로 사용하는지 확인

가장 먼저 확인할 항목

Clash의 HTTP 또는 혼합 포트가 실행 중인지 확인합니다.
Clash의 시스템 프록시를 켜고 VS Code를 완전히 종료한 뒤 다시 실행합니다.
VS Code 설정에서 프록시 주소와 포트가 비어 있거나 잘못되어 있지 않은지 확인합니다.
Clash의 Connections 또는 Logs 화면에서 VS Code가 만든 요청을 찾습니다.

Clash Verge 계열 클라이언트에서는 General 화면에 HTTP 포트 또는 Mixed Port가 표시됩니다. 기본값으로 알려진 7890을 무조건 입력하기보다 현재 화면에 표시된 값을 기준으로 사용해야 합니다. 다른 프록시 앱이 같은 포트를 이미 점유하고 있거나, 설정을 변경한 뒤 Clash를 재시작하지 않았다면 VS Code는 응답하지 않는 로컬 포트에 접속하게 됩니다.

Windows와 macOS의 시스템 프록시를 켜면 일반적으로 브라우저와 일부 데스크톱 앱이 Clash를 사용합니다. 하지만 VS Code나 확장 프로그램의 네트워크 요청은 운영체제 설정과 별도로 동작할 수 있습니다. VS Code 설정에서 http.proxy가 다른 주소를 가리키거나 http.proxySupport가 제한적으로 설정되어 있으면 시스템 프록시를 켜도 Copilot만 직접 연결을 시도할 수 있습니다.

VS Code의 설정 검색창에서 proxy를 입력해 관련 항목을 확인하세요. 수동 프록시를 사용할 때는 다음처럼 로컬 Clash 포트에 맞춰 입력할 수 있습니다.

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

위 설정에서 포트 번호는 예시일 뿐입니다. 실제 Clash 포트와 다르면 연결되지 않으므로 반드시 현재 클라이언트의 포트로 바꾸어야 합니다. http.proxyStrictSSL을 무조건 끄는 것은 권장하지 않습니다. 인증서 검사 문제를 분리해서 확인할 때만 잠시 테스트하고, 원인이 확인되지 않으면 다시 기본값으로 되돌리는 편이 안전합니다.

주의

VS Code를 관리자 권한으로 실행하거나 회사 보안 프로그램이 설치된 환경에서는 일반 앱과 프록시 상속 방식이 다를 수 있습니다. 먼저 VS Code를 완전히 종료하고, 작업 관리자나 활동 모니터에 남아 있는 프로세스까지 정리한 뒤 다시 실행하세요.

2단계: 노드 문제인지 규칙 문제인지 분리하기

Clash의 프록시 목록에서 지연 시간이 낮은 노드를 선택했다고 해서 GitHub Copilot 연결이 반드시 성공하는 것은 아닙니다. 지연 측정은 특정 테스트 주소에 대한 결과일 뿐이며, GitHub API와 스트리밍 연결이 같은 품질을 보장하지는 않습니다. 반대로 모든 노드가 실패하는 것처럼 보여도 실제 원인은 특정 도메인이 DIRECT로 빠지는 규칙일 수 있습니다.

가장 빠른 분리 방법은 잠시 Global 모드로 전환해 동일한 VS Code 작업을 다시 수행하는 것입니다. Global 모드에서 로그인과 자동완성이 정상이라면 노드 자체보다는 Rule 모드의 규칙 또는 DNS를 의심해야 합니다. Global 모드에서도 계속 타임아웃이 발생한다면 다른 노드로 바꾸고, Clash 로그에 표시되는 원격 주소와 오류 유형을 확인하세요.

관찰 결과	가능성이 높은 원인	다음 점검
Global과 Rule 모두 실패	노드, 포트, 방화벽, TLS 연결	다른 노드와 외부 네트워크에서 재시험
Global은 성공하고 Rule만 실패	도메인 규칙 또는 정책 그룹	Connections에서 매칭된规则과出站 확인
브라우저는 성공하지만 VS Code만 실패	앱 프록시 상속, 확장 캐시, 인증서	VS Code 프록시 설정과 로그 확인
로그인은 되지만 자동완성만 실패	Copilot API 또는 스트리밍 연결	관련 호스트의 규칙과 장시간 연결 확인

Clash의 Logs 화면에서 GitHub 또는 Copilot 관련 요청을 찾을 때는 도메인 이름만 보지 말고 어떤 정책 그룹으로 전달되었는지 함께 확인해야 합니다. 요청이 반복해서 DIRECT로 표시되는데 현재 네트워크에서 해당 서비스가 직접 연결되지 않는다면, 해당 도메인에 프록시 정책을 적용해야 합니다. 반대로 모든 요청이 프록시로 들어가지만 원격 연결에서 타임아웃이 발생한다면 노드 품질이나 업스트림 차단을 먼저 확인합니다.

팁

테스트할 때는 한 번에 여러 설정을 바꾸지 마세요. 같은 노드에서 Global 모드와 Rule 모드를 비교하고, 그다음 노드만 바꾸어 결과를 기록하면 원인을 훨씬 정확하게 분리할 수 있습니다.

3단계: GitHub Copilot 도메인 규칙과 DNS 확인

Copilot 연결 오류에서 규칙 문제는 특히 찾기 어렵습니다. 사용자는 github.com만 허용하면 충분하다고 생각할 수 있지만, VS Code 확장 프로그램은 로그인·API·콘텐츠 전송을 위해 여러 호스트를 호출합니다. 구독 설정의 규칙 제공자가 오래되었거나, GitHub 관련 도메인을 직접 연결하도록 정의했다면 메인 페이지는 열려도 Copilot 요청만 타임아웃될 수 있습니다.

먼저 Clash Connections에서 VS Code를 실행한 직후 발생하는 요청을 관찰하세요. 요청이 보이지 않는다면 VS Code가 Clash를 우회하고 있을 가능성이 큽니다. 요청은 보이지만 정책이 DIRECT라면 규칙 매칭 결과를 확인해야 합니다. 요청이 특정 프록시 그룹으로 전달되는데 그 그룹의 노드가 응답하지 않는다면 해당 그룹에서 다른 노드를 선택하거나, 테스트 목적에 한해 신뢰할 수 있는 프록시 그룹으로 바꾸어 보세요.

로그인 관련 요청: GitHub 인증 페이지와 OAuth 흐름이 중간에 끊기지 않는지 확인합니다.
API 요청: GitHub API 또는 Copilot 서비스 요청이 직접 연결로 빠지지 않는지 확인합니다.
스트리밍 요청: 자동완성 입력 후 연결이 오래 유지되는지, 즉시 reset되지 않는지 확인합니다.
규칙 우선순위: 넓은 DOMAIN-SUFFIX 또는 GEOIP 규칙이 세부 도메인보다 먼저 적용되지 않는지 확인합니다.

DNS도 함께 살펴봐야 합니다. Clash의 DNS가 켜져 있어도 운영체제나 브라우저, 보안 프로그램이 별도의 DNS 경로를 사용할 수 있습니다. 도메인이 잘못된 주소로 해석되면 연결 로그에 프록시 요청이 나타나기 전에 실패하거나, 정상적인 노드에서도 타임아웃처럼 보일 수 있습니다. fake-ip를 사용한다면 GitHub와 인증 관련 도메인이 fake-ip-filter에 잘못 포함되어 있지 않은지도 확인하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fallback:
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true

이 설정은 모든 환경에 그대로 적용하는 정답이 아닙니다. 회사망이나 학교망에서는 특정 DNS, DoH, UDP 요청이 차단될 수 있으므로 현재 네트워크에서 실제로 도달 가능한 서버를 사용해야 합니다. 설정을 바꾼 뒤에는 Clash의 DNS 캐시를 비우고 VS Code를 다시 시작하세요. 브라우저의 보안 DNS가 켜져 있다면 브라우저 테스트 결과만으로 VS Code의 DNS 상태를 판단하지 않는 것이 좋습니다.

규칙을 수정할 때의 주의점

공식 도메인 전체를 무조건 프록시로 보내는 방식은 임시 진단에는 유용하지만, 장기간 사용하면 불필요한 트래픽과 지연이 늘어날 수 있습니다. 원인을 확인한 뒤에는 필요한 도메인과 정책만 남기고, 제공업체의 규칙 업데이트와 충돌하지 않는지 확인하세요.

4단계: VS Code 인증 상태와 최종 연결 검증

프록시와 규칙을 수정했는데도 Copilot이 계속 연결되지 않으면 VS Code에 남아 있는 인증 토큰이나 확장 프로그램 상태를 점검해야 합니다. 네트워크가 잠시 끊긴 뒤 만료된 토큰이 캐시에 남으면, 정상적인 프록시 연결을 복구한 뒤에도 로그인 실패가 반복될 수 있습니다. 이때는 계정을 무작정 삭제하기보다 먼저 출력 패널의 로그를 저장해 현재 오류를 확인하는 것이 좋습니다.

VS Code의 확장 프로그램 화면에서 GitHub Copilot과 관련 확장 프로그램이 활성화되어 있는지 확인합니다.
보기 → 출력 메뉴에서 출력 채널을 GitHub Copilot 또는 관련 항목으로 변경합니다.
로그에 proxy, certificate, 401, 403, timeout 중 어떤 메시지가 반복되는지 기록합니다.
명령 팔레트에서 GitHub 로그아웃을 실행한 뒤 VS Code를 재시작하고 다시 로그인합니다.
로그인 과정에서 브라우저가 열리면 브라우저도 같은 Clash 정책을 사용하는지 확인합니다.

401이나 403은 단순한 네트워크 타임아웃과 다릅니다. 이 경우에는 계정 권한, 조직 정책, Copilot 구독 상태, 오래된 인증 토큰을 확인해야 합니다. 반면 연결이 일정 시간 후 끊기고 로그에 ETIMEDOUT 또는 i/o timeout이 반복된다면 노드와 라우팅 경로의 문제일 가능성이 더 높습니다. 인증 오류와 네트워크 오류를 같은 방식으로 해결하려고 하면 설정만 복잡해집니다.

최종 확인은 다음 순서로 진행하면 됩니다. 먼저 Clash를 Rule 모드에 두고 브라우저에서 GitHub를 열어 봅니다. 다음으로 VS Code에서 Copilot 상태를 확인하고, 짧은 코드 주석이나 함수 이름을 입력해 자동완성 요청을 발생시킵니다. 그 순간 Clash Connections에 요청이 나타나고, 의도한 프록시 그룹으로 전달되며, 로그에 반복적인 타임아웃이 없는지 확인합니다. 한 번 성공한 뒤에도 장시간 스트리밍이 안정적인지 확인해야 하므로 여러 번 입력하고 몇 분간 상태를 지켜보세요.

일부 프록시 클라이언트는 화면에서 노드 선택과 시스템 프록시 전환을 쉽게 제공하지만, 앱별 프록시 상속이나 규칙 로그가 제한적이라 원인 파악에 시간이 걸릴 수 있습니다. 반면 Clash는 노드·규칙·DNS·연결 로그를 한 흐름에서 확인할 수 있고, VS Code처럼 예외적인 앱도 로컬 포트와 TUN 모드로 세밀하게 다룰 수 있습니다. 설정을 직접 조정하는 과정이 처음에는 번거롭게 느껴져도, GitHub Copilot 타임아웃처럼 특정 앱에서만 재현되는 문제를 추적할 때는 이러한 투명성이 큰 장점입니다. 비슷한 프록시 도구에서 원인과 경로가 보이지 않아 계속 노드만 교체하고 있었다면, 이 글의 점검 순서를 적용할 수 있는 Clash를 사용해 보세요. Clash 무료 다운로드（Windows）를 통해 환경에 맞는 클라이언트를 확인하고 직접 안정성을 비교해 볼 수 있습니다.