설정을 가져왔지만 연결되지 않거나 간헐적으로 실패하는 사용자를 위한 안내입니다. 먼저 로그가 클라이언트에서 나온 것인지 커널에서 나온 것인지 확인한 뒤, 로컬 수신 대기, 도메인 이름 확인, 원격 연결, TLS, 프로토콜 매개변수 순서로 점검합니다. 아래에는 오류 대조표, Windows 점검 명령, 재현 절차를 정리했습니다. 빨간 오류가 보인다고 모든 설정을 바꾸기보다 어느 계층에서 실패했는지 확인하는 것이 중요합니다.
클라이언트 로그, 액세스 로그, 오류 로그 구분하기
v2rayN은 설정 관리, 커널 실행, 시스템 프록시 설정 등을 담당하는 데스크톱 클라이언트입니다. 실제 연결 처리는 선택한 커널이 담당합니다. Android에서는 v2rayNG가 주로 Xray 커널을, v2flyNG가 V2Fly 커널을 사용합니다. 클라이언트 화면의 오류 알림과 커널의 연결 오류는 서로 다른 문제입니다. 구독 다운로드 실패가 현재 프록시의 아웃바운드 연결 실패를 뜻하지는 않으며, 커널이 시작되지 않았다면 브라우저 DNS를 바꿔도 해결되지 않습니다.
문제를 진단하기 전에 클라이언트 버전, 실제 커널 이름과 버전을 기록하세요. 두 커널은 버전에 따라 오류 형식과 지원하는 설정 범위가 달라질 수 있으므로, 다른 커널의 전체 설정을 그대로 붙여 넣지 마세요. 아래 설명은 로그의 의미를 기준으로 하며, 예시의 주소와 포트, 문구는 이해를 돕기 위한 것으로 특정 버전의 전체 출력 형식을 나타내지 않습니다.
| 로그 출처 | 주요 기록 | 우선 점검 항목 |
|---|---|---|
| 클라이언트 로그 | 구독 업데이트, 프로세스 시작, 설정 생성 | 실행 환경, 파일 권한, 구독 요청 |
| 커널 액세스 로그 | 수신한 대상 요청과 인바운드·아웃바운드 정보 | 앱 요청이 커널에 들어왔는지, 분기 선택 |
| 커널 오류 로그 | 이름 확인, 연결 시도, 핸드셰이크, 설정 오류 | 가장 구체적인 원인과 대상 주소 |
액세스 로그에 accepted가 표시되면 보통 로컬 인바운드가 요청을 받은 것입니다. 원격 연결이 완료되었거나 웹페이지의 응답을 전부 받았다는 뜻은 아닙니다. 반대로 액세스 로그가 보이지 않더라도 단순히 액세스 로그가 꺼져 있을 수 있으므로, 앱이 프록시를 우회했다고 바로 판단해서는 안 됩니다.
로그 수준 선택: 먼저 warning, 짧게 debug 사용하기
Xray/V2Fly의 일반적인 오류 로그 수준은 debug, info, warning, error, none입니다. warning에서는 보통 경고와 오류가 기록되고, debug에서는 자세한 디버그 정보가 추가됩니다. none은 오류 로그 출력을 끕니다. 액세스 로그는 별도로 설정하므로 오류 로그 수준과 혼동하지 마세요.
-
커널 확인
v2rayN 시작 정보에서 커널 이름과 버전, 시작 결과를 기록하세요. 노드가 VMess인지 VLESS인지만 확인하지 말고, 실제로 예상한 커널이 실행 중인지 확인해야 합니다.
-
로그 수준 조정
v2rayN에서 흔히 사용하는 메뉴 경로는 「설정」→「매개변수 설정」→「Core: 기본 설정」→「로그 수준」입니다. 버전에 따라 메뉴 그룹이나 이름이 달라질 수 있으니 현재 화면을 기준으로 확인하세요. 잠시 debug를 선택하고 저장한 뒤 커널을 다시 시작합니다.
-
한 번 재현
시스템 시간을 기록하고 점검할 주소 하나만 엽니다. 해당 시점 전후 약 10초 동안의 연속 로그를 수집하세요. 속도 측정, 구독 업데이트, 여러 웹페이지 열기를 동시에 하지 마세요.
-
설정 복원
재현이 끝나면 warning으로 되돌리고 필요에 따라 액세스 로그를 끄세요. 공유하기 전에 구독 주소, 사용자 식별 정보, 인증 정보, 개인 도메인을 가리고 오류 유형과 필요한 포트 정보만 남기세요.
사용자 지정 커널 설정을 사용하는 경우 로그 항목은 다음과 같은 형식으로 작성할 수 있습니다. 이는 최상위 log 설정의 일부일 뿐, 단독 실행 가능한 전체 설정이 아닙니다. 클라이언트가 생성한 설정은 다음 시작 때 덮어써질 수 있으므로 클라이언트 화면에서 수정하는 편이 좋습니다.
{
"log": {
"loglevel": "debug"
}
}연결 흐름에 따라 로그 읽기: 실패 대상부터 가장 구체적인 원인까지
이는 문제를 찾는 순서를 보여 주는 것으로, 모든 요청이 반드시 이 시간 순서대로 진행되는 것은 아닙니다. 라우팅 과정에서 DNS 조회가 먼저 일어날 수 있고, 직접 연결 아웃바운드는 프록시 서버를 거치지 않을 수도 있습니다. 로그를 읽을 때 요청 대상, 선택된 아웃바운드, 실제 연결 시도 주소를 함께 확인해야 합니다. 그래야 ‘대상 웹사이트에 접속할 수 없음’을 ‘프록시 서버 포트가 열려 있지 않음’으로 잘못 해석하지 않습니다.
아래는 간략화한 오류 흐름입니다. 바깥쪽 오류는 프록시 요청이 처리되지 않았다는 뜻이고, 안쪽의 dial tcp가 TCP 연결 실패를 구체적으로 나타냅니다. 203.0.113.10은 문서용 예시 주소이고 443은 예시 원격 포트이므로 실제 노드에 사용하지 마세요.
proxy: failed to process outbound traffic
transport/internet: failed to open connection
dial tcp 203.0.113.10:443: i/o timeout- 먼저 시간을 확인합니다: 이번 재현 시간대의 로그만 점검해 이전에 노드를 바꾸면서 남은 오류를 현재 문제로 오인하지 않도록 합니다.
- 다음으로 요청을 확인합니다: 로그에 연결 식별자가 있다면 같은 식별자로 맥락을 연결하세요. 동시에 진행된 요청은 인접한 로그 행이라도 같은 연결이 아닐 수 있습니다.
- 마지막으로 원인을 읽습니다: 오류 흐름을 단계별로 따라가 이름 확인 실패, 연결 거부, 시간 초과, 인증서 검증 실패 같은 구체적인 원인을 찾습니다.
판단 기준: 프로토콜을 바꾸기 전에 실패 계층부터 확인
가장 안쪽의 오류가 여전히 원격 TCP 연결 시간 초과라면 먼저 주소와 포트를 확인하세요. TCP 연결이 성립되지 않은 상태에서 VMess 사용자 식별자나 VLESS 매개변수를 바꿔도 대개 해결되지 않습니다.
자주 발생하는 오류: 연결 거부, 시간 초과, 이름 확인 실패, 포트 충돌
같은 키워드라도 발생한 계층에 따라 의미가 다를 수 있습니다. 특히 connection refused는 로컬 127.0.0.1:10808 연결이 거부된 경우와 원격 서버 443 연결이 거부된 경우의 해결 방법이 완전히 다릅니다. 아래는 자주 보이는 원문 문구이며, 구체적인 접두사와 시스템 오류 설명은 다를 수 있습니다.
오류: connection refused
원인: 연결이 명시적으로 거부되었습니다. 해당 포트에서 서비스가 대기 중이지 않거나 방화벽이 연결을 적극적으로 거부할 때 흔히 발생합니다.
해결: 로그에 나온 대상 IP와 포트를 먼저 확인하세요. 로컬 주소라면 커널이 실행 중인지 점검하고, 원격 주소라면 노드 포트와 서버의 수신 대기 상태를 확인합니다.
오류: i/o timeout
원인: 네트워크 읽기 또는 쓰기 작업이 제한 시간을 넘겼습니다. TCP 연결, 핸드셰이크, 이후 데이터 전송 단계에서 발생할 수 있으므로 이 문구만으로 노드가 작동하지 않는다고 단정할 수 없습니다.
해결: 앞에 표시된 작업 이름과 주소를 확인하세요. dial 단계라면 네트워크 경로와 포트를 점검하고, 연결이 성립된 후 시간 초과가 발생했다면 핸드셰이크 매개변수와 원격 응답을 확인합니다.
오류: no such host
원인: 현재 이름 확인 과정에서 해당 도메인의 유효한 결과를 얻지 못했습니다. 철자 오류, 레코드 누락, 리졸버 동작 등이 원인일 수 있습니다.
해결: 먼저 노드 도메인의 철자를 확인하고 시스템 이름 확인 도구로 결과를 점검하세요. 커널이 별도의 DNS를 사용한다면 커널 DNS에 접근 가능한지와 규칙도 확인해야 합니다.
오류: address already in use
원인: 로컬 수신 대기 주소와 포트를 다른 프로세스가 이미 사용 중이거나 같은 프로그램이 중복 실행되었습니다.
해결: 해당 포트를 사용하는 프로세스를 확인하고 중복 실행 인스턴스를 종료하세요. 인바운드 포트를 바꾸면 앱의 프록시 설정도 함께 바꿔야 합니다. 커널 설정만 바꾸면 안 됩니다.
오류: failed to find an available destination
원인: 커널이 사용 가능한 연결 대상을 찾지 못했습니다. 이 오류는 여러 원인을 포괄하며 이름 확인 실패, 주소 접근 불가, 여러 차례의 연결 시도 실패 등이 함께 발생할 수 있습니다.
해결: 뒤이어 나오는 중첩 오류를 확인하고 구체적인 이름 확인 또는 연결 시도 원인에 따라 점검하세요. 이 한 줄만 보고 DNS 문제라고 단정하지 마세요.
TLS 핸드셰이크 실패: 인증서 이름, 시스템 시간, 전송 매개변수 확인
TLS 오류는 보통 연결이 보안 핸드셰이크 단계에 들어갔음을 뜻하지만, 올바른 서비스에 연결되었다는 보장은 없습니다. 잘못된 포트, 일치하지 않는 포워딩 설정, 중간 장비의 간섭 때문에 클라이언트가 예상과 다른 데이터를 받을 수 있습니다. 다른 보안 방식을 사용 중이라면 일반 TLS 인증서 오류의 해결 방법을 그대로 적용해서는 안 됩니다.
| 오류 문구 | 의미 | 점검 방법 |
|---|---|---|
x509: certificate has expired or is not yet valid | 인증서 유효 기간과 로컬 시스템 시간이 일치하지 않음 | 시스템 날짜, 시간, 시간대를 맞춘 뒤 서버 인증서의 유효 기간을 확인합니다. |
x509: certificate is valid for | 인증서가 적용되는 이름과 예상한 이름이 다름 | serverName/SNI와 인증서 도메인을 확인합니다. |
tls: first record does not look like a TLS handshake | 예상한 TLS 레코드와 다른 데이터를 받음 | 원격 포트에서 TLS를 제공하는지 확인하고 리버스 프록시 진입점을 점검합니다. |
EOF 또는 connection reset by peer | 스트림이 끝났거나 연결이 재설정됨. 원인은 하나로 특정되지 않음 | 발생 단계를 고려해 전송 유형, 경로, Host, 서버 로그를 확인합니다. |
서버 주소와 serverName은 항상 같지는 않습니다. 전자는 연결할 대상을 결정하고, 후자는 TLS 이름 검증 및 SNI에 사용됩니다. WebSocket에서는 경로와 HTTP Host도 각각 다른 역할을 합니다. 올바른 IP에 연결했다고 해서 이 값들이 모두 일치하는 것은 아닙니다. VMess와 VLESS의 인증 매개변수도 서버 설정과 일치해야 하지만, EOF 하나만 보고 어떤 항목이 잘못되었는지 판단할 수는 없습니다.
Windows 점검 예시: 로컬 10808과 원격 443을 따로 테스트
아래 예시에서는 클라이언트 설정의 로컬 HTTP 또는 혼합 인바운드 포트를 10808, 원격 서버 포트를 443으로 가정합니다. 진단을 위한 예시일 뿐 기본 설정과 같다는 보장은 없습니다. 실행하기 전에 실제 설정에 맞게 포트와 도메인을 바꾸세요. example.net은 문서용 예시 도메인으로 실제 노드가 아닙니다.
# PowerShell: 로컬 포트에서 수신 대기 중인지 확인
Get-NetTCPConnection -LocalPort 10808 -State Listen
# 시스템 DNS 이름 확인 결과 점검
Resolve-DnsName example.net
# 지정한 원격 TCP 포트 확인
Test-NetConnection -ComputerName example.net -Port 443
# HTTP 프록시를 제공하는 것으로 확인된 로컬 인바운드에만 사용
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://example.com/- 로컬 수신 대기가 없음: 먼저 커널 시작 로그, 설정 구문 오류, 포트 충돌을 확인하세요. 이때 브라우저 프록시를 반복해서 바꿔도 의미가 없습니다.
- 원격 TCP 테스트 실패: 이번 테스트에서 해당 TCP 연결이 성립되지 않았다는 뜻입니다. 주소, 네트워크, 방화벽, 서버의 수신 대기 상태를 구분해 확인해야 합니다. 이 명령은 UDP를 테스트하지 않습니다.
- 원격 TCP 테스트 성공: 해당 포트로 TCP 연결을 만들 수 있다는 것만 확인됩니다. TLS, VMess/VLESS 인증, 전송 설정이 올바르다는 뜻은 아닙니다.
- 명령 요청은 성공하지만 브라우저는 실패: 브라우저가 같은 프록시 진입점을 사용하는지, 시스템 프록시, 확장 프로그램 또는 앱별 프록시 설정이 어떻게 되어 있는지 우선 확인하세요.
로컬 포트가 SOCKS 인바운드만 제공한다면 curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/을 사용하세요. 여기서 socks5h는 대상 도메인 이름 확인을 프록시 측에 맡겨 로컬 이름 확인 경로와 구분하는 데 도움이 됩니다. 모든 DNS 요청이 자동으로 같은 방식으로 처리된다는 뜻은 아닙니다. 명령 테스트 시간도 로그 시간과 맞춰 다른 백그라운드 프로그램의 연결을 테스트 결과로 오인하지 않도록 하세요.
결론: 한 번에 변수 하나만 바꾸기
노드, 대상 주소, 프록시 진입점을 고정한 뒤 항목별로 확인하세요. 매번 설정 하나만 바꾸고 같은 요청을 반복해야 개선 원인이 포트, DNS, 핸드셰이크 매개변수 중 무엇인지 판단할 수 있습니다. 네트워크 경로가 우연히 바뀐 결과와도 구분할 수 있습니다.
로그 점검 중 자주 묻는 질문과 문의 정보 정리
로그에 warning이 계속 쌓이면 모든 연결이 실패한 건가요?
그렇지는 않습니다. 백그라운드 앱의 재시도나 취소된 연결 확인 요청도 경고로 기록될 수 있습니다. 먼저 일괄 속도 측정을 멈추고 대상 하나만 열어 시간을 기록한 뒤, 대상 주소나 연결 식별자를 기준으로 같은 요청의 맥락을 추출하세요.
시스템 프록시를 켰는데 로그에 브라우저 요청이 보이지 않아요.
먼저 액세스 로그가 켜져 있는지 확인한 뒤, 시스템 프록시가 가리키는 포트와 클라이언트 인바운드 포트가 일치하는지 점검하세요. 프록시를 명시한 curl 명령으로 비교할 수 있습니다. 일부 프로그램은 시스템 프록시를 사용하지 않으므로 설정 스위치만으로 적용 범위를 판단할 수 없습니다.
구독 업데이트는 시간 초과되지만 선택한 노드로 웹페이지는 열려요.
구독 가져오기는 별도의 HTTP 요청으로 점검하세요. 업데이트 작업이 직접 연결을 사용하는지 프록시를 사용하는지, 구독 서비스에 접근 가능한지, 구독 링크가 유효한지 확인합니다. 업데이트 실패를 점검하기 위해 아직 작동하는 노드 설정부터 삭제하지 마세요.
Android에서 연결 시간 초과가 발생했는데 Windows처럼 포트 정보가 보이지 않는 이유는 무엇인가요?
v2rayNG와 v2flyNG의 VPN 트래픽 처리 경로는 데스크톱 시스템 프록시와 다릅니다. 먼저 앱 안에서 로그를 확인하고 커널 버전, 네트워크 유형, 실패 시간을 기록하세요. 노드 도메인, 포트, 보안 설정을 대조하되 데스크톱의 로컬 인바운드 포트를 그대로 적용하지 마세요.
문의 내용을 정리할 때는 오류 한 줄을 잘라내는 것보다 앞뒤 로그를 연속해서 보존하는 편이 유용합니다. 아래 항목을 기록하고 민감 정보를 가린 사본을 로컬에 저장한 뒤 필요한 부분만 공유하세요. 구독 링크에는 액세스 토큰이 포함되는 경우가 많으므로 비밀번호라는 문구가 없더라도 공개해서는 안 됩니다.
- 운영체제 종류, 클라이언트 버전, 실제 커널 이름과 버전.
- 문제가 발생한 정확한 시간과 당시 시스템 프록시 또는 TUN 사용 여부.
- 재현 방법, 대상 유형, 매번 발생하는지 여부, 네트워크를 바꾼 뒤의 결과.
- 민감 정보를 가린 전체 오류 흐름, 로컬·원격 포트, 위 명령의 성공 또는 실패 결과.
- 최근 변경 사항. 예: 설정 업데이트, 커널 변경, DNS 조정, 네트워크 변경.
목표는 모든 로그를 없애는 것이 아니라 같은 요청의 각 단계에서 확인 가능한 결과를 얻는 것입니다. DNS, 인바운드, 라우팅 항목을 더 확인하려면 전체 설정 가이드를 참고하세요. 시작 또는 실행 환경 문제가 해결되지 않았다면 먼저 문제 해결 FAQ에서 기본 조건을 점검한 뒤 네트워크 연결을 분석하세요.