V2Ray 연결 안 됨
문제 해결 총정리

재현 가능한 점검 순서부터 세우기

문제가 발생한 계층부터 확인하기

V2Ray 클라이언트의 연결은 기본 네트워크, 클라이언트 화면, 프록시 코어, 원격 노드, 시스템 프록시 또는 가상 네트워크 어댑터, DNS 조회, 대상 앱이라는 최소 7단계를 거칩니다. 페이지가 열리지 않는 것은 최종 증상일 뿐 노드가 중단됐다는 뜻은 아닙니다. 기본 네트워크 단절, 코어 미실행, 이전 포트를 가리키는 시스템 프록시, 불일치하는 노드 설정, 도메인 조회 오류도 비슷한 결과를 만들 수 있습니다. 효과적인 점검은 모든 스위치를 반복해서 바꾸는 것이 아니라 먼저 장애 범위를 정하는 것입니다. 클라이언트의 트래픽 인계를 끈 뒤 일반 네트워크에 접속되는지, 클라이언트 로그에 코어 실행 성공이 표시되는지, 로컬 수신 포트가 존재하는지, 노드 연결이 TCP 연결 단계에서 실패하는지 TLS 또는 프로토콜 핸드셰이크 단계에서 실패하는지, 브라우저만 영향을 받는지 모든 앱이 영향을 받는지를 확인하세요.

먼저 현장 정보 네 가지를 적어 두는 것이 좋습니다. 사용 중인 플랫폼과 클라이언트, 장애가 시작되기 전에 변경한 내용, 영향을 받는 앱 범위, 로그에서 처음 나타난 오류입니다. 마지막 수십 줄을 복사하는 것보다 ‘첫 번째 오류’를 기록하는 편이 유용합니다. 이후의 연결 종료와 재시도 실패는 연쇄적으로 발생한 결과인 경우가 많기 때문입니다. 구독 업데이트 후 문제가 생겼다면 이전 구성 그룹도 보존하세요. 이전 구성은 작동하지만 새 구성은 작동하지 않으면 점검 범위를 구독 내용이나 새 매개변수로 좁힐 수 있습니다. 새 구성과 이전 구성 모두 작동하지 않는다면 네트워크, 시스템 프록시 및 클라이언트 실행 상태를 우선 확인하세요.

변수를 최소화해 재현하기

각 테스트에서는 조건 하나만 바꾸고 변경 후 완전히 다시 연결하세요. 예를 들어 노드를 테스트할 때는 같은 네트워크, 클라이언트, 라우팅 모드를 고정하고 노드 하나만 바꿉니다. 시스템 프록시를 테스트할 때는 연결 가능한 노드 하나를 고정한 뒤 ‘시스템 프록시 끄기’, ‘시스템 프록시 자동 설정’, ‘TUN 모드’를 각각 비교하세요. 노드 변경, 구독 업데이트, 코어 전환, DNS 수정을 한 번에 진행하면 연결이 복구되어도 실제 원인을 알 수 없어 이후 같은 문제가 반복됩니다.

최소 테스트 환경은 최대한 단순하게 구성하세요. 중복 실행 중인 프록시 도구를 종료하고, 네트워크 스택을 변경하는 디버깅 소프트웨어를 닫고, 브라우저의 독립 프록시 설정을 잠시 끈 뒤 클라이언트 기본 라우팅을 사용합니다. 데스크톱에서는 먼저 v2rayN으로 기준 테스트를 진행하세요. Android에서는 구독에 필요한 코어에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다. 설치 출처나 아키텍처가 확실하지 않다면 먼저 다운로드 페이지에서 플랫폼과 설치 유형을 확인하세요. 코어가 실행되지 않는 상태에서 라우팅 규칙을 계속 살펴보지 마세요. 모든 상위 단계의 테스트가 의미를 잃습니다.

로그를 읽을 때 단계별 키워드 파악하기

로그는 ‘error’만 검색하지 말고 단계별로 해석해야 합니다. 수신 주소와 포트가 표시되면 코어가 구성을 읽고 로컬 연결을 받기 시작했다는 뜻입니다. 연결 거부는 대개 대상 포트에 서비스가 없거나 중간 장비가 적극적으로 거부했다는 의미입니다. 시간 초과는 정해진 시간 안에 연결이 완료되지 않았다는 뜻입니다. 인증서 도메인 불일치, 핸드셰이크 실패 또는 서버 이름 관련 메시지가 나타나면 시스템 시간, SNI, TLS 및 전송 설정을 확인하세요. DNS 조회 실패가 나타나면 먼저 이름 해석 경로를 처리합니다. 로그에는 서버 주소와 구독 정보가 포함될 수 있으므로 다른 사람에게 전달하기 전에 계정 식별자, 인증 필드 및 전체 구독 주소를 삭제하세요.

클라이언트를 켜면 인터넷에 전혀 연결되지 않음

기본 네트워크 문제와 프록시 인계 문제를 먼저 구분하기

첫 단계는 v2rayN의 시스템 프록시를 끄거나 Android 클라이언트 연결을 종료하는 것입니다. 단, 구성을 바로 삭제하지는 마세요. 그런 다음 브라우저로 평소 정상적으로 열리는 사이트에 접속하고 로컬 네트워크 게이트웨이도 테스트합니다. 프록시를 꺼도 접속되지 않는다면 문제는 기본 네트워크, 무선 연결, 게이트웨이 또는 시스템 DNS에 있으므로 노드를 계속 바꿔도 의미가 없습니다. 프록시를 끄자마자 정상으로 돌아온다면 클라이언트가 트래픽을 인계했지만 로컬 프록시가 올바르게 전달하지 못한 것입니다. 코어 미실행, 시스템 프록시 포트와 실제 수신 포트 불일치, 사용할 수 없는 구성, 모든 요청을 잘못된 출구로 보내는 라우팅 등이 흔한 원인입니다.

데스크톱에서는 장애가 영향을 미치는 범위도 확인해야 합니다. 브라우저와 시스템 구성 요소가 모두 실패하면 시스템 프록시를 우선 점검하세요. 특정 앱만 실패한다면 해당 앱이 시스템 프록시를 무시하는지, 별도 프록시 주소를 저장했는지 확인합니다. 로컬 네트워크 주소에도 접근할 수 없다면 라우팅 모드가 사설 주소까지 잘못 프록시 처리하는지 확인하세요. TUN 모드에서 모든 앱의 네트워크가 동시에 끊기면 가상 네트워크 어댑터, 라우팅 테이블, DNS 인계 및 실행 권한을 중점적으로 살펴봅니다. ‘시스템 프록시’와 ‘TUN’을 같은 기능으로 보면 안 됩니다. 전자는 주로 시스템 프록시 설정을 따르는 앱에 진입점을 제공하고, 후자는 가상 네트워크 어댑터로 더 넓은 네트워크 트래픽을 인계하므로 장애 지점이 서로 다릅니다.

로컬 코어와 수신 포트 확인

v2rayN 화면에서 서버가 선택되어 있다고 해서 프록시 코어가 정상 실행 중이라는 뜻은 아닙니다. 구성을 전환한 뒤 로그의 시작 부분에서 코어 구성 로딩이 완료되었는지, 로컬 SOCKS 또는 HTTP 수신 정보가 표시되는지 확인하세요. 주소가 이미 사용 중이라는 로그가 나오면 다른 클라이언트 프로세스, 이전 비정상 종료로 남은 백그라운드 프로세스 또는 다른 소프트웨어가 같은 포트를 사용 중일 수 있습니다. 먼저 중복 클라이언트를 종료한 다음 시스템 도구로 포트 사용 현황을 확인하세요. Windows에서는 터미널에서 다음 명령을 실행할 수 있습니다. 예시 포트는 클라이언트 설정에 표시된 로컬 포트로 바꾸세요.

netstat -ano | findstr LISTENING
netstat -ano | findstr :10808
tasklist /fi "PID eq 프로세스 번호"

macOS와 Linux에서는 lsof -iTCP -sTCP:LISTEN 또는 ss -lntp로 수신 상태를 확인할 수 있습니다. 포트가 나타나지 않으면 클라이언트 로그로 돌아가 코어 실행 오류를 처리하세요. 포트가 존재한다면 시스템 프록시가 같은 포트를 가리키는지 테스트합니다. 포트를 변경한 뒤에는 반드시 시스템 프록지를 다시 적용해야 합니다. 클라이언트 수신 값만 바꾸고 시스템 설정을 새로 고치지 않으면 앱이 계속 이전 포트에 연결해 연결 거부가 발생합니다.

라우팅 모드와 남은 잘못된 설정 확인

점검 단계에서는 클라이언트가 제공하는 기본 라우팅 모드를 먼저 선택하고 복잡한 사용자 지정 규칙으로 시작하지 마세요. ‘로컬 네트워크 및 중국 본토 주소 우회’ 모드는 작동하지만 사용자 지정 모드에서 인터넷이 완전히 끊긴다면 규칙 순서, 기본 아웃바운드 및 도메인 매칭을 확인합니다. 라우팅은 보통 순서대로 매칭되므로 지나치게 넓은 차단 규칙이 앞에 있으면 이후 프록시 규칙이 실행되지 않습니다. 일부 규칙만 정의하고 적절한 기본 출구를 지정하지 않으면 매칭되지 않은 트래픽의 방향이 불분명해집니다. 연결을 복구한 뒤 규칙을 한 줄씩 다시 추가하고, 매번 도메인, 순수 IP, 로컬 네트워크 주소를 테스트하세요.

Windows에서는 클라이언트가 비정상 종료된 뒤 시스템 프록시가 남을 수 있습니다. 이때 브라우저는 이미 중지된 로컬 포트에 계속 연결하려 하므로 소프트웨어를 종료하면 모든 사이트가 열리지 않을 수 있습니다. v2rayN을 다시 시작해 시스템 프록시를 끄거나 시스템 네트워크 설정에서 수동 프록시를 끄세요. macOS에서는 현재 네트워크 서비스의 웹 프록시와 보안 웹 프록시가 여전히 활성화되어 있는지 확인해야 합니다. Linux 데스크톱 환경에서는 HTTP, HTTPS, SOCKS 설정이 각각 저장되어 있을 수도 있습니다. 남은 설정을 정리할 때는 클라이언트가 설정한 것으로 확인된 항목만 삭제하고 전체 네트워크 구성을 함부로 초기화하지 마세요.

노드 시간 초과, 연결 거부 및 핸드셰이크 실패

세 가지 오류를 나눠 처리하기

‘시간 초과’, ‘연결 거부’, ‘핸드셰이크 실패’는 서로 다른 단계를 가리킵니다. 시간 초과는 클라이언트가 연결을 시작한 뒤 예상한 응답을 오랫동안 받지 못했다는 뜻으로, 주소 접근 불가, 포트 필터링, 패킷 손실 또는 서버 무응답이 원인일 수 있습니다. 연결 거부는 대개 대상 호스트에는 접근할 수 있지만 지정된 포트에 서비스가 없거나 중간 장비가 명확히 거부했다는 의미입니다. 핸드셰이크 실패는 기본 연결이 이미 성립했을 가능성이 있으며 TLS, 프로토콜 인증, 전송 계층 또는 서버 이름 검증에서 문제가 발생했다는 뜻입니다. 세 경우를 모두 ‘노드 불량’으로 보면 로컬 시간, SNI, 전송 경로 및 매개변수 복사 오류를 놓치게 됩니다.

노드 하나를 고정해 원시 네트워크 테스트부터 진행하세요. 도메인 기반 노드는 도메인 조회 가능 여부, 조회 결과의 안정성, TCP 연결 수립 가능 여부를 각각 확인합니다. Windows에서는 PowerShell의 Test-NetConnection, macOS와 Linux에서는 nc를 사용할 수 있습니다. 이 테스트는 네트워크와 포트만 확인하며 VMess, VLESS, Trojan 또는 TLS 매개변수는 검증하지 않습니다. 따라서 포트에 접근할 수 있다고 전체 프록시가 반드시 작동하는 것은 아니지만, 포트에 접근할 수 없다면 먼저 주소, 네트워크 및 서버 상태를 처리해야 합니다.

Test-NetConnection example.com -Port 443

nc -vz example.com 443

예시 도메인은 구성에 있는 서버 주소로 바꿔야 합니다. 도메인이 주소로 해석되지 않으면 DNS 장으로 이동하세요. 정상적으로 해석되지만 포트 시간 초과가 계속되면 다른 네트워크에서 비교합니다. 같은 노드가 네트워크에 따라 다르게 작동한다면 현재 네트워크 경로에 문제가 있을 가능성이 큽니다. 모든 네트워크에서 실패하면서 같은 구독의 다른 노드는 작동한다면 해당 노드 자체 또는 노드 매개변수를 의심해야 합니다.

프로토콜과 전송 매개변수를 하나씩 대조하기

수동으로 구성할 때 서버 주소, 포트, 사용자 식별자, 암호화 방식, 전송 유형, 경로, Host, TLS, SNI, 지문 등의 필드는 서버와 일치해야 합니다. 구독을 가져오면 자동으로 채워지지만 업데이트 실패, 형식 변환 또는 이전 구성 잔여물로 필드가 불완전해질 수 있습니다. 확인할 때 주소와 포트만 비교하지 마세요. WebSocket 경로의 슬래시 하나, 다른 gRPC 서비스 이름, TLS 스위치 불일치, 잘못된 도메인을 사용하는 SNI도 TCP 연결 직후 연결을 끊을 수 있습니다.

TLS 관련 오류가 발생하면 먼저 시스템 날짜, 시간, 시간대를 확인하세요. 인증서 유효 기간 판단은 로컬 시간에 의존하므로 시간 차이가 크면 아직 유효하지 않거나 이미 만료된 것으로 판단할 수 있습니다. 다음으로 SNI가 인증서에 포함된 도메인인지 확인하세요. 서버 IP를 임의로 입력하면 안 됩니다. 인증서 검증 건너뛰기를 일반적인 해결책으로 사용하지 마세요. 도메인, 인증서 또는 서버 설정 문제를 숨길 뿐입니다. 자세한 인증서 오류 유형은 TLS 인증서 오류 문제 해결 체크리스트에서 확인할 수 있습니다.

클라이언트 테스트와 실제 접속의 차이 이해하기

클라이언트의 연결 테스트, 지연 시간 테스트, 실제 웹페이지 접속은 서로 다른 요청 방식을 사용할 수 있습니다. 특정 테스트는 실패했지만 웹페이지가 작동한다면 테스트 결과만으로 노드를 삭제하지 마세요. 테스트는 성공했지만 웹페이지가 열리지 않는다면 시스템 프록시, DNS 및 라우팅 인계를 확인합니다. 점검할 때는 실제 앱 요청과 코어 로그를 기준으로 삼고 테스트 방식도 기록하세요. 한 번의 순간적인 결과를 비교하지 말고 같은 네트워크, 같은 라우팅, 비슷한 시간대에 반복 검증합니다.

한 구독 그룹의 모든 노드에서 동시에 핸드셰이크가 실패한다면 시스템 시간, 클라이언트 코어, 구독 내용의 구조 변경 여부, 현재 네트워크가 공통 도메인이나 포트에 영향을 주는지를 우선 확인하세요. 특정 노드 하나만 실패한다면 해당 구성 항목을 집중적으로 대조합니다. v2rayN에서 코어 유형을 전환한 뒤 오류가 시작됐다면 현재 코어가 구성에 사용된 프로토콜 기능을 지원하는지 확인하세요. Xray와 V2Fly는 공통된 계보를 갖지만 일부 프로토콜 확장 지원은 완전히 같지 않으므로 코어 이름만 바꾸면 모든 구성이 호환된다고 가정해서는 안 됩니다.

구독 업데이트 실패 또는 가져온 뒤 목록이 비어 있음

구독 요청이 실제로 전송됐는지 먼저 확인하기

구독 업데이트는 구독 주소 해석, 네트워크 요청, 서버 응답, 콘텐츠 디코딩, 구성 변환 등 여러 단계를 거칩니다. ‘업데이트 실패’가 표시되면 로그의 HTTP 상태, 시간 초과 정보 또는 형식 오류부터 확인하세요. 요청 시간 초과는 현재 네트워크에서 구독 주소에 접근하지 못했거나 업데이트 요청이 정상적인 프록시를 거치지 않았다는 뜻일 수 있습니다. 인증되지 않았거나 접근이 금지됐다는 응답은 링크 만료, 계정 상태 또는 접근 제한과 관련된 경우가 많습니다. 성공 응답인데 목록이 비어 있다면 응답 내용이 클라이언트가 지원하는 구독 형식인지 확인하세요.

구독 주소를 복사할 때 전체 쿼리 매개변수를 보존하세요. 메신저, 메모 앱 또는 브라우저 주소 표시줄에서 끝부분이 잘리거나 특수 문자가 일반 텍스트로 변환될 수 있습니다. 원본에서 다시 복사한 뒤 클라이언트의 기존 주소를 덮어쓰는 것이 좋습니다. 구독 주소는 계정 자격 증명의 일부이므로 공개 페이지나 스크린샷에 게시하지 마세요. 구독 그룹 이름은 로컬 식별에만 영향을 주며 원격 링크를 복구하지 않습니다. 그룹 이름이 같다고 두 링크의 내용이 같은 것도 아닙니다.

직접 연결 업데이트와 프록시를 통한 업데이트 구분하기

일부 환경에서는 이미 작동하는 프록시를 통해 구독 주소에 접근해야 합니다. 연결 가능한 구성이 하나도 없는데 업데이트가 프록시에 의존하면 ‘연결하려면 구독이 필요하고, 업데이트하려면 연결이 필요한’ 순환이 생깁니다. 작동이 확인된 이전 구성을 남겨 먼저 연결한 뒤 업데이트하거나 서비스 제공업체가 안내한 방식으로 초기 구성을 가져오세요. 업데이트에 실패했다고 서버 목록 전체를 바로 비우지 마세요. 이전 구성은 구독 요청을 복구할 수 있는 유일한 기준일 때가 많습니다.

v2rayN의 구독 업데이트 옵션에서 시스템 프록시 또는 현재 프록시를 사용할 수 있지만, 실제 동작은 로그와 함께 확인해야 합니다. 로그의 구독 요청이 직접 시간 초과되는데 프록시를 켠 브라우저에서는 같은 도메인이 열린다면 클라이언트 업데이트 경로가 프록시를 거치지 않았을 가능성이 있습니다. Android에서는 백그라운드에서 v2rayNG 또는 v2flyNG가 업데이트를 실행할 때 네트워크 권한이 있고 시스템 데이터 제한에 차단되지 않았는지도 확인하세요. 무선 네트워크와 모바일 네트워크를 바꿔 비교하면 현재 접속 네트워크의 문제인지 빠르게 판단할 수 있습니다.

‘업데이트 성공 후 노드 없음’ 처리하기

업데이트 성공은 요청 및 파싱 과정에서 뚜렷한 오류가 발생하지 않았다는 뜻일 뿐, 유효한 노드가 포함되어 있다는 보장은 아닙니다. 먼저 그룹에 필터가 적용됐는지, 노드가 다른 그룹에 들어갔는지, 화면에 검색어가 남아 있는지 확인하세요. 필터를 해제해도 비어 있다면 응답 콘텐츠 유형을 확인합니다. 일반적인 구독은 인코딩된 링크 모음, 구조화된 구성 또는 클라이언트 전용 형식일 수 있습니다. 서버가 로그인 페이지, 오류 안내 또는 빈 텍스트를 반환하면 클라이언트가 형식을 인식하지 못할 수 있습니다.

업데이트 후 이전 노드가 모두 교체됐다면 구독 설정의 업데이트 정책을 확인하세요. 덮어쓰기 업데이트는 구독에서 일괄 관리하는 그룹에 적합하며, 로컬에서 수동으로 수정한 노드는 같은 자동 덮어쓰기 그룹에 섞지 않는 것이 좋습니다. 로컬 매개변수를 보존해야 한다면 별도 그룹으로 복사한 뒤 업데이트하세요. 데스크톱과 Android의 표준 가져오기 경로는 구독 링크 가져오기 단계를, 자동 업데이트 간격·프록시 업데이트·실패 원인은 구독 업데이트 실패 해결 방법을 참고하세요.

연결은 되지만 속도가 느리거나 변동이 큼

먼저 테스트 방식으로 인한 오판 배제하기

속도 문제는 비교 가능한 조건에서 판단해야 합니다. 특정 웹페이지 하나가 느린 것은 대상 사이트, 브라우저 확장 프로그램, 캐시 또는 이미지 리소스 때문일 수 있으며 프록시 경로 전체가 느리다는 뜻은 아닙니다. 같은 네트워크, 같은 기기, 같은 다운로드 대상을 선택하고 프록시 끄기, 프록시 켜기 및 노드 고정, 다른 노드로 전환의 세 상태를 각각 테스트하세요. 매 테스트 전에 백그라운드 동기화, 대용량 업데이트, 클라우드 드라이브 작업을 중지하고 여러 속도 측정 도구를 동시에 실행하지 마세요. 안정적인 처리량, 최초 연결 시간, 장시간 연결 유지 여부를 비교해야 하며 한 번의 순간 최고 속도만 보지 마세요.

프록시를 꺼도 느리다면 먼저 로컬 무선 신호, 라우터 부하 및 통신사 경로를 점검하세요. 직접 연결은 정상인데 모든 노드가 느리다면 클라이언트 라우팅, TUN, DNS 및 기기 리소스를 확인합니다. 특정 노드 하나만 느리다면 해당 노드의 회선, 혼잡 또는 원격 서버 부하일 가능성이 큽니다. 같은 네트워크에서 데스크톱과 Android가 같은 구성으로 모두 느리다면 기기 요인의 우선순위를 낮출 수 있습니다. 한 기기에서만 느리다면 절전, 백그라운드 제한, 가상 네트워크 어댑터 및 보안 소프트웨어를 확인하세요.

지연 시간, 대역폭, 패킷 손실 구분하기

지연 시간은 연결 수립과 상호작용 반응에, 대역폭은 지속적인 전송 속도에 영향을 주며, 패킷 손실은 재전송과 큰 변동을 일으킵니다. 세 지표는 서로 다릅니다. 연결 수립은 느리지만 지속 다운로드가 안정적인 노드는 지연 시간이 높아도 대역폭은 충분할 수 있습니다. 초기 응답은 빠르지만 전송 속도가 반복해서 떨어지는 노드는 혼잡이나 패킷 손실이 있을 수 있습니다. 클라이언트의 기본 테스트는 제한적인 참고 자료일 뿐이므로 최종 판단은 실제 사용 환경에서 검증해야 합니다. 한 번의 지연 시간 순위로 노드를 자주 자동 전환하지 마세요. 기존 연결이 끊기고 점검 표본의 일관성도 사라집니다.

프로토콜 캡슐화, TLS, 전송 방식 및 라우팅 경로는 모두 오버헤드를 추가하지만 프로토콜 이름만으로 속도를 판단해서는 안 됩니다. 같은 프로토콜도 서버, 네트워크, 시간대에 따라 성능이 완전히 달라질 수 있습니다. 먼저 매개변수가 정확하고 연결이 안정적인 노드를 선택한 뒤 네트워크 경로를 비교하세요. 로그에 연결 재설정, 재시도 또는 쓰기 시간 초과가 계속 나타난다면 속도 저하는 기기 성능보다 연결 품질 문제일 가능성이 큽니다.

TUN, MTU 및 우회 라우팅 확인하기

TUN 모드는 더 많은 트래픽을 인계하는 대신 가상 네트워크 어댑터, DNS 및 라우팅 처리 단계도 늘립니다. 시스템 프록시 모드는 정상인데 TUN에서 눈에 띄게 느려진다면 다른 가상 네트워크 어댑터, 중복 라우팅 또는 보안 소프트웨어 필터링이 있는지 확인하세요. 일부 네트워크에서는 MTU가 맞지 않아 작은 웹페이지는 열리지만 대용량 파일이 멈추거나 특정 사이트가 완전히 로드되지 않을 수 있습니다. MTU를 임의로 극단적인 값으로 바꾸지 말고 클라이언트 기본값으로 복원한 뒤 현재 네트워크에 맞춰 작은 값들을 단계적으로 테스트하세요. 변경할 때마다 다시 연결해야 합니다.

분기 규칙 때문에 우회 경로가 생길 수도 있습니다. 대상 도메인이 먼저 원격 DNS에서 예상과 다른 주소로 해석된 뒤 IP 규칙에 다시 매칭되면 출구 방향이 바뀔 수 있습니다. 복잡한 규칙 집합이 겹친다면 로그에서 라우팅 매칭 결과를 확인하세요. 점검 단계에서는 간단한 모드를 임시로 사용해 속도가 회복되는지 확인한 뒤 도메인 규칙, IP 규칙 및 원격 DNS를 하나씩 추가합니다. 규칙이 많다고 판단이 정확해지는 것은 아니며 규칙 수보다 명확한 우선순위가 중요합니다.

기기 리소스와 동시 연결 확인하기

데스크톱에서 리소스 사용량이 높다면 화면 프로세스, 프록시 코어, 다른 앱 중 무엇이 원인인지 먼저 확인하세요. 동시 연결이 많거나 로그가 계속 출력되거나 TUN이 트래픽을 인계하거나 실시간 보안 검사가 실행되면 부하가 증가할 수 있습니다. 불필요한 상세 로그를 끄고 중복 실행 중인 클라이언트를 줄이며 여러 프록시가 동시에 활성화되어 있지 않은지 확인하세요. Android 기기는 절전 모드, 높은 온도 또는 백그라운드 제한으로 연결이 느려지거나 일시 중지될 수 있습니다. 클라이언트의 백그라운드 실행을 허용한 뒤 다시 테스트하세요.

느린 속도가 특정 앱에서만 발생한다면 해당 앱이 QUIC, 독립 DNS 또는 자체 프록시를 사용하는지 확인하세요. 브라우저와 시스템 다운로드 도구의 동작을 임시로 비교해 앱 계층에 국한된 문제인지 판단할 수 있습니다. 모든 앱이 특정 시간대에 동시에 느려진다면 발생 시간, 네트워크 유형 및 노드 그룹을 기록하고 클라이언트 설정을 계속 바꾸지 마세요. 안정적으로 재현해야 로컬 구성과 외부 경로 변화를 구분할 수 있습니다.

DNS 조회 실패, 오염된 캐시 및 잘못된 분기

DNS 장애의 대표적인 증상 파악하기

DNS 문제는 도메인은 열리지 않지만 알고 있는 IP에 직접 접속하면 응답하는 경우, 일부 도메인이 간헐적으로 실패하는 경우, 클라이언트 로그에 lookup 또는 resolve 오류가 나타나는 경우, 네트워크를 바꾸면 잠시 복구되는 경우로 나타납니다. 더 눈에 띄지 않는 분기 오류도 있습니다. 도메인 조회는 성공했지만 반환된 주소가 잘못된 규칙에 매칭되어 트래픽이 예상과 다른 방향으로 흐르는 경우입니다. DNS를 점검할 때는 조회를 누가 시작했는지, 어느 DNS로 보냈는지, 조회 결과가 라우팅에 어떻게 사용되는지 세 가지를 함께 확인해야 합니다.

먼저 프록시를 끈 상태에서 시스템 DNS를 테스트한 뒤 클라이언트를 켜 결과를 비교하세요. Windows에서는 nslookup 또는 PowerShell의 Resolve-DnsName, macOS에서는 dig와 scutil --dns, Linux에서는 resolvectl query로 systemd-resolved의 조회 결과를 확인할 수 있습니다. 테스트할 때 도메인, 반환 주소, 사용된 서버를 기록하고 단순히 ‘DNS가 안 됨’이라고만 적지 마세요.

nslookup example.com
Resolve-DnsName example.com

dig example.com
scutil --dns

resolvectl query example.com
resolvectl status

캐시를 지우기 전에 증거 저장하기

시스템, 브라우저, 클라이언트 코어 및 앱 모두 조회 결과를 캐시할 수 있습니다. 곧바로 모든 캐시를 지우면 일시적으로 복구될 수 있지만 판단에 필요한 단서를 잃게 됩니다. 먼저 시스템 도구와 브라우저 결과를 비교하세요. 시스템 도구는 정상인데 브라우저만 실패하면 브라우저 보안 DNS, 확장 프로그램 및 자체 캐시를 확인합니다. 시스템 도구와 클라이언트 로그 결과가 다르면 클라이언트 내장 DNS를 확인하세요. 모든 도구가 실패할 때는 현재 네트워크가 제공하는 DNS와 네트워크 연결을 점검합니다.

정리가 필요하다고 확인되면 Windows에서는 ipconfig /flushdns를 실행할 수 있습니다. macOS에서는 현재 네트워크 서비스를 다시 시작하거나 시스템 DNS 캐시를 새로 고치고, Linux에서는 실제로 사용하는 DNS 서비스에 따라 해당 구성 요소를 다시 시작하세요. 정리한 뒤 조회를 다시 실행하고 결과를 기록합니다. 캐시를 지울 때마다 잠시만 복구된다면 근본 원인은 캐시 자체가 아니라 상위 DNS, 규칙 또는 네트워크가 계속 비정상 결과를 반환하는 데 있습니다.

클라이언트 DNS와 라우팅의 관계 확인하기

V2Ray 구성의 DNS는 단순히 ‘서버 주소 하나를 입력하는’ 기능이 아닙니다. 도메인 규칙에 따라 로컬 또는 원격 조회기를 선택할 수 있고, 반환된 IP는 다시 IP 라우팅 매칭에 사용될 수 있습니다. 도메인은 로컬에서 먼저 조회하지만 트래픽은 프록시 규칙으로 전송하면 조회 결과와 프록시 출구에서 보는 대상이 달라질 수 있습니다. fake DNS 또는 TUN DNS 인계를 활성화했다면 가상 주소를 코어가 올바르게 원래 주소로 되돌리는지도 확인해야 합니다. 점검할 때는 먼저 복잡한 도메인 분기와 fake DNS를 끄고 명확한 하나의 조회 경로로 검증한 뒤 고급 설정을 복원하세요.

아래 예시는 Xray 스타일 구성에서 단순화한 DNS 구조를 보여 줍니다. 실제 서버 주소와 조회 정책은 네트워크 환경에 맞춰 설정해야 합니다. 핵심은 로컬과 원격의 역할을 명확히 나누고 라우팅 규칙과 DNS 태그를 대응시키는 것입니다.

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      }
    ],
    "queryStrategy": "UseIP"
  }
}

구성 예시는 기존의 완전한 구성을 그대로 덮어쓸 수 없습니다. 코어 유형, 규칙 리소스 및 네트워크 조건이 다를 수 있기 때문입니다. 현재 클라이언트가 구독으로 관리된다면 화면의 DNS 및 라우팅 설정을 통해 조정하고, 다음 구독 업데이트에서 덮어써질 수 있는 수동 편집은 피하세요. V2Fly 코어를 사용하는 v2flyNG에서도 해당 필드가 현재 코어의 지원 범위에 속하는지 확인해야 합니다.

브라우저와 시스템 결과가 다른 경우 처리하기

최신 브라우저는 독립적인 보안 DNS를 활성화해 시스템 조회 경로를 우회할 수 있습니다. 시스템 명령으로는 정상적으로 조회되는데 브라우저가 잘못된 주소에 접속한다면 브라우저 네트워크 설정에서 조회 방식을 확인하고 확장 프로그램을 잠시 꺼서 비교하세요. 일부 앱은 연결과 조회 결과를 캐시하므로 시스템 DNS를 업데이트해도 이전 프로세스가 기존 결과를 계속 사용할 수 있습니다. 페이지 새로 고침만 하는 것보다 앱을 완전히 종료한 뒤 다시 여는 편이 확실합니다.

TUN 모드에서 도메인만 실패하고 순수 IP 요청은 접근 가능하다면 DNS 트래픽이 가상 네트워크 어댑터에 의해 인계되는지, 53번 포트를 다른 소프트웨어가 사용 중인지, 시스템에 활성 네트워크 인터페이스가 여러 개 있는지 확인하세요. 무선, 유선, 가상 네트워크 어댑터가 동시에 연결되어 있으면 시스템이 우선순위는 높지만 사용할 수 없는 인터페이스로 DNS 요청을 보낼 수 있습니다. 관련 없는 인터페이스를 먼저 비활성화해 확인한 뒤 장기적으로 사용할 인터페이스의 우선순위를 조정하세요.

시스템 프록시가 적용되지 않거나 일부 앱이 프록시를 사용하지 않음

시스템 설정과 클라이언트 수신 설정이 일치하는지 확인하기

시스템 프록시는 이 설정을 지원하는 앱의 요청을 로컬 HTTP 또는 SOCKS 포트로 보내는 기능입니다. 클라이언트에 ‘시스템 프록시가 켜짐’으로 표시되어도 시스템 설정의 주소와 포트가 코어의 실제 수신 설정과 일치하는지 대조해야 합니다. 일반적으로 로컬 주소는 루프백 인터페이스를 가리키고, 포트는 v2rayN 설정 화면과 로그에 표시된 수신 포트와 같아야 합니다. 포트를 변경했거나 구성 디렉터리를 전환했거나 여러 인스턴스를 동시에 실행했다면 시스템에 이전 값이 남아 있을 수 있습니다.

Windows에서는 시스템 네트워크 프록시 페이지에서 수동 프록시를 확인할 수 있으며, 명령으로 WinHTTP 상태를 확인할 수도 있습니다.

netsh winhttp show proxy

Windows의 사용자 수준 시스템 프록시와 WinHTTP 프록시는 완전히 같지 않다는 점에 유의하세요. 브라우저가 사용자 프록시로 접속된다고 해서 시스템 서비스나 명령줄 도구도 같은 설정을 사용하는 것은 아닙니다. macOS의 프록시는 네트워크 서비스별로 저장되므로 무선 네트워크와 유선 네트워크를 바꾼 뒤 각각 확인해야 합니다. Linux 데스크톱 환경, 터미널 환경 변수, 개별 앱도 각자 프록시 구성을 유지할 수 있습니다. 점검할 때는 대상 앱이 어떤 설정을 읽는지 먼저 파악하세요.

일부 앱만 직접 연결하는 문제 처리하기

일부 앱은 시스템 프록시를 따르지 않거나 SOCKS 설정은 읽지 않고 HTTP 프록시만 지원합니다. 이 경우 노드와 코어는 정상이어도 앱 트래픽은 직접 연결됩니다. 먼저 브라우저로 로컬 프록시를 확인한 다음 대상 앱에 독립 프록시 옵션이 있는지 살펴보세요. 지원한다면 클라이언트의 로컬 수신 주소와 해당 프로토콜 포트를 입력합니다. 지원하지 않으면서 반드시 트래픽을 인계해야 한다면 TUN 모드를 검토할 수 있습니다. 특정 앱 하나 때문에 전체 라우팅 규칙을 바꾸지 말고 해당 앱이 로컬 프록시 진입점을 사용하는지 먼저 확인하세요.

명령줄 도구는 일반적으로 환경 변수를 읽습니다. 임시 테스트에서는 현재 터미널에만 설정하면 터미널을 닫을 때 자동으로 사라집니다. 아래 예시는 로컬 HTTP 포트를 사용하며 포트는 클라이언트의 실제 값으로 바꿔야 합니다.

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

앞의 두 줄은 Windows 명령 프롬프트용이고 뒤의 두 줄은 macOS와 Linux에서 흔히 사용하는 셸용입니다. 테스트가 끝나면 변수를 삭제해 클라이언트가 실행되지 않을 때도 유효하지 않은 포트를 계속 가리키지 않도록 하세요. 앱 내부 프록시, 환경 변수, 시스템 프록시가 겹치면 일반적으로 앱 자체 설정이 우선합니다. 시스템 설정이 올바른데도 실패한다면 앱에 이전 프록시가 저장되어 있는지 확인하세요.

PAC, 전역 프록시, TUN 구분하기

PAC 또는 자동 구성 모드는 규칙에 따라 프록시를 사용할 요청을 결정하며, 시스템 프록시를 따르고 자동 구성을 지원하는 앱에 적합합니다. 전역 시스템 프록시는 지원되는 요청을 더 많이 로컬 포트로 전달하지만 시스템 프록시를 완전히 무시하는 프로그램까지 처리하지는 못합니다. TUN은 가상 네트워크 어댑터로 더 넓은 트래픽을 처리하며 올바른 라우팅, DNS 및 권한 설정이 필요합니다. 모드는 앱 범위에 따라 선택해야 하며 TUN을 모든 문제의 첫 해결책으로 사용해서는 안 됩니다.

PAC 모드에서 일부 사이트가 프록시를 사용하지 않지만 전역 모드에서는 작동한다면 문제는 대개 PAC 규칙, 캐시 또는 앱의 PAC 지원에 있습니다. 먼저 시스템 프록시 설정을 새로 고치고 대상 앱을 다시 시작한 뒤 규칙 매칭을 확인하세요. 전역 시스템 프록시도 작동하지 않지만 앱에 로컬 포트를 직접 입력하면 작동한다면 해당 앱이 시스템 설정을 읽지 않는 것입니다. TUN을 켠 뒤 모든 앱의 네트워크가 끊기면 노드를 계속 수정하지 말고 제2장으로 돌아가 가상 네트워크 어댑터와 라우팅을 확인하세요.

클라이언트가 시작되지 않거나 충돌하거나 코어가 반복 종료됨

화면 프로세스와 코어 프로세스부터 구분하기

v2rayN은 그래픽 화면과 프록시 코어가 함께 작동합니다. 화면은 정상적으로 열려도 구성 오류, 포트 충돌 또는 권한 문제로 코어가 즉시 종료될 수 있습니다. 반대로 코어가 백그라운드에 남아 있으면 화면을 다시 열 때 포트 충돌이 표시될 수 있습니다. 점검할 때는 먼저 작업 관리자나 시스템 프로세스 목록에서 어떤 프로세스가 종료되는지 확인하세요. 화면이 충돌한다면 앱 로그와 시스템 이벤트를 확인하고, 코어가 종료된다면 클라이언트 로그에서 시작 명령 다음에 처음 나타나는 오류를 우선 살펴봅니다.

구성 파일 손상도 흔한 원인입니다. 새 노드를 가져오거나 라우팅을 편집하거나 구독을 업데이트한 뒤 문제가 발생했다면 먼저 이전에 작동하던 구성으로 되돌리세요. 구성 디렉터리 전체를 바로 삭제하지 말고 먼저 백업한 뒤 클라이언트를 새 빈 구성으로 시작합니다. 빈 구성으로 시작되지만 기존 구성을 불러올 때 종료된다면 문제는 구성 내용이나 데이터베이스에 집중되어 있습니다. 빈 구성에서도 시작되지 않는다면 실행 환경, 권한, 파일 경로 및 보안 소프트웨어의 처리 기록을 확인하세요.

포트, 경로 및 실행 권한 확인하기

코어를 시작하려면 구성 읽기, 규칙 리소스 로드, 로그 생성, 로컬 포트 수신이 필요합니다. 설치 디렉터리에 쓰기 권한이 없거나 경로가 동기화 소프트웨어에 의해 잠겼거나 파일을 다른 프로그램이 사용 중이면 시작에 실패할 수 있습니다. 데스크톱에서는 현재 사용자가 읽고 쓸 수 있는 일반 디렉터리에 클라이언트를 두고 압축 파일 미리보기 창에서 직접 실행하지 마세요. 다운로드 플랫폼이나 아키텍처를 잘못 선택해도 프로그램이 실행되지 않을 수 있으므로 다운로드 페이지에서 Windows, macOS, Android, Linux에 해당하는 경로를 다시 확인하세요.

포트 사용 현황은 제2장의 방법으로 확인할 수 있습니다. 이전 코어 프로세스가 발견되면 클라이언트를 정상적으로 종료하고 프로세스가 끝날 때까지 기다린 뒤 다시 시작하세요. 프로세스가 종료되지 않을 때만 시스템 도구로 중지합니다. 무작위 포트를 계속 바꿔 중복 프로세스를 숨기지 마세요. 시스템 프록시와 앱 내부 프록시가 이전 포트를 계속 가리킬 수 있습니다. 포트를 변경한 뒤에는 시스템 프록시도 함께 업데이트하고 방화벽이 로컬 루프백 통신을 허용하는지 확인하세요.

업그레이드 후 시작 오류 처리하기

클라이언트 업그레이드 후 문제가 발생하는 흔한 원인은 새 화면과 호환되지 않는 이전 구성 필드, 실행 종속성 변화, 완전히 교체되지 않은 코어 파일, 파일을 점유한 이전 프로세스입니다. 먼저 클라이언트와 코어를 완전히 종료한 뒤 다시 시작하세요. 그래도 실패하면 구독 주소, 라우팅 및 필요한 설정을 백업하고 현재 설치 패키지를 새 디렉터리에서 시작한 뒤 하나씩 가져옵니다. 이전 디렉터리 전체를 새 디렉터리에 바로 덮어쓰지 마세요. 손상된 파일과 호환되지 않는 구성을 함께 되돌릴 수 있습니다.

v2rayN 데스크톱 버전과 클래식 WPF 버전은 화면 기술과 지원 플랫폼 범위가 다릅니다. 표시 또는 실행 환경 문제가 발생하면 두 버전 중 무엇을 사용하는지 먼저 확인하고 두 버전의 디렉터리 사이에서 구성 파일을 섞지 마세요. 두 버전의 차이는 v2rayN 데스크톱 버전과 WPF 버전 선택 안내에서 확인할 수 있습니다. 버전을 전환하기 전 구독과 사용자 지정 규칙을 백업하고 독립 디렉터리에서 테스트하면 이전 파일의 간섭을 피할 수 있습니다.

리소스 또는 규칙이 충돌을 유발하는지 분석하기

클라이언트가 구독 업데이트, 속도 측정 또는 TUN 활성화 중에만 종료된다면 특정 작업이 장애를 유발할 가능성이 있습니다. 구독에 구성이 많으면 파싱, 중복 제거, 테스트 과정에서 순간적인 리소스 사용량이 증가할 수 있으며 복잡한 라우팅 리소스 로딩 실패로 코어가 시작 직후 중단될 수도 있습니다. 먼저 자동 속도 측정과 자동 업데이트를 끄고 단일 수동 구성으로 기본 실행을 확인한 뒤 기능을 하나씩 복원하세요. 특정 구독 그룹에서만 발생한다면 로그를 보존하고 해당 그룹에 비정상 필드가 있는지 확인합니다.

로그가 빠르게 계속 증가하면 디스크를 차지하고 실행에 영향을 줄 수 있습니다. 점검할 때는 상세 로그를 짧게 활성화해 재현한 뒤 즉시 일반 수준으로 되돌리고 핵심 구간만 저장하세요. 전체 연결 정보가 포함된 디버그 로그를 장기간 보관하지 마세요. 시스템 디스크 공간이 부족하면 클라이언트가 구성을 저장하거나 리소스를 업데이트하지 못할 수 있으므로 먼저 공간을 확보하고 디렉터리에 쓸 수 있는지 확인합니다.

복구 가능한 구성 관리 습관 만들기

안정적으로 실행된 뒤에는 구독 주소, 사용자 지정 라우팅, 클라이언트 설정을 각각 백업하세요. 모든 복구 수단을 하나의 프로그램 디렉터리에만 의존하지 않는 것이 좋습니다. 업데이트 전에 현재 클라이언트 유형, 코어 유형 및 주요 포트를 기록해 두면 문제가 생겼을 때 정확히 되돌릴 수 있습니다. 백업은 통제된 위치에 보관하고 구독 주소나 인증 필드를 공개적으로 공유하지 마세요.

클라이언트가 빈 구성으로 안정적으로 실행된다면 다음 순서로 복원하는 것이 좋습니다. 단일 노드를 추가해 연결을 확인하고, 구독을 추가한 뒤, 시스템 프록시 설정을 복원하고, 마지막으로 사용자 지정 DNS·라우팅·TUN을 추가합니다. 각 단계마다 한 번씩 시작하고 로그를 확인하세요. 다시 충돌하더라도 어떤 구성 유형이 원인인지 명확히 알 수 있어 전체 디렉터리에서 처음부터 추측할 필요가 없습니다.

Android 연결 중단 및 백그라운드 제한

가상 네트워크 권한과 클라이언트 상태 확인하기

v2rayNG와 v2flyNG는 Android에서 일반적으로 시스템 가상 네트워크 인터페이스를 통해 트래픽을 인계합니다. 처음 연결하거나 시스템에서 권한을 초기화한 뒤에는 연결 권한을 확인하라는 메시지가 표시됩니다. 클라이언트 화면에는 시작 중이라고 나오지만 실제 연결이 형성되지 않는다면 가려진 권한 대화 상자가 있는지 먼저 확인하고 상태 표시줄의 가상 네트워크 상태도 살펴보세요. 다른 네트워크 도구가 같은 유형의 인터페이스를 사용 중이라면 이전 연결을 먼저 끊은 뒤 현재 클라이언트를 시작합니다.

구성을 가져온 뒤에는 연결할 노드를 하나 명확히 선택해야 합니다. 구독 그룹이 존재한다고 연결 가능한 구성이 선택된 것은 아니며, 업데이트 성공이 코어 실행을 의미하지도 않습니다. 연결한 뒤 로그를 열어 코어가 구성을 로드하고 로컬 진입점을 만들며 원격 연결을 시도하는지 확인하세요. 시작 단계에서 구성 오류가 바로 발생한다면 구조가 단순한 노드 하나로 먼저 검증하고 앱별 프록시, 복잡한 DNS, 사용자 지정 라우팅을 동시에 켜지 마세요.

화면 잠금 후 연결 끊김과 백그라운드 종료 처리하기

Android의 절전 정책은 화면 잠금, 대기 또는 메모리 부족 상황에서 백그라운드 프로세스를 제한할 수 있습니다. 전면 사용 중에는 정상이지만 일정 시간 화면을 잠근 뒤 연결이 끊기고 클라이언트를 다시 열면 복구되는 것이 대표적인 증상입니다. 시스템의 배터리 및 백그라운드 관리에서 v2rayNG 또는 v2flyNG가 계속 실행되도록 허용하고 자동 절전 대상이 아닌지 확인하세요. 기기마다 설정 이름은 다르지만 판단 방법은 같습니다. 같은 노드를 유지한 채 전면 화면, 짧은 잠금, 긴 잠금을 각각 테스트하고 클라이언트 프로세스와 연결 상태가 시스템에 의해 중지되는지 관찰합니다.

최근 작업 목록에서 앱을 잠그는 것만으로는 충분하지 않을 수 있습니다. 백그라운드 네트워크, 데이터 절약, 절전 제한도 확인해야 합니다. 절전 중 무선 네트워크가 꺼지면 연결이 중단될 수 있으며 모바일 네트워크로 전환한 뒤에는 클라이언트가 다시 연결해야 할 수 있습니다. 네트워크 전환 후 잠시 재연결되는 것은 정상입니다. 오래 복구되지 않으면 수동으로 연결을 끊었다가 다시 연결하고 로그에서 이전 네트워크 인터페이스를 계속 사용하는지 확인하세요.

앱별 프록시와 우회 설정 확인하기

앱별 프록시는 지정한 앱만 인계하거나 일부 앱을 제외할 수 있지만 선택 로직을 잘못 설정하면 ‘브라우저는 되지만 다른 앱은 직접 연결’되거나 반대 결과가 나타납니다. 먼저 앱별 기능을 끄고 전체 인계가 정상인지 확인하세요. 정상이라면 다시 활성화한 뒤 현재 모드가 선택한 앱만 프록시하는 방식인지, 선택한 앱을 우회하는 방식인지 확인합니다. 앱 업데이트, 재설치 또는 업무 프로필 공간으로 인해 앱 식별자가 바뀌면 기존 목록이 더 이상 매칭되지 않을 수 있습니다.

시스템 구성 요소나 특정 앱만 연결되지 않는다면 제외 목록에 들어갔는지, 독립 DNS를 사용하는지, 가상 네트워크가 제한되어 있는지 확인하세요. 명백한 앱 범위 문제를 노드를 계속 바꿔 해결하려 하지 마세요. 앱별 목록을 수정한 뒤에는 다시 연결해 라우팅 규칙을 완전히 다시 로드해야 합니다. 업무 프로필과 기본 사용자 공간은 별도의 네트워크 정책을 가질 수 있으므로 한 공간의 설정이 모든 공간에 적용된다고 가정하지 말고 각각 확인하세요.

무선 네트워크와 모바일 네트워크 비교하기

같은 노드가 무선 네트워크에서는 작동하지만 모바일 네트워크에서는 시간 초과되거나 그 반대라면 구성 자체는 유효하고 접속 네트워크, DNS, 주소 체계 또는 MTU에서 차이가 발생했을 가능성이 있습니다. 두 네트워크에서 도메인 조회, 연결 오류, 사용된 전송 방식을 각각 기록하세요. 모바일 네트워크가 IPv6를 우선 사용하지만 노드 도메인이 반환한 주소에 접근할 수 없다면 클라이언트 주소 정책과 DNS 조회 정책을 확인합니다. 무선 네트워크에 웹 인증 포털이 있다면 먼저 클라이언트 인계를 끄고 인증을 완료한 뒤 다시 연결하세요.

네트워크를 전환할 때 이전 연결이 원래 인터페이스에 남아 잠시 요청이 실패할 수 있습니다. 먼저 클라이언트의 자동 재연결을 기다리세요. 그래도 복구되지 않으면 한 번 연결을 끊었다가 다시 연결합니다. 전환할 때마다 앱을 재시작해야 한다면 시스템이 백그라운드 네트워크 변경 알림을 제한하는지, 클라이언트가 정지된 상태가 아닌지 확인하세요. 앱 데이터를 반복해서 삭제하지 마세요. 구독, 그룹, 라우팅 설정이 삭제될 뿐 네트워크 전환 문제는 해결되지 않을 수 있습니다.

v2rayNG와 v2flyNG의 점검 기준 선택하기

Android에서는 먼저 구성에 필요한 코어에 따라 클라이언트를 선택하세요. v2rayNG는 Xray 코어를 사용하므로 Xray 관련 프로토콜 기능이 필요한 구성에 적합합니다. v2flyNG는 V2Fly 코어를 사용하므로 해당 생태계 구성에 선택할 수 있습니다. 두 클라이언트를 동시에 설치했더라도 동시에 연결하지 말고, 같은 구성이 서로 다른 코어에서 완전히 동일하게 지원된다고 가정하지 마세요. 비교 테스트에서는 네트워크와 노드를 고정하고 클라이언트만 바꾼 뒤 구체적인 오류를 기록합니다.

v2rayNG에서는 연결되지만 v2flyNG에서는 연결되지 않거나 반대라면 휴대폰 네트워크 탓으로 돌리기 전에 해당 코어가 프로토콜 및 전송 기능을 지원하는지 확인하세요. Xray와 V2Fly의 기능 범위는 Xray와 V2Fly 코어 차이에서 확인할 수 있습니다. 다시 설치해야 한다면 Android 다운로드 경로에서 기기 아키텍처에 맞는 버전을 선택하고 기존 구독 정보를 보존한 뒤 이전하세요.