v2rayN 시스템 프록시가 작동하지 않을 때: 브라우저와 터미널 문제 해결

시스템 프록시는 모든 트래픽을 제어하는 스위치가 아닙니다

v2rayN의 시스템 프록시 기능은 주로 로컬 프록시 주소를 시스템 설정에 등록합니다. 앱이 이 설정을 참조하는지는 앱마다 다릅니다. 브라우저는 시스템 설정을 따를 수도 있고 확장 프로그램이나 별도 설정을 사용할 수도 있습니다. 명령줄 도구는 환경 변수나 자체 설정 파일을 읽는 경우가 많습니다. 따라서 “브라우저는 되는데 터미널은 안 되는” 상황은 모순이 아닙니다.

라우팅이 적용되는 두 단계도 구분해야 합니다. 먼저 앱이 요청을 로컬 프록시로 보낼지 결정하고, 요청을 받은 코어가 라우팅 규칙에 따라 직접 연결 또는 프록시 출구를 선택합니다. 요청이 v2rayN에 들어왔다고 해서 반드시 원격 노드를 거치는 것은 아닙니다. 시스템 프록시가 켜져 있어도 모든 프로세스가 요청을 프록시로 보내는 것은 아닙니다.

• 시스템 프록시: 시스템 설정을 따르는 앱에 프록시 연결 지점을 제공하며, 모든 네트워크 연결을 가로채는 기능은 아닙니다.
• PAC: 스크립트가 대상에 따라 프록시 주소나 DIRECT를 반환합니다. 직접 연결되는 것은 설정이 작동하지 않아서가 아니라 규칙에 따른 결과일 수 있습니다.
• 터미널 프록시: 주로 http_proxy, https_proxy, ALL_PROXY 환경 변수나 도구별 옵션을 사용합니다.
• TUN: 트래픽을 처리하는 별도의 경로입니다. 시스템 프록시와 혼동하지 않도록 이 글에서는 격리 테스트를 위해 먼저 TUN을 끕니다.

로컬 포트를 확인한 뒤 프록시 출구를 테스트하세요

아래 예시는 SOCKS 포트 10808과 HTTP 포트 10809를 사용합니다. 모든 버전에서 동일하게 쓰이는 고정값은 아닙니다. HTTP와 SOCKS 요청을 모두 받는 혼합 포트 하나만 제공하는 설정도 있습니다. 먼저 v2rayN의 「설정」→「매개변수 설정」에서 로컬 수신 관련 항목을 확인하고 시작 로그도 살펴보세요. 화면 항목은 버전에 따라 달라질 수 있으므로 실제 표시를 기준으로 확인해야 합니다.

PowerShell에서 아래 명령을 실행하세요. 먼저 포트가 수신 중인지 확인한 다음 curl.exe로 프록시를 명시해 요청합니다. 일부 PowerShell 환경에서 curl이 다른 명령의 별칭으로 해석되는 문제를 피하려고 프로그램 이름을 정확히 적었습니다. 대상 주소는 연결 확인용이므로 점검 중인 HTTPS 사이트로 바꿔도 됩니다.

# 예시 포트의 수신 상태 확인
Get-NetTCPConnection -State Listen -LocalPort 10808,10809 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

# HTTP 프록시: 프록시 우회 목록 무시, 최대 대기 시간 20초
curl.exe --noproxy "" --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/

# SOCKS 프록시: 대상 도메인 해석을 프록시 측에서 처리
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

HTTP 프록시로 HTTPS 대상에 접속하면 보통 먼저 200 Connection established가 표시됩니다. 이는 CONNECT 터널이 만들어졌다는 뜻일 뿐입니다. TLS 연결이 완료됐는지, 대상 사이트가 응답했는지도 확인해야 합니다. 사이트에서 HEAD 요청을 허용하지 않으면 -I를 빼고 -o NUL -D -를 사용해 GET 응답 헤더를 확인하세요.

브라우저 문제 해결: 시스템 설정, 확장 프로그램, PAC 확인

일반 브라우저 창에서 먼저 테스트하세요. 시크릿 창이라고 해서 모든 확장 프로그램이 반드시 꺼지는 것은 아닙니다. 일부 확장 프로그램은 시크릿 창에서 실행하도록 허용할 수 있습니다. 프록시 관련 확장 프로그램을 잠시 끄거나 새 브라우저 프로필을 사용하고, 기존 프로세스를 완전히 종료한 뒤 다시 실행하는 편이 확실합니다.

1. 시스템 프록시 설정

   v2rayN 트레이 메뉴에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택합니다. 코어가 실행 중인지 확인하세요. 여기서 말하는 “자동 설정”은 클라이언트가 시스템 설정을 변경하는 동작이며, PAC를 사용한다는 뜻은 아닙니다.

2. 시스템 프록시 연결 지점 확인

   Windows 11에서 「설정」→「네트워크 및 인터넷」→「프록시」를 열고 「프록시 서버 사용」에 표시된 주소와 포트를 확인하세요. 「설정 스크립트 사용」이 켜져 있다면 스크립트 주소도 기록하고 현재 필요한 설정인지 확인합니다.

3. 확장 프로그램이 설정을 덮어쓰는지 확인

   Chrome 주소창에 chrome://extensions/, Edge 주소창에 edge://extensions/를 입력해 프록시 전환 확장 프로그램을 잠시 끄세요. 그런 다음 브라우저의 「설정」→「시스템」 또는 「시스템 및 성능」에서 컴퓨터 프록시 설정을 열어 실제 연결 지점을 확인합니다.

4. 브라우저 자체 설정 확인

   Firefox에서 「설정」→「일반」→「네트워크 설정」→「설정」을 열고 테스트할 때는 「시스템 프록시 설정 사용」을 선택하세요. 「수동 프록시 설정」이나 「자동 프록시 구성 URL」을 선택하면 브라우저가 v2rayN에 등록된 설정을 따르지 않을 수 있습니다.

5. 같은 주소로 다시 테스트

   더 이상 필요하지 않은 PAC 스크립트를 잠시 비활성화하고, 수동 프록시가 실제 HTTP 포트 또는 혼합 포트를 가리키는지 확인한 뒤 명령줄 테스트와 같은 주소에 접속하세요. 테스트가 끝나면 기존 스크립트, 확장 프로그램, 우회 규칙을 복원합니다. 용도를 모르는 설정을 영구 삭제하지 마세요.

일부 도메인만 프록시를 거치지 않는다면 PAC가 DIRECT를 반환하는지, 시스템 프록시 예외 목록에 해당 도메인이 있는지, 코어 라우팅 규칙이 직접 연결로 처리하는지 확인하세요. PAC 선택은 요청이 코어에 들어오기 전에 이뤄지고, 코어 라우팅은 요청이 들어온 뒤에 적용됩니다. 해당 시간대의 접속 로그를 보면 어느 단계에서 결정됐는지 구분하는 데 도움이 됩니다.

• 브라우저는 열리지 않지만 프록시를 명시한 명령은 성공함: 확장 프로그램, 별도 프록시 설정, 시스템 정책을 먼저 확인하세요.
• 브라우저는 열리지만 접속 로그에 직접 연결로 표시됨: 브라우저 포트를 다시 바꾸기보다 코어 라우팅을 확인하세요.
• 스크립트를 끈 뒤 정상 작동함: PAC의 도메인 일치 규칙, 스크립트 주소 연결 상태, 브라우저 캐시를 확인하세요.

터미널 문제 해결: 환경 변수와 도구별 설정 확인

터미널 창 자체가 모든 명령의 네트워크 연결 방식을 결정하지는 않습니다. curl.exe, 패키지 관리자, 런타임마다 프록시 처리 방식이 다를 수 있습니다. 먼저 현재 PowerShell 프로세스의 프록시 환경 변수를 확인하고, 특히 NO_PROXY를 살펴보세요. 프록시 주소가 올바르더라도 우회 목록과 일치하는 대상에는 직접 연결할 수 있습니다.

# 현재 터미널 프로세스의 프록시 변수 확인
Get-ChildItem Env: |
  Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }

# Windows WinHTTP 프록시 확인: 별도 설정으로 기록
netsh winhttp show proxy

netsh winhttp show proxy에 표시되는 내용은 브라우저의 시스템 프록시 화면을 그대로 복사한 것이 아닙니다. WinHTTP와 사용자 수준 프록시는 별개의 설정 체계입니다. 이 화면에 “직접 연결”이라고 표시된다고 해서 v2rayN이 시스템 프록시를 등록하지 않았다고 단정할 수는 없습니다. 명령 하나를 고치려고 시스템 전체 설정을 성급하게 변경하는 것도 권장하지 않습니다.

아래 테스트는 현재 PowerShell 세션만 변경하고 종료할 때 원래 값을 복원합니다. 포트는 실제 HTTP 포트나 혼합 포트로 바꾸세요. HTTPS 대상에 http://127.0.0.1:10809를 프록시 주소로 사용하는 것은 정상입니다. 여기서 프로토콜은 로컬 프록시에 연결하는 방식을 나타내며 대상 사이트의 프로토콜을 의미하지 않습니다.

$names = @('http_proxy', 'https_proxy', 'ALL_PROXY', 'NO_PROXY')
$saved = @{}
foreach ($name in $names) {
  $saved[$name] = [Environment]::GetEnvironmentVariable($name, 'Process')
}

try {
  $env:http_proxy = 'http://127.0.0.1:10809'
  $env:https_proxy = 'http://127.0.0.1:10809'
  Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
  Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

  curl.exe --connect-timeout 10 --max-time 20 -I https://example.com/
}
finally {
  foreach ($name in $names) {
    if ($null -eq $saved[$name]) {
      Remove-Item "Env:$name" -ErrorAction SilentlyContinue
    }
    else {
      Set-Item "Env:$name" $saved[$name]
    }
  }
}

이 명령이 성공해도 현재 curl.exe가 이 변수들을 읽을 수 있다는 점만 확인된 것입니다. 다른 도구에서도 실패한다면 해당 도구의 프록시 옵션, 설정 파일, 실행 계정을 확인하세요. 이미 열려 있는 터미널은 나중에 변경한 사용자 환경 변수를 자동으로 가져오지 않는 경우가 많습니다. 설정을 영구 적용해야 한다고 확인한 뒤 사용자 변수를 수정하고 터미널을 다시 시작하세요. 처음부터 시스템 전체 설정으로 변경 범위를 넓히지 마세요.

오류 메시지로 원인을 좁히고 모든 실패를 노드 탓으로 돌리지 마세요

더 자세한 정보가 필요하면 테스트 명령에 -v를 추가해 로컬 프록시에 연결하는지 대상 주소에 직접 연결하는지 확인하세요. 출력을 공유하기 전에는 프록시 인증 정보, 구독 주소, 기타 민감한 매개변수를 가려야 합니다. 다음은 curl에서 흔히 볼 수 있는 오류이며 각각 해결 방법이 다릅니다.

로컬 수신은 정상인데 HTTP와 SOCKS를 명시한 테스트가 모두 출구 연결 단계에서 실패한다면 선택한 노드, 시스템 시간, 원격 설정을 점검하세요. VLESS 또는 VMess 노드는 전송 방식, TLS, 서버 매개변수도 확인해야 합니다. 이런 문제는 시스템 프록시 스위치를 전환해도 해결되지 않습니다. 구독을 업데이트한 뒤에는 목록이 새로고침됐는지만 보지 말고 현재 선택한 설정이 여전히 유효한지 확인하세요.

자주 묻는 질문과 복구 방법

마지막으로 기존 TUN, PAC, 확장 프로그램, 환경 변수를 복원하고 항목을 하나씩 되돌릴 때마다 다시 테스트하세요. 프록시를 명시한 정상 작동 명령을 기준으로 보관해 두면 다음에 문제가 생겨도 먼저 로컬 연결 지점과 출구를 확인한 뒤 앱이 트래픽을 전달하는지 점검할 수 있습니다. 이렇게 하면 문제 범위를 좁히고 브라우저 설정 문제를 노드 문제로 오인하는 일을 막을 수 있습니다.