실패한 요청 하나를 기준으로 시간, 대상 주소, 아웃바운드 태그, 하위 오류를 차례로 확인합니다. 구독을 가져왔지만 연결이 안 되거나 웹페이지가 열리지 않는 사용자를 위한 안내입니다. 로컬 리스너, 노드 연결, TLS 핸드셰이크, DNS 조회 문제를 구분하고 그래픽 클라이언트에서 하나씩 검증해 여러 설정을 한꺼번에 바꾸지 않도록 합니다.
먼저 로그 위치 확인: 클라이언트와 코어 로그 구분하기
‘클라이언트 작업 실패’와 ‘프록시 연결 실패’를 구분하세요. v2rayN은 구독 관리, 설정 생성, 코어 실행, 시스템 프록시 설정을 담당합니다. 실제 연결 처리는 Xray 또는 V2Fly 코어가 맡을 수 있습니다. 구독 다운로드 시간 초과가 노드 핸드셰이크 실패를 뜻하는 것은 아니며, 코어 실행 실패는 브라우저를 바꿔도 해결되지 않습니다.
v2rayN 메인 창 아래쪽의 로그 영역에서 시작 기록을 확인하고, 코어 이름과 버전, 실행 시간을 확인한 뒤 문제를 한 번 재현하세요. 버전에 따라 로그가 하단 탭이나 별도 창에 표시될 수 있고 메뉴 이름도 다를 수 있습니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 안드로이드는 메인 화면 메뉴에서 로그 페이지를 열 수 있으므로 데스크톱 메뉴 위치를 그대로 찾지 마세요.
- 구독 단계: 구독 업데이트 메시지를 확인해 주소 요청, 인증 또는 콘텐츠 파싱 중 어디서 실패했는지 살펴보세요. 전체 구독 링크를 공개하지 마세요.
- 시작 단계: 설정 읽기, 프로토콜 필드, 리스닝 포트, 코어 종료 정보를 확인하세요. 코어가 정상적으로 시작되지 않았다면 원격 웹사이트 문제를 먼저 살펴볼 필요는 없습니다.
- 접속 단계: 인바운드 요청, 라우팅 선택, 원격 연결, 응답 읽기 과정을 확인하세요. 오류가 방금 접속한 대상과 관련 있는지 대조하세요.
로그 레벨, 주소, 오류 흐름 이해하기
먼저 오류가 어느 계층에서 발생했는지 확인한 다음 로그 레벨을 살펴보세요. Xray와 V2Fly의 일반적인 로그 레벨은 debug, info, warning, error이며, none으로 관련 로그 출력을 끌 수도 있습니다. 접속 로그와 오류 로그가 항상 같은 경로로 출력되는 것은 아닙니다. accepted는 로컬 요청이 접수됐다는 뜻일 뿐, 원격 페이지가 정상적으로 응답했다는 의미는 아닙니다.
| 레벨 또는 기록 | 주요 용도 | 권장 조치 |
|---|---|---|
debug | 내부 처리 과정을 자세히 확인 | 짧게 재현할 때만 켜고 완료 후 원래대로 되돌리기 |
info | 시작 및 일부 실행 정보 확인 | 코어가 시작됐는지, 요청이 들어왔는지 먼저 확인 |
warning | 이상 또는 실패 상황 알림 | 대상 주소를 함께 보고 현재 접속에 영향이 있는지 판단 |
error | 심각도가 높은 오류 기록 | 설정 로드 및 리스닝 실패부터 확인 |
| 접속 기록 | 출발지, 대상, 라우팅 태그 표시 | 트래픽 진입 경로 확인용이며, 이것만으로 성공 여부를 판단할 수 없음 |
아래는 이해를 돕기 위한 형식 예시이며 실제 측정 결과가 아닙니다. 버전, 코어, 설정에 따라 필드 순서는 달라질 수 있습니다. 127.0.0.1:53124는 앱이 사용하는 임시 출발지 포트이므로 클라이언트 리스닝 포트를 53124로 바꾸면 안 됩니다. 대상 주소의 443은 이번 요청의 대상 포트이며 노드 서버 포트와 같다고 단정할 수 없습니다.
2026/08/14 10:15:30 from 127.0.0.1:53124 accepted tcp:example.com:443 [socks -> proxy]
[Warning] ... failed to process outbound traffic > ... dial tcp 192.0.2.10:443: connect: connection refused오류 흐름은 보통 바깥 계층의 처리 실패에서 시작해 하위 원인이 차례로 덧붙습니다. 먼저 끝부분의 구체적인 오류를 찾고, 어떤 대상과 아웃바운드에 해당하는지 거슬러 올라가세요. 예시의 192.0.2.10은 문서용 주소이므로 노드 주소로 입력하면 안 됩니다. 로그에 연결 ID가 있으면 같은 ID로 여러 줄을 연결하고, ID가 없다면 시간과 대상 주소를 기준으로 대조해 백그라운드 업데이트 요청을 브라우저 요청과 혼동하지 마세요.
연결 거부와 시간 초과: 오류가 난 주소부터 확인
connection refused가 보이면 먼저 콜론 앞의 주소를 확인하세요. 127.0.0.1:10808을 가리킨다면 앱이 이전 프록시 포트를 사용 중이거나 로컬 코어가 리스닝하지 않는 경우가 흔합니다. 노드 주소와 노드 포트를 가리킨다면 노드가 사용 가능한지, 구독의 포트가 바뀌었는지 확인하세요. 10808은 흔히 쓰이는 예시일 뿐이므로 현재 클라이언트의 실제 리스닝 값을 기준으로 판단해야 합니다.
오류: connect: connection refused
원인: 연결 시도가 거부 응답을 받았습니다. 대상 포트에서 서비스가 리스닝하지 않거나 네트워크 장비가 연결을 거부했을 수 있습니다.
해결 방법: 먼저 주소가 로컬인지 노드인지 구분하세요. 로컬 문제라면 리스닝 상태와 시스템 프록시를 확인하고, 노드 문제라면 구독을 업데이트한 뒤 사용 가능한 다른 노드와 비교해 보세요.
오류: i/o timeout
원인: 연결, 읽기 또는 쓰기 작업이 제한 시간 안에 끝나지 않았습니다. 이 메시지만으로 DNS 문제라고 단정할 수는 없습니다.
해결 방법: 앞부분의 모듈과 대상 주소를 확인해 연결 시도 중인지 데이터 읽기 중인지 판단한 다음, 같은 노드로 네트워크를 바꿔 비교해 보세요.
오류: bind: address already in use
원인: 로컬 리스닝 주소와 포트를 다른 프로세스나 클라이언트 중복 실행이 이미 사용 중입니다.
해결 방법: 중복 실행 중인 인스턴스를 종료하세요. 충돌이 계속되면 ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 포트 항목을 찾아 값을 바꾸고 저장한 뒤, 프록시를 수동 설정한 앱에도 변경 사항을 반영하세요.
Windows에서는 포트 충돌이 ‘일반적으로 각 소켓 주소는 한 번만 사용할 수 있습니다’와 같은 시스템 메시지로 표시될 수도 있습니다. 앞서 설명한 리스닝 충돌과 비슷한 의미입니다. 정체를 알 수 없는 시스템 프로세스를 바로 종료하거나 확인 없이 임의의 포트를 계속 시도하지 마세요.
판단 기준: 로컬 리스닝 실패라면 시작 단계부터 해결
코어가 10808 포트에 바인딩하지 못했다면 VMess, VLESS 또는 원격 DNS로 바꿔도 리스닝 충돌은 해결되지 않습니다. 시작 로그에서 바인딩 실패가 더 이상 나타나지 않도록 먼저 조치한 뒤 요청이 로그에 들어오는지 다시 테스트하세요.
핸드셰이크 실패: TLS와 전송 설정을 나눠 확인
핸드셰이크 오류는 연결이 수립된 뒤 나타나지만, 프로토콜 인증 단계까지 도달했다는 뜻은 아닐 수 있습니다. TLS 인증서 검증, 전송 경로, 사용자 인증은 서로 다른 확인 항목입니다. 모든 핸드셰이크 오류를 ‘비밀번호 오류’로 해석하거나 인증서 검증을 끄는 것을 일반적인 해결책으로 삼지 마세요.
오류: x509: certificate has expired or is not yet valid
원인: 인증서 유효 기간과 기기의 시간이 맞지 않을 수 있습니다. 기기 시계가 잘못됐거나 서버 인증서가 만료된 경우가 있습니다.
해결 방법: 먼저 시스템의 자동 시간 설정을 켜고 시간을 동기화한 뒤 다시 시도하세요. 시간이 정상인데도 오류가 계속되면 노드 제공자에게 인증서 처리를 요청하세요.
오류: remote error: tls: handshake failure
원인: 원격 서버가 TLS 핸드셰이크를 거부했습니다. 서버 이름, TLS 설정 또는 서버 측 정책이 원인일 수 있습니다.
해결 방법: 노드 편집 창에서 원본 설정과 대조해 TLS 사용 여부와 서버 이름 SNI를 확인한 다음, 최신 구독으로 다시 테스트하세요.
오류: websocket: bad handshake
원인: WebSocket 업그레이드 요청에 예상한 응답이 오지 않았습니다. 경로, Host 또는 리버스 프록시 진입 설정이 서로 맞지 않을 때 흔히 발생합니다.
해결 방법: 전송 방식, 경로, Host를 확인하세요. 경로 맨 앞의 슬래시와 원래 대소문자를 유지하고, SNI와 Host가 같은 필드라고 미리 가정하지 마세요.
- 먼저 프로토콜 확인: VMess와 VLESS는 서로 다른 프로토콜이므로 프로토콜 이름만 바꾼 채 나머지 설정을 그대로 사용하면 안 됩니다.
- 다음으로 전송 설정 확인: WebSocket, gRPC 등의 전송 설정은 서버와 일치해야 합니다. gRPC는 서비스 이름도 확인하세요.
- 마지막으로 보안 계층 확인: TLS와 REALITY는 각각 확인해야 할 필드가 다릅니다. REALITY 노드는 제공자가 안내한 공개 키, 짧은 ID, 서버 이름을 확인하고 일반적인 인증서 오류 해결 절차를 적용하지 마세요.
EOF 또는 unexpected EOF는 연결이 종료됐거나 데이터가 중간에 끊겼다는 뜻일 뿐, 이것만으로 인증 실패를 입증하지는 않습니다. 이 문구만 보인다면 앞뒤 로그를 함께 확인하고 전송 유형과 노드 상태를 대조하세요. 새 사용자 식별 정보를 계속 만들어 연결을 시도하지 마세요.
DNS 시간 초과: 노드 도메인과 접속 도메인 구분하기
같은 이름 조회 실패라도 발생한 위치에 따라 해결 방향이 다릅니다. 노드 주소가 도메인이라면 클라이언트가 먼저 노드 IP를 알아내야 합니다. 접속 대상이 도메인이라면 로컬 DNS, 코어 DNS 또는 원격 측에서 처리할 수 있습니다. 구체적인 동작은 설정에 따라 달라지므로 로그에 DNS가 보인다고 특정 공용 주소로 일괄 변경하지 마세요.
오류: lookup example.com: no such host
원인: 조회 시스템이 해당 도메인의 유효한 주소를 찾지 못했습니다. 이름 오타, DNS 레코드 부재 또는 현재 조회 경로의 비정상 응답이 원인일 수 있습니다.
해결 방법: 먼저 노드 도메인인지 웹페이지 도메인인지 확인하고, 철자와 현재 네트워크의 조회 결과를 살펴보세요. 모든 DNS 규칙을 바로 바꾸지는 마세요.
오류: context deadline exceeded
원인: 작업이 제한 시간을 초과했습니다. 앞선 로그에서 DNS 모듈이 원인이라고 확인된 경우에만 DNS 조회 시간 초과를 우선 점검하세요.
해결 방법: DNS 요청이 직접 연결되는지 프록시를 거치는지, 해당 경로에서 선택한 DNS 서버에 도달할 수 있는지 확인한 다음 관련된 DNS 설정만 변경하세요.
| 확인된 증상 | 우선 확인 항목 | 확인 방법 |
|---|---|---|
| 노드 도메인을 확인할 수 없음 | 노드 연결 전 도메인 조회 경로 | 네트워크를 바꾼 뒤 같은 노드로 재시도하고, 프로토콜은 동시에 바꾸지 마세요 |
| 일부 도메인만 열리지 않음 | 해당 도메인의 규칙과 조회 결과 | 실패한 도메인과 정상 도메인의 아웃바운드 태그 비교 |
| 프록시를 켠 뒤에만 DNS 실패 | DNS 아웃바운드 의존성 및 라우팅 루프 | 사용이 확인된 DNS 설정으로 되돌린 뒤 사용자 지정 규칙을 하나씩 활성화 |
일반 DNS는 UDP 53을, DNS over HTTPS는 TCP 443을 사용하는 경우가 많습니다. 포트에 연결할 수 있어도 조회 결과가 올바르다는 뜻은 아니며, 443 시간 초과가 반드시 웹페이지 접속 문제인 것도 아닙니다. 특히 ‘노드에 연결하려면 프록시로 노드 도메인을 먼저 조회해야 하지만, 프록시를 쓰려면 먼저 해당 노드에 연결해야 하는’ 순환 의존성을 주의하세요.
다섯 단계로 재검증: 한 번에 변수 하나만 변경
로그를 재현 가능한 작업 기록으로 활용하세요. 아래 데스크톱 절차는 v2rayN 기준이며, 설정 이름은 버전에 따라 다를 수 있으니 현재 화면의 항목을 기준으로 확인하세요. 코어 설정 파일을 직접 편집할 필요는 없습니다. 안드로이드를 사용한다면 같은 순서로 검증하고, 연결할 때 시스템 VPN 권한을 이미 허용했는지도 확인하세요.
-
현재 상태 기록
클라이언트와 코어 버전, 선택한 노드, 네트워크 유형, 오류 발생 시각을 적어 두세요. 메인 창의 로그 영역을 열고 기존 오류를 저장한 뒤 표시 내용을 지워 과거 기록이 섞이지 않게 합니다.
-
시작 결과 확인
‘설정’ → ‘매개변수 설정’에서 실제 리스닝 포트를 확인하세요. 더 자세한 정보가 필요하면 로그 레벨 항목을 찾아
info또는debug로 잠시 바꿉니다. 저장한 뒤 화면 안내에 따라 코어를 다시 시작하고, 설정 읽기나 포트 바인딩 오류가 없는지 먼저 확인하세요. -
트래픽 진입 경로 고정
트레이 메뉴의 ‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택하고 테스트 중에는 TUN을 꺼 두어 두 진입 방식이 겹치지 않게 하세요. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 적용됩니다. 별도로 프록시를 설정한 앱은 따로 확인해야 합니다.
-
요청 한 번 재현
시스템 프록시를 따르는 브라우저에서 같은 HTTPS 페이지를 열고 요청 시각을 기록한 뒤 로그에서 해당 대상을 찾으세요. 로그가 전혀 없다면 노드가 잘못됐다고 판단하기 전에 앱의 진입 경로와 로그 레벨부터 확인하세요.
-
항목 하나만 바꿔 재검증
오류 흐름을 참고해 노드 선택, SNI, DNS 경로 등 한 항목만 조정하세요. 같은 요청을 변경 전후로 비교하고, 정상화되면 상세 로그를 원래 레벨로 되돌린 뒤 마지막으로 정상 작동한 설정을 보존하세요.
접속 기록에서 요청이 direct로 처리됐지만 프록시를 거칠 것으로 예상했다면 노드 인증서가 아니라 라우팅 규칙과 규칙 순서를 확인하세요. 아웃바운드 태그는 직접 지정할 수 있습니다. proxy와 direct는 흔히 쓰이는 이름일 뿐이므로 실제 생성된 설정과 현재 화면에서 선택한 라우팅 모드를 기준으로 판단하세요.
판단 기준: 같은 요청의 단계별 변화를 비교
변경 후 ‘노드 연결 시간 초과’가 ‘TLS 핸드셰이크 실패’로 바뀌었다면 실패 위치가 달라진 것이지 문제가 해결된 것은 아닙니다. 새로 나타난 가장 하위 원인을 계속 확인하세요. 같은 페이지가 정상적으로 열리고 관련 요청에서 오류가 더는 반복되지 않아야 이번 검증이 끝난 것입니다.
로그 문제 해결 FAQ
로그에 빨간 오류가 없는데 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 해당 대상의 접속 기록이 있는지 확인하세요. 기록이 없다면 브라우저가 시스템 프록시를 따르는지, 프록시 포트가 일치하는지 확인합니다. 기록이 있다면 아웃바운드 태그와 뒤이어 발생한 오류를 살펴보세요. 로그 레벨이 너무 높거나 접속 로그가 꺼져 있어 기록이 적어 보일 수도 있습니다.
warning이 계속 나오는데 노드를 전부 삭제해야 하나요?
그럴 필요 없습니다. 먼저 백그라운드에서 네트워크를 사용하는 앱을 닫고 페이지 하나를 재현한 다음, 요청 시각과 같은 시간대의 경고를 찾으세요. 일부 오류는 취소된 요청이나 접속할 수 없는 대상에서 발생할 수 있으므로 경고 개수만으로 모든 노드에 문제가 있다고 판단하면 안 됩니다.
구독 업데이트 실패도 핸드셰이크 오류로 처리해야 하나요?
먼저 구독 다운로드와 노드 통신을 구분하세요. ‘구독 그룹’에서 업데이트 결과를 확인하고 구독 주소가 유효한지, 현재 네트워크 환경에 맞는 접속 방식인지 살펴보세요. 프록시를 통한 업데이트 옵션이 있다면 사용 가능한 프록시 연결이 이미 있을 때만 시도하세요. 아직 가져오지 않은 노드에 의존하지 않도록 주의해야 합니다.
지연 시간 테스트는 성공했는데 실제 접속은 왜 시간 초과되나요?
지연 시간 테스트는 연결이나 특정 테스트 대상만 확인할 수 있으며 모든 웹사이트, DNS, 전송이 정상이라는 뜻은 아닙니다. 같은 노드를 유지한 채 브라우저에서 실패한 페이지를 재현하고 도메인, 대상 포트, 아웃바운드 태그를 비교한 뒤 실제 요청의 오류 흐름을 확인하세요.
로그를 다른 사람에게 보여줄 때 어떤 정보를 남겨야 하나요?
클라이언트와 코어 버전, 오류 발생 시각, 프로토콜 및 전송 유형, 포트, 전체 오류 흐름은 남기세요. 민감한 주소를 가릴 때는 ‘노드 도메인’, ‘접속 도메인’처럼 일관된 표시를 사용하고 서로 다른 대상을 같은 이름으로 덮지 마세요. 구독 링크와 사용자 인증 정보는 스크린샷에 포함하지 마세요.