V2Ray 첫 연결 가이드: 노드 선택, 실제 연결 테스트, 프록시 작동 확인

이 글의 핵심

구독은 가져왔지만 프록시 연결 여부를 확인하기 어려운 사용자를 위한 안내입니다. 먼저 v2rayN에서 노드를 선택하고 실제 연결 테스트를 실행한 다음, 로컬 수신 포트를 확인합니다. 터미널과 브라우저에서 각각 연결을 검증하고 로그를 바탕으로 노드 장애, 시스템 프록시 미적용, 라우팅 직결을 구분하세요. Android 사용자는 같은 순서로 v2rayNG를 점검할 수 있습니다.

1. 구독, 노드, 현재 연결 상태 구분하기

구독 업데이트에 성공했다는 것은 클라이언트가 설정을 가져와 파싱했다는 뜻일 뿐, 모든 노드에 연결할 수 있다는 의미는 아닙니다. 노드 목록의 이름, 지역, 프로토콜은 설정에 기재된 정보입니다. 이름만으로 실제 출구 위치를 확인할 수 없으며, VMess 또는 VLESS로 표시된다고 서버가 정상 작동하는 것도 아닙니다.

v2rayN은 구독을 관리하고 코어를 실행하며 트래픽 진입점을 설정하는 데스크톱 클라이언트입니다. 원격 연결은 선택한 코어가 실제로 수행합니다. Android에서는 v2rayNG가 Xray 코어를, v2flyNG가 v2fly 코어를 사용합니다. 문제를 진단할 때는 클라이언트와 코어 정보를 함께 기록하세요. 단순히 “V2Ray가 연결되지 않는다”고만 적어서는 원인을 파악하기 어렵습니다.

목록이 업데이트됐는지 확인: v2rayN의 「구독 그룹」 메뉴에서 해당 업데이트 작업을 선택하고 로그에서 파싱이 완료됐는지 확인하세요. 구독 주소가 저장된 것만 확인해서는 안 됩니다.
노드가 선택됐는지 확인: 사용 가능한 노드를 선택하고 마우스 오른쪽 버튼을 눌러 「활성 서버로 설정」을 선택한 다음, 메인 화면에 현재 서버로 표시되는지 확인하세요. 목록에서 행을 한 번 클릭하는 것만으로는 전환되지 않을 수 있습니다.
코어가 실행 중인지 확인: 로그에서 설정 파싱 실패, 코어 종료, 수신 실패가 있는지 확인하세요. 코어가 실행되지 않으면 시스템 프록시를 켜도 연결되지 않습니다.
시스템 시간이 정확한지 확인: Linux에서 timedatectl status를 실행해 시간과 동기화 상태를 확인할 수 있습니다. 시스템 시간이 크게 어긋나면 TLS 인증서 검증이나 프로토콜 인증에 문제가 생길 수 있습니다.

2. 실제 연결 테스트로 노드 고르기

v2rayN의 TCP 지연 시간 테스트는 원격 주소와 포트에 TCP 연결이 가능한지 주로 확인합니다. 실제 연결 테스트는 보통 해당 노드를 통해 지정된 테스트 주소에 요청을 보내므로 더 많은 프로토콜 및 전송 구간을 확인합니다. 두 테스트 모두 대역폭 측정은 아닙니다. 테스트에 성공해도 현재 테스트 대상에 접속할 수 있다는 뜻일 뿐, 실제 웹사이트 접속까지 보장하지는 않습니다.

후보 노드 선택

노드 목록에서 Ctrl 키를 누른 채 후보 노드 3개를 선택하세요. 서로 다른 경로의 노드를 먼저 고르고, 구독 전체를 한꺼번에 테스트해 동시 연결이 지나치게 많아지지 않도록 합니다.
실제 연결 테스트 실행

마우스 오른쪽 버튼으로 테스트 메뉴를 열고 「서버 실제 연결 지연 시간 테스트」 또는 현재 버전에서 「실제 연결」이 포함된 항목을 선택하세요. 메뉴 이름은 버전에 따라 다를 수 있습니다. TCP 지연 시간이나 다운로드 속도 테스트를 같은 기능으로 착각하지 마세요.
테스트 대상 확인

모두 실패하면 「설정」→「매개변수 설정」에서 실제 연결 테스트 주소와 시간 제한 설정을 찾으세요. 사용된 주소를 기록하고, 테스트 대상 자체에 접속할 수 없다면 접속 가능한 것으로 확인된 다른 HTTPS 테스트 대상으로 바꿔 비교하세요.
반복해서 비교

같은 네트워크와 테스트 주소를 유지하며 후보 노드별로 2회 더 테스트하세요. 한 번의 최저 지연 시간보다 연속으로 성공하는 노드를 우선 선택한 뒤 지연 시간을 비교하세요.
활성 노드로 설정

안정적으로 테스트에 성공한 노드를 활성 서버로 설정하고 코어 전환이 끝날 때까지 기다린 다음, 실제로 사용할 웹사이트를 여세요. 테스트만 실행해도 해당 노드가 현재 사용 노드로 자동 전환되는 것은 아닙니다.

결과에 표시되는 밀리초 값은 테스트 대상, 핸드셰이크 과정, 당시 네트워크 상태에 따라 달라집니다. 클라이언트나 테스트 주소가 다르면 직접 비교하기 어렵습니다. 처음 문제를 해결할 때는 정해진 지연 시간 기준을 찾기보다 테스트가 계속 성공하는지, 실패할 때 어떤 로그가 남는지 확인하는 편이 중요합니다.

실제 연결 테스트

권장

노드를 통해 테스트 대상에 요청하므로 첫 연결을 확인할 때 주요 노드 선별 기준으로 적합합니다. 테스트에 성공한 뒤에도 브라우저와 실제 사용 서비스에 접속되는지 확인하세요.

추천 상황: 처음 사용할 활성 노드 선택

TCP 지연 시간 테스트

원격 TCP 포트에 연결할 수 있는지 확인합니다. 포트에 연결되더라도 UUID, TLS, 전송 경로 또는 기타 프로토콜 설정이 올바르다는 뜻은 아닙니다.

추천 상황: 서버 포트에 빠르게 연결할 수 있는지 확인

실제 웹페이지 접속

앱의 프록시 설정, DNS, 라우팅 규칙, 대상 서비스의 상태가 모두 영향을 줍니다. 최종 사용 경험을 확인하는 방법이지만, 한 번 실패했다고 노드 장애로 단정할 수는 없습니다.

추천 상황: 평소 사용하는 환경에서 접속 확인

3. 로컬 포트와 트래픽 진입점 확인

이제 노드가 작동하는지와 앱이 해당 노드를 사용하는지를 나눠 확인합니다. v2rayN의 「설정」→「매개변수 설정」에서 로컬 수신 포트와 수신 주소를 찾으세요. 현재 버전에서 관련 항목이 별도의 인바운드 설정 페이지에 있다면 해당 화면을 기준으로 확인합니다. 아래 10808은 명령어 예시일 뿐, 모든 설치 환경에서 사용하는 고정 포트가 아닙니다.

로컬 진입점 예시

수신 주소: 127.0.0.1
예시 포트: 10808
진입점 프로토콜: SOCKS5. 혼합 인바운드는 HTTP도 지원할 수 있습니다
확인 위치: 매개변수 설정 및 코어 시작 로그

클라이언트가 실제로 해당 포트를 수신 중일 때만 아래 명령을 사용하세요. 별도의 HTTP 인바운드가 있다면 그 포트를 입력해야 합니다.

첫 검증 범위

검증 대상: 현재 기기의 브라우저와 curl
시스템 프록시: 시스템 설정을 따르는 앱에 적용
TUN 모드: 첫 테스트에서는 우선 끄기
LAN 공유: 이 기기에서 확인할 때는 켤 필요 없음

한 번에 하나의 진입점만 확인하세요. 시스템 프록시, TUN, 브라우저 확장 프로그램을 함께 켜면 트래픽 경로를 추적하기 어려워집니다.

Linux에서 아래 명령을 실행해 예시 포트가 수신 중인지 확인할 수 있습니다. 출력이 없으면 실제 포트와 코어 상태부터 확인하세요. 다른 프로그램이 사용 중이라고 표시되면 해당 프로그램을 종료하거나 로컬 포트를 바꾸고 앱 설정도 함께 업데이트합니다. 프록시가 작동하지 않는다는 이유만으로 모든 방화벽 포트를 열지 마세요.

ss -ltnp 'sport = :10808'

127.0.0.1에서 수신하면 이 기기에서 시작된 연결만 허용하므로 이 안내의 작업에 적합합니다. 0.0.0.0은 모든 IPv4 인터페이스에서 수신한다는 뜻으로, 다른 기기의 접속을 허용할 수 있습니다. 이 기기에서 처음 연결을 확인할 때는 「LAN 연결 허용」을 켤 필요가 없습니다.

4. curl로 프록시 연결 확인

명령줄에서 프록시를 명시하면 터미널이 시스템 프록시 설정을 읽는지 고민하지 않아도 됩니다. 아래 명령은 로컬 SOCKS5 포트 10808을 사용해 HTTPS 출구 주소 확인 서비스에 접속하는 예입니다. 해당 서비스에 문제가 있으면 테스트가 실패할 수도 있으므로, 접속 가능한 다른 대상에서도 확인하세요. 이 결과만으로 노드 장애를 단정할 수는 없습니다.

# 직결 기준 테스트: 프록시 환경 변수를 무시하며, 실패해도 진단에 도움이 됩니다
curl --noproxy '*' --connect-timeout 10 --max-time 20 https://api.ipify.org
printf '\n'

# 로컬 SOCKS5를 명시적으로 사용하고 대상 도메인 처리를 프록시 측에 맡깁니다
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://api.ipify.org
printf '\n'

socks5h의 h는 대상 도메인 처리를 프록시 서버에 맡긴다는 뜻으로, 이번 진단에서 로컬 DNS가 끼치는 영향을 줄여 줍니다. 그렇다고 기기 전체의 DNS가 프록시를 통과한다는 의미는 아닙니다. --noproxy ""는 이번 요청에서 프록시 우회 목록을 비워, 환경 변수 NO_PROXY 때문에 테스트가 의도치 않게 직결되는 것을 방지합니다.

직결과 프록시의 출구가 다름: 두 요청의 공인 IP 출구가 서로 다르다는 뜻입니다. 코어 접속 로그도 확인해 프록시 요청이 라우팅 규칙에 따라 직결 아웃바운드로 전송되지 않았는지 확인하세요.
두 요청의 출구가 같음: 프록시가 작동하지 않는다고 바로 판단할 수는 없습니다. 노드와 로컬 기기가 같은 공인 IP를 공유하거나, 클라이언트 규칙에 따라 해당 도메인이 직결될 수 있습니다. 어떤 아웃바운드가 선택됐는지 확인하세요.
로컬 포트 연결이 거부됨: 원격 노드를 계속 바꾸기보다 코어가 실행 중인지, 포트 번호가 맞는지 먼저 확인하세요.
로컬 연결은 성공하지만 시간 초과됨: 로그에서 DNS, TLS, 원격 연결, 인증 오류를 확인한 뒤 두 번째 테스트 대상으로 대상 서비스 문제와 노드 문제를 구분하세요.

HTTP 진입점을 테스트하려면 해당 포트가 실제로 HTTP 프록시 요청을 받는 경우에만 아래 명령을 실행하세요. 혼합 인바운드는 보통 SOCKS와 HTTP를 모두 지원하지만, SOCKS 전용 인바운드는 HTTP 포트로 사용할 수 없습니다. 인증서 검증을 무시하는 옵션으로 TLS 오류를 감추지 마세요.

curl --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://example.com/

5. 브라우저와 라우팅 적용 여부 확인

curl에서 프록시를 명시한 요청이 성공하면 브라우저를 확인합니다. v2rayN에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택하세요. Linux 데스크톱에 설정이 적용되지 않는다면 GNOME의 「설정」→「네트워크」→「네트워크 프록시」→「수동」에서 로컬 HTTP 또는 SOCKS 호스트와 해당 포트를 입력할 수 있습니다. 데스크톱 환경마다 설정 위치가 다르므로 실제 시스템 화면을 기준으로 확인하세요.

브라우저에 별도의 프록시 설정이 있을 수 있습니다. Firefox에서는 「설정」→「일반」→「네트워크 설정」→「설정」에서 「시스템 프록시 설정 사용」을 선택하거나 SOCKS 호스트 127.0.0.1과 실제 포트를 직접 입력하세요. 프록시 설정을 변경하는 확장 프로그램은 먼저 일시 중지해 시스템 설정을 덮어쓰지 않도록 합니다.

새 브라우저 창을 열고 명령줄 테스트에서 사용한 출구 확인 주소에 접속한 뒤 결과를 기록하세요.
v2rayN의 접속 로그도 함께 확인해 해당 도메인 요청과 선택된 아웃바운드를 점검하세요. 접속 로그가 비활성화되어 있다면 잠시 켜고, 확인을 마친 뒤 원래 설정으로 되돌리세요.
직결 규칙이 적용됐다면 현재 라우팅 모드를 기록하세요. 필요한 경우 현재 버전에서 제공하는 전역 프록시 모드로 잠시 전환해 비교한 다음, 테스트가 끝나면 기존 분할 라우팅 규칙을 복원하세요.
마지막으로 실제 사용할 웹사이트에 접속하세요. 진입점, 라우팅, 대상 사이트 접속이 모두 예상대로 작동해야 첫 연결 확인이 완료된 것입니다.

Android에서는 v2rayNG에서 노드를 선택한 뒤 메인 화면의 연결 버튼을 누르고 시스템 VPN 권한을 승인한 다음 연결을 테스트하세요. VPN 상태 아이콘이 보이는 것은 로컬 터널이 생성됐다는 뜻일 뿐이므로 대상에 접속할 수 있는지도 확인해야 합니다. 앱별 프록시를 켰다면 브라우저가 프록시 대상에 포함됐는지 확인하세요. v2flyNG에서도 연결 상태와 앱 적용 범위를 각각 점검해야 합니다.

6. 첫 연결에서 자주 묻는 질문

실제 연결 테스트는 성공하는데 브라우저에서 페이지가 열리지 않는 이유는 무엇인가요?

먼저 SOCKS5를 명시한 curl 명령을 실행하세요. 성공한다면 브라우저별 프록시 설정, 시스템 프록시, 라우팅 규칙을 중점적으로 확인하세요. 브라우저 요청이 접속 로그에 없다면 해당 요청이 아직 코어에 도달하지 않았을 가능성이 큽니다. 구독의 프로토콜 설정부터 바꾸지는 마세요.

TCP 지연 시간은 나오는데 실제 연결 테스트가 계속 시간 초과되는 이유는 무엇인가요?

원격 TCP 포트에는 연결되지만 이후 연결 과정이 완료되지 않았다는 뜻입니다. 테스트 대상이 작동하는지 확인한 다음 시스템 시간과 로그의 TLS, 인증, 전송 오류를 점검하세요. 한 노드만 실패한다면 구독을 업데이트하고 다른 노드와 비교하세요. VLESS를 VMess로 임의 변경하지 마세요.

명령 실행 시 127.0.0.1:10808에 연결할 수 없다고 나오는 이유는 무엇인가요?

「설정」→「매개변수 설정」으로 돌아가 실제 포트를 확인한 뒤 포트 검사 명령을 다시 실행하세요. 코어 로그에 주소가 이미 사용 중이라고 표시되면 포트 충돌을 해결하고 코어를 재시작하세요. 원격 노드가 아무리 안정적이어도 로컬 진입 포트가 수신 중이 아니면 해결되지 않습니다.

웹페이지가 열리면 프록시가 적용된 것인가요?

반드시 그렇지는 않습니다. 대상 사이트에 원래 직결할 수 있었을 수도 있습니다. 출구 확인 결과, 코어에 기록된 대상 요청, 선택된 프록시 아웃바운드를 함께 확인하세요. 프록시 아이콘, 노드 이름, 한 번의 속도 테스트 결과만으로 브라우저 트래픽 경로를 확정할 수는 없습니다.

여전히 연결되지 않는다면 문제 해결 정보를 전달할 때 운영체제, 클라이언트 버전, 코어 이름과 버전, 진입점 유형과 포트, 테스트 대상, 실패 시각, 관련 오류 로그를 함께 적으세요. 버전은 클라이언트의 「도움말」→「정보」 또는 코어 시작 로그에서 확인할 수 있습니다. “최신 버전”이라고만 적지 마세요. 이 정보가 있으면 실패한 구간부터 점검하고 로컬 설정 문제와 서버 설정 문제를 구분할 수 있습니다.