먼저 요청이 실패한 시점의 로그를 보관한 뒤, 로컬 리스너, 도메인 조회, 원격 연결, 사용자 인증 순서로 원인을 확인하세요. 실행 실패, 연결 시간 초과, 웹페이지 접속 불가 문제를 겪는 사용자를 위해 v2rayN과 v2rayNG의 로그 확인 위치, V2Ray/Xray 로그 수준, 오류별 다음 점검 항목을 안내합니다.
실패 상황을 다시 만든 뒤 해당 로그 찾기
문제가 발생한 시간을 기록하고 다운로드와 백그라운드 업데이트를 잠시 멈춘 다음, 확인할 페이지 하나만 여세요. 로그에는 여러 연결 기록이 뒤섞일 수 있습니다. 시간과 대상 주소를 기준으로 삼지 않으면 백그라운드 프로그램의 실패를 현재 웹페이지 문제로 착각하기 쉽습니다. 마지막 한 줄만 캡처하지 말고 오류 전후 약 10~20줄을 보관하면 원인 흐름을 파악하기 좋습니다.
- v2rayN 데스크톱: 먼저 메인 창의 실행 정보나 로그 영역에서 클라이언트 시작 메시지와 코어 출력을 구분해 확인하세요. 로그 상세도를 높이려면 「설정」→「매개변수 설정」으로 이동해 코어 또는 로그 관련 항목을 찾으세요. 버전에 따라 메뉴 그룹 이름이 다를 수 있으므로 화면의 ‘로그 수준’ 또는
loglevel항목을 기준으로 확인하면 됩니다. - v2rayNG Android: 메인 화면 메뉴에서 「로그」를 열고 서비스를 시작한 뒤 문제를 다시 재현하세요. 현재 버전의 「설정」에 로그 수준 항목이 있다면 잠시 수준을 높이고 서비스를 다시 시작하세요. Android VPN 권한 안내를 코어 오류로 오해하지 않도록 주의하세요.
- 사용자 지정 V2Ray/Xray 설정: 실제 실행 설정의
log섹션을 확인하세요.error는 오류 로그 파일을,access는 액세스 로그 파일을 지정합니다. 파일을 지정하지 않은 경우 출력 위치는 실행 방식과 클라이언트의 콘솔 출력 처리 방법에 따라 달라집니다. - 로그 파일을 찾을 수 없는 경우: 먼저 파일 기록이 설정되어 있는지 확인하세요. 데스크톱 클라이언트의 실행 파일 폴더, 작업 폴더, 설정 폴더는 서로 다를 수 있으므로 로그가 모두 설치 폴더에 있다고 단정할 수 없습니다. 상대 경로도 실제 작업 폴더를 기준으로 확인하세요.
loglevel 설정: 먼저 info, 필요할 때만 잠시 debug
loglevel은 로그의 상세 수준을 뜻합니다. 먼저 info로 바꾸고 저장한 뒤 코어를 재시작해 문제를 다시 재현하세요. 정보가 부족할 때만 잠시 debug를 사용하세요. 로그 수준은 네트워크 모드가 아닙니다. 수준을 높여도 연결이 복구되거나 프록시가 더 많은 앱을 자동으로 처리하지는 않습니다.
| 수준 | 사용 상황 | 확인할 내용 |
|---|---|---|
debug | 복잡한 문제를 짧은 시간 동안 추적할 때 | 상세한 상황 정보. 확인 가능한 세부 내용은 코어와 버전에 따라 다릅니다. |
info | 일반적인 연결 문제를 점검할 때 | 시작, 연결, 라우팅 관련 정보 |
warning | 평소에 이상 징후를 살펴볼 때 | 경고 및 그보다 심각한 문제. 일반 연결 정보는 적게 표시됩니다. |
error | 오류만 확인할 때 | 요청이 코어로 들어오는 전체 과정을 확인하지 못할 수 있습니다. |
none | 해당 로그 출력 끄기 | 문제를 재현하는 중에는 사용하기 적합하지 않습니다. |
아래 예시는 기존 최상위 설정에 추가할 수 있는 로그 설정이며 전체 프록시 설정이 아닙니다. 첫 점검부터 디렉터리 권한 문제가 섞이지 않도록 파일 경로는 지정하지 않았습니다. 클라이언트가 설정을 생성하는 경우에는 인터페이스에서 수정하는 것이 좋습니다. 생성된 파일을 직접 편집하면 다음 실행 때 변경 사항이 덮어써질 수 있습니다.
{
"log": {
"loglevel": "info"
}
}- 파일로 기록해야 한다면
error또는access에 현재 프로세스가 쓸 수 있는 경로를 지정하고 상위 폴더가 이미 있는지 확인하세요. - 추가 권한이 필요한 시스템 폴더에 로그를 기록하지 마세요. 로그 기록을 위해 모든 프로그램을 계속 관리자 권한으로 실행하는 것도 피해야 합니다.
- 문제 재현을 마치면 평소 사용하는 로그 수준으로 되돌리고 더 이상 필요하지 않은 디버그 파일을 삭제하세요. 액세스 로그에는 대상 도메인, 주소, 연결 시간이 포함될 수 있습니다.
오류 흐름 파악하기: 연결이 어느 단계에서 멈췄는지 확인
코어는 실제로 프록시 트래픽을 처리하는 프로그램입니다. 인바운드는 로컬 앱의 요청을 받고, 아웃바운드는 요청을 직접 연결할 대상이나 프록시 서버로 전달합니다. 설정을 하나씩 바꿔 보기보다 요청이 인바운드에 도달했는지 먼저 확인하고, 아웃바운드 선택과 네트워크 핸드셰이크를 살펴보는 편이 효과적입니다.
오류 한 줄에는 여러 원인이 이어져 표시되는 경우가 많습니다. 바깥쪽에는 “아웃바운드 트래픽 처리 실패”라고 나오고, 안쪽에 connection refused 또는 i/o timeout이 표시될 수 있습니다. 먼저 가장 안쪽의 구체적인 원인을 읽고 어떤 주소에 연결했는지 확인하세요. 로그에 표시된 대상은 프록시 서버일 수도 있고, 직접 연결하는 웹사이트나 DNS 서버일 수도 있습니다. 모두 노드 문제로 단정하면 안 됩니다.
이 숫자는 연결의 역할을 구분하기 위한 참고값일 뿐, 일괄적으로 변경하라는 설정이 아닙니다. 실제 수신 대기 포트는 클라이언트 설정을, 원격 포트는 서버에서 제공한 정보를 기준으로 확인하세요. 로그에 443이 표시된다는 사실만으로 해당 연결이 프록시를 거치는지 알 수는 없습니다.
연결 오류: 거부, 시간 초과, 사용 가능한 대상 없음
오류: connection refused
원인: 연결이 명시적으로 거부된 상태입니다. 대상 포트에서 수신 대기 중인 서비스가 없거나 방화벽이 연결을 적극적으로 거부할 때 흔히 발생합니다.
해결: 먼저 대상 주소를 확인하세요. 127.0.0.1:10808이라면 로컬 코어가 실행 중인지와 해당 포트의 수신 상태를 확인하세요. 원격 주소라면 노드 포트와 서버의 수신 상태를 확인하세요.
오류: i/o timeout
원인: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 완료되지 않았습니다. 연결 시도, TLS 핸드셰이크, 응답 대기 중에 발생할 수 있습니다.
해결: 오류 접두어를 보고 시간 초과가 발생한 단계를 확인한 다음, 같은 노드로 Wi-Fi와 모바일 네트워크를 바꿔 비교하세요. 모든 시간 초과를 DNS 문제로 단정하지 마세요.
오류: failed to find an available destination
원인: 현재 대상에 연결을 시도했지만 사용 가능한 연결을 만들지 못했습니다. 보통 여러 오류를 요약해 표시하는 메시지이므로 이것만으로 근본 원인을 특정하기는 어렵습니다.
해결: 같은 오류 흐름에서 이름 조회 실패, 연결 거부, 시간 초과 메시지를 더 찾아 도메인, 포트, 네트워크 경로를 각각 확인하세요.
오류: no such host
원인: 해당 조회 시스템에서 도메인의 유효한 주소를 찾지 못했습니다. 주소 오타가 있거나 이름 조회 요청이 잘못된 경로로 전달됐을 수도 있습니다.
해결: 로그에 나온 도메인이 노드 주소인지 대상 웹사이트 주소인지 먼저 확인한 뒤, 실제로 사용 중인 DNS 서버와 분기 라우팅 규칙을 점검하세요.
v2rayN을 사용하는 Windows 사용자라면 예시의 로컬 포트가 수신 대기 중인지 먼저 확인할 수 있습니다. 아래 명령은 TCP 상태만 조회하며 시스템 설정을 변경하지 않습니다. 결과가 없다고 원격 노드에 문제가 있다고 볼 수는 없습니다. 먼저 클라이언트에서 시작 오류를 확인하고 포트가 실제로 10808인지 점검하세요.
Get-NetTCPConnection -State Listen -LocalPort 10808해당 포트에서 SOCKS 프록시를 제공하는 것이 확인되면 명시적 프록시 요청을 한 번 실행하세요. socks5h는 대상 도메인을 프록시 측에서 조회한다는 뜻입니다. 여기서 15초는 테스트를 위해 직접 지정한 제한 시간이며 코어의 기본 시간 초과 값이 아닙니다.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 15 --max-time 30 -I https://example.com/- 로컬에서 즉시 연결 거부: 코어가 실행되지 않았거나 포트가 잘못 입력됐거나 프록시 유형이 맞지 않는 문제부터 해결하세요.
- 요청이 코어에 들어간 뒤 원격 연결 시간 초과: 노드 주소, 네트워크 연결 가능 여부, 핸드셰이크 매개변수를 계속 확인하세요.
- 명령은 성공하지만 브라우저는 실패: 시스템 프록시, 브라우저 자체 프록시 설정, 관련 라우팅을 확인하세요. 먼저 클라이언트를 다시 설치할 필요는 없습니다.
인증 및 TLS 오류: 설정을 확인하고 검증을 건너뛰지 마세요
TCP 연결이 성립했다는 것은 포트에 연결할 수 있다는 뜻일 뿐, 프록시 프로토콜 인증에 성공했다는 뜻은 아닙니다. UUID는 일부 프록시 프로토콜에서 사용자를 식별하는 자격 정보입니다. TLS는 서버 신원을 확인하고 전송 내용을 암호화하는 방식입니다. 두 문제는 따로 점검해야 합니다. 로그 수준을 바꾸거나 로컬 포트를 변경해도 대개 해결되지 않습니다.
오류: invalid user
원인: 사용자 인증에 실패했습니다. 이 메시지는 서버 로그에 표시되는 경우가 많으며, 자격 정보 불일치, 사용자 삭제, 프로토콜 매개변수 불일치 등이 원인일 수 있습니다.
해결: 서버와 클라이언트의 사용자 식별 정보 및 프로토콜을 확인하세요. VMess라면 시스템 시간도 점검하고, 필요하면 관리자에게 같은 시각의 서버 로그를 확인해 달라고 요청하세요.
오류: x509: certificate has expired or is not yet valid
원인: 인증서 유효 기간과 현재 시스템 시간이 맞지 않습니다. 인증서가 만료됐거나 기기의 날짜가 잘못됐을 수 있습니다.
해결: 먼저 기기에서 날짜와 시간 자동 설정을 켠 다음, 서버 관리자에게 인증서 유효 기간과 배포 상태를 확인해 달라고 요청하세요.
오류: x509: certificate signed by unknown authority
원인: 현재 환경에서 신뢰할 수 있는 인증서 체인을 구성하지 못했습니다. 중간 인증서 누락, 자체 서명 인증서, 네트워크에서의 인증서 교체 등이 원인일 수 있습니다.
해결: 서버의 전체 인증서 체인과 시스템의 신뢰 상태를 확인하고 관리자에게 올바른 인증서가 무엇인지 확인하세요. 검증을 끄는 방법을 장기적인 해결책으로 사용하지 마세요.
오류: EOF
원인: 읽기가 완료되기 전에 연결이 종료됐습니다. 이 메시지만으로는 인증 실패라고 단정할 수 없습니다.
해결: 앞뒤 로그를 함께 확인해 TLS, 전송 방식, 서버 응답을 점검하세요. 클라이언트에 이 한 줄만 있다면 관리자에게 해당 시각의 서버 기록을 요청하세요.
- 먼저 구독을 업데이트한 뒤 사용할 설정을 다시 선택하세요. 구독 업데이트는 목록을 새로 고치는 작업이며 현재 연결이 자동으로 바뀌는 것은 아닙니다.
- 서버 주소, 포트, 프로토콜, 사용자 식별 정보, 전송 방식, TLS 설정을 하나씩 확인하세요. WebSocket을 사용하는 경우에만 경로와 Host도 확인하세요. 다른 전송 방식을 쓴다면 이 항목을 그대로 적용하지 마세요.
- TLS 핸드셰이크에서 서버 이름으로 전달하는 SNI를 확인하세요. SNI는 연결에 사용하는 IP 주소와 다를 수 있으므로 서버 설정에 맞춰야 합니다.
- REALITY를 사용하는 경우 서버 요구 사항에 따라 공개 키, 짧은 ID, 서버 이름을 확인하세요. 일반 인증서 오류의 해결 절차를 그대로 적용할 수 없습니다.
시작 실패: 포트 충돌과 설정 구문부터 확인
서비스를 시작하자마자 종료된다면 웹페이지를 테스트하기 전에 시작 로그부터 확인하세요. 코어가 정상적으로 수신 대기하지 못하면 브라우저의 프록시 연결 실패는 그에 따른 결과일 뿐입니다. 노드를 바꿔도 로컬 설정 구문 오류나 수신 주소 충돌은 해결되지 않습니다.
오류: address already in use
원인: 다른 프로세스가 해당 수신 주소와 포트를 사용 중이거나 코어가 중복 실행됐습니다.
해결: 포트를 점유한 프로세스를 확인하고 중복 실행된 인스턴스를 정상 종료하세요. 로컬 수신 포트를 변경한다면 해당 포트를 사용하는 앱의 설정도 함께 바꾸세요.
오류: failed to load config files
원인: 설정을 불러오지 못했습니다. 경로에 접근할 수 없거나 JSON 구문이 잘못됐거나 현재 코어에서 지원하지 않는 필드가 있을 수 있습니다.
해결: 뒤이어 표시되는 파일명, 필드명, 줄 및 열 정보를 확인하세요. 마지막으로 정상 작동했던 설정을 복원하고 코어와 설정이 호환되는지도 확인하세요.
Windows에서는 앞에서 사용한 포트 조회 명령으로 OwningProcess를 확인한 뒤 아래 명령으로 프로세스를 찾을 수 있습니다. 어떤 앱이 사용하는지 확인한 다음 해당 앱을 정상 종료하세요. 포트를 점유했다는 이유만으로 알 수 없는 시스템 프로세스를 강제 종료하지 마세요.
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Name *v2ray*, *xray* -ErrorAction SilentlyContinue자주 묻는 질문: 경고가 있거나 로그가 없거나 속도 측정이 정상일 때
로그에 warning이 표시되지만 웹페이지가 열립니다. 바로 설정을 바꿔야 하나요?
먼저 경고가 발생한 시간과 대상을 확인하세요. 백그라운드 프로그램이 요청을 취소했거나 특정 직접 연결 대상에 실패한 기록은 현재 페이지와 무관할 수 있습니다. 반복적으로 재현되고 실제 사용에 영향을 주는 오류만 조치하세요. 로그를 비교해 확인하고 경고 개수만으로 노드 품질을 판단하지 마세요.
info로 설정했는데 웹페이지에 접속해도 새 로그가 전혀 표시되지 않습니다.
먼저 코어가 실행 중인지 확인한 뒤 확인된 로컬 포트를 지정해 프록시 명령으로 테스트하세요. 명시적 프록시 요청은 로그에 표시되는데 브라우저 요청은 표시되지 않는다면 브라우저나 시스템 프록시를 확인해야 합니다. v2rayNG에서는 VPN 서비스 상태와 앱별 프록시에서 해당 앱이 제외되어 있는지 확인하세요.
지연 시간 측정은 정상인데 실제 연결은 왜 시간 초과가 발생하나요?
먼저 어떤 방식으로 속도를 측정했는지 확인하세요. TCP 지연 시간은 연결 과정 일부만 확인할 뿐, 인증이나 TLS 또는 대상 접속 성공을 보장하지 않습니다. 같은 노드로 실제 웹페이지 요청을 한 번 보내고 로그를 확인해 원격 연결 단계에서 멈췄는지 이후 핸드셰이크에서 멈췄는지 살펴보세요. 지연 시간만으로 노드 설정 문제를 배제하지 마세요.
구독 정보와 로그를 전부 관리자에게 보내면 더 편리한가요?
먼저 구독 링크, 사용자 식별 정보, 토큰, 비밀번호, 개인 주소를 가리고 오류 원문, 시간, 필요한 주변 기록만 남기세요. ‘로컬 주소’, ‘노드 주소’, ‘대상 주소’의 역할은 구분해 두세요. 민감한 항목은 직접 삭제한 뒤 가렸다고 표시하고 전체 설정 화면은 보내지 마세요.
점검 결과 정리: 다음 테스트에서 결론을 얻기
한 차례 점검을 마친 뒤 같은 노드, 같은 대상, 같은 네트워크에서 다시 테스트하세요. 한 번 성공했다고 해서 그 시점의 해당 요청만 가능했다는 사실 외에 다른 점까지 확인되는 것은 아닙니다. 간헐적 시간 초과가 문제였다면 원래 사용 환경에서도 계속 관찰해야 합니다. 관리자에게 문의할 때는 “여전히 안 됩니다”라고만 쓰기보다 수행한 작업과 결과를 구체적으로 적어야 원인 파악에 도움이 됩니다.
- 환경: 운영체제 버전, 클라이언트 버전, 코어 이름과 버전, 시스템 프록시 또는 VPN/TUN 중 어떤 방식으로 트래픽을 처리하는지
- 재현 단계: 어떤 설정을 시작했는지, 어떤 대상에 접속했는지, 문제가 발생한 시각, 네트워크를 바꾼 뒤에도 재현되는지
- 증거: 민감한 정보를 가린 오류 원문과 앞뒤 기록, 오류가 클라이언트와 서버 중 어디에서 발생했는지
- 변경 사항: 수정한 필드, 수정 전후의 동작, 원래 설정으로 되돌린 뒤에도 같은 오류가 발생하는지
마지막으로 평소 로그 수준으로 되돌리고 정상 작동하는 설정을 복사해 보관하세요. 연결 거부는 수신 상태와 포트를, 시간 초과는 발생 단계를, 인증 오류는 자격 정보와 프로토콜을, 인증서 오류는 시간과 신뢰 체인을 먼저 확인하세요. 단계별로 점검해야 관련 없는 설정을 계속 바꾸는 일을 막을 수 있습니다.