v2rayNG 자주 묻는 질문

세 단계로 확인합니다. 첫째, 받은 것이 웹페이지 주소가 아니라 구독 주소인지 확인하세요. 구독 주소를 열면 소개 페이지가 아니라 인코딩된 텍스트나 노드 목록이 나옵니다. 둘째, 주소가 잘리지 않았는지 확인하세요. 채팅 창이나 웹페이지에서 복사할 때 끝부분의 경로 파라미터를 놓치기 쉬우니 다시 통째로 복사하세요. 셋째, 다른 방식으로 가져와 검증하세요. v2rayNG에서 '클립보드에서 구독 가져오기'로 주소를 붙여 넣어도 오류가 나면 브라우저에서 그 주소를 직접 열어 반환 내용이 오류 페이지나 로그인 페이지인지 확인하세요.

주소 자체가 만료되면 클라이언트에서 어떻게 해도 노드를 받을 수 없으므로 서비스 제공자에게 새 구독 주소를 요청해야 합니다. 가져오기에 성공하면 노드가 그룹별로 목록에 표시되니, 먼저 실제 연결 지연 테스트를 한 번 하고 노드를 고르세요.

프로세서 아키텍처를 보면 됩니다. 2015년 이후 주류 스마트폰은 대부분 64비트 ARM 칩이므로 arm64 버전을 설치하면 되고, 패키지가 더 작고 실행 효율도 높습니다. 범용(universal) 버전은 여러 아키텍처용 라이브러리를 함께 담아 구형 기기와 에뮬레이터를 지원하는 대신 설치 파일이 큽니다.

확실하지 않다면 arm64 버전을 먼저 설치하고, 앱이 설치되지 않거나 패키지 파싱에 실패했다는 메시지가 나오면 범용 버전으로 바꾸세요. 두 버전의 앱 데이터는 호환되지 않으므로 버전을 바꾸기 전에 구독 주소를 복사해 두고, 설치 후 다시 가져오면 됩니다.

'프록시만'은 라우팅 규칙에 걸린 트래픽만 프록시로 보내고 나머지는 직접 연결하므로 규칙을 세밀하게 짜 둔 환경에 맞습니다. 'LAN 우회'는 모든 트래픽을 프록시로 보내면서 내부 네트워크 대역(192.168.x.x, 10.x.x.x 등)을 제외하며, 가정과 사무실 네트워크에서 흔히 쓰는 설정입니다. '전역'은 모든 트래픽을 프록시로 넘기므로 노드가 살아 있는지 임시로 확인할 때 적합합니다.

전환한 뒤에는 연결을 끊었다가 다시 연결해야 적용됩니다. 평소에는 'LAN 우회'에 두고, 특정 앱의 동작이 이상할 때 잠시 '전역'으로 바꿔 비교하면 문제가 분기 규칙에 있는지 노드 자체에 있는지 판단할 수 있습니다.

v2rayNG의 '앱별 프록시'는 두 가지 모드를 제공합니다. 화이트리스트는 체크한 앱만 프록시로 보내고, 블랙리스트는 체크하지 않은 앱만 통과시킵니다. 기본 상태에서는 모든 앱이 프록시를 사용합니다.

흔한 방법은 브라우저, 메일 클라이언트, 개발 도구를 화이트리스트에 넣고, 은행·결제·배달처럼 네트워크 환경에 민감한 앱은 제외해 로그인 위험 감지와 지역 검증으로 인한 문제를 줄이는 것입니다. 변경한 뒤에도 연결을 끊었다가 다시 연결해야 새 분기 규칙이 적용됩니다. 목록의 앱은 이름순으로 정렬되니 용도를 모르는 앱은 일단 체크하지 마세요.

먼저 '구독 업데이트'를 수동으로 한 번 눌러 반환 메시지를 확인하세요. 흔한 원인은 세 가지입니다. 첫째, 서비스 제공자가 구독 주소의 토큰이나 경로를 바꾸면 예전 주소는 곧바로 404를 반환합니다. 둘째, 현재 네트워크에서 구독 도메인 이름 해석이 실패할 수 있으니 다른 네트워크 환경(예: Wi-Fi에서 모바일 데이터로)에서 다시 시도해 보세요. 셋째, 클라이언트의 자동 업데이트 주기가 길어 실행할 때마다 새로 고치지는 않습니다.

주소가 유효한 것을 확인했다면 구독 설정에서 자동 업데이트를 켤 수 있습니다. 노드 공유 링크도 하나 복사해 예비로 남겨 두면, 구독을 잠시 불러오지 못할 때 주요 노드를 수동으로 먼저 가져올 수 있습니다.

바깥에서 안쪽 순서로 확인하고, 각 단계에서 변수는 하나만 바꾸세요. 첫째, 프록시를 끄고 직접 연결해 기기 네트워크 자체가 정상인지 확인합니다. 둘째, 다른 노드로 연결해 노드 하나의 문제인지 걸러냅니다. 셋째, 라우팅 모드와 앱별 프록시를 확인해 현재 앱이 프록시 범위에 있는지 보세요. 넷째, DNS 설정을 확인하세요. 로컬 해석이 실패하면 프록시에 연결되어도 페이지가 열리지 않습니다. 다섯째, 특정 사이트만 이상하다면 대개 그 사이트의 접속 정책 문제이며 노드와는 관련이 없습니다.

전체 과정에서 각 단계의 결과를 기록해 두고, 구체적인 지점을 찾은 뒤 그 부분만 조정하는 편이 클라이언트를 반복해서 재설치하는 것보다 훨씬 효과적입니다.

모든 노드가 동시에 실패하면 문제는 대개 클라이언트 밖에 있습니다. 먼저 구독을 수동으로 한 번 업데이트해 노드 정보가 만료되지 않았는지 확인하고, 네트워크 환경을 바꿔 테스트해 현재 Wi-Fi나 회선 문제인지 살펴보세요. 그다음 시스템 시간을 확인하세요. VMess처럼 시간 검증이 있는 프로토콜은 시간 오차에 민감해서 시스템 시간이 틀어지면 핸드셰이크가 바로 실패합니다.

네트워크를 바꾼 뒤 일부 노드가 살아나면 특정 회선의 문제이고, 모바일 데이터로 바꿔도 전부 실패한다면 문제는 구독 쪽일 가능성이 크므로 서비스 제공자에게 확인해야 합니다.

TUN 모드는 가상 네트워크 인터페이스로 트래픽을 가로채므로 시스템에서 VPN 권한을 부여해야 합니다. 처음 켤 때 시스템이 권한 대화상자를 띄우면 반드시 허용을 눌러야 하며, 그렇지 않으면 연결이 곧바로 끊깁니다. 이전에 거부했다면 시스템 설정의 VPN 또는 앱 권한에서 다시 허용하면 됩니다.

흔한 원인이 두 가지 더 있습니다. VPN 채널은 한 번에 하나의 앱만 차지할 수 있으니 다른 프록시 앱이 실행 중이지 않은지 먼저 확인하세요. 일부 커스텀 시스템은 백그라운드 시작을 제한하므로 배터리 및 성능 설정에서 클라이언트를 백그라운드 실행 허용 목록에 추가해야 합니다. TUN 모드는 시스템 프록시보다 적용 범위가 넓으니, 켠 뒤에는 테스트 페이지로 출구 주소가 바뀌었는지 먼저 확인하는 것이 좋습니다.

먼저 '시스템 프록시' 스위치가 켜져 있고 모드가 '시스템 프록시 자동 구성' 또는 '전역'으로 선택되어 있는지 확인하세요. 브라우저에 프록시 관리 확장 프로그램이 설치되어 있으면 확장이 시스템 프록시 설정을 덮어쓰므로, 시스템 설정을 따르도록 바꾸거나 잠시 사용 중지하세요.

또 한 가지 경우가 있습니다. 관리자 권한으로 실행되는 프로그램은 현재 사용자의 프록시 설정을 읽지 않을 수 있으며, 이런 프로그램은 TUN 모드로 트래픽을 가로채야 합니다. 설정을 바꾼 뒤 브라우저를 한 번 재시작해 새 프록시 구성이 적용되게 하고, 테스트 페이지를 열어 출구 주소를 확인하세요.

DNS 유출은 도메인 해석 요청이 프록시 채널을 거치지 않고 로컬 네트워크나 통신사 DNS에서 처리되는 현상입니다. 점검 방법은 이렇습니다. 연결 후 DNS 점검용 테스트 페이지를 열어 반환된 해석 서버의 소속을 확인하고, 로컬 통신사나 공유기 주소가 나온다면 유출이 있는 것입니다.

유출을 막으려면 원격 DNS를 켜서 해석 요청을 노드 쪽에서 처리하게 하고, 라우팅 설정에서 DNS 조회의 경로를 따로 지정하세요. 데스크톱에서는 로컬 네트워크를 거치지 않는 해석 주소를 DNS 설정에 지정할 수도 있습니다. 바꾼 뒤 다시 연결하고 한 번 더 측정해 확인하세요. DNS 설정과 라우팅 규칙은 서로 영향을 주므로 한 번에 하나씩만 바꾸는 것이 좋습니다.