v2rayN에 구독을 가져왔지만 아직 첫 연결을 완료하지 않은 사용자를 위한 글입니다. 먼저 노드 정보와 코어 유형을 확인하고, 실제 연결 지연을 측정한 다음 시스템 프록시를 켭니다. 이후 코어 로그, 브라우저의 외부 IP 주소, 명시적 프록시 명령으로 결과를 검증합니다.
연결 전에 노드와 로컬 설정 확인
핵심 포인트
구독 업데이트가 성공했다는 것은 클라이언트가 서버 설정을 받았다는 뜻일 뿐, 노드 연결이 완료됐다는 의미는 아닙니다. 노드 목록의 주소, 포트, 프로토콜, 전송 방식, TLS 설정은 하나의 구성으로 사용해야 합니다. VLESS와 VMess 같은 프로토콜 이름은 설정의 일부일 뿐이므로, 한 노드의 주소와 다른 노드의 포트를 조합하지 마세요. 첫 연결 전에 UUID, 플로우 제어, SNI 또는 전송 경로를 임의로 변경하는 것도 피해야 합니다.
핵심 포인트
이 글은 v2rayN 7.12.5 데스크톱 화면을 메뉴 기준으로 설명합니다. 세부 버전에 따라 메뉴 문구가 조금 다를 수 있지만 핵심 경로는 같습니다. 먼저 구독 그룹을 선택해 구독을 업데이트한 뒤 Core 유형과 로컬 수신 포트를 확인합니다. VLESS와 Reality 설정은 일반적으로 Xray를 선택하며, 기존 VMess 및 WebSocket 노드도 Xray에서 읽을 수 있습니다.
구독 업데이트
메인 화면에서 「구독 그룹」을 열고 현재 그룹을 선택한 뒤 「현재 구독 업데이트」를 실행합니다. 서버 목록에 노드가 표시되는지 확인하고 업데이트 시간이 오래된 기록이 아닌지도 살펴보세요.
코어 선택
「설정」→「매개변수 설정」→「Core 유형」으로 이동해 일반적인 VLESS 및 VMess 노드에는 Xray를 선택합니다. 저장 후 메인 화면으로 돌아와 호환되지 않는 코어가 설정을 처리하지 않도록 합니다.
포트 확인
「설정」→「매개변수 설정」에서 로컬 SOCKS 수신 포트를 확인합니다. 이 글의 명령은 10808을 기준으로 작성했으므로 화면에 다른 값이 표시되면 이후 명령도 같은 값으로 바꿔야 합니다.
시간 동기화
시스템이 날짜, 시간, 시간대를 자동으로 동기화하도록 설정하세요. 시간 차이가 크면 인증서 유효 기간을 잘못 판단해 TLS 핸드셰이크가 실패할 수 있습니다.
기존 프록시 정리
같은 포트를 계속 사용 중인 기존 클라이언트를 종료한 뒤 v2rayN을 시작하세요. 하나의 포트는 두 프로세스가 동시에 사용할 수 없습니다. 로그에 address already in use가 표시되면 특히 이 항목을 확인해야 합니다.
실제 연결 지연으로 첫 노드 선택
핵심 포인트
노드 이름에 표시된 지역과 배율만으로 사용 가능 여부를 판단할 수는 없습니다. 첫 연결에서 가장 유용한 지표는 실제 연결 지연입니다. 클라이언트가 로컬 프록시 코어를 통해 실제 요청을 보내므로 프로토콜 인증, 전송 계층 연결, TLS 핸드셰이크를 모두 거칩니다. 일반 네트워크 계층 지연보다 웹페이지를 열 때의 체감에 가깝습니다.
핵심 포인트
서버 목록에서 같은 구독의 후보 노드를 선택하고 마우스 오른쪽 버튼으로 「서버 테스트」를 연 다음 「실제 연결 지연」을 실행합니다. 첫 번째 라운드에서는 3~8개만 골라도 충분하며 수백 개를 동시에 테스트할 필요는 없습니다. 결과가 186ms, 242ms, 611ms, 시간 초과로 나왔다면 앞의 두 노드를 우선 시도하세요. 500ms를 넘는 노드도 연결될 수 있지만 첫 화면 응답은 대체로 더 느립니다.
일반 지연
내 컴퓨터와 대상 주소 사이의 기본 네트워크 왕복 시간을 주로 측정합니다. 결과는 빠르지만 프록시 프로토콜과 암호화 핸드셰이크까지 완료된다는 보장은 없습니다.
적합한 용도: 명백히 연결할 수 없는 주소 빠르게 제외
실제 연결 지연
권장프록시 코어를 통해 실제 연결을 완료하므로 브라우저 접속 경로에 더 가깝습니다. 첫 노드를 고를 때 가장 참고 가치가 높은 지표입니다.
적합한 용도: 첫 연결 노드 선택, 일상적인 노드 전환
다운로드 속도 테스트
데이터를 계속 전송해 처리량을 확인합니다. 테스트 주소, 회선 혼잡, 로컬 대역폭, 노드 속도 제한의 영향을 함께 받습니다.
적합한 용도: 사용 가능한 노드 사이에서 대용량 파일 속도 비교
| 실제 연결 결과 | 첫 연결 판단 | 다음 단계 |
|---|---|---|
| 80～300 ms | 첫 번째 후보로 적합 | 활성 서버로 지정하고 프록시 시작 |
| 300～500 ms | 연결은 되지만 응답이 느릴 수 있음 | 같은 지역의 다른 노드와 비교 |
| 500ms 초과 | 높은 지연 또는 회선 혼잡 | 예비로 남겨 두고 노드 우선 교체 |
| 시간 초과 또는 -1 | 테스트 요청이 완료되지 않음 | 로그를 확인하고 한 번의 결과만으로 삭제하지 않기 |
핵심 포인트
한 번의 시간 초과만으로 설정이 잘못됐다고 단정할 수는 없습니다. 테스트 대상이 일시적으로 연결되지 않았거나 DNS 조회에 문제가 있거나, 노드가 테스트 주소를 제한하거나, 코어가 막 시작된 경우에도 실패할 수 있습니다. 10초 간격으로 한 번 더 시도하고 로그에서 timeout, connection refused, TLS 오류, DNS 오류 중 무엇인지 확인하세요. 목록의 빨간 숫자 하나보다 구체적인 오류 유형이 진단에 더 유용합니다.
노드와 시스템 프록시 시작
핵심 포인트
실제 연결 지연 테스트가 끝나면 후보 노드를 더블클릭하거나 오른쪽 클릭 메뉴에서 활성 서버로 지정합니다. 메인 화면에서는 보통 선택 상태로 현재 노드를 표시합니다. 그다음 시스템 트레이의 v2rayN 메뉴에서 시스템 프록시 모드를 선택하세요. 첫 검증에서는 대상 요청을 확실히 포함하는 모드를 먼저 사용하는 것이 좋습니다. 규칙 분할로 테스트 사이트가 직결 처리되어 ‘노드는 시작됐지만 외부 IP가 바뀌지 않았다’고 잘못 판단하는 일을 피할 수 있습니다.
핵심 포인트
코어 시작과 시스템 프록시는 서로 다른 두 상태입니다. 코어가 시작되면 127.0.0.1:10808 같은 로컬 포트가 프록시 요청을 받기 시작합니다. 시스템 프록시를 켜야 시스템 설정을 따르는 브라우저와 앱이 자동으로 해당 포트로 트래픽을 전달합니다. 첫 단계만 완료한 경우 명령줄에서 프록시를 명시하면 성공할 수 있지만 브라우저는 여전히 직접 연결될 수 있습니다.
활성 서버로 지정
실제 연결 지연이 낮은 노드를 더블클릭해 현재 활성 서버가 되었는지 확인합니다. 행이 선택된 상태에만 머물러서는 안 되며, 활성 서버가 실제로 전환되어야 합니다.
코어 시작
메인 창 하단의 상태와 로그 패널을 확인합니다. 정상적으로 시작되면 로컬 포트 수신을 알리는 내용이 표시되어야 하며, 시작 실패나 포트 점유 오류가 연속해서 나타나서는 안 됩니다.
프록시 활성화
트레이 메뉴를 열고 시스템 프록시 모드를 선택합니다. 첫 검증 중에는 브라우저에 별도로 설정된 기존 프록시를 먼저 해제해 요청이 다른 포트로 전달되지 않도록 하세요.
연결 새로 고침
브라우저를 완전히 종료한 뒤 다시 열거나 새 시크릿 창을 만드세요. 오래 실행된 일부 프로그램은 기존 연결을 재사용하므로 페이지를 단순히 새로 고치는 것만으로는 새 프록시가 즉시 적용되지 않을 수 있습니다.
프록시 적용 여부를 확인하는 세 단계
핵심 포인트
상태 표시줄에 ‘실행 중’이라고 나오는 것은 코어 프로세스가 시작됐다는 뜻일 뿐, 대상 트래픽이 노드를 통과했다는 증거는 아닙니다. 신뢰할 수 있는 검증은 로컬 진입점, 프록시 출구, 앱의 실제 요청을 모두 확인해야 합니다. 아래 세 단계에서 로그, 브라우저, 명령줄을 교차 확인하면 ‘코어가 시작되지 않음’, ‘시스템 프록시가 트래픽을 넘겨받지 않음’, ‘라우팅 규칙 때문에 요청이 직결됨’을 구분할 수 있습니다.
코어 로그 확인
v2rayN 로그 패널을 연 뒤 새 웹페이지를 방문합니다. 새로운 연결 기록이 보여야 하며 요청이 프록시 아웃바운드로 들어갔는지 확인할 수 있어야 합니다. timeout, failed to dial, TLS handshake error가 계속 표시되어서는 안 됩니다.
브라우저 외부 IP 비교
시스템 프록시를 끈 상태에서 공인 외부 IP 주소를 한 번 기록한 뒤, 프록시를 켜고 새 창에서 다시 조회합니다. 테스트 도메인이 규칙에 따라 프록시를 통과한다면 외부 IP와 통신사 정보가 달라져야 합니다.
명시적 프록시 실행
명령줄에서 127.0.0.1:10808을 직접 지정해 시스템 프록시 설정을 우회한 요청을 보냅니다. 명령은 성공하지만 브라우저가 그대로라면 시스템 프록시 적용 여부와 브라우저 자체 네트워크 설정을 우선 확인하세요.
핵심 포인트
Windows에서는 PowerShell의 이전 환경에서 명령 별칭이 인자 해석에 영향을 주는 것을 피하기 위해 PowerShell 또는 명령 프롬프트에서 curl.exe를 사용할 수 있습니다. macOS와 Linux 터미널에서는 보통 curl을 그대로 사용합니다. 아래 명령은 DNS 조회도 SOCKS 프록시를 통과시킵니다. socks5h 끝의 h는 대상 도메인 조회를 프록시 측에서 수행한다는 뜻입니다.
curl.exe --proxy socks5h://127.0.0.1:10808 https://api.ipify.org
curl --proxy socks5h://127.0.0.1:10808 https://api.ipify.org핵심 포인트
명령이 공인 주소를 반환하면 로컬 SOCKS 진입점이 요청을 받고 응답을 가져왔다는 의미입니다. 이어서 --proxy 없이 같은 요청을 실행해 비교하세요. 두 결과가 다르면 일반적으로 명시적 프록시 경로가 정상적으로 구성된 것입니다. 결과가 같다면 노드 출구, 라우팅 규칙, 로그를 함께 확인해야 하며 주소 문자열만으로 결론을 내려서는 안 됩니다.
curl.exe https://api.ipify.org
curl https://api.ipify.org핵심 포인트
분할 라우팅 규칙을 사용하는 경우 공인 IP 확인 도메인이 직결로 처리될 수 있습니다. 이때는 로그의 아웃바운드 태그를 확인하는 편이 정확합니다. 요청이 direct 또는 freedom이 아니라 프록시 아웃바운드에 매칭되어야 합니다. 프록시로 지정된 테스트 도메인을 다시 요청한 뒤 로그에서 도메인, 대상 포트 443, 아웃바운드 태그가 서로 일치하는지도 확인하세요.
첫 연결 실패 빠른 점검
핵심 포인트
문제를 확인할 때 노드, 코어, 포트, 라우팅, DNS를 동시에 변경하지 마세요. 한 번에 변수 하나만 바꾸고, 변경할 때마다 코어를 다시 시작한 뒤 재테스트합니다. 가장 짧은 순서는 로컬 포트가 수신 중인지 확인하고, 노드가 원격 핸드셰이크를 완료하는지 확인한 다음, 시스템 프록시와 분할 라우팅을 점검하는 것입니다.
실제 연결 지연이 모두 시간 초과로 표시되면 어떻게 하나요?
먼저 구독 업데이트 시간과 시스템 시간을 확인한 다음 「설정」→「매개변수 설정」→「Core 유형」에서 코어를 점검합니다. 코어를 다시 시작한 뒤 노드 하나만 테스트하고, 로그에서 DNS 실패, 연결 거부, 핸드셰이크 시간 초과를 구분하세요.
로그에 포트가 이미 사용 중이라고 표시되면 어떻게 하나요?
다른 프록시 클라이언트와 기존 v2rayN 프로세스를 종료한 뒤 10808이 여전히 사용 중인지 확인합니다. 매개변수 설정에서 사용하지 않는 포트(예: 10818)로 변경할 수도 있습니다. 저장하고 재시작한 다음 명령줄 인자도 같은 포트로 바꾸세요.
명령줄은 성공하지만 브라우저 외부 IP가 그대로라면?
명시적 프록시가 성공했다면 노드와 로컬 SOCKS 진입점은 대체로 정상입니다. 다음으로 트레이의 시스템 프록시 모드를 확인하고 브라우저 사용자 지정 프록시를 해제한 뒤 브라우저를 다시 시작하세요. 테스트 도메인이 라우팅 규칙에 따라 직결 처리되지 않았는지도 확인해야 합니다.
노드 하나만 실패하고 나머지는 정상이라면?
로컬 환경 전체에 문제가 있을 가능성은 낮습니다. 현재 구독을 다시 업데이트하고 실패한 노드의 주소, 포트, 전송 방식, TLS, SNI, 플로우 제어가 모두 있는지 확인하세요. 정상 노드의 특정 필드만 복사해 덮어쓰지 마세요.
연결 후 몇 분이 지나 갑자기 끊기면?
로그 패널을 계속 열어 두고 끊긴 시각의 오류와 시간을 기록하세요. 여러 노드가 동시에 실패하면 로컬 네트워크 전환, 절전 모드 복귀, DNS를 확인합니다. 현재 노드만 실패한다면 같은 구독에서 실제 연결 지연이 정상인 예비 노드로 바꿔 비교하세요.
| 증상 | 우선 확인할 계층 | 핵심 근거 |
|---|---|---|
| 코어가 시작되지 않음 | 로컬 프로세스 및 포트 | 로그의 수신 실패 및 설정 해석 오류 |
| 명시적 프록시도 시간 초과 | 노드 및 원격 핸드셰이크 | DNS, 연결, TLS 또는 프로토콜 오류 |
| 명시적 프록시는 성공하지만 브라우저는 실패 | 시스템 프록시 및 앱 설정 | 브라우저 요청이 코어 로그에 들어오지 않음 |
| 일부 웹사이트만 직결 | 라우팅 분할 | 로그의 direct 또는 freedom 아웃바운드 |
첫 연결 성공 후 설정 마무리
핵심 포인트
세 단계 검증을 마쳤다면 일상적인 라우팅 모드로 복원한 뒤 다시 한 번 비교 테스트를 진행할 수 있습니다. 중국 본토 도메인은 직결하고 나머지 요청은 프록시로 보내는 방식이 흔하지만, 실제 결과는 규칙 순서와 아웃바운드 태그에 따라 달라집니다. 규칙은 보통 위에서 아래 순서로 매칭되므로 광고 차단, 사설 주소, 특정 도메인처럼 더 구체적인 규칙을 포괄적인 규칙보다 앞에 배치해야 합니다.
핵심 포인트
실제 연결 테스트를 통과한 노드를 최소 두 개 보유하세요. 하나는 주 노드로, 하나는 예비 노드로 사용합니다. 노드를 전환한 뒤 외부 IP와 로그를 다시 확인하고, 같은 구독의 모든 노드가 완전히 동일한 전송 매개변수를 사용한다고 가정하지 마세요. 구독을 업데이트하면 서버에서 내려온 노드 내용으로 덮어써지므로, 구독 노드를 로컬에서 직접 수정하기 전에 정말 필요한지 확인해야 합니다.
- 현재 로컬 수신 포트를 기록해 두세요. 예를 들어 SOCKS 포트가 10808이면 나중에 명시적 프록시 테스트를 실행하기 편리합니다.
- 실제 연결 테스트를 세 번 연속 성공했고 300ms 이내인 예비 노드를 하나 남겨 두세요.
- 구독을 업데이트한 뒤 실제 연결 지연을 다시 측정하고, 며칠 전 속도 테스트 결과를 그대로 사용하지 마세요.
- geosite, geoip 또는 사용자 지정 도메인 규칙을 변경했다면 로그에서 실제 아웃바운드 태그를 확인하세요.
- 장애가 발생하면 먼저 오류 시각, 노드 이름, 로그 유형을 저장한 뒤 계층별로 점검하세요.