v2rayN 문제 해결 가이드

진단 단계 › 앱 진입점 › 로컬 수신 › 외부 연결

인터넷에 연결되지 않음: ‘연결됨’ 상태를 구분하세요

메인 창에서 서버를 선택한 상태, 코어가 실행 중인 상태, 시스템 프록시가 켜진 상태는 각각 다릅니다. 노드가 활성 항목으로 표시되어도 이후 요청에 사용될 준비가 됐다는 뜻일 뿐, 원격 핸드셰이크가 성공했다는 의미는 아닙니다. 문제를 진단할 때는 ‘모든 앱에서 연결할 수 없음’, ‘브라우저에서만 실패’, ‘일부 도메인만 실패’를 먼저 구분하세요. 사용 중인 클라이언트, 운영체제, 프록시 모드, 문제가 처음 발생한 시각도 기록해 두면 결과를 비교하기 쉽습니다.

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

먼저 v2rayN 트레이 메뉴에서 ‘시스템 프록시 → 시스템 프록시 해제’를 선택하고 TUN 모드를 잠시 끄세요. 평소 직접 연결되는 웹사이트에 접속해 기기 자체의 네트워크가 정상인지 확인합니다. 호텔·학교·공공 Wi-Fi는 먼저 인증해야 할 수 있습니다. 프록시를 해제해도 모든 연결이 실패한다면 노드 설정을 계속 바꾸지 말고 네트워크 접속, 게이트웨이 또는 시스템 DNS부터 확인하세요. 테스트가 끝나면 ‘시스템 프록시 자동 설정’을 다시 선택합니다.

다른 프록시 프로그램과 브라우저 프록시 확장 기능을 종료하고 v2rayN만 실행해 보세요. 여러 프로그램이 시스템 프록시 설정을 번갈아 변경하면 화면에 표시된 상태와 실제 설정이 달라질 수 있습니다. 특정 브라우저에서만 문제가 발생한다면 새 임시 브라우저 프로필로 테스트해 확장 기능, 캐시, 보안 정책의 영향을 배제하세요. 기존 설정을 바로 삭제하지 마세요. 문제를 재현할 수 있는 환경을 보존해야 원인을 찾기 쉽습니다.

로컬 혼합 포트를 확인하세요

‘설정 → 매개변수 설정 → Core: 기본 설정’에서 ‘로컬 혼합 수신 포트’를 확인하세요. 아래 명령은 포트가 10808이라고 가정합니다. 실제 포트가 다르면 명령의 포트 번호도 함께 바꾸세요. 프록시를 명시적으로 지정하면 시스템 프록시를 거치지 않고 클라이언트의 로컬 수신과 외부 연결이 정상인지 확인할 수 있습니다. Windows PowerShell에서는 동명의 다른 명령과 혼동하지 않도록 curl.exe를 사용하세요.

curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 https://example.com/

HTTP 응답 헤더가 반환되면 이번 요청이 프록시 경로를 통과했다는 뜻입니다. 모든 웹사이트에 접속할 수 있다는 의미는 아닙니다. 로컬 주소에 연결할 수 없다는 메시지가 바로 표시되면 코어 실행 여부와 포트 충돌을 확인하세요. 응답을 기다리다 시간 초과가 발생하면 원격 연결과 DNS를 살펴보세요. 인증서 오류가 나타나면 시스템 시간과 대상 인증서를 확인하고 인증서 검증을 바로 끄지 마세요. 대상 사이트 자체에 문제가 있을 수 있으므로 정상 작동이 확인된 다른 주소로 교차 테스트하세요.

로그로 진입점·라우팅·핸드셰이크를 구분하세요

메인 창의 로그 영역에서 이전 로그를 지운 뒤 요청을 한 번만 보내고 같은 시각의 기록을 확인하세요. 관련 기록이 전혀 없다면 요청이 클라이언트에 도달하지 않았거나 액세스 로그가 비활성화된 것일 수 있습니다. 프록시를 명시한 테스트 결과와 함께 판단하세요. 로그가 비어 있다는 이유만으로 결론을 내리면 안 됩니다. 로컬 연결 기록이 있으면 대상 도메인, 아웃바운드 태그, 오류 유형을 확인해 요청이 예상한 경로로 전달됐는지 살펴보세요.

‘로그 수준’을 잠시 info로 설정하면 시작 과정과 오류 전후 상황을 확인하는 데 도움이 됩니다. 액세스 로그 출력 여부는 사용하는 코어와 로그 설정에 따라 달라집니다. 문제를 재현한 뒤에는 warning으로 되돌려 불필요한 로그가 계속 쌓이지 않게 하세요. 로그를 공유하기 전에는 구독 주소, 서버 주소, 사용자 식별 정보와 인증 내용을 삭제하고 오류 문구, 대상 유형, 발생 순서만 남기세요.

확인 결과에 따라 수정하고, 동시에 재설치하지 마세요

프록시를 명시한 요청은 성공하지만 브라우저에서 실패한다면 시스템 프록시가 작동하지 않는 경우를 확인하세요. 로컬 포트는 정상인데 모든 원격 연결이 시간 초과되면 노드 연결 시간 초과 항목으로 이동하세요. 도메인 접속만 실패한다면 DNS 및 라우팅 확인을 살펴보세요. 특정 웹사이트에서만 문제가 발생하면 해당 사이트를 노드별로, 직접 연결과 프록시 연결로 나눠 비교하세요. 사이트 자체의 접속 정책을 클라이언트 전체의 문제로 오인하지 마세요.

수정 후에는 원래 사용하던 브라우저와 네트워크 환경에서 다시 테스트해 임시 환경에서만 해결된 것은 아닌지 확인하세요. 단계별 점검 목록은 연결됨으로 표시되지만 웹페이지가 열리지 않을 때의 점검 메모를 참고하세요. 최종적으로 효과가 확인된 변경만 남기고 진단 중 임시로 추가한 규칙은 되돌려 다음 문제의 원인이 되지 않도록 하세요.

진단 단계 › 서버 주소 › 전송 포트 › 프로토콜 핸드셰이크

노드 연결 시간 초과: TCP 연결과 프로토콜 작동을 구분하세요

V2Ray 지연 시간 테스트는 방식에 따라 의미가 다릅니다. Tcping은 주로 서버의 지정 포트에 연결할 수 있는지 확인하고, 실제 연결 테스트는 선택한 프록시 설정으로 테스트 주소에 요청을 보냅니다. Tcping 성공이 인증, TLS 또는 전송 설정의 정상 작동을 보장하지는 않습니다. 실제 연결 테스트 실패도 테스트 주소에 접속할 수 없어서일 수 있습니다. 노드를 비교하기 전에 테스트 방식과 전체 오류 메시지를 기록하세요.

주소 확인과 포트 연결부터 점검하세요

노드 편집 창을 열어 서버 주소에 불필요한 공백이 없는지, 포트가 서버 제공 정보와 일치하는지 확인하세요. 주소 입력란에는 보통 호스트 이름이나 IP만 입력합니다. 경로가 포함된 전체 웹 주소를 붙여넣지 마세요. 도메인을 확인할 수 없다면 현재 네트워크의 DNS 상태부터 점검하세요. 연결 거부와 응답 시간 초과는 의미가 다릅니다. 연결 거부는 대상에 도달했지만 해당 포트가 연결을 받지 않는 경우가 많고, 시간 초과는 네트워크 경로, 방화벽 또는 원격 서버의 응답과 관련될 수 있습니다.

Windows에서는 Test-NetConnection으로 서버 포트 연결을 확인할 수 있습니다. 명령에 입력하는 주소는 실제 서버 주소로 바꾸세요. 이 결과는 연결 여부를 판단할 때만 사용할 수 있습니다. 노드 포트 대신 웹사이트 포트를 테스트하지 마세요. 같은 노드가 모바일 핫스팟에서는 작동하고 가정 네트워크에서는 실패한다면 프로토콜 항목부터 바꾸지 말고 두 네트워크의 DNS, IPv6, 외부 연결 정책, 보안 프로그램 규칙을 비교하세요.

TLS·전송·인증 항목을 확인하세요

TCP 연결은 되지만 핸드셰이크가 실패한다면 제공업체의 원본 설정과 사용자 ID, 비밀번호, 전송 방식, TLS 사용 여부, 서버 이름, 경로를 대조하세요. WebSocket 경로와 Host는 서버 주소와 다른 값입니다. gRPC 서비스 이름도 임의로 입력하는 메모가 아닙니다. 항목을 비워도 되는지는 서버 설정에 따라 다르므로 다른 노드의 설정을 그대로 가져오지 마세요. 항목을 하나 바꾼 뒤 테스트하고, 실패하면 원래 값으로 되돌리세요.

REALITY 노드는 서버에서 제공한 공개 키, 짧은 ID, 서버 이름도 일치해야 합니다. 구독에 포함된 값을 임의로 새로 만들거나 바꾸지 마세요. 이름이 웹사이트처럼 보인다고 서버 IP로 바꾸는 것도 피하세요. 프로토콜 항목은 서로 연관되어 있어 한 항목만 ‘최적화’해도 전체 설정이 작동하지 않을 수 있습니다. 구독을 가져온 뒤 값이 누락됐다면 클라이언트와 선택한 코어가 해당 설정을 지원하는지 확인한 후 제공업체에 문의하세요.

인증서 유효 기간, 호스트 이름 불일치, 핸드셰이크 검증 오류가 발생하면 먼저 시스템 날짜·시간·시간대를 맞춘 뒤 인증서 이름과 서버 이름이 일치하는지 확인하세요. 회사 네트워크의 HTTPS 검사도 연결에 영향을 줄 수 있습니다. ‘안전하지 않은 연결 허용’을 일반적인 해결책으로 사용하지 마세요. 검증 기준을 낮출 뿐 아니라 포트 연결 실패, 비밀번호 오류, 전송 경로 불일치는 해결하지 못합니다.

교차 테스트로 문제 범위를 좁히세요

테스트 주소를 하나로 고정하고 같은 구독의 두 노드를 비교한 다음, 같은 노드를 서로 다른 네트워크에서 비교하세요. 한 노드만 실패한다면 노드 설정이나 서버 문제일 가능성이 큽니다. 모든 노드가 동시에 실패하면 로컬 네트워크, 코어 시작 여부, 구독 만료부터 확인하세요. 특정 프로토콜 유형만 실패한다면 해당 코어의 지원 여부와 공통 전송 항목을 확인하세요. 구독 전체를 삭제할 필요는 없습니다.

테스트 방식의 한계를 파악하세요

실제 연결 테스트 주소는 그대로 유지하세요. 주소를 바꿨다면 이전 결과와 바로 비교할 수 없습니다. 일부 사이트는 자동 요청을 제한하거나 리디렉션을 사용하고, 특정 외부 IP의 접속을 차단할 수 있습니다. 따라서 테스트 실패만으로 프록시를 전혀 사용할 수 없다고 단정할 수 없습니다. 브라우저에서 실제 웹페이지를 열고 같은 시각의 로그를 확인하면 자동 테스트가 확인하지 못한 부분을 점검할 수 있습니다.

계속 시간 초과가 발생한다면 문의할 때 프로토콜 유형, 전송 방식, TLS 사용 여부, 같은 노드를 다른 네트워크에서 테스트한 결과, 민감 정보를 가린 오류 내용을 포함하세요. 전체 공유 링크를 공개하지 마세요. 첫 노드 선택과 연결 확인 순서는 첫 연결, 실제 연결 속도 테스트 및 프록시 확인에서 확인할 수 있습니다. 클라이언트 다운로드와 플랫폼 선택은 다운로드 페이지에서 진행하세요.

진단 단계 › 구독 요청 › 응답 내용 › 노드 파싱

구독 업데이트 실패: 다운로드와 파싱을 따로 확인하세요

구독 업데이트는 구독 내용을 가져오는 과정과 그 내용을 클라이언트가 인식하는 노드로 변환하는 과정으로 나뉩니다. 네트워크 시간 초과, 인증 실패, 형식 비호환은 각각 해결 방법이 다릅니다. 먼저 ‘구독 그룹 설정’에서 업데이트 대상 그룹을 확인한 뒤 이번 업데이트 로그를 살펴보세요. 같은 주소를 반복해서 가져와 중복 그룹을 만들면 기존 노드와 새 업데이트 결과를 구분하기 어려워집니다.

주소가 완전한지, 권한이 유효한지 확인하세요

구독 그룹을 편집해 주소의 시작 부분과 끝 부분, 쿼리 매개변수가 온전한지 확인하세요. 메신저에서 긴 링크가 잘리거나 복사 과정에서 줄바꿈·한글 문장 부호가 섞일 수 있습니다. 인증 정보가 포함된 구독 주소는 접속 권한을 가진 비밀번호와 같습니다. 공개 웹사이트, 온라인 변환 도구, 스크린샷에 올리지 마세요. 제공업체가 주소를 재설정했다면 예전 주소가 열리더라도 유효한 노드 목록을 반환하지 않을 수 있습니다.

구독이 만료됐거나 트래픽 한도에 도달했거나 계정 권한이 바뀌면 노드 목록 대신 안내 페이지가 반환될 수 있습니다. HTTP 인증 오류나 접근 거부가 발생하면 먼저 제공업체 계정 페이지에서 상태를 확인하세요. 인증 오류를 클라이언트 설정 누락으로 오해하지 마세요. 주소의 식별 정보를 바꿔 권한을 우회하려고 해서도 안 됩니다. 주소와 계정 상태가 유효한 것을 확인한 다음 네트워크를 점검하세요.

직접 연결 업데이트와 프록시 업데이트를 구분하세요

v2rayN의 ‘구독 그룹’ 메뉴에는 보통 구독 업데이트와 프록시를 통한 업데이트가 있습니다. 메뉴 문구는 버전에 따라 다를 수 있습니다. 직접 연결 업데이트는 실패하지만 기존 노드는 사용할 수 있다면 현재 작동 중인 프록시를 통해 업데이트해 보세요. 반대로 현재 노드가 작동하지 않는다면 프록시 업데이트도 실패합니다. 이때는 정상 작동하는 다른 노드로 바꾸거나 직접 연결 업데이트를 테스트하세요. 문제가 있는 동일한 연결 경로를 사용해 반복 시도하지 마세요.

직접 연결과 프록시 연결이 모두 실패하면 오류가 발생한 단계를 확인하세요. 도메인 확인 오류는 DNS, 연결 시간 초과는 네트워크 경로, TLS 오류는 시스템 시간과 인증서 환경을 점검하세요. 브라우저에서 구독 주소가 열린다고 클라이언트에서도 내용을 가져올 수 있다는 뜻은 아닙니다. 브라우저는 다른 프록시, 로그인 상태 또는 보안 확인 절차를 사용할 수 있습니다. 비교할 때 두 요청이 동일한 네트워크 경로를 사용하는지 확인하세요.

다운로드는 성공했지만 노드가 없는 경우

업데이트 로그에 요청 성공이 표시되는데 노드 수가 바뀌지 않는다면 반환된 내용이 웹페이지, 오류 안내 또는 호환되지 않는 형식인지 확인하세요. 서버가 성공 상태 코드를 반환해도 로그인 페이지를 보내는 경우가 있습니다. 표준 공유 링크, 인코딩된 노드 목록, 특정 클라이언트 전용 설정은 서로 다른 형식입니다. 파일 확장자나 주소에 ‘구독’이라는 단어가 있다는 이유만으로 v2rayN에서 사용할 수 있다고 판단하지 마세요.

일부 노드만 가져오기에 실패한다면 실패한 노드의 프로토콜, 전송 방식, 공통 항목을 비교하세요. 구버전 클라이언트는 새 매개변수를 인식하지 못할 수 있습니다. 먼저 설정을 백업한 뒤 v2rayN 다운로드에서 시스템에 맞는 설치 파일을 선택해 업데이트하세요. 이해하지 못하는 항목을 직접 삭제해 가져오기에 성공시키려 하지 마세요. 중요한 인증·전송 설정이 빠진 노드는 목록에 표시되더라도 연결할 수 없습니다.

노드가 ‘업데이트되지 않은 것처럼’ 보이는 원인은 필터일 수도 있습니다. 현재 그룹, 키워드 필터, 목록 정렬을 확인해 새 노드가 숨겨지지 않았는지 살펴보세요. 구독 그룹의 필터 조건을 확인하고 업데이트 전후의 노드 이름과 서버 주소를 비교하세요. 노드 이름이 바뀌었다고 새 서버가 추가된 것은 아닙니다. 중복 노드가 있다고 업데이트 실패인 것도 아니므로 로그와 실제 내용을 기준으로 판단하세요.

이전 설정을 보존하고 되돌릴 수 있는 업데이트 절차를 마련하세요

업데이트 전에 현재 사용할 수 있는 설정을 내보내고 그룹 설정을 기록하세요. 백업 파일에는 민감한 노드 정보가 들어 있으므로 안전한 위치에 보관해야 합니다. 특정 구독 형식이 문제라고 의심되면 임시 그룹을 만들어 따로 테스트하고 성공한 경우에만 기존 그룹을 대체하세요. 실패하면 임시 그룹만 삭제하면 되므로 모든 서버를 비울 필요가 없습니다. 여러 항목을 삭제·중복 제거·덮어쓰기 전에 적용 범위를 확인하세요.

진단이 끝난 뒤 자동 업데이트를 켤지 결정하세요. 시작하자마자 업데이트가 멈춘다면 자동 작업을 잠시 끄고 수동 업데이트가 안정적으로 완료되는지 확인하세요. 자동 재시도는 잘못된 주소나 호환되지 않는 내용을 해결하지 못하며, 처음 오류의 단서를 덮어쓸 수 있습니다. 막연히 ‘다시 시작하니 됐다’고 기록하기보다 어떤 업데이트 메뉴에서 어떤 네트워크와 그룹을 사용했을 때 성공했는지 남겨 두세요.

진단 단계 › 기준 결과 비교 › 외부 연결 부하 › 전송 경로

속도 저하: 지연 시간·전송량·앱 응답을 따로 확인하세요

웹페이지 로딩 지연, 다운로드 속도 저하, 동영상 버퍼링은 서로 다른 문제일 수 있습니다. 지연 시간은 요청을 시작할 때의 대기 시간에 영향을 주고, 처리량은 지속적인 데이터 전송 능력을 나타냅니다. 패킷 손실과 재전송이 있으면 속도가 들쭉날쭉해질 수 있습니다. 지연 시간이 짧은 노드가 대용량 파일 전송에 항상 적합한 것은 아닙니다. 처음 열 때, 다운로드 중, 일정 시간 사용한 뒤 중 언제 느려지는지 먼저 파악한 다음 적절한 방법으로 비교하세요.

조건을 고정해 기준 결과를 만드세요

클라우드 동기화, 시스템 업데이트, 다른 다운로드를 먼저 일시 중지하세요. 테스트 기기, Wi-Fi 위치, 대상 주소, 테스트 시간대를 최대한 동일하게 유지합니다. 속도 테스트를 여러 개 실행하면서 브라우저 속도를 판단하지 마세요. 동시에 보낸 요청이 대역폭을 나눠 씁니다. 같은 작업으로 노드 두 개를 비교하고 몇 차례 반복해 차이가 지속되는지 확인하세요. 한 번의 최고 속도는 캐시나 잠시 한가한 상태 때문일 수 있어 장기 성능의 기준으로 삼기 어렵습니다.

그다음 시스템 프록시를 해제하고 TUN을 끈 상태에서 기본 네트워크를 테스트하세요. 직접 연결 작업도 뚜렷하게 느리다면 Wi-Fi 신호, 라우터 부하, 인터넷 회선 사용량부터 확인하세요. 가능하다면 유선 연결로도 비교해 보세요. 모바일 핫스팟은 다른 네트워크와 비교하는 참고 자료일 뿐 원래 네트워크와 대역폭이 같다는 뜻은 아닙니다. 기준 속도가 안정적이지 않은 상태에서 프록시 설정을 바꾸면 결과가 서로 모순될 수 있습니다.

노드 부하와 대상 사이트 정책을 비교하세요

같은 시간에 특정 노드만 느리다면 외부 연결 부하, 회선 품질, 해당 출구에서 대상 사이트까지의 경로가 원인일 수 있습니다. 같은 대상을 고정해 노드를 바꾸고 개선이 반복되는지 확인하세요. 다운로드 사이트 하나만 느리고 다른 사이트는 정상이라면 대상 사이트의 속도 제한, 계정 등급, 연결 수 제한, 콘텐츠 전송 정책도 고려해야 합니다. 외부 연결 경로를 바꾸면 대상 사이트까지의 경로가 달라질 수 있지만 서버 자체의 제한이 풀린다고 보장할 수는 없습니다.

노드 이름에 표시된 지역만으로 실제 회선 품질을 판단하지 마세요. 노드 이름은 구분을 위한 표시일 뿐 실제 경로는 제공업체의 배치와 네트워크 연결 방식에 따라 달라집니다. 로컬 포트를 바꾸기보다 사용량이 많은 시간대에만 느리고 한가한 시간대에 회복되는지 살펴보세요. 시간대별 실제 작업 결과와 연결 오류를 기록해 지속적인 문제를 제공업체에 전달하는 편이 지연 시간 숫자 하나만 보내는 것보다 도움이 됩니다.

분할 라우팅·UDP·TUN의 영향을 확인하세요

느린 요청이 실제로 어느 출구를 사용하는지 먼저 확인하세요. 다운로드가 도메인 규칙에 따라 직접 연결될 수 있고, 브라우저 확장 기능이 별도의 출구를 사용할 수도 있습니다. ‘라우팅 설정’에서 현재 프리셋과 사용자 지정 규칙을 확인하세요. 필요하다면 적용 범위가 명확한 임시 규칙으로 비교한 뒤 테스트가 끝나면 바로 되돌리세요. 속도 테스트를 위해 사설 네트워크 트래픽 전체를 프록시로 보내면 로컬 네트워크 서비스와 기기 접속에 영향을 줄 수 있습니다.

일부 앱은 UDP나 QUIC을 사용합니다. 노드가 해당 트래픽을 지원하지 않으면 대기 후 다른 방식으로 전환되어 처음에는 느리다가 이후 정상처럼 보일 수 있습니다. ‘UDP 사용’을 켜도 로컬에서 해당 트래픽을 처리할 수 있게 될 뿐, 원격 서버에 UDP 지원이 생기는 것은 아닙니다. 먼저 일반 HTTPS 요청으로 기준을 잡은 뒤 앱 자체의 프로토콜 동작을 비교하세요. 브라우저 프로토콜 옵션을 바꿀 때는 원래 값을 기록하고 테스트 후 복원하세요.

TUN 모드는 가상 네트워크 어댑터, 라우팅 제어, 시스템 권한에도 영향을 받습니다. TUN에서만 느리다면 TUN을 끄고 프록시를 명시해 같은 작업을 테스트하세요. 명시적 프록시가 정상이라면 TUN 라우팅, DNS 가로채기, 다른 가상 네트워크 어댑터와의 충돌을 확인하세요. MTU가 맞지 않으면 특정 경로에 문제가 생길 수 있지만 온라인에서 본 값을 그대로 적용하지 마세요. 큰 패킷 전송은 실패하지만 작은 요청은 정상인 것처럼 근거를 먼저 확인한 뒤 한 번에 하나씩 바꾸세요.

효과 없는 최적화는 줄이고 장기 성능을 확인하세요

연결 재사용, 전송 매개변수, 코어 선택은 많이 켠다고 더 빨라지는 것이 아닙니다. 서버 설정과 맞지 않으면 기능을 추가할수록 호환성 문제가 생길 수 있습니다. 구독에서 제공한 기본 전송 설정을 유지하고 패킷 손실, 외부 연결 부하, 라우팅 오류부터 해결하세요. 코어를 바꾼 뒤 빨라졌다면 동일한 노드와 규칙을 사용했는지 확인하세요. 서로 다른 경로의 차이를 코어 자체의 차이로 착각할 수 있습니다.

속도 측정 사이트만 보지 말고 평소 사용하는 앱을 일정 시간 사용해 확인하세요. 응답이 느려지는 단계, 연결 오류 동반 여부, 노드나 네트워크 변경 후 회복되는지를 기록합니다. 라우팅 규칙 적용을 더 자세히 살펴보려면 geosite 및 geoip 분할 라우팅 설정을 참고하세요. 성능 진단의 목표는 안정적인 병목 지점을 찾는 것이지, 설정을 계속 바꿔 한 번 빠른 결과를 얻는 것이 아닙니다.

진단 단계 › 시스템 DNS › 코어 DNS › 라우팅용 DNS 확인

DNS 문제: 도메인을 어느 단계에서 조회하는지 확인하세요

같은 도메인도 시스템 DNS, 브라우저 보안 DNS, 코어 DNS, 프록시 서버 DNS를 거쳐 조회될 수 있습니다. 시스템 DNS를 바꿨는데 결과가 그대로여도 설정이 저장되지 않았다고 단정할 수 없습니다. 요청이 해당 DNS를 사용하지 않았을 수 있습니다. 먼저 앱, 프록시 진입점, 노드 유형을 기록하고 로그에서 DNS 오류를 확인하세요. 어느 단계에서 이름을 조회하는지 알아야 시스템 설정을 바꿀지 코어 설정을 바꿀지 판단할 수 있습니다.

도메인 조회 오류와 연결 오류를 구분하세요

로그에 표시되는 도메인 없음, DNS 조회 시간 초과, 대상 연결 시간 초과는 각각 다르게 처리해야 합니다. DNS 조회가 성공해도 주소가 올바르거나 연결 가능한 것은 아닙니다. ‘IP 주소로는 접속되는데 도메인으로는 안 된다’는 결과만으로 판단해서도 안 됩니다. HTTPS로 IP에 직접 접속하면 인증서 이름, SNI, 가상 호스트 설정 때문에 실패할 수 있습니다. 이런 실패만으로 DNS에 문제가 있다고 볼 수는 없습니다.

시스템 터미널에서 nslookup example.com을 실행해 시스템 DNS가 결과를 반환하는지 확인할 수 있습니다. 하지만 이 도구는 보통 브라우저의 보안 DNS를 사용하지 않으며 v2rayN 코어 DNS 설정도 자동으로 적용하지 않습니다. 시스템 수준을 확인하는 데는 적합하지만 프록시 요청의 DNS 경로까지 정상임을 증명하지는 못합니다. 비교할 때 사용한 DNS 서버를 기록하고 서로 다른 경로의 결과를 같은 것으로 취급하지 마세요.

domainStrategy가 적용되는 범위를 이해하세요

routing.domainStrategy는 라우팅 규칙을 비교할 때 도메인과 조회된 IP를 어떻게 사용할지 정합니다. AsIs는 규칙 판단에 도메인을 그대로 사용하는 방식입니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 IP를 조회해 IP 규칙을 추가로 확인합니다. 이 항목은 ‘모든 DNS 요청을 프록시로 보내는’ 전역 스위치가 아니며 앱 또는 시스템의 DNS 설정을 대체하지도 않습니다.

아래는 Xray/V2Ray 형식의 일부 설정으로 항목 간 관계를 설명하기 위한 예시이며, 전체 클라이언트 설정이 아닙니다. 사용 중인 코어의 설정 구조에 맞게 합치고 직접 연결 아웃바운드 태그가 실제로 direct인지 확인하세요. v2rayN의 그래픽 라우팅 편집기가 설정을 생성하므로 실행 중 임시 파일을 직접 수정하지 않는 것이 좋습니다. 다음 시작 때 변경 사항이 덮어써질 수 있습니다. 규칙에서 참조하는 데이터도 준비되어 있어야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNS 서버 자체에 연결할 수 있는지 확인하세요

DoH를 설정할 때는 DNS 서버 주소, 인증서 검증, 서버까지의 네트워크 경로를 함께 고려해야 합니다. DoH는 암호화된 전송 방식일 뿐 요청이 직접 연결될지 프록시를 사용할지 결정하지 않습니다. DNS 서버의 도메인을 먼저 조회해야 하는데 서버 접속 경로가 아직 연결되지 않은 프록시에 의존하면 시작 단계에서 순환 의존이 생길 수 있습니다. 사용하는 코어가 지원하는 부트스트랩 DNS와 라우팅 방식을 함께 설계하세요. URL만 바꾸는 것으로 해결되지는 않습니다.

먼저 정상 작동이 확인된 DNS 설정으로 되돌려 기본 조회가 되는지 확인한 뒤 분할 설정을 하나씩 추가하세요. 코어마다 DNS 항목이 다를 수 있으므로 한 코어용 설정을 다른 코어에 그대로 붙여넣지 마세요. 화면의 ‘DNS 설정’과 ‘TUN 모드 설정’은 서로 다른 단계를 관리할 수 있습니다. 실제로 사용하는 코어와 트래픽 가로채기 범위를 확인한 다음 설정 위치를 선택하세요.

IPv6를 켠 뒤 일부 사이트에서만 시간 초과가 발생한다면 네트워크 어댑터에 IPv6 주소가 표시되는지만 보지 말고 실제로 사용할 수 있는 IPv6 경로가 있는지 확인하세요. IPv6 주소를 반환하면서도 연결을 완료하지 못하는 네트워크가 있습니다. 범위를 제한한 설정으로 IPv4만 사용할 때의 결과를 비교할 수 있지만 모든 DNS 문제의 기본 해결책으로 IPv6를 끄지는 마세요. 문제를 해결한 뒤 원래 필요한 설정인지 다시 확인하세요.

캐시를 정리하고 DNS 경로를 확인하세요

설정을 바꾼 뒤 관련 앱을 종료했다가 다시 실행하세요. 필요하다면 Windows에서 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비울 수 있습니다. 이 명령은 브라우저, 코어, 서버 측 캐시까지 지우지는 않습니다. 같은 도메인으로 다시 테스트하면서 오류가 DNS 조회 실패에서 연결 실패로 바뀌는지 살펴보세요. 오류 단계가 바뀌었다면 진단이 진전된 것이므로 단순히 ‘여전히 안 됨’으로 처리하지 마세요.

온라인 DNS 테스트는 해당 검사 방식으로 확인할 수 있는 DNS 출구만 보여 줍니다. 전체 트래픽 경로를 증명하는 것은 아닙니다. 브라우저 보안 DNS, 캐시, 프록시 모드도 결과에 영향을 줍니다. 분할 설정은 DNS 및 DoH 설정 가이드에서, 경로 확인은 DNS 누출 테스트와 방지 설정에서 확인하세요. 먼저 예상한 DNS 출구를 정한 뒤 검사 결과가 그 기준과 다른지 판단하세요.

진단 단계 › 앱 프록시 › 시스템 진입점 › TUN 가로채기

시스템 프록시가 작동하지 않을 때: 앱이 설정을 사용하는지 확인하세요

‘시스템 프록시 자동 설정’은 주로 운영체제 설정에 로컬 프록시 진입점을 지정합니다. 모든 앱이 이 진입점을 사용한다는 뜻은 아닙니다. 앱에 따라 별도 프록시를 사용하거나 환경 변수만 읽거나 소켓에 직접 연결할 수 있습니다. 계속 켜기 버튼을 누르는 대신 대상 앱이 어떤 진입점을 사용하는지, 해당 진입점이 현재 수신 중인 주소와 포트를 가리키는지 확인하세요.

시스템 설정과 실제 수신 상태를 비교하세요

v2rayN 메인 창 하단이나 트레이 메뉴에서 ‘시스템 프록시 → 시스템 프록시 자동 설정’을 선택한 뒤 Windows ‘설정 → 네트워크 및 인터넷 → 프록시’에서 주소와 포트를 확인하세요. 주소는 보통 로컬 루프백 주소이며 포트는 ‘로컬 혼합 수신 포트’와 일치해야 합니다. 설정이 곧바로 바뀐다면 다른 프록시 소프트웨어, 관리 도구 또는 조직 정책이 설정을 제어하는지 확인하세요.

아래 명령으로 자주 사용하는 포트의 수신 여부를 확인할 수 있습니다. 아무 결과도 나오지 않으면 실제 포트가 다른지 먼저 확인하고 코어 프로세스를 살펴보세요. 결과가 나오더라도 수신 중인 프로그램이 반드시 v2rayN인 것은 아닙니다. 프로세스 ID로 프로그램을 식별해야 합니다. 문제 해결을 위해 시스템 프로세스를 함부로 종료하지 마세요. 포트를 다른 앱이 사용 중이라면 비어 있는 포트로 바꿀 수 있지만 시스템 설정과 앱의 수동 설정도 함께 바꿔야 합니다.

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

이 컴퓨터에서만 사용하는 앱을 위해 ‘LAN 연결 허용’을 켤 필요는 없습니다. 이 설정은 수신 가능한 네트워크 범위를 바꿀 뿐 시스템 프록시를 무시하는 앱이 설정을 읽게 해주지는 않습니다. 다른 기기에서 실제로 이 컴퓨터에 연결해야 하는 경우에만 수신 주소, 방화벽, 접근 범위를 함께 검토하세요. 진단이 끝나면 원래의 최소 수신 범위로 되돌려 임시 설정을 계속 사용하지 않도록 하세요.

브라우저와 명령줄 도구의 개별 프록시 설정을 확인하세요

브라우저 프록시 확장 기능, 기업 정책, 브라우저 자체 설정이 시스템 프록시를 덮어쓸 수 있습니다. 먼저 확장 기능을 끄고 브라우저를 다시 연 뒤 프록시를 명시한 요청과 비교하세요. 명령줄 도구는 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY 등의 환경 변수를 읽을 수 있습니다. 기존 터미널에는 시작 당시의 환경 변수가 남아 있으므로 변수 변경 후 새 터미널을 여세요. 기존 창에서 요청만 반복하지 마세요.

Windows 사용자 프록시와 WinHTTP 프록시는 설정 출처가 서로 다릅니다. netsh winhttp show proxy로 WinHTTP 프록시를 확인할 수 있지만, 여기에 직접 연결로 표시된다고 일반 브라우저가 사용자 프록시를 사용하지 않는다는 뜻은 아닙니다. 모든 앱에 영향을 주는 전체 초기화 명령을 함부로 실행하지 마세요. 대상 프로그램이 어떤 설정을 읽는지 확인한 뒤 해당 프로그램의 공식 프록시 설정을 살펴봐야 시스템 서비스나 조직 설정에 영향을 주지 않습니다.

PAC·분할 라우팅 규칙·앱 우회를 구분하세요

PAC를 사용하면 스크립트가 어떤 요청을 프록시로 보낼지 결정합니다. 코어 라우팅은 요청이 클라이언트에 들어온 뒤 어떤 아웃바운드를 사용할지 정합니다. 서로 다른 두 단계의 분할 설정입니다. 웹사이트 요청이 프록시 로그에 없다면 PAC 단계에서 이미 직접 연결됐거나 앱이 시스템 프록시를 사용하지 않는 것일 수 있습니다. 범위를 좁히려면 우선 명시적인 로컬 수동 프록시로 테스트한 다음 코어 규칙을 확인하세요. 두 단계를 동시에 바꾸지 마세요.

요청이 코어에 들어왔지만 잘못된 출구를 사용한다면 ‘라우팅 설정’의 규칙 순서를 확인하세요. 더 구체적인 규칙이 먼저 적용될 수 있는 포괄적인 규칙보다 앞에 오도록 하고 로컬 네트워크 접근 규칙은 유지하세요. 도메인 일치는 트래픽 탐지와 DNS 정책의 영향을 받으므로 최종 IP만 보고 어떤 규칙이 적용됐는지 추측하지 마세요. 리디렉션으로 다른 도메인이 섞이지 않도록 같은 브라우저에서 같은 URL로 재검사하세요.

TUN이 필요한 경우에만 트래픽 가로채기 조건을 확인하세요

대상 앱이 프록시 진입점을 지원하지 않는다면 TUN 모드를 고려할 수 있습니다. 사용 전 일반 시스템 프록시 연결이 정상인지 확인하고 가상 네트워크 어댑터와 라우팅 관리에 필요한 시스템 권한을 허용하세요. TUN은 원격 노드 문제를 해결하는 스위치가 아닙니다. 프록시를 명시한 요청도 실패한다면 먼저 노드 연결을 해결하세요. TUN을 켠 뒤에는 다른 가상 사설 네트워크, 가상 머신 네트워크 어댑터, 보안 소프트웨어가 라우팅을 함께 바꾸는지 확인해 중복 가로채기를 방지하세요.

macOS와 Linux는 데스크톱 프록시 진입 방식이 다르며 앱이 데스크톱 설정을 따르는지도 다를 수 있습니다. Windows의 설정 경로를 그대로 적용하지 마세요. 기본 설정을 다시 구성해야 한다면 가이드의 시스템 프록시 설정 단계를 참고하세요. 진단 후 불필요한 프록시 도구를 종료하고 앱과 클라이언트를 다시 실행하거나 재부팅한 뒤에도 설정이 일치하는지 확인하세요.

진단 단계 › 그래픽 인터페이스 › 코어 프로세스 › 실행 환경

클라이언트 충돌: 인터페이스 종료와 코어 종료를 나눠 확인하세요

창이 열리지 않는 문제, 창이 바로 꺼지는 문제, 코어가 반복해서 재시작하는 문제, 연결 후 앱이 종료되는 문제는 각각 다릅니다. 마지막으로 정상 작동했을 때와 최근 변경 사항을 기록하세요. 클라이언트 업데이트, 폴더 이동, 사용자 지정 설정 가져오기, TUN 사용 여부를 확인합니다. 전체 폴더를 바로 삭제하지 마세요. 설정, 로그, 실행 파일을 모두 지우면 재현할 수 없는 현상만 남을 수 있습니다.

운영체제·아키텍처·설치 위치를 확인하세요

다운로드 페이지에서 플랫폼과 프로세서에 맞는 설치 파일을 선택하세요. Windows 데스크톱 버전과 클래식 WPF 버전은 인터페이스 구성이 다르며 설정 폴더를 임의로 덮어써도 된다는 뜻이 아닙니다. macOS에서는 Apple Silicon과 Intel을 구분하고 Linux에서는 배포판의 패키지 형식과 프로세서 아키텍처를 맞춰야 합니다. 설치 파일을 잘못 선택했다면 올바른 파일을 다시 받으세요. 파일 이름을 바꾸거나 다른 아키텍처의 파일을 섞어 실행하지 마세요.

압축을 푼 폴더에서 실행한다면 압축 파일 미리 보기에서 바로 열지 말고 먼저 전체 압축을 해제하세요. 폴더에 쓰기 권한이 있고 디스크 공간이 충분한지, 경로가 권한 제한이 있는 임시 위치는 아닌지 확인합니다. 포터블 설정과 설치형 설정은 저장 위치가 다를 수 있으므로 경험만 믿고 백업을 프로그램 폴더에 덮어쓰지 마세요. 이동이나 업데이트 전에 클라이언트 내보내기 기능 또는 실제 데이터 폴더를 사용해 백업하세요.

최소 설정으로 데이터 문제를 분리하세요

백업한 뒤 독립된 폴더나 사용자 데이터 환경에서 같은 플랫폼의 클라이언트를 실행하고 기존 설정을 가져오지 않은 상태로 안정적으로 열리는지 확인하세요. 두 인스턴스가 같은 포트를 동시에 사용하지 않도록 하세요. 새 환경에서는 정상이라면 구독, 라우팅, DNS 설정을 한 종류씩 가져오고 매번 재시작해 확인하세요. 설정 손상인지 사용자 지정 기능이 원인인지 좁힐 수 있습니다.

빈 설정에서도 창이 바로 종료된다면 시스템 오류 기록과 실행 환경 메시지를 확인하세요. Windows에서는 이벤트 뷰어의 애플리케이션 로그에서 오류 모듈을 확인할 수 있습니다. macOS에서는 시스템이 제공하는 충돌 보고서를, Linux에서는 터미널에서 그래픽 프로그램을 실행해 시작 오류를 확인하세요. 마지막 창만 캡처하지 말고 오류 문구를 기록하세요. 실행에 필요한 구성 요소는 해당 설치 파일의 안내를 따르고 출처가 불분명한 사이트에서 임의의 구성 요소를 설치하지 마세요.

코어가 종료되면 첫 번째 오류부터 확인하세요

그래픽 인터페이스는 정상인데 코어가 계속 실행되지 않는다면 시작 로그에서 처음 나타난 명확한 오류를 확인하세요. 수신 포트 충돌, 잘못된 설정 항목, 규칙 데이터 누락, 권한 부족으로 이후 연결 오류가 연이어 발생할 수 있습니다. 첫 오류를 해결하고 다시 시작한 뒤 나머지 문제를 살펴보세요. 마지막에 표시된 ‘연결 거부’를 원인으로 단정하지 마세요. 코어 종료의 결과일 수 있습니다.

사용자 지정 설정을 사용한다면 구문이 올바른지, 아웃바운드 태그가 있는지, 규칙에서 참조하는 데이터를 사용할 수 있는지 확인하세요. 코어마다 설정 항목이 다르므로 코어를 바꾼 뒤에는 사용자 지정 설정도 점검해야 합니다. 자동 생성된 실행 설정은 다음 시작 때 다시 만들어질 수 있으므로 그래픽 설정이나 사용자 지정 설정 원본을 수정하세요. 새 라우팅 규칙을 추가한 뒤에만 오류가 발생했다면 클라이언트와 노드를 한꺼번에 바꾸지 말고 해당 규칙부터 되돌리세요.

업데이트·되돌리기·보안 소프트웨어 점검

업데이트 후에만 문제가 발생했다면 먼저 오류와 이전 설정을 보존하고 격리된 환경에서 업데이트 전후를 비교하세요. 이전 버전의 프로그램 파일 전체를 새 폴더에 덮어쓰지 마세요. 실행 파일이 섞이면 새로운 호환성 문제가 생길 수 있습니다. 이전 버전으로 되돌려야 한다면 출처가 확인된 완전한 설치 파일을 사용하고 현재 데이터는 따로 보관해 새 설정 형식과 기존 설정이 서로 덮어쓰지 않게 하세요.

보안 소프트웨어가 차단했다면 먼저 구체적인 기록, 파일 경로, 발생 시각을 확인해 시작 실패와 관련이 있는지 판단하세요. 모든 보호 기능을 끄거나 전체 디스크를 예외로 등록하는 방법은 일반적인 해결책이 아닙니다. 회사나 학교 기기에서 관리 정책으로 제한된다면 관리자에게 허용 범위를 확인하세요. 문제를 해결한 뒤 남아 있는 시스템 프록시 설정을 정리하고 클라이언트를 다시 실행해 실제 연결을 테스트하세요. 그래픽 인터페이스와 코어가 모두 안정적으로 작동하는지 확인합니다.

진단 단계 › VPN 권한 › 앱별 라우팅 › 백그라운드 및 네트워크 전환

Android 문제: 연결 권한·앱별 프록시·백그라운드 연결 끊김

Android에서는 v2rayNG를 우선 사용하고 V2Fly 코어 기반의 v2flyNG를 대안으로 사용할 수 있습니다. 데스크톱의 ‘시스템 프록시’ 방식을 Android에 그대로 적용할 수는 없습니다. 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 가져오고 설정에 따라 외부 연결을 선택합니다. VPN 아이콘이 표시되어도 시스템 경로가 만들어졌다는 뜻일 뿐, 원격 노드의 인증이나 연결이 성공한 것은 아닙니다. 실제 접속과 로그를 함께 확인하세요.

첫 실행 및 VPN 권한

노드를 가져온 뒤 대상 서버를 선택하고 연결을 시작할 때 시스템에 표시되는 VPN 권한 요청을 확인하세요. 권한 창이 나타나지 않거나 다른 화면에 가려졌다면 앱을 앞으로 가져와 다시 시도하고 다른 VPN 앱이 실행 중인지 확인합니다. Android에서는 보통 한 앱이 현재 사용자 VPN 연결을 사용합니다. 두 클라이언트를 번갈아 실행하면 서로 연결을 대체해 간헐적으로 끊기는 것처럼 보일 수 있습니다.

Android 다운로드에서 기기 아키텍처에 맞는 설치 파일을 선택하세요. 최신 기기는 대부분 arm64를 사용합니다. 아키텍처를 모르면 시스템 정보에서 확인하거나 범용 패키지를 선택하세요. 설치에 실패하면 운영체제 버전 제한, 설치 권한, 서명 충돌, 저장 공간 부족을 구분해 확인하세요. 다운로드를 반복하는 것만으로 해결되지 않습니다. 서명 충돌로 업데이트할 수 없다면 먼저 설정을 내보내고 삭제 후 재설치할 때 데이터에 미치는 영향을 검토하세요.

앱별 프록시 및 라우팅 모드를 확인하세요

브라우저에서는 접속되지만 특정 앱에서 실패한다면 클라이언트의 앱별 프록시 설정을 확인하세요. ‘선택한 앱만 프록시 사용’과 ‘선택한 앱 우회’ 중 어떤 방식인지 확인해야 합니다. 두 설정은 반대 방향으로 작동합니다. 시스템 앱, 업무 프로필의 앱, 일반 사용자 앱은 서로 다른 환경에 있을 수도 있습니다. 이름이 비슷하다는 이유만으로 대상 앱이 포함됐다고 판단하지 마세요. 설정을 바꾼 뒤 연결을 다시 시작해 테스트하세요.

모든 앱에서 실패한다면 추가 앱별 필터를 잠시 해제하고 작동이 확인된 노드 하나와 기본 라우팅으로 테스트하세요. 원격 DNS, 트래픽 탐지, IPv6, 분할 라우팅 목록을 동시에 바꾸지 마세요. 특정 앱이 UDP를 사용한다면 노드와 코어가 해당 트래픽을 실제로 지원하는지도 확인하세요. VPN 경로가 트래픽을 가져오더라도 원격 서버가 앱에 필요한 모든 프로토콜을 전달할 수 있다는 뜻은 아닙니다.

일부 앱은 연결이나 DNS 결과를 자체 캐시하므로 분할 설정을 바꾼 뒤에도 이전 연결을 계속 사용할 수 있습니다. 대상 앱을 종료했다가 다시 열고, 필요하다면 클라이언트 연결을 끊었다가 다시 연결하세요. 앱 데이터를 바로 삭제하면 로그인 정보와 로컬 자료가 사라질 수 있으므로 첫 번째 조치로 삼지 마세요. 먼저 브라우저와 다른 일반 앱으로 교차 테스트해 문제가 한 앱에만 있는지 확인하세요.

화면을 끈 뒤 연결이 끊기거나 네트워크 전환 후 실패

화면을 켰을 때는 정상인데 잠금 상태로 한동안 두면 연결이 끊긴다면 시스템 배터리 최적화, 백그라운드 실행 제한, 제조사 작업 관리 설정을 먼저 확인하세요. 기기 설정에서 클라이언트가 계속 실행되도록 허용하고 연결 알림을 유지하세요. 모든 앱의 백그라운드 권한을 한꺼번에 풀지 말고 VPN 연결을 유지해야 하는 클라이언트에만 적용하세요. 시스템 업데이트 후 권한이 바뀔 수 있으므로 문제가 다시 발생하면 설정을 재확인하세요.

시스템의 ‘VPN 항상 사용’과 ‘VPN을 사용하지 않는 연결 차단’은 연결이 끊겼을 때의 네트워크 동작을 바꿉니다. 후자를 켜면 클라이언트가 종료되거나 다시 연결되는 동안 인터넷이 완전히 끊길 수 있으며 이는 해당 설정의 의도된 동작입니다. 먼저 이 동작이 필요한지 판단하세요. 기본 네트워크를 점검할 때는 해당 제한을 잠시 끌 수 있지만 원래 값을 기록하고 테스트가 끝난 뒤 필요에 따라 복원하세요.

Wi-Fi에서 모바일 네트워크로 전환한 뒤 연결되지 않으면 먼저 VPN 연결을 끊었다가 다시 연결해 복구되는지 확인하세요. 네트워크가 바뀌면 IP 주소와 DNS, 기존 연결 상태도 달라져 이전 연결을 계속 사용할 수 없을 수 있습니다. 특정 네트워크에서만 실패한다면 같은 노드로 각각 테스트하고 웹 인증이 필요한지, IPv6 경로에 문제가 있는지 확인하세요. 네트워크 전환 후 실패를 전부 백그라운드 앱 정리 탓으로 돌리지 마세요.

모바일 DNS 및 진단 증거

Android의 비공개 DNS, 브라우저 보안 DNS, 클라이언트 DNS 설정이 함께 도메인 조회에 영향을 줄 수 있습니다. 도메인 오류가 발생하면 모든 설정을 한꺼번에 끄지 말고 현재 값을 먼저 기록하세요. 로그에 DNS 시간 초과가 표시되면 현재 네트워크와 클라이언트의 원격 DNS 경로를 함께 확인합니다. 특정 브라우저에서만 문제가 있다면 브라우저 자체 DNS 동작을 비교하세요. 자세한 내용은 DNS 항목에서 단계별로 확인할 수 있습니다.

Android 문제를 다른 사람에게 설명할 때는 기기 운영체제, 클라이언트 이름, 네트워크 유형, 화면 잠금 및 네트워크 전환 조건, VPN 연결 유지 여부를 기록하세요. 민감 정보를 가린 최초 오류도 첨부하고 같은 노드가 데스크톱 v2rayN에서 작동하는지 알려 주세요. 기기 간 비교는 문제 범위를 좁히는 데 도움이 되지만 설정이 완전히 같다는 의미는 아닙니다. 복구한 뒤 화면 잠금, 다시 켜기, 네트워크 전환을 직접 테스트해 실제 문제가 발생했던 상황에서도 해결됐는지 확인하세요.