v2rayN 시스템 프록시가 작동하지 않을 때: 브라우저와 명령줄 터미널 점검

먼저 구분할 것: 시스템 프록시, 앱 프록시, 라우팅

시스템 프록시를 켰다고 모든 프로그램이 v2rayN을 거치는 것은 아닙니다. Windows 프록시 설정은 앱이 직접 읽어야 합니다. 브라우저는 보통 시스템 설정을 따르지만, 많은 명령줄 도구는 자체 옵션이나 환경 변수에 의존합니다. 브라우저는 접속되는데 터미널은 실패하더라도 노드에 문제가 있다고 단정할 수 없습니다.

점검을 시작하기 전에 변수를 고정하세요. TUN은 잠시 끄고, 실행 중인 프록시 클라이언트 하나와 노드 하나, 테스트 주소 하나만 사용합니다. 여기서는 요청 방법을 보여주기 위해 https://example.com을 사용합니다. 특정 지역에서 접속 가능한지 확인하는 전용 테스트 사이트는 아니므로, 실제 문제를 점검할 때는 원래 실패했던 주소로도 다시 테스트하세요.

1단계: 로컬 프록시 포트가 실제로 연결을 수신하는가?

브라우저를 변경하기 전에 로컬 접속 경로부터 확인하세요. 아래 예시에서는 HTTP 프록시를 지원한다고 확인한 127.0.0.1:10808을 사용합니다. 모든 버전의 기본 포트가 이 값이라는 뜻은 아닙니다. 클라이언트에 다른 포트가 표시되면 모든 명령에서 같은 값으로 바꾸세요. 이전 안내의 HTTP 포트와 SOCKS 포트를 혼동하지 않도록 주의해야 합니다.

1. 접속 경로 확인

   v2rayN에서 「설정」→「매개변수 설정」으로 이동한 뒤, 기본 설정의 로컬 수신 관련 항목에서 포트와 접속 프로토콜을 확인하세요. 화면 버전에 따라 그룹 이름이 다를 수 있습니다. 포트 번호만 보고 프로토콜을 추측하지 말고, 메인 화면 상태와 코어 시작 로그도 함께 확인하세요.

2. 수신 상태 확인

   PowerShell에서 아래 Test-NetConnection을 실행하세요. TcpTestSucceeded가 False라면 먼저 코어가 종료되었는지, 포트를 잘못 입력했는지 확인한 다음 시작 로그를 살펴보세요.

3. 프로세스 확인

   netstat으로 수신 대기 항목과 PID를 확인한 뒤 작업 관리자의 「세부 정보」에서 해당 프로세스를 찾으세요. 포트 연결에 성공해도 프로그램이 연결을 받고 있다는 뜻일 뿐, 그 프로그램이 현재 v2rayN에서 실행한 코어라는 보장은 없습니다.

4. 프록시를 지정해 요청 보내기

   뒤에 나오는 curl.exe --proxy 명령으로 접속 경로를 직접 지정하세요. 이 단계가 성공하면 시스템 프록시를 점검하고, 실패하면 접속 프로토콜과 노드 매개변수, 코어 오류부터 확인하세요.

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
netstat -ano | findstr ":10808"

코어 로그에 address already in use가 표시되면 먼저 포트 충돌을 해결해야 합니다. 정체를 모르는 프로세스를 바로 종료하지 마세요. 어떤 프로그램인지 확인한 뒤 중복 실행을 닫거나 로컬 포트를 변경하고, 시스템 프록시 설정을 다시 적용하세요.

브라우저에서 프록시가 작동하지 않을 때: 시스템 설정, 확장 프로그램, PAC 점검

브라우저를 점검할 때는 현재 실제로 적용 중인 프록시 설정이 무엇인지 파악하는 것이 중요합니다. Edge나 Chrome에서는 시스템 설정, 프록시 확장 프로그램, 시작 매개변수, 조직 정책이 모두 연결에 영향을 줄 수 있습니다. v2rayN 아이콘이 시스템 트레이에 보인다는 사실만으로 브라우저가 v2rayN을 사용한다고 볼 수는 없습니다.

1. 시스템 프록시 적용

   v2rayN 시스템 트레이 메뉴에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택하세요. 그런 다음 Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 주소와 포트가 현재 로컬 접속 경로와 일치하는지 확인합니다.

2. 프록시 확장 프로그램 사용 중지

   브라우저의 「확장 프로그램」→「확장 프로그램 관리」에서 프록시를 관리하는 확장 프로그램을 잠시 사용 중지한 뒤 브라우저를 다시 시작하세요. 시크릿 창만 사용하는 것으로는 충분하지 않습니다. 일부 확장 프로그램은 시크릿 창에서도 실행되도록 허용할 수 있고, 브라우저 정책도 계속 적용됩니다.

3. 자동 구성 스크립트 확인

   Windows의 같은 「프록시」 페이지에서 「설정 스크립트 사용」을 확인하세요. 켜져 있다면 스크립트 주소와 규칙을 점검합니다. 점검 중에는 기존 값을 기록한 뒤 단일 수동 프록시로 잠시 바꾸세요. PAC가 DIRECT를 반환해 판단을 흐리는 일을 막을 수 있습니다.

4. 다시 테스트하고 로그 확인

   브라우저를 완전히 닫았다가 다시 열고 같은 테스트 주소에 접속하면서 코어의 액세스 로그를 확인하세요. 요청이 코어에 들어온 뒤에는 출구 태그도 확인해야 합니다. 직접 연결 규칙이 적용됐다면 라우팅 선택의 문제이지 시스템 프록시가 작동하지 않는 것은 아닙니다.

PAC는 “앱이 요청을 어디로 전달할지” 결정하고, 코어 라우팅은 “요청을 받은 뒤 어디로 보낼지” 결정합니다. 어느 계층에서든 트래픽이 직접 연결될 수 있지만 해결해야 할 위치는 다릅니다. 한 웹사이트만 프록시를 거치게 하려고 PAC와 DNS, 모든 라우팅 규칙을 한꺼번에 바꾸지 마세요.

터미널에서 프록시가 작동하지 않을 때: curl 옵션으로 확인한 뒤 환경 변수 설정

명령줄 프로그램은 Windows에서 시스템 프록시를 켰다고 자동으로 경로를 바꾸지 않는 경우가 많습니다. 먼저 명령줄 옵션을 직접 지정해 확인한 다음 환경 변수를 설정하세요. PowerShell에서는 curl.exe를 전체 이름으로 입력하는 것이 좋습니다. Windows PowerShell에서 curl 별칭이 다른 명령을 실행해 옵션이 다르게 해석되는 일을 막을 수 있습니다.

요청 한 번으로 HTTP 프록시 확인

아래 명령은 시스템 프록시 설정을 사용하지 않습니다. 이번 요청에서 --noproxy는 우회 대상을 예약 테스트 도메인 unused.invalid로 제한합니다. 기존 NO_PROXY 설정 때문에 example.com이 예기치 않게 직접 연결되는 일을 방지하기 위한 것입니다. 이 명령은 영구 설정을 변경하지 않습니다.

curl.exe --proxy http://127.0.0.1:10808 --noproxy unused.invalid --connect-timeout 10 --verbose --head https://example.com

상세 출력에서 127.0.0.1에 연결된 기록과 HTTPS 요청의 CONNECT 과정을 확인하면 접속 경로가 작동하는지 판단할 수 있습니다. HTTP 응답 코드는 그 뒤 요청의 결과를 나타냅니다. 응답을 받았다고 반드시 원격 프록시 노드를 거쳤다는 뜻은 아니므로 코어의 출구 기록도 비교하세요. 로그를 공유하기 전에는 인증 정보와 민감한 주소를 삭제해야 합니다.

현재 PowerShell 세션에 프록시 설정

$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

curl.exe --connect-timeout 10 --head https://example.com

HTTPS_PROXY에 http://를 쓰는 것은 정상입니다. 이 값은 터미널에서 로컬 HTTP 프록시까지 연결하는 방식을 나타내며, HTTPS 대상은 보통 CONNECT 터널로 접속합니다. 대상 URL이 HTTPS라는 이유만으로 프록시 접속 주소를 임의로 https://로 바꾸지 마세요.

• 적용 범위: PowerShell에서 설정한 이 값은 현재 세션과 이후에 실행되는 하위 프로세스에만 적용됩니다. 이미 실행 중인 다른 터미널에는 변수가 전달되지 않습니다.
• 도구별 차이: 환경 변수가 모든 도구에 강제로 적용되는 것은 아닙니다. 도구에 따라 소문자 변수나 전용 설정, 명령줄 옵션이 필요할 수 있으니 해당 도구의 문서를 확인하세요.
• 터미널별 차이: WSL과 컨테이너는 별도의 네트워크 환경을 사용할 수 있습니다. 이 환경의 127.0.0.1이 Windows 호스트의 접속 경로를 가리키지 않을 수도 있으므로 주소를 그대로 복사해 사용하지 마세요.
• SOCKS 접속 경로: 해당 포트가 SOCKS5를 지원한다고 확인한 경우에만 전용 옵션을 사용하세요. curl의 socks5h://는 대상 도메인 처리를 프록시에 맡긴다는 뜻입니다. HTTP만 지원하는 포트에 연결할 때 사용하면 안 됩니다.

테스트 후 세션 변수 삭제

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

삭제하기 전에 기존 값을 기록해 두세요. 프록시 환경 변수가 설정된 PC라면 원래 구성으로 되돌려야 합니다. 특히 테스트 변수를 시스템 환경 변수로 급히 저장하지 마세요. v2rayN을 종료해 로컬 포트가 닫힌 뒤에도 변수를 상속한 프로그램은 계속 연결 오류를 낼 수 있습니다.

오류 메시지에 따라 어느 계층을 수정해야 할까?

오류는 발생한 위치와 함께 해석해야 합니다. 같은 “시간 초과”라도 터미널이 로컬 접속 경로에 연결할 때, 코어가 원격 서버에 연결할 때, 원격 서버가 대상 사이트에 접속할 때 발생할 수 있습니다. 아래에는 실제 오류 문구를 정리했습니다. 버전에 따라 앞뒤에 주소, 포트, 소요 시간이 추가될 수 있습니다.

TUN 모드는 언제 더 편리할까?

여러 앱이 시스템 프록시를 따르지 않고 각각 설정하기도 어렵다면 TUN을 고려할 만합니다. TUN은 가상 인터페이스와 라우팅으로 트래픽을 전달하지만 사용 중인 코어, DNS 정책, 제외 규칙의 영향을 받습니다. 모든 트래픽이 조건 없이 원격 노드로 들어간다는 뜻은 아닙니다.

• 먼저 기준 상태를 기록하세요: HTTP 프록시를 직접 지정한 테스트가 성공하는지 확인하고 현재 노드와 라우팅 설정을 기록한 뒤 TUN을 켜세요. 그렇지 않으면 접속 경로 문제와 가상 네트워크 어댑터 문제가 뒤섞입니다.
• 안내에 따라 권한을 부여하세요: v2rayN 메인 화면에서 TUN을 켜세요. 관리자 권한이 필요하다는 안내가 표시되면 안내에 따라 프로그램을 다시 시작하고, 가상 인터페이스와 라우팅, DNS 초기화 로그를 확인하세요.
• 중복 설정을 피하세요: 처음 비교 테스트할 때는 터미널 프록시 변수를 지우고 「시스템 프록시」를 「시스템 프록시 지우기」로 바꿔 TUN 경로만 확인하세요. 접속 경로를 여러 개 동시에 변경하지 마세요.
• 업무 네트워크를 유지하세요: 로컬 네트워크 기기와 사내 도메인에 정상적으로 접속되는지 테스트하세요. 다른 가상 네트워크 어댑터나 업무 네트워크와 충돌한다면 먼저 TUN을 꺼서 복구한 다음 제외 항목을 조정하세요.

자주 묻는 질문: 프록시를 켰는데 왜 결과가 다를까?

최종 판단은 관찰 가능한 세 가지 결과를 기준으로 내리세요. 앱이 로컬 접속 경로에 연결했는지, 코어가 요청을 받았는지, 해당 요청이 어떤 출구를 선택했는지 확인하면 됩니다. 이 순서대로 근거를 모으면 클라이언트를 반복해서 재설치하거나 DNS를 임의로 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 처음 가져오기와 프록시 설정을 다시 확인하려면 빠른 시작 가이드를 참고하세요.