노드를 가져왔지만 연결되지 않거나 웹페이지가 열리지 않고 간헐적으로 연결이 끊기는 사용자에게 적합합니다. 전체 로그를 한 줄씩 번역하기보다 장애 발생 시간을 먼저 기록한 뒤, 인바운드 수신, 라우팅 매칭, 원격 아웃바운드의 세 단계에서 처음 나타난 이상을 찾고 단일 변수 테스트로 원인을 확인하는 것이 핵심입니다.
먼저 실제로 유용한 실행 로그 찾기
v2rayN, v2rayNG, v2flyNG는 모두 클라이언트 상태를 표시하지만, 화면 알림이 곧 코어 실행 로그를 의미하지는 않습니다. “시작 성공”, “테스트 완료” 같은 메시지는 작업이 실행되었다는 뜻일 뿐입니다. 요청이 어느 단계에서 멈췄는지 확인하려면 시간, 로그 수준, 연결 대상, 오류 흐름이 포함된 핵심 출력을 확인해야 합니다.
v2rayN 7.x를 예로 들면 먼저 메인 화면의 “정보” 영역을 확인할 수 있습니다. 기록 범위를 조정하려면 “설정”→“매개변수 설정”으로 이동해 코어 로그 수준 관련 옵션을 찾으세요. v2rayNG 1.10.x에서는 사이드 메뉴의 “로그”로 들어가며, 로그 수준은 일반적으로 “설정”의 고급 옵션에 있습니다. 세부 버전에 따라 명칭이 조금 다를 수 있지만, 구독 업데이트 알림만 보지 말고 코어 로그를 선택해야 합니다.
로그를 기록하기 전에 문제를 한 번 깔끔하게 재현하기
- 진행 중인 다운로드, 속도 측정, 백그라운드 동기화를 중지해 관련 없는 연결을 줄입니다.
- 현재 로그를 지우거나 테스트를 시작한 정확한 시간을 기억해 둡니다.
- 대상 노드를 시작하고 코어 상태가 안정될 때까지 기다린 다음, 명확한 웹 주소나 앱 기능 하나를 엽니다.
- 30초 안에 문제를 재현한 직후 작업을 중지하고, 장애 전후의 로그 약 20~50줄을 저장합니다.
- 사용한 노드, 시스템 프록시 상태, TUN 상태, 로컬 포트를 기록하되 전체 구독 주소, UUID, 비밀번호, 액세스 토큰은 공개하지 마세요.
인바운드·라우팅·아웃바운드 순서로 오류 흐름 읽기
일반적으로 요청은 브라우저나 다른 앱에서 시작해 로컬 SOCKS, HTTP 또는 TUN 인바운드로 코어에 들어온 뒤 라우팅 규칙과 매칭되고, 마지막으로 프록시 노드 또는 직접 연결 출구를 통해 전송됩니다. 로그의 오류는 여러 계층의 정보가 이어진 형태인 경우가 많습니다. 가장 바깥쪽은 “처리 실패”를 설명하고, 가장 안쪽에 원래 원인에 가까운 정보가 있습니다.
마지막 error만 검색하지 마세요. 먼저 같은 시간대에 새로운 연결이 나타났는지 확인한 다음, 바깥쪽에서 안쪽으로 오류 흐름을 따라가며 dial, lookup, authentication, routing, bind 같은 키워드를 찾습니다. 이후에 한꺼번에 나타나는 취소 메시지보다 처음 발생한 이상 징후가 진단에 더 중요합니다.
첫 번째 단계: 인바운드가 요청을 받았는가
웹페이지를 클릭한 뒤 로그에 새 연결이 전혀 추가되지 않는다면, 문제는 아직 코어에 도달하지 않았을 가능성이 큽니다. 이때는 시스템 프록시가 켜져 있는지, 브라우저가 별도 프록시를 사용하는지, 앱이 시스템 프록시를 무시하는지, 로컬 주소와 포트가 일치하는지 확인하세요. v2rayN의 일반적인 로컬 포트는 10808이지만, 업그레이드·설정 이전·수동 변경 후에는 “설정”→“매개변수 설정”에 표시된 실제 값을 기준으로 해야 합니다.
127.0.0.1에서 들어온 연결이 로그에 표시됨: 앱이 로컬 인바운드에 도달한 상태입니다.- 새 기록이 전혀 없음: 먼저 앱 프록시 설정과 시스템 프록시 상태를 확인하세요.
bind또는address already in use가 표시됨: 다른 프로세스가 로컬 수신 대기 포트를 사용 중입니다.- SOCKS 클라이언트가 HTTP 포트에 연결됨: 프로토콜 버전 오류가 발생하거나 연결이 즉시 거부될 수 있습니다.
두 번째·세 번째 단계: 어떤 출구가 선택되었는가
인바운드가 정상이라면 요청이 프록시, 직접 연결, 차단 중 어느 출구로 전달되었는지 확인하세요. 라우팅 규칙 순서가 잘못되면 노드 자체는 정상이어도 대상 도메인이 앞선 직접 연결 또는 차단 규칙에 가로막힐 수 있습니다. 그다음 아웃바운드 연결을 확인합니다. 이 단계에서는 도메인 확인, 서버 포트, 전송 방식, TLS 매개변수, 사용자 인증이 모두 처리됩니다.
| 확인 위치 | 일반적인 현상 | 우선 확인할 항목 |
|---|---|---|
| 인바운드 | 연결 기록이 없거나 수신 대기 실패 | 시스템 프록시, 10808 포트, 프로토콜 유형 |
| 라우팅 | 요청이 잘못된 출구로 전달됨 | 규칙 순서, 도메인 분류, 직접 연결 및 차단 규칙 |
| 아웃바운드 | 연결 시간 초과, 인증 실패 | 서버 주소, 포트, UUID, 전송 방식 및 TLS |
| 응답 단계 | 연결되지만 곧 끊김 | 원격 응답, 네트워크 전환, 유휴 연결 종료 |
rejected, timeout, invalid user의 의미
같은 문제라도 V2Ray와 Xray 코어, 전송 방식, 버전에 따라 표현이 조금씩 다를 수 있습니다. 판단할 때는 핵심 동작을 보세요. rejected는 어느 한 계층에서 연결을 명시적으로 거부했다는 뜻이고, timeout은 정해진 시간 안에 작업이 완료되지 않았다는 뜻이며, invalid user는 인증 정보가 일치하지 않음을 직접 가리킵니다.
오류: rejected
원인 및 해결:거부는 로컬 인바운드, 라우팅 차단, 원격 서버 등 여러 지점에서 발생할 수 있습니다. rejected 뒤에 나오는 모듈명을 먼저 확인하세요. blocked가 함께 표시되면 라우팅 규칙을 확인하고, authentication 또는 invalid user가 바로 뒤따르면 노드 인증 매개변수를 점검하세요.
오류: connection timeout
원인 및 해결:정해진 시간 안에 연결이 수립되지 않았다는 뜻입니다. 먼저 서버 주소와 포트를 확인한 뒤 현재 네트워크와 다른 사용 가능한 네트워크에서 각각 테스트하세요. 단일 노드에서만 시간 초과가 발생한다면 노드 매개변수나 원격 접속 가능성을 우선 확인합니다.
오류: dial tcp: i/o timeout
원인 및 해결:TCP 연결 시도가 제때 완료되지 않은 상태로, 대상 주소에 접근할 수 없거나 포트가 응답하지 않거나 네트워크 경로가 불안정할 때 흔히 발생합니다. UUID부터 바꾸지 말고 주소, 포트, 기본 네트워크부터 확인하세요.
오류: invalid user
원인 및 해결:서버가 클라이언트가 제출한 사용자 정보를 인식하지 못한 상태입니다. VMess 또는 VLESS 노드의 UUID, 추가 인증 매개변수, 구독 업데이트 시점을 확인하고 기존 노드와 새 설정을 섞어 쓰고 있지 않은지 점검하세요.
오류: failed to find an available destination
원인 및 해결:아웃바운드에서 사용할 수 있는 대상을 찾지 못한 상태입니다. 주소 확인 실패, 빈 대상 목록, 앞선 연결 시도의 전부 실패 등이 원인일 수 있습니다. 노드 주소 표기와 DNS 결과를 확인한 뒤 코어를 재시작해 다시 테스트하세요.
오류: context canceled
원인 및 해결:상위 작업이 현재 동작을 취소한 상태입니다. 노드 전환, 코어 중지, 앞선 연결 실패 때 흔히 발생하며 대개 후속 결과에 해당합니다. 더 앞선 시간대에서 timeout, rejected 또는 인증 오류를 찾아보세요.
오류: address already in use
원인 및 해결:사용하려는 로컬 수신 대기 포트가 이미 사용 중입니다. 중복 실행된 클라이언트를 종료하거나 “설정”→“매개변수 설정”에서 사용하지 않는 로컬 포트로 변경하세요. 예를 들어 10808을 비어 있는 포트로 바꾼 뒤 앱 프록시 설정도 함께 업데이트해야 합니다.
모든 rejected를 노드 장애로 단정하지 마세요
로그에는 광고 도메인, 로컬 네트워크 검색, 시스템 연결성 검사, 사용자가 직접 방문한 요청이 함께 기록될 수 있습니다. 차단 규칙이 의도대로 요청을 거부할 때도 rejected 유형의 정보가 나타납니다. 오류 시간이 실제 작업과 일치하고 관련 도메인 또는 IP가 이번 접속 대상일 때만 주요 단서로 판단하세요.
- 특정 도메인 하나만 실패하고 다른 웹사이트는 정상: 해당 도메인의 라우팅 분류와 DNS 결과를 확인하세요.
- 모든 프록시 요청이 시간 초과: 노드 주소, 서버 포트, 현재 네트워크를 확인하세요.
- 모든 노드에서 포트 사용 중 메시지 표시: 로컬 인바운드를 먼저 처리하고 노드를 하나씩 수정할 필요는 없습니다.
- 구독 업데이트 후 갑자기 invalid user 발생: 클라이언트가 실제로 업데이트된 노드를 사용 중인지 확인하세요.
단일 변수 테스트로 문제 범위 좁히기
효율적인 문제 해결에는 재현 가능한 비교가 필요합니다. DNS, 포트, 전송 방식, 라우팅 규칙을 한 번에 모두 바꾸면 연결이 복구되어도 어떤 변경이 효과가 있었는지 알 수 없습니다. 원래 설정을 복사해 보관하고 매번 변수 하나만 변경한 뒤 같은 대상으로 다시 테스트하는 방법이 더 안전합니다.
- 로컬 인바운드 확인:코어를 시작한 뒤 실제 설정 포트가 정상적으로 수신 대기 중인지 확인하고, 브라우저 요청이 로그에 들어오는지 관찰하세요.
- 노드 선택 확인:클라이언트 메인 화면에서 대상 노드를 다시 선택해, 한 노드를 편집하고 다른 노드를 사용 중인 상황을 피하세요.
- 라우팅 임시 단순화:설정에 미치는 영향을 분명히 확인한 뒤 기본 프록시 규칙으로 다시 테스트해 복잡한 분할 라우팅이 잘못된 판단을 일으키는지 확인하세요.
- 아웃바운드 매개변수 확인:서버 주소, 포트, VMess 또는 VLESS 유형, UUID, 전송 방식, TLS, 서버 이름을 항목별로 비교하세요.
- 네트워크 변경 비교:노드와 클라이언트 설정은 그대로 두고 네트워크만 전환하세요. 오류가 계속되는 시간 초과에서 정상 연결로 바뀐다면 현재 네트워크 경로의 문제일 가능성이 높습니다.
- 복원 및 검증:원인을 찾은 뒤 다른 임시 설정을 원래대로 되돌리고 자주 사용하는 대상 세 곳에 연속으로 접속해 최소 2분 동안 같은 오류가 반복되는지 관찰하세요.
포트 사용 중 오류를 판단하는 전체 과정
v2rayN을 시작한 뒤 웹페이지에 전혀 접속되지 않고, 로그에 원격 연결 오류보다 먼저 로컬 수신 대기 오류가 나타났다고 가정해 보겠습니다. 이때는 먼저 10808 포트를 처리해야 하며 노드를 바꾸거나 전송 매개변수를 수정해서는 안 됩니다. 일반적인 로그는 다음과 비슷한 형태로 나타날 수 있습니다.
failed to start inbound
listen tcp 127.0.0.1:10808: bind: address already in use중복 실행된 클라이언트 프로세스를 완전히 종료한 뒤 다시 시작하세요. 그래도 포트가 사용 중이면 “설정”→“매개변수 설정”에서 비어 있는 다른 로컬 포트를 선택하고 브라우저 또는 시스템 프록시도 같은 포트를 사용하도록 설정합니다. 변경 후에는 먼저 수신 대기 성공 로그가 나타나고, 이어서 로컬 장치에서 들어온 연결 기록이 나타나야 합니다. 요청이 코어에 들어온 뒤에야 라우팅과 아웃바운드를 계속 확인하면 됩니다.
자주 나타나는 로그 현상별 구체적인 대응
일부 장애는 하나의 오류 문구로만 나타나지 않고 “연결 기록은 있지만 웹페이지가 응답하지 않음”, “처음에는 정상인데 몇 분 후 시간 초과” 같은 복합적인 현상으로 나타납니다. 아래에서는 사용자가 자주 설명하는 상황별로 첫 번째 조치를 제시합니다. 조치 후에도 장애가 발생한 시간대의 로그를 다시 확인해야 합니다.
로그가 계속 스크롤될 때 방금 실패한 요청을 찾는 방법
먼저 로그를 지우고 백그라운드 다운로드를 종료한 다음 테스트 웹페이지 하나만 엽니다. 클릭한 시간을 기록하고 이후 30초 동안의 기록에서 대상 도메인, timeout, rejected, failed 또는 error를 검색하세요.
시작 성공으로 표시되지만 브라우저에 새 로그가 전혀 없을 때
v2rayN의 시스템 프록시 상태와 브라우저의 별도 프록시 설정을 확인하세요. 프록시를 수동으로 입력했다면 주소는 127.0.0.1이어야 하며 포트는 클라이언트의 현재 설정과 일치해야 합니다.
connection timeout이 특정 노드 하나에서만 발생할 때
네트워크는 그대로 두고 이미 정상 작동하는 다른 노드로 전환해 테스트하세요. 다른 노드가 정상이라면 문제 노드의 서버 주소, 포트, 전송 매개변수를 확인하고 구독을 업데이트한 뒤 노드를 다시 선택하세요.
노드 전환 후 context canceled가 다수 나타날 때
노드를 전환하면 기존 연결이 종료되므로 이런 기록은 대개 별도로 처리할 필요가 없습니다. 새 코어가 안정될 때까지 기다린 뒤 다시 테스트하고, 새로운 시간대에서 더 일찍 나타난 연결 시도 또는 인증 오류를 찾으세요.
v2rayNG에는 연결됨으로 표시되지만 앱에서 계속 시간 초과가 발생할 때
사이드 메뉴에서 로그를 열고 대상 앱의 요청이 표시되는지 확인하세요. 기록이 없으면 시스템 연결 권한과 앱 자체 프록시를 확인하고, 기록이 있으면 라우팅과 아웃바운드 단계에서 계속 원인을 좁히세요.
DNS 문제와 노드 문제를 구분하는 방법
로그에 도메인 확인 실패가 나타나고 이미 알고 있는 IP를 사용하는 다른 요청은 정상이라면 DNS 문제일 가능성이 높습니다. 노드 서버 자체가 도메인을 사용하는 경우 확인 실패가 아웃바운드 연결을 직접 차단합니다. 대상 도메인에서만 확인 실패가 발생한다면 DNS 분할 설정과 도메인 규칙도 확인해야 합니다. timeout이 보인다고 바로 DNS 문제로 단정하지 마세요. 포트에 접근할 수 없어도 시간 초과가 발생합니다.
lookup또는no such host가 표시됨: 먼저 DNS 설정과 노드 주소 표기를 확인하세요.- IP 확인 후
dial tcp시간 초과 발생: 포트와 네트워크 경로를 중점적으로 확인하세요. - TCP 연결 후 인증 오류 발생: UUID, 프로토콜 유형, 서버 측 매개변수를 확인하세요.
- 특정 도메인만 잘못된 출구로 연결됨: 라우팅 규칙 순서와 GeoSite 데이터가 최신인지 확인하세요.
라우팅 데이터가 오래되면 도메인 분류가 예상과 달라질 수 있지만, 일반적으로 invalid user를 만들지는 않습니다. 오류와 처리 범위를 대응시키면 불필요한 변경을 피할 수 있습니다. 인증 오류는 사용자 매개변수, 수신 대기 오류는 로컬 포트, 확인 오류는 DNS, 잘못된 규칙 매칭은 라우팅을 확인하세요.
다시 확인할 수 있는 장애 기록 저장하기
간헐적인 연결 끊김은 재시작 후 잠시 정상으로 돌아올 수 있어 처리하기 가장 어렵습니다. 마지막 오류 하나만 캡처하기보다 다음 재현 결과와 바로 비교할 수 있도록 구조화된 기록을 저장하세요. 클라이언트, 코어, 네트워크 환경, 노드 유형, 장애 시간, 첫 번째 이상 징후를 포함해야 합니다.
| 기록 항목 | 작성 예시 | 용도 |
|---|---|---|
| 클라이언트 및 버전 | v2rayN 7.x | 메뉴 위치와 기본 동작 판단 |
| 코어 유형 | Xray 또는 V2Ray | 로그 표현 차이 해석 |
| 로컬 인바운드 | 127.0.0.1:10808 | 앱이 올바른 포트에 연결되는지 확인 |
| 프로토콜 및 전송 | VLESS 및 TCP | 인증 및 전송 점검 범위 한정 |
| 재현 시간 | 14:32:10~14:32:40 | 많은 로그에서 해당 요청 찾기 |
| 첫 번째 이상 징후 | dial tcp: i/o timeout | 근본 원인과 후속 연쇄 오류 구분 |
설정 관리자에게 문제를 문의할 때는 위 환경 정보와 민감한 내용을 가린 오류 일부를 제공할 수 있습니다. 구독 주소, UUID, 비밀번호, 토큰, 전체 서버 주소, 개인적으로 방문한 도메인은 삭제하세요. 시간, 모듈명, 오류 유형, 포트만 남겨도 대부분의 판단에 필요한 정보를 제공할 수 있습니다.
- 먼저 원문을 복사한 뒤 민감한 정보를 가리세요. 그래야 스크린샷에서 중요한 맥락이 잘리는 일을 피할 수 있습니다.
- 오류 앞뒤로 최소 10줄을 남기고 어떤 작업을 수행했는지 적으세요.
- 문제가 안정적으로 재현되는지 간헐적인지, 네트워크 또는 노드를 전환했을 때의 비교 결과를 설명하세요.
- 수정 후 같은 작업을 반복해 원래 오류가 더 이상 나타나지 않는지 확인하세요. 화면에 “연결됨”으로 표시되는지만 확인해서는 안 됩니다.