웹페이지가 열리지 않으면 먼저 로컬 포트가 정상적으로 열렸는지 확인하고, 요청이 코어에 도달했는지 살펴본 다음 DNS 조회, 원격 연결, 프로토콜 핸드셰이크 문제를 구분하세요. 이 글에서는 Windows의 v2rayN과 Xray 코어를 예로 들어 포트 확인 명령, 주요 오류 메시지, 단일 요청 재현 절차를 설명합니다. 노드를 가져온 뒤 문제가 발생한 단계를 찾으려는 사용자에게 유용합니다.
1. 클라이언트 알림과 코어 로그 구분하기
v2rayN은 클라이언트 관리 프로그램이고, 실제 연결 처리는 Xray 코어가 담당합니다. 구독 다운로드나 화면 설정 저장 실패는 클라이언트 단계에서 발생할 수 있습니다. 포트 리슨, 라우팅, 노드 연결, TLS 핸드셰이크는 주로 코어 로그에서 확인합니다. 클라이언트가 실행된다고 코어가 포트를 정상적으로 열었다는 뜻은 아니며, 목록에 노드가 있다고 연결할 수 있다는 뜻도 아닙니다.
문제 해결을 시작하기 전에 v2rayN과 Xray의 버전을 각각 기록해 두세요. 클라이언트 버전은 「도움말」→「정보」에서 확인하고, Xray 버전은 코어 시작 로그에서 확인할 수 있습니다. 데스크톱 버전에 따라 메뉴 배치가 다를 수 있으므로 이 글에서는 「설정」→「매개변수 설정」의 항목 이름으로 안내합니다. 특정 버전의 기본 포트를 모든 버전의 고정값으로 간주하지 마세요.
처리 단계를 역으로 따라가면 문제 범위를 좁힐 수 있습니다. 로컬 연결이 거부되면 노드 비밀번호부터 바꾸지 마세요. 노드 주소로 연결을 시도하다 시간 초과가 발생했다면 브라우저 설정만 살펴봐서는 안 됩니다. 인증서 오류는 TLS 검증 단계까지 진행됐다는 뜻이지만, 프록시 프로토콜 인증이 성공했다는 의미는 아닙니다.
2. 로그 레벨과 로그 한 줄 읽는 순서
Xray 오류 로그 레벨은 주로 debug, info, warning, error이며, 해당 로그를 끄는 none도 있습니다. warning으로 설정하면 일반적으로 그보다 낮은 info와 debug 로그는 표시되지 않습니다. 액세스 로그는 별도의 기록 종류이므로 info 오류 로그와 동일하게 보면 안 됩니다.
| 레벨 | 주요 용도 | 사용 팁 |
|---|---|---|
| debug | 연결과 처리 과정을 자세히 확인 | 문제를 재현할 때만 잠시 활성화 |
| info | 시작 및 연결 처리 등 일반 이벤트 확인 | 초기 문제 해결에 적합 |
| warning | 비정상 연결과 잠재적인 설정 문제 확인 | 요청 대상과 함께 영향 여부 판단 |
| error | 심각한 실행 오류 확인 | 시작이나 포트 리슨에 영향을 주는지 우선 확인 |
아래는 단순화한 액세스 로그 예시이며 실제 측정 결과가 아닙니다. 날짜 형식, 연결 식별자, 아웃바운드 태그는 코어 버전과 생성된 설정에 따라 달라질 수 있습니다. 대괄호 안의 태그는 설정 이름일 뿐이며, 이름만으로 실제 라우팅이 올바른지 판단할 수 없습니다.
2026/10/03 10:20:31 from tcp:127.0.0.1:52134 accepted tcp:example.com:443 [socks -> proxy]127.0.0.1:52134는 연결을 시작한 로컬 주소입니다. 여기서 52134는 보통 임시 포트이며 브라우저에 입력할 프록시 리슨 포트가 아닙니다.example.com:443은 이번 요청의 대상 주소입니다. 문제를 확인할 때 대상 사이트 주소와 노드 서버 주소를 구분하세요.accepted는 인바운드 요청을 수신했다는 뜻입니다. 원격 연결이 성공했거나 웹페이지 로딩이 끝났다는 의미는 아닙니다.- 연결 식별자가 있으면 같은 식별자를 따라 기록을 확인하세요. 식별자가 없다면 시간과 대상 주소를 기준으로 앞뒤 로그를 연결해 살펴보세요.
요약: 같은 요청의 로그를 찾고 가장 안쪽의 원인을 확인하세요
실패한 요청의 앞뒤 로그를 약 10~20줄 정도 보관하고, 오류가 이어지는 과정을 따라가 마지막 시스템 오류나 TLS 오류까지 확인하세요. 가장 바깥쪽의 failed to process만 따로 보면 어떤 설정을 바꿔야 할지 판단하기 어렵습니다.
3. 포트 충돌: 코어가 실제로 실행됐는지 확인하기
코어가 시작 직후 종료되거나 시작 메시지가 반복해서 나타나면 bind, address already in use를 먼저 검색하세요. 포트 충돌은 로컬 컴퓨터에서 발생하므로 구독을 새로 받거나 원격 노드를 바꿔도 대개 해결되지 않습니다. 아래 영어 문구는 자주 나타나는 오류 키워드이며, 실제 로그에는 여러 오류 접두사가 붙을 수 있습니다.
오류: address already in use
원인: 리슨하려는 로컬 주소와 포트를 다른 프로세스가 이미 사용하고 있습니다.
해결: 포트를 사용 중인 프로세스를 찾아 중복 실행된 클라이언트를 종료하세요. 두 프로그램을 함께 실행해야 한다면 각각 다른 리슨 포트를 설정하세요.
오류: Only one usage of each socket address
원인: Windows에서 소켓 바인딩 충돌이 발생했습니다. 이전 코어 프로세스가 계속 실행 중일 때 자주 나타납니다.
해결: 작업 관리자에서 프로세스를 확인하고 해당 프로그램을 종료한 뒤 v2rayN을 다시 실행하세요. 정체를 알 수 없는 시스템 프로세스를 무작정 종료하지 마세요.
먼저 「설정」→「매개변수 설정」에서 로컬 리슨 포트를 확인하세요. 화면에 10808이 표시된다고 가정하고 Windows 터미널에서 아래 두 명령을 실행합니다. 두 번째 명령의 4321은 첫 번째 명령 결과의 마지막 열에서 확인한 PID 예시이므로 실제 숫자로 바꿔야 합니다.
netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 4321"로컬 주소 열과 LISTENING 상태를 확인하세요. 검색 결과에 10808이 있다는 이유만으로 포트 충돌이라고 판단하면 안 됩니다. 클라이언트를 종료한 뒤에도 다른 프로세스가 해당 포트를 계속 사용한다면 프로세스가 무엇인지 확인해야 합니다. 포트가 비면 코어를 다시 시작하고 바인딩 오류가 재발하는지 살펴보세요.
4. 시간 초과와 연결 거부: DNS와 원격 네트워크 구분하기
‘시간 초과’는 특정 단계가 제한 시간 안에 완료되지 않았다는 뜻일 뿐, 노드가 작동하지 않는다는 의미는 아닙니다. 오류가 로컬 포트, 노드 서버, 대상 웹사이트 중 어디와 관련되는지 먼저 확인하세요. 이어서 DNS 조회, TCP 연결 시도, 연결이 성립된 뒤의 데이터 송수신 중 어느 단계에서 발생했는지 살펴보세요.
오류: lookup … no such host
원인: 해당 도메인을 조회했지만 사용할 수 있는 결과를 얻지 못했습니다. 대상은 노드 도메인일 수도, 웹사이트 도메인일 수도 있습니다.
해결: 로그에 나온 도메인의 철자를 먼저 확인한 다음, 해당 조회에 사용된 DNS 설정을 점검하세요. 브라우저에서 도메인이 조회된다는 이유만으로 코어 쪽 문제까지 배제할 수는 없습니다.
오류: dial tcp … i/o timeout
원인: TCP 연결 시도가 제시간에 완료되지 않았습니다. 서버 무응답, 패킷 손실, 방화벽 또는 주소 선택 문제일 수 있습니다.
해결: 노드 주소와 포트를 확인하고, 다른 네트워크나 사용 가능한 다른 노드로 하나씩 바꿔 비교하세요. 같은 서버에서만 실패하는지 기록해 두세요.
오류: connection refused
원인: 연결이 명시적으로 거부됐습니다. 해당 포트에서 서비스가 리슨하지 않거나 네트워크 장비가 연결을 차단할 때 자주 발생합니다.
해결: 대상이 127.0.0.1이면 로컬 리슨 상태를 확인하세요. 노드 서버라면 원격 포트를 점검하고 서비스 제공자에게 서버 상태를 문의하세요.
Windows에서는 아래 명령으로 노드의 TCP 포트에 연결할 수 있는지 확인할 수 있습니다. 예시 도메인은 설명용이므로 실행 전에 노드 설정에 있는 실제 서버 주소로 바꾸고, 포트도 노드와 일치시켜야 합니다. 이 명령은 현재 시스템 네트워크에서 TCP 연결을 시험할 뿐, 전체 프록시 연결을 테스트하지는 않습니다.
Test-NetConnection -ComputerName node.example.com -Port 443TcpTestSucceeded : True는 이번 TCP 연결이 성공했다는 것만 보여 줍니다. UUID, TLS, REALITY 또는 전송 계층 설정은 검증하지 않습니다.- 결과가 False라면 다른 네트워크에서 같은 포트를 테스트해 비교하세요. 한 번의 실패만으로 어느 구간에서 차단됐는지는 알 수 없습니다.
- 노드 주소의 DNS 조회에 성공해도 대상 웹사이트의 DNS가 정상이라는 뜻은 아닙니다. 두 주소가 서로 다른 경로로 조회될 수 있습니다.
- 속도 측정과 웹페이지 접속은 서로 다른 대상과 라우팅 경로를 사용할 수 있습니다. 실패한 웹페이지에 해당하는 로그를 기준으로 확인하세요.
5. 핸드셰이크 실패: TLS와 노드 설정 확인하기
TCP 연결은 되지만 사용할 수 없다면 핸드셰이크 단계를 확인하세요. VLESS와 VMess는 프록시 프로토콜이고, TLS는 보안 전송의 일부이며, WebSocket과 gRPC 등은 전송 방식입니다. 서로 연관된 설정이지만 서로를 대신할 수는 없습니다. 프로토콜과 포트를 올바르게 입력했더라도 설정이 모두 끝난 것은 아닙니다.
오류: x509: certificate has expired or is not yet valid
원인: 인증서 유효 기간과 현재 시간이 맞지 않습니다. 인증서가 만료됐거나 기기의 날짜와 시간이 정확하지 않을 수 있습니다.
해결: 먼저 Windows의 「설정」→「시간 및 언어」→「날짜 및 시간」에서 시간을 동기화하세요. 시간이 정확한데도 오류가 나면 서버 측에서 인증서 유효 기간을 확인해야 합니다.
오류: x509: certificate is valid for …, not …
원인: 검증에 사용된 서버 이름이 인증서에 포함된 도메인과 일치하지 않습니다.
해결: 서비스 제공자의 설정을 참고해 TLS 서버 이름 또는 serverName을 확인하세요. 노드 IP를 인증서 도메인으로 임의 입력하지 마세요.
오류: websocket: bad handshake
원인: WebSocket 업그레이드 요청이 예상한 응답을 받지 못했습니다. 경로, Host 또는 리버스 프록시 설정이 맞지 않을 때 자주 발생합니다.
해결: WebSocket 경로, Host, TLS 사용 여부, 포트를 하나씩 확인하세요. 경로의 대소문자와 슬래시를 그대로 유지하고 UUID만 바꾸지 마세요.
EOF 또는 connection reset by peer만 보인다면 연결이 중간에 종료됐다는 것만 알 수 있으며, 비밀번호 오류라고 단정할 수 없습니다. 서버의 연결 종료, 프록시 프로토콜 설정 불일치, 중간 네트워크의 연결 초기화 등에서도 비슷한 로그가 나올 수 있습니다. 먼저 전체 설정을 확인한 뒤 같은 노드를 다른 네트워크에서 비교해 보세요.
- 서버 주소, 포트, 프로토콜, 사용자 식별자를 확인하고 직접 수정할 때 VLESS 설정을 VMess 노드에 적용하지 않도록 주의하세요.
- TLS 서버 이름과 전송 계층 설정을 확인하세요. WebSocket의 Host와 TLS의 serverName은 서로 다른 항목이므로 같은 값을 무작정 입력하지 마세요.
- REALITY를 사용하는 경우에는 원래 설정에 따라 공개 키, shortId, serverName 등의 값을 확인하세요. 일반 인증서 오류와 같은 방식으로 해결하려고 하지 마세요.
- 서비스 제공자가 전달한 유효한 노드 설정을 다시 가져온 뒤 항목별로 비교하세요. 여러 번 직접 수정하면 변경된 부분을 추적하기 어려워집니다.
요약: 핸드셰이크 오류는 검증을 끄기보다 설정부터 확인하세요
인증서 이름이나 유효 기간에 문제가 있다면 먼저 시간, serverName 또는 서버 인증서를 바로잡으세요. 인증서 검증을 끄면 실제 문제를 가릴 수 있으므로 일상적인 설정으로 유지하는 것은 적절하지 않습니다.
6. 요청 한 번으로 최소 재현하기
문제 해결을 어렵게 만드는 대표적인 방법은 DNS와 라우팅을 바꾸고, 노드를 교체하고, TUN까지 한꺼번에 켜는 것입니다. 이후 정상 작동하더라도 어떤 변경이 효과가 있었는지 알 수 없습니다. 아래 절차에서는 한 번에 노드 하나, 대상 하나, 트래픽 처리 방식 하나만 사용해 전후를 비교합니다.
-
현재 상태 기록
클라이언트와 코어 버전, 현재 노드, 라우팅 모드, 로컬 포트, TUN 사용 여부를 기록하세요. 문제를 살피기 전에 원래 설정을 보관해 되돌아갈 기준을 마련하세요.
-
로그 설정 조정
「설정」→「매개변수 설정」에서 「로그 레벨」을 찾아 임시로 info로 변경하세요. 정보가 부족할 때만 debug를 사용하세요. 저장한 뒤 코어를 다시 시작하고 시작 로그가 새로 기록됐는지 확인하세요.
-
요청 경로 고정
먼저 TUN을 끄고 메인 화면에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택한 다음 시스템 프록시를 따르는 브라우저로 테스트하세요. 특정 프록시 포트를 지정해 테스트한다면 자동 프록시 적용 결과와 혼동하지 마세요.
-
한 번 재현
페이지 자동 새로고침과 백그라운드 다운로드를 끄고 현재 시간을 기록한 뒤, 실패한 주소에 한 번만 접속하세요. 마지막 한 줄만 자르지 말고 해당 시간 전후의 시작, 요청, 오류 로그를 함께 복사하세요.
-
한 항목씩 비교
노드나 네트워크 중 하나만 바꾼 뒤 같은 주소에 다시 접속하세요. 문제가 해결되면 로그 레벨을 원래대로 되돌리고 시스템 프록시와 TUN 상태도 의도한 설정인지 확인하세요.
브라우저 프록시 설정을 거치지 않고 비교하려면 아래 명령을 사용할 수 있습니다. 현재 SOCKS 리슨 포트가 10808이라고 가정하며 최대 대기 시간은 15초입니다. 다른 포트를 사용한다면 먼저 명령을 수정하세요. socks5h는 대상 도메인 조회를 프록시에 맡기지만, 코어 내부에서 어떤 DNS 정책을 사용할지는 결정하지 않습니다.
curl.exe --proxy socks5h://127.0.0.1:10808 --max-time 15 --head https://example.com/HTTP 상태 코드가 반환되면 이번 요청에서 HTTP 응답을 받았다는 뜻입니다. 상태 코드가 403 또는 405더라도 연결 시간 초과와는 구분해 처리해야 합니다. 명령은 성공하지만 브라우저에서 실패한다면 브라우저 자체 프록시, 확장 프로그램, 시스템 프록시 적용 상태를 먼저 확인하세요. 둘 다 같은 단계에서 실패한다면 코어 오류 로그를 따라 계속 원인을 찾으세요.
7. 자주 묻는 질문과 로그 공유 전 확인 사항
노드 지연 시간은 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 TCP 지연 테스트인지 실제 연결 테스트인지 확인하세요. TCP 연결 성공만으로 전체 프록시 경로가 검증되지는 않습니다. 메인 화면에서 노드를 선택하고 마우스 오른쪽 버튼을 눌러 「서버 실제 연결 지연 테스트」 결과를 확인한 다음, 실패한 웹페이지의 로그에서 대상, 라우팅, 핸드셰이크 단계를 살펴보세요.
오류도 없고 요청 로그도 전혀 없으면 어떻게 하나요?
로그 레벨과 액세스 로그 활성화 여부를 먼저 확인하세요. 지정한 SOCKS 포트를 사용하는 curl 명령으로 재현하고 브라우저 접속 결과와 비교하세요. 브라우저 요청만 코어에 도달하지 않는 경우 「시스템 프록시」→「시스템 프록시 자동 설정」과 브라우저 자체 프록시 설정을 확인하세요.
구독 업데이트가 시간 초과되면 노드 핸드셰이크 오류처럼 점검해야 하나요?
먼저 실패한 작업이 구독 다운로드인지 노드 연결인지 구분하세요. 「구독 그룹」에서 구독 주소와 현재 업데이트 방식을 확인하세요. 구독에 프록시가 필요하다면 사용할 수 있는 노드가 있는지 먼저 확인한 뒤 프록시를 통해 업데이트하도록 설정하세요. 구독 다운로드 오류만으로 목록의 노드가 전부 작동하지 않는다고 볼 수는 없습니다.
로그에 가끔 EOF가 나타나면 바로 노드를 바꿔야 하나요?
이 한 줄만으로 판단할 필요는 없습니다. 같은 시각에 페이지가 실제로 실패했는지 먼저 확인하세요. 페이지를 닫거나 연결을 취소해도 연결 종료 로그가 남을 수 있습니다. 오류가 특정 요청과 반복해서 일치하는 경우에만 노드 설정과 네트워크 상태를 비교하세요.
다른 사람에게 문제 해결을 요청하기 전에 무엇을 가려야 하나요?
구독 전체 주소, 액세스 토큰, UUID, 비밀번호, 개인 키, 개인 접속 기록을 삭제하세요. 오류 키워드, 시간 순서, 프로토콜과 전송 유형, 포트, 같은 방식으로 치환한 호스트 이름은 남겨도 됩니다. 공개된 공간에는 원본 설정 전체를 올리지 마세요.
문제를 설명하는 글은 간단해도 충분합니다. 버전, 운영체제, 트래픽 처리 방식, 실패한 대상의 종류, 재현 시각, 노드나 네트워크를 바꿨을 때의 차이를 적으세요. 스크린샷 크기보다 오류 흐름을 보존하는 것이 중요합니다. 포트가 리슨하지 않으면 로컬 실행부터 해결하고, 원격 연결 시도가 실패하면 네트워크 연결 가능성을 확인하고, 핸드셰이크 단계까지 도달했다면 설정을 점검하세요. 이 순서대로 진행하면 같은 점검을 되풀이하지 않을 수 있습니다.