v2rayN 문제 해결 가이드

인터넷에 연결되지 않을 때: 요청이 어느 단계에서 멈추는지 확인

클라이언트가 실행 중인 것과 앱이 프록시를 통해 인터넷에 연결되는 것은 별개의 문제입니다. 일반적인 연결은 앱, 시스템 프록시 또는 가상 네트워크 어댑터, 로컬 인바운드, 라우팅 규칙, 원격 노드를 거쳐 대상 서비스에 도달합니다. 어느 한 단계라도 연결되지 않으면 웹페이지가 열리지 않을 수 있습니다. 먼저 실패 범위를 기록하세요. 모든 앱에서 발생하는지, 특정 브라우저에서만 발생하는지, 모든 사이트가 안 열리는지 특정 도메인만 안 열리는지, 클라이언트를 종료하면 일반 네트워크가 복구되는지 확인합니다. 이런 범위를 파악하면 오류 메시지 하나만 볼 때보다 원인을 쉽게 좁힐 수 있습니다.

일반 네트워크와 프록시 네트워크 비교하기

다른 프록시 도구를 종료하고 v2rayN의 시스템 프록시와 TUN을 끈 다음, 평소 바로 접속할 수 있는 페이지가 일반 네트워크에서 열리는지 확인하세요. 이때도 연결되지 않으면 네트워크 연결, 게이트웨이, 무선 네트워크 인증 페이지, 시스템 DNS부터 확인하고 노드 변경은 미루세요. 공용 무선 네트워크는 먼저 로그인해야 할 수 있으며, 프록시를 실행하면 인증 페이지가 표시되지 않을 수도 있습니다. 일반 연결이 정상인지 확인한 뒤 v2rayN을 실행하고 설정된 노드를 선택해 시스템 프록시를 켜세요. 같은 브라우저로 같은 테스트 페이지에 접속합니다.

이어서 클라이언트 로그를 열고 현재 표시를 지우거나 시작 시간을 기록한 다음 요청을 한 번 보냅니다. 새 연결 기록이 없다면 앱이 시스템 프록시를 사용하는지, 로컬 포트가 올바른지, 브라우저 확장 프로그램이 요청을 가로채는지부터 확인하세요. 로그에 대상 도메인과 아웃바운드가 기록되었다면 요청은 적어도 코어에 도달한 것입니다. 이후 DNS 조회, 원격 연결, 핸드셰이크, 대상 서버 응답 중 어느 단계에서 오류가 났는지 살펴보세요. 일반적으로 로그 수준은 정보면 충분하며, 구체적인 원인을 찾을 때만 잠시 상세 수준을 높이면 됩니다.

시스템 프록시를 거치지 않고 로컬 인바운드 직접 테스트하기

아래 예시는 SOCKS 인바운드를 기준으로 합니다. 포트는 클라이언트 설정에 표시된 실제 값으로 바꾸세요. 예시의 10808은 모든 설치에서 사용하는 고정 포트가 아닙니다. Windows에서는 터미널에서 curl.exe를, macOS와 Linux에서는 보통 curl을 사용합니다. 테스트 주소는 연결 완료 여부를 확인하기 위한 것으로 모든 서비스가 정상인지 보장하지 않습니다. 특정 HTTP 상태 코드가 반환되더라도 연결이 성립했는지 함께 확인해야 합니다.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl --noproxy "*" --connect-timeout 10 -I https://example.com

첫 번째 명령은 프록시를 명시적으로 지정하고, 두 번째 명령은 프록시를 우회합니다. 각각의 결과를 기록하세요. socks5h를 사용하면 대상 도메인을 프록시 측에서 조회하므로 앱의 로컬 DNS 조회가 테스트에 영향을 주지 않습니다. 첫 번째 명령에서 로컬 포트 연결 실패가 발생하면 코어가 실행 중인지, 해당 포트에서 수신 대기 중인지 확인하세요. 프록시 요청은 성공하는데 브라우저에서 실패한다면 브라우저 프록시 설정, 확장 프로그램 또는 캐시 문제일 가능성이 큽니다. HTTP 인바운드 포트를 SOCKS 포트로 사용하지 마세요. 두 프로토콜을 혼용하면 빈 응답이나 프로토콜 오류가 발생할 수 있습니다.

라우팅 오류와 대상 서비스 장애 구분하기

요청이 코어에 들어간 뒤 direct, proxy, block 중 어떤 아웃바운드가 선택되었는지 확인하세요. 특정 사이트가 잘못 block으로 분류된 경우 노드를 바꿔도 해결되지 않습니다. 어떤 도메인 규칙이 일치했는지 찾아야 합니다. 잘못 direct로 분류된 경우에도 연결 시간 초과가 발생할 수 있습니다. 우선 라우팅을 간단한 프록시 설정으로 잠시 바꾸고 같은 요청을 다시 테스트하세요. 문제가 해결되면 기존 규칙을 하나씩 복원합니다. 이 비교는 원인을 찾기 위한 방법일 뿐, 모든 요청을 하나의 아웃바운드로 보내는 설정을 계속 사용하는 것은 권장하지 않습니다. 특히 로컬 네트워크와 노드 서버 주소에는 적절한 직접 연결 경로를 유지해야 합니다.

자주 사용하는 서비스는 대부분 정상인데 특정 대상만 실패한다면 대상 사이트 점검, 계정 제한, 서버 측 지역 정책 또는 브라우저 세션 문제도 고려하세요. 클라이언트를 반복해서 재설치하기보다 다른 브라우저 세션과 같은 네트워크에 연결된 다른 기기에서 비교하는 편이 효과적입니다. 최종 확인에는 프록시 대상 하나, 직접 연결 대상 하나, 로컬 네트워크 대상 하나를 포함하고 로그에 예상한 아웃바운드가 표시되는지 확인하세요. 연결이 복구되어도 라우팅이 잘못되었다면 완전히 해결된 것이 아닙니다.

노드 시간 초과: 주소, 포트, 핸드셰이크 문제 구분하기

노드 테스트 시간 초과가 서버 중단을 의미하는 것은 아닙니다. 클라이언트 테스트에는 도메인 조회, 전송 연결, 프로토콜 핸드셰이크, 테스트 주소 접속이 포함될 수 있으며 어느 한 단계에서 실패해도 시간 초과로 표시될 수 있습니다. 먼저 모든 노드가 동시에 실패하는지, 특정 설정만 실패하는지 구분하세요. 현재 네트워크에서만 실패하는지 다른 네트워크에서도 실패하는지도 확인합니다. 모든 노드에서 문제가 생기면 로컬 네트워크, DNS, 프록시 순환 또는 테스트 주소를 먼저 확인하고, 특정 노드만 실패하면 해당 노드의 매개변수를 하나씩 점검하세요.

연결 대상을 확인하고 매개변수를 잘못된 항목에 입력하지 않기

노드 편집 화면에서 서비스 제공업체가 안내한 서버 주소, 포트, 프로토콜, 전송 방식, 보안 설정을 확인하세요. 서버 주소는 일반적으로 도메인 또는 IP이며 웹 주소의 프로토콜 접두어나 경로를 포함하면 안 됩니다. WebSocket의 경로와 Host, TLS의 SNI는 서로 다른 항목이므로 비슷해 보인다는 이유로 바꿔 입력하지 마세요. 포트는 원격 서비스가 수신 대기 중인 포트여야 합니다. 로컬 SOCKS 포트는 앱이 클라이언트에 연결할 때 사용하므로 서버 포트 항목에 입력하면 잘못된 서비스에 연결됩니다.

구독에서 가져온 노드라면 먼저 구독을 업데이트해 이전 주소를 계속 사용하지 않도록 하세요. 다만 업데이트하면 구독에서 관리하는 노드가 덮어써질 수 있으므로 직접 수정하기 전에 비교용 사본을 저장하세요. 비교할 때는 한 번에 한 항목만 바꾸고 전송 방식, 포트, 보안 설정을 동시에 변경하지 마세요. 비밀번호, 사용자 ID, 공개 키 등의 형식이 올바르더라도 서버 설정과 일치하지 않을 수 있습니다. 이런 오류는 시간 제한을 늘려 해결할 수 없으므로 유효한 설정을 다시 가져와야 합니다.

오류 유형으로 연결이 어느 단계까지 진행됐는지 파악하기

로그에 connection refused가 표시되면 연결 시도가 거부된 것입니다. 포트, 서비스 상태, 중간 장비의 정책을 확인하세요. i/o timeout이나 연결 시간 초과는 지정된 시간 안에 예상한 작업이 완료되지 않았다는 뜻입니다. network is unreachable는 로컬 라우팅 또는 주소 체계 문제에 더 가깝습니다. 이 메시지를 모두 같은 원인으로 해석하지 마세요. 서버가 ping에 응답하지 않는다는 이유만으로 프록시를 사용할 수 없다고 단정해서도 안 됩니다. 서버가 해당 탐색 요청은 거부하면서 일반 연결은 허용할 수 있습니다.

TCP 연결이 성립한 뒤 TLS 또는 인증 오류가 발생하면 핸드셰이크 설정을 확인하세요. 먼저 시스템 시간을 동기화하고 SNI, 인증서에 해당하는 도메인, 클라이언트의 전송 방식이 서버 설정과 일치하는지 점검합니다. REALITY 설정에서는 공개 키, 짧은 ID, 서버 이름, 지문 등을 확인하고 선택한 코어가 해당 조합을 지원하는지도 살펴보세요. 원인을 찾는 동안에는 서비스 제공업체가 명확히 지원하는 설정을 사용하고 다른 프로토콜의 매개변수를 임의로 섞지 마세요.

네트워크 경로와 프록시 순환 확인하기

동일한 노드를 신뢰할 수 있는 다른 네트워크에서도 테스트하세요. 모바일 핫스팟에서는 연결되지만 현재 무선 네트워크에서 실패한다면 해당 네트워크의 외부 연결 제한, 주소 체계 지원, 방화벽을 확인하세요. 모든 네트워크에서 실패하면 설정과 원격 서비스를 다시 살펴봐야 합니다. 네트워크를 바꾼 뒤에는 연결을 새로 설정하고 이전 네트워크의 세션을 재사용하지 마세요. 노드 도메인이 여러 주소 체계의 주소를 반환할 때 일부 주소는 조회되지만 연결할 수 없어 지연이 발생할 수 있습니다. 실제로 연결을 시도한 주소를 확인한 다음 주소 선택 방식을 조정하세요.

TUN을 켠 뒤에만 시간 초과가 발생한다면 노드 서버로 향하는 트래픽이 다시 프록시로 전달되어 순환 경로가 생겼을 수 있습니다. 노드 서버 주소가 올바르게 제외되어 있는지, 클라이언트가 해당 주소에 직접 연결하는 경로를 관리하는지 확인하세요. 구독 주소나 노드 도메인의 DNS 조회가 아직 설정되지 않은 프록시 아웃바운드에 의존해 시작 단계에서 순환 참조가 생길 수도 있습니다. TUN을 끄고 일반 네트워크로 DNS 조회와 구독 업데이트를 진행한 다음 설정을 하나씩 복원하면 이런 문제와 실제 원격 연결 불가를 구분하는 데 도움이 됩니다.

마지막으로 노드 연결과 실제 서비스 접속을 따로 확인하세요. 클라이언트의 테스트 주소에 문제가 있으면 정상 노드 여러 개가 모두 실패로 표시될 수 있습니다. 실제 웹페이지에 접속된다면 모든 노드를 바로 삭제하지 말고 테스트 주소와 테스트 방식을 확인하세요. 오류가 발생한 시간, 사용한 네트워크, 오류 유형을 기록하고 서비스 제공업체에 문의할 때는 접속 정보를 가리세요. 인증서 문제는 TLS 핸드셰이크 및 인증서 오류 해결도 참고하세요. 수정 후에는 원래 라우팅과 실행 모드로 되돌려 확인합니다.

구독 실패: 다운로드, 파싱, 노드 업데이트 구분하기

구독을 가져오는 과정은 주소 저장, 구독 콘텐츠 다운로드, 콘텐츠를 노드 목록으로 변환하는 세 단계입니다. 링크를 저장했다고 해서 다운로드에 성공한 것은 아니며, 텍스트를 내려받았다고 해서 클라이언트가 노드 형식으로 파싱할 수 있는 것도 아닙니다. 먼저 어느 단계에서 오류가 발생했는지, 업데이트 후 목록이 실제로 바뀌었는지 확인하세요. 기존 노드는 연결되지만 구독 업데이트가 실패한다면 사용 가능한 설정을 보존하고 업데이트 경로부터 복구하세요. 점검에 필요한 연결 경로를 잃지 않도록 노드 전체를 삭제하지 않는 것이 좋습니다.

먼저 주소와 서비스 상태 확인하기

구독 그룹 설정에서 전체 주소를 확인하세요. 복사 과정에서 줄바꿈, 앞뒤 공백, 전각 문장부호가 섞이지 않았는지 특히 주의합니다. 일부 주소에는 쿼리 매개변수나 액세스 토큰이 있으므로 물음표 앞의 경로만 남기거나 문자를 임의로 수정하면 안 됩니다. 브라우저에서 열리는 관리 페이지와 구독 API 주소는 다를 수 있으니 서비스 제공업체가 구독용으로 명시한 주소를 사용하세요. 링크 만료, 계정 상태 변경, 액세스 토큰 재설정으로 기존 주소가 오류 페이지를 반환할 수 있습니다.

응답 유형을 보면 문제를 좁히는 데 도움이 됩니다. 인증 실패나 접근 금지는 인증 정보, 계정 권한, 서비스 정책과 관련된 경우가 많습니다. 리소스를 찾을 수 없으면 경로가 바뀌었을 수 있고, 요청 제한이 걸리면 업데이트 빈도를 낮추고 허용되는 시간까지 기다려야 합니다. 서버의 일시적인 오류를 해결하려고 노드 비밀번호를 바꾸지는 마세요. 응답 상태가 성공처럼 보여도 로그인 페이지나 안내 문구를 받은 것일 수 있으니 클라이언트 파싱 오류를 확인해 실제로 구독 데이터가 내려왔는지 살펴보세요.

‘구독은 프록시가 필요하고, 프록시는 구독이 필요함’ 문제 해결하기

일부 구독 주소는 현재 네트워크에서 직접 접속할 수 없어 이미 사용 가능한 프록시로 업데이트해야 합니다. 이 경우 클라이언트에서 프록시를 통한 업데이트를 선택하고 현재 노드가 실제로 연결되는지 확인하세요. 클라이언트를 막 설치해 노드 목록이 비어 있다면 사용할 아웃바운드가 없어 프록시를 통한 업데이트에 실패합니다. 서비스 제공업체가 제공한 단일 노드 설정으로 먼저 연결한 뒤 구독을 업데이트하세요. 별도로 사용할 수 있는 설정이 없다면 서비스 제공업체에 접속 가능한 구독 주소를 문의하고, 작동하지 않는 노드를 계속 바꾸지는 마세요.

반대로 직접 연결할 수 있던 구독 주소를 프록시로 업데이트할 때 실패한다면 프록시 측 DNS, 인증서 또는 외부 연결 제한이 원인일 수 있습니다. 같은 주소에 직접 업데이트와 프록시를 통한 업데이트를 각각 시도하고 결과를 기록하세요. 한 방식에서만 실패한다면 다운로드 경로를 원인으로 좁힐 수 있습니다. 브라우저에서는 열리지만 클라이언트에서는 실패할 경우 브라우저가 다른 프록시, 로그인 세션 또는 자동 리디렉션을 사용하는지도 확인하세요. 브라우저의 계정 상태가 클라이언트의 구독 요청에 전달되지 않을 수 있습니다.

네트워크 시간 초과와 파싱 실패 구분하기

v2rayN, v2rayNG, v2flyNG가 지원하는 프로토콜과 설정 형식은 각각의 구현과 사용 중인 코어에 따라 다릅니다. 서비스 제공업체가 클라이언트별로 다른 구독 주소를 제공할 수 있으며, 다른 형식의 설정 파일을 다운로드하면 내용이 온전해도 가져오지 못할 수 있습니다. 먼저 구독 주소가 현재 클라이언트용인지 확인하고, 형식을 인식하지 못하는지 일부 노드가 지원되지 않는지 전체 콘텐츠가 비어 있는지 살펴보세요. 지원되지 않는 항목을 발견해도 가져오기를 위해 보안 매개변수를 임의로 삭제하지 마세요. 기존 연결의 의미가 달라질 수 있습니다.

업데이트가 성공했는데도 새 노드가 보이지 않으면 현재 선택된 구독 그룹, 검색 필터, 정렬 조건을 확인하세요. 업데이트 과정에서 노드 ID가 바뀌면 기존에 선택한 노드가 사라질 수 있으므로 다시 선택하고 적용해야 합니다. 노드 이름이 그대로라고 해서 서버 주소와 매개변수가 바뀌지 않았다는 뜻은 아닙니다. 설정 세부 정보를 비교하세요. 일부 노드만 남았다면 프로토콜 지원 차이나 구독 서비스의 응답 내용이 달라졌는지 먼저 확인한 뒤 클라이언트에서 데이터가 손실되었는지 판단하세요.

업데이트 빈도를 조절하고 실제 결과 확인하기

업데이트 버튼을 연속으로 누르는 것을 재시도 방법으로 삼지 마세요. 요청이 잦으면 서비스의 요청 제한에 걸릴 수 있고, 로그를 특정 작업과 연결하기도 어려워집니다. 먼저 자동 업데이트를 일시 중지하고 수동으로 한 번 요청한 뒤 시간, 다운로드 경로, 오류를 기록하고 원인을 해결하세요. 자동 업데이트를 다시 켤 때는 적절한 간격을 설정하고 여러 기기에서 같은 주소로 짧은 시간 동안 요청을 반복하지 않도록 합니다. 네트워크가 복구된 직후에는 노드 연결을 먼저 확인한 다음 구독을 업데이트하면 실패 요청이 겹치는 일을 줄일 수 있습니다.

복구 후에는 그룹 업데이트 성공 여부, 노드 선택 가능 여부, 코어의 새 설정 로드를 확인하고 실제 연결도 테스트하세요. 구독은 보통 노드를 동기화하지만 데스크톱과 Android의 라우팅, DNS, 앱별 분할, TUN 설정까지 동일하게 맞춰 주지는 않습니다. 컴퓨터에서 업데이트에 성공해도 휴대폰에서의 확인을 대신할 수 없습니다. 기기 간 동기화 범위는 v2rayN과 v2rayNG의 멀티 디바이스 설정 동기화를 참고하세요. 사용 가능한 설정은 안전한 곳에 백업하되 인증 정보가 포함된 내보내기 파일을 공개 폴더에 두지 마세요.

속도 저하: 연결 설정 지연과 전송 속도 저하 구분하기

속도 문제는 크게 세 가지로 나타납니다. 페이지를 처음 열 때 오래 기다리는 경우, 전송을 시작한 뒤 계속 느린 경우, 연결이 간헐적으로 멈췄다가 복구되는 경우입니다. 각각 DNS와 핸드셰이크, 지속 대역폭과 혼잡, 네트워크 전환이나 패킷 손실이 원인일 수 있습니다. 측정 결과 하나만 기록하기보다 실제 증상을 먼저 설명하세요. 작은 파일은 빠르지만 큰 파일은 느린 경우와 모든 사이트를 처음 열 때 느린 경우는 점검 경로가 다릅니다. 노드 성능 차이와 대상 서버 차이를 혼동하지 않도록 같은 노드, 같은 대상, 같은 기기에서 테스트하세요.

조건을 고정해 재현 가능한 비교 만들기

네트워크를 사용하는 동기화, 다운로드, 시스템 업데이트를 종료하고 기존 작업을 다시 테스트하세요. 무선 네트워크에서는 액세스 포인트 가까이에서 비교하고, 가능하다면 유선과 무선 연결도 비교합니다. 일반 직접 연결도 느리다면 로컬 네트워크부터 해결해야 합니다. 프록시 연결만 느리다면 같은 네트워크에서 사용할 수 있는 노드 두 개를 비교하세요. 노드와 DNS, 라우팅을 동시에 바꾸면 문제가 해결되어도 어떤 변경이 효과가 있었는지 알기 어렵습니다.

테스트 대상도 동일하게 유지하세요. 다운로드 사이트마다 단일 연결 속도를 제한할 수 있고 웹페이지의 외부 리소스가 서로 다른 네트워크에 있을 수도 있습니다. 속도 테스트 하나로 동영상, 회의, 파일 다운로드 전체 성능을 판단할 수는 없습니다. 순간 최고 속도보다 첫 응답까지 걸리는 시간, 전송 중 속도 유지 여부, 재연결이 반복되는지를 기록하는 편이 실용적입니다. 같은 노드도 시간대에 따라 성능이 달라질 수 있으므로 네트워크 혼잡 여부를 확인하려면 비슷한 조건에서 반복해서 관찰하세요. 곧바로 클라이언트를 재설치할 필요는 없습니다.

처음 접속할 때 느리다면 DNS, 핸드셰이크, 재시도 확인하기

페이지를 처음 열 때 느리지만 다시 방문하면 빨라지는 경우 DNS 조회 시간, 주소 선택, 연결 재사용을 먼저 살펴보세요. 노드 도메인이나 대상 도메인에 여러 주소가 있으면 클라이언트가 연결할 수 없는 주소를 먼저 시도하고 실패를 기다린 뒤 다른 주소로 전환할 수 있습니다. 로그에 반복된 연결 시도, 핸드셰이크 실패, DNS 시간 초과가 기록되는지 확인하세요. 시스템 시간, 전송 매개변수, DNS 경로를 살펴보고 계속 재시도해야만 우연히 연결되는 상태가 아닌지 확인합니다.

대부분의 페이지 콘텐츠는 빠른데 이미지, 글꼴, 스크립트가 계속 로드되지 않는다면 리소스 도메인이 다른 아웃바운드로 라우팅되거나 차단 규칙이 페이지 리소스에 영향을 주는 것일 수 있습니다. 브라우저 개발자 도구의 네트워크 탭에서 실패한 리소스의 도메인을 확인하고 클라이언트 로그와 비교하세요. 사이트 전체를 노드 속도 문제로 단정하지 마세요. 라우팅을 잠시 단순화했을 때 해결된다면 규칙 순서와 규칙 세트를 하나씩 확인합니다. 구체적인 도메인 규칙은 더 포괄적인 규칙보다 앞에 두어 먼저 일치하도록 해야 합니다.

지속적인 전송 속도 저하: 네트워크 혼잡, 기기 리소스, 전송 조건 확인하기

전송을 시작한 뒤 속도가 안정적으로 느리다면 먼저 기기의 프로세서, 메모리, 디스크 사용량이 한계에 가까운지 확인하세요. 백그라운드 연결이 많거나 로그 수준이 지나치게 상세한 경우, 실시간 검사나 절전 모드도 처리 부담을 높일 수 있습니다. 모바일 기기는 발열 후 성능이 낮아져 같은 연결도 점점 느려질 수 있습니다. 데스크톱에서는 일반 전원 모드로 다시 테스트하고 Android에서는 온도와 백그라운드 작업도 확인하세요. 최적화 옵션을 무작정 여러 개 추가하기보다 불필요한 동시 연결을 줄이는 편이 결과를 이해하기 쉽습니다.

TUN 모드에서만 대용량 파일 전송이 멈추고 시스템 프록시 모드에서는 정상이라면 가상 네트워크 어댑터 경로, MTU, 추가 캡슐화를 확인하세요. 작은 패킷은 통과하지만 큰 패킷을 처리하지 못하면 연결은 성립해도 전송이 멈출 수 있습니다. 온라인에서 찾은 고정 MTU 값을 그대로 적용하지 마세요. 먼저 두 모드를 비교해 가상 네트워크 경로에서 문제가 발생하는지 확인한 뒤 클라이언트 설정을 조금씩 조정하고 필요하면 되돌릴 수 있도록 한 다음 실제 작업으로 재검증하세요.

프로토콜 이름만으로 속도가 결정되지는 않습니다. VMess, VLESS, Trojan, Shadowsocks의 성능은 전송 조합, 서버 부하, 네트워크 경로에 따라 달라집니다. 서버에서 지원하는 설정과 맞지 않는 프로토콜로 바꾸는 것만으로는 성능을 개선할 수 없습니다. 먼저 프록시 프로토콜 차이와 사용 상황을 읽어 매개변수의 범위를 이해한 뒤 서비스 제공업체가 지원하는 조합을 선택하세요. 수정 후에는 자주 사용하는 서비스뿐 아니라 라우팅 변경으로 직접 연결 서비스가 느려지지 않았는지도 확인해야 합니다.

DNS 문제: 시스템·코어·프록시 측 DNS 조회 구분하기

DNS는 도메인을 IP 주소로 변환하지만 프록시 환경에서는 모든 조회가 한 곳에서 이루어지지 않습니다. 앱이 로컬에서 먼저 조회한 뒤 IP를 프록시에 전달할 수도 있고, 도메인을 SOCKS 또는 HTTP 프록시에 넘겨 코어나 원격 서버에서 조회할 수도 있습니다. TUN은 시스템의 DNS 요청을 가로챌 수도 있습니다. 따라서 시스템 명령으로 주소를 찾을 수 있다는 사실은 해당 조회 경로가 동작한다는 의미일 뿐, 브라우저·코어·원격 측 경로도 정상이라는 뜻은 아닙니다. 문제를 해결하기 전에 어떤 도메인에서 실패했는지, 어느 계층에서 조회했는지 확인하세요.

노드 도메인과 대상 도메인을 따로 확인하기

노드 서버가 도메인을 사용하는 경우 클라이언트는 먼저 노드 주소를 조회해야 합니다. 프록시 연결이 성립한 뒤에야 대상 웹사이트에 접속할 수 있습니다. 두 조회는 서로 다른 작업입니다. 로그에서 노드 도메인을 찾지 못했다면 대상 웹사이트의 라우팅을 변경하지 말고 시작 단계에서 사용되는 DNS를 먼저 확인하세요. 대상 도메인 조회에 실패했다면 앱이 도메인을 전달하는지, 코어에 관련 DNS 설정이 있는지, 선택한 DNS 서버에 예상한 아웃바운드로 접속할 수 있는지 살펴보세요.

Windows, macOS, Linux에서는 필요한 도구가 설치된 터미널에서 아래 조회 명령으로 기본 비교를 할 수 있습니다. 출력 여부만 보지 말고 반환된 주소, 사용한 DNS 서버, 오류 유형을 확인하세요. 시스템 조회는 성공하지만 프록시 접속이 실패하면 코어 로그를 함께 살펴봅니다. 조회 결과가 캐시에서 제공될 수 있으므로 설정을 바꾼 뒤에는 새 요청이 실제로 새로운 DNS 경로를 사용하는지 확인하세요. 페이지를 반복해서 새로고침해도 브라우저가 저장한 이전 결과를 계속 사용할 수 있습니다.

nslookup example.com

프록시 테스트로 로컬 DNS와 프록시 측 DNS 구분하기

SOCKS 테스트에서 socks5는 보통 curl이 대상 도메인을 로컬에서 조회하고, socks5h는 도메인을 프록시 측에 전달합니다. 같은 대상에 각각 테스트하면 로컬 DNS가 문제에 영향을 주는지 파악할 수 있습니다. 이때도 실제 SOCKS 포트로 바꾸세요. 한 방식이 성공했다고 다른 방식을 계속 꺼야 한다는 뜻은 아닙니다. 두 경로가 다르게 동작한다는 의미이므로 라우팅 요구사항과 앱 동작을 고려해 최종 방식을 선택하세요.

curl --proxy socks5://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com

프록시 측 DNS는 정상이고 로컬 DNS 조회만 실패한다면 시스템 DNS, 브라우저의 보안 DNS, 네트워크에서 제공하는 DNS 서비스를 확인하세요. 두 경로가 모두 실패하더라도 로그의 오류가 다르면 각각 처리해야 하며 여러 설정을 한 번에 바꾸면 안 됩니다. 브라우저가 자체 암호화 DNS를 사용하면 시스템 DNS를 바꿔도 영향을 받지 않을 수 있습니다. 반대로 브라우저 조회가 정상이라고 다른 앱까지 정상인 것은 아닙니다. 비교를 위해 브라우저가 시스템 설정을 따르도록 잠시 바꾸고 원인을 확인한 뒤 필요에 맞게 원래 설정으로 되돌리세요.

라우팅의 도메인 조회 정책 이해하기

domainStrategy는 라우팅 규칙을 검사할 때 도메인을 IP로 변환할지 여부에 영향을 줍니다. V2Ray 계열 코어에서 AsIs, IPIfNonMatch, IPOnDemand는 각각 목적이 다르며 단순한 성능 단계로 보면 안 됩니다. 아래는 라우팅 일부이며 바로 실행할 수 있는 전체 설정이 아닙니다. direct, proxy, block이라는 아웃바운드가 이미 있고 관련 규칙 데이터도 있다는 전제입니다. GUI 클라이언트에서는 생성된 전체 설정을 직접 덮어쓰지 말고 라우팅 설정 화면을 통해 입력하세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

명확한 마지막 일치 규칙이 있을 때 이후 DNS 조회 동작은 규칙 순서와 코어 구현에도 영향을 받습니다. 특정 정책을 선택했다고 모든 요청에 IP 매칭이 반드시 적용되는 것은 아닙니다. 수정 후에는 설정 이름만 보지 말고 실제 로그를 확인하세요. 광고 도메인 규칙, 로컬 네트워크 IP 규칙, 지역별 도메인 규칙은 각각 다른 정보를 사용합니다. 규칙 세트가 없거나 카테고리 이름을 사용할 수 없으면 설정 로드가 실패할 수도 있습니다. 규칙 순서에 관한 자세한 내용은 geosite 및 geoip 라우팅 설정 실전 가이드를 참고하세요.

DNS 순환 참조를 피하고 가상 주소를 신중하게 다루기

암호화 DNS 서버도 네트워크 연결이 필요합니다. DNS 서버 연결에 프록시가 필요한데 노드 주소 조회도 그 DNS 서버에 의존하면 순환 참조가 발생할 수 있습니다. 시작에 필요한 DNS 조회 경로를 확보하고 DNS 요청이 예상한 아웃바운드로 나가는지 확인하세요. 가상 주소 매핑에서는 시스템이 반환하는 주소가 실제 서버 주소가 아닐 수 있으며 이는 정상 동작의 일부입니다. 다만 클라이언트를 종료한 뒤 라우팅이 남거나 오래된 캐시가 유지되거나 로컬 네트워크 도메인이 잘못 매핑되면 앱이 대상에 연결되지 않을 수 있습니다.

복구할 때는 먼저 가장 단순한 DNS 설정으로 되돌리고 충돌하는 DNS 가로채기 기능을 끈 다음 하나씩 추가하세요. 로컬 네트워크 호스트 이름, 프린터, 내부 서비스는 보통 로컬 DNS가 필요하므로 모두 원격으로 보내지 않는 것이 좋습니다. 변경할 때마다 노드 도메인, 프록시 대상, 직접 연결 대상, 로컬 네트워크 이름을 테스트해 네 가지 요구가 모두 정상인지 확인하세요. fake DNS, 도메인 정책, 규칙 세트의 의미는 용어 빠른 참조에서 확인할 수 있습니다. 특정 사이트를 열기 위해 전체 DNS 로직을 망가뜨리지 않도록 주의하세요.

시스템 프록시가 작동하지 않을 때: 앱 연결 경로와 TUN 범위 확인하기

시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정이지 모든 연결을 강제로 가로채는 기능은 아닙니다. 시스템 설정을 따르는 브라우저는 보통 이를 사용하지만 명령줄 프로그램, 일부 게임, 자체 네트워크 스택을 사용하는 소프트웨어는 무시할 수 있습니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 가로채며 적용 범위가 다른 대신 권한, 라우팅, DNS 등의 조건이 추가됩니다. 앱이 시스템 프록시를 사용하지 않을 때는 앱의 네트워크 동작을 먼저 확인하세요. 시스템 프록시가 켜져 있다고 모든 트래픽이 코어로 들어간다고 단정해서는 안 됩니다.

시스템에 실제로 저장된 설정 확인하기

v2rayN에서 시스템 프록시를 켠 뒤 운영체제의 네트워크 설정을 열어 프록시 주소와 포트가 현재 클라이언트의 로컬 HTTP 또는 혼합 인바운드로 바뀌었는지 확인하세요. 주소는 보통 루프백 주소지만 포트는 실제 설정값이어야 합니다. 코어의 수신 포트를 변경했는데 시스템 프록시가 이전 포트를 가리키면 시스템 설정을 따르는 앱이 모두 실패할 수 있습니다. 시스템에 수동 프록시가 아니라 자동 설정 스크립트가 표시된다면 현재 어떤 방식을 사용하는지 확인해 두 설정이 서로 덮어쓰지 않게 하세요.

브라우저 프록시 확장 프로그램, 다른 프록시 도구, 기기 관리 정책처럼 프록시 설정을 변경할 수 있는 다른 소프트웨어를 종료하거나 확인하세요. 회사나 관리 대상 기기의 프록시 설정은 정책으로 고정될 수 있으며 클라이언트가 바꾸더라도 원래 값으로 돌아갈 수 있습니다. 이 경우 기기 관리 규정을 따르고 시스템 설정을 계속 덮어쓰지 마세요. 일반 개인 기기라면 기능을 켜기 전후의 값이 바뀌는지 확인해 v2rayN이 현재 사용하는 네트워크 환경을 수정하는지 살펴보세요. 이미 연결이 끊긴 네트워크 설정을 바꾸고 있는 것은 아닌지도 확인해야 합니다.

앱 로그로 프록시 경유 여부 확인하기

새 요청을 보내고 클라이언트 연결 기록을 확인하세요. 기록이 없다면 앱 자체 프록시 설정을 확인합니다. 기록은 있지만 아웃바운드가 direct라면 시스템 프록시는 작동했지만 라우팅에서 직접 연결을 선택했을 수 있습니다. 외부 IP 확인 페이지의 결과도 한계가 있습니다. 해당 페이지가 직접 연결 규칙에 일치한다면 결과가 바뀌지 않아도 프록시가 실패했다는 뜻은 아닙니다. 요청이 코어에 들어갔는지와 어떤 아웃바운드가 선택되었는지를 함께 확인한 뒤 연결 경로 문제인지 규칙 문제인지 판단하세요.

터미널 프로그램은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY의 영향을 받는 경우가 많습니다. 앱에 따라 소문자 형식만 인식하거나 일부 변수만 지원할 수 있습니다. 문제를 확인할 때는 먼저 명령에 프록시를 직접 지정해 로컬 인바운드가 작동하는지 확인한 다음 환경 변수를 살펴보세요. NO_PROXY에 대상 도메인이나 네트워크 대역이 포함되어 있으면 요청이 프록시를 우회합니다. 변수를 바꾼 뒤에는 앱이나 터미널을 다시 시작해야 할 수 있으며 기존 프로세스는 새 값을 읽지 않을 수 있습니다.

TUN 실행 실패와 실행 후 문제를 나눠서 해결하기

TUN을 시작할 수 없다면 권한, 가상 네트워크 어댑터 생성, 라우팅 설정 오류가 로그에 있는지 먼저 확인하세요. 데스크톱 운영체제에서는 권한을 높이거나 네트워크 구성 요소를 허용해야 할 수 있지만 시스템 보호 기능을 계속 꺼 두지는 마세요. 로그에 표시된 거부 작업만 구체적으로 처리하세요. 코어가 실행되었더라도 가상 네트워크 어댑터 생성에 실패하면 TUN이 정상적으로 작동하지 않을 수 있습니다. 클라이언트 모드, 어댑터 상태, 로그에 시작 기록이 있는지 확인하세요.

TUN을 시작한 뒤 인터넷이 끊기면 먼저 TUN을 끄고 시스템 프록시로 같은 노드를 테스트하세요. 시스템 프록시는 정상이라면 라우팅, DNS 가로채기 또는 다른 가상 네트워크 어댑터가 원인일 가능성이 높습니다. 여러 VPN이나 가상 네트워크 도구를 동시에 실행하면 기본 라우팅이 계속 바뀔 수 있습니다. 노드 서버 트래픽에는 올바른 외부 연결 경로가 필요하며 로컬 네트워크에도 적절한 제외 규칙이 있어야 합니다. 모든 제외 항목을 지우면 노드 연결과 로컬 서비스까지 함께 가로챌 수 있으니 주의하세요.

종료 후 네트워크 복구하기: 되돌릴 수 있는 경로 유지하기

클라이언트가 비정상 종료되면 시스템 프록시가 이미 닫힌 로컬 포트를 계속 가리킬 수 있습니다. 이때 브라우저는 실패하지만 프록시를 지정하지 않은 직접 연결 테스트는 정상이라면 중요한 단서입니다. 시스템 프록시 설정에서 남아 있는 항목을 지우고 TUN의 가상 네트워크 어댑터나 라우팅이 남아 있는지도 확인하세요. 일반적인 경우에는 네트워크 어댑터를 바로 삭제하기보다 정상적으로 종료하고 클라이언트를 다시 시작한 뒤 프록시를 끄는 편이 안전합니다. 네트워크 설정을 직접 변경하기 전에는 특히 관리 대상 네트워크의 원래 값을 기록하세요.

마지막으로 브라우저, 터미널, 시스템 프록시를 따르지 않는 앱 하나를 각각 테스트하세요. 한 종류의 프로그램만 확인하고 해결되었다고 판단하지 마세요. 로컬 네트워크 기기와 직접 연결 대상에 접속할 수 있는지, 클라이언트를 종료한 뒤 일반 네트워크가 복구되는지도 확인해야 합니다. 앱별 프록시와 TUN은 각각 적용 범위가 다르므로 요구사항을 만족하면서 변수는 적은 방식을 우선 선택하세요. 기본 설정은 빠른 시작 가이드에서 확인하고, 문제를 해결하는 동안 새 라우팅 템플릿과 새 트래픽 가로채기 모드를 동시에 추가하지 마세요.

클라이언트 충돌: GUI 종료, 코어 종료, 설정 오류 구분하기

클라이언트 창이 갑자기 닫히거나 창은 남아 있는데 인터넷이 되지 않거나 시작 버튼을 누른 직후 중단되는 경우는 각각 다른 문제입니다. v2rayN의 GUI와 프록시 코어는 서로 다른 구성 요소입니다. GUI가 정상이라고 코어가 실행 중인 것은 아니며 코어가 종료되어도 창이 닫히지 않을 수 있습니다. 먼저 문제가 발생한 조건을 기록하세요. 시작 직후인지, 특정 노드를 가져온 뒤인지, TUN을 켠 뒤인지, 일정 시간 실행한 뒤인지 확인합니다. 동일한 한 가지 작업으로 문제를 재현할 수 있다면 원인을 찾기 위한 좋은 출발점입니다.

설정과 로그를 보존한 뒤 설치 복구하기

GUI를 열 수 있다면 먼저 클라이언트 기능으로 필요한 설정을 내보내고 현재 구독 그룹, 라우팅 모드, DNS 설정을 기록하세요. 백업에는 접속 정보가 들어 있을 수 있으므로 안전한 위치에 보관해야 합니다. GUI를 열 수 없더라도 사용자 데이터 폴더를 바로 삭제하지 마세요. 먼저 폴더 사본을 보관한 뒤 시작 로그나 운영체제의 앱 오류 기록을 확인하세요. 로그를 복사해 도움을 요청할 때는 서버 인증 정보, 구독 주소, 사용자 경로 등 불필요한 민감 정보를 제거하세요.

재설치하기 전에 다운로드 페이지에서 운영체제와 프로세서 아키텍처를 확인하세요. Windows용 v2rayN 데스크톱 버전과 클래식 WPF 버전은 진입 화면이 다르므로 한 버전의 프로그램 파일을 다른 버전 파일과 섞지 마세요. macOS에서는 칩에 맞는 설치 파일을 선택하고 Linux에서는 프로세서 아키텍처와 배포판 패키지 형식을 함께 확인하세요. 운영체제에서 종속 항목이 없다고 표시되면 오류에 명시된 공식 실행 환경을 설치하세요. 출처가 불분명한 팝업에서 복구 구성 요소를 받지 마세요.

GUI가 갑자기 종료될 때 시작 오류와 리소스 문제 확인하기

시작 직후 종료된다면 운영체제가 앱 실행을 차단했는지, 설치가 완료되었는지, 사용자 데이터 폴더에 쓸 수 있는지 확인하세요. macOS에서는 앱을 적절한 응용 프로그램 폴더로 옮긴 뒤 시스템 보안 알림을 처리해야 합니다. Linux에서는 설치된 프로그램을 그래픽 터미널에서 실행해 표준 오류 출력을 확인하고 데스크톱 세션에 필요한 구성 요소도 점검하세요. 경로 권한이나 종속 항목 문제에는 구체적인 단서가 있어야 합니다. 모든 오류를 감추기 위해 관리자 권한으로 계속 실행하지 마세요.

일정 시간 실행한 뒤 충돌한다면 연결 수가 많을 때, 로그가 쌓였을 때, 절전 모드에서 복귀했을 때, 화면 환경이 바뀌었을 때 발생하는지 살펴보세요. 저장 공간과 메모리 사용량을 확인하고 불필요하게 상세한 로그를 줄인 뒤 같은 작업으로 다시 테스트합니다. 기기가 절전 모드에서 깨어나면 네트워크 인터페이스가 달라질 수 있으니 앱을 재설치하기보다 먼저 연결을 다시 설정하세요. 특정 화면 조작에서만 문제가 생긴다면 연결을 유지하기 위해 해당 조작을 잠시 피하고 절차를 기록하세요. 일시적인 시스템 문제를 모든 노드 설정의 손상으로 오해하지 않도록 합니다.

코어가 바로 종료되면 첫 설정 오류부터 확인하기

설정 로드 실패 로그에는 문제 필드, 아웃바운드 태그, 규칙 데이터, 수신 포트가 표시되는 경우가 많습니다. 로그에서 가장 먼저 발생한 실제 오류부터 해결하세요. 이후 이어지는 여러 오류는 처음 문제로 인한 연쇄 오류일 수 있습니다. 포트가 사용 중이라면 어떤 프로그램이 점유하고 있는지 확인하고 중복 실행된 클라이언트를 종료하거나 로컬 인바운드 포트를 변경한 뒤 시스템 프록시에도 반영하세요. 코어를 실행하려고 라우팅 규칙을 전부 삭제하지 마세요. 규칙 데이터 누락과 잘못된 아웃바운드 이름은 각각 따로 해결해야 합니다.

특정 노드를 선택했을 때만 코어가 종료되면 해당 프로토콜과 코어의 지원 여부를 확인하세요. v2rayNG는 주로 Xray 코어를 사용하고 v2flyNG는 V2Fly 코어를 사용하므로 지원 기능이 완전히 같지 않습니다. v2rayN에서 코어를 바꾸더라도 지원하지 않는 조합이 자동으로 호환되지는 않습니다. 노드, 전송 방식, 코어가 서로 맞는지 확인하고 필요하다면 유효한 구독에서 다시 가져오세요. 특히 REALITY처럼 연결에 필요한 필드를 로드 오류를 피하려고 삭제하지 마세요. 코어가 시작된다고 올바르게 연결되는 것은 아닙니다.

최소 설정으로 문제 범위 좁히기

백업을 보관한 뒤 사용할 수 있는 노드 하나, 기본 라우팅, 기본 DNS만 포함한 비교 환경을 만드세요. TUN, 복잡한 규칙, 사용자 지정 설정은 잠시 끕니다. 최소 환경이 정상이라면 구독 그룹, 라우팅, DNS, 트래픽 가로채기 기능을 하나씩 복원하고 매번 다시 테스트합니다. 이렇게 하면 특정 설정 계층으로 문제를 좁힐 수 있습니다. 테스트 환경과 기존 환경이 같은 포트에서 동시에 수신 대기하지 않도록 하고, 두 인스턴스가 시스템 프록시 설정을 서로 변경하지 않게 하세요.

복구 후 정상 종료와 재시작을 진행한 다음 구독, 노드, 시스템 프록시, TUN의 실제 상태를 확인하세요. 재설치만으로 복구되지만 이전 설정을 다시 가져오면 문제가 반복된다면 설치 프로그램보다 설정이 원인일 가능성이 높습니다. 코어와 클라이언트의 관계는 사이트 소개 및 Project V 생태계 안내를 참고하세요. 문제를 알릴 때 운영체제, 아키텍처, 클라이언트 이름, 재현 단계, 민감 정보를 제거한 오류 내용을 제공하면 전체 설정을 공유하는 것보다 안전하고 재현하기도 쉽습니다.

Android 연결 문제: VPN 권한, 앱별 분할, 백그라운드 제한 확인하기

Android용 v2rayNG와 v2flyNG는 시스템 VPN 인터페이스를 통해 트래픽을 처리하므로 데스크톱 시스템 프록시와는 점검 방식이 다릅니다. 상태 표시줄에 VPN 아이콘이 보이는 것은 시스템 인터페이스가 생성되었다는 뜻일 뿐 원격 노드에 연결되었다는 의미는 아닙니다. 먼저 사용할 수 있는 노드를 선택하고 시작 권한을 승인한 다음 브라우저에서 요청을 보내 클라이언트 로그를 확인하세요. 실행 직후 중단되면 권한, 설정 로드, 다른 VPN과의 충돌부터 확인합니다. 계속 실행되는데도 인터넷이 되지 않으면 노드, DNS, 라우팅 순서로 점검하세요.

시스템 권한과 VPN 사용 상태 확인하기

처음 연결할 때는 보통 시스템 VPN 요청을 승인해야 합니다. 권한 창을 취소했거나 다른 창에 가려졌거나 기기 정책이 VPN을 제한하면 클라이언트가 인터페이스를 만들지 못할 수 있습니다. 시스템 VPN 설정에서 현재 활성화된 연결을 확인하고 트래픽을 가로채는 다른 VPN 앱은 종료하세요. 로컬 필터링 도구 일부도 같은 인터페이스를 사용하므로 프록시와 무관해 보여도 충돌이 생길 수 있습니다. 먼저 트래픽을 가로채는 앱 하나만 남겨 비교한 뒤 일상적으로 앱을 사용할 순서를 결정하세요.

시스템에서 상시 연결 VPN 또는 VPN을 거치지 않는 연결 차단이 설정되어 있는지 확인하세요. 이미 비활성화된 다른 앱을 지정해 두면 일반 네트워크에도 접속할 수 없게 될 수 있습니다. 현재 클라이언트가 비정상 종료되었는데 직접 연결 차단 정책이 유지되어도 기기 전체가 오프라인처럼 보일 수 있습니다. 설정을 변경하기 전에 기능을 이해하고 테스트가 끝나면 사용 목적에 맞게 복구하세요. 모든 제한을 영구적으로 끄지 마세요. 관리 대상 기기에서는 관리자 정책을 따라야 하며 권한 제한을 해결하려고 앱을 반복해서 재설치하지 마세요.

일부 앱만 실패한다면 앱별 분할 목록 확인하기

앱별 분할에는 선택한 앱만 프록시를 사용하도록 하는 방식과 선택한 앱을 우회시키는 방식이 있습니다. 같은 목록이라도 모드가 다르면 결과가 완전히 달라집니다. 먼저 현재 모드를 확인한 뒤 실패한 앱이 목록에 있는지 살펴보세요. 시스템 구성 요소, 업무 프로필의 앱, 개인 앱은 각각 트래픽을 가로채는 범위가 다를 수 있습니다. 브라우저는 정상인데 다른 앱만 실패한다면 바로 노드를 바꾸지 말고 해당 앱의 요청이 클라이언트 로그에 들어오는지 먼저 확인하세요.

앱 트래픽이 VPN에 들어간 뒤에도 도메인 및 IP 라우팅 규칙을 거칩니다. 앱 목록은 트래픽을 가로챌지 결정하고 라우팅은 가로챈 뒤 어떤 아웃바운드로 보낼지 결정하므로 서로 대체할 수 없습니다. 일부 앱은 자체 DNS, 고정 IP, 장시간 연결을 사용해 브라우저와 다르게 동작합니다. 라우팅을 변경한 뒤에는 기존 연결이 이전 경로를 계속 사용하지 않도록 앱을 완전히 종료하고 다시 실행하세요. 로컬 네트워크 기기에 접속할 수 없다면 모든 대상을 강제로 프록시에 보내기보다 로컬 네트워크 직접 연결 규칙과 앱별 가로채기 설정을 확인하세요.

화면이 꺼진 뒤 연결이 끊기면 배터리 및 백그라운드 정책부터 확인하기

화면이 켜져 있을 때는 정상이고 꺼진 뒤 실패한다면 백그라운드 제한이 원인일 가능성이 큽니다. 시스템 배터리 관리에서 클라이언트의 백그라운드 실행이 허용되어 있는지 확인하고 절전 모드, 백그라운드 데이터 제한, 기기 제조사의 작업 종료 설정도 살펴보세요. 기기마다 메뉴 이름이 다르므로 기능을 기준으로 찾으세요. 설정을 바꾼 뒤 같은 화면 꺼짐 상태를 재현하고 연결이 유지되는지 확인합니다. 화면이 켜져 있을 때만 테스트해서는 백그라운드 문제가 해결됐다고 판단할 수 없습니다.

프로세스 종료와 일시적인 네트워크 중단도 구분하세요. 클라이언트 자체가 종료되었다면 백그라운드 관리 설정을 살펴봐야 합니다. 클라이언트는 실행 중인데 로그에 연결 끊김이 표시되면 무선 네트워크와 모바일 네트워크 간 전환, 네트워크 절전, 원격 세션 종료가 원인일 수 있습니다. 백그라운드 실행을 허용해도 모든 세션이 계속 유지되는 것은 아니므로 네트워크가 바뀐 뒤 클라이언트가 다시 연결해야 합니다. 새 연결이 성립할 때까지 기다린 다음 새 요청을 보내고, 이전 세션의 실패만으로 현재 네트워크까지 사용할 수 없다고 판단하지 마세요.

모바일 네트워크와 무선 네트워크를 각각 테스트하기

같은 노드가 무선 네트워크에서는 정상인데 모바일 네트워크에서는 실패한다면 두 네트워크의 주소 체계와 DNS 차이, 시스템 데이터 절약 제한을 확인하세요. 추가로 설정한 비공개 DNS를 잠시 끄고 비교할 수도 있지만 이는 원인 확인을 위한 단계이지 계속 꺼 두라는 뜻은 아닙니다. UDP 관련 서비스만 문제가 있다면 노드, 전송 방식, 서버가 해당 트래픽 전달을 지원하는지 확인하세요. 웹페이지가 열린다고 모든 프로토콜이 정상이라는 뜻은 아닙니다. 일반 HTTP 요청은 다른 종류의 연결 경로를 주로 확인합니다.

무선 네트워크를 바꾼 뒤 첫 연결이 느리다면 이전 DNS 캐시와 주소 변경이 원인일 수 있습니다. 먼저 연결을 중지했다가 다시 시작하고 로그에 표시된 서버 주소가 현재 DNS 조회 결과인지 확인한 다음 DNS 변경을 검토하세요. 공용 네트워크에서 인증이 필요하면 VPN을 시작하기 전에 먼저 인증을 완료합니다. 클라이언트를 종료해도 네트워크에 접속할 수 없다면 노드를 계속 수정하지 말고 시스템 네트워크와 VPN 정책을 확인하세요. 시스템 시간이 맞지 않으면 TLS에도 영향을 주므로 Android 기기에서도 자동 시간과 시간대를 확인해야 합니다.

적합한 클라이언트를 선택하고 전체 연결 과정 확인하기

Android에서는 v2rayNG를 우선 권장하며 V2Fly 코어를 사용하는 v2flyNG도 대안입니다. 하지만 클라이언트를 바꾸는 것이 모든 문제의 해결책은 아닙니다. 특정 코어 기능에 의존하는 노드는 가져오기 전에 호환성을 확인하세요. 설치 파일은 기기 아키텍처에 맞게 선택하고 확인하기 어렵다면 Android 다운로드 안내에서 해당 파일을 확인하세요. 설치가 실패했다고 노드 프로토콜을 임의로 바꾸지 마세요. 두 클라이언트가 같은 구독을 사용하더라도 앱 목록, DNS, 라우팅 설정은 각각 확인해야 합니다.

마지막 확인에는 화면이 켜진 상태의 접속, 화면이 꺼진 뒤 새 요청, 무선 및 모바일 네트워크 전환, 로컬 네트워크 접속, VPN 중지 후 일반 네트워크 복구가 포함되어야 합니다. 각 항목에서 같은 작업을 비교하고 다른 사용 상황이 손상되지 않았는지 확인하세요. 처음 설정하는 과정은 구독 가져오기 및 연결 가이드에서 확인할 수 있습니다. 용어가 헷갈리면 먼저 용어 빠른 참조를 살펴보세요. 사용 가능한 설정과 민감 정보를 제거한 점검 기록을 보관하면 같은 증상이 다시 발생했을 때 확인된 단계부터 이어서 점검할 수 있습니다.