GitHub Copilot CLI 연결 실패? v2rayN 터미널 프록시 해결법

v2rayN에서는 브라우저와 다른 프로그램이 정상적으로 인터넷에 접속하는데 GitHub Copilot CLI만 로그인되지 않거나 명령 실행이 멈추는 경우가 있습니다. 이때 노드 자체가 고장 났다고 단정하기보다, 터미널에서 실행된 프로세스가 v2rayN의 로컬 프록시 포트를 사용하고 있는지 먼저 확인해야 합니다. 브라우저는 v2rayN이 켠 시스템 프록시를 자동으로 따를 수 있지만, 터미널 프로그램과 Node.js 기반 CLI는 환경 변수나 자체 프록시 설정이 없으면 직접 연결을 시도할 수 있습니다.

Copilot CLI 연결은 한 단계의 웹 접속만으로 끝나지 않습니다. 인증 페이지를 열고 장치 코드 또는 브라우저 인증을 완료한 뒤, CLI가 API 엔드포인트와 인증 서버에 다시 요청합니다. 따라서 브라우저 로그인 화면은 열리는데 CLI가 계속 대기하거나, 인증 코드 입력 후 ETIMEDOUT, ECONNRESET, fetch failed 같은 오류가 나타날 수 있습니다. 이 글에서는 v2rayN의 실제 로컬 포트 확인, Windows 터미널 환경 변수 설정, 프록시 전달 테스트, DNS 및 라우팅 점검, TUN 모드의 보완 방법을 순서대로 설명합니다.

왜 v2rayN은 연결되는데 Copilot CLI만 실패할까

v2rayN의 시스템 프록시 기능은 운영체제의 프록시 설정을 변경하는 방식입니다. 브라우저처럼 운영체제 프록시 설정을 읽는 애플리케이션은 이 값을 따라가지만, 모든 터미널 명령이 같은 동작을 하는 것은 아닙니다. CLI 프로그램은 실행 시점에 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 같은 환경 변수를 읽거나, 런타임이 제공하는 프록시 옵션을 별도로 사용합니다. 아무 설정도 없으면 터미널에서 실행된 요청이 로컬 프록시 포트가 아니라 현재 네트워크의 직접 연결로 나갈 수 있습니다.

특히 인증 과정은 여러 호스트를 연속해서 사용합니다. 장치 인증 페이지와 API 요청의 도메인이 서로 다를 수 있고, 로그인 이후에도 토큰 검증이나 Copilot 서비스 요청이 이어집니다. 한 도메인만 프록시를 통과하고 다른 도메인이 직접 연결되면 “로그인은 완료된 것처럼 보이지만 CLI가 준비되지 않음” 또는 “인증 코드를 확인한 뒤 응답 없음”과 같은 증상이 생깁니다. 따라서 브라우저에서 인증 페이지가 열렸다는 사실만으로 CLI의 모든 요청이 성공한다고 볼 수 없습니다.

먼저 v2rayN에서 현재 활성 서버와 코어 실행 상태를 확인하세요. 메인 화면의 시스템 프록시 메뉴가 켜져 있어도 코어가 중지되었거나, 터미널에 지정한 포트가 실제 HTTP 포트가 아니면 CLI는 연결할 수 없습니다. 설정 → 参数设置 또는 설치된 언어에 해당하는 매개변수 설정 화면에서 HTTP, SOCKS 로컬 포트를 확인하고, 문서나 예제에 나온 숫자를 그대로 복사하지 마세요. 환경에 따라 포트는 다를 수 있으며 다른 프로그램이 해당 포트를 이미 사용하고 있을 수도 있습니다.

v2rayN 로컬 포트와 프록시 형식 확인하기

v2rayN은 보통 HTTP 프록시와 SOCKS 프록시를 별도의 로컬 포트로 열 수 있습니다. 여기서 중요한 것은 포트 번호보다 포트의 프로토콜입니다. HTTP 포트에 socks5:// 주소를 넣거나 SOCKS 포트에 http://를 넣으면 포트가 열려 있어도 프록시 협상이 실패합니다. 먼저 v2rayN의 포트 표시 영역 또는 설정 화면에서 실제 유형을 확인한 뒤 같은 유형의 URL을 사용하세요.

Windows에서 포트가 열려 있는지만 확인하려면 PowerShell을 사용할 수 있습니다. 아래 명령의 포트 번호는 예시이므로 v2rayN에 표시된 값으로 바꾸세요.

Test-NetConnection 127.0.0.1 -Port 10809
Test-NetConnection 127.0.0.1 -Port 10808

TcpTestSucceeded : True가 표시되면 해당 로컬 포트에 TCP 연결을 만들 수 있다는 뜻입니다. 이것만으로 원격 노드나 Copilot API가 정상이라는 의미는 아닙니다. 포트가 닫혀 있으면 v2rayN 코어가 중지되었거나 다른 포트를 사용 중이거나, 방화벽 또는 포트 충돌이 원인일 수 있습니다. 포트가 열려 있는데 요청이 실패하면 다음 단계에서 프록시 형식과 환경 변수 상속을 확인합니다.

간단한 HTTPS 요청으로 HTTP 프록시 전달을 검증할 수도 있습니다.

curl.exe -I -x http://127.0.0.1:10809 https://github.com
curl.exe -I -x http://127.0.0.1:10809 https://api.github.com

응답 상태 코드가 200, 301, 302 또는 인증이 필요하다는 응답으로 돌아오면 적어도 해당 요청은 프록시를 통해 원격 서버까지 도달한 것입니다. 반대로 로컬 포트 연결 거부, TLS 핸드셰이크 실패, 일정 시간 후 시간 초과가 발생하면 CLI를 설정하기 전에 v2rayN 로그와 노드 라우팅을 먼저 점검해야 합니다.

터미널 세션에 프록시를 설정하고 로그인 테스트하기

가장 안전한 방법은 먼저 현재 터미널 세션에만 환경 변수를 설정하는 것입니다. 설정이 잘못되어도 새 창을 열면 원래 상태로 돌아가며, 다른 프로그램의 네트워크 동작까지 바꾸지 않습니다. PowerShell에서는 다음처럼 입력합니다.

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="http://127.0.0.1:10809"

curl.exe -I https://api.github.com

Copilot CLI 또는 그 실행 런타임이 SOCKS를 지원하고 v2rayN의 SOCKS 포트를 사용하려면 다음과 같이 바꿀 수 있습니다.

$env:HTTP_PROXY="socks5h://127.0.0.1:10808"
$env:HTTPS_PROXY="socks5h://127.0.0.1:10808"
$env:ALL_PROXY="socks5h://127.0.0.1:10808"

모든 CLI가 SOCKS URL을 동일하게 처리하는 것은 아니므로, 처음에는 HTTP 포트와 http:// 형식을 우선 시험하는 편이 좋습니다. ALL_PROXY만 설정했는데도 작동하지 않는다면 HTTPS 요청에 직접 사용되는 HTTPS_PROXY를 명시하세요. 변수 이름은 대소문자를 구분하지 않는 런타임도 있지만, 호환성을 위해 대문자와 소문자를 함께 설정할 수 있습니다.

1. 포트 확인

   v2rayN 메인 화면 또는 설정 → 매개변수 설정에서 HTTP 로컬 포트를 확인하고 코어가 실행 중인지 살핍니다.

2. 변수 적용

   PowerShell에 HTTP_PROXY, HTTPS_PROXY를 설정합니다. 우선 http://127.0.0.1:실제포트 형식을 사용합니다.

3. API 확인

   curl.exe -I https://api.github.com을 실행해 터미널 요청이 프록시를 통해 응답하는지 확인합니다.

4. CLI 로그인

   같은 터미널 창에서 Copilot CLI 로그인 명령을 실행하고, 브라우저 인증 후 터미널의 성공 또는 오류 메시지를 기록합니다.

5. 세션 고정

   검증이 끝난 뒤에만 사용자 환경 변수 또는 셸 프로필에 저장합니다. 비밀번호와 토큰은 변수 값에 넣지 않습니다.

명령 프롬프트를 사용한다면 문법이 다릅니다.

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
set ALL_PROXY=http://127.0.0.1:10809

이 설정은 현재 창과 그 창에서 시작한 자식 프로세스에만 적용됩니다. 이미 열려 있던 터미널에서 실행 중인 CLI에는 새 값이 자동으로 전달되지 않을 수 있으므로, 변수 설정 후 Copilot CLI를 다시 실행하세요. 영구 설정이 필요하다면 Windows 환경 변수 화면에서 사용자 변수로 등록할 수 있지만, 회사 네트워크나 다른 VPN을 사용하는 환경에서는 모든 개발 도구가 같은 프록시를 사용하게 된다는 점을 고려해야 합니다.

Linux 또는 macOS 셸과 유사한 환경에서는 다음 형식을 사용합니다. 실제 셸이 변수 구문을 지원하는지 확인하세요.

export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export ALL_PROXY="http://127.0.0.1:10809"
curl -I https://api.github.com

라우팅 규칙, DNS와 TUN 모드로 직접 연결 문제 보완하기

터미널에 프록시 변수를 넣었는데도 연결이 불안정하다면 v2rayN의 라우팅 규칙을 확인하세요. github.com과 API 도메인이 규칙에 의해 직접 연결로 분류되면, CLI가 로컬 HTTP 프록시에 도달한 뒤에도 Xray 코어가 원격 요청을 직접 보낼 수 있습니다. 반대로 로컬 주소나 v2rayN의 원격 서버 주소까지 프록시 규칙으로 되돌리면 순환 연결이 생길 수 있습니다. 일반적으로 로컬 사설 주소와 노드 연결에 필요한 예외를 먼저 처리하고, 필요한 서비스 도메인을 프록시 아웃바운드로 보내는 순서가 안전합니다.

PowerShell에서 현재 프록시 변수가 실제로 설정되었는지 확인하려면 다음 명령을 사용합니다.

Get-ChildItem Env: | Where-Object {
  $_.Name -match "PROXY"
}

변수 값이 출력되지 않으면 현재 셸은 프록시 정보를 전달받지 못한 것입니다. 값이 보이더라도 애플리케이션이 해당 변수를 지원한다는 보장은 없으므로, 반드시 curl.exe 같은 독립적인 요청으로 결과를 비교하세요. NO_PROXY가 넓게 설정되어 있으면 특정 GitHub 도메인이 우회될 수도 있습니다. 문제를 재현하는 동안에는 불필요한 NO_PROXY 항목을 제거하고, 로컬 주소 예외만 남기는 것이 원인 분리에 도움이 됩니다.

DNS 문제가 의심되면 노드 주소와 인증 대상 도메인을 각각 나누어 확인합니다. v2rayN의 코어 로그에서 도메인 해석 실패, 원격 DNS 연결 실패, no such host와 같은 문구를 찾으세요. 시스템 DNS가 해당 도메인을 해석하지 못하는 환경에서는 TUN 모드가 도움이 될 수 있지만, TUN을 켠다고 모든 CLI가 자동으로 같은 경로를 사용하는 것은 아닙니다. TUN은 운영체제 트래픽을 가상 네트워크 인터페이스로 받아 라우팅하는 방식이고, 환경 변수 프록시는 애플리케이션이 프록시 서버에 요청하도록 지시하는 방식입니다. 두 기능은 대체 관계가 아니라 필요에 따라 보완적으로 사용할 수 있습니다.

로그인 성공 여부와 재발 방지 확인

환경 변수와 라우팅을 수정한 뒤에는 여러 설정을 동시에 바꾸지 말고 한 번에 하나의 조건만 검증하세요. 먼저 v2rayN에서 활성 노드가 연결된 상태인지 확인하고, 그다음 새 터미널에서 프록시 변수를 설정합니다. 이어서 API 요청을 실행하고, 마지막으로 같은 창에서 Copilot CLI 로그인과 간단한 명령을 실행합니다. 인증 브라우저가 열렸다는 사실보다 CLI가 토큰을 저장하고 후속 요청까지 완료했다는 메시지가 중요합니다.

로그인 후에도 요청이 실패하면 토큰 문제와 네트워크 문제를 구분해야 합니다. 프록시를 사용한 curl 요청이 계속 성공하고 CLI만 인증 오류를 내면 CLI의 로그인 상태, 만료된 자격 증명 또는 조직 정책을 확인하세요. 반대로 curl부터 시간 초과가 발생하면 계정 정보를 반복해서 입력하지 말고 v2rayN 로그, 노드 상태, DNS와 라우팅을 먼저 복구해야 합니다. 인증 토큰이나 장치 코드는 공개 로그에 남기지 말고, 문제를 공유할 때도 값은 가린 상태로 기록하세요.