v2rayN 실행 로그 확인법: 오류 메시지별 원인과 해결 방법

이 글의 핵심 내용

노드를 가져왔지만 웹페이지가 열리지 않거나 연결이 시간 초과되거나 코어가 시작되지 않는 v2rayN 사용자에게 적합한 안내입니다. 먼저 실패한 요청의 오류 로그 전체를 보관한 뒤 로컬 수신 대기, 트래픽 유입, DNS, 원격 포트, 프로토콜 핸드셰이크 순서로 점검하세요. 로그 수준 설정과 자주 보이는 영문 오류의 의미, Windows 로컬 테스트 명령을 소개해 모든 문제를 ‘노드가 끊겼다’고 단정하지 않도록 돕습니다.

1. 실행 로그를 열고 실패한 요청 재현하기

v2rayN은 GUI 클라이언트이며 실제 프록시 연결은 클라이언트가 실행한 코어가 처리합니다. 클라이언트 화면 오류, 코어 시작 실패, 개별 연결 실패는 서로 다른 문제입니다. 로그를 확인하기 전에 선택된 노드, 코어 종류, 오류 발생 시각을 확인하세요. 노드를 바꾸는 동안 생긴 오류를 한데 섞어 분석하지 마세요.

현재 설정 기록하기

메인 화면에서 클라이언트 버전, 선택한 노드의 프로토콜과 전송 방식을 기록한 다음 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 대기 포트를 확인하세요. 데스크톱 UI와 클래식 UI는 설정 메뉴 구성이 다를 수 있으니 현재 버전에 표시된 항목을 기준으로 확인하세요.
진단 로그 켜기

‘설정’ → ‘매개변수 설정’에서 코어의 ‘로그 수준’ 항목을 찾으세요. 일부 버전에서는 ‘Core: 기본 설정’ 그룹에 있습니다. Xray를 사용한다면 먼저 info를 선택하고, 정보가 부족할 때만 잠시 debug로 바꾸세요. 저장한 뒤 코어를 다시 시작해야 설정이 적용됩니다.
문제 한 번 재현하기

메인 화면 아래쪽의 실행 정보나 로그 영역을 열고 현재 시각을 기록하세요. 여러 노드의 속도 테스트는 잠시 멈추고 노드 하나만 선택한 뒤 문제가 발생한 웹사이트에 한 번 접속합니다. 해당 시각 전후의 로그를 복사하고 마지막 한 줄만 잘라내지 마세요.
로그 수준 원래대로 돌리기

원인을 찾은 뒤 로그 수준을 warning 또는 기존 값으로 되돌리세요. 파일 로그를 켰다면 저장 위치와 파일 크기도 확인하세요. 진단 로그에는 방문한 도메인, 로컬 주소, 아웃바운드 태그가 기록될 수 있습니다.

Xray의 일반적인 로그 수준은 debug, info, warning, error, none입니다. 로그 수준은 기록의 상세도만 바꾸며 연결 정책에는 영향을 주지 않습니다. error만 선택하면 유용한 연결 과정이 누락될 수 있고, debug를 계속 켜 두면 로그가 많아지고 접속 메타데이터가 노출될 가능성도 커집니다.

2. 오류 체인 읽기: 주소를 먼저, 근본 원인은 그다음

로그 한 줄에 여러 단계의 오류가 함께 들어가는 경우가 많습니다. 바깥쪽에는 ‘연결 처리 실패’, 중간에는 ‘사용 가능한 대상 없음’, 가장 안쪽에는 연결 거부나 시간 초과가 표시될 수 있습니다. 우선 오류 체인에 어떤 주소가 나오는지 확인하고 가장 구체적인 시스템 오류를 찾으세요. failed가 보인다고 프로토콜부터 바꾸면 안 됩니다.

로그 단서	의미	다음 단계
`127.0.0.1:10808`	앱이 로컬 프록시에 연결할 때 자주 표시되는 로컬 루프백 주소와 포트입니다.	수신 대기 상태를 확인하고 앱에 입력한 포트를 대조하세요.
`dial tcp`	TCP 연결을 시도하는 중입니다.	뒤에 표시된 주소가 노드 서버인지 대상 웹사이트인지 확인하세요.
`lookup`、`no such host`	도메인 이름을 확인하는 단계에서 문제가 발생했습니다.	오류가 난 도메인, DNS 경로, 응답 결과를 확인하세요.
`accepted`	코어가 인바운드 요청을 받았습니다.	해당 아웃바운드 결과를 확인하세요. 원격 연결이 성공했다는 뜻은 아닙니다.
`direct`、`proxy`	현재 설정의 아웃바운드 태그일 수 있습니다.	실제 라우팅 설정과 대조하세요. 태그 이름은 고정된 표준이 아닙니다.

아래는 로그를 읽는 순서를 보여 주기 위한 간략한 예시이며 실제 측정 기록이 아닙니다. 로컬 TCP 포트에서 연결이 거부됐다는 뜻입니다. 이 메시지만으로 원격 노드의 품질을 판단할 수는 없습니다.

dial tcp 127.0.0.1:10808: connectex: No connection could be made because the target machine actively refused it.

핵심 판단 기준: 주소를 보면 점검 대상을 알 수 있습니다

오류가 루프백 주소를 가리키면 로컬 수신 대기 상태부터 확인하세요. 노드 서버 주소를 가리키면 원격 포트를 확인합니다. 연결의 양쪽이 어디인지 파악한 다음 노드 설정을 바꿀지 결정하세요.

3. 자주 나오는 오류 메시지와 해결 방법

같은 문제라도 코어나 운영체제에 따라 영문 표현이 조금씩 다를 수 있습니다. 아래 오류 문구를 찾을 때는 주소, 포트, 전송 유형, 인증서 이름 등 앞뒤 문맥을 함께 확인하세요. 경고가 한 번 나와도 실제 사용에 문제가 없다면 바로 설정을 바꿀 필요는 없습니다. 같은 오류가 반복되고 실제 연결 실패와 일치할 때 진단 단서로 삼으세요.

오류: connection refused

원인: 대상 주소에서 연결을 거부했습니다. 해당 포트에서 서비스가 수신 대기 중이지 않거나 방화벽이 연결을 차단했을 수 있습니다.

해결: 먼저 주소를 확인하세요. 로컬 포트라면 코어가 실행 중인지 확인하고, 원격 포트라면 구독 정보의 서버와 포트를 대조한 뒤 서버 관리자에게 수신 대기 상태를 확인해 달라고 요청하세요. 다시 시도하는 것만으로 포트 문제를 해결할 수는 없습니다.

오류: i/o timeout

원인: 제한 시간 안에 읽기나 쓰기 작업이 완료되지 않았습니다. TCP 연결, TLS 핸드셰이크 또는 이후 데이터 전송 단계에서 발생할 수 있습니다.

해결: dial, read, write가 표시되는지 확인해 어느 단계인지 파악하세요. 같은 노드를 유지한 채 다른 네트워크에서 다시 테스트하세요. 시간 초과만으로 비밀번호가 틀렸다고 단정하거나 제한 시간을 무작정 늘리지 마세요.

오류: failed to handshake

원인: 핸드셰이크 단계에서 실패했다는 뜻입니다. 이 문구만으로는 원인을 알 수 없으며 뒤에 이어지는 인증서, 인증, EOF 또는 시간 초과 정보가 구체적인 단서를 제공합니다.

해결: 서버 요구사항에 따라 프로토콜, TLS, SNI, 전송 방식, 인증 매개변수를 하나씩 대조하세요. REALITY를 사용한다면 공개 키, shortId, serverName과 클라이언트 지원 여부도 확인해야 합니다.

오류: bind: Only one usage of each socket address

원인: Windows에서 바인딩하려는 로컬 주소와 포트를 다른 프로세스가 이미 사용 중입니다. 프로그램이 중복 실행됐을 때 자주 발생합니다.

해결: 해당 포트를 사용하는 프로세스를 찾아 중복 실행을 종료하거나 로컬 포트를 변경하세요. 포트를 바꿨다면 브라우저, 터미널, 직접 설정한 프록시 주소도 함께 수정해야 합니다.

오류: no such host

원인: 도메인 이름을 확인해 사용할 수 있는 결과를 얻지 못했습니다. 도메인 오타, DNS의 존재하지 않는다는 응답, 조회 경로 오류 등이 원인일 수 있습니다.

해결: 노드 도메인과 대상 웹사이트 도메인을 구분하세요. 철자와 구독 갱신 결과를 확인한 다음 해당 DNS 설정을 점검하세요. TLS의 이름 확인이 깨질 수 있으므로 모든 도메인을 IP 주소로 바꾸지는 마세요.

오류: x509: certificate has expired or is not yet valid

원인: 인증서 유효 기간 확인에 실패했습니다. 서버 인증서가 만료됐거나 로컬 날짜와 시간이 잘못됐을 수 있습니다.

해결: 먼저 시스템 시간을 동기화한 다음 서버 관리자에게 인증서 갱신과 인증서 체인을 확인해 달라고 요청하세요. 인증서 검증을 끄는 방식은 장기적인 해결책이 아닙니다.

오류: failed to find an available destination

원인: 대상 연결 실패를 요약한 바깥쪽 오류인 경우가 많으며, DNS 문제만을 뜻하지는 않습니다. 내부에는 연결 거부, 시간 초과, 주소에 연결할 수 없다는 오류가 포함될 수 있습니다.

해결: 전체 오류 체인을 펼쳐 lookup, dial tcp 또는 시스템 오류처럼 가장 구체적인 내용을 확인한 뒤 해당 항목에 따라 해결하세요. 이 문구만 보고 DNS부터 바꾸지 마세요.

EOF와 connection reset by peer만으로 인증 실패라고 단정할 수는 없습니다. 상대방이 연결을 종료하거나 초기화했다는 뜻이며, 전송 매개변수 불일치, 서버 정책, 연결 재사용, 중간 네트워크 장비 등이 원인일 수 있습니다. 웹페이지를 닫을 때만 가끔 발생하고 새 요청은 정상이라면 우선 지켜보세요. 핸드셰이크 때마다 발생한다면 서버 로그와 비교해 보세요.

4. 로컬 포트부터 원격 설정까지 순서대로 범위 좁히기

아래 예시는 Windows PowerShell에서 로컬 프록시가 127.0.0.1:10808을 수신 대기 중이라고 가정합니다. 이 포트는 예시일 뿐 모든 버전에서 고정으로 사용하는 값이 아닙니다. ‘설정’ → ‘매개변수 설정’에서 로컬 수신 대기 포트와 인바운드 유형을 먼저 확인하세요. 시스템 프록시, 별도 HTTP 포트, 혼합 포트는 기억에 의존해 같은 것으로 취급하면 안 됩니다.

10808

이 섹션의 예시 로컬 프록시 포트

443

HTTPS 대상 포트 예시

15초

예시 요청의 전체 제한 시간

첫 번째 단계: 로컬에서 프로세스가 수신 대기 중인지 확인

Get-NetTCPConnection -LocalPort 10808 -State Listen
Test-NetConnection -ComputerName 127.0.0.1 -Port 10808

첫 번째 명령은 수신 대기 항목과 OwningProcess를 확인합니다. 해당 항목이 없으면 일치하는 개체가 없다는 메시지가 표시됩니다. 두 번째 명령의 TcpTestSucceeded : True는 로컬 TCP 포트에 연결할 수 있다는 뜻일 뿐, SOCKS 협상이나 원격 프록시 연결 성공을 의미하지는 않습니다. 프로세스를 확인하려면 Get-Process -Id 뒤에 조회한 프로세스 번호를 입력해 다른 서비스를 잘못 종료하지 않도록 하세요.

두 번째 단계: 프록시를 명시해 요청 보내기

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://example.com/

이 명령을 사용하려면 해당 포트가 SOCKS5를 지원해야 합니다. socks5h는 대상 도메인 조회를 프록시 측에 맡겨 curl이 로컬에서 먼저 대상 도메인을 조회하지 않도록 합니다. 실제로 코어가 도메인을 어떻게 조회하는지는 DNS 및 라우팅 설정에 따라 달라집니다. example.com은 예시 대상이며 노드 서버 주소가 아닙니다. HTTP 응답 헤더를 받았다면 해당 요청의 연결 경로가 완료된 것입니다. 모든 사이트가 정상이라는 뜻은 아닙니다.

명령 실행 즉시 연결이 거부됨: 로컬 포트와 수신 대기 프로세스를 확인하세요. 원격 설정부터 바꿀 필요는 없습니다.
로컬 포트에는 연결되지만 요청이 시간 초과됨: 같은 시각의 코어 로그에서 DNS, 노드 주소, 핸드셰이크 오류를 확인하세요.
명령은 성공하지만 브라우저에서 실패함: 브라우저의 개별 프록시 설정, 시스템 프록시, 프록시 예외 목록을 확인하세요.
특정 웹사이트 하나만 실패함: 다른 사이트로 교차 테스트하고 해당 도메인의 라우팅 규칙 적용 결과, DNS 응답, 대상 서비스 상태를 확인하세요.

세 번째 단계: 라우팅 문제와 원격 연결 문제 구분하기

시스템 프록시는 이를 따르는 앱이 트래픽을 연결하는 방식을 정하고, 라우팅 분기는 코어가 받은 트래픽을 어느 출구로 보낼지 결정합니다. 문제를 분리하려면 테스트 대상을 프록시 아웃바운드로 보내는 라우팅 모드로 잠시 바꿔 테스트한 뒤 원래 설정으로 복구하세요. 노드 포트를 테스트할 때는 Test-NetConnection의 컴퓨터 이름과 포트를 노드 세부 정보에 표시된 실제 값으로 바꾸세요. TCP 연결 성공은 포트에 도달할 수 있다는 뜻일 뿐 VLESS, VMess, Trojan의 인증이나 핸드셰이크를 확인하지는 않습니다.

핵심 판단 기준: 명시적 프록시 요청이 성공한 뒤 시스템 연결 설정 확인

curl로 프록시를 명시한 요청은 성공하지만 브라우저에서 실패한다면 노드 설정은 그대로 두고 시스템 프록시와 브라우저 설정부터 확인하세요. 이미 정상인 원격 연결에 불필요한 변수를 추가하지 않을 수 있습니다.

5. 핸드셰이크 실패 시 프로토콜과 전송 매개변수 확인

구독을 성공적으로 가져왔다는 것은 클라이언트가 설정을 읽었다는 뜻일 뿐입니다. 서버에 여전히 접속할 수 있다는 보장은 없으며, 현재 코어가 모든 설정 항목을 지원한다는 의미도 아닙니다. 구독을 갱신한 뒤에는 현재 선택한 항목이 실제로 갱신된 노드인지 확인하세요. 이전 노드를 사용하면서 새 구독 정보를 기준으로 문제를 찾지 마세요.

설정 조합	우선 확인할 항목	자주 하는 잘못된 변경
VMess	사용자 ID, 서버 인증 설정, 로컬 시간, 전송 설정.	서버 요구사항을 확인하지 않고 인증 항목을 수정함.
VLESS + REALITY	사용자 ID, 공개 키, shortId, serverName, flow, 코어 지원 여부.	다른 노드의 공개 키나 flow를 복사함.
Trojan + TLS	비밀번호, 서버 주소, 포트, SNI, 인증서 체인.	인증서 검증을 꺼서 도메인이나 인증서 오류를 숨김.
WebSocket 전송	경로, Host, TLS 설정, 리버스 프록시 설정.	경로의 대소문자나 끝의 슬래시가 중요하지 않다고 여김.
gRPC 전송	serviceName, TLS 설정, 리버스 프록시의 HTTP/2 지원 여부.	노드 포트만 바꾸고 리버스 프록시는 확인하지 않음.

전송 방식과 프록시 프로토콜은 서로 다른 계층입니다. VLESS라고 해서 자동으로 REALITY를 사용하는 것은 아니며 TLS가 WebSocket과 같은 것도 아닙니다. 서버의 전체 설정을 기준으로 판단하세요. 클라이언트 드롭다운에 특정 옵션이 있다는 이유로 노드 조합을 임의로 바꾸면 안 됩니다. 문제를 점검할 때는 한 번에 항목 하나만 바꾸고 같은 요청을 재현해 결과를 기록하세요.

6. 자주 묻는 질문과 로그 공유 전 확인 사항

지연 시간 테스트는 정상인데 웹페이지가 열리지 않는 이유는 무엇인가요?

TCP 지연 시간은 특정 포트의 연결 상태만 보여 주며 프로토콜 인증이나 웹사이트 접속까지 확인하지 않을 수 있습니다. 먼저 위의 프록시 지정 요청으로 다시 테스트한 다음 해당 시각의 코어 로그를 확인하세요. 지연 시간 하나만으로 전체 연결 경로를 판단하지 마세요.

구독 갱신이 시간 초과되면 노드가 반드시 고장 난 건가요?

구독 다운로드와 노드 연결은 서로 다른 요청입니다. 먼저 ‘구독 그룹’에서 구독 주소가 만료되지 않았는지 확인한 다음 갱신 요청이 직접 연결인지 프록시를 거치는지 확인하세요. 프록시로 갱신하려면 먼저 사용 가능한 노드가 있어야 합니다. 로그를 공유할 때 전체 구독 주소를 공개하지 마세요.

브라우저는 되는데 명령줄과 게임은 연결되지 않는 이유는 무엇인가요?

일부 앱은 시스템 프록시를 사용하지 않습니다. 명령줄에서는 프록시를 명시해 먼저 연결을 확인할 수 있습니다. 다른 앱은 프록시 지원 여부를 확인하세요. TUN을 사용하기 전에 권한, 라우팅, DNS를 점검하세요. 연결 방식과 노드 설정을 동시에 바꾸면 결과를 비교하기 어렵습니다.

debug를 켰는데도 원인을 찾을 수 없는 이유는 무엇인가요?

먼저 백그라운드 요청을 줄이고 노드 하나와 대상 하나만 정해 한 번 재현하세요. 오류 체인 전체를 보관하고 클라이언트 버전, 코어 버전, 운영체제 버전, 발생 시각을 기록하세요. 필요하면 서버 관리자에게 같은 시간대의 서버 로그를 확인해 달라고 요청하세요.

다른 사람에게 도움을 요청할 때는 문제 해결에 필요한 구조는 유지하되 민감한 값은 삭제하세요. 사용자 이름, 구독 토큰, 노드 인증 정보, 불필요한 접속 기록은 공개하면 안 됩니다. ‘시간 초과’ 화면만 캡처해서는 문제가 어느 단계에서 생겼는지 판단하기 어렵습니다. 민감한 정보를 가린 오류 체인 전체 중 짧은 구간이 로그 화면 전체보다 유용합니다.

환경 정보 유지: 클라이언트 버전, 코어 버전, 운영체제 버전, 시스템 프록시 또는 TUN 사용 여부.
재현 정보 유지: 오류 발생 시각, 대상 유형, 매번 발생하는지 여부, 네트워크를 바꿨을 때의 결과.
구조 정보 유지: 프로토콜, 전송 방식, TLS 또는 REALITY 사용 여부, 오류가 로컬인지 원격인지.
비밀 정보 삭제: 전체 구독 링크, UUID, 비밀번호, 개인 키, 토큰이 포함된 쿼리 매개변수. 필요하지 않은 전체 서버 주소도 가릴 수 있습니다.

마지막으로 원래 순서대로 다시 테스트하세요. 코어가 정상적으로 시작되고, 로컬 포트에 연결할 수 있으며, 프록시 지정 요청에 응답이 오고, 평소 사용하는 앱이 예상대로 연결되는지 확인합니다. 네 가지 모두 통과하면 일반 라우팅과 로그 수준을 복구하세요. DNS, 포트, 프로토콜을 한꺼번에 바꾸는 것보다 이 순서를 따르면 검증 가능한 결론을 얻기 쉽습니다.