v2rayN 연결됨으로 표시되지만 웹페이지가 열리지 않을 때: 시스템 프록시·라우팅·DNS 점검

이 글의 핵심

v2rayN을 실행하고 노드를 선택했는데도 웹페이지가 열리지 않는 데스크톱 사용자에게 적합합니다. 먼저 브라우저 요청이 로컬 코어에 전달되는지 확인한 뒤, 라우팅 분기와 도메인 조회, 원격 연결을 점검하세요. 한 번에 하나씩만 변경하고 같은 주소로 다시 테스트하면 됩니다. 포트 확인과 명령줄 요청, 로그를 함께 살펴보면 시스템 프록시 미적용, 코어 미실행, 노드 연결 불가를 구분할 수 있어 클라이언트를 반복해서 재설치할 필요가 없습니다.

1. 연결 상태만 보지 말고 시스템 프록시 확인하기

먼저 ‘시스템 프록시’가 ‘시스템 프록시 자동 설정’으로 되어 있는지 확인하세요. 클라이언트가 실행 중이고 노드 이름이 표시되거나 지연 시간 테스트에 응답이 있더라도, 브라우저가 프록시를 사용한다는 뜻은 아닙니다. v2rayN은 설정과 관리 인터페이스이며, 로컬 요청을 받아 원격 서버에 연결하는 것은 코어입니다. 앱의 진입 경로와 코어 상태를 모두 확인해야 합니다.

아래 메뉴 이름은 일반적인 중국어 인터페이스를 기준으로 합니다. 데스크톱 버전에 따라 메뉴 위치가 다를 수 있습니다. 하단 메뉴를 찾을 수 없다면 작업 표시줄 알림 영역의 v2rayN 아이콘을 마우스 오른쪽 버튼으로 클릭해 같은 이름의 메뉴를 확인하세요. 먼저 현재 설정을 기록하고 TUN 모드는 잠시 끈 뒤 시스템 프록시 경로만 점검하세요. 두 가지 연결 방식이 동시에 적용되는 상황을 피할 수 있습니다.

직접 연결 확인

v2rayN의 ‘시스템 프록시’에서 ‘시스템 프록시 해제’를 선택하고, 평소 바로 접속되는 웹사이트를 열어 보세요. 이때도 접속되지 않는다면 먼저 컴퓨터의 인터넷 연결, 무선 네트워크 인증 또는 상위 네트워크 문제를 해결하세요.
사용할 노드 지정

메인 화면에서 대상 노드를 선택한 뒤 마우스 오른쪽 버튼을 눌러 ‘활성 서버로 설정’을 선택하세요. 코어가 시작될 때까지 기다립니다. 하단 로그에 시작 실패가 바로 표시되면 다음 절에서 포트를 확인하세요.
시스템 프록시 사용

‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 클릭하세요. Windows의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 프록시 주소가 로컬 컴퓨터를 가리키는지, 포트가 클라이언트의 인바운드 설정과 일치하는지 확인하세요.
별도 프록시 설정 해제

브라우저 확장 프로그램과 브라우저 자체의 프록시 설정을 확인하세요. 별도로 지정한 프록시가 있다면 먼저 비활성화한 다음 브라우저를 완전히 종료했다가 다시 열고 같은 주소로 테스트하세요.

2. 로컬 포트와 코어의 수신 상태 확인하기

시스템 프록시 포트는 코어가 실제로 수신 대기 중인 포트와 일치해야 합니다. v2rayN에서 ‘설정’ → ‘매개변수 설정’을 열고 로컬 인바운드의 수신 주소, 포트, 프로토콜 유형을 확인하세요. 버전에 따라 ‘Core: 기본 설정’이나 인바운드 관련 탭에 있을 수 있습니다. 원격 노드의 서버 포트를 시스템 프록시에 입력하면 안 됩니다.

127.0.0.1

원격 노드 주소가 아닌 로컬 루프백 주소

10808

아래 명령의 로컬 포트 예시는 설정값에 맞춰 바꾸세요

443

HTTPS에서 흔히 사용하는 대상 포트이며, 고정된 인바운드 포트가 아닙니다

아래 명령은 Windows PowerShell에서 사용할 수 있습니다. 클라이언트의 HTTP 또는 혼합 인바운드 포트가 10808이라고 가정합니다. 실제 포트가 다르면 명령의 숫자를 먼저 바꾸세요. SOCKS 인바운드만 사용하는 경우에는 여기의 HTTP 프록시 테스트를 그대로 실행하지 마세요.

Test-NetConnection 127.0.0.1 -Port 10808
netstat -ano | findstr ":10808"
curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:10808 https://www.example.com/

TcpTestSucceeded : True는 로컬 포트에 연결할 수 있다는 뜻일 뿐, 원격 노드나 DNS, 대상 웹사이트가 정상이라는 의미는 아닙니다.
netstat에서 LISTENING 행과 마지막 열의 PID를 확인한 다음, 작업 관리자의 ‘세부 정보’ 탭에서 프로세스를 대조하세요. 포트 번호만 보고 정체를 모르는 프로세스를 종료하지 마세요.
프록시 요청에서 HTTP 상태 코드가 반환되면 요청에 응답이 온 것입니다. 403은 웹사이트 정책 때문일 수도 있으므로 로컬 포트 문제로 분류하면 안 됩니다. 200 Connection established만 확인한 것으로는 이후 TLS 연결과 웹페이지 요청이 성공했다고 볼 수 없습니다.
포트가 수신 대기 중이 아니라면 클라이언트 로그에서 시작 오류를 확인하세요. 다른 로컬 프록시 프로세스가 해당 포트를 사용 중이라면 중복 프로세스를 종료하거나 인바운드 포트를 변경한 뒤 시스템 프록시를 다시 설정하세요.

판단 기준: 명령은 성공하지만 브라우저는 실패한다면 앱 진입 경로부터 점검

로컬 프록시를 명시한 요청은 성공하는데 브라우저에서 같은 주소가 열리지 않는다면 브라우저 프록시, 시스템 프록시, 확장 프로그램 설정을 먼저 확인하세요. 이 경우 구독 설정이나 DNS를 계속 바꿔도 진입 경로가 일치하지 않는 문제는 보통 해결되지 않습니다.

3. 라우팅 분기 때문에 요청이 잘못된 경로로 나가는지 확인하기

로컬 포트가 정상이라면 ‘라우팅’을 확인하세요. 라우팅 분기란 규칙에 따라 요청을 프록시, 직접 연결 또는 차단으로 보내는 것을 말합니다. 브라우저 요청이 코어에 전달되더라도 선택한 노드를 거친다는 보장은 없습니다. 사용자 지정 규칙에 따라 특정 도메인이 직접 연결되거나 차단될 수도 있습니다.

현재 라우팅 설정 이름을 기록하세요. ‘전역’ 또는 ‘전역 프록시’ 프리셋이 있다면 잠시 전환한 뒤 같은 오류 주소로 다시 테스트하세요. 여기서 바꾸는 것은 라우팅 설정이지 TUN 모드가 아닙니다.
전역 프록시에서는 정상이고 기존 모드에서만 실패한다면 원래 설정으로 돌아간 뒤 대상 도메인이 사용자 지정 직접 연결, 차단 규칙 또는 범위가 너무 넓은 도메인 접미사 규칙에 해당하는지 확인하세요.
로그에서 라우팅 정보를 표시할 수 있다면 요청 시각을 기준으로 대상 도메인을 찾아 실제 아웃바운드 태그를 확인하세요. 로그에 관련 항목이 없다면 목록에 표시된 노드 이름만으로 트래픽 경로를 판단하지 마세요.
규칙을 수정한 뒤 원래 모드로 복원하세요. 직접 연결되어야 하는 웹사이트와 프록시를 사용해야 하는 웹사이트를 각각 테스트해, 국소적인 문제를 새로운 라우팅 오류로 바꾸지 않았는지 확인하세요.

4. 시스템 DNS, 코어 DNS, 노드 도메인 조회를 구분하기

DNS는 도메인 이름을 IP 주소로 변환하는 과정입니다. 최소한 두 종류의 도메인을 구분해야 합니다. 하나는 원격 노드 서버의 도메인이고, 다른 하나는 접속하려는 웹사이트의 도메인입니다. 노드 도메인을 조회하지 못하면 코어가 노드에 연결하지 못할 수 있습니다. 웹사이트 도메인 조회에 실패하면 일부 사이트만 영향을 받을 수 있습니다. 시스템 DNS와 코어 DNS도 반드시 같은 설정을 사용하는 것은 아닙니다.

Windows에서는 아래 두 명령으로 시스템의 DNS 조회 결과를 확인하고 시스템 캐시를 비울 수 있습니다. 두 번째 명령은 로컬 시스템 DNS 캐시만 지우며, 코어 설정을 초기화하거나 브라우저의 자체 DNS 캐시를 자동으로 비우지는 않습니다.

Resolve-DnsName www.example.com
ipconfig /flushdns

시스템 DNS 조회 성공: 현재 시스템 확인자가 결과를 반환했다는 뜻일 뿐, 코어가 같은 조회 경로를 사용하거나 해당 결과가 현재 네트워크에 적합하다는 의미는 아닙니다.
노드 도메인 조회 실패: 먼저 노드 주소에 오타가 없는지 확인한 다음 프록시 연결을 설정할 때 사용하는 DNS 경로를 점검하세요. 확인자에 접근하려면 아직 연결되지 않은 프록시가 필요한 경우 시작 단계에서 의존성 순환이 발생할 수 있습니다.
DNS 변경: ‘설정’ → ‘DNS 설정’에서 현재 코어에 해당하는 옵션을 확인하세요. 해당 버전에서 DNS가 ‘매개변수 설정’에 있다면 관련 탭으로 이동합니다. 먼저 기존 값을 저장하고 한 번에 한 설정 묶음만 변경한 뒤, 화면 안내에 따라 저장하고 코어를 다시 시작하세요.
IP 주소로 웹사이트 주소를 바꾸지 마세요: HTTPS 웹사이트는 보통 인증서 검증과 사이트 선택에 도메인 이름을 사용합니다. IP 주소로 접속에 실패해도 DNS 문제라는 확실한 증거가 되지는 않습니다.

SOCKS 인바운드가 설정되어 있음을 확인했다면 아래 방법으로 SOCKS 프록시에 대상 도메인 전달을 맡겨 프록시 경로에서 조회하게 할 수도 있습니다. 명령의 10808은 실제 SOCKS 또는 혼합 인바운드 포트와 일치해야 합니다. 시스템에서 직접 조회한 결과와 비교할 수는 있지만, 이것만으로 모든 DNS 조회가 어느 단계에서 이루어지는지 확정할 수는 없습니다.

curl.exe -I --connect-timeout 10 --max-time 20 --socks5-hostname 127.0.0.1:10808 https://www.example.com/

5. 로그 원문으로 노드와 핸드셰이크 오류 찾기

진입 경로와 포트, 라우팅, DNS를 모두 확인한 뒤 노드를 테스트하세요. 클라이언트 하단 로그나 ‘로그’ 메뉴를 열고 요청이 발생한 시각을 기록한 다음 오류를 다시 재현합니다. 아래는 나타날 수 있는 오류 예시입니다. 앞뒤 내용은 코어와 시스템에 따라 달라질 수 있으므로 마지막 단어만 보고 결론을 내리지 마세요.

오류: bind: address already in use

원인 및 해결: 코어가 수신 대기하려는 로컬 주소나 포트를 이미 다른 프로세스가 사용 중입니다. 포트 조회로 프로세스를 확인하고 중복 클라이언트를 종료하거나 로컬 인바운드 포트를 변경하세요. 그런 다음 시스템 프록시 설정을 다시 적용합니다.

오류: connection refused

원인 및 해결: 대상 엔드포인트에서 연결을 거부했습니다. 오류가 로컬 주소를 가리키는지 원격 주소를 가리키는지 먼저 확인하세요. 로컬 주소라면 수신 상태를, 원격 주소라면 노드 포트와 서비스 상태를 점검해야 합니다. 모든 경우를 DNS 문제로 보면 안 됩니다.

오류: lookup …: no such host

원인 및 해결: 특정 도메인을 사용할 수 있는 주소로 조회하지 못했습니다. 생략된 부분에는 실제로 조회한 도메인이 표시됩니다. 먼저 노드 도메인인지 웹사이트 도메인인지 구분한 뒤 철자, DNS 설정, 확인자 연결 상태를 확인하세요.

오류: i/o timeout

원인 및 해결: 네트워크 작업 중 한 단계에서 응답 대기 시간이 초과되었습니다. 앞에 표시된 대상 주소를 바탕으로 DNS, 원격 연결, 응답 읽기 중 어느 단계에서 시간 초과가 발생했는지 확인하세요. 이미 정상임을 확인한 다른 노드와 비교해 볼 수 있지만, 이 로그 한 줄만으로 계정이 만료됐다고 단정할 수는 없습니다.

오류: x509: certificate has expired or is not yet valid

원인 및 해결: 인증서 유효 기간 확인에 실패했습니다. 로컬 컴퓨터의 시각이나 서버 인증서가 원인일 수 있습니다. 먼저 시스템의 ‘날짜 및 시간’에서 시각을 맞추세요. 시간이 정확한데도 실패한다면 서비스 제공자에게 인증서를 확인해 달라고 요청하세요. 인증서 검증을 끄지 마세요.

노드를 바꿀 때는 라우팅 설정과 테스트 주소를 그대로 유지하고 활성 노드만 변경하세요. TCP 지연 테스트에 결과가 나온다는 것은 특정 포트 연결에 응답이 있었다는 뜻일 뿐, 프로토콜 인증과 TLS 핸드셰이크, 웹페이지 요청이 모두 성공했다는 의미는 아닙니다. 클라이언트의 연결 가능성 또는 실제 연결 테스트를 사용하더라도 테스트 대상이 실제 접속하려는 웹사이트와 다를 수 있습니다.

특정 노드만 실패한다면 구독을 업데이트했는지, 계정의 트래픽 한도와 만료 상태, 서비스 공지를 확인하세요.
모든 노드가 갑자기 실패한다면 다른 네트워크에서 한 번 비교해 보세요. 예를 들어 컴퓨터를 잠시 휴대폰 핫스팟에 연결할 수 있습니다. 비교하는 동안 코어와 DNS를 동시에 변경하지 마세요.
VLESS와 VMess는 설정 항목이 서로 다릅니다. REALITY를 사용하는 노드는 제공자가 지정한 공개 키, 서버 이름 및 기타 매개변수도 일치해야 합니다. 알 수 없는 항목을 비워 두거나 추측해서 입력하지 마세요.
‘설정’ → ‘매개변수 설정’에서 코어 유형 관련 옵션을 확인하고 사용 중인 코어가 해당 설정을 지원하는지 살펴보세요. 코어를 바꾸는 것이 만능 해결책은 아닙니다. 먼저 기존 옵션을 기록한 뒤 시작 로그를 확인하세요.

6. 자주 나타나는 증상과 복구 확인

지연 시간이 수십 밀리초인데도 웹페이지가 열리지 않는 이유는 무엇인가요?

지연 시간 테스트에 웹페이지 요청 전체가 포함되지 않을 수 있습니다. 먼저 로컬 프록시를 명시한 명령을 실행한 다음 같은 시각의 로그를 확인하세요. 포트에는 연결되지만 핸드셰이크에 실패한다면 프로토콜 매개변수와 시스템 시각, 노드 상태를 점검하세요. 지연 시간 순으로 노드를 계속 바꾸는 것은 도움이 되지 않습니다.

웹사이트 하나만 열리지 않아도 재설치해야 하나요?

먼저 재설치하지 마세요. 현재 노드를 유지한 채 다른 웹사이트를 테스트한 다음, 전역 프록시로 잠시 전환해 문제가 있던 사이트를 다시 열어 보세요. 다른 사이트는 정상이라면 대상 사이트 상태, 도메인 규칙, DNS, 해당 사이트의 접속 경로 제한을 먼저 확인하세요.

브라우저는 되는데 다른 앱은 연결되지 않나요?

먼저 해당 앱의 네트워크 설정에서 ‘시스템 프록시 사용’이나 별도 프록시 설정을 찾아보세요. 수동 프록시를 지원한다면 로컬 주소와 실제 인바운드 포트를 입력하고 HTTP 또는 SOCKS 유형을 맞추세요. 명령줄 도구도 별도 설정이 필요할 수 있으므로 모두 시스템 프록시를 읽는다고 가정하면 안 됩니다.

클라이언트를 종료한 뒤 일반 웹사이트도 열리지 않나요?

v2rayN을 다시 열고 ‘시스템 프록시’ → ‘시스템 프록시 해제’를 선택한 뒤 종료하세요. 클라이언트를 시작할 수 없다면 시스템 네트워크 설정에서 수동 프록시가 중지된 로컬 포트를 계속 가리키는지 확인하세요. 변경 전에 기존 값을 기록해 두어 회사나 기관 네트워크의 프록시 설정을 덮어쓰지 않도록 하세요.

문제 해결 후 어떤 설정을 유지해야 하나요?

효과가 확인된 수정 사항 하나만 유지하고, 임시로 변경한 라우팅과 로그 수준은 복원하세요. 효과가 없었던 DNS 변경은 되돌리세요. TUN 모드를 사용했다면 시스템 프록시 경로가 정상인지 먼저 확인한 뒤 TUN을 별도로 다시 켜서 테스트하세요. 두 방식이 동시에 트래픽을 처리해 생기는 혼선을 피할 수 있습니다.

수정이 끝나면 같은 브라우저에서 이전에 열리지 않던 주소를 다시 방문하고, 직접 연결되어야 하는 웹사이트도 하나 확인하세요. 추가로 도움을 요청해야 한다면 클라이언트와 코어 버전, 운영체제 종류, 오류 발생 시각, 테스트 방법, 관련 오류 로그를 정리하세요. 공유 전에 구독 주소와 사용자 식별 정보, 인증 매개변수를 가리세요. 문제 해결을 위해 구독 정보나 전체 설정 파일을 공개하지 마세요.

시스템 프록시가 올바른 로컬 주소와 포트를 가리킵니다.
올바른 프로세스가 로컬 포트에서 수신 대기 중이며, 프록시를 명시한 요청이 응답을 받았습니다.
기존 라우팅 설정에서 대상 웹사이트가 예상한 경로로 연결됩니다.
로그에 표시된 DNS 오류와 노드 핸드셰이크 오류를 각각 해결했습니다.
임시 설정을 복원했으며, 정상 종료 후 네트워크 상태도 예상대로입니다.