V2Ray 연결됨에도 웹페이지가 열리지 않을 때: 시스템 프록시·DNS·라우팅 점검 목록

클라이언트에 “연결됨” 또는 “서비스가 시작됨”이라고 표시되는 것은 보통 로컬 프록시 코어가 실행되고 수신 포트가 열렸다는 뜻일 뿐입니다. 브라우저 요청이 프록시를 거쳤다는 의미도, 원격 노드가 연결을 완료할 수 있다는 의미도 아닙니다. 점검할 때는 요청이 실제로 통과하는 경로를 따라 바깥쪽으로 확인하고, 구독을 반복해서 갱신하거나 노드를 계속 바꾸지 않는 것이 좋습니다.

이 글의 빠른 요약

이 체크리스트는 v2rayN, v2rayNG, v2flyNG가 실행 중이지만 웹페이지가 시간 초과되거나 빈 화면으로 표시되거나 연결할 수 없다고 나오는 경우에 유용합니다. 트래픽이 로컬 포트로 들어오는지, 노드에 연결할 수 있는지, 도메인이 해석되는지, 라우팅이 잘못 분기되지 않았는지, 시스템 시간이 정확한지를 순서대로 확인하면 문제 발생 계층을 좁힐 수 있습니다.

먼저 “클라이언트 연결됨”의 의미부터 확인하기

V2Ray, Xray, V2Fly 코어는 보통 필요할 때 원격 연결을 수립합니다. 클라이언트를 시작하면 로컬 HTTP, SOCKS 또는 VPN 인터페이스가 먼저 활성화되고, 브라우저가 실제 요청을 보낸 뒤에야 코어가 DNS 조회, 라우팅 규칙 매칭, 프로토콜 캡슐화, 원격 연결을 수행합니다. 따라서 화면에 표시된 실행 상태만으로는 완전한 웹 요청 테스트를 대신할 수 없습니다.

브라우저 요청 로컬 프록시 규칙 매칭 노드 연결 대상 웹사이트

먼저 장애 범위를 구분해 보세요. 프록시를 완전히 끈 뒤 일반 웹사이트가 열리는지, 프록시를 켠 뒤 모든 웹사이트가 실패하는지 아니면 프록시 규칙이 적용되는 사이트만 실패하는지, 도메인으로 접속할 때 실패한다면 알려진 주소로 직접 접속해도 실패하는지를 확인합니다. 세 가지 결과는 각각 로컬 네트워크, 프록시 경로, DNS 또는 라우팅 계층을 가리킵니다.

10808

일반적인 SOCKS 포트

10809

일반적인 HTTP 포트

10초

첫 번째 시간 초과 관찰값

3개 계층

로컬, 노드, 대상 서버

1단계: 시스템 프록시가 실제로 클라이언트를 가리키는지 확인

Windows에서 v2rayN을 사용할 때 코어 실행과 시스템 프록시는 서로 독립된 상태입니다. 서비스만 시작하고 시스템 프록시를 설정하지 않았다면 브라우저는 계속 직접 연결합니다. v2rayN 메인 화면에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택한 뒤, Windows 「설정」→「네트워크 및 인터넷」→「프록시」로 이동해 프록시 서버가 127.0.0.1을 가리키고 포트가 v2rayN의 현재 HTTP 포트와 일치하는지 확인하세요.

v2rayN에서 「설정」→「매개변수 설정」을 열고 로컬 SOCKS 및 HTTP 수신 포트를 기록합니다.
포트가 다른 숫자로 직접 변경되지 않았는지 확인하세요. 일반적인 조합은 SOCKS 10808, HTTP 10809입니다.
브라우저에 프록시 확장 프로그램이나 고정 프록시 주소가 별도로 설정되어 시스템 프록시를 덮어쓰고 있지 않은지 확인하세요.
시스템 프록시를 변경하는 다른 네트워크 도구를 잠시 종료한 뒤 「시스템 프록시 자동 설정」을 다시 실행하세요.
브라우저를 종료한 후 다시 열어 기존 연결 풀과 이전 프록시 설정을 무효화하세요.

시스템 프록시 설정을 우회해 로컬 포트를 확인하려면 터미널에서 요청을 HTTP 프록시로 직접 보내면 됩니다. 아래 테스트에서 HTTP 응답 헤더가 반환되면 브라우저와 로컬 프록시 사이의 연결은 대체로 정상입니다. 즉시 127.0.0.1에 연결할 수 없다고 나오면 코어가 종료됐는지, 포트 입력이 틀렸는지, 수신 주소가 변경됐는지를 먼저 확인하세요.

curl --proxy http://127.0.0.1:10809 --head https://v2help.com/

오류: Failed to connect to 127.0.0.1 port 10809

원인 및 해결: 로컬 HTTP 포트가 수신 대기 중이 아니거나 실제 포트가 10809가 아닙니다. 「설정」→「매개변수 설정」으로 돌아가 포트를 확인하고 저장한 뒤 코어를 다시 시작하세요.

오류: address already in use

원인 및 해결: 다른 프로세스가 수신 포트를 사용 중입니다. 같은 포트를 점유한 프로그램을 종료하거나 HTTP 및 SOCKS 포트를 사용하지 않는 포트로 변경한 뒤 시스템 프록시도 함께 업데이트하세요.

Android에서는 작동 방식이 다릅니다. v2rayNG와 v2flyNG가 앱 트래픽을 제어하려면 시스템 VpnService 권한을 허용해야 합니다. 처음 연결할 때 권한을 건너뛰었거나 시스템이 백그라운드에서 VPN을 종료하면 클라이언트 화면에는 노드 정보가 남아 있지만 실제 트래픽은 코어로 들어가지 않을 수 있습니다. 다시 연결을 누르고 상태 표시줄에 VPN 아이콘이 나타나는지 확인하세요. 또한 「설정」→「앱별 프록시」에서 테스트 중인 브라우저가 실수로 제외되지 않았는지 점검합니다.

2단계: 노드 연결 가능 여부와 구독 매개변수 확인

시스템 프록시가 올바르다면 다음은 노드 자체를 확인할 차례입니다. 지연 시간 테스트는 특정 탐색 요청이 응답을 받았다는 것만 보여 줄 뿐, VMess, VLESS 또는 전송 계층의 핸드셰이크가 끝까지 성공했다는 뜻은 아닙니다. 단일 노드를 선택해 실제 웹 요청을 한 번 보내고, 클라이언트 실행 로그에서 연결 시도, TLS, WebSocket 또는 인증 오류가 나타나는지 확인하는 방법이 더 확실합니다.

관찰 결과	가능성이 높은 문제 계층	다음 점검 항목
여러 노드가 모두 약 10초 후 시간 초과	로컬 네트워크, DNS 또는 공용 라우팅	네트워크를 바꾸고 도메인 해석을 확인
노드 하나만 시간 초과	노드 주소, 포트 또는 서비스 상태	구독을 갱신하고 노드 매개변수 확인
TCP 연결 후 즉시 거부됨	사용자 식별자, 전송 경로 또는 프로토콜 불일치	구독 제공처와 설정을 다시 동기화
홈페이지는 열리지만 이미지와 스크립트가 계속 실패	회선 패킷 손실, MTU 또는 분기 설정 불일치	전체 프록시 모드와 다른 네트워크를 비교

구독 갱신 성공은 클라이언트가 설정 파일 하나를 내려받았다는 뜻일 뿐, 그 안의 모든 노드가 사용 가능하다는 의미는 아닙니다. 사용자 식별자, 포트, TLS 서버 이름, WebSocket 경로를 임의로 추측해 입력하지 마세요. 이 값들은 서버 설정과 일치해야 합니다. 구독을 갱신한 직후 모든 노드가 작동하지 않는다면 현재 선택한 그룹이 실제로 새 노드를 참조하는지 먼저 확인한 뒤 코어를 다시 시작하세요. 이전 활성 설정을 계속 사용하고 있을 수 있습니다.

오류: dial tcp: i/o timeout

원인 및 해결: 지정된 주소와 포트가 제한 시간 안에 연결되지 않았습니다. 먼저 같은 구독의 다른 노드로 비교한 다음 로컬 네트워크를 바꿔 단일 노드 문제인지 현재 회선에서 연결할 수 없는 문제인지 구분하세요.

오류: connection refused

원인 및 해결: 원격 주소에는 도달했지만 대상 포트가 연결을 받아들이지 않습니다. 구독을 갱신하고 포트를 확인하세요. 해당 노드에서만 발생한다면 로컬 프록시 설정을 계속 수정하지 마세요.

오류: invalid user

원인 및 해결: VMess 또는 VLESS의 사용자 식별자가 서버와 일치하지 않거나 기존 설정이 만료됐습니다. 구독을 다시 갱신하고 노드를 다시 선택하세요. 사용자 식별자를 직접 수정하지 마세요.

오류: failed to dial WebSocket

원인 및 해결: WebSocket 경로, 호스트 이름, TLS 매개변수 또는 중간 네트워크 설정이 일치하지 않습니다. 구독 원본 매개변수와 대조하면서 전송 방식과 경로가 직접 변경되지 않았는지 중점적으로 확인하세요.

결론: 노드를 계속 바꾸기보다 단일 변수로 비교하기

같은 네트워크에서는 클라이언트 설정을 유지하고 정상 작동이 확인된 노드 하나만 바꾸세요. 그다음 노드는 유지한 채 다른 네트워크로 전환합니다. 두 번의 비교만으로도 노드 문제와 로컬 회선 문제를 구분할 수 있습니다.

3단계: 프록시 전에 DNS가 실패하는지 확인

브라우저가 도메인에 접속하려면 먼저 주소를 얻어야 합니다. 노드 서버 자체가 도메인을 사용한다면 클라이언트는 노드 주소도 먼저 해석해야 하며, 이 단계가 실패하면 프록시 프로토콜은 핸드셰이크를 시작할 기회조차 얻지 못합니다. 대표적으로 로그에 lookup, no such host 또는 failed to find an available destination이 나타나고, 로컬 캐시에 남은 이전 페이지는 잠시 정상적으로 열릴 수 있습니다.

nslookup v2help.com
nslookup v2help.com 1.1.1.1

첫 번째 명령은 현재 시스템 DNS를 사용하고, 두 번째 명령은 비교를 위해 특정 DNS 서버를 지정합니다. 첫 번째가 계속 시간 초과되지만 두 번째가 1~2초 안에 주소를 반환한다면 시스템 DNS를 먼저 복구하세요. 둘 다 실패하면 현재 네트워크에서 DNS 조회를 허용하는지 계속 확인합니다. 테스트가 끝나면 클라이언트로 돌아가 코어를 재시작하고 요청을 다시 보내 이전 실패 캐시가 판단에 영향을 주지 않도록 하세요.

Windows에서는 「설정」→「네트워크 및 인터넷」→현재 네트워크 연결에서 DNS 설정을 확인할 수 있습니다.
DNS를 변경한 뒤 ipconfig /flushdns를 실행하고 브라우저를 완전히 종료한 다음 다시 여세요.
v2rayN 7.x에서 사용자 지정 DNS를 사용할 때는 입력한 서버 주소가 해석 가능한지, 설정 문법에 불필요한 쉼표나 유효하지 않은 항목이 없는지 확인하세요.
라우팅 규칙이 도메인으로 매칭되어야 한다면 DNS 조회 전에 모든 도메인을 규칙의 예상과 맞지 않는 주소로 강제로 변환하지 마세요.
노드 도메인만 해석되지 않고 일반 도메인은 정상이라면 구독의 노드 주소가 완전한지, 공백이 섞이지 않았는지 확인하세요.

오류: failed to lookup ip for domain

원인 및 해결: 코어가 현재 DNS에서 노드 또는 대상 도메인의 주소를 얻지 못했습니다. 시스템 DNS를 자동으로 받도록 복구하거나 사용 가능한 DNS 설정으로 변경한 뒤 코어를 다시 시작하세요.

오류: no such host

원인 및 해결: 도메인이 존재하지 않거나 철자가 틀렸거나 DNS가 존재하지 않는 결과를 반환했습니다. 구독의 서버 주소를 확인하고 전송 계층 호스트 이름과 노드 주소를 서로 바꾸지 마세요.

오류: failed to find an available destination

원인 및 해결: 아웃바운드 대상에서 사용할 수 있는 주소를 얻지 못했습니다. 해석 실패 또는 주소 체계 불일치에서 흔히 발생합니다. 먼저 기본 DNS를 복구한 뒤 IPv4와 현재 네트워크가 제공하는 주소를 각각 테스트하세요.

4단계: 라우팅 분기가 요청을 잘못된 출구로 보내지 않는지 확인

라우팅 분기는 요청을 프록시, 직접 연결 또는 차단 중 어디로 보낼지 결정합니다. 노드가 완전히 정상이어도 규칙이 대상 도메인을 직접 연결로 보내면 웹페이지가 시간 초과될 수 있습니다. 반대로 로컬 네트워크 주소가 프록시로 전송되면 라우터 관리 페이지나 로컬 서비스가 열리지 않을 수 있습니다. 가장 효과적인 진단은 즉시 규칙을 다시 작성하는 것이 아니라, 잠시 전체 프록시로 전환해 비교하는 것입니다.

현재 라우팅 설정을 저장하고 사용 중인 규칙 세트 이름을 기록하세요.
v2rayN에서 전체 프록시에 해당하는 라우팅 모드를 임시로 선택하고 코어를 다시 시작하세요.
브라우저의 기존 탭을 닫고 조금 전 실패했던 동일한 주소를 다시 방문하세요.
전체 모드에서 복구된다면 문제는 도메인 규칙, 주소 규칙 또는 아웃바운드 태그에 있습니다.
기존 라우팅을 복원하고 매칭 순서를 하나씩 확인하세요. 잘못된 규칙을 가리기 위해 전체 모드를 장기간 사용하지 마세요.

V2Ray와 Xray 라우팅은 보통 설정 순서대로 매칭됩니다. 범위가 넓은 규칙이 앞에 있으면 뒤의 정밀한 규칙보다 먼저 요청을 가로챌 수 있습니다. 예를 들어 범위가 지나치게 넓은 직접 연결 도메인 규칙은 원래 프록시로 보내야 할 요청을 직접 전송하게 만들고, 너무 앞에 있는 차단 규칙은 요청을 로컬에서 거부합니다. 로그에 대상 도메인과 아웃바운드 태그가 표시된다면 실제 매칭 결과를 기준으로 판단하세요.

도메인 읽기 규칙 매칭 아웃바운드 선택 연결 수립

v2rayNG와 v2flyNG에서는 앱별 프록시도 추가로 확인해야 합니다. 선택한 앱만 VPN을 사용하도록 설정했는데 브라우저가 선택되지 않았다면 클라이언트는 연결 상태를 유지해도 브라우저는 계속 직접 연결합니다. 「설정」→「앱별 프록시」로 이동해 현재 모드가 “선택한 앱 우회”인지 “선택한 앱만 프록시”인지 확인하세요. 두 모드는 선택 항목의 의미가 서로 반대입니다.

결론: 전체 모드가 작동하면 규칙 매칭을 다시 확인

같은 노드가 전체 모드에서는 웹페이지를 열고 분기 모드로 돌아가자마자 실패한다면 노드와 로컬 포트는 이미 검증된 것입니다. 다음으로 도메인 규칙, 주소 범위, 앱별 목록, 아웃바운드 태그만 확인하세요.

5단계: 시스템 시간을 보정하고 TLS 및 프로토콜 매개변수 확인

시스템 시간이 틀리면 TLS 인증서의 유효 기간 판단에 영향을 주고 시간 범위에 의존하는 인증 절차도 방해합니다. VMess는 클라이언트와 서버의 시간 차이에 민감합니다. 컴퓨터가 절전 모드에서 깨어난 뒤 시간이 어긋났거나 가상 환경이 일시 중지됐다가 복구되면 로컬 포트는 정상인데 원격 연결이 계속 거부될 수 있습니다. VLESS에서 TLS를 사용할 때도 인증서 검증을 위해 정확한 시간이 필요합니다.

Windows에서 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 시간 자동 설정과 표준 시간대 자동 설정을 켜세요.
“지금 동기화”를 클릭하고 날짜, 시간대, 분 단위가 모두 정확한지 확인하세요.
Android에서는 시스템 「설정」→「시스템」→「날짜 및 시간」으로 이동해 네트워크 제공 시간 사용을 활성화하세요.
시간을 보정한 뒤에는 브라우저 페이지만 새로 고치지 말고 v2rayN, v2rayNG 또는 v2flyNG의 코어를 재시작하세요.
로그에 TLS 오류가 계속 표시되면 구독의 서버 이름, 전송 보안 유형, 포트를 확인하고 다른 노드의 매개변수를 섞어 사용하지 마세요.

오류: certificate has expired or is not yet valid

원인 및 해결: 로컬 시간이 틀렸거나 원격 인증서가 유효 기간이 아닙니다. 먼저 시스템 시간을 동기화하세요. 시간이 정확한데 특정 노드에서만 발생한다면 해당 노드 사용을 중단하고 구독을 갱신하세요.

오류: tls: handshake failure

원인 및 해결: TLS 서버 이름, 프로토콜 협상 또는 원격 설정이 일치하지 않습니다. 구독에서 제공한 TLS 매개변수로 복원하고 다른 노드의 서버 이름을 복사해 넣지 않았는지 확인하세요.

오류: rejected proxy connection

원인 및 해결: 프록시 경로에서 연결이 거부됐습니다. 인증 매개변수가 만료됐거나 현재 아웃바운드에서 대상이 차단됐을 수 있습니다. 구독을 갱신한 뒤 같은 그룹의 다른 노드와 비교하고 어느 아웃바운드에서 거부됐는지 확인하세요.

클라이언트가 사용하는 코어와 노드의 기능이 서로 맞는지도 확인해야 합니다. v2rayN은 설정에 따라 적절한 코어를 호출할 수 있고, v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 일반적인 VMess 및 VLESS 설정이라고 해서 모든 확장 전송 기능이 서로 다른 코어 사이에서 그대로 호환되는 것은 아닙니다. 가져온 뒤 필드가 사라졌거나 로그에 지원되지 않는 기능이라고 명확히 표시되면 알 수 없는 필드를 임의로 삭제하지 말고 설정 기능에 맞는 클라이언트를 선택하세요.

순서대로 실행하는 최종 점검 목록

앞선 점검을 마쳤다면 아래 순서대로 다시 확인해 보세요. 각 단계에서는 “통과” 또는 “통과하지 않음”만 판단하면 됩니다. 처음으로 통과하지 못한 항목이 나오면 해당 계층부터 처리하고 여러 설정을 계속 겹쳐서 변경하지 마세요. 이렇게 하면 원인 파악 시간을 줄이고 복구 후 임시 설정도 쉽게 되돌릴 수 있습니다.

기본 네트워크: 프록시를 끈 상태에서 현재 네트워크로 일반 웹페이지에 정상적으로 접속할 수 있습니다.
코어 상태: 클라이언트 실행 로그에 포트 점유, 설정 해석 실패 또는 프로세스 종료 메시지가 없습니다.
로컬 진입점: 시스템 프록시가 127.0.0.1과 실제 HTTP 포트를 가리키거나 Android VPN 권한이 허용되어 있습니다.
요청 인바운드: 웹페이지를 새로 고칠 때 액세스 로그에 새 대상 도메인 또는 연결 기록이 표시됩니다.
노드 연결 가능: 지연 시간 탐색만이 아니라 최소 하나의 노드에서 실제 웹 요청을 완료할 수 있습니다.
DNS 정상: 시스템 조회가 약 1~2초 안에 결과를 반환하고 로그에 lookup 오류가 계속 나타나지 않습니다.
라우팅 정상: 전체 모드와 분기 모드의 비교 결과가 명확하며 대상이 예상한 아웃바운드에 매칭됩니다.
시간 정확: 시스템 날짜, 시간대, 분 단위가 동기화되어 TLS 로그에 유효 기간 오류가 더 이상 표시되지 않습니다.
앱 범위: 브라우저가 앱별 프록시에서 제외되지 않았고 만료된 별도 프록시 설정도 사용하지 않습니다.
설정 일치: 프로토콜, 포트, 사용자 식별자, TLS 서버 이름, 전송 경로가 모두 같은 구독 항목에서 가져온 값입니다.

지연 시간 테스트에 숫자가 표시되는데 웹페이지는 왜 시간 초과되나요?

지연 시간 탐색이 프로토콜 핸드셰이크와 대상 접속까지 반드시 완료하는 것은 아닙니다. 노드를 선택한 뒤 실행 로그를 열고 웹페이지에 접속하면서 i/o timeout, TLS 또는 인증 오류가 나타나는지 중점적으로 확인하세요.

브라우저만 열리지 않고 다른 앱은 인터넷에 연결되면 어떻게 하나요?

먼저 브라우저 자체의 프록시 설정과 확장 프로그램을 끄고 시스템 프록시를 따르는지 확인하세요. 그런 다음 브라우저를 완전히 종료했다가 다시 열어 기존 연결 풀이 테스트에 영향을 주지 않도록 합니다.

구독을 갱신했는데도 이전 노드를 계속 사용하나요?

현재 활성 그룹과 선택된 노드를 확인하고 갱신된 항목을 다시 선택한 뒤 코어를 재시작하세요. 구독 목록을 새로 고쳐도 실행 중인 기존 연결이 즉시 전환된다는 보장은 없습니다.

전체 모드는 작동하지만 분기 모드는 작동하지 않을 때 어떻게 고치나요?

분기 모드로 돌아간 뒤 대상 도메인이 매칭된 아웃바운드 태그를 확인하세요. 앞쪽에 있는 범위가 넓은 직접 연결 규칙, 차단 규칙, Android 앱별 프록시 목록을 우선 점검합니다.

컴퓨터를 다시 시작한 뒤 웹페이지가 또 열리지 않으면 다시 설정해야 하나요?

먼저 클라이언트가 실행 중인지, 시스템 프록시가 현재 포트를 가리키는지, 포트를 다른 프로그램이 사용하고 있지 않은지 확인하세요. 설정 파일에 오류가 없다면 모든 구독을 다시 가져올 필요는 없습니다.

점검 목록이 “요청 인바운드”에서 멈춘다면 문제는 브라우저, 시스템 프록시 또는 VPN 권한에 집중됩니다. 요청이 코어에 들어온 뒤 연결 오류가 발생한다면 노드, 네트워크, DNS를 중점적으로 확인하세요. 분기 모드에서만 실패한다면 바로 규칙 매칭으로 돌아가면 됩니다. 문제를 한 계층으로 제한한 뒤 설정을 변경하는 편이 클라이언트를 한꺼번에 재설치하는 것보다 재현 가능한 결과를 얻기 쉽습니다.