V2Ray 문제 해결 가이드

인터넷 연결 안 됨: 연결이 끊기는 지점부터 확인

직접 연결과 프록시 연결을 비교하세요

‘인터넷이 안 된다’는 말만으로는 문제를 정확히 파악하기 어렵습니다. 모든 앱에서 연결이 안 되는지, 브라우저에서만 안 되는지, 특정 사이트만 열리지 않는지 먼저 구분하세요. 프록시 클라이언트를 종료하고 시스템 프록시를 원래 설정으로 되돌린 뒤, 직접 연결되는 평소 사이트에 접속해 보세요. 그래도 연결되지 않으면 네트워크 접속, 무선 연결, 게이트웨이, 웹 로그인이 필요한 네트워크 인증부터 확인하세요. 기본 네트워크에 문제가 있을 때 노드를 계속 바꾸면 상황만 복잡해질 수 있습니다.

직접 연결이 복구되면 클라이언트를 실행하고 정상적인 사용 권한이 있는 노드 하나를 선택하세요. 데스크톱에서는 v2rayN, Android에서는 v2rayNG를 우선 사용하고, V2Fly 설정이 필요한 경우에만 v2flyNG를 고려하세요. 시스템 트래픽을 가로채는 도구를 여러 개 동시에 실행하지 마세요. TUN과 복잡한 분할 라우팅을 끄고, 시스템 프록시를 지원하는 브라우저에서 일반 프록시 연결을 확인해 문제 범위를 좁히세요.

요청이 지나는 단계별로 확인하세요

일반적인 접속은 앱의 프록시 설정, 로컬 수신 포트, 라우팅 규칙, 노드 연결, 대상 서비스 순으로 진행됩니다. 클라이언트 창이 열려 있다는 사실은 관리 프로그램이 실행 중임을 뜻할 뿐입니다. 노드를 선택했더라도 코어가 실행 중이라는 보장은 없습니다. 클라이언트 로그에서 먼저 시작 성공 여부와 수신 주소 및 포트를 확인한 뒤, 접속을 시도했을 때 해당 요청이 기록되는지 살펴보세요. 요청 기록이 없다면 앱이 실제로 트래픽을 클라이언트에 전달하는지부터 확인해야 합니다.

로그에 로컬 포트 바인딩 실패가 표시되면 다른 클라이언트나 프로그램이 해당 포트를 사용 중인지 확인하세요. 수신 포트를 변경했다면 앱에 입력한 프록시 포트도 함께 수정해야 합니다. 로컬 인바운드 포트와 원격 노드 포트를 혼동하지 마세요. 전자는 이 기기의 앱 요청을 받고, 후자는 서버에 연결합니다. 두 포트의 숫자가 같더라도 서로 자동으로 연결되는 것은 아닙니다.

한 번에 한 가지씩 바꿔 원인을 좁히세요

같은 노드를 유지하고 클라이언트 라우팅만 명시적인 프록시 경로로 임시 변경한 뒤 같은 대상에 접속해 보세요. 연결되면 분할 라우팅 규칙에 문제가 있을 가능성이 큽니다. 여전히 실패하면 다른 설정은 그대로 둔 채 정상 작동이 확인된 노드로 바꿔 보세요. 매번 변경 항목과 결과를 기록하면 여러 설정을 바꾼 뒤 갑자기 해결되어 원인을 알 수 없는 상황을 피할 수 있습니다. 테스트가 끝나면 원래 모드로 되돌려 임시 전체 프록시 설정이 최종 설정으로 남지 않게 하세요.

특정 사이트 하나만 열리지 않는다면 해당 서비스 상태를 확인하고 정상 작동하는 다른 사이트와 비교하세요. 웹페이지는 열리지만 이미지나 로그인이 실패한다면 관련 도메인이 다른 경로를 사용하거나 대상 서비스가 현재 출구를 거부하는 것일 수 있습니다. 이때는 노드 전체가 고장 났다고 단정하지 말고 실패한 요청의 도메인과 라우팅 경로를 확인하세요.

복구 여부는 반복해서 확인할 수 있어야 합니다. 클라이언트를 끄면 연결이 끊기고 정해 둔 설정으로 다시 실행하면 복구되며, 로그에 표시된 대상과 아웃바운드가 예상과 일치해야 합니다. 이 최소 작동 설정을 저장한 뒤 분할 라우팅, TUN, 앱별 설정을 하나씩 활성화하세요. 연결 확인 방법은 첫 연결 및 실제 연결 속도 측정 가이드에서 더 확인할 수 있습니다.

노드 시간 초과: 포트, 핸드셰이크, 프로토콜 구분

시간 초과가 발생한 단계를 먼저 확인하세요

노드 시간 초과는 도메인 조회, 전송 연결, TLS 핸드셰이크 또는 프로토콜 인증 단계에서 발생할 수 있습니다. 마지막의 막연한 연결 실패 문구만 보지 말고 로그에서 관련된 첫 번째 오류를 찾으세요. 대상 호스트, 포트, 오류 유형, 발생 시간을 기록하세요. 같은 노드라도 네트워크에 따라 결과가 다를 수 있으며, 이는 한 번 측정한 속도보다 진단에 더 유용합니다. 테스트할 때는 노드 매개변수와 클라이언트 모드를 동일하게 유지하세요.

TCPing은 포트 연결 상태를 주로 확인하며, 프록시 프로토콜 전체 과정이나 인증 정보, 대상 웹사이트 접속을 검증하지는 않습니다. 포트에 연결되지만 실제 요청이 실패한다면 사용자 식별 정보 불일치, 전송 경로 오류, TLS 매개변수 불일치가 원인일 수 있습니다. 반대로 특정 테스트 방식이 실패해도 실제 트래픽이 모두 차단된다는 뜻은 아닙니다. 포트 테스트와 클라이언트의 실제 연결 테스트를 함께 사용하고, 두 지표를 같은 것으로 취급하지 마세요.

원격 주소와 전송 매개변수를 확인하세요

먼저 노드 주소 앞뒤에 공백이 없는지, 포트가 유효한 범위에 있는지, 서버에서 제공한 정보와 일치하는지 확인하세요. 이어서 프로토콜, 사용자 식별 정보, 비밀번호, 전송 유형, 추가 필드를 점검하세요. WebSocket의 경로와 Host, gRPC의 서비스 이름은 정확히 일치해야 합니다. 사소해 보이는 슬래시나 대소문자 차이 때문에 요청이 잘못된 서비스로 전달될 수도 있습니다. 다른 노드의 입력 방식을 보고 누락된 필드를 추측해 채우지 마세요.

주소가 도메인이라면 현재 해당 도메인을 조회할 수 있는지 먼저 확인하세요. 서비스 제공자가 확인한 주소로 잠시 바꾸는 방법은 통제된 진단에만 사용해야 하며, 도메인 검증에 의존하는 설정을 임의로 수정해서는 안 됩니다. 연결 주소, TLS의 serverName, HTTP Host는 각각 연결 대상, 서비스 신원 검증, 애플리케이션 계층의 호스트 이름을 지정합니다. 세 값이 항상 같아야 한다고 단정할 수 없습니다.

TLS 및 REALITY 오류 확인

인증서가 아직 유효하지 않거나 만료됐다는 메시지는 기기 시간이 잘못됐거나 서버 인증서에 실제 문제가 있음을 나타낼 수 있습니다. 먼저 시스템 날짜, 시간대, 시간을 동기화한 다음 SNI가 서버 요구사항과 일치하는지 확인하세요. 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 도메인 오입력, 인증서 체인 누락, 잘못된 호스트 연결 같은 원인을 숨길 수 있으며, 접속되더라도 설정이 올바르다는 보장이 없습니다.

REALITY 연결에서는 서버 공개 키, shortId, serverName, 지문, 서비스 제공자가 요구한 flow도 확인해야 합니다. 필드 지원 여부는 선택한 코어와 클라이언트 구현에 따라 다르므로, 노드 이름에 특정 용어가 포함됐다고 해서 호환된다고 판단하지 마세요. 알 수 없는 필드나 지원되지 않는 프로토콜 메시지가 표시되면 먼저 코어 유형을 확인한 뒤 설정 출처를 점검하세요. 자세한 차이는 Xray와 V2Fly 코어 차이를 참고하세요.

네트워크를 바꿔 비교하고 서버를 확인하세요

같은 기기에서 신뢰할 수 있는 무선 네트워크와 모바일 데이터를 각각 사용해 테스트하세요. 한쪽 네트워크에서만 실패한다면 네트워크 인증, 접속 정책, 주소 체계, 통신사 경로를 확인하세요. 모든 네트워크에서 실패하지만 다른 노드는 정상이라면 해당 노드 자체를 집중적으로 점검하세요. 테스트 중에는 다른 다운로드를 중지해 기기 혼잡으로 핸드셰이크가 지연되지 않도록 하세요. 원인을 가리기 위해 시간 초과 값을 계속 높이지 마세요.

서버 관리 권한이 있다면 서비스 프로세스가 올바른 주소를 수신 대기 중인지, 호스트 방화벽과 상위 보안 규칙이 대상 포트를 허용하는지 확인하고 같은 시간대의 서버 로그를 살펴보세요. 관리 권한이 없다면 민감 정보를 지운 발생 시간과 오류 단계, 테스트 네트워크를 서비스 제공자에게 전달해 확인하세요. 노드 링크 전체를 공개하지 마세요. 재연결 시에만 가끔 시간 초과가 발생하고 이후 계속 정상 작동한다면 클라이언트를 바로 재설치하기보다 절전 복귀와 네트워크 전환을 확인하세요.

변경을 마친 뒤 같은 대상으로 가벼운 요청을 여러 번 보내 핸드셰이크가 안정적으로 재현되는지 확인하고, 정상 분할 라우팅으로 되돌리세요. 인증서 문제에 관한 자세한 내용은 TLS 인증서 및 SNI 문제 해결을 참고하세요. 포트는 연결되지만 인증이 실패한다면 매개변수를 다시 확인하고 시스템 프록시를 반복해서 조정하지 마세요.

구독 업데이트 실패: 가져오기·형식·파싱 확인

업데이트 과정을 세 단계로 나눠 확인하세요

구독 업데이트는 주소의 콘텐츠 가져오기, 콘텐츠 형식 식별, 노드를 클라이언트에 저장하는 세 단계로 진행됩니다. 업데이트 실패 메시지가 나타나면 네트워크 오류인지, 비정상 HTTP 상태인지, 콘텐츠 파싱 오류인지 먼저 확인하세요. 기존 노드가 작동해도 구독 주소를 정상적으로 가져올 수 있다는 뜻은 아닙니다. 업데이트가 성공해도 새 노드마다 연결된다는 보장은 없습니다. 두 경로를 각각 확인하고 한쪽 결과로 다른 쪽을 판단하지 마세요.

클라이언트의 구독 그룹에서 주소 전체가 정확한지 확인하고, 복사 과정에서 쿼리 매개변수가 빠지거나 줄바꿈 또는 설명 문구가 섞이지 않았는지 살펴보세요. 주소에 포함된 접속 정보는 민감하므로 공개 스크린샷이나 온라인 변환 사이트에 올리지 마세요. 보기 좋게 만들려고 주소 인코딩을 바꾸지 마세요. 퍼센트 인코딩과 구분 기호가 서버에서 주소를 식별하는 데 사용될 수 있습니다. 원래 주소를 따로 저장한 뒤 서비스 제공자가 준 전체 주소를 다시 붙여 넣으세요.

업데이트 요청에 실제로 어떤 경로가 사용되는지 확인하세요

일부 클라이언트는 구독 업데이트에 직접 연결을 사용할지, 현재 프록시를 경유할지 선택할 수 있습니다. 직접 연결로 구독 서버에 접속할 수 없다면 정상 작동하는 노드가 있는 경우 프록시를 통한 업데이트를 테스트할 수 있습니다. 현재 노드가 이미 작동하지 않는다면 그 노드로 구독을 가져오려는 시도는 순환 문제를 일으킬 수 있습니다. 브라우저 프록시만 바꾸지 말고 업데이트 설정을 확인하세요. 사용할 수 있는 노드가 없다면 정상 네트워크로 서비스 제공자가 제공한 유효한 설정을 가져오고, 신뢰할 수 없는 변환 서비스를 임의로 찾지 마세요.

시간 초과는 보통 접속 경로나 DNS 조회 문제를 가리키며, 연결 거부는 서버 포트가 열려 있지 않을 가능성이 있습니다. 인증 관련 상태라면 구독 권한을 확인하세요. 요청 빈도 제한이 표시되면 서비스 제공자 규칙에 따라 기다리고 업데이트 버튼을 연속으로 누르지 마세요. 서버 오류가 반환되면 시간과 상태 정보를 기록하고 잠시 후 다시 시도하세요. 그룹을 반복해서 삭제하고 다시 만들어도 원격 서비스 오류는 해결되지 않으며 기존에 사용 가능한 노드를 잃을 수 있습니다.

파일 확장자가 아니라 반환된 콘텐츠를 확인하세요

구독에는 인코딩된 공유 링크 모음이나 클라이언트가 지원하는 다른 형식이 포함될 수 있습니다. 일반 JSON 설정, 단일 공유 링크, 구독 주소는 서로 다른 입력이므로 각각 맞는 가져오기 메뉴에 넣어야 합니다. 서버가 반환한 로그인 페이지, 만료 안내, 오류 페이지는 상태가 정상처럼 보여도 노드 데이터가 아닙니다. 파싱 오류가 발생하면 콘텐츠 유형을 확인하고 주소 끝에 특정 확장자가 있는지만으로 판단하지 마세요.

공유 링크의 프로토콜 필드와 전송 매개변수를 클라이언트가 지원해야 합니다. 일부 가져오기 도구는 기본 노드는 인식하지만 추가 매개변수를 무시해 가져오기는 성공했는데 연결은 실패할 수 있습니다. 가져온 노드의 편집 화면과 원래 매개변수를 비교하고 TLS, 보안 계층, 전송 유형, 특수 프로토콜 필드를 집중적으로 확인하세요. 형식 차이와 변환 시 주의점은 구독 형식과 공유 링크 간 변환을 참고하세요.

업데이트 후 목록 확인

먼저 노드 목록의 검색어와 필터를 해제한 뒤 방금 업데이트한 구독 그룹을 선택하세요. 일부 클라이언트는 이전 활성 서버나 목록 선택을 유지해 새 노드가 있어도 표시되지 않을 수 있습니다. 서버가 실제로 빈 목록을 반환했다면 반복해서 가져오지 말고 구독 권한, 요금제 상태, 서비스 제공자의 노드 필터 조건을 확인하세요. 같은 주소로 그룹을 여러 개 만들어도 사용할 수 있는 노드가 늘지는 않으며, 출처만 추적하기 어려워집니다.

구독을 정리하기 전에 아직 작동하는 기존 노드 하나나 설정 백업을 보관하세요. 자동 업데이트가 구독 노드의 수동 변경 사항을 덮어쓸 수 있습니다. 장기간 사용할 변경 사항은 클라이언트가 지원하는 별도 설정이나 그룹 정책으로 관리하고, 임시 수정 결과가 계속 저장될 것이라고 기대하지 마세요. 복구 후에는 새 노드의 실제 연결을 확인하고 다음 업데이트에서도 콘텐츠를 가져올 수 있는지 점검하세요. 가져오기 메뉴에 관한 일반적인 질문은 자주 묻는 질문에서 확인할 수 있습니다.

속도 저하: 지연 시간·전송 속도·앱 대기 구분

어떤 과정이 느린지 먼저 구분하세요

웹페이지가 표시되기까지 오래 걸리는 현상, 파일 다운로드가 계속 느린 현상, 동영상이 간헐적으로 멈추는 현상은 서로 다릅니다. 첫 번째는 DNS, 연결 수립, 핸드셰이크와 관련될 수 있고, 두 번째는 경로 대역폭, 패킷 손실, 대상 서비스 부하에 더 영향을 받습니다. 발생 시간, 사용 네트워크, 노드, 대상 유형을 기록하세요. 짧은 연결에서 한 번 측정한 지연 시간으로 다운로드 속도를 추정하거나 브라우저의 모든 대기 시간을 프록시 경로 탓으로 돌리지 마세요.

신뢰할 수 있는 같은 대상을 선택하고 비슷한 시간대에 직접 연결과 프록시 경로를 각각 테스트하세요. 실제 사용 환경을 대표하는 대상을 선택하고, 캐시에 저장된 정적 페이지와 대용량 파일 다운로드를 직접 비교하지 마세요. 백그라운드 동기화, 시스템 업데이트, 다른 기기의 대용량 전송을 일시 중지한 뒤 결과를 확인하세요. 무선 신호가 불안정하거나 로컬 업로드 대역폭이 가득 차 있으면 노드 자체가 정상이어도 요청이 밀리고 응답이 느려질 수 있습니다.

반복 가능한 노드 비교 테스트를 진행하세요

네트워크와 대상은 그대로 두고 노드만 바꾼 다음, 노드를 고정하고 네트워크를 바꿔 보세요. 이렇게 하면 노드 경로와 로컬 접속 문제를 구분할 수 있습니다. 실제 연결 속도 측정은 전체 요청 과정에 더 가까운 결과를 제공하지만 측정 대상, 서비스 부하, 테스트 시점의 영향을 받습니다. 모든 노드를 연속으로 높은 동시성으로 테스트하면 대역폭을 소모하고 서버 제한을 유발해 결과의 비교 가능성이 떨어질 수 있습니다.

노드에 표시된 지역 이름이 실제 종단 간 경로를 뜻하지는 않습니다. 가까운 지역이라고 혼잡이 적은 것은 아니며, 지연 시간이 짧다고 전송량이 많은 것도 아닙니다. 특정 서비스만 느리다면 출구에서 해당 서비스까지의 경로, 콘텐츠 전송 선택, 대상 서비스의 속도 제한이 원인일 수 있습니다. 이때는 로컬 수신 포트를 계속 바꾸기보다 다른 출구와 비교하는 편이 유용하지만, 해당 서비스 자체의 장애 여부도 확인해야 합니다.

중복 트래픽 가로채기와 잘못된 라우팅을 확인하세요

시스템 프록시, TUN, 브라우저 프록시 확장 프로그램, 다른 네트워크 도구가 동시에 작동하는지 확인하세요. 여러 계층이 겹치면 연결이 우회하거나 클라이언트의 아웃바운드 트래픽이 다시 인바운드로 전달될 수 있습니다. 테스트할 때는 경로 하나만 남겨 두세요. 특정 계층을 끈 뒤 문제가 해결되면 출처가 불분명한 성능 옵션에 의존하지 말고 해당 계층의 제외 규칙과 라우팅을 확인하세요.

라우팅 오류도 일부 콘텐츠만 느린 것처럼 보이게 할 수 있습니다. 예를 들어 기본 페이지는 직접 연결하고 리소스 도메인은 프록시를 사용하면 연결 수립이 추가로 발생할 수 있습니다. 프록시를 사용해야 하는 대상이 부적절한 직접 연결 경로로 전달되면 시간 초과를 반복해서 기다릴 수도 있습니다. 로그에서 실제 아웃바운드를 확인하고 해당 규칙을 조정하세요. 규칙은 보통 순서대로 적용되므로 앞쪽의 넓은 규칙이 뒤쪽의 세부 규칙을 덮어쓸 수 있습니다. 자세한 내용은 라우팅 설정 실전 가이드를 참고하세요.

프로토콜과 기기 리소스의 한계

전송 다중화, 동시 연결, 기타 고급 옵션은 모든 환경에서 통하는 속도 향상 기능이 아닙니다. 네트워크, 대상, 서버 설정에 따라 오히려 성능이 나빠질 수 있으며, 호환되지 않는 매개변수는 연결 재설정을 일으킬 수 있습니다. 먼저 서비스 제공자가 안내한 기본 매개변수로 복구하고 안정성을 확인한 다음 옵션을 하나씩 테스트하세요. 측정 시간을 줄이려고 인증이나 보안 계층을 끄지 마세요. 전송량 문제와는 다른 종류의 설정입니다.

기기 리소스도 함께 확인하세요. 저전력 모드, 지속적인 과열, 높은 CPU 사용량, 부족한 디스크 공간, 상세 로그의 지속적인 기록은 클라이언트 응답에 영향을 줄 수 있습니다. 인터페이스는 느리지만 다운로드 속도가 정상이라면 원격 대역폭보다는 관리 화면이나 기기 리소스 문제일 가능성이 큽니다. 불필요한 실시간 새로고침과 장시간 디버그 로그를 끄고 같은 작업을 다시 비교하세요.

TUN에서만 대용량 파일이 멈추고 작은 요청은 정상이라면 DNS와 라우팅을 먼저 확인한 뒤 경로 MTU나 캡슐화 문제를 고려할 수 있습니다. 클라이언트에 해당 설정이 있고 복구 방법을 이해하는 경우에만 범위를 좁혀 테스트하세요. 네트워크 매개변수를 임의로 복사하지 마세요. 실제 작업이 끝까지 완료되고 연결이 반복해서 재설정되지 않는 것을 복구 기준으로 삼으세요. 테스트 조건을 기록해 특정 시점의 우연한 최고 속도를 장기적인 성능으로 오해하지 않도록 하세요.

DNS 문제: 리졸버와 요청 경로 확인

노드 도메인과 대상 도메인을 구분하세요

DNS에는 최소 두 가지 대상이 있습니다. 클라이언트는 먼저 노드 서버를 찾아야 하고, 프록시 요청에서는 대상 웹사이트의 도메인도 조회해야 할 수 있습니다. 노드 도메인을 조회할 수 없으면 원격 프로토콜 연결 전에 실패합니다. 대상 도메인 조회에 문제가 있으면 노드는 연결됐지만 일부 사이트만 열리지 않을 수 있습니다. 로그에서 어떤 도메인 조회가 실패했는지 먼저 확인하고, 조회 오류가 보인다고 모든 DNS 설정을 바로 바꾸지 마세요.

누가 도메인을 조회하는지도 확인해야 합니다. 앱은 시스템 리졸버를 사용할 수도 있고 자체 암호화 DNS를 사용할 수도 있습니다. 프록시 코어도 별도의 DNS 설정을 가질 수 있습니다. SOCKS 요청은 앱이 먼저 도메인을 조회하거나 도메인 이름을 프록시 서버에 전달하는 방식으로 처리될 수 있습니다. 따라서 시스템 명령으로 조회에 성공해도 해당 조회 경로만 정상임을 뜻할 뿐, 브라우저나 코어의 DNS 경로까지 문제가 없다는 증거는 아닙니다.

시스템 조회 결과 확인

Windows, macOS, Linux 터미널에서 아래 명령을 사용하면 시스템 기본 리졸버가 예시 도메인에 응답하는지 확인할 수 있습니다. 해당 도구가 없다면 운영체제에서 제공하는 네트워크 진단 화면을 사용하면 됩니다. 익숙하지 않은 도구를 추가로 설치할 필요는 없습니다. 명령이 성공해도 결과가 IPv4인지 IPv6인지, 명확한 도메인 없음 응답인지, 조회 시간 초과가 발생했는지 확인하세요.

nslookup example.com

실제 문제를 진단할 때는 로그에 나온 대상 도메인을 조회하세요. 예시 도메인은 명령 형식을 보여 주기 위한 것입니다. 프록시 클라이언트 로그와 결과를 비교하세요. 시스템 조회는 성공했는데 코어 조회가 실패한다면 코어 DNS 주소와 아웃바운드 경로를 먼저 확인하세요. 시스템 조회 자체가 시간 초과된다면 로컬 네트워크, 라우터, 선택한 DNS 서비스를 점검하세요. 인증서 오류를 DNS 조회 실패로 오해하지 마세요. 두 오류는 발생 단계가 다릅니다.

DNS 조회 루프와 주소 체계 문제 확인

특정 DNS 서비스에 연결하려면 프록시가 필요한데, 노드 도메인 조회도 그 DNS에 의존한다면 시작 단계에서 순환 문제가 생길 수 있습니다. 노드 도메인에 연결 가능한 초기 조회 경로를 마련하고 DNS 서비스 요청이 잘못된 라우팅으로 클라이언트에 되돌아오지 않는지 확인하세요. 암호화 DNS를 설정할 때는 서비스 도메인 조회와 이후 요청을 구분해야 합니다. 주소 하나를 입력했다고 모든 의존성이 해결된 것은 아닙니다.

아래 예시는 V2Ray 내장 DNS의 기본 구조와 IPv4만 조회하는 진단 방법을 보여 주며, 전체 프록시 설정이 아닙니다. 나열된 DNS 서비스에 현재 네트워크로 접속할 수 있어야 합니다. 코어별 필드 지원과 DNS 라우팅 방식은 따로 확인하세요. 그래픽 클라이언트를 사용한다면 설정 화면에서 변경하는 것이 좋습니다. 클라이언트가 실행 파일을 다시 생성할 수 있으므로 해당 파일을 직접 수정하지 마세요.

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

IPv6 경로에 뚜렷한 문제가 있을 때만 주소 체계를 임시로 제한해 비교하세요. 제한 후 복구되면 IPv6 연결 가능 여부, 라우팅, 클라이언트 설정을 추가로 점검하고 IPv6 비활성화를 모든 기기의 고정 해법으로 삼지 마세요. 도메인이 여러 주소를 반환할 때 앱마다 선택하는 주소가 달라 같은 기기에서도 결과가 다를 수 있습니다.

캐시와 브라우저별 설정 확인

DNS를 변경한 뒤에도 이전 캐시 때문에 테스트가 기존 주소로 계속 접속할 수 있습니다. 테스트 앱을 닫았다 다시 열고 운영체제에서 제공하는 방법으로 DNS 캐시를 비운 다음 요청을 다시 보내세요. 브라우저의 보안 DNS, 앱 내부 캐시, 시스템 캐시가 항상 함께 지워지는 것은 아닙니다. 어느 계층의 캐시를 비웠는지 기록해 같은 페이지를 반복해서 새로고침하면서 새 조회 결과를 사용한다고 착각하지 않도록 하세요.

마지막으로 대상 도메인, 조회 방식, 반환된 주소 체계, 실제 아웃바운드를 서로 비교하세요. 도메인 하나만 실패하면 hosts 파일의 재정의나 전용 라우팅 규칙이 있는지 확인하세요. 모든 도메인이 실패하지만 이미 연결된 세션은 데이터를 주고받을 수 있다면 DNS 계층 문제일 가능성이 큽니다. 복구 후 필요한 브라우저 설정을 다시 켜고 노드 시작과 첫 접속이 각각 완료되는지 확인하세요. 캐시가 남아 있을 때만 작동하는 설정이 되지 않도록 해야 합니다.

시스템 프록시 작동 안 함: 앱과 로컬 인바운드 확인

시스템 프록시가 적용되는 범위를 확인하세요

시스템 프록시는 해당 설정을 지원하는 앱에 프록시 주소를 제공하는 기능이며, 기기의 모든 네트워크 연결을 자동으로 우회시키지는 않습니다. 브라우저는 작동하지만 특정 앱이 직접 연결한다면 해당 앱이 시스템 프록시를 사용하지 않을 수 있습니다. 명령줄 도구, 백그라운드 서비스, 일부 게임, 자체 네트워크 구성요소가 있는 프로그램은 별도의 프록시 설정을 사용할 수 있습니다. 사용할 시스템 프록시, 앱 내 프록시, TUN을 선택하기 전에 앱이 어떤 방식을 지원하는지 확인하세요.

v2rayN의 시스템 프록시 상태와 라우팅 모드도 서로 다른 개념입니다. 시스템 프록시는 앱을 로컬 포트로 안내하고, 라우팅 모드는 코어로 들어온 요청을 어떤 아웃바운드로 보낼지 정합니다. 분할 라우팅 모드를 선택해도 모든 앱에 프록시가 자동 설정되지는 않습니다. 시스템 프록시를 켜도 라우팅에서 프록시 아웃바운드를 선택한다는 보장은 없습니다. 트레이 메뉴의 문구 하나만 보지 말고 두 계층의 상태를 각각 확인하세요.

수신 주소, 포트, 프로토콜 확인

먼저 클라이언트 설정과 시작 로그에서 실제로 수신 대기 중인 주소와 포트를 확인하세요. 이 기기에서만 사용할 경우 일반적으로 루프백 주소가 적합합니다. 앱의 HTTP 프록시 포트는 HTTP를 지원하는 인바운드와 일치해야 하고, SOCKS 포트에는 해당 프로토콜 지원이 필요합니다. 혼합 포트의 사용 가능 여부는 클라이언트와 코어 설정에 따라 다르므로 다른 가이드의 포트 번호만 보고 판단하지 마세요.

아래 예시는 서로 독립된 인바운드 두 개를 설명하기 위한 것입니다. 노드 설정이 아니며 원격 아웃바운드도 포함하지 않습니다. 포트는 예시일 뿐이므로 실제 로컬 설정을 따라야 합니다. 이 설정을 사용하는 앱은 프로토콜에 맞는 포트를 선택해야 합니다. 클라이언트가 이미 수신 설정을 생성했다면 이 내용을 그대로 추가하지 마세요. 포트 중복 바인딩으로 코어 전체가 시작되지 않을 수 있습니다.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

플랫폼 설정이 덮어쓰이지 않았는지 확인하세요

Windows에서는 현재 사용자 계정의 프록시 설정을 열어 수동 프록시와 자동 구성 스크립트를 구분하세요. 앱마다 사용하는 네트워크 스택이 다를 수 있으므로 브라우저가 작동한다고 백그라운드 서비스도 같은 프록시를 사용한다고 단정하지 마세요. 클라이언트를 종료한 뒤에도 시스템이 더는 프로그램이 수신하지 않는 로컬 포트를 가리키면 직접 연결은 정상인데 앱에서 연결 오류가 발생하는 설정이 남을 수 있습니다.

macOS 프록시 설정은 현재 네트워크 서비스에 연결되어 있습니다. 무선 네트워크나 유선 연결을 바꾸거나 새 네트워크 서비스를 추가했다면 예전에 수정한 항목만 보지 말고 현재 사용하는 서비스의 설정을 확인하세요. Linux 데스크톱의 프록시 설정도 터미널과 시스템 서비스를 모두 제어하지 않을 수 있습니다. 앱이 환경 변수를 읽는 경우 기존 프로세스에 시작 당시 값이 남아 있는지도 확인하세요. 설정을 바꾼 뒤 테스트 앱을 다시 시작하는 편이 확실합니다.

프록시 확장 프로그램과 우회 규칙 확인

브라우저 프록시 확장 프로그램, 자동 구성 스크립트, 앱 내 프록시, 시스템 설정이 서로 덮어쓸 수 있습니다. 추가 프록시 설정을 잠시 끄고 진입 경로 하나만 남긴 뒤 접속 시 코어 로그가 생성되는지 확인하세요. 로그가 없다면 앱 우회 목록에서 대상이 직접 연결로 지정됐는지 살펴보세요. 로그는 있지만 잘못된 아웃바운드를 사용한다면 시스템 프록시를 계속 켰다 끄지 말고 라우팅 규칙을 확인하세요.

TUN은 더 다양한 유형의 트래픽을 처리할 수 있지만 시스템 권한, 가상 네트워크 인터페이스, 올바른 라우팅이 필요합니다. 시스템 프록시가 작동하지 않는 이유를 모르는 상태에서 무작정 대체 수단으로 사용하지 마세요. 먼저 일반 인바운드 경로를 확인한 뒤 TUN을 별도로 활성화하세요. 대상 앱의 요청 로그가 생성되고 올바른 아웃바운드 규칙이 적용되며, 클라이언트를 종료한 뒤 시스템 네트워크 설정이 예상대로 복구되는 것이 정상 상태입니다. 다른 모드에 관한 질문은 사용 안내의 연결 절차를 참고하세요.

클라이언트 충돌: 인터페이스·코어·설정 구분

어떤 프로세스가 종료됐는지 먼저 확인하세요

창이 사라짐, 인터페이스 응답 없음, 코어 종료는 서로 다른 문제입니다. 창을 닫아도 트레이 아이콘이 남아 있다면 트레이로 최소화된 것일 수 있습니다. 관리 화면은 정상인데 연결이 모두 끊겼다면 코어 시작에 실패했을 수 있습니다. 프로그램 전체가 갑자기 종료된다면 시스템 오류 기록과 클라이언트 로그를 확인하세요. 시작, 노드 전환, 구독 업데이트, 절전 모드 복귀 등 발생 직전의 동작을 기록하면 원인을 좁힐 수 있습니다.

처음부터 설정 디렉터리를 삭제하지 마세요. 먼저 프로그램을 종료하고 관련 프로세스가 끝났는지 확인한 다음 설정, 구독 그룹, 필요한 사용자 설정을 백업하세요. 로그는 보관하되 공유 전에 민감 정보를 지우세요. 인터페이스를 열 수 없어도 운영체제의 파일 관리 및 진단 도구로 최근 수정된 파일과 앱 오류 기록을 확인할 수 있습니다. 출처가 불분명한 복구 스크립트를 내려받지 마세요.

운영체제, 아키텍처, 설치 방식 확인

재설치하기 전에 설치 패키지가 운영체제와 칩셋 유형에 맞는지 확인하세요. 데스크톱용 v2rayN의 데스크톱 버전과 클래식 WPF 버전은 인터페이스 구현이 다르므로 시스템 요구사항은 실제 설치 패키지 안내를 기준으로 확인해야 합니다. 런타임 환경 누락, 오래된 운영체제, 아키텍처 불일치 때문에 기본 창이 뜨기 전에 프로그램이 종료될 수 있습니다. 설치 파일과 플랫폼 선택은 클라이언트 설치 패키지에서 확인하고 파일 이름 일부만 보고 호환성을 추측하지 마세요.

설치 디렉터리에 쓰기 권한이 있는지, 사용자 디렉터리의 여유 공간이 충분한지, 프로그램이 제한된 네트워크 위치나 임시 디렉터리에 놓이지 않았는지 확인하세요. 설정을 저장해야 하는 프로그램은 파일을 생성할 수 없으면 설정이 사라지거나 업데이트 실패, 반복 종료가 발생할 수 있습니다. 설치 방식에 맞는 로컬 위치에 프로그램을 둔 뒤 테스트하세요. 디렉터리 권한 문제를 가리기 위해 항상 최고 권한으로 실행하지 마세요.

첫 번째 시작 오류를 확인하세요

코어 로그에는 포트 사용 중, 설정 파싱 오류, 리소스 파일을 읽을 수 없음, 지원되지 않는 필드 등이 명확히 표시되는 경우가 많습니다. 먼저 유효한 오류 중 가장 먼저 발생한 항목을 해결하세요. 이후 연결 실패는 그로 인한 연쇄 오류일 수 있습니다. 클라이언트가 두 개 실행 중이거나 이전 프로세스가 수신 포트를 계속 사용하고 있는지도 확인하세요. 중복 프로세스를 종료한 뒤 다시 시작하는 편이 네트워크 매개변수 전체를 임의로 바꾸는 것보다 원인을 확인하기 쉽습니다.

설정을 직접 수정한 뒤 문제가 생겼다면 가장 최근 변경부터 되돌리세요. JSON의 쉼표, 따옴표, 배열, 객체 괄호는 모두 문법에 맞아야 합니다. 문법이 올바르더라도 현재 코어가 해당 필드를 지원한다는 뜻은 아닙니다. 그래픽 클라이언트는 실행 파일을 다시 생성하는 경우가 많으므로 생성된 파일을 직접 수정하면 다음 시작 때 덮어쓸 수 있습니다. 장기적으로 사용할 설정은 클라이언트가 공식적으로 지원하는 입력 경로를 이용하세요.

별도 설정으로 문제를 재현하세요

백업이 있고 클라이언트 데이터 위치를 알고 있는 경우에만 별도의 테스트 데이터 디렉터리를 사용하거나 기존 데이터 디렉터리 이름을 바꿔 초기 설정으로 실행해 보세요. 테스트 인스턴스와 기존 인스턴스를 동시에 실행하지 마세요. 초기 상태에서 정상 작동한다면 구독 하나, 노드 하나, 필요한 설정을 순서대로 복원하세요. 특정 항목을 복원한 뒤 문제가 재현되면 해당 데이터나 기능으로 범위를 좁힐 수 있습니다.

빈 설정에서도 충돌한다면 운영체제 호환성, 런타임 환경, 설치 파일, 보안 소프트웨어의 차단 기록을 확인하세요. 차단 기록이 있으면 먼저 이벤트 내용을 읽고 출처를 확인하세요. 보안 기능 전체를 바로 끄지 마세요. TUN을 켰을 때만 실패한다면 권한과 가상 인터페이스를 확인하세요. 일반 프록시가 실행된다면 노드 데이터를 모두 지우고 다시 만들 필요는 없습니다.

절전 모드 이후 멈추거나 오래 실행한 뒤 종료되는 문제라면 메모리, 핸들, 디스크, 네트워크 전환도 관찰하세요. 자동 속도 측정, 잦은 새로고침, 예약 업데이트 등의 범위를 줄여 특정 작업이 원인인지 확인하세요. 복구 후에는 시작, 가져오기, 연결, 정상 종료를 모두 테스트한 다음 자동 작업을 다시 켜세요. 문제를 보고할 때 클라이언트 이름, 시스템 아키텍처, 재현 단계, 민감 정보를 지운 오류 내용을 제공하세요. ‘안 열림’이라고만 적거나 설정 데이터베이스 전체를 업로드하지 마세요.

Android 문제: VPN 권한·백그라운드 실행·앱별 라우팅

로컬 VPN 처리와 원격 연결을 구분하세요

v2rayNG와 v2flyNG는 Android VPN 서비스 인터페이스를 통해 앱 트래픽을 받을 수 있습니다. 시스템에 VPN 표시가 나타나는 것은 로컬 트래픽 처리 서비스가 작동 중임을 뜻할 뿐, 원격 노드와 핸드셰이크가 완료됐다는 의미는 아닙니다. 클라이언트 로그와 실제 접속 결과를 확인해 문제 단계를 판단하세요. 처음 실행할 때 시스템 권한을 승인해야 하며, 권한이 거부되거나 다른 서비스로 대체되면 클라이언트가 예상대로 트래픽을 처리하지 못합니다.

일반적으로 한 사용자 환경에서 활성 VPN 서비스는 하나만 사용할 수 있습니다. 다른 VPN이나 보안 네트워크 도구, 같은 인터페이스를 사용하는 앱이 현재 연결을 차지할 수 있습니다. 먼저 다른 트래픽 처리 서비스를 중지하고 테스트할 클라이언트를 다시 시작하세요. 시스템의 상시 연결 VPN이나 VPN을 사용하지 않는 연결 차단 기능 때문에 클라이언트가 실행되지 않을 때 전체 기기에서 인터넷이 안 될 수도 있습니다. 변경 전 상태를 기록하고 테스트가 끝나면 필요에 따라 원래대로 되돌리세요.

설치 패키지와 코어 선택

설치할 때 기기 아키텍처에 맞춰 arm64 또는 범용 패키지를 선택하세요. 최신 주요 스마트폰은 대체로 arm64를 사용하지만 출시 연도만으로 판단해서는 안 됩니다. 확실하지 않으면 시스템이나 기기 정보를 확인하거나 범용 패키지를 사용하세요. 저장 공간 부족, 앱 설치 출처 권한, 기존 앱과 서명 차이도 설치 실패의 원인일 수 있으므로 모든 설치 오류를 네트워크 문제로 보지 마세요.

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하세요. V2Fly 설정과의 호환성이 필요하다면 v2flyNG를 선택할 수 있습니다. 두 앱은 인터페이스만 다른 동일 앱이 아니므로 프로토콜 기능과 필드 지원은 코어에 따라 확인해야 합니다. REALITY 등의 기능을 사용하는 노드는 해당 코어가 이를 지원하는지 먼저 확인하세요. 설치 파일은 Android 클라이언트 다운로드에서 확인하세요. 전환하기 전에 필요한 설정을 백업하고 앱 데이터를 서로 그대로 옮길 수 있다고 가정하지 마세요.

화면 잠금 후 연결 끊김과 백그라운드 종료 해결

화면이 켜져 있을 때는 정상인데 잠금 후 시간이 지나면 연결이 끊긴다면 배터리 최적화, 백그라운드 실행, 백그라운드 데이터 제한을 먼저 확인하세요. 기기마다 설정 이름이 다르므로 시스템 앱 관리에서 해당 클라이언트를 찾아 필요한 백그라운드 활동을 허용하고 과도한 절전을 제외하세요. 모든 앱의 절전 제한을 한꺼번에 끄지 말고 계속 연결이 필요한 클라이언트에만 필요한 범위로 적용하세요.

프로세스 종료와 유휴 네트워크 연결 끊김도 구분해야 합니다. 프로세스가 종료되면 클라이언트 알림이나 VPN 표시가 사라지는 경우가 많습니다. 유휴 연결 문제라면 연결 표시가 남아 있어도 첫 요청 때 다시 연결해야 할 수 있습니다. 복구 전후 로그를 살펴보고 백그라운드 정책과 노드 연결 중 어느 쪽을 조정할지 판단하세요. 화면이 켜진 직후 복구되더라도 시스템이 네트워크 사용을 다시 허용한 것일 수 있으므로 서버가 먼저 연결을 끊었다고 단정하지 마세요.

앱별 프록시와 네트워크 전환 확인

일부 앱에서만 접속할 수 없다면 앱별 프록시의 포함 또는 제외 모드를 확인하세요. 두 모드의 의미는 반대입니다. 목록에서 앱을 선택하면 해당 앱만 프록시를 사용할 수도 있고, 반대로 프록시에서 제외될 수도 있습니다. 앱을 새로 설치하거나 재설치한 뒤에는 목록과 실제 앱 식별 정보가 갱신되어야 할 수 있습니다. 확실한 테스트 앱 하나를 선택해 요청이 로그에 나타나는지 확인한 후 전체 목록을 복구하세요.

무선 네트워크에서 모바일 데이터로 전환하면 주소가 바뀌어 기존 연결이 끊길 수 있습니다. 연결을 중지한 뒤 다시 시작해 복구되는지 확인하세요. 전환할 때마다 실패한다면 클라이언트의 네트워크 변경 처리와 시스템 백그라운드 제한을 확인하세요. 데이터 절약 모드, 모바일 데이터 권한, 현재 접속 지점도 점검하세요. 특정 무선 네트워크에서만 문제가 발생한다면 노드나 DNS 문제로 판단하기 전에 웹 인증을 완료했는지 확인하세요.

휴대폰의 VPN이 테더링에 연결된 다른 기기의 트래픽까지 처리한다고 보장할 수 없습니다. 휴대폰 브라우저가 정상이라고 해서 테더링 기기도 같은 경로를 사용하는 것은 아닙니다. 테더링 문제를 해결하려고 로컬 수신 포트를 임의로 개방하거나 접속 범위를 넓히지 마세요. 복구 후 화면이 켜진 상태의 접속, 잠금 후 접속, 무선 네트워크와 모바일 데이터 간 전환, 연결 중지 후 직접 접속을 차례로 확인하세요. 문제가 계속되면 증상에 맞춰 이 페이지의 노드, DNS, 구독 섹션을 참고하세요. 기본 절차부터 다시 확인해야 한다면 사용 안내로 돌아가 가져오기와 연결 확인 단계를 점검하세요.