구독을 가져온 뒤 v2rayN의 실제 연결 지연 시간 테스트가 시간 초과되거나, 브라우저에서 페이지가 열리지 않거나, 코어가 시작되지 않는 경우에 적합한 안내입니다. 먼저 로컬 수신 상태를 확인하고 구독과 노드를 점검한 다음 시스템 프록시와 네트워크 제한을 살펴보세요. 한 번에 하나씩 설정을 바꾸고, 명령 실행 결과와 같은 시간대의 로그를 비교해 문제 발생 단계를 찾으세요. 처음부터 클라이언트를 재설치할 필요는 없습니다.
먼저 구분하기: 포트 연결 실패, 노드 시간 초과, 브라우저 프록시 미사용
현재 설정을 유지한 채 선택한 노드, 테스트 시간, 오류 메시지를 기록하세요. 여러 노드의 속도를 한꺼번에 측정하지 말고 노드 하나를 선택해 한 번 재현한 뒤 메인 화면의 로그 영역에서 해당 기록을 확인하세요. 일괄 테스트는 여러 연결을 동시에 만들기 때문에 다른 노드의 오류를 현재 문제로 오인하기 쉽습니다.
v2rayN은 그래픽 클라이언트이며 실제 연결은 선택한 코어가 처리합니다. 화면이 열리고 구독이 표시된다고 해서 코어가 실행 중인 것은 아닙니다. 목록의 지연 시간도 테스트 방식을 구분해서 봐야 합니다. TCP 연결 테스트는 대상 포트에 연결할 수 있을 가능성만 보여 주며, 실제 연결 테스트에는 프록시 프로토콜과 핸드셰이크, 테스트 URL까지 영향을 줍니다.
| 증상 | 우선 점검 | 이 증상만으로 단정할 수 없는 점 |
|---|---|---|
| 모든 노드가 바로 실패하고 로그에 수신 실패가 표시됨 | 로컬 포트, 코어 프로세스, 설정 불러오기 | 구독 전체가 만료됐다고 단정할 수 없음 |
| TCP 테스트에는 값이 표시되지만 실제 연결 테스트는 시간 초과됨 | 프로토콜 설정, TLS, 테스트 URL, 서버의 외부 연결 | TCP 연결 가능 여부가 프록시 사용 가능 여부를 뜻하지는 않음 |
| 실제 연결 테스트는 성공하지만 브라우저는 여전히 실패함 | 시스템 프록시, 브라우저 자체 프록시, 라우팅 규칙 | 브라우저 접속 실패만으로 노드가 오프라인이라고 판단할 수 없음 |
| 노드 하나만 계속 시간 초과됨 | 해당 노드의 주소, 포트, 계정, 서비스 상태 | 보통 시스템 전체 설정부터 바꿀 필요는 없음 |
첫 번째 단계: 시스템 시간, 로컬 포트, 코어 실행 확인
아래 절차는 Windows용 v2rayN을 기준으로 합니다. 버전에 따라 화면의 문구가 다를 수 있으므로 포트는 실제 설정을 확인하세요. 먼저 「설정」→「매개변수 설정」에서 로컬 수신 설정을 찾아 SOCKS 또는 혼합 수신 포트를 확인합니다. 원격 노드의 서버 포트를 시스템 프록시에 입력하지 마세요.
-
시스템 시간 동기화
Windows 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 자동으로 시간 설정을 켠 뒤 「지금 동기화」를 선택하세요. 날짜와 시간대도 확인합니다. 시간이 크게 어긋나면 인증서 유효 기간 확인이나 일부 프로토콜 인증에 영향을 줄 수 있습니다. 시간대 표시가 다르다는 이유만으로 시스템 시계가 잘못됐다고 볼 수는 없습니다.
-
수신 포트 확인
v2rayN의 「설정」→「매개변수 설정」에서 수신 주소와 포트를 확인하세요. 이 글에서는 SOCKS 또는 혼합 수신 포트가
127.0.0.1:10808이라고 가정합니다. 화면에 다른 포트가 표시되면 아래 명령에서도 해당 포트를 사용하세요. -
포트를 사용 중인 프로세스 확인
PowerShell에서 아래 명령을 실행해 수신 상태와 PID를 확인한 뒤 작업 목록에서 프로세스를 확인하세요. 현재 코어가 수신 중이라면 일반적으로 정상입니다. 이전 클라이언트 인스턴스나 다른 프로그램이 사용 중이라면 해당 프로그램을 정상 종료하거나 현재 수신 포트를 비어 있는 포트로 변경하세요.
-
코어 다시 불러오기
설정을 저장하고 노드를 다시 선택한 다음 로그를 확인하세요. 필요하면 클라이언트를 종료한 후 다시 실행합니다. 포트를 변경했다면 브라우저 자체 프록시와 명령줄에 지정한 포트도 함께 변경해야 합니다. 수신 중인 포트가 없다면 원격 노드를 계속 테스트하지 말고 먼저 코어 시작 오류를 해결하세요.
Get-NetTCPConnection -State Listen -LocalPort 10808
netstat -ano | findstr ":10808"
tasklist /FI "PID eq 1234"마지막 줄의 1234는 예시 PID이므로 앞의 두 명령에서 확인한 프로세스 번호로 바꿔야 합니다. netstat 출력에서 로컬 주소와 원격 주소를 구분하고 상태가 LISTENING인지 확인하세요. 숫자 10808이 보인다는 이유만으로 포트가 다른 프로세스에 점유됐다고 단정하지 마세요. 어떤 프로세스인지 모르는 시스템 프로세스를 강제로 종료해서도 안 됩니다.
두 번째 단계: 구독 목록이 아니라 업데이트 성공 여부 확인
구독 목록에 이전에 저장한 내용이 남아 있을 수 있습니다. 업데이트에 실패해도 기존 노드는 계속 표시되므로 노드가 수십 개 있다고 해서 현재 구독이 유효하다는 뜻은 아닙니다. 먼저 「구독 그룹」→「구독 그룹 설정」에서 해당 그룹의 주소를 확인한 다음, 「구독 그룹」 메뉴에서 업데이트를 실행하고 결과와 업데이트 시간을 살펴보세요.
- 401 또는 403 응답: 먼저 구독 토큰과 접근 권한, 서비스 제공자의 제한을 확인하세요. 이 상태 코드는 요청이 HTTP 서비스에 도달했음을 뜻하므로 로컬 포트가 시작되지 않은 문제와는 다릅니다.
- 웹페이지나 로그인 페이지가 표시됨: 계정 관리 페이지가 아니라 구독 주소를 복사했는지 확인하세요. 페이지가 열렸다고 해서 클라이언트가 해석할 수 있는 노드 설정이 반환된 것은 아닙니다.
- 요청 시간 초과: 구독 도메인에 접속할 때 프록시가 필요한지 먼저 확인하세요. 사용 가능한 노드가 있다면 메뉴에서 프록시를 통해 업데이트하는 옵션을 시도할 수 있습니다. 모든 노드를 사용할 수 없는 상황에서 프록시를 통해 업데이트를 반복하면 해결할 수 없는 의존 관계가 생깁니다.
- 업데이트는 성공했지만 노드는 계속 작동하지 않음: 서비스 계정 만료 여부, 남은 트래픽, 노드 이전 여부를 확인하세요. 구독을 내려받는 것과 노드 인증에 성공하는 것은 별개의 과정입니다.
업데이트 전에 기존 설정을 백업하고 테스트를 위해 모든 그룹을 바로 삭제하지 마세요. 업데이트 후 목록이 비어 있다면 우선 응답 내용과 형식 호환성 문제를 해결하세요. 시스템 프록시를 계속 바꿔도 잘못된 구독 내용이 유효한 노드로 바뀌지는 않습니다.
세 번째 단계: 노드 설정을 확인하고 로그로 연결 실패와 핸드셰이크 실패 구분
현재 노드를 두 번 클릭해 편집 창을 열고 서비스 제공자가 안내한 원본 설정과 항목별로 비교하세요. 먼저 주소와 포트를 확인한 뒤 프로토콜과 전송 계층을 점검합니다. 노드 이름만 보고 프로토콜을 추측하지 말고, 작동하는 노드의 TLS나 전송 설정을 다른 노드에 일괄 적용하지 마세요.
- VMess: UUID, 암호화 방식, 서버에서 요구하는 기타 항목을 확인하세요. 오래된 설정을 이전하는 경우 서버의 최신 안내에 따라 다시 가져오고, 인증 설정을 임의로 바꿔가며 시도하지 마세요.
- VLESS: UUID와 흐름 제어 설정, 필요한 TLS 또는 REALITY 매개변수를 확인하세요. REALITY 노드는 서비스 제공자가 안내한 공개 키, 짧은 ID, 서버 이름 등의 설정도 일치해야 합니다.
- TLS: 서버 이름이 서비스 제공자의 요구사항과 일치하는지 확인하세요. 노드 연결 주소와 인증서에 사용된 도메인은 서로 다를 수 있으므로 두 값을 무조건 같게 바꾸면 안 됩니다.
- WebSocket: 전송 유형, 경로, Host를 확인하세요. 경로는 대소문자를 구분하는 경우가 많습니다. 맨 앞의 슬래시를 빠뜨리거나 Host를 잘못 입력해도 핸드셰이크가 실패할 수 있습니다.
- 코어 지원 여부: 현재 코어가 노드에서 요구하는 프로토콜과 전송 방식의 조합을 지원하는지 확인하세요. v2rayN은 클라이언트 이름이고 V2Ray와 Xray는 코어 프로젝트이므로 세 가지를 같은 버전 개념으로 보면 안 됩니다.
오류: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
원인: 현재 수신 주소와 포트가 이미 사용 중인 경우가 많습니다. 해결: 수신 프로세스를 확인하고 중복 실행을 종료하거나 로컬 포트를 변경한 다음 코어를 다시 불러오세요.
오류: dial tcp: lookup
원인: 주소 확인 오류에서 흔히 볼 수 있는 로그 일부입니다. 전체 행에는 보통 도메인과 구체적인 오류가 함께 표시됩니다. 해결: 서버 주소를 확인하고 시스템의 DNS 조회 명령으로 도메인을 테스트한 다음 코어의 DNS 설정을 참고해 실제 조회 경로를 확인하세요.
오류: i/o timeout
원인: 네트워크 읽기 또는 쓰기 단계 중 하나가 제한 시간 안에 완료되지 않은 것입니다. 이 오류만으로 서버가 다운됐다고 판단할 수는 없습니다. 해결: 같은 로그 행이나 앞뒤 행에서 대상 주소와 작업 단계를 확인한 뒤 서버 포트와 프록시를 거친 대상 URL을 각각 테스트하세요.
오류: x509: certificate has expired or is not yet valid
원인: 시스템 시간이 잘못됐거나 서버 인증서가 유효 기간이 아닐 수 있습니다. 해결: 먼저 시간을 동기화하세요. 시간이 맞는데도 같은 오류가 발생하면 서비스 제공자에게 인증서 갱신을 요청하세요. 인증서 검증을 건너뛰는 것은 일반적인 해결 방법으로 사용하지 마세요.
서버 도메인은 PowerShell의 Resolve-DnsName으로, 포트는 Test-NetConnection으로 확인할 수 있습니다. 매개변수에는 노드 편집 창에 표시된 실제 서버 주소와 원격 포트를 입력하세요. 로컬 포트 10808을 입력하면 안 됩니다. 시스템 DNS 조회에 성공해도 시스템의 해당 조회 경로가 정상이라는 뜻일 뿐입니다. 코어가 별도의 DNS를 사용한다면 코어 로그도 확인하세요.
판단 기준: TCP 연결이 되면 핸드셰이크 설정을 집중 점검
서버 포트 테스트는 통과하지만 프록시 요청이 계속 실패한다면 로컬 포트를 반복해서 변경하지 말고 인증, TLS, 전송 계층 설정부터 확인하세요. TCP 연결에 성공해도 서버 측 제한이나 중간 네트워크 간섭 가능성은 남아 있지만 점검 범위를 좁힐 수 있습니다.
네 번째 단계: 시스템 프록시를 거치지 않고 프록시 연결점 단독 테스트
코어가 정상적으로 수신 중인지 확인한 다음 PowerShell에서 아래 명령을 실행하세요. 이 명령은 로컬 SOCKS 연결점을 직접 지정하므로 브라우저가 시스템 프록시를 읽는지에 영향을 받지 않습니다. 여기서 10808은 SOCKS를 지원하는 것으로 확인된 포트여야 합니다. 해당 포트가 HTTP 전용 연결점이라면 아래의 HTTP 형식 명령을 사용하고 실제 포트를 입력하세요.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 --head https://example.com/socks5h는 대상 도메인 조회를 프록시에 맡겨 로컬에서 대상 사이트를 조회하는 과정의 영향을 줄입니다. HTTP 상태 줄이 응답되면 대체로 해당 연결점을 통해 HTTP 응답을 받은 것입니다. 다만 요청이 실제로 원격 프록시를 통해 나갔다고 단정할 수는 없으므로 로그에서 라우팅 결과를 확인하세요. 클라이언트의 로컬 연결점을 직접 지정해도 요청이 반드시 원격 프록시 출구로 나가는 것은 아닙니다.
curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 5 --max-time 15 --head https://example.com/두 번째 명령은 HTTP 연결점 사용 예시일 뿐이며 10809가 모든 버전에 있는 고정 포트는 아닙니다. 해당 연결점을 활성화하지 않았다면 그대로 따라 입력하지 마세요. 테스트 URL은 현재 네트워크와 서비스 정책에서 접속을 허용하는 사이트를 선택해야 합니다. URL 하나만 실패하면 별도의 사이트로도 비교해 대상 서비스 장애를 노드 문제로 오인하지 마세요.
- 명령은 성공하지만 브라우저는 실패: v2rayN 메인 화면 아래쪽의 「시스템 프록시」에서 「시스템 프록시 자동 구성」을 선택한 다음 Windows 「설정」→「네트워크 및 인터넷」→「프록시」가 현재 로컬 연결점을 가리키는지 확인하세요. 브라우저에 별도 프록시를 설정했다면 해당 설정도 확인해야 합니다.
- 분할 라우팅 모드에서만 실패: 테스트 대상을 프록시 출구로 보내는 것이 확실한 규칙을 임시로 적용해 비교한 뒤 원래 규칙으로 되돌리세요. 규칙 순서와 도메인 일치 여부, 최종 출구는 로그를 바탕으로 확인해야 합니다. 모드 이름만 보고 판단하지 마세요.
- 모든 로컬 요청이 거부됨: 첫 번째 단계로 돌아가 코어가 여전히 수신 중인지 확인하세요. 브라우저에 프록시 연결 실패가 표시되더라도 원격 노드에는 아직 연결하지 않았을 수 있습니다.
- 시스템 프록시는 정상이지만 특정 앱만 실패: 해당 앱이 시스템 프록시를 사용하지 않을 수 있습니다. 먼저 앱 자체의 네트워크 설정을 확인하세요. TUN은 별도의 트래픽 처리 방식이므로 기본 연결을 확인하기 전에 함께 활성화하지 않는 편이 좋습니다.
계속 시간 초과되는 경우: 네트워크 비교와 최소한의 기록으로 마무리
네 단계를 모두 확인한 뒤 같은 컴퓨터와 같은 노드로 현재 네트워크 및 모바일 핫스팟에서 각각 테스트하세요. 한 번에 네트워크 하나만 바꾸고 DNS, 노드 설정, 라우팅 모드는 동시에 변경하지 마세요. 특정 네트워크에서만 실패한다면 해당 네트워크의 DNS, 외부 연결 제한, 인증 페이지, 연결 품질을 먼저 확인하세요. 모든 네트워크에서 같은 노드만 실패한다면 서비스 제공자에게 문의하세요.
| 기록 항목 | 기록 방법 |
|---|---|
| 클라이언트와 코어 | 실제 클라이언트 버전, 코어 종류와 버전을 기록하세요. “최신 버전”이라고만 쓰지 마세요. |
| 발생 시각 | 분 단위로 정확히 기록하고 시간대를 함께 적어 서버 로그와 대조할 수 있게 하세요. |
| 로컬 확인 | 수신 포트, 프로세스 이름, 프록시 연결을 직접 지정한 명령의 결과 |
| 네트워크 비교 | 현재 네트워크와 핫스팟에서 재현되는지, 노드 하나만 실패하는지 |
| 오류 맥락 | 같은 요청이 발생한 시점의 로그 앞뒤 내용을 남기고 인증 항목과 구독 토큰은 가리세요. |
정리: 각 단계에서 재현 가능한 결과 남기기
로컬 수신이 정상인지, 구독 업데이트가 유효한지, 노드 설정이 일치하는지, 프록시 연결을 직접 지정한 요청이 성공하는지 확인하는 것이 지연 시간 숫자 하나보다 문제 판단에 더 유용합니다. 연결이 복구되면 임시 테스트 규칙과 네트워크 설정을 원래대로 되돌리고 정상 작동하는 설정을 저장하세요. 안정적인 연결을 확보했다면 테스트 수치를 더 낮추기 위해 계속 설정을 바꿀 필요는 없습니다.