이 글은 v2rayN에 노드 연결이 정상으로 표시되고 시스템 프록시도 켜져 있지만, 브라우저나 명령줄이 여전히 직접 연결되거나 시간 초과·접속 불가 상태인 경우에 적합합니다. 먼저 로컬 프록시 포트가 실제로 수신 대기 중인지 확인하고, 애플리케이션이 시스템 프록시를 읽는지 판단한 뒤 DNS, 라우팅 규칙과 터미널 환경 변수를 점검합니다. 이 과정을 마치면 문제가 클라이언트, 로컬 프록시 설정 또는 특정 애플리케이션 내부 중 어디에 있는지 파악할 수 있습니다.
먼저 시스템 프록시가 어떤 트래픽에 적용되는지 구분하기
“v2rayN이 실행 중”인 것과 “애플리케이션 트래픽이 프록시로 들어간 것”은 별개의 문제입니다. v2rayN은 Xray 코어를 실행한 뒤 로컬 루프백 주소에 SOCKS, HTTP 또는 혼합 인바운드 포트를 만들고, 시스템 프록시는 그중 하나를 운영체제 설정에 등록합니다. 이 설정을 실제로 읽는 애플리케이션만 요청을 로컬 포트로 전달합니다. 노드가 연결됨으로 표시되는 것은 클라이언트에 아웃바운드 조건이 갖춰졌다는 뜻일 뿐, 브라우저·터미널·다른 프로그램이 이를 사용한다는 의미는 아닙니다.
v2rayN 7.x의 일반적인 설정을 예로 들면 로컬 SOCKS 포트는 127.0.0.1:10808, HTTP 포트는 127.0.0.1:10809로 표시됩니다. 실제 포트는 「설정」→「매개변수 설정」의 로컬 수신 대기 설정을 기준으로 확인하세요. 시작 포트를 변경했다면 테스트 명령도 함께 수정해야 합니다. HTTP 요청을 SOCKS 포트로 보내거나 SOCKS 주소를 HTTP 주소로 입력하면 연결 실패로 나타납니다.
| 애플리케이션 유형 | 주로 읽는 설정 | 우선 확인할 위치 |
|---|---|---|
| Chromium 계열 브라우저 | 일반적으로 Windows 시스템 프록시를 따르지만 기업 정책이나 브라우저 확장의 영향을 받을 수 있음 | 시스템 「네트워크 및 인터넷」→「프록시」 |
| Firefox | 시스템 프록시를 사용하거나 별도의 프록시 설정을 저장할 수 있음 | 브라우저 「설정」→「네트워크 설정」 |
| PowerShell, curl, 패키지 관리자 | 도구 구현에 따라 환경 변수나 명령줄 인자를 읽으므로 시스템 설정을 자동으로 따른다고 가정하면 안 됨 | HTTP_PROXY, HTTPS_PROXY 및 도구 설정 |
| v2rayNG、v2flyNG | Android에서는 시스템 VPN 서비스를 통해 선택한 애플리케이션의 트래픽을 가로챔 | 애플리케이션 프록시 스위치, 앱별 설정 및 라우팅 규칙 |
결론: 먼저 애플리케이션이 로컬 포트에 도달했는지 확인하기
브라우저와 터미널의 결과가 다르다면 같은 노드를 반복해서 바꾸기보다 각자 사용하는 프록시 진입점을 먼저 확인하세요. 노드·구독·프로토콜 매개변수가 모두 같다면 애플리케이션이 프록시 설정을 읽는지가 가장 흔한 분기점입니다.
먼저 v2rayN 로컬 포트가 사용 가능한지 확인하기
브라우저를 점검하기 전에 클라이언트 포트가 수신 대기 중인지, 포트가 점유되었는지, 코어가 정상적으로 시작되었는지부터 확인해야 합니다. v2rayN에서 사용할 노드로 전환한 뒤 메인 화면이나 실행 로그에 시작 성공 메시지가 표시되는지 확인하고 현재 Core 유형도 점검하세요. VMess, VLESS 등의 노드 매개변수는 코어가 처리하며, 시스템 프록시는 서버 주소·포트·전송 계층·사용자 식별자 입력 오류를 수정해 주지 않습니다.
코어 시작 여부 확인
v2rayN 메인 화면에서 노드를 선택해 활성 서버로 지정하고 실행 로그를 여세요. 정상이라면 코어 시작 및 로컬 인바운드 수신 대기 정보가 표시됩니다. 창에 재시작이나 종료 메시지가 계속 나타난다면 먼저 로그의 설정 오류를 해결하세요.
수신 대기 포트 확인
「설정」→「매개변수 설정」으로 이동해 로컬 SOCKS 및 HTTP 포트를 기록하세요. 이 글의 예시는 SOCKS
10808, HTTP10809를 사용하므로 화면에 표시된 값과 다르면 그대로 적용하지 마세요.시스템 프록시 설정
v2rayN의 「시스템 프록시」 메뉴를 열고 시스템 프록시 자동 구성을 선택하세요. 이어서 Windows 「설정」→「네트워크 및 인터넷」→「프록시」로 이동해 주소가
127.0.0.1을 가리키고 포트가 클라이언트의 현재 HTTP 수신 대기 포트와 일치하는지 확인하세요.루프백 연결 테스트
PowerShell에서
Test-NetConnection 127.0.0.1 -Port 10809를 실행하세요. 결과의TcpTestSucceeded가True여야 합니다.False라면 문제는 아직 로컬 수신 대기 또는 포트 점유에 있습니다.명시적 프록시 테스트
curl.exe --proxy http://127.0.0.1:10809 -I https://example.com를 실행하세요. 정상적인 로컬 테스트에서는 루프백 연결 수립 시간이 보통 0.01초 미만이며, 원격 응답 시간은 노드 경로에 따라 달라집니다.
오류: curl: (7) Failed to connect to 127.0.0.1 port 10809
원인 및 해결: 지정한 포트에서 수신 대기 중인 프로그램이 없습니다. 코어가 시작되지 않았거나 HTTP 포트가 잘못 입력되었거나 다른 프로그램이 포트를 점유한 경우가 일반적입니다. 「설정」→「매개변수 설정」에서 포트를 확인하고 코어를 재시작한 뒤 다시 테스트하세요.
오류: failed to start app/proxyman/inbound: failed to listen TCP
원인 및 해결: 로컬 수신 대기 포트가 충돌했습니다. 해당 포트를 사용하는 프로그램을 종료하거나 매개변수 설정에서 사용하지 않는 포트로 변경하세요. 예를 들어 HTTP 포트를 10809에서 10909로 바꾼 뒤 시스템 프록시도 새 포트를 사용하도록 동기화합니다.
브라우저가 프록시를 사용하지 않을 때의 점검 순서
명시적 curl 프록시 요청은 성공했는데 브라우저가 여전히 직접 연결된다면 노드와 로컬 포트는 대체로 정상이며, 다음 단계는 브라우저의 프록시 설정 읽기 방식을 확인하는 것입니다. 오래된 프로세스가 연결 풀이나 시작 당시의 프록시 상태를 유지하지 않도록 브라우저를 완전히 종료한 뒤 다시 실행하세요. 탭 하나만 닫는 것으로는 모든 네트워크 프로세스가 재생성되지 않을 수 있습니다.
Chromium 계열 브라우저는 일반적으로 Windows 시스템 프록시를 사용하지만, 독립 프록시 확장 프로그램·관리 정책·시작 매개변수가 시스템 설정을 덮어쓸 수 있습니다. Firefox는 자체 네트워크 설정에서 “프록시 사용 안 함”, “시스템 프록시 설정 사용” 또는 “수동 프록시 설정”을 선택할 수 있습니다. Firefox에서만 실패한다면 「설정」→「일반」→「네트워크 설정」으로 이동해 시스템 프록시 사용을 선택하거나, v2rayN의 현재 포트에 맞춰 HTTP 및 SOCKS 주소를 입력하세요.
- 시스템 수동 프록시 주소가 이미 만료된 LAN 주소가 아니라
127.0.0.1인지 확인하세요. - 포트가 v2rayN의 현재 설정과 일치하는지 확인하세요. 특히 설정 디렉터리를 전환한 뒤 포트가 기본값으로 돌아갈 수 있다는 점에 유의합니다.
- 프록시 규칙을 변경하는 브라우저 확장 프로그램을 일시적으로 비활성화한 뒤 브라우저 프로세스 전체를 재시작해 테스트하세요.
- Windows 프록시 설정의 예외 목록을 확인하세요. 대상 도메인이 우회 목록에 있으면 직접 연결됩니다.
- 일반 창과 시크릿 창을 각각 테스트하세요. 결과가 다르면 확장 프로그램 권한이나 브라우저 프로필 설정이 서로 다를 가능성이 큽니다.
- 이미 캐시된 단일 페이지로 결과를 판단하지 말고 개발자 도구를 열어 새로운 HTTPS 요청을 테스트하세요.
오류: ERR_PROXY_CONNECTION_FAILED
원인 및 해결: 브라우저가 프록시 사용을 시도했지만 설정된 로컬 주소에 연결하지 못했습니다. Windows 시스템 프록시 포트와 v2rayN HTTP 수신 대기 포트를 확인하고 코어 프로세스가 계속 실행 중인지 점검하세요.
오류: ERR_TUNNEL_CONNECTION_FAILED
원인 및 해결: 브라우저는 HTTP 프록시에 연결했지만 HTTPS 터널을 만들지 못했습니다. 먼저 같은 포트로 명시적 curl 요청을 실행한 뒤, 실행 로그에서 노드 시간 초과·TLS 매개변수 오류·라우팅 차단 여부를 확인하세요.
오류: PR_CONNECT_RESET_ERROR
원인 및 해결: 연결 수립 중 연결이 재설정된 것입니다. 이 메시지만으로 시스템 프록시가 작동하지 않는다고 판단하지 마세요. Firefox를 시스템 프록시 사용으로 변경해 다시 시도하고, v2rayN 로그에서 요청이 코어로 들어갔는지 확인하세요.
왜 한 브라우저에서는 열리는데 다른 브라우저에서는 열리지 않나요?
먼저 두 브라우저가 프록시를 가져오는 위치를 비교하세요. 한쪽은 Windows 시스템 프록시를 따르고 다른 쪽은 수동 포트를 저장했을 수 있습니다. 독립 설정을 127.0.0.1과 현재 HTTP 포트로 변경한 뒤 두 브라우저를 완전히 종료하고 다시 테스트하세요.
확장 프로그램을 꺼도 직접 연결로 표시되면 어떻게 하나요?
브라우저 바로 가기에 프록시 시작 매개변수가 포함되어 있는지 확인하고 시스템 프록시 예외 목록도 점검하세요. 이후 명시적 curl 프록시 테스트를 실행합니다. 명시적 테스트는 성공하지만 브라우저만 실패한다면 브라우저 정책과 프로필 설정을 계속 확인해야 합니다.
시스템 프록시를 켠 뒤 로컬 네트워크 페이지가 열리지 않나요?
시스템 프록시 우회 목록에 로컬 주소를 유지하거나 v2rayN 라우팅 규칙에서 사설 주소를 직접 연결로 처리하세요. 일반적인 사설 네트워크 대역은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16입니다.
브라우저를 재시작하면 프록시가 다시 사라지나요?
v2rayN의 시스템 프록시 모드가 “시스템 프록시 변경 안 함”으로 설정되어 있는지, 클라이언트 종료 시 시스템 설정을 삭제하는지 확인하세요. 계속 사용하려면 클라이언트 시작 후 시스템 프록시 자동 구성을 다시 선택하세요.
명령줄 터미널은 별도로 프록시를 설정해야 합니다
명령줄 도구가 시스템 프록시를 자동으로 읽는다고 일괄적으로 볼 수는 없습니다. 같은 터미널에서도 curl, PowerShell 모듈, 런타임 패키지 관리자와 독립 다운로드 프로그램이 서로 다른 방식을 사용할 수 있습니다. 가장 확실한 방법은 먼저 단일 명령에 프록시 주소를 명시적으로 전달한 뒤, 필요할 때 현재 세션의 환경 변수를 설정하는 것입니다. 이렇게 하면 도구 설정 문제를 v2rayN 노드 장애로 잘못 판단하는 일을 피할 수 있습니다.
HTTP 프록시 주소에는 v2rayN의 HTTP 수신 대기 포트를 사용해야 합니다. 예: http://127.0.0.1:10809. SOCKS를 사용하려면 socks5h://127.0.0.1:10808로 입력할 수 있습니다. 여기서 socks5h는 프록시가 대상 도메인을 해석하도록 하므로 로컬 DNS 해석과 프록시 아웃바운드 결과의 불일치를 줄일 수 있습니다. 이 형식을 지원하는지는 각 명령의 프록시 옵션을 기준으로 확인하세요.
# PowerShell: 현재 창에서 이후 실행되는 프로그램에만 적용
$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:NO_PROXY="localhost,127.0.0.1"
# HTTP 프록시 명시적 테스트
curl.exe --proxy http://127.0.0.1:10809 -I https://example.com
# SOCKS 명시적 테스트 및 프록시 측 도메인 해석
curl.exe --proxy socks5h://127.0.0.1:10808 -I https://example.com:: Windows 명령 프롬프트: 현재 창에만 설정
set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809
set NO_PROXY=localhost,127.0.0.1
# macOS 또는 Linux 셸: 현재 세션에만 설정
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export NO_PROXY=localhost,127.0.0.1| 현상 | 판단 | 처리 방법 |
|---|---|---|
| 브라우저 성공, curl 직접 연결 | curl이 시스템 프록시를 사용하지 않음 | --proxy를 사용하거나 현재 세션 환경 변수 설정 |
| 명시적 HTTP 프록시는 성공하지만 환경 변수는 실패 | 변수 이름·범위 또는 도구의 읽기 규칙이 잘못됨 | 대문자 변수와 도구가 요구하는 변수를 함께 설정하고 해당 터미널 프로세스를 재시작 |
| HTTP 포트는 실패하지만 SOCKS 포트는 성공 | HTTP 인바운드 포트가 잘못되었거나 수신 대기 중이 아님 | 매개변수 설정을 확인하고 10808과 10809를 혼동하지 않기 |
| 로컬 주소도 프록시를 사용함 | 우회 설정이 없음 | NO_PROXY=localhost,127.0.0.1 설정 |
오류: curl: (5) Could not resolve proxy: 127.0.0.1:10809
원인 및 해결: 프록시 변수 형식이 잘못 입력되었을 수 있습니다. 예를 들어 주소와 프로토콜을 인식할 수 없는 값으로 나눠 입력한 경우입니다. 변수를 http://127.0.0.1:10809로 완전하게 작성하고 불필요한 따옴표와 공백을 제거한 뒤 터미널을 다시 여세요.
오류: curl: (97) connection to proxy closed
원인 및 해결: 프록시 프로토콜과 포트 유형이 맞지 않을 때 흔히 발생합니다. HTTP 주소는 HTTP 포트에, SOCKS 주소는 SOCKS 포트에 연결해야 합니다. 확인 후 두 개의 명시적 테스트 명령을 각각 실행하세요.
결론: 터미널 점검은 명시적 매개변수를 기준으로 하기
--proxy를 포함한 단일 명령이 성공했다면 로컬 포트와 노드 경로는 이미 정상적으로 작동한다는 뜻입니다. 이후에는 구독·프로토콜·라우팅 규칙을 계속 바꾸기보다 환경 변수나 특정 도구의 설정을 수정하세요.
포트는 정상인데도 접속할 수 없다면 DNS와 라우팅 확인
로컬 포트에 연결된다는 것은 애플리케이션이 프록시 진입점에 도달했다는 뜻일 뿐입니다. 요청은 Xray에 들어간 뒤 도메인 해석, 라우팅 매칭과 프록시 아웃바운드 과정을 거칩니다. 규칙이 대상 도메인을 직접 연결로 보내면 외부에서는 여전히 로컬 네트워크로 접속한 것처럼 보일 수 있고, 노드 서버의 도메인 해석에 실패하면 해당 노드를 통한 모든 요청이 시간 초과될 수 있습니다. 이때는 브라우저 오류 페이지만 보지 말고 문제를 재현하면서 실행 로그를 확인하세요.
테스트 범위를 노드 하나, 브라우저 하나, 명시적 curl 명령 하나로 줄이세요. 복잡한 사용자 지정 라우팅은 일시적으로 끄고 사설 주소만 직접 연결로 유지한 뒤 나머지 테스트 요청은 프록시 아웃바운드로 보내세요. 이렇게 해서 복구된다면 문제는 대개 규칙 순서·도메인 목록·아웃바운드 태그에 있습니다. 계속 실패한다면 구독의 서버 주소·포트·VMess 또는 VLESS 사용자 매개변수·TLS·전송 방식이 서버와 일치하는지 확인하세요.
- v2rayN 실행 로그에서 테스트 시각을 찾아 대상 도메인이나 대상 주소가 표시되는지 확인하세요.
- 요청은 보이지만 직접 연결로 표시된다면 라우팅 규칙이 매칭한 아웃바운드 태그와 규칙 우선순위를 확인하세요.
timeout이 표시되면 노드 서버 연결 시간 초과와 최종 대상 연결 시간 초과를 구분하세요.- 도메인 해석 실패가 표시되면 노드 서버 주소의 철자를 확인하고 사용 가능한 DNS로 변경한 뒤 코어를 재시작하세요.
- 요청이 전혀 보이지 않는다면 애플리케이션 프록시 설정으로 돌아가 계속 점검하세요. 먼저 노드 프로토콜 매개변수를 변경하지 마세요.
오류: failed to find an available destination
원인 및 해결: 코어가 사용 가능한 대상 주소를 얻지 못했습니다. 도메인 해석 실패 또는 사용할 수 없는 라우팅 결과가 원인일 수 있습니다. 노드 서버 주소의 철자, DNS 설정과 라우팅 아웃바운드 태그를 확인한 뒤 코어를 재시작하세요.
오류: dial tcp: i/o timeout
원인 및 해결: 노드 서버 또는 최종 대상과의 TCP 연결이 제한 시간을 초과했습니다. 먼저 같은 구독의 다른 노드로 바꿔 비교한 뒤 서버 포트, 로컬 시간과 해당 연결을 허용하는 네트워크인지 확인하세요.
오류: invalid user
원인 및 해결: 서버가 노드 인증 매개변수를 승인하지 않았습니다. 구독 정보가 만료되었거나 수동 편집 중 사용자 식별자를 잘못 입력한 경우가 흔합니다. 이는 시스템 프록시 스위치와 무관하므로 해당 구독 그룹을 업데이트하고 노드를 다시 선택하세요.
결과에 따라 해결 방법 선택
점검이 끝났다고 모든 설정을 동시에 바꿀 필요는 없습니다. 가장 효율적인 방법은 정상 작동이 확인된 노드 하나를 유지하고 테스트 결과에 따라 다음 단계를 정하는 것입니다. 루프백 포트가 실패하면 코어와 포트를 처리하고, 명시적 프록시는 성공하지만 브라우저가 실패하면 브라우저의 프록시 출처를 확인합니다. 브라우저는 성공하지만 터미널이 실패하면 명령줄 인자와 환경 변수를 점검하세요. 모든 애플리케이션 요청이 로그에 들어오지만 아웃바운드가 실패할 때만 DNS·라우팅·노드 설정을 확인하면 됩니다.
포트를 바꿨는데도 시스템 프록시에 예전 숫자가 남아 있나요?
먼저 v2rayN의 「시스템 프록시」 메뉴에서 시스템 프록시를 지운 뒤 자동 구성을 다시 선택하세요. 이후 Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 새 포트가 입력되었는지 확인합니다.
v2rayN을 종료한 뒤 브라우저가 모두 열리지 않나요?
시스템에 로컬 포트를 가리키는 프록시 설정이 남아 있지만 클라이언트는 이미 수신 대기를 중지했을 수 있습니다. 클라이언트를 다시 시작하거나 시스템 프록시 메뉴에서 삭제를 실행한 뒤 Windows 수동 프록시가 꺼져 있는지 확인하세요.
터미널의 특정 도구 하나만 작동하지 않나요?
먼저 해당 도구가 HTTP_PROXY, HTTPS_PROXY 또는 독립 프록시 매개변수를 지원하는지 확인하세요. curl의 명시적 프록시가 성공했다면 문제는 해당 도구의 자체 설정으로 좁혀진 것이므로 v2rayN을 다시 설치할 필요가 없습니다.
구독을 업데이트한 뒤 갑자기 모두 시간 초과되나요?
해당 구독 그룹을 수동으로 업데이트하고 노드를 다시 선택한 뒤 실행 로그를 확인하세요. 로컬 포트에는 계속 연결되지만 여러 노드가 동시에 시간 초과된다면 구독 매개변수·시스템 시간·현재 네트워크 환경을 비교하세요.
Android에서도 127.0.0.1 포트를 설정해야 하나요?
일반적으로 데스크톱 시스템의 프록시 설정 절차를 그대로 적용할 필요는 없습니다. v2rayNG와 v2flyNG는 Android VPN 서비스를 통해 트래픽을 가로채므로 애플리케이션 연결 상태·앱별 프록시·라우팅 모드·실행 로그를 확인하세요.
최종 판단: 세 번의 테스트로 장애 계층 좁히기
로컬 포트 테스트, 명시적 프록시 요청, 애플리케이션 내 접속 순서로 실행하세요. 앞 단계가 실패하면 해당 계층에서 멈춰 수정하고, 앞의 두 단계는 성공했지만 세 번째 단계만 실패하면 특정 애플리케이션만 확인합니다. 이 순서를 따르면 포트 오류가 있을 때 라우팅을 반복해서 바꾸거나, 터미널에 프록시를 설정하지 않은 상태에서 정상 노드를 잘못 삭제하는 일을 피할 수 있습니다.