구독을 가져왔지만 노드가 작동하는지 확신이 서지 않는 데스크톱 사용자에게 적합합니다. ‘노드 설정 확인 → 실제 연결 테스트 → 활성 서버 지정 → 시스템 프록시 켜기 → 로그와 출구 IP 대조’ 순서로 진행하면 노드 장애, 프록시 진입점 문제, 라우팅 분기 문제를 구분할 수 있습니다. 이 글에서는 Windows용 v2rayN을 예로 들며, 처음부터 TUN을 켤 필요는 없습니다.
연결 전: 구독과 로컬 프록시 진입점 확인
구독 업데이트에 성공했다는 것은 클라이언트가 서버 항목을 가져왔다는 뜻일 뿐, 모든 노드에 연결할 수 있다는 의미는 아닙니다. 목록에 주소, 포트, 프로토콜이 있는지 확인한 다음 구독 서비스가 아직 유효한지도 점검하세요. VMess, VLESS 등의 프로토콜은 인증 정보와 전송 설정에도 영향을 받습니다. 지연 시간을 줄이려고 서비스 제공자가 설정한 TLS, SNI 또는 전송 경로를 함부로 변경하지 마세요.
이 글에서는 Windows용 v2rayN 7.x 계열에서 흔히 쓰이는 메뉴 이름을 기준으로 안내합니다. 세부 버전에 따라 버튼 위치나 문구가 조금 다를 수 있습니다. 먼저 ‘설정’ → ‘매개변수 설정’을 열어 로컬 수신 포트를 확인하고, 메인 창으로 돌아와 하단의 ‘시스템 프록시’와 라우팅 모드를 살펴보세요. 이후 명령 예시는 HTTP 프록시를 지원하는 로컬 혼합 포트가 127.0.0.1:10808에서 수신 대기한다고 가정합니다. 실제 값은 매개변수 설정과 시작 로그를 기준으로 확인하세요.
노드 선택: 실제 연결 지연이 TCP 지연보다 실사용 상태를 잘 보여줍니다
TCP 지연 테스트는 대상 주소와 포트에 TCP 연결을 설정할 수 있는지 확인합니다. 인증 정보가 올바른지, TLS와 전송 계층 및 원격 출구가 정상인지까지 확인해 주지는 않습니다. 실제 연결 테스트는 해당 노드를 통해 테스트 주소에 요청을 보내므로 처음 노드를 추릴 때 더 적합합니다. 다만 테스트 당시 해당 주소에 접속한 결과만 보여준다는 점은 유의하세요.
실제 연결 지연
권장메인 창에서 후보 노드를 선택한 뒤 마우스 오른쪽 버튼을 눌러 ‘서버 실제 연결 지연 테스트’를 선택하세요. 프록시 연결을 통해 설정된 테스트 주소에 접속하므로 포트 확인만으로는 발견하기 어려운 일부 연결 문제를 찾아낼 수 있습니다.
적합한 용도: 처음 노드를 추리거나 노드를 변경한 뒤 연결 상태를 확인할 때
TCP 지연
마우스 오른쪽 버튼 메뉴의 ‘서버 지연 테스트 Tcping’은 TCP 포트에 연결할 수 있는지 빠르게 확인하는 기능입니다. 숫자가 표시되더라도 프록시가 정상 작동한다는 뜻은 아닙니다. 다른 전송 방식에 의존하는 노드는 이 결과만으로 판단할 수 없습니다.
적합한 용도: 포트 연결 실패와 이후 핸드셰이크 실패를 구분할 때 참고
다운로드 속도 테스트
속도 테스트는 실제 트래픽을 발생시키므로 연결 상태를 확인한 뒤 처리량을 비교할 때 사용하세요. 속도가 빠르다고 웹페이지가 반드시 빨리 열리는 것은 아니며, 구독에 포함된 모든 노드를 자주 일괄 테스트하는 것도 권장하지 않습니다.
적합한 용도: 사용 가능한 노드 몇 개 중 대용량 파일 전송에 쓸 후보를 고를 때
먼저 후보 노드 3~5개를 골라 각각 3회씩 테스트하고, 연속으로 성공하는지 살펴보세요. 아래는 결과를 해석하는 예시일 뿐, 이 사이트에서 직접 측정한 값은 아닙니다. 노드 A는 3회에 180, 195, 188ms, 노드 B는 95ms, 시간 초과, 110ms가 나왔다고 가정해 보겠습니다. 처음 연결할 때는 B의 최저 기록만 보지 말고 A처럼 안정적인 노드를 우선 선택하세요.
- 모든 테스트가 시간 초과: 먼저 PC에서 인터넷에 정상적으로 접속되는지 확인한 다음, 테스트 주소가 유효한지와 구독이 만료되지 않았는지 살펴보세요. 로그에 공통 핸드셰이크 오류가 있는지도 확인합니다.
- 일부 테스트만 시간 초과: 연속으로 성공한 노드로 먼저 바꾸고, 전역 설정은 성급하게 수정하지 마세요.
- 지연은 정상인데 대상 사이트에 접속할 수 없음: 대상 사이트에 직접 접속해 확인하세요. 테스트 사이트 접속이 된다고 해서 모든 사이트에 접속할 수 있는 것은 아닙니다.
첫 연결: 활성 서버로 지정한 다음 시스템 프록시 켜기
목록에서 강조 표시된 행이 현재 사용 중인 서버라고 단정할 수는 없습니다. 테스트는 선택한 항목을 대상으로 실행할 수도 있으므로 ‘속도 테스트 성공’과 ‘현재 트래픽이 이 노드를 통과함’은 별개의 문제입니다. 테스트를 마친 뒤에는 해당 노드를 활성 서버로 직접 지정하고 코어가 정상적으로 다시 로드될 때까지 기다리세요.
-
후보 노드 선택
서버 목록에서 실제 연결 테스트를 연속으로 통과한 노드를 클릭하세요. 마우스 오른쪽 버튼을 눌러 작업 대상을 확인하면 구독 그룹을 전환한 뒤에도 이전 행 위치를 기준으로 노드를 잘못 판단하는 일을 막을 수 있습니다.
-
활성 서버로 지정
마우스 오른쪽 버튼을 눌러 ‘활성 서버로 지정’을 선택하고 목록의 활성 표시와 로그의 재로드 결과를 확인하세요. 선택된 행의 배경색만 보고 전환이 완료됐다고 판단하지 마세요.
-
프록시 설정
메인 창 하단의 ‘시스템 프록시’ 메뉴에서 ‘시스템 프록시 자동 설정’을 선택하세요. 트레이 아이콘의 ‘시스템 프록시’ 하위 메뉴에서도 설정할 수 있습니다. 이번에는 ‘시스템 프록시 해제’를 선택하지 마세요.
-
라우팅 확인
현재 라우팅 모드를 기록해 두세요. 분기 설정의 영향을 제외해야 한다면 클라이언트에서 제공하는 ‘전역’ 프록시 라우팅 프리셋을 잠시 선택하세요. 확인을 마친 뒤 평소 사용하는 분기 프리셋으로 되돌리면 됩니다.
-
새 요청 보내기
새 브라우저 창을 열어 대상 웹페이지에 접속하면서 하단 로그도 확인하세요. 브라우저가 이전 연결을 계속 재사용한다면 브라우저를 완전히 종료한 뒤 다시 열고 같은 테스트를 진행하세요.
작동 확인: 브라우저, 출구 IP, 로그를 교차 점검
웹페이지가 열리는 것만으로 프록시가 작동한다고 볼 수는 없습니다. 해당 사이트에 원래 직접 연결할 수 있거나 분기 규칙에 따라 직접 연결하도록 설정되어 있을 수도 있습니다. 같은 대상을 기준으로 프록시 미사용, 프록시 명시 지정, 시스템 프록시를 따르는 브라우저에서 각각 결과를 확인하는 편이 더 확실합니다.
| 확인 항목 | 확인 방법 | 결과 해석 |
|---|---|---|
| 직접 연결 기준값 | 프록시를 거치지 않고 IP 조회 주소에 요청을 보내 반환된 주소를 기록합니다 | 현재 네트워크에서 해당 사이트로 직접 연결할 때 사용하는 출구 주소를 확인합니다 |
| 명시적 프록시 | 로컬 혼합 포트를 통해 동일한 IP 조회 주소에 요청을 보냅니다 | 로컬 진입점, 선택한 노드, 원격 출구까지의 연결 경로를 확인합니다 |
| 브라우저 접속 | 시스템 프록시를 켠 뒤 브라우저에서 같은 조회 주소를 엽니다 | 명시적 프록시 결과와 비교해 브라우저가 예상한 진입점을 사용하는지 확인합니다 |
| 로그 확인 | 요청을 보낸 시점의 대상 도메인, 출구 태그 또는 오류를 확인합니다 | 요청이 코어에 들어온 뒤 프록시 처리, 직접 연결 또는 거부 중 어떤 결과였는지 파악하는 데 참고합니다 |
Windows PowerShell에서는 curl.exe로 결과를 비교할 수 있습니다. 프로그램 이름을 명시하면 일부 환경에서 같은 이름으로 등록된 별칭과 혼동하는 일을 피할 수 있습니다. 아래 예시는 공개 IP 조회 서비스를 사용합니다. 요청 과정에서 현재 출구 주소가 해당 사이트에 전달되므로 개인정보 보호 기준에 따라 조회 서비스를 선택하세요. 포트가 10808이 아니라면 먼저 실제 HTTP 또는 혼합 수신 포트로 바꾸세요.
# 프록시를 명시적으로 우회해 직접 연결 기준값 확인
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org
# 로컬 HTTP / 혼합 프록시 진입점을 명시적으로 사용
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://api.ipify.org두 명령 모두 코어 라우팅의 영향을 받으므로 비교할 때는 앞에서 설정한 임시 전역 프록시 프리셋을 사용하세요. 두 번째 명령에서 직접 연결과 다른 공인 주소가 반환되면 브라우저에서 https://api.ipify.org를 열어 브라우저 결과가 두 번째 명령의 결과와 일치하는지 비교하세요. IP 위치 데이터베이스는 정확하지 않을 수 있으니 표시된 국가나 도시만으로 노드가 바뀌었는지 판단하지 마세요.
- 명시적 프록시는 성공하지만 브라우저에는 직접 연결 주소가 표시됨: 먼저 시스템 프록시 설정, 브라우저 프록시 확장 프로그램, 브라우저 자체 프록시 정책을 확인하세요.
- 두 주소가 같음: 먼저 조회 사이트가 직접 연결 규칙에 해당하는지 확인한 다음 활성 서버를 점검하세요. 주소가 같다는 사실만으로 프록시가 작동하지 않는다고 단정할 수는 없습니다.
- IP 조회는 성공하지만 서비스 사이트에 접속할 수 없음: 해당 사이트의 라우팅, DNS, 서버 측 제한을 확인하세요. 곧바로 클라이언트를 다시 설치할 필요는 없습니다.
요청을 보낸 시간대의 로그를 확인해야 합니다. 현재 로그 수준이 경고나 오류만 기록한다면 접속 항목이 없다고 해서 요청이 코어를 거치지 않았다고 단정할 수 없습니다. 필요한 경우 ‘설정’ → ‘매개변수 설정’에서 로그 수준을 잠시 조정한 다음 요청을 다시 보내세요. 로그에는 도메인이나 주소 같은 정보가 포함될 수 있으므로 문제를 해결한 뒤에는 원래 설정으로 되돌리고, 공유하기 전에 민감한 내용을 가리세요.
자주 묻는 질문: 실패 지점에 따라 문제 범위 좁히기
실제 연결 테스트는 통과했는데 브라우저에서 접속할 수 없나요?
먼저 위의 명시적 프록시 명령을 실행하세요. 명령이 성공하면 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’이 적용됐는지 확인하고 브라우저 프록시 확장 프로그램을 잠시 끄세요. 명령도 실패한다면 활성 서버와 현재 라우팅, 요청 시점의 로그를 다시 확인하세요. 실제 연결 테스트의 주소와 브라우저에서 접속하는 대상은 다르므로 서로 대체할 수 없습니다.
127.0.0.1:10808 연결에 실패했다는 메시지가 표시되면 어떻게 하나요?
원격 노드의 지연 시간이 높은 게 아니라 로컬 진입점에 연결되지 않은 상태입니다. ‘설정’ → ‘매개변수 설정’에서 수신 포트를 확인한 다음 코어가 정상적으로 시작됐는지 살펴보세요. 로그에 주소가 이미 사용 중이라고 표시되면 PowerShell에서 Get-NetTCPConnection -LocalPort 10808 -State Listen을 실행해 포트를 사용 중인 프로세스를 확인할 수 있습니다. 프로세스의 정체를 확인한 뒤 조치하고, 알 수 없는 시스템 프로세스를 바로 종료하지 마세요.
시스템 프록시를 켠 뒤 모든 웹페이지에 접속할 수 없나요?
먼저 ‘시스템 프록시’에서 ‘시스템 프록시 해제’를 선택하고 직접 연결로 웹페이지가 다시 열리는지 확인하세요. 복구된다면 노드를 다시 테스트하고 로컬 포트를 확인하세요. 직접 연결도 여전히 되지 않으면 먼저 PC 네트워크를 점검해야 합니다. 클라이언트를 종료하기 전에도 시스템 프록시를 해제해야 앱이 더 이상 수신하지 않는 로컬 포트에 계속 연결하려는 상황을 막을 수 있습니다.
로그에 인증서 오류가 표시되는데 인증서 확인을 꺼도 되나요?
먼저 Windows ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 시스템 시간을 동기화한 다음 노드의 TLS 서버 이름이 서비스 제공자가 안내한 SNI와 일치하는지 확인하세요. 인증서 확인은 유지하고, 검증 건너뛰기를 일반적인 해결 방법으로 사용하지 마세요. 설정을 확신할 수 없다면 구독을 다시 업데이트하고 서비스 제공자에게 확인하세요.
첫 연결을 마쳤다는 기준은 어떤 스위치의 색이 바뀌었는지가 아닙니다. 반복 확인할 수 있는 근거가 있어야 합니다. 노드의 실제 연결 테스트가 연속으로 성공하고, 활성 서버가 명확하게 지정되어 있으며, 명시적 프록시 요청이 성공하고, 브라우저 접속 결과가 예상과 일치하며, 로그에도 해당 요청과 관련된 연결 오류가 없어야 합니다. 확인 후 평소 사용하는 분기 설정으로 되돌리고 일상적으로 쓰는 사이트를 테스트해 임시 점검 설정을 계속 사용하는 일을 방지하세요.
- 사용 가능한 예비 노드를 하나 남겨 두세요. 주 노드에 문제가 생기면 먼저 예비 노드로 전환해 다시 테스트합니다.
- 포트, 라우팅 프리셋, 실패 시간을 기록하되 구독 주소 전체를 저장하거나 공개하지 마세요.
- 분기 설정을 복구한 뒤 중국 본토 웹사이트에 직접 연결한 출구 주소가 표시되는 것은 의도한 결과일 수 있습니다. 모든 사이트에 같은 출구 주소가 표시되어야 하는 것은 아니므로 대상별 규칙에 따라 판단하세요.