v2rayN을 실행하고 노드도 선택했지만 브라우저가 시간 초과되거나, 일부 사이트가 열리지 않거나, 구독 업데이트에 실패하는 경우에 적용할 수 있습니다. 먼저 브라우저 요청이 로컬 프록시로 전달되는지 확인한 다음 DNS, 아웃바운드 규칙, 원격 연결을 점검하세요. Windows를 중심으로 로컬 포트, 명령 출력, 로그 시각을 근거로 문제 지점을 좁히며, 반복해서 재설치하거나 여러 설정을 한꺼번에 바꾸지 않습니다.
1. 커널 실행과 웹 연결 성공은 별개입니다
v2rayN은 클라이언트 인터페이스이며, 실제 연결은 선택한 커널이 처리합니다. 노드 선택, 커널 실행, 시스템 프록시 활성화, 웹사이트 접속은 각각 다른 단계입니다. 인터페이스에 실행 중으로 표시되더라도 로컬 프로그램이 동작 중이라는 뜻일 뿐, 원격 서버 인증이 완료됐거나 모든 앱이 프록시를 사용한다는 의미는 아닙니다.
노드 목록의 TCP 지연 시간도 웹 접속 테스트를 대신할 수 없습니다. TCP 연결이 성립했다면 해당 단계에서 연결 가능하다는 뜻일 뿐입니다. VLESS 또는 VMess 설정, TLS 핸드셰이크, 대상 사이트 접속은 여전히 실패할 수 있습니다. 프로토콜을 바로 바꾸기보다 먼저 어떤 범위에서 문제가 발생하는지 기록하세요.
- 모든 앱에서 인터넷이 안 되는 경우: 먼저 시스템 프록시를 잠시 해제하고 트래픽을 가로채는 TUN 모드를 종료한 뒤 일반 네트워크가 복구되는지 확인하세요.
- 브라우저에서만 문제가 생기는 경우: 브라우저 자체 프록시, 프록시 확장 프로그램, 보안 DNS 설정을 먼저 확인하세요.
- 일부 도메인만 접속되지 않는 경우: 전체 노드가 작동하지 않는다고 단정하지 말고 DNS, 라우팅 규칙 적용 여부, 대상 사이트 응답을 먼저 확인하세요.
- 노드를 바꾼 직후 문제가 생긴 경우: 변경 시각을 기록하고 해당 시각 이후의 커널 로그를 확인해 이전 연결이나 오류가 원인처럼 보이는 상황을 배제하세요.
2. 시스템 프록시와 브라우저 연결 경로 확인
시스템 프록시는 해당 설정을 따르는 앱이 요청을 전달할 위치를 정할 뿐, 모든 프로그램의 트래픽을 자동으로 처리하지는 않습니다. 브라우저에 별도의 프록시 확장 프로그램이 있으면 Windows 설정을 우회할 수 있으며, 터미널 도구는 명령줄 옵션이나 환경 변수만 읽을 수도 있습니다. 따라서 브라우저 접속 문제와 커널의 트래픽 전달 문제를 따로 확인해야 합니다.
-
활성 노드 설정
v2rayN 서버 목록에서 대상 항목을 마우스 오른쪽 버튼으로 클릭하고 「활성 서버로 설정」을 선택하세요. 하단의 활성 서버 정보가 바뀌었는지 확인한 다음 커널이 정상적으로 시작되는지 살펴보세요.
-
시스템 프록시 켜기
메인 화면 하단의 「시스템 프록시」 메뉴에서 「시스템 프록시 자동 설정」을 선택하세요. 트레이 아이콘의 해당 메뉴에서도 설정할 수 있습니다. 문제를 확인하는 동안에는 트래픽 경로가 헷갈리지 않도록 TUN을 함께 켜지 마세요.
-
프록시 주소 확인
Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 주소가 클라이언트의 수신 설정과 일치하는지 확인하세요. 일반적인 루프백 주소는
127.0.0.1이며, 포트는 실제 HTTP 또는 혼합 수신 포트와 같아야 합니다. -
브라우저 설정의 우회 여부 확인
브라우저 프록시 확장 프로그램을 잠시 끄고, 브라우저 자체 프록시는 시스템 프록시를 사용하도록 설정하세요. 브라우저를 완전히 종료한 뒤 다시 열고 같은 URL로 테스트하세요. DNS와 라우팅 설정은 동시에 바꾸지 마세요.
시스템 프록시를 해제했을 때 일반 사이트가 열리고 다시 켜면 모두 접속되지 않는다면 프록시 경로와 관련된 문제일 가능성이 있습니다. 그렇다고 노드를 사용할 수 없다고 단정할 수는 없습니다. 다음으로 로컬 포트가 실제로 열려 있는지, 브라우저에서 선택한 프로토콜이 수신 유형과 일치하는지 확인하세요.
3. 로컬 포트와 명시적 프록시 테스트로 문제 위치 찾기
v2rayN의 「설정」→「환경 설정」에서 로컬 수신 설정을 확인하세요. 메뉴와 항목 위치는 버전에 따라 다를 수 있습니다. 혼합 포트는 지원하는 여러 프록시 프로토콜을 받을 수 있지만, SOCKS 전용 수신 포트를 HTTP 프록시처럼 사용할 수는 없습니다. 아래 명령은 Windows 터미널에서 실행하며, HTTP 또는 혼합 수신 포트가 10808이라고 가정합니다.
netstat -ano | findstr :10808
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/
netstat 출력에서 로컬 주소, LISTENING 상태, PID를 확인하세요. 포트 번호가 보인다는 것만으로는 정상이라고 할 수 없습니다. 작업 관리자의 「세부 정보」에서 PID로 프로세스를 찾아 현재 클라이언트가 실행한 커널인지 확인하세요. 출처를 알 수 없는 시스템 프로세스를 임의로 종료하지 마세요.
| 결과 | 판단할 수 있는 내용 | 다음 조치 |
|---|---|---|
| 로컬 포트에서 수신 대기 중인 프로세스가 없음 | 요청이 아직 프록시 커널에 도달하지 않음 | 시작 로그, 설정 로드 오류, 포트 충돌 확인 |
| 명시적 프록시는 성공하지만 브라우저는 실패 | 테스트 대상까지 프록시 경로가 작동함 | 시스템 프록시, 브라우저 확장 프로그램, 브라우저 DNS 확인 |
| HTTP 403 또는 405 응답 수신 | HTTP 응답이 도착한 것으로, 연결 시간 초과와는 다름 | 인증서, 응답 헤더, 다른 사이트 결과를 함께 확인해 제한 원인 파악 |
| 직접 연결은 성공하지만 명시적 프록시는 시간 초과 | 문제가 프록시 경로에 집중됨 | 해당 요청의 DNS 조회, 아웃바운드, 핸드셰이크 로그 확인 |
정리: 앱의 연결 경로와 외부로 나가는 경로를 분리해 확인하세요
같은 URL을 명시적 프록시로 테스트했을 때 응답이 오는데 브라우저는 계속 시간 초과된다면 브라우저에서 로컬 포트까지의 연결을 먼저 해결하세요. 이 경우 구독을 반복해서 업데이트하거나 노드를 바꿔도 연결 경로 설정 문제는 대개 해결되지 않습니다.
수신 포트가 SOCKS만 지원한다면 --proxy socks5h://127.0.0.1:10808로도 테스트할 수 있습니다. 여기서 socks5h는 대상 도메인 조회를 프록시 측에 맡긴다는 뜻입니다. 로컬에서 도메인을 먼저 조회한 뒤 SOCKS로 전달하는 테스트와는 결과가 다를 수 있습니다.
4. DNS 문제를 두 단계로 나눠 확인
DNS는 대상 웹사이트에만 관련된 문제가 아닙니다. 노드 주소가 도메인이라면 커널은 보통 먼저 노드 도메인을 IP 주소로 변환해야 합니다. 이 단계에서 실패하면 프록시 연결을 시작할 수 없습니다. 대상 사이트의 도메인은 인바운드 유형, 라우팅, DNS 설정에 따라 로컬, 커널 설정의 리졸버, 원격에서 조회될 수 있습니다.
nslookup example.com
ipconfig /flushdns
nslookup으로 Windows의 기본 DNS 조회 경로를 확인할 수 있지만, v2rayN 내장 DNS를 거치지 않을 수 있고 브라우저의 보안 DNS도 검사하지 않습니다. 주소가 반환됐다는 것은 해당 조회에서 결과를 받았다는 뜻일 뿐, 현재 네트워크에 적합하거나 프록시 연결이 정상이라는 뜻은 아닙니다. 시스템 DNS 캐시를 지워도 브라우저와 커널에는 각각 별도의 캐시가 남아 있을 수 있습니다.
- 먼저 노드 도메인을 확인하세요: 노드 편집 창에서 서버 주소를 확인하고 공백이나 잘못된 문자가 없는지, 도메인이 여전히 유효한지 살펴보세요.
- 다음으로 대상 도메인을 확인하세요: 같은 대상에 대한 시스템 조회 결과와 커널 로그를 비교해 DNS 오류와 이후 연결 시간 초과를 구분하세요.
- 브라우저 보안 DNS를 확인하세요: 잠시 시스템 DNS를 사용하도록 바꿔 비교하고, 결과를 기록한 다음 사용할 조회 경로를 결정하세요.
- 커널 DNS 설정을 확인하세요: 현재 버전에 「설정」→「DNS 설정」이 있다면 리졸버 주소와 리졸버에 접근하는 경로를 확인하세요. 아직 연결되지 않은 동일한 프록시 연결에 노드 도메인 조회를 의존하게 만들지 마세요.
5. 라우팅 분기와 실제 아웃바운드 확인
시스템 프록시를 켰다고 해서 커널에 들어온 모든 요청이 프록시 서버를 경유하는 것은 아닙니다. 라우팅 규칙에 따라 도메인이나 주소가 직접 연결, 프록시, 차단 아웃바운드로 전달될 수 있습니다. 규칙은 보통 순서대로 적용되므로 앞쪽의 포괄적인 규칙이 뒤쪽의 세부 규칙보다 먼저 적용될 수 있습니다. IP 규칙의 적용 결과를 이해하려면 도메인 조회 방식도 함께 확인해야 합니다.
- 메인 화면 하단의 「라우팅」 메뉴에서 현재 프리셋을 기록하세요. 사용자 지정 규칙이 있다면 먼저 백업한 다음 테스트 대상이 프록시를 사용하도록 명확히 지정된 프리셋이나 규칙을 임시로 선택하세요.
- 대상 사이트 하나만 방문하고 시각을 기록하세요. 로그 상세 수준을 설정할 수 있다면 대상 도메인, 인바운드 연결, 선택된 아웃바운드 태그를 찾아 요청이 뜻하지 않게 직접 연결되거나 차단되지 않았는지 확인하세요.
- 사용자 지정 설정을 직접 수정했다면 규칙에서 참조하는 아웃바운드 태그가 실제로 존재하는지 확인하세요. 인터페이스에 표시되는 노드 이름과 커널의 아웃바운드 태그는 서로 다른 개념입니다.
- 원래 프리셋으로 되돌린 뒤 다시 테스트하세요. 규칙을 바꿨을 때만 차이가 재현된다면 규칙부터 수정하세요. 노드와 DNS를 동시에 바꾸지 마세요.
TUN은 가상 네트워크 어댑터, 라우팅 테이블, 권한도 관련되는 별도의 트래픽 경로입니다. 명시적 프록시는 정상인데 TUN만 실패한다면 브라우저의 시스템 프록시를 계속 조정하지 말고 TUN 시작 로그와 시스템 라우팅을 확인하세요. 두 모드를 따로 검증해야 네트워크 어댑터 문제를 프로토콜 문제로 오인하지 않습니다.
6. 오류 메시지 원문으로 노드와 구독 확인
로컬 수신과 앱의 연결 경로를 확인한 뒤 원격 연결을 점검하세요. 아래는 로그에 나타날 수 있는 오류 일부이며, 전체 메시지는 커널과 시스템에 따라 다를 수 있습니다. 키워드 하나만으로 결론 내리지 말고 앞뒤의 대상 주소와 시각을 함께 확인하세요.
오류: bind: address already in use
원인: 시작 시 바인딩하려는 주소나 포트가 이미 사용 중입니다. 해결: 로그에 나온 포트의 PID를 조회하고 중복 실행된 인스턴스를 종료하거나 수신 포트를 바꾼 뒤 시스템 프록시도 같은 포트로 업데이트하세요.
오류: connection refused
원인: 대상 포트에서 연결을 거부했습니다. 로컬 수신 포트일 수도 있고 원격 노드일 수도 있습니다. 해결: 오류에 표시된 IP와 포트를 먼저 확인하세요. 로컬 주소라면 커널 상태를, 원격 주소라면 서버 포트와 서비스 상태를 점검하세요.
오류: no such host
원인: 해당 시점에 사용한 DNS 경로에서 도메인 주소를 확인하지 못했습니다. 해결: 오류에 나온 도메인이 노드인지 대상 사이트인지 확인한 뒤 관련 리졸버, 도메인 표기, DNS 접근 경로를 점검하세요.
오류: context deadline exceeded
원인: 특정 작업이 제한 시간 안에 완료되지 않았습니다. 이 메시지만으로는 DNS, 연결, 핸드셰이크 중 어느 단계인지 알 수 없습니다. 해결: 앞뒤 로그로 단계를 확인하고 같은 테스트 대상에 알려진 정상 노드를 사용해 비교하세요.
노드를 편집할 때는 서비스 제공업체가 현재 안내하는 서버 주소, 포트, 사용자 ID, 전송 방식, TLS, 서버 이름을 하나씩 대조하세요. VMess와 VLESS는 서로 다른 프로토콜이므로 프로토콜 이름만 바꾸고 나머지 필드를 그대로 사용할 수 없습니다. REALITY가 포함된 설정은 공개 키, Short ID 등의 매개변수와 현재 사용 중인 커널의 설정 지원 여부도 확인해야 합니다.
인증서 유효 기간이나 핸드셰이크 오류는 시스템 시각이 맞지 않아 발생할 수도 있습니다. Windows 「설정」→「시간 및 언어」→「날짜 및 시간」에서 자동 시간 설정을 확인하고 동기화하세요. 주소나 시간 오류를 숨기려고 인증서 검증을 끄지 마세요.
- 구독에 노드가 표시된다고 해서 아직 유효한 것은 아닙니다: 최근 업데이트 결과, 서비스 이용 기간, 트래픽 한도를 확인하고 기존 노드가 교체되지 않았는지 살펴보세요.
- 구독 업데이트 실패가 웹 프록시 실패를 뜻하지는 않습니다: 업데이트 요청은 다른 경로를 사용할 수 있습니다. 현재 버전에서 프록시를 통한 업데이트 옵션을 확인하세요.
- 로그를 공유하기 전에 민감 정보를 가리세요: 구독 URL, 사용자 ID, 인증 정보를 숨기고 시각, 오류 메시지, 필요한 포트 정보만 남기세요.
7. 자주 묻는 질문과 복구 확인
지연 시간이 80ms인데 웹페이지가 계속 시간 초과되는 이유는 무엇인가요?
여기서 80ms는 가정한 TCP 테스트 결과이지 실제 웹페이지 로딩 시간이 아닙니다. 어떤 방식으로 테스트했는지 확인한 뒤 명시적 프록시 요청을 실행하세요. TCP 연결이 가능해도 사용자 인증, TLS 핸드셰이크, 대상 사이트 접속 단계에서 실패할 수 있습니다.
포트를 바꿨는데도 브라우저가 연결되지 않는 이유는 무엇인가요?
「시스템 프록시」에서 설정을 먼저 해제한 다음 「시스템 프록시 자동 설정」을 선택하고 Windows 프록시 포트를 확인하세요. 브라우저 확장 프로그램에 이전 포트가 고정되어 있다면 확장 프로그램 설정도 바꾸고 브라우저를 다시 시작해야 합니다.
v2rayN을 종료했더니 일반 웹페이지도 열리지 않아요. 어떻게 해야 하나요?
Windows 「설정」→「네트워크 및 인터넷」→「프록시」에서 로컬 수신 서비스가 종료된 수동 프록시를 끄세요. TUN을 켰었다면 비활성화됐는지도 확인하세요. 기본 네트워크를 복구한 뒤 클라이언트를 실행해 각 항목을 차례로 점검하세요.
모든 설정을 삭제하고 다시 설치해야 하나요?
먼저 삭제하지 마세요. 현재 설정을 저장하고 오류를 기록하세요. 설정을 불러올 수 없거나 프로그램 파일이 누락됐거나 명확한 호환성 문제가 있을 때만 다운로드 센터에서 적절한 버전을 받아 비교하세요. 재설치만으로는 사용할 수 없는 노드나 잘못된 구독이 자동으로 복구되지 않습니다.
문제를 해결한 뒤 같은 URL로 브라우저 접속과 명시적 프록시 테스트를 반복하고, 평소 사용하는 사이트도 추가로 확인하세요. 기존 라우팅, 브라우저 확장 프로그램, TUN 설정은 하나씩 복원하고 매번 테스트하세요. 특정 설정을 복원했을 때 문제가 다시 발생하면 재현 가능한 근거로 기록해 계속 점검하세요.
- 예상한 커널이 로컬 포트에서 수신 중이고 시스템 프록시가 올바른 주소와 포트를 가리킵니다.
- 대상 요청에서 정상적인 응답을 받고, 로그에 연결 또는 DNS 오류가 반복되지 않습니다.
- 클라이언트를 다시 시작한 뒤에도 접속할 수 있으며, 종료 후 시스템 네트워크 상태도 예상대로 돌아옵니다.