V2Ray 실행 로그 확인 방법: connection refused 등 주요 오류의 의미와 문제 해결 절차

먼저 로그가 기록한 연결 단계를 확인하세요

프록시 요청은 클라이언트가 웹페이지를 원격 노드에 바로 전달하는 방식이 아닙니다. v2rayN에서 흔히 사용하는 로컬 SOCKS 포트 127.0.0.1:10808을 예로 들면, 브라우저나 다른 앱이 먼저 로컬 인바운드에 연결하고, 코어가 노드 도메인을 확인한 다음 TCP 또는 UDP 연결을 만들고 TLS 또는 REALITY 핸드셰이크를 수행합니다. 마지막으로 VMess, VLESS 등의 프로토콜 인증이 진행됩니다. 어느 한 단계라도 실패하면 화면에는 모두 “연결 실패”로 표시될 수 있습니다.

따라서 로그 끝부분의 단어 하나만 잘라 보지 마세요. “지연 시간 테스트”를 누르거나 웹페이지를 열었거나 설정을 시작한 시점을 먼저 찾은 뒤, 위쪽으로 10~30줄을 확인하세요. 반복되는 retry와 failed to process outbound traffic은 상위 단계의 요약일 뿐인 경우가 많습니다. 실제 원인은 앞쪽의 dial, lookup, handshake 또는 authentication 줄에 있습니다.

액세스 로그는 요청이 코어에 들어왔는지 확인하는 데 사용하며, 대상 도메인·대상 포트·인바운드 태그·선택된 아웃바운드 태그 등이 기록됩니다. 오류 로그는 연결이 어느 단계에서 중단됐는지 보여줍니다. 액세스 로그에 새 기록이 전혀 없다면 먼저 시스템 프록시, TUN 또는 앱 자체의 프록시 설정을 확인하세요. 액세스 로그에 대상 주소가 나타난 뒤 오류 로그에서 연결 실패가 보고된다면 노드 주소·포트·네트워크 경로를 중점적으로 점검해야 합니다.

로그 레벨을 설정하고 유효한 맥락을 남기세요

로그 레벨은 일반적으로 debug, info, warning, error, none으로 나뉩니다. 평소에는 warning 또는 error를 사용하면 출력량을 줄일 수 있습니다. 연결 문제를 확인할 때는 먼저 info로 바꾸고, 핸드셰이크 매개변수나 라우팅 적용 여부를 확인할 수 없을 때만 일시적으로 debug를 사용하세요. 점검이 끝나면 원래 레벨로 되돌려 로그 파일이 계속 커지지 않도록 해야 합니다.

v2rayN 7.x를 예로 들면 「설정」→「매개변수 설정」→「Core 유형」에서 현재 노드가 Xray 코어를 사용하는지 V2Fly 코어를 사용하는지 먼저 확인하세요. 그런 다음 메인 화면의 로그 영역에서 코어를 다시 시작한 뒤 출력 내용을 확인합니다. 로그 레벨이나 Core 유형을 변경한 후에는 현재 설정을 중지하고 다시 시작해야 하며, 기존 프로세스에는 새 매개변수가 자동으로 적용되지 않습니다.

1. 테스트 시간을 고정하세요

   현재 로그의 마지막 시간을 지우거나 기억한 뒤, 10초 안에 “실제 연결 지연 시간 테스트”를 한 번만 실행하거나 테스트 페이지를 한 번만 여세요.

2. 코어 유형을 확인하세요

   v2rayN 7.x에서 「설정」→「매개변수 설정」→「Core 유형」을 열고 노드가 실제로 사용하는 코어를 확인하세요. 잘못된 프로세스의 로그를 읽지 않도록 주의합니다.

3. 로그 레벨을 높이세요

   먼저 info로 한 번 재현하세요. 라우팅·핸드셰이크·DNS 세부 정보가 보이지 않을 때만 debug로 변경합니다.

4. 코어를 다시 시작하세요

   현재 서비스를 중지한 뒤 다시 시작하고, 새 로그에 127.0.0.1:10808 또는 실제 설정 포트가 수신 대기 중이라는 내용이 나타나는지 확인하세요.

5. 전체 로그 구간을 저장하세요

   오류 전후로 각각 10~30줄을 남기고 노드 프로토콜·전송 방식·포트·재현 동작도 함께 기록하세요.

생성된 코어 설정을 직접 확인해야 한다면 최상위 log 객체를 살펴볼 수 있습니다. 아래 예시는 오류와 액세스 기록을 표준 출력으로 보내며, 실제 파일 위치는 클라이언트가 관리합니다. 클라이언트가 생성한 임시 설정을 직접 수정하면 다음 시작 때 덮어쓰일 수 있으므로, 가급적 클라이언트 설정을 사용하세요.

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "info"
  }
}

안드로이드의 v2rayNG 1.10.x와 v2flyNG도 같은 방식으로 확인합니다. 대상 설정을 시작한 뒤 메인 화면 메뉴에서 로그 페이지로 이동하고 즉시 문제를 재현하세요. 시스템이 백그라운드 프로세스를 제한할 수 있으므로 앱을 전환한 뒤 로그 갱신이 멈춘다면 클라이언트를 포그라운드에 둔 상태로 한 번 테스트하세요. “새 로그가 없다”는 이유만으로 노드가 정상이라고 판단해서는 안 됩니다.

오류 원문으로 네트워크와 포트 문제를 찾으세요

connection refused는 TCP 연결이 특정 주소까지 도달했지만 대상 포트가 연결을 적극적으로 거부했다는 뜻입니다. 단순한 시간 초과와는 다릅니다. 거부는 대개 빠르게 반환되며, 서버 프로세스가 해당 포트에서 수신 대기하지 않거나 포트를 잘못 입력했거나 도메인이 잘못된 호스트로 확인됐거나 로컬 인바운드 포트를 원격 포트로 잘못 사용한 경우에 발생합니다.

context deadline exceeded는 작업이 제한 시간 안에 완료되지 않았다는 뜻이며, DNS 조회·TCP 연결·TLS 핸드셰이크·원격 응답 단계에서 발생할 수 있습니다. 이 한 줄만으로 노드가 고장 났다고 단정할 수 없으므로 앞부분에 dial tcp, lookup, TLS handshake 같은 구체적인 대상이 표시되는지 확인하세요.

시간 초과 위치를 판단할 때는 소요 시간을 비교해 보세요. LAN의 포트 충돌은 보통 시작 후 1초 안에 나타납니다. 원격 포트 거부도 수백 밀리초에서 수초 안에 반환되는 경우가 많습니다. 약 10초를 연속으로 기다린 뒤 deadline exceeded가 나타난다면 네트워크 경로의 패킷 손실, 방화벽의 무응답 차단 또는 핸드셰이크 단계의 무응답일 가능성이 더 큽니다. 시간 차이만으로 결론을 내릴 수는 없지만 점검 순서를 정하는 데 도움이 됩니다.

invalid user 및 핸드셰이크 인증 오류 해결

invalid user, invalid account 또는 인증 실패 메시지는 대개 네트워크 연결이 프로토콜 처리 단계까지 도달했지만 클라이언트가 제출한 인증 정보가 서버 설정과 일치하지 않는다는 뜻입니다. VMess에서는 UUID, 서버 시간, 노드 사용 중지 여부를 중점적으로 확인하고, VLESS에서는 UUID, 암호화 필드, Flow, 보안 방식을 확인하세요. 노드 정보를 복사할 때 공백 하나가 추가되어도 인증 매개변수가 무효화될 수 있습니다.

VMess는 시스템 시간에 민감한 편입니다. 데스크톱이나 안드로이드 기기의 시간이 크게 어긋나면 주소와 포트가 정확해도 인증을 완료하지 못할 수 있습니다. 시스템의 자동 날짜·자동 시간·자동 시간대를 켠 뒤 클라이언트를 다시 시작하세요. 화면에서 분만 수동으로 맞추는 것으로는 충분하지 않으며, 시간대와 초 단위 오차도 함께 보정해야 합니다.

WebSocket, gRPC 또는 REALITY를 사용할 때는 인증 매개변수뿐 아니라 전송 계층도 확인해야 합니다. WebSocket에서는 경로 불일치, Host 불일치, HTTP 404 응답이 자주 발생합니다. gRPC에서는 serviceName을 확인하고, REALITY에서는 serverName·공개 키·shortId·지문을 확인하세요. 주소에 연결된다는 것은 TCP 경로가 존재한다는 뜻일 뿐, 이 필드들이 올바르다는 의미는 아닙니다.

• VMess: UUID, alterId, 암호화 방식, 시스템 시간, 전송 유형, TLS 설정을 확인하세요.
• VLESS: UUID, Flow, 전송 유형, 보안 방식, 서버 이름을 확인하세요.
• WebSocket: path와 Host를 확인하세요. 경로의 슬래시와 대소문자는 서버 설정과 일치해야 합니다.
• gRPC: serviceName을 확인하고 노드 메모나 도메인을 이 필드에 입력하지 마세요.
• REALITY: serverName·공개 키·shortId·지문·Flow의 조합을 확인하세요. 그중 한 필드만 따로 바꾼 뒤 그대로 재사용하지 마세요.

노드 장애·구독 문제·라우팅 분할을 구분하세요

같은 구독의 모든 노드가 동시에 실패한다면 먼저 로컬 환경, 구독 업데이트 결과, DNS, 시스템 시간을 확인하세요. 하나의 노드만 실패한다면 해당 노드의 주소·포트·계정 상태가 변경됐을 가능성이 더 큽니다. 노드 테스트는 통과하지만 특정 웹사이트만 열리지 않는다면 구독을 반복해서 다시 가져오기보다 라우팅 규칙·DNS 분할·대상 사이트 연결을 확인해야 합니다.

라우팅 문제의 전형적인 특징은 로그에 대상 도메인이 이미 나타났지만 예상과 다른 아웃바운드 태그가 선택되는 것입니다. 예를 들어 프록시로 보내야 할 도메인이 direct로 전송되거나 LAN 주소가 프록시 아웃바운드로 전송될 수 있습니다. 규칙을 수정한 뒤에는 설정을 다시 불러오고 같은 대상의 아웃바운드 태그를 다시 확인하세요. 클라이언트 상태 아이콘만 봐서는 안 됩니다.

구독 업데이트 성공은 클라이언트가 구독 응답을 받았다는 뜻일 뿐, 구독에 포함된 모든 노드에 연결할 수 있다는 의미는 아닙니다. 업데이트 후 노드 수·업데이트 시간·주요 필드가 변경됐는지 확인하세요. 업데이트 후 목록이 비어 있다면 먼저 구독 그룹의 필터 조건을 확인하고, 기존 노드가 계속 남아 있다면 올바른 구독 그룹이 업데이트됐는지 확인하세요.

정해진 순서로 최종 점검을 완료하세요

효율적인 문제 해결은 무작위 설정을 계속 시도하는 것이 아니라 순서를 지키는 데 달려 있습니다. 먼저 코어가 로컬 포트에서 수신 대기하는지 확인하고, 요청이 인바운드에 들어왔는지 확인한 다음 DNS·원격 연결·전송 핸드셰이크·프로토콜 인증을 점검하세요. 앞 단계가 통과되어야 다음 단계의 로그도 분석할 가치가 있습니다.

예를 들어 로그에 먼저 accepted tcp:example.com:443이 나타난 뒤 노드 주소에 대한 connection refused가 나타난다면 앱에서 로컬 인바운드까지의 경로는 정상입니다. 이때는 시스템 프록시를 계속 조정할 필요 없이 원격 노드 포트를 확인해야 합니다. 반대로 웹페이지를 열었는데 액세스 로그가 전혀 늘지 않는다면 브라우저나 시스템이 실제로 127.0.0.1:10808을 가리키는지 먼저 확인하세요.

1. 수신 대기를 확인하세요

   클라이언트를 시작한 뒤 address already in use가 없는지 확인하고 로컬 인바운드 포트가 정상적으로 수신 대기하는지 확인하세요.

2. 요청을 확인하세요

   고정 테스트 페이지를 열고 액세스 로그에 대상 도메인과 443 포트가 나타나는지 확인하세요. 기록이 없다면 시스템 프록시 또는 앱 프록시를 점검하세요.

3. 이름 확인을 확인하세요

   lookup, no such host, 노드 도메인을 검색해 DNS가 사용 가능한 주소를 반환했는지 확인하세요.

4. 연결을 확인하세요

   refused, timeout, unreachable을 기준으로 포트 거부·연결 시간 초과·네트워크 연결 불가를 구분하세요.

5. 핸드셰이크를 확인하세요

   TLS·REALITY·WebSocket·gRPC 매개변수를 확인한 뒤 VMess·VLESS 인증 필드를 점검하세요.

6. 로그 레벨을 복원하세요

   문제 확인이 끝나면 debug를 warning 또는 기존 설정으로 되돌리고 코어를 다시 시작하세요.

다른 사람에게 문제 해결 정보를 제공할 때는 클라이언트 이름과 버전 계열, 코어 유형, 노드 프로토콜, 전송 방식, 오류 발생 시간, 전체 로그 구간을 포함하세요. 계정 자격 증명·구독 주소·UUID·공개 키 외의 비공개 연결 정보는 필요한 만큼 가린 뒤 공유해야 합니다. 단, 오류 전후의 단계 표시·대상 포트·아웃바운드 태그는 삭제하지 마세요.