V2Ray 문제 해결 가이드

인터넷에 연결되지 않을 때: 앱부터 외부 연결까지 단계별 점검

클라이언트에 실행 중이라고 표시되어도 화면이나 코어가 작동 상태에 들어갔다는 뜻일 뿐, 원하는 웹사이트에 접속할 수 있다는 보장은 없습니다. 먼저 모든 프로그램에서 실패하는지, 브라우저에서만 실패하는지, 일부 사이트에서만 실패하는지 구분하세요. 처음 발생한 시각, 최근 변경한 설정, 네트워크를 바꿔도 같은지 기록해 두세요. 연결 버튼을 반복해서 누르는 것보다 이런 기록이 문제를 파악하는 데 유용하며, 웹사이트 자체의 장애를 클라이언트 설정 오류로 오해하는 일도 줄일 수 있습니다.

비교 기준이 될 기본 연결 만들기

먼저 클라이언트의 트래픽 가로채기를 중지하고 시스템 프록시가 원래 상태로 돌아왔는지 확인한 다음, 평소 직접 접속할 수 있는 사이트를 열어 보세요. 이때도 접속되지 않으면 무선 네트워크, 유선 연결, 게이트웨이, 네트워크 로그인 페이지부터 확인하세요. 웹 인증이 필요한 공용 네트워크라면 먼저 인증을 마쳐야 합니다. 기본 네트워크가 정상이라면 클라이언트를 시작하고 유효한 기존 설정 하나를 선택하세요. 테스트 중에는 프록시 클라이언트를 하나만 실행하고, 네트워크 출구를 바꾸는 다른 도구는 일시 중지하세요.

다음으로 로컬 프록시 포트가 작동하는지 확인하세요. v2rayN에서 실제 HTTP 또는 SOCKS 수신 주소와 포트를 확인하고, 다른 가이드에 나온 숫자를 그대로 입력하지 마세요. 브라우저에서 프록시를 수동 설정했다면 프로토콜을 수신 포트에 맞춰야 하며, 주소는 보통 로컬 컴퓨터를 가리킵니다. SOCKS 주소를 HTTP 항목에 넣거나 원격 서버 포트를 로컬 프록시 포트로 입력하면 페이지가 전혀 열리지 않을 수 있습니다. 이 경우에도 노드 설정 자체는 정상일 수 있습니다.

로그로 ‘연결 요청이 들어오지 않음’과 ‘연결 후 실패’를 구분하세요

클라이언트 로그를 열고 접속 대상이 분명한 사이트를 다시 방문하세요. 관련 연결 기록이 전혀 없다면 브라우저가 시스템 프록시를 우회하는지, 확장 프로그램이 설정을 덮어쓰는지, 대상 프로그램이 시스템 프록시를 사용하지 않는지 먼저 확인하세요. 로그에 대상 도메인이 나타난다면 DNS 조회, 연결, 핸드셰이크 중 어느 단계에서 오류가 발생하는지 살펴보세요. 로그에서 중복 메시지가 합쳐질 수 있으므로 새 줄이 추가되지 않았다는 이유만으로 트래픽이 들어오지 않았다고 단정하지 마세요. 필요하면 로그 상세 수준을 잠시 높여 다시 검사하세요.

‘특정 사이트만 접속되지 않고 나머지는 정상’이라면 라우팅 규칙이 해당 도메인을 적절하지 않은 출구로 보내는지 확인하세요. 비교를 위해 클라이언트의 전역 프록시 라우팅을 잠시 사용할 수 있지만, 테스트가 끝나면 원래 설정으로 되돌리세요. 전역 라우팅에서는 열리고 기존 규칙에서는 열리지 않는다면 규칙 순서, 도메인 일치 여부, 직접 연결 시 DNS를 확인하세요. 두 방식 모두 실패한다면 노드 연결과 대상 서비스 상태를 점검하세요.

인증, 인증서, 기존 연결의 영향을 확인하세요

인증서 오류가 표시되면 시스템 날짜와 시간대, 시간 동기화 상태를 먼저 확인한 뒤 노드의 서버 이름 설정을 점검하세요. 문제를 덮기 위해 인증서 검증을 끄지 마세요. 브라우저에서는 웹페이지가 열리지만 특정 앱에서 인터넷을 사용할 수 없다면 해당 앱이 별도의 프록시, 고정 연결 풀 또는 백그라운드 서비스를 사용하는지도 확인하세요. 시스템 프록시를 바꿔도 이미 만들어진 연결은 바로 새로 연결되지 않을 수 있습니다. 현재 페이지만 새로 고치는 것보다 앱을 완전히 종료했다가 다시 실행하는 편이 새 설정을 확인하기에 좋습니다.

TUN을 켠 뒤 모든 트래픽이 끊기고 끄면 브라우저가 다시 작동한다면 권한, 가상 네트워크 어댑터, 라우팅, DNS 처리 설정을 확인하세요. 곧바로 클라이언트 전체를 다시 설치하지 마세요. 현재 설정을 저장하고 ‘클라이언트 하나, 노드 하나, 시스템 프록시’의 최소 작동 상태로 되돌린 다음 규칙을 하나씩 추가하세요. 매번 같은 페이지로 테스트하고 오류 메시지를 기록하세요. ‘열리지 않음’에서 그치지 말고 시간 초과, 연결 거부, 이름 조회 실패, 인증서 검증 실패 중 어떤 오류인지 확인해야 합니다.

복구 후에는 최소 세 가지를 확인하세요. 일반 웹페이지가 끝까지 로드되는지, 프록시가 필요한 앱에서 새 연결을 만들 수 있는지, 클라이언트를 종료한 뒤에도 기본 네트워크가 작동하는지 확인합니다. 일부 리소스만 표시되지 않는다면 설정 전체를 계속 바꾸기보다 브라우저 개발자 도구에서 실패한 도메인을 확인하세요. 자세한 점검 순서는 연결은 됐지만 인터넷이 안 될 때 확인할 항목을 참고하세요. 첫 설정을 아직 마치지 않았다면 시작 가이드부터 진행하는 편이 좋습니다.

노드 연결 시간 초과: 포트·전송·핸드셰이크 오류 구분

시간 초과는 한 가지 원인으로만 발생하지 않습니다. 연결 과정의 어느 단계가 정해진 시간 안에 완료되지 않은 상태입니다. 클라이언트 테스트 도구는 TCP 연결, 프록시를 통한 HTTP 요청, 기타 탐지 절차 등을 측정할 수 있으며, 서로 다른 테스트 결과를 같은 기준으로 비교할 수는 없습니다. 먼저 테스트 유형을 확인한 뒤 실제 접속을 시도하세요. 노드 하나의 테스트 실패가 구독 전체의 오류를 뜻하지 않으며, 포트 연결이 가능하다고 해서 인증과 전송 설정까지 올바른 것은 아닙니다.

특정 노드 문제인지 전체 환경 문제인지 먼저 확인하세요

같은 네트워크와 클라이언트 설정에서 서로 다른 출처 또는 경로의 유효한 노드 두 개를 각각 테스트하세요. 하나만 실패한다면 해당 노드와 서버 상태를 집중적으로 확인하세요. 모든 노드가 동시에 실패한다면 컴퓨터의 시간, 네트워크 출구, 방화벽, 코어 실행 상태를 점검하세요. 그다음 다른 네트워크로 잠시 바꿔 비교합니다. 네트워크 변경은 DNS와 출구를 함께 바꾸므로 환경에 문제가 있음을 보여 줄 뿐, 특정 설정이 잘못되었다고 단정할 수는 없습니다.

서버 주소와 포트는 구독 정보나 서비스 제공자가 안내한 전체 값을 기준으로 확인하세요. 도메인 뒤에 프로토콜 접두사를 중복으로 붙이지 말고, 포트 항목에 경로를 넣지 마세요. 수동 설정이라면 앞뒤 공백, 전각 문장 부호, 복사 누락도 확인해야 합니다. 도메인 주소라면 컴퓨터에서 주소가 조회되는지 확인하세요. 주소가 갱신되는 서비스라면 한 번 조회한 주소를 계속 고정하지 말고 설정을 다시 가져오세요.

오류가 발생한 단계에 따라 범위를 좁히세요

이런 오류 문구는 점검을 시작할 단서일 뿐, 원인을 확정하는 결론은 아닙니다. 예를 들어 연결 거부는 연결 요청에 명시적인 거부 응답이 왔다는 뜻이지만, 거부 주체는 원격 서버일 수도 있고 경로상의 장비일 수도 있습니다. 시간 초과 로그 한 줄만으로는 패킷 손실과 서버 무응답을 구분할 수 없습니다. 오류 전후의 로그 몇 줄, 특히 연결 대상과 사용된 아웃바운드를 기록하세요. 대상 웹사이트의 연결 거부와 프록시 서버의 연결 거부를 혼동하지 마세요. 서로 다른 계층의 문제입니다.

전송 설정은 관련 항목끼리 일치해야 합니다

TLS를 사용하는 노드는 서버 이름, 전송 프로토콜, 서버 요구 사항을 확인하세요. WebSocket의 경로와 Host, gRPC의 서비스 이름 같은 값은 서버 설정에 맞아야 합니다. 프로토콜 이름만 바꿔서는 안 됩니다. VLESS와 REALITY를 함께 사용할 때는 공개 키, 짧은 ID, 서버 이름, 흐름 제어 등 해당 조합에 필요한 항목도 확인하세요. 필수 항목은 조합에 따라 다르므로 서로 다른 가이드의 설정값을 끼워 맞추기보다 전체 링크를 다시 가져오는 것이 안전합니다.

시스템 시간이 맞지 않으면 인증서 유효기간 판정에 영향을 줄 수 있고 일부 프로토콜의 인증 과정에도 문제가 생길 수 있습니다. 시스템 설정에서 시간을 동기화한 뒤 코어를 다시 시작해 새 연결을 만드세요. 인증서 체인 오류가 발생하면 시스템 신뢰 저장소가 정상인지, 네트워크에 로그인 인증 페이지가 필요한지 확인하세요. 검증 생략을 상시 설정으로 사용하지 마세요. 서버 이름과 시간 문제에 관한 자세한 내용은 TLS 핸드셰이크 및 인증서 오류 해결을 참고하세요.

마지막으로 클라이언트나 코어를 업데이트해야 하는지 판단하세요. 로그에 필드 미지원, 프로토콜 인식 실패, 설정 파싱 오류가 명시된 경우에만 업데이트가 직접적인 해결책이 될 수 있습니다. 업데이트 전에 설정을 저장하고 클라이언트 다운로드 페이지에서 플랫폼에 맞는 버전을 선택하세요. 업데이트 후에는 기존 노드로 다시 테스트해 경로 변경까지 동시에 하지 않도록 합니다. 노드 자체가 만료되었거나 작동하지 않는다면 서비스 제공자에게 설정값과 점검 상태를 확인하세요. 테스트 간격을 계속 줄여 연결 요청을 늘리지 마세요.

복구 여부는 테스트 한 번의 성공으로 판단하지 말고 실제 웹페이지에 연결해 일정 시간 사용할 수 있는지 확인하세요. 유효한 노드 설정과 테스트 환경을 저장하고, 임시 방화벽 예외와 디버그 설정은 되돌리세요. 시간 초과가 다시 발생하면 이 기준을 바탕으로 노드, 네트워크, 컴퓨터 설정 중 무엇이 바뀌었는지 확인할 수 있습니다.

구독 업데이트 실패: 주소·가져오기 경로·콘텐츠 형식 확인

구독 업데이트는 콘텐츠 가져오기, 파싱, 그룹에 반영하기의 세 단계로 나뉩니다. 업데이트 오류가 표시되면 먼저 어느 단계에서 실패했는지 확인하세요. 연결 시간 초과는 대개 가져오기 단계의 문제입니다. 응답을 인식할 수 없다면 파싱 단계일 수 있고, 업데이트가 완료됐는데 노드가 보이지 않으면 그룹 필터와 콘텐츠 변경 여부를 확인해야 합니다. 처음부터 기존 구독을 삭제하지 마세요. 여전히 작동하는 기존 노드를 유지하면 연결을 이어가고 문제를 비교할 수 있습니다.

주소가 완전한지 확인하고 구독 정보를 보호하세요

서비스 제공자 페이지에서 구독 주소를 다시 복사해 앞뒤와 쿼리 매개변수가 모두 포함됐는지 확인하세요. 메신저에서 줄바꿈이 들어가거나, 브라우저가 실제 링크 대신 표시 텍스트를 복사하거나, 물음표 뒤의 매개변수를 수동으로 지우면 주소가 작동하지 않을 수 있습니다. 구독 주소에는 접속 정보가 포함되는 경우가 많으므로 공개 게시판에 전체 주소를 올리거나 알 수 없는 변환 서비스에 입력하지 마세요. 도움을 요청할 때는 오류 유형만 설명하고, 화면을 공유하기 전에 주소와 계정 정보, 노드 인증 항목을 가리세요.

계정 페이지에서 만료, 이용 정지, 데이터 소진, 구독 주소 재설정 안내가 있는지 확인하세요. 서비스 페이지에 로그인할 수 있다고 해서 기존 구독 주소도 유효한 것은 아닙니다. 웹페이지가 열린다고 구독 API가 정상이라는 뜻도 아닙니다. 서비스 제공자가 새 주소를 안내했다면 기존 그룹을 수정해 업데이트하세요. 이름이 비슷한 그룹을 여러 개 만들지 마세요. 어떤 노드가 같은 출처에서 왔는지 확인할 수 있도록 기존 그룹 메모를 남겨 두세요.

구독 가져오기와 노드 연결을 따로 점검하세요

노드 연결에 성공해도 같은 경로로 구독 API에 접속할 수 있다는 보장은 없습니다. 반대로 모든 노드가 작동하지 않을 때 기존 프록시로 구독을 가져오려 하면 순환 의존이 생길 수 있습니다. 클라이언트에 프록시를 통한 업데이트, 직접 업데이트 또는 비슷한 옵션이 있는지 확인한 뒤 현재 네트워크에 맞춰 선택하고 각각 비교 테스트하세요. 클라이언트와 화면에 따라 옵션 이름이 다르므로 구독 업데이트가 항상 시스템 프록시를 사용한다고 가정하면 안 됩니다.

직접 업데이트가 시간 초과되지만 기존 노드로 구독 서비스에 접속할 수 있다면 현재 프록시를 통해 업데이트해 보세요. 현재 프록시는 사용할 수 없지만 구독 API에 직접 접속할 수 있다면 직접 가져오기로 바꾸세요. 매번 가져오기 방식 하나만 조정하고 DNS와 그룹 주소를 동시에 바꾸지 마세요. 연속으로 실패하면 서버의 요청 제한에 걸리지 않도록 잠시 기다린 뒤 다시 시도하세요. 네트워크 로그인 인증이 필요한 환경이라면 먼저 인증을 완료해야 합니다. 그렇지 않으면 구독 콘텐츠 대신 로그인 페이지를 가져올 수 있습니다.

형식 호환성과 누락된 노드 확인

구독 콘텐츠는 인코딩된 공유 링크 모음일 수도 있고 특정 클라이언트 전용 형식일 수도 있습니다. 파일명이나 링크 끝의 확장자만으로 현재 클라이언트와 호환되는지 알 수 없습니다. 서비스 제공자가 v2rayN, v2rayNG, v2flyNG용이라고 명시한 링크를 우선 사용하세요. 로그에 특정 프로토콜 필드가 지원되지 않는다고 표시되면 임의로 필드를 지워 연결 오류를 만들기보다 클라이언트와 코어가 해당 항목을 지원하는지 확인한 뒤 소프트웨어를 업데이트하세요.

오류 없이 업데이트됐지만 노드 일부만 남았다면 키워드 필터, 프로토콜 필터, 그룹 필터가 설정되어 있는지 확인하세요. 서비스 제공자가 노드 목록을 변경했는지, 클라이언트가 중복 항목 처리 규칙에 따라 합쳤는지도 살펴보세요. 먼저 전체 그룹으로 전환한 뒤 알고 있는 노드 별칭을 검색하세요. 목록 개수가 어제와 다르다는 이유만으로 파싱 오류라고 판단하지 마세요. 서버 콘텐츠가 바뀌어도 같은 현상이 생길 수 있습니다.

업데이트 후 연결 매개변수가 바뀐 문제는 가져오기 문제와 별개입니다. 기존 노드가 교체되었거나 현재 선택 항목이 삭제된 노드를 가리킬 수 있습니다. 업데이트된 노드를 다시 선택하고 코어를 시작하세요. 새 구독은 가져와지지만 모든 노드가 연결되지 않는다면 계속 가져오기 과정을 점검하지 말고 노드 시간 초과 항목으로 이동하세요. 복구 후에는 필요한 그룹 설정을 백업해 접근이 제한된 위치에 보관하고 로그와 함께 공개하지 마세요.

복구 여부는 다음을 확인하면 됩니다. 업데이트가 완료됐다는 표시가 나오고, 대상 그룹에서 새 콘텐츠를 찾을 수 있으며, 유효한 노드를 선택해 실제 연결을 만들 수 있어야 합니다. 그룹을 처음 추가하는 방법은 구독 가져오기 가이드를, 주소 관리와 자주 묻는 사용 방법은 자주 묻는 질문을 참고하세요. 계정 상태가 정상인데 여러 기기에서 같은 주소로 모두 실패한다면 불필요하게 각 기기를 재설치하기보다 잠시 기다리거나 서비스 제공자에게 API 상태를 문의하세요.

속도 저하: 지연 시간·전송 속도·앱 사용 경험을 나눠 측정

페이지가 느리게 열리거나 동영상이 버퍼링되고 대용량 파일 다운로드가 느린 원인은 서로 다를 수 있습니다. 지연 시간은 한 번 왕복하는 데 걸리는 시간이고, 처리량은 지속적으로 데이터를 전송하는 능력입니다. 패킷 손실과 지터는 연결 안정성에 영향을 줍니다. 노드 목록에서 한 번 좋은 측정값이 나왔다고 모든 앱이 빠르다는 뜻은 아닙니다. 처음 화면이 뜨기까지 오래 걸리는지, 지속 속도가 낮은지, 연결이 간헐적으로 끊기는지 먼저 파악한 뒤 적절한 비교 방법을 선택하세요.

일관된 테스트 환경 만들기

평소 안정적인 대상 하나를 정하고 비슷한 시간대에 같은 네트워크와 클라이언트, 같은 방법으로 테스트하세요. 시스템 업데이트, 클라우드 동기화, 대역폭을 많이 쓰는 작업은 일시 중지하고 같은 네트워크의 다른 기기가 업로드 대역폭을 모두 사용하고 있지 않은지도 확인하세요. 업로드가 혼잡해도 웹페이지 응답이 느려질 수 있으므로 다운로드 사용량만 확인해서는 안 됩니다. 무선 신호가 약하다면 액세스 포인트에 가까이 이동하거나 유선 네트워크로 바꿔 로컬 무선 재전송을 원격 경로 문제로 오해하지 않도록 하세요.

그다음 노드만 바꿔 같은 대상의 상태를 확인하세요. 여러 노드에서 같은 사이트만 느리고 다른 사이트는 정상이라면 대상 사이트의 속도 제한, 콘텐츠 전달 경로, 계정 제한을 고려하세요. 같은 노드가 모바일 네트워크에서는 정상이고 유선 네트워크에서는 느리다면 접속 경로 차이일 수 있습니다. 여러 속도 테스트를 동시에 실행하지 마세요. 병렬 테스트는 대역폭을 서로 차지하므로 일상적인 사용 경험을 반영하지 않으며 결과를 공정하게 비교하기도 어렵습니다.

로그와 시스템 사용량으로 병목 위치 확인

전송 중 재연결, 시간 초과, 연결 재설정이 자주 발생한다면 안정성부터 해결하세요. 무작정 동시 연결 수를 늘리면 문제가 더 커질 수 있습니다. 작업 관리자나 시스템 모니터에서 클라이언트, 코어, 대상 앱이 프로세서를 지속적으로 많이 사용하는지 확인하세요. 절전 모드, 과열, 빈번한 백그라운드 검사도 암호화와 네트워크 처리에 영향을 줄 수 있습니다. 소프트웨어 설정을 바꾸기 전에 정상적인 전원과 냉각 상태를 확보하세요.

브라우저에서는 다운로드가 정상인데 특정 앱만 느리다면 해당 앱이 다른 출구를 사용하거나, 별도 프록시를 설정했거나, 다른 서비스 지역을 선택했는지 확인하세요. 라우팅 규칙에 따라 웹페이지는 프록시를 거치고 다운로드 도메인은 직접 연결될 수도 있고, 반대일 수도 있습니다. 대상 도메인의 연결 기록에서 실제 아웃바운드를 확인하세요. 앱 이름만 보고 경로를 추측할 수는 없습니다. 한 앱이 로그인, 미디어, 업데이트 등 여러 도메인을 동시에 사용할 수 있습니다.

전송 및 TUN 설정은 신중하게 조정하세요

멀티플렉싱이 모든 프로토콜과 네트워크 환경에서 더 빠른 것은 아닙니다. 특정 고급 전송 옵션을 켠 뒤에만 문제가 발생한다면 해당 옵션을 기본값으로 되돌려 비교하세요. 출처가 다른 설정을 모아 ‘범용 가속 설정’으로 사용하지 마세요. 프로토콜과 코어 조합에는 지원 범위가 있으며 서버에서 활성화하지 않은 기능을 클라이언트에서만 바꿔도 성능이 향상되지는 않습니다. 전송 유형을 임의로 바꾸기보다 서비스 제공자가 안내한 설정을 그대로 유지하는 것이 중요합니다.

TUN 모드에서 ‘작은 페이지는 열리지만 큰 파일은 멈추는’ 현상이 나타나면 MTU, 경로 MTU 탐색, UDP 처리를 원인 후보로 살펴볼 수 있지만 이것이 유일한 원인은 아닙니다. 먼저 TUN을 끄고 시스템 프록시로 같은 파일을 다운로드해 비교하세요. TUN에서만 문제가 생기면 가상 네트워크 어댑터와 코어 로그를 확인하세요. MTU를 조정해야 한다면 기존 값을 기록하고 작은 범위에서 시험하세요. 결과가 달라지지 않으면 원래 값으로 되돌리고, 설명할 수 없는 네트워크 값을 장기간 유지하지 마세요.

DNS 문제도 ‘느리게 느껴지는’ 원인이 될 수 있습니다. 도메인 조회가 재시도되면 처음 페이지를 여는 데 오래 걸려도 파일 전송이 시작된 뒤에는 속도가 정상일 수 있습니다. 이 경우 대역폭이 높은 노드만 찾지 말고 DNS 항목을 확인하세요. 브라우저 캐시도 흔히 놓치는 부분입니다. 두 번째 접속이 빠른 것은 리소스가 이미 컴퓨터에 저장되었기 때문일 수 있습니다. 첫 로딩을 비교하려면 새 세션을 사용하거나 캐시 조건을 동일하게 유지하세요.

최종적으로 확인할 것은 우연히 한 번 나온 최고 속도가 아니라 재현 가능한 개선입니다. 실제 사용 환경에서 충분히 테스트해 속도를 잠시 높이는 대신 연결이 자주 끊기지는 않는지 확인하세요. 서비스 제공자가 표시한 트래픽 배수는 요금 계산 기준이지 속도 보장이 아닙니다. 지역, 프로토콜, 트래픽 배수 선택은 노드 선택 비교 가이드를 참고하세요. 기본 네트워크가 이미 혼잡하다면 클라이언트 설정으로 접속 대역폭을 늘릴 수 없습니다. 먼저 로컬 네트워크와 상위 네트워크 상태를 점검하세요.

DNS 문제: 어디서 조회하고 결과가 어디에 사용되는지 확인

DNS는 도메인을 IP 주소로 변환하지만 프록시 환경에서는 시스템, 브라우저, 클라이언트 코어, 원격 서버 중 여러 곳에서 조회가 이루어질 수 있습니다. 한 곳에서 조회에 성공해도 실제 접속에 같은 결과가 사용된다는 보장은 없습니다. 처음부터 DNS 서버를 바꾸기보다 실패한 요청을 누가 보냈는지, 조회가 어떤 경로를 거치는지, 결과 주소가 라우팅 선택에 영향을 주는지 확인하세요. 도메인 조회와 연결 출구를 함께 살펴봐야 합니다.

이름 조회 실패와 연결 실패를 구분하세요

로그에 도메인 조회 실패가 명시되어 있다면 해당 도메인을 기록하고 같은 시각에 다른 도메인이 조회되는지도 비교하세요. 모든 도메인 조회가 실패한다면 DNS 서비스 자체와 접속 경로를 확인하세요. 특정 도메인만 문제가 있다면 권한 DNS 레코드, 캐시, 대상 도메인 상태를 살펴보세요. IP 주소로 사이트에 직접 접속하는 것은 신뢰할 만한 대체 테스트가 아닙니다. 많은 사이트가 서버 이름, 인증서, 가상 호스트를 사용하므로 IP 주소로 연결된다고 해서 도메인 접속 과정이 정상인 것은 아닙니다.

시스템에 내장된 도구로 시스템 측 DNS 조회를 확인할 수 있습니다. Windows에서는 nslookup example.com을 실행하세요. 이 명령은 시스템 조회가 응답을 받는지 확인할 뿐, 브라우저의 암호화 DNS나 클라이언트 내장 DNS도 같은 결과를 사용한다는 뜻은 아닙니다. 비교할 때 조회 시각과 네트워크를 기록하고 IP 주소 하나만 남기지 마세요. 시스템에서는 조회되는데 클라이언트에서 오류가 난다면 시스템 캐시를 반복해서 지우기보다 코어의 DNS 설정을 확인하세요.

도메인 정책과 규칙 순서 이해하기

라우팅 규칙은 도메인이나 IP 주소를 기준으로 적용할 수 있습니다. 도메인 규칙이 일치하지 않으면 일부 정책은 주소 규칙을 계속 확인하기 위해 도메인을 조회합니다. 아래 예시는 V2Ray/Xray 라우팅 객체에서 필드 위치를 이해하기 위한 일부 코드이며, 그대로 실행할 수 있는 완전한 설정은 아닙니다. DNS 서버 주소 설정과도 다르므로 이 한 줄만 바꿔 모든 이름 조회 문제를 해결할 수는 없습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

IPIfNonMatch는 도메인이 기존 규칙과 일치하지 않을 때 조회를 시도한 뒤 관련 IP 주소 규칙을 확인한다는 뜻입니다. 실제 결과는 규칙 순서, 조회 결과, 기본 아웃바운드에 따라 달라집니다. 다른 정책으로 바꾸면 판단 시점이 달라질 뿐 라우팅이 더 정확해진다는 보장은 없습니다. 먼저 대상 도메인이 어떤 출구를 사용해야 하는지 확인한 뒤 해당 규칙에 일치하지 않는 이유를 살펴보세요. 자세한 용어는 라우팅 및 분할 연결 용어를 참고하세요.

DNS 요청과 프록시 사이의 순환 의존을 피하세요

프록시 서버 주소가 도메인인데 해당 도메인을 조회하는 DNS 요청도 아직 연결되지 않은 프록시를 통해서만 보낼 수 있다면 시작 과정에서 순환 의존이 생길 수 있습니다. 암호화 DNS를 사용해도 해당 서비스 주소를 먼저 조회해야 할 수 있습니다. 클라이언트가 지원하는 범위에서 서버 도메인에 사용할 수 있는 초기 DNS 조회 경로를 마련하고, 프록시가 작동하기 전에도 해당 경로에 접근할 수 있는지 확인하세요. 확인 없이 복잡한 원격 DNS 조회 경로를 추가하지 마세요.

TUN을 사용할 때는 시스템 DNS 요청이 수신되고 전달되어 올바르게 라우팅되는지도 확인하세요. 브라우저 암호화 DNS, 시스템 암호화 DNS, 코어 DNS를 동시에 사용하면 프로그램마다 결과가 달라질 수 있습니다. 먼저 테스트 경로 하나를 정하고 다른 계층의 사용자 지정 설정은 잠시 끈 뒤 하나씩 다시 활성화하세요. FakeDNS와 같은 매핑 방식을 사용한다면 트래픽 가로채기를 끈 뒤 관련 앱의 연결을 다시 만들어야 합니다. 해당 매핑 방식에서만 유효한 주소를 계속 사용할 수 있기 때문입니다.

듀얼 스택 네트워크도 확인해야 합니다. 도메인에서 두 종류의 주소가 모두 반환되더라도 한쪽 네트워크 경로를 사용할 수 없으면 간헐적으로 기다리거나 일부 앱에서만 실패할 수 있습니다. 실제 연결에 어떤 주소가 사용되는지 확인한 뒤 클라이언트의 주소 선택 설정으로 잠시 비교하세요. 시스템 전체에서 특정 주소 유형을 비활성화하는 것은 첫 단계로 권장하지 않습니다. 라우팅, 게이트웨이, 상위 네트워크의 실제 문제를 가릴 수 있고 다른 앱에도 영향을 줄 수 있습니다.

복구를 확인할 때는 시스템 조회, 클라이언트 로그, 실제 웹페이지 접속을 각각 점검해 세 결과가 서로 모순되지 않는지 확인하세요. 네트워크도 한 번 바꿔 새 네트워크에서 DNS 설정이나 초기 조회 조건이 달라지는지 살펴보세요. DNS 주소만 바꿔 잠시 복구됐다가 다시 실패한다면 캐시 만료 후의 상태도 확인해야 합니다. ‘DNS 결과는 정상인데 연결은 실패함’이 확인되면 이후에는 DNS를 계속 바꾸지 말고 아웃바운드와 대상 서비스를 점검하세요.

시스템 프록시가 작동하지 않을 때: 프록시 주소·권한·TUN 확인

시스템 프록시는 앱이 참고하도록 제공되는 프록시 설정 모음이지, 모든 프로그램의 트래픽을 강제로 가로채는 스위치가 아닙니다. 일부 앱은 이 설정을 읽고, 일부 앱은 자체 프록시를 사용하며, 직접 연결하는 프로그램도 있습니다. 따라서 브라우저는 접속되지만 다른 프로그램은 안 된다고 해서 v2rayN이 실행되지 않은 것은 아닙니다. 먼저 대상 앱이 어떤 연결 방식을 지원하는지 확인한 뒤 시스템 프록시, 앱 내부 프록시, TUN 중 적절한 방식을 선택하세요.

시스템 설정에 프록시가 실제로 적용됐는지 확인하세요

v2rayN에서 시스템 프록시 자동 설정을 선택한 뒤 운영체제의 네트워크 프록시 설정을 열어 주소와 포트가 현재 수신 주소를 가리키는지 확인하세요. 이전 포트나 다른 프로그램의 주소가 남아 있다면 다른 클라이언트, 관리 도구, 자동화 스크립트가 설정을 덮어쓰는지 확인하세요. 다른 트래픽 처리 도구를 종료한 뒤 프록시 설정을 다시 적용하세요. 조직에서 관리하는 기기는 정책 제한이 있을 수 있으므로 관리 요구 사항을 우회하지 말고 허용된 네트워크 설정 방식을 확인하세요.

앱에서 프록시를 수동 설정했다면 프로토콜, 호스트, 포트를 확인하고 인증란에 잘못된 값이 들어 있지 않은지 점검하세요. 일반적인 로컬 수신 포트는 인증을 사용하지 않을 수 있으므로 노드의 사용자 ID나 비밀번호를 브라우저 프록시 인증란에 넣지 마세요. 문제 해결을 위해 수신 주소를 모든 네트워크 인터페이스로 무작정 바꾸는 것도 피해야 합니다. 로컬 전용으로 사용할 때는 로컬 범위로 유지해야 접근을 통제하기 쉽습니다. LAN에서 공유해야 한다면 접근 권한을 별도로 계획하세요.

자동 구성, 별도 프록시, 환경 변수 구분하기

시스템에는 수동 프록시, 자동 구성 스크립트, 앱 내부 프록시가 함께 설정되어 있을 수 있으며 우선순위는 앱에 따라 다릅니다. 브라우저 확장 프로그램도 브라우저의 아웃바운드를 별도로 바꿀 수 있습니다. 관련 확장 프로그램을 끄고 브라우저의 프록시 설정을 확인한 뒤 세션을 다시 만드세요. 명령줄 도구와 백그라운드 서비스는 환경 변수나 독립 설정을 사용할 수 있습니다. 브라우저가 정상이라고 해서 같은 경로를 사용한다고 단정하지 마세요. 이 안내서에서는 먼저 그래픽 인터페이스를 통해 실제 연결 지점을 확인합니다.

TUN 문제를 시작과 트래픽 전달로 나눠 확인하세요

TUN은 가상 네트워크 어댑터를 통해 해당 어댑터로 라우팅된 트래픽을 처리하지만, 실제 적용 범위는 시스템 라우팅과 클라이언트 설정에 따라 달라집니다. 시작에 실패하면 권한, 가상 네트워크 어댑터 생성, 드라이버 관련 로그를 먼저 확인하세요. 시작은 됐지만 인터넷이 되지 않으면 라우팅, DNS, 출구 선택, 서버 주소의 우회 설정이 올바른지 점검하세요. 스위치가 켜졌다고 트래픽이 모두 처리된다고 단정하지 말고, 모든 클라이언트가 같은 옵션을 제공한다고 가정하지도 마세요.

데스크톱에서 관리자 권한이 필요한 작업은 운영체제가 승인한 절차로 권한을 부여하세요. 권한을 부여한 뒤에도 실패한다면 이전 가상 네트워크 어댑터가 남아 있는지, 다른 네트워크 도구가 라우팅을 사용 중인지, 보안 소프트웨어에 명시적인 차단 기록이 있는지 확인하세요. 보안 기능 전체를 끄지 마세요. 기록을 바탕으로 필요한 구성 요소만 허용한 뒤 테스트하세요. 확실한 근거가 없다면 문제 해결 과정에서 새로운 위험이 생기지 않도록 기존 보안 설정을 유지하세요.

접속이 순환하거나 TUN을 켜자마자 인터넷이 끊기면 먼저 TUN을 끄고 시스템 프록시가 기본 상태에서 작동하는지 확인하세요. 그런 다음 트래픽 처리와 DNS 설정을 하나씩 활성화해 어느 단계에서 문제가 생기는지 확인하세요. 라우팅 규칙은 TUN으로 처리된 트래픽의 출구를 결정하며, TUN을 켠다고 모든 대상이 자동으로 같은 노드를 사용하는 것은 아닙니다. 설정 방법과 사용 사례는 TUN 설정 가이드와 가상 네트워크 어댑터 원리를 참고하세요.

클라이언트를 종료한 뒤 인터넷이 끊기면 시스템 프록시가 이미 종료된 로컬 프록시를 계속 가리키는지 먼저 확인하고, 가상 네트워크 어댑터와 라우팅이 정상적으로 해제됐는지도 살펴보세요. 프로세스를 모두 강제 종료하기보다 클라이언트를 다시 열어 트래픽 처리 중지, 시스템 프록시 해제 등 정상적인 절차로 복구하세요. 복구 후 현재 작동하는 트래픽 처리 방식을 기억해 두세요. 일상적으로는 필요한 방식 하나만 사용해 중복 프록시와 설정 덮어쓰기를 줄이는 것이 좋습니다.

클라이언트 충돌: UI·코어·설정 문제를 나눠 확인

창이 갑자기 닫히는 경우, 시작 버튼을 눌러도 반응이 없는 경우, 화면은 정상인데 코어가 종료되는 경우는 서로 다른 문제입니다. 시스템 트레이 아이콘이 남아 있는지, 로그가 계속 갱신되는지, 작업 관리 도구에서 관련 프로세스가 실행 중인지 확인하세요. 시작 직후 종료되는지, 특정 노드를 가져온 뒤 종료되는지, TUN을 켤 때만 종료되는지 등 발생 동작을 기록하세요. 안정적으로 재현되는 조건이 일회성 충돌 메시지보다 문제를 찾는 데 도움이 됩니다.

설정을 보호한 뒤 실행 환경을 점검하세요

폴더 삭제, 설정 초기화, 재설치 전에 클라이언트가 지원하는 내보내기 기능으로 필요한 설정을 저장하세요. 구독 주소와 노드 인증 정보는 민감하므로 본인이 관리하는 위치에 백업해야 합니다. 화면을 열 수 없다면 복구를 위해 기존 데이터 폴더를 복사해 둘 수 있지만 전체 폴더를 공개하지 마세요. 현재 설치에 해당하는 설정 경로인지도 확인하세요. 다른 휴대용 폴더의 데이터를 현재 실행 중인 인스턴스의 데이터로 착각할 수 있습니다.

클라이언트 다운로드 페이지에서 플랫폼과 프로세서 아키텍처를 확인하세요. 데스크톱 운영체제에서 한 종류의 앱이 실행된다고 해서 다른 아키텍처용 패키지도 적합한 것은 아닙니다. 특히 프로세서가 다른 기기로 옮길 때는 해당 기기에 맞는 패키지를 다시 선택하세요. Windows 데스크톱 버전과 클래식 WPF 버전은 서로 다른 UI 기술을 사용합니다. 선택한 패키지의 요구 사항에 따라 실행 환경을 확인하고, 한 UI의 의존성 안내를 다른 UI에 그대로 적용하지 마세요.

UI가 열리지 않는 문제와 코어가 시작되지 않는 문제를 따로 해결하세요

UI가 시작하자마자 종료되면 시스템 이벤트 기록, 앱 로그, 디스크 여유 공간을 확인하세요. 설치 폴더에 쓸 수 없거나 사용자 데이터 폴더 권한에 문제가 있거나 동기화 프로그램이 파일을 잠그면 시작에 영향을 줄 수 있습니다. 프로그램을 정상적으로 접근할 수 있는 위치에 두고 현재 사용자에게 필요한 권한이 있는지 확인하세요. 일반적인 파일 접근 문제를 숨기기 위해 항상 최고 권한으로 실행하지 마세요. TUN에 필요한 권한 상승 작업은 일상적인 UI 시작 문제와 따로 판단해야 합니다.

UI는 열려 있지만 코어가 바로 중지된다면 설정 생성 오류와 수신 포트 문제를 중점적으로 확인하세요. 주소가 이미 사용 중이라는 로그는 다른 인스턴스가 실행 중이거나 다른 프로그램이 같은 포트를 사용한다는 뜻일 수 있습니다. 중복 인스턴스를 종료하고 포트 용도를 확인한 뒤 로컬 수신 설정을 수정하세요. 수정 후에는 시스템 프록시와 앱의 프록시 설정도 함께 업데이트해야 합니다. 클라이언트 포트만 바꾸고 브라우저가 이전 포트를 계속 사용하면 ‘시작은 됐지만 접속되지 않음’ 문제가 생깁니다.

설정 파싱 오류, 지원되지 않는 필드, 규칙 파일 읽기 실패가 표시되면 최근 변경 사항부터 확인하세요. 직접 편집한 JSON은 따옴표, 쉼표, 필드 유형을 점검하되 클라이언트가 시작할 때마다 다시 생성하는 파일을 직접 수정하지 마세요. 설정 화면에서 해당 항목을 되돌리거나 이전에 저장한 설정을 복원하는 편이 좋습니다. 가져온 설정이 현재 코어와 호환되지 않는다면 임의로 오류 행을 지우지 말고 프로토콜 지원 여부를 확인하세요.

업데이트 후 문제가 생기면 이전 상태와 비교하세요

업데이트 직후 문제가 발생했다면 사용한 패키지 유형, 시스템 환경, 문제를 재현하는 동작을 기록하세요. 버전 정보를 지어내거나 기억에만 의존해 작성하지 마세요. 이전 프로세스가 종료됐는지, 새 프로그램이 기존 데이터 위치를 계속 읽고 있는지 확인하세요. 여러 인스턴스가 같은 데이터 폴더를 사용하면 상태가 꼬일 수 있습니다. 재설치 전에 실제로 어떤 실행 파일이 작동 중인지 확인하세요. 바탕 화면 바로 가기가 이전 폴더를 가리킬 수도 있습니다.

보안 소프트웨어가 구성 요소를 격리하거나 차단했다면 명확한 이벤트 기록과 파일 출처를 확인한 뒤 복원하거나 예외를 설정하세요. 보호 기능을 한꺼번에 모두 끄지 마세요. 디스크 공간 부족, 비정상 종료, 데이터 기록 중단도 설정을 불완전하게 만들 수 있습니다. UI를 열 수 있다면 읽을 수 있는 데이터를 먼저 내보낸 뒤 새 작업 데이터를 만드세요. 복구할 때 그룹과 규칙을 하나씩 가져오면 문제를 유발한 항목을 찾기 쉽습니다.

문의를 올릴 때는 운영체제 종류와 아키텍처, 클라이언트 UI 유형, 재현 단계, 민감 정보를 가린 오류 전후 상황을 포함하세요. 구독 인증 정보, 서버 인증 필드, 불필요한 개인 경로는 숨기세요. 복구 후에는 일반 연결을 먼저 확인한 다음 복잡한 라우팅과 TUN을 다시 추가하세요. 창이 열리는지만 확인하지 말고 실제 사용 상태도 충분히 관찰해야 합니다. 코어와 그래픽 클라이언트의 관계는 Project V 생태계 안내를 참고해 UI 문제와 코어 문제를 구분하세요.

모바일 연결 오류: VPN 권한·백그라운드 실행·앱별 규칙 확인

Android 문제 해결은 v2rayNG를 기준으로 설명하고, V2Fly 코어를 사용하는 대안으로 v2flyNG도 다룹니다. 두 클라이언트는 설정 기능과 UI 세부 사항이 다를 수 있으므로 한쪽의 고급 설정이 다른 쪽에도 그대로 적용된다고 가정하지 마세요. 현재 실제로 실행 중인 클라이언트를 확인한 뒤 기본 네트워크, VPN 권한, 노드 연결, 앱별 규칙 순서로 점검하세요. 데스크톱 시스템 프록시 사용 경험만으로 Android의 VPN 트래픽 처리를 판단할 수 없습니다.

시작 후 인터넷이 되지 않으면 VPN 권한과 충돌부터 확인하세요

처음 연결할 때 시스템에서 VPN 연결 권한을 허용해야 합니다. 권한 설정을 마치지 않으면 노드를 가져와도 앱 트래픽을 자동으로 처리할 수 없습니다. 시스템 VPN 설정과 클라이언트 알림을 확인해 원하는 클라이언트가 현재 연결되어 있는지 살펴보세요. Android에서는 일반적으로 한 사용자 공간에서 VPN 서비스를 하나만 실행할 수 있습니다. VPN 방식을 사용하는 다른 네트워크 도구가 충돌할 수 있으므로 다른 서비스를 중지한 뒤 테스트할 클라이언트만 시작하세요.

시스템에서 VPN 상시 사용을 설정했거나 VPN을 사용하지 않을 때 연결 차단을 켰다면 클라이언트가 끊겼을 때 기본 네트워크도 작동하지 않을 수 있습니다. 시스템 정책에 따른 동작이며 네트워크가 손상되었다는 뜻은 아닐 수 있습니다. 문제를 점검하기 전에 이 옵션의 영향을 확인하고, 필요한 경우 허용된 기기 관리 범위 안에서 테스트 조건을 조정한 뒤 복구하세요. 업무 프로필이나 기기 정책이 적용되는 환경에서는 관리자가 안내한 네트워크 방식을 따르세요.

화면을 끈 뒤 연결이 끊기는 문제와 백그라운드 제한을 따로 확인하세요

앱이 화면에 표시될 때는 정상인데 화면을 잠근 뒤 연결이 끊긴다면 배터리 최적화, 백그라운드 활동 제한, 데이터 절약 모드를 먼저 확인하세요. 제조사마다 설정 위치가 다를 수 있으므로 앱 정보에서 배터리, 백그라운드 데이터, 자동 시작 관련 항목을 찾아보세요. 사용 중인 클라이언트에 필요한 권한만 조정하고 모든 앱의 전원 설정을 바꿀 필요는 없습니다. 알림 권한과 백그라운드 서비스 제한도 확인하되 알림이 보인다는 사실만으로 노드 연결이 계속 유지된다고 판단할 수는 없습니다.

테스트할 때 노드 하나를 고정하고 먼저 앱을 화면에 표시한 상태에서 접속해 보세요. 그다음 화면을 잠시 껐다가 해제한 직후 로그에서 재연결과 네트워크 변경 기록을 확인하세요. 무선 네트워크에서 모바일 네트워크로 바꿀 때만 끊긴다면 기존 연결이 끊어진 뒤 복구되지 않았을 수 있습니다. 먼저 연결을 중지했다가 다시 만들어 새 네트워크에서 사용할 수 있는지 확인하세요. 연결이 복구되기 전에 프로토콜 매개변수를 반복해서 바꾸면 네트워크 전환 문제와 설정 문제가 섞일 수 있습니다.

일부 앱만 실패하면 앱별 규칙과 DNS를 확인하세요

앱별 프록시에는 선택한 앱만 프록시를 사용하거나 선택한 앱을 프록시에서 제외하는 방식이 있습니다. 모드를 반대로 선택하면 앱을 체크했는데도 프록시를 사용하지 않을 수 있습니다. 먼저 모드를 확인한 뒤 대상 앱과 필요한 관련 서비스가 올바른 목록에 포함됐는지 점검하세요. 변경 후 VPN 연결을 다시 만들고 대상 앱을 완전히 종료했다가 실행하세요. 브라우저와 특정 앱의 결과가 다른 이유는 앱마다 DNS나 연결 프로토콜이 다르기 때문일 수 있습니다. 웹페이지 테스트 한 번만으로 트래픽 처리 범위를 판단하지 마세요.

시스템 비공개 DNS, 클라이언트 DNS, 앱 내부의 암호화 DNS가 동시에 설정되어 있을 수 있습니다. 로그에 이름 조회 실패가 나타나면 모든 DNS 설정을 바꾸기 전에 DNS 문제 해결 절차에서 실제 조회 주체를 확인하세요. 모든 조회 경로를 서로 다른 서비스로 한꺼번에 바꾸지 마세요. 모바일 네트워크와 무선 네트워크에서 결과가 다르면 새 네트워크에 인증이 필요한지, 특정 연결이 제한되는지, 클라이언트가 기존 아웃바운드를 복구했는지도 확인하세요. 필요하면 다른 유효한 노드 하나로 비교하세요.

설치·이전 및 최종 확인

기기 아키텍처와 맞지 않는 설치 패키지는 설치되지 않거나 실행되지 않을 수 있습니다. 기기의 프로세서와 시스템 지원 여부에 맞춰 선택하세요. 대부분의 최신 기기는 arm64를 사용합니다. 확실하지 않다면 기기 정보를 확인하고 다운로드 페이지의 범용 패키지 안내를 참고하세요. 기존 앱 위에 설치할 수 없다면 시스템이 표시한 원인을 확인하고 서명 차이 또는 다른 사용자 공간의 설치 기록이 있는지 살펴보세요. 덮어 설치를 위해 바로 데이터를 지우지 말고 먼저 백업하세요.

설정을 이전할 때 시스템 관련 옵션을 무작정 모두 복사하기보다 본인의 구독을 다시 추가해 업데이트하는 것이 좋습니다. 앱별 목록, 백그라운드 권한, VPN 권한은 기기 환경에 따라 달라지므로 새 기기에서 다시 확인해야 합니다. 수동으로 추가한 노드 하나만 연결되지 않는다면 전체 공유 매개변수와 코어 지원 여부를 확인하세요. 두 네트워크에서 모든 노드가 실패한다면 휴대폰 설정만 반복해서 살펴보기보다 계정과 서비스 상태를 점검하세요.

마지막으로 실제 사용 환경에서 확인하세요. 앱을 화면에 표시한 상태의 접속, 화면 잠금 후 복구, 네트워크 전환, 대상 앱 연결, 정상적인 연결 종료 후 기본 네트워크가 모두 예상대로 작동해야 합니다. 유효한 설정을 저장하고 임시 디버그 설정과 불필요한 권한 변경은 되돌리세요. 설치 패키지를 다시 선택해야 한다면 Android 클라이언트 다운로드로 이동하세요. 자주 쓰는 기능 차이만 알아보려면 자주 묻는 질문을 참고하세요. 한 차례 검증을 마친 뒤 일상적인 복잡한 규칙을 다시 적용해야 다음 문제도 명확한 기준으로 점검할 수 있습니다.