클라이언트에 ‘연결됨’이 표시되고 지연 시간 테스트에 숫자가 나오더라도 브라우저 트래픽이 프록시 경로를 완전히 통과한다는 뜻은 아닙니다. 웹페이지 하나를 열 때도 도메인 해석, 라우팅 매칭, 인바운드 리스너, 아웃바운드 연결, 시스템 앱 트래픽 인계 등 여러 단계를 거칩니다. 어느 한 단계라도 잘못 설정되면 클라이언트는 정상처럼 보이지만 웹페이지가 계속 로드되거나 즉시 오류가 발생할 수 있습니다.
문제 해결 중에는 노드, DNS, 라우팅, 시스템 설정을 동시에 바꾸지 마세요. 여러 변수를 한꺼번에 변경하면 네트워크가 복구되어도 실제 원인을 확인하기 어렵습니다. 노드 자체를 먼저 검증한 뒤 DNS를 확인하고, 라우팅 규칙을 단순화한 다음 시스템 프록시 또는 VPN 트래픽 인계 상태를 점검하는 순서가 안전합니다. 각 단계가 끝날 때마다 같은 테스트 페이지로 재확인하고 결과를 기록하세요.
먼저 ‘연결됨’이 정확히 무엇을 의미하는지 확인하세요
v2rayN, v2rayNG 또는 v2flyNG에 실행 상태가 표시된다는 것은 대개 로컬 코어가 시작되었거나 로컬 프록시 진입점이 만들어졌다는 뜻입니다. 이것만으로 원격 노드에 연결할 수 있다고 단정할 수 없으며, 브라우저가 해당 진입점을 사용한다는 보장도 없습니다. 지연 시간 테스트에도 한계가 있습니다. 일부 테스트는 서버까지의 연결 시간만 측정하므로 실제 웹 요청에는 프로토콜 핸드셰이크, 도메인 해석, 라우팅 규칙, 원격 출구 상태가 추가로 영향을 줍니다.
먼저 증상을 다음과 같이 나눠 보세요. 증상에 따라 우선 확인할 항목이 다릅니다.
| 증상 | 우선 확인할 항목 | 흔한 원인 |
|---|---|---|
| 모든 웹페이지가 열리지 않음 | 노드, 시스템 프록시, VPN 트래픽 인계 | 노드 장애, 로컬 포트 미인계, 코어 연결 실패 |
| 도메인은 열리지 않지만 일부 주소는 접속 가능 | DNS | 해석 서버에 연결할 수 없음, 잘못된 출구로 전송된 DNS 조회 |
| 일부 웹사이트만 열리지 않음 | 라우팅, DNS, 노드 출구 | 잘못된 규칙 매칭, 특정 주소 대역 제한, 비정상적인 해석 결과 |
| 브라우저는 되지만 다른 소프트웨어는 안 됨 | 시스템 프록시 및 앱별 프록시 설정 | 앱이 시스템 프록시를 읽지 않음, 브라우저에만 프록시가 설정됨 |
| 노드 전환 후 복구됨 | 기존 노드 설정 및 서비스 상태 | 노드 만료, 프로토콜 매개변수 불일치, 원격 서버 연결 불가 |
1단계: 노드가 실제로 작동하는지 확인
노드는 전체 경로의 상류에 있습니다. 노드가 작동하지 않을 때 로컬 DNS나 라우팅을 반복해서 조정해도 대개 소용이 없습니다. 가장 효과적인 방법은 지연 시간만 확인하는 것이 아니라 같은 클라이언트에서 정상 작동이 확인된 다른 노드로 전환한 뒤 실제 웹페이지에 접속해 보는 것입니다. 새 노드에서 즉시 복구된다면 원인은 대부분 기존 노드 또는 해당 매개변수에 있습니다.
노드 정보 항목별 확인
- 주소와 포트를 확인하세요. 서버 주소에 불필요한 공백이 없는지, 포트가 유효한 숫자인지, 가져온 뒤 잘못 수정되지 않았는지 확인합니다.
- 프로토콜 유형을 확인하세요. VMess와 VLESS는 서로 다른 프로토콜이므로 주소와 포트만 남겨 서로 바꿔 사용할 수 없습니다. 클라이언트에 표시된 프로토콜은 원본 노드 설정과 일치해야 합니다.
- 사용자 식별자를 확인하세요. UUID, 사용자 ID 등의 인증 필드는 완전해야 합니다. 복사 과정에서 문자가 하나라도 빠지면 핸드셰이크가 실패할 수 있습니다.
- 전송 매개변수를 확인하세요. TCP, WebSocket, gRPC 등의 전송 방식과 Host, 경로, serviceName 등의 필드는 서버 설정과 일치해야 합니다.
- 보안 매개변수를 확인하세요. TLS 또는 REALITY를 사용하는 VLESS 노드는 올바른 서버 이름, 공개 키, 짧은 ID 등의 매개변수가 필요합니다. 매개변수가 누락되면 로컬 코어는 실행되더라도 원격 핸드셰이크가 완료되지 않을 수 있습니다.
- 기기 시간을 확인하세요. 시스템 날짜, 시간 또는 시간대가 크게 틀리면 인증서 검증이나 일부 프로토콜 인증이 실패할 수 있습니다. 먼저 시스템 자동 시간 설정을 켠 뒤 다시 연결하세요.
노드가 구독에서 제공된 것이라면 먼저 구독을 한 번 업데이트하고 현재 선택한 노드가 여전히 존재하는지 확인하세요. 구독 주소가 빈 내용을 반환하거나, 노드가 제거되었거나, 오래된 설정을 장기간 업데이트하지 않은 경우 클라이언트에 이미 만료된 기록이 남을 수 있습니다. 업데이트 후에는 노드 수만 확인하지 말고 노드를 다시 선택해 실제 연결 테스트를 실행하세요.
2단계: DNS 해석 장애인지 판단
브라우저가 도메인에 접속하려면 먼저 도메인을 주소로 해석해야 합니다. DNS 조회에 실패하면 프록시 코어는 실행 중이어도 웹페이지에 ‘서버를 찾을 수 없음’, ‘주소를 해석할 수 없음’이 표시되거나 연결 단계에서 오래 멈출 수 있습니다. 도메인 접속만 실패하고 이미 맺어진 연결이나 주소를 직접 사용하는 서비스는 응답한다면 DNS를 우선 확인해야 합니다.
먼저 범위를 좁혀 확인하세요
- 오류 메시지에 도메인 해석, 이름 해석 또는 DNS 관련 문구가 있는지 확인합니다.
- 다른 노드로 전환한 뒤 다시 테스트하세요. 모든 노드에서 같은 도메인 오류가 발생한다면 로컬 DNS 설정을 의심할 가능성이 큽니다.
- 클라이언트의 기본 DNS 설정으로 임시 복원하고 직접 추가한 복잡한 분기 해석 규칙을 비활성화하세요.
- DNS 조회에 사용하는 출구에 연결할 수 있는지 확인합니다. 프록시 조회를 지정했다면 프록시 노드에 먼저 연결할 수 있어야 하며, 직접 연결 조회를 지정했다면 로컬 네트워크에서 해당 해석 서비스에 접근할 수 있어야 합니다.
DNS와 라우팅에는 선후 관계가 있습니다. 라우팅 규칙이 IP로 매칭되면 코어가 먼저 도메인을 해석해야 할 수 있지만, DNS 조회 자체도 직접 연결 출구 또는 프록시 출구를 선택해야 합니다. 여러 DNS 설정, 도메인 분기, 주소 분기가 동시에 존재하면 ‘해석 결과가 라우팅을 결정하고, 라우팅이 다시 해석에 영향을 주는’ 복잡한 경로가 쉽게 만들어집니다. 문제 해결 단계에서는 정책 수를 먼저 줄이고 기본 해석이 가능한지 확인한 다음 항목별로 복원하세요.
캐시도 흔한 방해 요소입니다. DNS를 변경한 뒤에도 브라우저, 운영체제, 프록시 코어에 이전 해석 결과가 남아 있을 수 있습니다. 설정을 바꾼 후에는 클라이언트를 완전히 종료했다가 다시 시작하고 브라우저도 다시 여세요. 웹페이지 새로고침만으로는 새 DNS 조회가 발생하지 않을 수 있습니다.
DNS 결과가 정상인데도 열리지 않는다면
해석에 성공했다는 것은 주소를 얻었다는 뜻일 뿐, 현재 출구를 통해 해당 주소에 반드시 접속할 수 있다는 뜻은 아닙니다. 한 도메인이 여러 IPv4 또는 IPv6 주소를 반환할 수 있지만 로컬 네트워크, 노드 출구 또는 라우팅 규칙은 그중 일부에만 유효할 수 있습니다. 로그에 해석 완료가 표시된 뒤 연결 시간 초과가 발생한다면 더 단순한 주소 정책을 임시로 사용하거나 사용자 지정 IPv6 우선 설정을 끄고 비교 테스트를 진행하세요. 원인을 확인한 뒤 실제 네트워크 환경에 맞는 주소 계열 정책을 선택하면 됩니다.
3단계: 잘못된 라우팅 차단과 출구 오류 배제
라우팅 규칙은 연결을 프록시, 직접 연결 또는 차단 중 어디로 보낼지 결정합니다. 규칙은 보통 위에서 아래로 매칭되며, 일치하면 이후 규칙을 더 확인하지 않습니다. 범위가 지나치게 넓은 직접 연결 규칙이 앞에 있으면 프록시를 사용해야 할 웹사이트가 직접 연결되어 실패할 수 있고, 범위가 넓은 차단 규칙은 요청을 로컬에서 종료시킬 수 있습니다.
‘전역 프록시’로 비교 테스트하기
노드가 이미 정상임을 확인했다면 잠시 전역 프록시 모드로 전환해 볼 수 있습니다. 전역 모드에서는 웹페이지가 열리지만 규칙 모드에서는 열리지 않는다면 문제는 거의 라우팅 설정에 있습니다. 이때 노드 매개변수를 계속 수정하지 말고 규칙 순서, 매칭 범위, 아웃바운드 태그를 집중적으로 확인하세요.
라우팅을 확인할 때는 다음 항목을 중점적으로 살펴보세요.
- 기본 출구가 존재하는지 확인하세요. 어떤 규칙에도 매칭되지 않은 트래픽에는 명확한 기본 출구가 있어야 하며, 존재하지 않는 아웃바운드 태그를 가리켜서는 안 됩니다.
- 규칙 순서가 적절한지 확인하세요. 정확한 도메인과 좁은 범위의 규칙은 넓은 규칙보다 앞에 두어 조기 매칭을 피하는 것이 일반적입니다.
- 도메인 조건과 주소 조건이 함께 사용되는지 확인하세요. 주소 매칭은 DNS 해석을 유발할 수 있으며, 해석 정책이 최종 결과에 영향을 줍니다.
- 차단 범위가 지나치게 넓지 않은지 확인하세요. 테스트 중에는 최근 추가한 차단 항목을 잠시 비활성화하고 하나씩 복원하며 재확인합니다.
- 직접 연결 규칙이 대상을 덮어쓰는지 확인하세요. 대상 도메인이나 해석된 주소가 직접 연결 범위에 포함되면 웹페이지가 프록시를 우회하다가 접속에 실패할 수 있습니다.
- 아웃바운드 태그가 일치하는지 확인하세요. 규칙의
outboundTag는 실제 아웃바운드 설정의 태그와 정확히 일치해야 합니다.
문제 해결 순서:
1. 노드로 실제 접속이 성공하는가
2. 전역 프록시가 작동하는가
3. 규칙 모드에서 실패하는가
4. 대상 도메인에 매칭된 규칙 확인
5. 해당 규칙이 proxy, direct 또는 block 중 어디를 가리키는지 확인
6. 규칙 하나를 조정한 뒤 즉시 재확인문제 발생 중에는 여러 규칙 세트를 한꺼번에 가져오지 마세요. 출처가 다른 규칙에는 서로 겹치는 도메인과 주소 범위가 포함될 수 있습니다. 먼저 클라이언트 기본 규칙으로 검증한 다음 사용자 지정 규칙 하나를 추가해 테스트하세요. 이처럼 단계적으로 추가하면 어떤 규칙이 출구를 바꿨는지 정확히 확인할 수 있습니다.
4단계: 시스템 프록시 또는 VPN 트래픽 인계가 적용됐는지 확인
프록시 코어가 시작된 뒤에도 앱 트래픽이 로컬 인바운드 포트로 들어가야 합니다. 데스크톱에서는 보통 시스템 프록시, 앱 내 프록시 또는 다른 트래픽 인계 방식이 사용되며, Android의 v2rayNG와 v2flyNG는 대개 VPN 모드로 기기 트래픽을 인계합니다. 로컬 코어 실행과 트래픽 인계는 서로 독립된 상태이므로 시작 버튼만 확인해서는 안 됩니다.
v2rayN 데스크톱 점검
- 현재 사용할 노드를 선택했는지 확인하세요. 클라이언트 창만 실행한 상태인지 확인하는 것으로는 충분하지 않습니다.
- 시스템 프록시 모드가 켜져 있는지 확인하고, 운영체제의 프록시 설정에 해당 로컬 주소와 포트가 표시되는지 점검하세요.
- 브라우저에 프록시를 수동으로 입력한 적이 있다면 ‘시스템 프록시 사용’으로 되돌리거나 기존 포트를 지우세요. 브라우저가 이미 사용할 수 없는 로컬 포트에 계속 연결하는 일을 방지할 수 있습니다.
- 다른 프록시 프로그램이 같은 포트를 사용하고 있지 않은지 확인하세요. 포트 충돌이 발생하면 코어 로그에 리스닝 실패 또는 주소가 이미 사용 중이라는 메시지가 표시되는 경우가 많습니다.
- 클라이언트를 종료한 뒤 시스템 프록시가 올바르게 복원됐는지 확인하고 다시 시작하세요. 비정상 종료로 이전 프록시 주소가 남으면 모든 요청이 존재하지 않는 포트로 계속 전송될 수 있습니다.
v2rayNG 및 v2flyNG Android 점검
- 연결을 시작한 뒤 시스템 상태 영역에 VPN 연결 상태가 표시되고 클라이언트의 VPN 연결이 허용되어 있는지 확인하세요.
- 앱별 프록시 설정을 확인하세요. 대상 브라우저나 앱이 제외되어 있으면 해당 트래픽은 프록시로 들어가지 않습니다.
- 테스트를 위해 일시적으로 배터리 절전 제한 또는 백그라운드 활동 제한을 해제하세요. 화면을 잠그거나 앱을 전환한 뒤 시스템이 코어 프로세스를 종료하는 일을 방지할 수 있습니다.
- 기기에 다른 VPN 연결이 동시에 존재한다면 먼저 연결을 끊고 테스트하세요. 일반적으로 시스템에서는 두 VPN 인계 경로가 동시에 정상 작동하기 어렵습니다.
- 네트워크를 전환한 뒤에는 직접 연결을 끊었다가 다시 연결해 코어가 하위 연결을 새로 수립하도록 하세요.
‘브라우저는 인터넷이 되지만 특정 소프트웨어는 되지 않는’ 현상은 대개 노드 전체의 장애가 아닙니다. 일부 소프트웨어는 시스템 프록시를 읽지 않고, 일부 앱은 자체 프록시 설정을 사용하며, UDP 연결을 사용하는 경우도 있습니다. 이때는 해당 앱이 트래픽 인계를 받는지, UDP가 허용되는지, 라우팅에서 해당 대상 주소에 다른 출구를 지정했는지부터 확인하세요.
5단계: 로그로 어느 계층에서 실패했는지 확인
앞의 네 단계로도 원인을 찾지 못했다면 클라이언트 로그를 열고 기존 로그를 지운 뒤 테스트 웹페이지에 다시 접속하세요. 이렇게 하면 과거 기록의 방해를 줄일 수 있습니다. 코어 시작 단계의 정보만 보지 말고 요청 시점에 새로 추가된 몇 줄을 확인하세요.
| 로그 단서 | 일반적으로 가리키는 원인 | 다음 단계 |
|---|---|---|
| 연결 시간 초과, 대상에 연결할 수 없음 | 노드 주소, 네트워크 경로 또는 원격 서비스 | 노드와 네트워크를 전환하고 주소와 포트를 확인 |
| 인증 실패, 핸드셰이크 실패 | 프로토콜, 보안 매개변수 또는 기기 시간 | 노드를 다시 가져오고 UUID와 전송 매개변수를 확인 |
| 도메인 해석 실패 | DNS 설정 또는 DNS 출구 | 기본 DNS로 복원하고 조회 경로 확인 |
| 아웃바운드 태그를 찾을 수 없음 | 라우팅 규칙 참조 오류 | 규칙과 아웃바운드 설정의 태그를 대조 |
| 포트 리스닝 실패 | 로컬 포트 충돌 | 충돌하는 프로그램을 종료하거나 로컬 포트 변경 |
| 로그에 웹 요청이 전혀 없음 | 트래픽이 클라이언트로 들어오지 않음 | 시스템 프록시, VPN 및 앱별 설정 확인 |
로그에 ‘요청 없음’이 기록되는 것 자체가 중요한 결과입니다. 웹페이지에 접속할 때 로그에 새로운 인바운드 기록이 전혀 없다면 문제는 코어 이전 단계에서 발생한 것이므로 시스템 프록시 또는 VPN 트래픽 인계 확인으로 돌아가야 합니다. 인바운드 요청은 보이지만 성공한 아웃바운드가 없다면 DNS, 라우팅, 노드 핸드셰이크 중 어디에서 실패했는지 계속 판단하세요. ‘요청이 들어왔는가’와 ‘아웃바운드가 어느 단계에서 멈췄는가’라는 두 질문으로 범위를 빠르게 좁힐 수 있습니다.
최종 점검 목록: 순서대로 하나씩 확인
- 일반 네트워크 연결 자체가 정상이며 기기에서 로컬 네트워크가 허용한 페이지에 접속할 수 있는지 확인합니다.
- 시스템 날짜, 시간, 시간대를 동기화합니다.
- 구독을 업데이트하고 노드를 다시 선택합니다. 제거된 이전 기록을 계속 사용하지 마세요.
- 정상 작동이 확인된 노드로 하나 이상 전환하고 실제 웹페이지 접속으로 검증합니다.
- VMess 또는 VLESS 프로토콜, 주소, 포트, UUID, 전송 및 보안 매개변수를 확인합니다.
- 클라이언트 기본 DNS로 복원하고 클라이언트와 브라우저를 다시 시작한 뒤 재확인합니다.
- 잠시 전역 프록시로 전환합니다. 전역 모드가 작동하면 라우팅 규칙을 집중적으로 확인합니다.
- 규칙 순서, 직접 연결 범위, 차단 범위, 아웃바운드 태그를 확인합니다.
- 데스크톱에서는 시스템 프록시 주소와 로컬 리스닝 포트가 일치하는지 확인합니다.
- Android에서는 VPN이 연결되어 있고 대상 앱이 앱별 규칙에서 제외되지 않았는지 확인합니다.
- 로컬 포트 충돌이나 다른 VPN 연결이 있는지 확인합니다.
- 로그를 지운 뒤 문제를 한 번 재현하고 새 로그로 실패 계층을 확인합니다.
문제 해결이 끝나면 임시로 전환했던 전역 모드를 일상적으로 필요한 라우팅 모드로 되돌리고, 사용자 지정 DNS·규칙 세트·앱별 설정을 항목별로 복원하세요. 각 항목을 복원할 때마다 접속 테스트를 실행합니다. 이렇게 하면 기존 분기 요구 사항을 유지하면서 어떤 설정이 장애를 다시 일으키는지 확인할 수 있습니다.
노드를 다시 가져온 뒤에도 인증 또는 핸드셰이크 오류가 계속되고 다른 노드는 정상이라면 해당 노드의 전체 매개변수를 업데이트해야 할 가능성이 큽니다. 같은 네트워크에서 모든 노드가 시간 초과되지만 네트워크를 바꾸면 복구된다면 현재 네트워크가 대상 주소, 포트 또는 프로토콜 트래픽을 제한하는지 확인하세요. 문제를 ‘특정 노드’, ‘특정 기기’, ‘특정 네트워크’ 중 하나로 좁히면 후속 조치가 훨씬 명확해집니다.