노드를 가져왔지만 연결 시간 초과가 발생하거나 웹페이지가 열리지 않는 경우에 적합한 안내입니다. 먼저 명령어로 로컬 프록시가 요청을 받는지 확인하고, 앱 트래픽이 코어로 전달되는지 살펴본 다음 노드 매개변수와 원격 포트를 점검합니다. 한 번에 하나씩만 변경하고 다시 테스트하면 로컬 설정, 프로토콜 핸드셰이크, 서버 장애를 구분할 수 있어 모든 문제를 노드 오류로 단정하지 않아도 됩니다.
1. 시간 초과가 발생하는 구간부터 구분하기
v2rayN은 설정을 관리하고 코어를 실행하며 시스템 프록시를 설정하는 데스크톱 클라이언트입니다. 실제 연결은 선택한 코어가 처리합니다. 앱 화면이 열리고 구독이 갱신된다고 해서 프록시를 통한 외부 연결까지 정상이라는 뜻은 아닙니다. 구독을 내려받는 경로와 대상 웹사이트에 접속하는 경로가 다를 수도 있습니다. 점검할 때는 노드 목록의 상태만 보지 말고 실제 요청 하나를 기준으로 확인하세요.
먼저 노드 하나, 대상 주소 하나, 테스트 방법 하나를 정합니다. 대량 속도 측정과 자동 전환은 잠시 중지하고 문제가 재현된 시간을 기록하세요. 클라이언트 테스트에서만 시간 초과가 표시되고 브라우저에서는 접속된다면, 먼저 테스트 주소에 해당 노드로 접근할 수 있는지 확인합니다. 테스트 대상에 연결할 수 없다고 해서 모든 웹사이트에 접속할 수 없는 것은 아닙니다.
- 모든 노드에서 실패: 노드를 하나씩 수정하기 전에 로컬 포트, 코어 실행 상태, 시스템 프록시부터 확인하세요.
- 특정 노드 하나만 실패: 같은 테스트 조건에서 해당 노드 설정, 원격 포트, 서버 상태를 확인하세요.
- 특정 앱 하나만 실패: 해당 앱이 시스템 프록시를 따르는지, 자체 프록시나 별도의 DNS 설정을 사용하는지 확인하세요.
- 일부 웹사이트만 실패: 라우팅 규칙 적용 여부, 도메인 이름 해석, 대상 사이트의 제한을 점검하세요. 클라이언트를 바로 재설치할 필요는 없습니다.
2. 로컬 포트: 코어가 요청을 수신하는지 확인하기
먼저 v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트와 프록시 유형을 확인하세요. UI 버전에 따라 항목 위치가 다를 수 있으므로 현재 설정과 시작 로그를 기준으로 판단해야 합니다. 아래에서는 127.0.0.1:10808 혼합 인바운드를 예로 듭니다. HTTP 또는 SOCKS 인바운드를 따로 사용한다면 해당 포트로 바꾸세요. 예시의 숫자가 모든 버전에서 기본값으로 고정되어 있는 것은 아닙니다.
Windows에서는 PowerShell에서 아래 명령을 실행합니다. 첫 번째 명령으로 수신 상태를 확인하고, 두 번째 명령으로 결과에 표시된 프로세스 ID에 해당하는 프로그램을 찾습니다. LISTENING이 표시되어야 포트가 수신 중인 것입니다. 연결 기록만 있고 수신 기록이 없다면 정상으로 볼 수 없습니다.
netstat -ano | findstr ":10808"
tasklist /FI "PID eq 1234"두 번째 명령의 1234는 예시 프로세스 ID입니다. 실행 전에 첫 번째 명령 결과의 마지막 열에 표시된 실제 ID로 바꾸세요. macOS와 Linux에서는 아래 명령으로 확인할 수 있습니다. Linux에 lsof가 설치되어 있지 않다면 ss를 사용하세요.
lsof -nP -iTCP:10808 -sTCP:LISTEN
# Linux에서 사용할 수 있는 다른 점검 방법
ss -lntp 'sport = :10808'- 수신 중이지 않음: 코어 시작 로그를 확인하고 설정 로드 실패, 코어 누락, 권한 오류 등을 해결한 뒤 노드를 다시 활성화하세요.
- 다른 프로그램이 포트를 사용 중: 먼저 어떤 프로세스인지 확인한 다음 충돌하는 프로그램을 종료하거나 인바운드 포트를 변경하세요. 포트를 바꿨다면 앱의 프록시 설정도 함께 수정해야 합니다.
- 수신 주소가 일치하지 않음: IPv6 루프백 주소에서만 수신 중이면 IPv4 주소인
127.0.0.1로 접속하지 못할 수 있습니다. 주소와 인바운드 설정을 일치시키세요.
3. 시스템 프록시: 명시적 요청으로 문제 구간 분리하기
로컬 포트가 정상적으로 수신 중이면 시스템 프록시 설정을 거치지 않고 프록시 포트에 직접 요청을 보내세요. Windows에서는 일부 PowerShell 환경에서 같은 이름의 별칭이 다르게 동작할 수 있으므로 curl.exe를 사용하고, macOS와 Linux에서는 curl을 사용합니다. 아래 example.com은 테스트 대상 예시일 뿐입니다. 명령의 포트는 실제 인바운드 포트와 일치해야 합니다.
# Windows: HTTP를 지원하는 인바운드에서만 사용
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com
# macOS / Linux: SOCKS5를 지원하는 인바운드에서만 사용
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.comsocks5h는 대상 도메인의 처리를 프록시에 맡긴다는 뜻입니다. 두 명령은 서로 다른 인바운드 프로토콜을 테스트하므로 SOCKS만 지원하는 포트에 HTTP 프록시 문법을 사용하면 안 됩니다. HTTP 응답 헤더가 반환되면 요청이 응답을 반환할 수 있는 지점까지 도달한 것입니다. 403 같은 상태 코드가 반환되면 사이트 정책도 확인해야 하며, 이를 연결 시간 초과와 같은 문제로 보면 안 됩니다.
-
프록시 포트 확인
v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 인바운드 포트와 유형을 확인한 뒤, 해당 설정에 맞는 명시적 프록시 명령을 실행하세요.
-
시스템 프록시 켜기
Windows에서는 v2rayN 트레이 메뉴의 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 선택해 프록시를 적용한 다음 브라우저를 다시 열어 테스트하세요.
-
시스템 설정 확인
Windows의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 다른 프로그램이 설정을 반복해서 덮어쓰는지도 살펴보세요.
-
앱 자체 설정 확인
브라우저 프록시 확장 프로그램과 앱 자체의 네트워크 설정을 확인하세요. 별도의 프록시 설정을 잠시 끄고 한 가지 트래픽 전달 방식만 유지한 상태에서 다시 테스트합니다.
결론: 명시적 프록시 요청이 성공하면 앱 진입 경로부터 수정
명령은 성공하지만 브라우저에서 계속 실패한다면 브라우저 프록시, 시스템 프록시, 앱 DNS 설정의 차이부터 해결하세요. 이 경우 트래픽이 로컬 프록시에 들어오지 않는 문제는 노드를 바꿔도 해결되지 않습니다.
macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 설정을 확인할 수 있습니다. Linux의 시스템 프록시가 특정 프로그램에 적용되는지는 데스크톱 환경과 앱 구현에 따라 다릅니다. 명령줄 도구도 데스크톱 프록시 설정을 읽지 않을 수 있으므로 명시적 매개변수나 해당 도구에서 지원하는 프록시 환경 변수가 필요합니다.
4. 클라이언트 로그: 마지막 줄보다 실패 단계 확인하기
요청을 한 번 더 보내면서 v2rayN의 로그 영역이나 사용 중인 버전에서 제공하는 로그 창을 확인하세요. 요청 전후의 로그 몇 줄을 함께 보관하되, 인바운드 주소, 대상 주소, 라우팅 아웃바운드, 가장 구체적인 오류 메시지를 특히 살펴보세요. ‘연결 처리 실패’ 같은 상위 단계 메시지는 요약일 뿐인 경우가 많으며, 실제 원인은 뒤에 이어지는 DNS, TCP, TLS 오류에 기록되어 있을 수 있습니다.
bind: address already in use
원인: 프로그램이 바인딩하려는 로컬 주소와 포트를 다른 프로세스가 사용 중입니다.
해결: 포트를 사용하는 프로세스와 용도를 확인하고 충돌을 해결한 뒤 코어를 다시 시작하세요. 포트를 바꿨다면 시스템 프록시 설정도 갱신해야 합니다.
connect: connection refused
원인: 연결이 명시적으로 거부되었습니다. 해당 포트에서 서비스가 수신 중이지 않거나 장치 또는 방화벽이 연결을 거부할 때 흔히 발생합니다.
해결: 오류에 표시된 주소가 로컬인지 원격인지 먼저 확인한 다음 해당 장치의 수신 상태와 거부 규칙을 점검하세요.
i/o timeout
원인: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 끝나지 않았습니다. 이 메시지만으로는 노드가 작동하지 않는지 대상 사이트가 응답하지 않는지 판단할 수 없습니다.
해결: 앞뒤 로그를 함께 확인해 DNS 조회, 연결, 데이터 전송 중 어느 단계에서 멈췄는지 파악한 다음 노드 포트와 대상 웹사이트를 각각 테스트하세요.
x509: certificate has expired or is not yet valid
원인: 인증서 유효 기간 확인에 실패했습니다. 컴퓨터 시간이 잘못되었거나 서버 인증서가 만료되었을 수 있습니다.
해결: 먼저 시스템 날짜와 시간을 동기화하세요. 시간이 정확한데도 오류가 계속되면 서버 관리자가 인증서와 인증서 체인을 확인해야 합니다.
오류 문구는 운영체제와 코어에 따라 달라질 수 있습니다. 위 내용은 흔히 볼 수 있는 오류 일부이며 모든 버전에서 로그가 그대로 표시된다는 뜻은 아닙니다. 코어에서 액세스 로그를 켰는데 해당 요청이 보이지 않는다면 앱 진입 경로부터 확인하세요. 액세스 로그가 꺼져 있다면 요청이 보이지 않는다는 이유만으로 트래픽이 들어오지 않았다고 단정할 수 없습니다.
5. 노드 설정: 프로토콜과 전송 매개변수 확인하기
원격 포트에 TCP 연결이 된다고 해서 프록시 인증과 전송 핸드셰이크까지 성공한다는 뜻은 아닙니다. VMess, VLESS, Trojan, Shadowsocks는 각각 인증 및 보안 방식이 다릅니다. 전송 계층, TLS, 프로토콜 이름은 서로 다른 설정 항목입니다. 프로토콜 드롭다운만 바꿔서는 노드가 다른 프로토콜로 변환되지 않습니다.
| 점검 항목 | 확인할 내용 | 수정 방법 |
|---|---|---|
| 주소와 포트 | 서버 도메인, IP 주소, 서버 수신 포트 | 제공된 정보와 일치시킵니다. 로컬 포트 10808을 노드의 원격 포트로 입력하지 마세요. |
| 프로토콜 및 인증 | VMess/VLESS의 UUID, Trojan의 비밀번호, Shadowsocks의 암호화 방식과 비밀번호 | 전체 설정을 다시 가져와 수동 입력 중 공백이 들어가거나 문자가 누락되는 일을 방지하세요. |
| 전송 설정 | TCP, WebSocket 등 전송 유형과 해당 경로 및 Host | 항목별로 서버 설정과 일치시킵니다. 경로의 대소문자와 앞쪽 슬래시도 같아야 합니다. |
| TLS 설정 | TLS 사용 여부, 서버 이름, 인증서 도메인 | 서버 요구 사항에 맞게 입력하고 연결 주소와 TLS 서버 이름을 구분하세요. |
| 코어 지원 여부 | 선택한 코어가 노드에 필요한 프로토콜, 전송 방식, 보안 설정을 지원하는지 | 실제로 실행 중인 코어와 오류 메시지를 확인하세요. 클라이언트 이름만으로 지원 여부를 짐작하지 마세요. |
구독이 갱신되었다면 먼저 ‘구독 그룹’에서 업데이트를 실행해 최신 설정을 가져온 뒤, 현재 활성 노드가 이전 기록인지 확인하세요. 연결을 시도하려고 TLS 서버 이름을 임의로 지우거나 인증서 검증을 끄지 마세요. 설정 오류를 숨기고 연결 보안을 약화할 수 있습니다. VMess 인증에는 시스템 시간이 적절하게 설정되어 있어야 하므로 시간 동기화는 인증서 오류가 있을 때만 필요한 작업이 아니라 기본 점검 항목입니다.
- Windows: ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 자동 시간 설정을 확인하고 시간 동기화를 실행하세요.
- macOS: ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 시간 출처와 현재 시간이 올바른지 확인하세요.
- Android: v2rayNG 또는 v2flyNG를 사용할 때도 시스템 시간, 노드 항목, 연결 로그를 확인하세요. 데스크톱의 시스템 프록시 설정을 Android의 VPN 방식 트래픽 전달에 그대로 적용할 수는 없습니다.
6. 서버 연결: 포트, 핸드셰이크, 트래픽 전달 구분하기
로컬 수신, 앱 진입 경로, 노드 설정을 모두 확인한 뒤 현재 네트워크에서 원격 서버에 연결할 수 있는지 테스트합니다. Windows PowerShell에서 다음 명령을 실행할 수 있습니다. 예시에 나온 example.com과 443은 자신의 노드 서버 주소와 실제 포트로 바꿔야 합니다. 예시를 그대로 실행해도 노드가 작동하는지는 확인할 수 없습니다.
Test-NetConnection -ComputerName example.com -Port 443TcpTestSucceeded 값을 확인하세요. True는 TCP 연결이 성공했다는 뜻일 뿐, UUID, 비밀번호, TLS, WebSocket 경로, 서버 트래픽 전달 설정까지 올바르다는 의미는 아닙니다. False라면 주소 조회 결과, 서버 수신 상태, 보안 그룹, 방화벽을 추가로 점검하세요. UDP 기반 전송의 경우 이 TCP 테스트로 해당 프로토콜을 확인할 수 없습니다.
- DNS 조회 결과 확인:
nslookup example.com으로 서버 도메인을 확인하세요. 자신의 노드 도메인으로 바꾼 뒤 결과가 서버 배포 설정과 일치하는지 살펴봅니다. IPv4와 IPv6 주소가 여러 개라면 실제 연결에 사용되는 주소를 각각 확인하세요. - 수신 상태 확인: 직접 관리하는 Linux 서버에서는
ss -lntp로 TCP 수신 상태를 확인할 수 있습니다. UDP 서비스는ss -lnup을 사용하세요. 수신 주소, 포트, 프로세스가 배포 설정과 일치해야 합니다. - 인바운드 규칙 확인: 클라우드 플랫폼의 보안 그룹과 시스템 방화벽에서 실제 서버 포트와 해당 프로토콜을 허용해야 합니다. 문제를 찾는 대신 방화벽 전체를 장기간 꺼 두지 마세요.
- 핸드셰이크 경로 확인: 리버스 프록시를 사용한다면 도메인, TLS 인증서, 전달 경로, 백엔드 서비스 상태도 점검하세요. 외부 포트가 열려 있어도 백엔드가 정상이라는 보장은 없습니다.
- 서버 외부 연결 확인: 핸드셰이크는 성공했지만 대상에 접속하지 못한다면 서버 DNS, 아웃바운드 연결, 라우팅 정책, 대상 웹사이트의 응답을 확인하세요.
결론: 같은 노드로 네트워크 비교하기
노드, 기기, 대상 웹사이트는 그대로 두고 신뢰할 수 있는 다른 네트워크에서 다시 테스트하세요. 특정 네트워크에서만 실패한다면 해당 네트워크의 DNS 조회, IPv6 경로, 외부 연결 제한부터 확인합니다. 네트워크가 달라도 같은 단계에서 실패한다면 노드와 서버를 집중적으로 살펴보세요.
ping은 ICMP를 사용하며 서버나 중간 네트워크에서 차단될 수 있습니다. 따라서 ping에 응답이 없다고 해서 프록시 포트에 연결할 수 없다고 단정할 수 없습니다. 반대로 ping에 응답해도 프록시 인증 성공을 의미하지 않습니다. 한 가지 테스트 결과만으로 전체 연결 경로를 판단하지 마세요.
7. 수정 후 다시 테스트하고 정상 상태 기록하기
수정을 마친 뒤 기존 요청 경로를 따라 다시 확인하세요. 먼저 포트 수신 상태를 확인하고 명시적 프록시 명령을 실행한 다음 실제 앱을 테스트합니다. 한 번에 하나의 설정만 바꾸고 변경 전후 오류가 어떻게 달라졌는지 기록하세요. 연결 시간 초과가 인증 실패로 바뀌었다면 점검 단계가 진전된 것입니다. 모든 변경 사항을 바로 되돌리고 처음부터 다시 시작할 필요는 없습니다.
- 반복해서 확인: 같은 대상에 요청을 반복해 보내고 로그에 같은 오류가 계속 나타나지 않는지 확인하세요.
- 라우팅 확인: 요청이 프록시를 거치는지 직접 연결되는지 확인하세요. 직접 연결이 성공한 것을 노드가 복구된 것으로 오해하지 않도록 합니다.
- 정상 설정 복원: 임시 디버그 로그를 끄고 사용하지 않는 프록시 덮어쓰기를 제거하되 필요한 방화벽 규칙은 유지하세요.
- 문의 자료 보관: 클라이언트 버전, 코어 유형과 버전, 노드 프로토콜, 실패 단계, 오류 원문, 네트워크 비교 결과를 기록하되 인증 정보는 첨부하지 마세요.
원인을 찾지 못했다면 문제 해결 안내를 확인하세요. 설정을 가져오고 활성화하는 방법이나 시스템 프록시 설정을 아직 확인하지 않았다면 빠른 시작 가이드에 따라 재현 가능한 기본 설정을 먼저 구성한 다음 로그를 살펴보세요. 노드, DNS, 코어를 동시에 바꾸는 것보다 원인을 찾기 쉽습니다.