v2rayN은 실행 중인데 브라우저에서 사이트가 열리지 않거나, 터미널은 프록시를 거치지 않고 직접 연결되거나, 일부 앱만 연결되는 경우에 해당합니다. 먼저 프록시를 명시한 요청으로 로컬 프록시 진입점을 확인한 뒤 브라우저의 프록시 설정, 시스템 PAC 설정, 터미널 환경 변수를 각각 점검하세요. 아래 내용은 Windows를 중심으로 설명하고 Bash와 Zsh에서 확인하는 명령도 덧붙였습니다. 예시 포트는 실제 클라이언트 수신 포트로 바꿔야 합니다.
1. 시스템 프록시, 앱 연결, 라우팅을 구분하기
v2rayN의 ‘시스템 프록시 자동 설정’은 컴퓨터의 모든 네트워크 요청을 프록시로 강제 전송하는 기능이 아닙니다. 시스템 프록시 설정을 변경하며, 해당 설정을 읽는 앱만 로컬 프록시 진입점을 사용합니다. 브라우저는 보통 시스템 설정을 따르지만 확장 프로그램, 브라우저 정책, 별도의 프록시 설정이 이를 덮어쓸 수 있습니다. 명령줄 도구가 설정을 읽는지는 각 도구의 구현에 따라 다릅니다.
라우팅 모드는 프록시에 연결된 다음 단계입니다. ‘전역’을 선택해도 로컬 수신 포트로 들어오지 않은 요청은 프록시에 연결되지 않습니다. 반대로 코어에 들어온 요청도 현재 라우팅 규칙에 따라 직접 연결될 수 있습니다. 문제를 확인할 때는 먼저 요청이 들어왔는지 확인하고, 그다음 어떤 아웃바운드로 전달됐는지 살펴보세요. 두 설정을 혼동하지 않는 것이 중요합니다.
- 브라우저는 되는데 터미널은 안 되는 경우: 노드를 바꾸기보다 터미널의 프록시 옵션과 환경 변수를 먼저 확인하세요.
- 프록시를 명시하면 되는데 브라우저에서 안 되는 경우: 확장 프로그램, PAC, 브라우저의 별도 프록시 설정을 먼저 확인하세요.
- 프록시를 명시해도 연결되지 않는 경우: 포트, 코어 실행 상태, 아웃바운드 로그부터 확인하세요. 시스템 프록시 스위치는 우선 확인할 대상이 아닙니다.
- 일부 도메인에서만 문제가 생기는 경우: 우회 목록, 라우팅 규칙, DNS, 대상 사이트의 응답을 확인하세요.
2. 포트를 지정해 로컬 프록시 진입점 확인하기
먼저 v2rayN 메인 화면 하단의 상태 표시줄에서 로컬 포트를 확인한 다음, ‘설정’ → ‘매개변수 설정’에서 수신 포트와 프로토콜을 확인하세요. 버전에 따라 SOCKS, HTTP 또는 혼합 수신 진입점으로 표시될 수 있습니다. 다른 가이드에 나온 포트 번호를 이 PC의 설정이라고 가정하면 안 됩니다. 아래 예시는 127.0.0.1:10808에서 HTTP 프록시 요청을 받는 것을 확인했다고 가정합니다. 해당 포트가 SOCKS만 지원한다면 뒤에 나오는 SOCKS 명령을 사용하세요.
Windows PowerShell에서는 먼저 포트에 연결할 수 있는지 확인한 뒤 curl.exe로 프록시를 명시해 요청하세요. curl.exe로 입력하면 일부 Windows PowerShell 환경에서 curl 별칭이 다른 명령을 가리키는 문제를 피할 수 있습니다. 테스트 대상은 https://example.com/입니다. 요청 경로를 확인하기 위한 주소일 뿐, 특정 서비스 사이트에 접속할 수 있음을 보장하지는 않습니다.
Test-NetConnection 127.0.0.1 -Port 10808
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 20 -I -v https://example.com/--noproxy ""는 이번 명령에서 우회 목록을 비워 기존 NO_PROXY 설정이 테스트에 영향을 주지 않게 합니다. 진입점이 SOCKS5만 지원한다면 아래 명령을 사용하세요. socks5h는 curl이 로컬에서 먼저 도메인을 조회하는 대신 프록시 서버에 대상 도메인 처리를 맡긴다는 뜻입니다.
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 20 -I -v https://example.com/요점: 진입점을 먼저 확인한 다음 자동 프록시 설정 점검하기
프록시를 명시한 요청으로 대상 사이트의 HTTP 응답을 받은 뒤 브라우저와 터미널의 자동 프록시 설정을 확인하세요. 200 Connection established만으로는 충분하지 않습니다. 터널이 연결됐다는 뜻이므로 TLS 핸드셰이크와 이후 대상 서버의 응답도 확인해야 합니다. 대상 서버가 403을 반환했다고 로컬 포트가 작동하지 않는 것은 아닙니다.
3. 브라우저의 확장 프로그램과 남은 PAC 설정 확인하기
여기서는 Windows 11의 Chrome, Edge, Firefox를 예로 듭니다. 먼저 현재 프록시 설정을 기록하세요. 특히 회사 네트워크에서 사용하는 스크립트 주소를 확인해야 합니다. 조직에서 관리하는 기기는 관리자 지침에 따라 처리하고 기존 설정을 함부로 삭제하지 마세요. 시크릿 창은 확장 프로그램을 확실히 분리해 테스트하는 방법이 아닙니다. 일부 확장 프로그램은 시크릿 모드에서도 허용될 수 있고 시스템 설정도 그대로 적용됩니다.
-
프록시 확장 프로그램 사용 중지하기
Chrome에서는 ‘확장 프로그램’ → ‘확장 프로그램 관리’를, Edge에서는 ‘확장’ → ‘확장 관리’를 여세요. 프록시, 자동 전환 규칙 또는 네트워크 요청을 제어하는 확장 프로그램을 잠시 사용 중지한 뒤 모든 브라우저 창을 닫고 다시 실행해 같은 주소로 테스트하세요.
-
시스템 프록시 진입점 확인하기
Windows에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 여세요. ‘수동 프록시 설정’의 주소와 포트가 로컬 HTTP 또는 혼합 수신 진입점과 일치하는지 확인하세요. 주소만 입력하는 칸에는
127.0.0.1을 입력하고 전체 프록시 URL을 넣지 마세요. -
스크립트 설정 확인하기
같은 페이지에서 ‘설정 스크립트 사용’을 확인하세요. 개인 기기에서 이전 PAC 주소가 계속 활성화되어 있다면 주소를 기록한 후 잠시 끄고, 테스트할 연결 방식 하나만 남기세요. 스크립트, 수동 포트, 라우팅 사전 설정을 한꺼번에 바꾸면 어떤 설정으로 문제가 해결됐는지 알 수 없습니다.
-
별도 프록시 설정 확인하기
Firefox에서 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 여세요. v2rayN이 적용한 시스템 설정을 따르려면 ‘시스템 프록시 설정 사용’을 선택하세요. 수동 프록시를 유지한다면 각 포트를 확인하세요. SOCKS 전용 포트를 HTTP 프록시 칸에 입력하지 마세요.
-
시스템 프록시 설정 다시 적용하기
로컬 프록시를 명시한 테스트가 성공한 것을 확인한 뒤 v2rayN 트레이 메뉴의 ‘시스템 프록시’에서 먼저 ‘시스템 프록시 해제’를 선택하고, 이어서 ‘시스템 프록시 자동 설정’을 선택하세요. 그런 다음 Windows 프록시 페이지를 다시 열어 주소와 포트가 예상대로 바뀌었는지 확인합니다.
PAC는 URL이나 도메인 등의 조건에 따라 사용할 프록시를 선택하는 스크립트로, 일부 요청을 직접 연결하도록 지정할 수 있습니다. 따라서 ‘스크립트 주소가 설정되어 있다’는 사실만으로 모든 요청이 v2rayN을 거친다고 볼 수는 없습니다. 브라우저에 설정이 조직에서 관리된다고 표시되거나 설정을 꺼도 자동으로 다시 켜진다면 시스템 프록시 버튼을 반복해서 누르지 말고 관리 정책과 실행 중인 다른 프록시 도구를 확인하세요.
4. 터미널의 변수, 프로토콜, 프로세스 환경 확인하기
브라우저에서 접속된다고 터미널도 자동으로 프록시를 사용하는 것은 아닙니다. curl 같은 도구는 앞 절의 --proxy 옵션으로 먼저 테스트한 뒤 현재 터미널 세션에 환경 변수를 설정하세요. https_proxy는 ‘HTTPS 대상에 접속할 때 사용할 프록시’를 뜻하며, 값은 http://127.0.0.1:10808이어도 됩니다. 클라이언트는 HTTP 프록시의 CONNECT 메서드로 대상까지 TLS 터널을 만들기 때문에 프록시 URL을 HTTPS로 바꿀 필요가 없습니다.
PowerShell: 먼저 확인하고 현재 세션에 설정하기
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'
$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'
Remove-Item Env:all_proxy -ErrorAction SilentlyContinue
curl.exe --connect-timeout 5 --max-time 20 -I -v https://example.com/위와 같이 값을 지정하면 현재 PowerShell 프로세스와 이후 실행되는 하위 프로세스에만 적용됩니다. 이미 실행 중인 터미널, 편집기, 백그라운드 작업의 환경 변수는 자동으로 바뀌지 않습니다. Windows에서는 환경 변수 이름의 대소문자를 구분하지 않지만 다른 시스템에서는 대소문자별 변수도 확인해야 합니다. 인증 정보가 포함된 프록시 변수의 출력 내용을 공개 게시판에 올리지 마세요.
Bash / Zsh: 충돌하는 변수 정리 후 소문자 변수 사용하기
env | grep -iE '^(http|https|all|no)_proxy='
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY all_proxy
export http_proxy='http://127.0.0.1:10808'
export https_proxy='http://127.0.0.1:10808'
export no_proxy='localhost,127.0.0.1,::1'
curl --connect-timeout 5 --max-time 20 -I -v https://example.com/curl은 http_proxy의 대소문자를 특별히 처리하므로 여러 플랫폼에서 문제를 확인할 때는 소문자 변수를 우선 사용하세요. ALL_PROXY는 일부 도구에서 지원하는 공통 프록시 변수지만 모든 도구가 이를 읽는다고 가정하면 안 됩니다. NO_PROXY는 프록시를 우회할 때 사용합니다. 여기에 대상 도메인이 포함되어 있거나 값이 *로 설정되어 있으면 ‘변수는 설정했는데 요청은 직접 연결되는’ 상황이 생길 수 있습니다. 도구마다 일치 항목을 판별하는 문법도 완전히 같지는 않습니다.
- 현재 창에서만 실패하는 경우: 두 터미널 세션의 변수를 비교해 이전 창에 오래된 포트가 남아 있는지 확인하세요.
- 편집기 터미널에서 실패하는 경우: 편집기를 실행한 뒤 변수가 바뀌었다면 편집기를 다시 시작하세요. 새 터미널이 갱신된 환경을 상속합니다.
- 하위 시스템이나 컨테이너에서 실패하는 경우:
127.0.0.1은 호스트가 아니라 해당 환경 자체를 가리킬 수 있습니다. 실제 네트워크 모드에 맞춰 호스트 주소를 확인하고 호스트의 루프백 주소를 그대로 사용하지 마세요. - curl은 되는데 다른 도구는 실패하는 경우: 해당 도구의 별도 프록시 설정과 공식 지원 방식을 확인하세요. 이것만으로 v2rayN이 작동하지 않는다고 판단할 수는 없습니다.
테스트가 끝나면 PowerShell에서 Remove-Item Env:http_proxy,Env:https_proxy,Env:no_proxy -ErrorAction SilentlyContinue를 실행해 이번에 설정한 변수를 삭제할 수 있습니다. Bash / Zsh에서는 unset http_proxy https_proxy no_proxy를 사용하세요. 테스트 전에 값이 설정되어 있었다면 바로 삭제하지 말고 기록해 둔 원래 값으로 복원하세요.
5. 실제 오류 메시지로 실패 단계 찾기
명령줄의 전체 오류 메시지와 발생 시각을 기록하고, v2rayN 로그에서 같은 요청을 확인하세요. 아래는 curl에서 흔히 볼 수 있는 오류 문구입니다. 포트, 대상 주소, 제한 시간(밀리초)은 환경에 따라 달라집니다. 오류 코드는 원인을 좁히는 데 도움이 되지만 프록시를 명시한 테스트 결과와 함께 판단해야 합니다. ‘연결 실패’라는 문구만 보고 결론 내리지 마세요.
오류: curl: (7) Failed to connect to 127.0.0.1 port 10808
원인: curl이 이 로컬 진입점에 연결하지 못했습니다. 코어가 실행되지 않았거나 수신 포트가 다르거나 로컬 정책이 연결을 차단했을 수 있습니다.
해결: 실제 수신 포트와 코어 로그를 확인하고 Test-NetConnection으로 연결을 점검하세요. 수신 프로세스가 무엇인지 확인하고 방화벽 전체를 끄지는 마세요.
오류: curl: (5) Could not resolve proxy
원인: 프록시 서버 이름을 확인하지 못했습니다. 프록시 주소를 잘못 입력했거나 변수에 형식이 잘못된 호스트 이름이 들어 있는 경우가 흔합니다.
해결: 로컬 테스트에서는 확인된 루프백 주소와 포트를 명시하고 변수 값을 확인한 다음 같은 명령을 다시 실행하세요.
오류: curl: (28) Connection timed out
원인: 연결 또는 데이터 전송이 제한 시간을 초과했습니다. 시간 초과만으로는 로컬 진입점, 원격 아웃바운드, 대상 사이트 중 어디에 문제가 있는지 구분할 수 없습니다.
해결: -v 출력으로 로컬 포트에 연결됐는지 확인한 다음 같은 시각의 코어 로그를 대조해 아웃바운드 연결과 대상 서버 응답을 점검하세요.
오류: curl: (60) SSL certificate problem
원인: 인증서 검증에 실패했습니다. 시스템 시간, 인증서 신뢰 체인, 네트워크의 HTTPS 검사와 관련된 문제일 수 있으며 요청이 프록시에 들어가지 않았다는 뜻은 아닙니다.
해결: 시스템 날짜, 인증서 발급자, 시스템의 신뢰 설정을 확인하세요. 인증서 검증을 끄는 방법을 장기적인 해결책으로 사용하지 마세요.
로그에 요청이 직접 연결 규칙에 일치했다고 표시되면 브라우저를 재설치하지 말고 라우팅 규칙을 확인하세요. VMess, VLESS 등의 노드 프로토콜은 프록시 아웃바운드 연결을 설명하는 것입니다. 로컬 앱은 보통 HTTP 또는 SOCKS 진입점으로 연결됩니다. 노드 프로토콜 이름을 http_proxy에 넣어도 올바른 로컬 프록시 연결이 만들어지지 않습니다.
6. 테스트 결과를 비교해 한 번에 한 계층만 변경하기
설정은 한 번에 하나만 변경하고 같은 대상으로 다시 테스트하세요. 프록시를 명시한 curl 테스트, 환경 변수만 사용하는 curl 테스트, 프록시 확장 프로그램을 끈 브라우저 테스트의 세 가지 결과를 저장해 두는 것이 좋습니다. 이렇게 하면 문제를 좁힐 수 있고 클라이언트를 업데이트하거나 포트를 바꾸거나 네트워크를 전환한 뒤에도 같은 절차로 다시 점검할 수 있습니다.
- 프록시를 명시하면 성공하지만 변수 테스트는 실패하는 경우: 변수 값, 우회 목록, 프로세스 환경 상속, 도구 설정을 확인하세요.
- 두 curl 테스트는 성공하지만 브라우저에서 실패하는 경우: 확장 프로그램, PAC, 별도 프록시 설정, 관리 정책을 확인하세요.
- 포트에는 연결되지만 프록시를 명시한 요청은 실패하는 경우: 진입점 프로토콜이 일치하는지 확인한 뒤 코어 로그, 노드 연결, 대상 사이트를 살펴보세요.
- 모두 정상으로 돌아온 경우: 필요한 확장 프로그램과 기존 스크립트를 하나씩 다시 활성화하세요. 항목을 하나 복원할 때마다 테스트해 실제 충돌 원인을 찾으세요.
요점: 같은 요청의 프록시 연결 증거를 기준으로 판단하기
시스템 프록시 버튼의 상태는 설정을 적용했는지만 보여 줄 뿐, 대상 요청이 프록시를 통과했음을 증명하지 않습니다. 클라이언트 로그, curl 상세 출력, 앱의 프록시 설정을 서로 대조하면 전역 모드를 반복해서 전환하는 것보다 문제 발생 계층을 쉽게 찾을 수 있습니다.
추가 점검이 필요하다면 운영체제 버전, v2rayN 버전, 수신 프로토콜과 포트, 실패한 명령, 오류 발생 시각을 기록하세요. 로그를 제출하기 전에 구독 주소, 액세스 토큰, 노드 인증 정보, 개인이 사용하는 대상 주소를 삭제하세요. 구독 업데이트는 주로 연결 설정을 변경합니다. 터미널 환경 변수를 대신 설정하거나 브라우저 확장 프로그램의 프록시 제어를 자동으로 해제해 주지는 않습니다.