v2rayN 첫 연결 설정 가이드: 노드 선택, 실제 연결 지연 테스트와 프록시 확인

이 글의 핵심 내용

구독 목록에 노드가 표시된다고 해서 프록시가 작동하는 것은 아닙니다. 구독을 막 가져온 데스크톱 사용자를 위해 실제 연결 테스트 → 활성 서버 지정 → 시스템 프록시 켜기 → 출구 주소와 로그 확인 순서로 첫 연결을 점검합니다. Windows용 v2rayN을 기준으로 노드 연결 가능 여부, 앱의 프록시 사용 여부, 라우팅 규칙 적용 여부를 각각 확인합니다.

1. 연결 전에 로컬 포트와 테스트 범위 확인

v2rayN은 클라이언트 인터페이스이며, 실제 연결은 실행 중인 프록시 코어가 처리합니다. 구독에는 노드 주소와 프로토콜, 인증 정보가 포함됩니다. 시스템 프록시는 일부 앱이 요청을 로컬 프록시로 보내도록 설정하고, 라우팅 규칙은 요청을 직접 연결할지 원격 노드를 경유할지 결정합니다. 이 중 하나라도 잘못 설정되면 노드를 선택했는데도 웹페이지가 열리지 않을 수 있습니다.

처음 문제를 점검할 때는 TUN 모드를 끄고 시스템 프록시를 변경하는 다른 프로그램도 종료하세요. 가상 네트워크 어댑터가 트래픽을 가로채 포트나 브라우저 설정 문제를 가리는 상황을 피하고 시스템 프록시 경로만 확인할 수 있습니다. 아래 숫자는 테스트를 위한 구체적인 값이며, 측정 결과나 모든 설치 환경의 기본값을 뜻하지 않습니다.

127.0.0.1

로컬 루프백 주소

10808

이 문서에서 사용하는 로컬 프록시 포트

15초

명령줄 단일 요청의 최대 대기 시간

「설정」→「매개변수 설정」으로 이동해 인바운드 관련 로컬 리스닝 포트를 확인한 다음, 메인 화면 하단에 표시된 HTTP, SOCKS 또는 혼합 포트와 대조하세요. 버전에 따라 설정 메뉴 이름이 다를 수 있으므로 실제 표시되는 포트 유형을 기준으로 확인하면 됩니다. HTTP와 SOCKS가 서로 다른 포트를 사용한다면 아래 명령에도 각각 올바른 포트를 입력해야 합니다. 같은 숫자를 모든 곳에 그대로 복사하지 마세요.

2. 실제 연결 테스트로 노드를 고른 뒤 활성 서버로 지정

실제 연결 지연 테스트는 지정한 노드를 통해 테스트 주소에 요청을 보내므로 서버의 TCP 포트만 확인하는 것보다 실제 사용 환경에 가깝습니다. 다만 해당 노드에서 테스트 주소까지의 경로만 확인할 뿐, 모든 웹사이트와 프로토콜 또는 지속적인 다운로드가 정상이라는 뜻은 아닙니다. 테스트 전후에 DNS, 라우팅, 전송 설정을 동시에 바꾸면 어떤 변경이 영향을 주었는지 파악하기 어렵습니다.

노드 확인

메인 화면에서 방금 가져온 구독 그룹을 열고 노드 이름, 주소, 프로토콜이 제대로 표시되는지 확인하세요. 트래픽 안내나 만료 알림만 표시된 항목은 연결 가능한 노드로 취급하지 마세요.
여러 노드 테스트

후보 노드를 몇 개 선택한 뒤 마우스 오른쪽 버튼을 눌러 테스트 메뉴를 열고 「서버 실제 연결 지연 테스트」를 선택하세요. 일부 버전은 메뉴에 ‘다중 선택’ 안내가 붙어 있습니다. TCP 지연만 테스트하는 항목이 아니라 ‘실제 연결’이 포함된 항목을 선택하세요.
후보 노드 재테스트

실제 연결 지연 열에서 성공적으로 응답한 노드를 확인하고 후보로 남겨 두세요. 후보 노드는 다시 두 번 테스트해 반복적으로 시간 초과가 발생하는지 살펴보세요. 한 번 측정한 최저값만으로 장기적인 안정성을 판단하지 마세요.
활성 서버로 지정

대상 노드를 마우스 오른쪽 버튼으로 클릭해 「활성 서버로 설정」을 선택한 다음, 메인 화면에 표시된 현재 서버 정보를 확인하세요. 노드를 테스트했더라도 실제 사용 노드로 자동 지정되는 것은 아닙니다.
코어 실행 상태 확인

하단 로그에서 코어가 바로 종료되지 않았는지 확인하세요. 리스닝 포트 충돌, 설정 파싱 실패 또는 지원하지 않는 프로토콜 필드가 표시되면 먼저 실행 문제를 해결한 뒤 브라우저를 테스트하세요.

3. 시스템 프록시와 전역 라우팅은 별도로 설정

Windows 버전에서는 메인 화면 하단이나 트레이 아이콘의 마우스 오른쪽 버튼 메뉴에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택할 수 있습니다. 그런 다음 Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 주소와 포트가 v2rayN의 로컬 HTTP 포트를 가리키는지 확인하세요. 여기에 원격 노드 주소를 입력하면 안 됩니다. 시스템 프록시는 이 PC에서 수신 대기 중인 로컬 포트에 연결합니다.

시스템 프록시와 라우팅은 같은 설정이 아닙니다. 시스템 프록시는 앱이 요청을 로컬 프록시에 전달할지 결정하고, 라우팅은 코어에 들어온 요청을 어떻게 전달할지 결정합니다. 처음 연결을 확인할 때는 직결 규칙의 영향을 줄이도록 잠시 ‘전역’ 라우팅을 사용할 수 있습니다. 확인을 마친 뒤에는 평소 사용하는 분할 라우팅으로 되돌리세요.

시스템 프록시 + 임시 전역 라우팅

권장

「시스템 프록시」에서 자동 설정을 켜고 「라우팅」에서 전역 프록시에 해당하는 프리셋을 선택하세요. 두 설정을 함께 적용하면 브라우저 요청이 현재 노드를 경유하는지 확인하기 쉽습니다.

추천 상황: 첫 연결 확인, 분할 라우팅 규칙의 영향 배제

시스템 프록시 + 평소 사용하는 분할 라우팅

앱은 로컬 포트에 연결되지만, 코어는 도메인과 주소 등의 규칙에 따라 직접 연결하거나 프록시를 사용합니다. 출구 주소 확인 사이트도 규칙에 따라 직접 연결될 수 있습니다.

추천 상황: 연결 확인을 마친 뒤 평소에 사용할 때

활성 서버만 지정

코어에서 사용할 수 있는 원격 출구를 선택한 상태지만, 프록시를 설정하지 않은 앱은 대개 기존 네트워크 경로로 접속합니다. 상태 표시줄에 노드 이름이 보인다는 사실만으로 브라우저가 프록시에 연결되었다고 볼 수는 없습니다.

추천 상황: 앱에서 프록시를 직접 설정하거나 명령줄 테스트를 별도로 실행할 때

여기서 ‘전역’은 코어의 라우팅 범위를 뜻하며, 컴퓨터의 모든 트래픽이 자동으로 프록시를 통과한다는 뜻은 아닙니다. 시스템 프록시를 따르지 않는 앱, 별도로 프록시를 설정한 브라우저 확장 프로그램, 일부 UDP 요청은 각각 확인해야 합니다. 이 문서의 브라우저 테스트는 주로 시스템 프록시를 따르는 HTTP 및 HTTPS 요청을 대상으로 합니다.

4. 브라우저 확인: 출구 주소 비교와 접속 로그 점검

신뢰할 수 있는 출구 주소 확인 서비스를 하나 선택하고 전후 비교에 같은 서비스를 사용하세요. 예를 들어 브라우저 주소창에 https://api.ipify.org를 입력하면 해당 요청에 표시되는 공인 IP 주소를 확인할 수 있습니다. 이런 서비스는 방문자의 출구 주소를 확인할 수 있으므로 구독 링크나 인증 정보가 포함된 화면을 제삼자에게 보내지 마세요.

직접 연결 기준값 기록: 시스템 프록시를 잠시 해제하고 TUN이 꺼져 있으며 다른 프로그램이 트래픽을 가로채지 않는 상태에서 페이지를 새로고침한 뒤 표시된 주소를 기록하세요.
프록시 연결 결과 기록: 「시스템 프록시 자동 설정」을 다시 켜고 같은 활성 노드를 유지한 채 임시로 전역 라우팅을 사용한 다음, 같은 주소를 다시 여세요.
로그의 연결 경로 확인: 현재 로그 수준에서 접속 기록을 제공한다면 대상 도메인의 요청을 찾아 출구가 직결이 아닌 프록시를 가리키는지 확인하세요. 코어마다 출구 표기가 다를 수 있으므로 실제 설정과 함께 판단해야 합니다.
브라우저의 별도 설정 확인: 프록시 관리 확장 프로그램과 브라우저 자체의 프록시 설정을 확인하세요. 시크릿 창은 캐시의 영향을 줄일 수 있지만 확장 프로그램이나 프록시 설정까지 반드시 비활성화되는 것은 아닙니다.

출구 주소가 다르면 두 요청이 서로 다른 출구를 거쳤다는 강한 근거가 됩니다. 주소가 같더라도 분할 라우팅 규칙과 앱의 프록시 연결 여부를 더 확인해야 하며, 노드가 실패했다고 바로 판단하면 안 됩니다. 두 요청이 각각 IPv4와 IPv6를 사용했는지도 확인하세요. 주소 체계가 다른 결과는 직접 비교하기 어렵습니다. 브라우저 캐시에 이전 결과가 남아 있을 수 있으니 필요하면 강력 새로고침한 뒤 다시 시도하세요.

5. 명령줄 확인: 프록시 요청과 직접 연결 비교

명령줄 도구가 Windows 시스템 프록시를 읽는다고 보장할 수 없습니다. 프록시 주소를 명령에 명시하면 앱이 시스템 설정을 읽는지 여부와 관계없이 로컬 포트에서 원격 출구까지의 연결을 직접 테스트할 수 있습니다. Windows PowerShell에서는 curl.exe를 사용하세요. 구버전 환경에서 curl 별칭으로 인해 매개변수가 다르게 해석되는 문제를 피할 수 있습니다.

HTTP 프록시 포트

프록시 주소: 127.0.0.1
예시 포트: 10808
명령 매개변수: --proxy http://127.0.0.1:10808
필수 조건: 해당 포트가 HTTP 프록시 또는 혼합 인바운드를 지원해야 합니다

HTTPS 대상은 HTTP CONNECT로 터널을 만듭니다. 로컬 포트에 http를 지정해도 대상 연결의 TLS가 해제되는 것은 아닙니다.

SOCKS 프록시 포트

프록시 주소: 127.0.0.1
예시 포트: 10808
명령 매개변수: --proxy socks5h://127.0.0.1:10808
필수 조건: 해당 포트가 SOCKS 또는 혼합 인바운드를 지원해야 합니다

socks5h는 대상 도메인 조회를 프록시에 맡기므로 curl이 PC에서 대상 도메인을 먼저 조회하지 않습니다.

포트를 확인한 다음 아래 명령을 하나씩 실행하세요. 첫 번째 명령은 프록시를 사용하지 않도록 지정하고 프록시 환경 변수도 무시합니다. 나머지 두 명령은 HTTP와 SOCKS 포트를 각각 테스트합니다. 혼합 인바운드가 아니라면 각 명령의 포트를 실제 값으로 바꾸세요. 아래 명령에는 실제 측정 결과가 포함되어 있지 않습니다. 반환 주소와 소요 시간은 해당 PC의 실행 결과를 기준으로 확인하세요.

# 직접 연결 기준값: TUN과 다른 투명 프록시가 꺼진 상태에서 실행
curl.exe -4 --noproxy "*" --connect-timeout 5 --max-time 15 https://api.ipify.org

# HTTP 프록시: NO_PROXY 우회 목록을 비우고 지정한 포트를 사용
curl.exe -4 --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://api.ipify.org

# SOCKS 프록시: 대상 도메인 조회를 프록시에 맡김
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 https://api.ipify.org

앞의 두 명령은 -4를 사용해 직접 연결과 로컬 연결에서 주소 체계가 달라질 가능성을 줄입니다. SOCKS 원격 조회를 사용하는 경우 최종 대상의 주소 체계는 프록시 측의 조회와 라우팅에 따라 달라집니다. 서로 다른 주소 체계의 결과가 나오면 로그를 함께 확인하고 문자열이 같은지만 비교하지 마세요.

결과	우선 확인할 항목	다음 조치
로컬 포트 연결이 거부됨	코어가 실행되지 않았거나 포트가 잘못 입력됨	상태 표시줄의 포트를 확인하고 리스닝 실패 로그를 살펴보세요.
로컬 포트에는 연결되지만 요청 시간 초과	원격 연결, 대상 주소 접속 가능 여부 또는 DNS	실제 연결 테스트를 통과한 다른 노드로 바꾸고 나머지 조건은 그대로 유지하세요.
명령줄은 성공하지만 브라우저는 실패	시스템 프록시 또는 브라우저의 별도 프록시 설정	시스템 프록시를 다시 자동 설정하고 프록시 관리 확장 프로그램을 잠시 비활성화하세요.
프록시 명령과 직접 연결의 출구 주소가 같음	코어 라우팅이 직접 연결을 선택함	잠시 전역 프록시 라우팅으로 전환한 뒤 출구 기록을 확인하세요.

6. 첫 연결 시 자주 묻는 질문

실제 연결 테스트는 성공했는데 웹사이트가 열리지 않는 이유는 무엇인가요?

지연 테스트는 특정 테스트 주소를 사용합니다. 브라우저가 로컬 프록시에 연결되지 않았거나 대상 웹사이트에 별도의 연결 문제가 있을 수 있습니다. 먼저 「활성 서버로 설정」이 되어 있는지 확인한 다음 「시스템 프록시」→「시스템 프록시 자동 설정」을 점검하세요. 마지막으로 명시적 프록시 명령으로 같은 대상에 요청해 문제 범위를 좁히세요.

지연이 가장 낮은 노드가 가장 빠른 노드인가요?

그렇지 않습니다. 실제 연결 지연은 테스트 요청이 완료되는 데 걸린 시간이지 다운로드 대역폭이 아닙니다. 먼저 테스트를 연속으로 통과하는 노드를 선택한 다음, 실제 사용할 웹사이트에 같은 시간대에 접속해 보세요. 여러 노드의 다운로드 속도를 측정하면 구독 트래픽이 소모될 수 있으므로 클라이언트를 실행할 때마다 반드시 할 필요는 없습니다.

로그에 address already in use가 표시되면 어떻게 하나요?

대개 다른 프로세스가 로컬 리스닝 포트를 사용 중이라는 뜻입니다. 클라이언트가 중복 실행 중인지 먼저 확인하세요. 포트를 변경해야 한다면 「설정」→「매개변수 설정」에서 인바운드 포트를 수정하고 저장한 뒤 관련 서비스를 다시 시작하세요. 이후 시스템 프록시를 다시 설정하고 명령줄의 포트도 함께 변경해야 합니다.

VLESS 노드로 바꾼 뒤 프로토콜 필드를 다시 입력해야 하나요?

정상적인 구독에는 대개 서버에서 요구하는 필드가 이미 포함되어 있습니다. 전송, TLS, REALITY 또는 flow 매개변수를 임의로 변경하지 마세요. 지원하지 않는 필드 오류가 발생하면 현재 코어가 해당 조합을 지원하는지 확인한 뒤 구독 제공자에게 매개변수를 문의하세요. 필드를 수정해도 서버와 설정이 맞지 않는 문제는 해결되지 않습니다.

클라이언트를 종료한 뒤 웹페이지가 열리지 않을 때는 어떻게 복구하나요?

먼저 v2rayN을 다시 실행한 다음 「시스템 프록시」 메뉴에서 「시스템 프록시 지우기」를 선택하세요. 클라이언트를 실행할 수 없다면 Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 남아 있는 수동 프록시를 끄고 네트워크를 가로채는 다른 프록시 프로그램이 있는지도 확인하세요.

7. 확인을 마친 뒤 평소 사용하는 분할 라우팅으로 복원

첫 연결이 정상이라는 판단은 상태 표시줄에 노드 이름이 보이는 것만으로 충분하지 않습니다. 로컬 포트에 연결할 수 있고, 명시적 프록시 요청이 성공하며, 브라우저 프록시 설정이 올바르고, 대상 요청이 예상한 출구를 거치는지 확인해야 합니다. 이 기준을 기록해 두면 반복해서 지연 테스트를 실행하는 것보다 이후 문제 해결에 도움이 됩니다.

재테스트를 마친 활성 노드 하나와 해당 구독 그룹을 기록해 두세요. 구독 업데이트 후 안내용 항목을 잘못 선택하는 일을 줄일 수 있습니다.
임시 전역 라우팅을 평소 사용하는 분할 라우팅으로 되돌린 뒤 자주 쓰는 사이트를 확인하세요. 일부 사이트가 직접 연결로 바뀌는 것은 규칙에 따른 정상 동작일 수 있습니다.
실제 HTTP 및 SOCKS 포트를 기록하고 원격 서버 포트와 로컬 리스닝 포트를 혼동하지 마세요.
도움을 요청할 때는 클라이언트 버전, 코어 유형, 발생 시각과 민감 정보를 가린 오류 내용을 제공하세요. 구독 주소, 인증 식별자, 연결 자격 증명은 공개하지 마세요.