연결은 됐는데 웹페이지가 열리지 않을 때: 단계별 점검표

1. 실행 상태와 요청 성공 여부 구분하기

Android 상태 표시줄에 VPN 아이콘이 나타나면 시스템에 로컬 VPN 인터페이스가 만들어진 것입니다. 원격 노드 인증까지 성공했다는 뜻은 아닙니다. v2rayN에서 코어가 실행 중으로 표시되는 것도 로컬 프로세스가 시작됐다는 의미일 뿐입니다. 웹페이지를 열려면 앱 트래픽 전달, 도메인 조회, 라우팅, 원격 연결, 대상 사이트 응답이 모두 정상이어야 합니다.

먼저 테스트 방법을 하나로 고정하세요. 같은 브라우저에서 동일한 전체 HTTPS 주소를 열고, 평소 접속할 수 있는 사이트도 비교 대상으로 선택합니다. 노드를 바꾸면서 DNS와 브라우저 설정까지 함께 변경하지 마세요. 문제가 해결되어도 어떤 변경이 효과가 있었는지 알 수 없습니다.

2. 기본 네트워크와 시스템 시간 확인

먼저 v2rayNG 연결을 끄거나 v2rayN의 「시스템 프록시」에서 「시스템 프록시 지우기」를 선택하세요. TUN도 켜져 있다면 잠시 비활성화해야 합니다. 시스템 프록시를 지워도 TUN의 트래픽 처리는 자동으로 중단되지 않습니다. 그런 다음 평소 접속할 수 있는 사이트를 열어 Wi-Fi나 모바일 데이터가 정상인지 확인하세요.

1. 네트워크 연결 확인

   프록시를 끈 뒤 브라우저를 여세요. 공용 Wi-Fi에서 로그인 페이지가 뜨면 먼저 네트워크 인증을 완료하세요. 그래도 접속할 수 없다면 노드 설정을 바꾸기 전에 모바일 데이터로 전환해 테스트하세요.

2. 시간 동기화

   Android에서는 보통 「설정」→「시스템」→「날짜 및 시간」에서 자동 설정을 켭니다. Windows에서는 「설정」→「시간 및 언어」→「날짜 및 시간」에서 자동 설정을 켜고 동기화를 실행하세요. 제조사에 따라 메뉴 이름은 다를 수 있습니다.

3. 연결 다시 시작

   클라이언트로 돌아가 기존 노드를 선택한 뒤 연결을 다시 시작하세요. 기기 시간이 맞지 않으면 인증서 유효성 확인에 영향을 주거나 VMess의 시간 기반 인증이 실패할 수 있습니다. 시간대 표시만 바꿔서는 실제 시간이 잘못된 문제를 해결할 수 없습니다.

4. 결과 기록

   네트워크 유형, 노드 이름, 실패한 주소, 요청 시간을 기록하세요. 이후 테스트에도 같은 주소를 사용하세요. 네트워크를 전환한 뒤에는 다시 연결해 이전 연결 상태를 새 네트워크의 결과로 오인하지 않도록 합니다.

3. 브라우저 트래픽이 클라이언트로 전달되는지 확인

v2rayNG를 사용하려면 먼저 Android VPN 권한을 허용해야 합니다. 기기에서 시스템 VPN 인터페이스를 사용하는 다른 도구가 실행 중이면 해당 도구를 중지한 뒤 v2rayNG를 시작하세요. v2rayN에서는 시스템 프록시와 TUN을 구분해야 합니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 적용되며, 터미널 프로그램은 보통 프록시를 별도로 지정해야 합니다.

v2rayNG의 사이드 메뉴에서 「설정」→「앱별 프록시」로 이동해 스위치, 목록, 모드를 확인하세요. 「선택한 앱만 프록시 사용」을 켰다면 브라우저를 목록에서 선택해야 합니다. 우회 모드를 사용하는 경우에는 선택한 브라우저가 오히려 프록시를 거치지 않습니다. 버전에 따라 모드 이름이 다를 수 있으니 화면의 설명을 확인하세요.

• Android에서 비교: 기존 목록을 기록해 둔 뒤 앱별 프록시 제한을 잠시 끄고 연결을 다시 설정한 다음 같은 브라우저로 재시도하세요.
• Windows에서 비교: v2rayN의 「시스템 프록시」에서 「시스템 프록시 자동 구성」을 선택하고, 브라우저의 프록시 확장 프로그램이 직접 연결이나 이전 포트를 강제하지 않는지 확인하세요.
• 로그 확인: 요청을 한 번 보내고 해당 도메인이나 대상 주소가 기록되는지 살펴보세요. 액세스 로그가 비활성화되어 있다면 기록이 없다는 사실만으로 트래픽이 전달되지 않았다고 단정할 수 없습니다. 잠시 로그 상세도를 높인 뒤 다시 시도하세요.

데스크톱에서는 로컬 프록시를 명시해 브라우저의 프록시 설정과 비교할 수도 있습니다. 아래 포트는 테스트 예시일 뿐 모든 버전의 기본값은 아닙니다. 먼저 클라이언트의 현재 수신 설정을 확인한 뒤 명령의 포트를 실제 값으로 바꾸세요.

# Windows 터미널; 재현하려는 사이트 주소로 대상 주소를 바꾸세요
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/

socks5h는 대상 도메인 조회를 프록시 쪽에서 처리한다는 뜻입니다. 프록시를 직접 지정했을 때 HTTP 상태 코드가 반환되지만 브라우저에서는 여전히 실패한다면 브라우저와 시스템 프록시의 트래픽 처리를 먼저 확인하세요. 403이나 405가 반환되더라도 HTTP 응답을 받은 것일 뿐 페이지 접근 권한이 정상이라는 뜻은 아닙니다. 일부 사이트는 HEAD 요청을 허용하지 않으므로 -I를 빼고 다시 시도하세요.

4. 노드 도메인과 웹사이트 DNS를 나눠서 점검

혼동하기 쉬운 DNS 대상은 두 가지입니다. 노드 서버 주소와 접속하려는 웹사이트 주소입니다. 노드 주소가 도메인이라면 연결을 시작하기 전에 클라이언트가 해당 도메인의 IP 주소를 찾아야 합니다. 이때 모든 DNS 요청을 아직 연결되지 않은 프록시로 보내면 순환 의존성이 생길 수 있습니다.

노드 연결은 되지만 웹사이트 도메인 조회가 실패하는 경우도 있습니다. 브라우저의 보안 DNS, Android의 비공개 DNS, 클라이언트 DNS 규칙이 서로 다른 조회 경로에 관여할 수 있습니다. Android에서는 보통 「설정」→「네트워크 및 인터넷」→「비공개 DNS」에서 현재 상태를 확인합니다. 제조사에 따라 「연결 및 공유」 메뉴에 있을 수 있습니다.

• 먼저 기존 값 기록: 사용자 지정 DNS 주소와 관련 규칙을 보관하고 설정 전체를 바로 덮어쓰지 마세요.
• 잠깐 비교 테스트: 비공개 DNS에 사용자 지정 호스트 이름을 사용한다면 잠시 자동으로 전환한 뒤 다시 연결해 테스트하세요. 브라우저에서 설정한 보안 DNS도 별도로 테스트하세요.
• 대상 구분: 로그에서 실패한 항목이 노드 도메인이라면 노드 주소의 DNS 조회부터 해결하세요. 웹사이트 도메인이라면 웹사이트 트래픽에 사용되는 DNS 경로를 확인하세요.
• 잘못된 판단 주의: HTTPS 도메인 대신 웹사이트 IP 주소로 간단히 테스트하지 마세요. 인증서 이름과 가상 호스트 일치 여부에 따라 결과가 달라질 수 있습니다.

5. 라우팅 순서와 분기 규칙 적용 여부 확인

일부 사이트만 접속할 수 없다면 먼저 실제로 어떤 아웃바운드를 사용하는지 확인하세요. V2Ray/Xray의 라우팅 규칙은 순서대로 적용됩니다. 앞쪽 규칙과 일치하면 보통 뒤의 규칙은 해당 연결을 결정하지 않습니다. 범위가 넓은 직접 연결 규칙이 앞에 있으면 프록시를 사용할 사이트가 직접 연결될 수 있습니다.

v2rayNG에서는 사이드 메뉴의 「라우팅 설정」에서 현재 규칙과 모드를 확인하세요. v2rayN에서는 「설정」→「라우팅 설정」에서 사용 중인 규칙 세트를 확인합니다. 화면에 표시되는 모드 이름은 버전에 따라 달라질 수 있습니다. 모드 제목만 보지 말고 테스트 요청이 어떤 아웃바운드를 사용하는지 확인하세요.

1. 현재 라우팅 설정을 저장하거나 모드를 캡처해 나중에 복원할 수 있도록 하세요.
2. 일반 웹 트래픽을 프록시로 보내는 테스트 모드를 잠시 사용하되, 로컬 네트워크에 필요한 직접 연결 규칙은 유지하세요.
3. 연결을 다시 설정한 뒤 기존에 실패한 사이트를 열어 보세요. 이전 연결이 재사용되어 판단에 영향을 주지 않도록 합니다.
4. 접속이 복구되면 사용자 지정 규칙으로 돌아가 도메인, IP, 아웃바운드 태그, 규칙 데이터베이스를 위에서 아래 순서로 확인하세요.

geosite:cn은 도메인 집합 조건이고 geoip:private는 사설 주소 집합 조건입니다. 둘은 같은 의미가 아닙니다. 규칙 데이터베이스를 참조할 때 파일이 없거나 집합 이름이 잘못되면 로드에 실패할 수 있으므로 시작 로그를 확인하세요. 또한 도메인 조건과 IP 조건이 함께 있는 규칙을 조건 중 하나만 만족하면 일치한다고 섣불리 해석하지 마세요.

6. 마지막으로 노드와 서버 설정 확인

트래픽이 클라이언트로 들어오고 DNS 조회도 성공했는데 원격 연결을 설정할 수 없다면 노드 자체를 점검하세요. 먼저 구독을 업데이트해 현재 선택한 항목이 오래된 설정으로 바뀌지 않았는지 확인하세요. 구독 업데이트는 설정을 가져왔다는 뜻일 뿐 서버가 온라인이거나 계정의 사용량이 남아 있다는 의미는 아닙니다.

• 서버와 포트: 서비스 제공업체의 최신 설정과 비교하세요. 흔히 쓰이는 웹사이트 포트 443이 모든 노드의 고정 포트라고 가정하지 마세요.
• 프로토콜과 인증: VMess와 VLESS의 프로토콜 유형 및 사용자 식별자가 서버 설정과 일치해야 합니다. 다른 매개변수는 그대로 둔 채 프로토콜 이름만 바꾸지 마세요.
• 전송 및 보안: WebSocket 경로, Host, TLS 서버 이름을 확인하세요. REALITY를 사용한다면 공개 키와 shortId 등 관련 매개변수도 확인해야 합니다. 노드에서 실제로 사용하는 항목만 점검하세요.
• 코어 지원: v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 코어마다 지원 기능이 완전히 같지는 않으므로 노드를 복사하기 전에 프로토콜과 보안 설정을 지원하는지 확인하세요.

두 가지 비교 테스트면 충분합니다. 같은 네트워크에서 다른 정상 노드를 사용하고, 같은 노드에서 다른 로컬 네트워크를 사용해 보세요. 다른 노드는 작동하지만 특정 노드만 계속 실패한다면 노드 설정, 서버 상태, 계정을 중점적으로 확인하세요. 모든 노드가 특정 Wi-Fi에서만 실패한다면 해당 네트워크의 제한과 DNS 조회 경로를 확인하세요. 비교 결과는 원인을 좁히는 단서이지 한 번의 테스트로 확정할 수 있는 결론은 아닙니다.

7. 설정 복원 및 자주 묻는 질문

원인을 찾은 뒤 비교 테스트용으로 임시 변경한 설정을 하나씩 복원하세요. 특히 전체 트래픽 프록시 모드, 비공개 DNS, 브라우저 보안 DNS는 테스트 중 변경했다는 이유로 그대로 두지 마세요. 먼저 원래 실패했던 주소가 다시 열리는지 확인한 다음 직접 연결 사이트와 접속이 필요한 로컬 네트워크 서비스를 테스트하세요. 한 문제를 해결하면서 다른 연결 경로까지 바꾸지 않도록 주의하세요.