v2rayN 연결됨으로 표시되지만 웹페이지가 열리지 않을 때: 8단계 점검 목록

1단계: 노드 선택, 커널 실행, 요청 성공을 구분하세요

v2rayN은 그래픽 클라이언트이며, 실제 프록시 요청은 선택한 커널이 처리합니다. 화면에서 노드가 선택되어 있거나 시스템 프록시가 설정되어 있는 것, 지연 시간 테스트에 숫자가 표시되는 것만으로는 브라우저의 HTTPS 요청이 노드를 통해 전달됐다고 볼 수 없습니다. 일반적인 TCP 지연 시간 테스트는 특정 주소와 포트에 연결할 수 있는지만 확인하며, 인증, TLS, REALITY, 최종 웹사이트까지 이어지는 전체 연결을 검증하지는 않습니다.

먼저 네트워크 연결을 가로채는 다른 프로그램을 종료하고, v2rayN의 TUN 모드를 잠시 끈 뒤 ‘시스템 프록시 + 로컬 진입점’을 기준으로 테스트하세요. 시스템 프록시와 TUN 모드는 연결을 처리하는 범위가 다르며, 동시에 사용하면 라우팅과 DNS 변수가 늘어납니다. 회사 프록시나 인증이 필요한 네트워크라면 먼저 네트워크 로그인을 완료하세요. 조직에서 요구하는 설정을 임의로 제거하지 마세요.

1. 시스템 프록시를 잠시 해제한 뒤 평소 직접 접속되는 웹사이트를 열어 기본 네트워크가 정상인지 확인하세요.
2. 점검할 노드를 선택해 활성 서버로 설정한 다음, 커널 시작 로그에 설정 오류나 리스닝 오류가 있는지 확인하세요.
3. 현재 클라이언트 버전, 실제 커널 이름과 버전, 테스트 URL 및 시간을 기록하고 이후에도 동일한 조건으로 다시 테스트하세요.

시스템 프록시를 해제한 뒤에도 인터넷에 전혀 연결되지 않으면 먼저 Wi-Fi, 게이트웨이, 네트워크 인증, 시스템 DNS를 확인하세요. 이 경우 VLESS, VMess 또는 구독 그룹을 계속 바꿔도 기본 네트워크 문제는 해결되지 않는 경우가 많습니다.

2단계: 시스템 프록시 주소와 로컬 진입점 확인

v2rayN 트레이 메뉴에서 ‘시스템 프록시’를 찾아 ‘시스템 프록시 자동 구성’을 선택하세요. 버전에 따라 메뉴 이름은 조금 다를 수 있습니다. 중요한 점은 노드만 선택하는 것이 아니라 Windows 프록시 서버 주소가 실행 중인 로컬 진입점을 가리키도록 하는 것입니다. 이어서 Windows ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 주소와 포트를 확인하세요.

여기서 10808은 예시일 뿐, 모든 버전에 고정된 기본값이 아닙니다. ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 관련 항목을 확인하고, 시작 로그나 실제 설정을 기준으로 삼으세요. 버전에 따라 SOCKS와 HTTP 진입점을 구분하거나 혼합 진입점을 사용할 수 있습니다. Windows 수동 프록시에는 HTTP 프록시 요청을 처리할 수 있는 진입점을 지정해야 합니다. SOCKS만 지원하는 포트를 임의로 입력하면 안 됩니다.

• 프록시 주소에는 로컬 루프백 주소를 입력하세요. 원격 노드 도메인이나 구독 URL을 입력하면 안 됩니다.
• 로컬 진입점 포트와 노드 서버 포트는 서로 다른 항목이며, 포트 번호가 같을 필요는 없습니다.
• 자동 구성 스크립트와 수동 프록시에 다른 프로그램의 설정이 남아 있는지 확인해 브라우저가 이전 스크립트를 계속 사용하지 않도록 하세요.
• 명령줄 도구와 일부 앱은 Windows 시스템 프록시를 따르지 않으므로 프록시를 별도로 지정해야 합니다. 이런 앱의 연결 실패만으로 노드가 작동하지 않는다고 판단할 수는 없습니다.

3단계: 포트 리스닝과 프로세스 점유 확인

시스템 프록시 주소가 올바르더라도 로컬 포트에서 요청을 받는 서비스가 없으면 웹페이지가 열리지 않습니다. PowerShell을 열고 아래 명령을 실행하세요. 실제 포트가 10808이 아니라면 명령의 숫자를 먼저 바꾸세요.

netstat -ano | findstr ":10808"
Get-NetTCPConnection -LocalPort 10808 -State Listen

로컬 주소, LISTENING 상태, 프로세스 ID를 확인하세요. 리스닝 항목이 없다면 먼저 커널이 종료됐는지 살펴보세요. 리스닝이 확인되더라도 현재 v2rayN이 실행한 커널이 해당 포트를 사용 중인지 확인해야 합니다. 작업 관리자의 ‘세부 정보’에서 PID를 대조하고, 필요하다면 ‘명령줄’ 열을 표시해 프로그램 경로를 확인하세요.

정체를 알 수 없는 시스템 프로세스를 무작정 종료하지 마세요. 포트 충돌을 해결한 뒤 현재 커널을 다시 시작하고 리스닝 상태를 확인하세요. 커널이 포트를 정상적으로 열지 못한 상태에서 시스템 프록시만 바꿔도 문제는 그대로 남습니다.

4단계: 시간 동기화와 노드 핸드셰이크 매개변수 확인

로컬 진입점은 정상인데 모든 요청이 연결 단계에서 실패한다면 노드 매개변수와 기기 시간을 확인하세요. Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 자동 시간 설정을 켜고 ‘지금 동기화’를 누르면 됩니다. 실제 날짜와 시계를 확인하세요. 시간대 표시만 바꾸는 것은 시스템 시간을 정확하게 맞추는 것과 다릅니다.

구독 업데이트가 성공했다는 것은 설정을 가져왔다는 뜻일 뿐, 노드가 여전히 서비스 중이거나 현재 커널이 모든 필드를 지원한다는 의미는 아닙니다. 가져온 뒤 일부 필드가 사라진다면 클라이언트가 실제로 실행하는 커널과 설정 형식을 먼저 확인한 다음 설정 제공자에게 문의하세요. REALITY 등의 기능은 해당 Xray 버전의 지원 범위를 기준으로 확인해야 합니다. V2Fly와 Xray를 완전히 동일한 커널로 간주하면 안 됩니다.

• 신뢰할 수 있는 설정 소스에서 노드를 다시 가져와 기존 항목과 비교하면 수동 수정 중 필드를 빠뜨리는 일을 줄일 수 있습니다.
• 인증서 검증 해제를 일반적인 해결책으로 사용하지 마세요. 인증서 오류가 발생하면 먼저 시간, 서버 이름, 서버 인증서 체인을 확인하세요.
• 같은 노드가 다른 기기에서 작동한다면 노드 이름만 비교하지 말고 실제 매개변수와 커널 버전을 대조하세요.

5단계: DNS 문제와 프록시 연결 문제 구분

‘도메인이 열리지 않는다’고 해서 반드시 DNS 오류인 것은 아닙니다. 노드 도메인에 연결할 때는 도메인 조회가 필요하고, 직접 연결되는 대상은 로컬에서 조회될 수 있으며, 프록시 대상의 조회 위치는 커널과 아웃바운드 설정에 따라 달라집니다. 각 단계에서 서로 다른 DNS 서버를 사용할 수 있습니다. 브라우저 보안 DNS, Windows DNS, 커널 DNS 역시 각각 별개의 설정입니다.

먼저 Windows 기본 제공 도구인 curl.exe에서 프록시를 명시해 브라우저 설정을 우회하세요. 아래 테스트의 제한 시간은 15초이며, 응답과 오류가 발생하는 단계를 확인하는 용도입니다. 특정 상태 코드를 보장하거나 속도를 측정하는 테스트는 아닙니다. 포트는 실제로 HTTP 프록시를 지원하는 로컬 진입점으로 바꾸세요.

curl.exe -I --connect-timeout 10 --max-time 15 --proxy http://127.0.0.1:10808 https://www.example.com/

Resolve-DnsName www.example.com

첫 번째 명령은 지정한 진입점을 통한 요청을 확인합니다. 두 번째 명령은 현재 Windows 시스템의 DNS 조회 경로만 확인할 뿐, 커널 DNS가 정상이라고 증명하지는 않습니다. SOCKS의 로컬 조회와 프록시 측 조회를 비교하려면 진입점이 SOCKS를 지원하는지 확인한 뒤 아래 두 명령을 사용할 수 있습니다.

curl.exe -I --max-time 15 --socks5 127.0.0.1:10808 https://www.example.com/
curl.exe -I --max-time 15 --socks5-hostname 127.0.0.1:10808 https://www.example.com/

DNS를 조정한 뒤 ipconfig /flushdns를 실행해 Windows DNS 캐시를 지우고, 브라우저와 커널도 다시 시작해 각각의 캐시 영향을 배제하세요. HTTPS 대상 주소를 임의로 IP로 바꿔 테스트하지 마세요. 인증서 이름, SNI, 웹사이트 가상 호스트가 달라져 새로운 오류가 생길 수 있습니다.

6단계: 라우팅 분기와 기본 아웃바운드 확인

명시적 프록시 테스트에서는 같은 노드가 정상인데 브라우저에서 일부 도메인만 실패한다면 해당 요청이 직접 연결이나 차단 아웃바운드로 라우팅되는 경우가 흔합니다. v2rayN의 라우팅 설정에서 현재 규칙 세트, 매칭 순서, 기본 아웃바운드를 확인하세요. 메뉴 위치는 버전에 따라 다르므로 화면의 ‘라우팅 설정’ 또는 라우팅 구성 항목을 찾으면 됩니다.

1. 현재 라우팅 설정 이름을 기록하고 사용자 지정 규칙을 먼저 백업하세요.
2. 대상 요청을 프록시 아웃바운드로 보내는 라우팅 모드를 임시로 선택하고 같은 URL로 다시 테스트하세요. ‘시스템 프록시 자동 구성’만으로 모든 요청이 프록시를 거치는 것은 아닙니다.
3. 정상으로 돌아왔다면 기존 규칙으로 되돌아가 도메인 규칙, IP 규칙, 차단 항목, 기본 아웃바운드를 확인하세요.
4. 사용자 지정 규칙을 한 그룹씩 복원해 실패가 재현될 때까지 확인한 다음, 문제가 되는 매칭 항목을 찾아 수정하세요.

도메인 조회 시점에도 도메인 전략이 영향을 줍니다. AsIs, IPIfNonMatch, IPOnDemand는 조회 시점이 서로 다르며, ‘적극적으로 조회할수록 더 안정적’이라고 볼 수 없습니다. IP 규칙에 조회 결과가 필요한 경우 DNS 응답이 아웃바운드 선택에 사용됩니다. 조회 오류와 지나치게 광범위한 규칙이 겹치면 요청이 잘못된 출구로 전달될 수 있습니다.

7단계: 브라우저 확장 프로그램과 별도 프록시 설정 확인

프록시를 명시한 curl.exe에서는 대상 사이트 응답을 받지만 브라우저에서만 실패한다면 브라우저 쪽을 집중적으로 확인하세요. 방문 기록을 모두 지우기보다 임시 브라우저 프로필로 같은 URL을 열면 기존 상태를 더 잘 보존할 수 있습니다. 시크릿 창도 완전히 깨끗한 환경은 아니며, 일부 확장 프로그램은 시크릿 창에서도 실행되도록 허용할 수 있습니다.

• 프록시 확장 프로그램: 프록시 전환 확장 프로그램을 잠시 비활성화해 Windows 시스템 프록시를 덮어쓰거나 이전 포트를 계속 사용하는 일이 없도록 하세요.
• 별도 프록시: Firefox에서 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 열고, 더 이상 작동하지 않는 수동 프록시가 지정되어 있지 않은지 확인하세요.
• 보안 DNS: 현재 모드를 기록한 뒤 시스템 DNS 조회 경로와 비교 테스트를 하세요. 커널 DNS와 브라우저 DNS를 동시에 변경하지 마세요.
• 캐시 및 연결: 브라우저 프로세스를 완전히 종료한 뒤 다시 실행하세요. 탭만 새로 고치면 이전 연결이나 캐시 결과가 계속 사용될 수 있습니다.
• 보안 소프트웨어: 커널 프로그램이나 로컬 프록시 연결을 차단하는지 확인하세요. 먼저 로그를 살펴보고 필요한 연결만 허용하세요. 보호 기능을 계속 꺼 두지 마세요.

특정 웹사이트 하나만 실패한다면 다른 HTTPS 사이트와 비교하세요. 사이트 자체 장애, 계정 접근 제한, 접속 IP 제한, 인증서 문제도 ‘페이지가 열리지 않음’으로 나타날 수 있습니다. 한 사이트만으로 노드 전체의 상태를 판단할 수는 없습니다. 웹사이트에서 HTTP 오류 상태 코드가 돌아왔다면 일반적으로 해당 요청은 응답을 반환할 수 있는 서버나 중간 장치까지 도달한 것입니다.

8단계: 같은 시점의 로그를 대조한 뒤 네트워크 비교 테스트

마지막으로 로그를 자세히 살펴보세요. 먼저 웹페이지를 클릭한 시간을 기록하고 해당 시각 전후의 커널 로그를 확인하세요. 평소에는 warning 수준으로 두고, 문제 해결 중에는 잠시 info로 높이세요. 필요할 때만 짧게 debug를 사용하세요. 로그 수준을 높이면 대상 도메인과 연결 정보가 포함될 수 있으므로 점검이 끝나면 원래 설정으로 되돌리세요.

다음 비교에서는 조건을 하나만 바꾸세요. 같은 컴퓨터와 노드를 유지한 채 모바일 핫스팟으로 바꾸면 기존 네트워크의 제한 여부를 파악하는 데 도움이 됩니다. 또는 같은 네트워크에서 정상 작동이 확인된 다른 노드를 사용해 노드 서비스 상태를 비교하세요. 네트워크, 프로토콜, DNS, 커널을 동시에 바꾸면 문제가 해결되더라도 어느 변경이 효과가 있었는지 알 수 없습니다.