v2rayN의 로그는 GUI 로그와 코어 로그 두 층으로 나뉘고, 코어 로그는 다시 로딩·핸드셰이크·라우팅 세 단계로 구성됩니다. 이 글에서는 두 로그를 여는 경로와 파일 위치, 자주 나오는 오류 원문 여섯 가지의 의미와 대처 방법, 타임스탬프에서 아웃바운드 노드까지 따라가는 다섯 단계 순서를 다룹니다. 연결 실패, 구독 업데이트 실패, 라우팅 규칙이 적용되지 않는 세 가지 상황에 적합합니다.
로그는 두 층: GUI 로그와 코어 로그
결론부터 말하면 v2rayN에서 볼 수 있는 로그는 두 가지입니다. GUI 로그는 코어 시작과 종료, 노드 전환, 구독 업데이트, 시스템 프록시 켜기와 끄기 같은 인터페이스 동작을 기록합니다. 코어 로그는 각 연결이 인바운드에서 아웃바운드까지 거치는 전체 경로를 기록합니다. 연결 문제를 GUI 로그만 보고 있으면 보통 '시작 성공' 같은 기록만 보이고, 실패 원인은 그곳에 없습니다.
로그 입구는 메인 화면 하단의 '로그' 탭이며, GUI 로그와 코어 로그를 전환할 수 있습니다. GUI 로그는 프로그램 폴더 아래 guiLogs 하위 디렉터리에 날짜별로 함께 저장됩니다. 코어 로그는 기본적으로 화면에만 출력되므로, 규칙 매칭과 도메인 해석 기록을 더 자세히 보려면 '설정' → '매개변수 설정'에서 로그 레벨(loglevel)을 warning에서 info 또는 debug로 올리고, 확인이 끝나면 다시 warning으로 되돌리세요.
| 기록 계층 | 여는 위치 | 주요 기록 내용 | 적합한 상황 |
|---|---|---|---|
| GUI 로그 | '로그' 탭에서 GUI 쪽으로 전환 | 코어 시작과 종료, 구독 업데이트, 노드 전환, 시스템 프록시 켜기와 끄기 | 인터페이스 조작 실패인지 연결 실패인지 판단 |
| 코어 로그 | 같은 탭에서 코어 로그로 전환 | 인바운드 수신, 라우팅 판정, 아웃바운드 연결, 오류 스택 | 연결 실패가 어느 단계에서 발생했는지 파악 |
| 로그 파일 | 프로그램 폴더의 guiLogs 하위 디렉터리, 날짜별 이름 | GUI 로그의 이전 기록 보관 | 프로그램 재시작 후 지난번 시작 기록 확인 |
세 가지 기록 중 연결 문제를 볼 때는 주로 코어 로그를 봅니다. GUI 로그의 역할은 코어가 실제로 실행되었는지 확인하는 것입니다. GUI 로그에 시작 기록조차 없다면 이후 분석은 의미가 없으므로, 먼저 코어 시작 실패 문제를 해결해야 합니다.
코어 로그의 세 단계 구조: 로딩, 핸드셰이크, 라우팅
정상적인 요청 하나는 코어 로그에 네 줄에서 여섯 줄의 기록을 남기며, 시간 순서대로 세 단계에 속합니다. 로딩 단계는 코어가 설정을 읽고 로컬 포트를 여는 단계, 핸드셰이크 단계는 인바운드가 요청을 받고 아웃바운드가 연결을 시작하는 단계, 라우팅 단계는 규칙 판정과 최종 아웃바운드 결과입니다. 장애를 파악하는 첫걸음은 오류가 어느 단계에 속하는지 판단하는 것입니다.
2026/07/02 09:14:02 [Info] infra/conf/serial: Reading config: config.json
2026/07/02 09:14:02 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
2026/07/02 09:14:31 [Info] [4821937461] proxy/vless/inbound: received request for tcp:example.com:443
2026/07/02 09:14:31 [Info] [4821937461] app/dispatcher: default route for tcp:example.com:443
2026/07/02 09:14:31 [Info] [4821937461] transport/internet/tcp: dialing TCP to tcp:node.example.net:443
2026/07/02 09:14:32 [Info] [4821937461] proxy/vless/outbound: tunnelling request to tcp:example.com:443대괄호 안의 숫자는 요청 ID로, 같은 연결의 모든 로그가 같은 ID를 공유합니다. 로그가 너무 빠르게 올라갈 때는 한 줄씩 읽을 필요 없이 ID 하나를 검색하면 한 경로의 기록을 이어서 볼 수 있습니다.
| 단계 | 대표 로그 줄 | 설명 |
|---|---|---|
| 로딩 | Reading config、listening TCP on 127.0.0.1:10808 | 코어가 설정을 읽고 로컬 포트를 여는 단계. 이 줄이 없으면 코어가 실행되지 않은 것입니다. |
| 핸드셰이크 | received request for tcp:...、dialing TCP to tcp:... | 인바운드가 요청을 받고 아웃바운드가 연결을 시작. 앞줄만 있고 뒷줄이 없으면 문제는 라우팅 판정이나 로컬 네트워크에 있습니다. |
| 라우팅 | default route for、tunnelling request to | 규칙 판정 결과와 최종 아웃바운드. direct가 나타나면 직접 연결 규칙에 매칭된 것입니다. |
세 단계 중 가장 자주 놓치는 것이 라우팅 단계입니다. 대상 도메인이 규칙에 의해 직접 연결로 판정되면 로그에 아웃바운드 연결 줄이 나타나지 않고 오류도 나지 않으며, 화면은 계속 로딩만 됩니다. 이럴 때는 노드를 바꾸지 말고 '라우팅 설정'으로 돌아가 규칙 순서를 확인해야 합니다.
자주 나오는 오류 원문 여섯 가지
아래 여섯 가지는 코어 로그에서 가장 자주 등장하는 오류 원문이며, 인바운드에서 아웃바운드 순서로 배열했습니다. 각 항목마다 원인과 대처 방법을 제시하며, 원문은 로그 창의 검색창에 그대로 복사해 찾을 수 있습니다.
오류: address already in use
원인과 해결: 로컬 수신 포트가 이미 사용 중입니다. v2rayN은 기본적으로 10808(SOCKS)과 10809(HTTP)를 사용하는데, 다른 프록시 도구나 완전히 종료되지 않은 코어 프로세스가 같은 포트를 점유하면 이 오류가 발생합니다. 먼저 작업 관리자에서 남은 프로세스를 종료하거나, '설정' → '매개변수 설정'에서 로컬 수신 포트를 20808로 바꾼 뒤 코어를 다시 시작하세요.
오류: failed to find an available destination
원인과 해결: 아웃바운드 서버 주소를 확인할 수 없습니다. 노드 주소 오타, DNS 해석 실패, DNS 오염 등이 원인입니다. 먼저 '매개변수 설정'의 DNS 설정에서 1.1.1.1 또는 223.5.5.5로 바꾸고 코어를 다시 시작하세요. 그래도 오류가 나면 노드 주소를 IP로 바꿔 다시 시도해, 도메인 해석 문제인지 주소 자체가 잘못된 것인지 구분하세요.
오류: dial tcp ...: i/o timeout
원인과 해결: 아웃바운드 연결이 제한 시간 안에 응답을 받지 못했습니다. 먼저 서버 주소와 포트에 도달할 수 있는지, 같은 노드가 다른 네트워크에서는 연결되는지 확인하세요. 특정 노드에서만 시간 초과가 나면 노드를 바꾸면 되고, 모든 노드에서 시간 초과가 나면 로컬 방화벽이 v2rayN과 코어 프로세스를 허용하는지 확인하세요.
오류: tls: first record does not look like a TLS handshake
원인과 해결:전송 계층 설정이 서버와 맞지 않는 경우입니다. 서버에서는 TLS를 켜지 않았는데 클라이언트에서 켠 경우, 또는 양쪽 파라미터가 서로 어긋난 경우에 자주 나타납니다. 노드 공유 링크를 다시 한 번 가져온 뒤 「전송 프로토콜」과 「전송 계층 보안」 두 항목이 서버의 실제 설정과 일치하는지 확인하고, 이 두 값은 직접 조합해 넣지 마세요.
오류: rejected proxy/vless: invalid user
원인과 해결: UUID 또는 비밀번호가 서버에 등록된 값과 다릅니다. 구독 업데이트 후 이 오류가 나오면 대부분 서버에서 UUID를 바꿨는데 로컬은 예전 값을 쓰고 있는 경우입니다. 공유 링크를 다시 복사하거나 구독을 다시 가져오면 되고, 나머지 설정은 건드릴 필요가 없습니다.
오류: connection reset by peer 또는 EOF
원인과 해결: 연결이 맺어진 뒤 상대방이 먼저 끊은 경우입니다. 서버 프로세스 재시작, 프로토콜 매개변수 불일치, 경로 상의 중간 장비 개입 등으로 발생합니다. 먼저 같은 설정으로 다른 노드를 시험해 보세요. 노드를 바꾸면 정상이라면 해당 노드만의 문제이고, 모든 노드에서 끊긴다면 설정 계층을 확인해야 합니다.
결론: 먼저 단계를 나누고, 그다음 키워드를 대조
같은 i/o timeout이라도 아웃바운드 연결 줄 뒤에 나타나면 서버나 경로 문제이고, 코어 시작 단계에 나타나면 로컬 네트워크와 DNS를 확인해야 합니다. 키워드를 대조하기 전에 요청 ID로 이 오류가 어느 단계에 속하는지 먼저 확인하세요.
원인 파악 순서: 타임스탬프에서 아웃바운드 노드까지
로그 양이 많을 때 한 줄씩 읽는 것은 비효율적입니다. 아래 다섯 단계를 따라가면 각 단계에서 질문 하나씩만 답하면 되고, 보통 2~3분 안에 실패 지점을 찾을 수 있습니다.
- 타임스탬프 맞추기. 로그에서
failed또는error를 검색해 해당 줄의 시간을 기록합니다. 같은 초 또는 1~2초 전으로 올라가 같은 요청 ID의 마지막 정상 기록을 찾으세요. 장애는 이 두 줄 사이에서 발생합니다. - 트래픽이 코어에 들어왔는지 확인.
received request를 검색하세요. 이 줄이 아예 없다면 요청이 v2rayN에 도달하지 않은 것이므로, 시스템 프록시 스위치, 브라우저 프록시 확장 프로그램, 시스템 프록시 포트가 로컬 수신 포트(기본 10808 / 10809)와 일치하는지 먼저 확인하세요. - 라우팅 판정 결과 확인.
default route와direct를 검색하세요. 대상이 직접 연결로 판정되면 로그에 아웃바운드 연결 줄이 나타나지 않아 연결은 안 되지만 오류도 표시되지 않으므로, '라우팅 설정'으로 돌아가 규칙 순서를 조정해야 합니다. - 아웃바운드 결과 확인.
dialing TCP to바로 뒤에 오는 오류가 근본 원인이므로, 위 여섯 가지 원문과 바로 대조해 처리하세요. 연결은 성공했는데 이후EOF가 나타나면 해당 노드를 사용 불가로 표시하세요. - 변수를 고정해 한 번 재현. 실패 대상 하나만 남기고 자동 구독 업데이트와 지연 시간 측정을 끈 뒤, 한 번 재현하고 바로 멈춘 다음 로그를 비우고 다시 시작하세요. 그러면 로그 양이 수천 줄에서 수십 줄로 줄어들어 이후 판단이 추측에 기대지 않게 됩니다.
결론: 재현되는 로그라야 쓸모가 있다
실패 대상을 도메인 하나로 고정하고, 한 번 재현한 뒤 해당 요청 ID의 전체 경로만 잘라내면 보통 30줄을 넘지 않습니다. 수천 줄의 과거 로그를 뒤지는 것보다 적중률이 훨씬 높습니다.
로그 점검에 관한 자주 묻는 질문
아래 다섯 가지 질문은 실제 사용 중 들어온 피드백에서 나온 것이며, 답은 모두 구체적인 조작으로 이어집니다.
로그가 전부 Info인데 뭔가 문제가 있는 건가요?
아닙니다. Info는 정상 연결 기록이며, Warning과 Error만 처리하면 됩니다. 로그 레벨을 warning으로 되돌리는 것은 출력을 줄일 뿐 연결 결과를 바꾸지 않습니다.
로그가 너무 빨리 올라가서 알아보기 어려운데 어떻게 하나요?
먼저 자동 구독 업데이트와 지연 시간 측정을 끄고 대상 도메인 하나를 고정해 한 번 재현하세요. 점검이 끝나면 로그 레벨을 debug에서 warning으로 되돌려 불필요한 출력을 줄이세요.
노드를 세 개나 바꿨는데 같은 오류가 나옵니다.
오류가 발생한 위치에 따라 노드 교체가 효과가 있는지가 결정됩니다. 인바운드 단계와 라우팅 단계의 오류는 노드를 바꿔도 소용없고, 아웃바운드 단계의 시간 초과나 EOF 계열 오류만 노드 교체로 검증할 가치가 있습니다.
로그에 실제 도메인과 IP가 나오는데 정상인가요?
정상입니다. 코어는 각 연결의 대상 주소를 기록합니다. 로그를 다른 사람에게 보내기 전에 자신의 서버 주소와 대상 도메인은 먼저 바꿔 두세요.
구독 업데이트가 실패했는데 코어 로그에는 아무것도 없습니다.
구독 업데이트는 GUI 계층에서 처리되므로 코어 로그가 아니라 GUI 로그를 봐야 합니다. 또는 사용 가능한 노드에 먼저 연결한 뒤 구독 설정에서 '프록시를 통해 업데이트'를 체크하고 다시 시도할 수 있습니다.