V2Ray 문제 해결 매뉴얼

비교 가능한 기준 상태 만들기

먼저 클라이언트를 종료하거나 시스템 프록시를 끄고, 평소 안정적으로 접속되는 사이트를 브라우저에서 열어 보세요. 동시에 로컬 네트워크가 정상적으로 주소를 가져오는지도 확인합니다. 직접 연결도 실패한다면 라우터, 무선 네트워크, 케이블, 인증 페이지 또는 기기의 네트워크 스택부터 해결해야 합니다. 프록시 클라이언트는 하위 네트워크 단절을 복구하지 못합니다. 직접 연결이 정상이라면 v2rayN, v2rayNG 또는 v2flyNG를 다시 실행하고 기존 노드와 라우팅 모드를 유지한 채 같은 사이트에 접속하세요. 이 비교를 통해 “네트워크 자체가 작동하지 않는 경우”와 “프록시 경로가 작동하지 않는 경우”를 구분할 수 있습니다.

데스크톱에서는 “코어가 실행 중인 상태”와 “시스템 트래픽이 코어로 유입된 상태”도 구분해야 합니다. v2rayN 실행 로그에는 로컬 인바운드가 정상적으로 수신 대기한다는 내용이 나타나야 합니다. 다른 프로세스가 포트를 사용 중이면 코어가 시작 직후 종료될 수 있지만 트레이 아이콘은 남아 있을 수 있습니다. 설정에서 로컬 HTTP 및 SOCKS 포트를 확인한 뒤 브라우저나 시스템 프록시가 같은 포트를 사용하는지 확인하세요. 브라우저 프록시 확장을 수동으로 설정했다면 확장이 이전 포트를 가리키고 있지 않은지도 점검해야 합니다.

1. STEP 01프록시를 끄고 직접 연결 확인
2. STEP 02코어와 포트 수신 대기 확인
3. STEP 03시스템 프록시 주소 확인
4. STEP 04노드를 바꿔 비교

로컬 포트가 실제로 수신 대기 중인지 확인

Windows에서는 PowerShell로 해당 포트를 확인할 수 있습니다. 아래는 일반적인 로컬 포트를 사용한 예시이며, 실제 점검 시에는 클라이언트 설정 화면에 표시된 값으로 바꾸세요. 아무 출력도 없다면 포트가 생성되지 않은 것입니다. 프로세스 기록은 있지만 현재 클라이언트가 아니라면 포트 충돌이 발생한 것입니다. “포트 번호가 맞아 보인다”는 이유만으로 판단하지 마세요. 수신 대기 중인 프로세스가 유효한 근거입니다.

WINDOWS / LOCAL LISTENER

Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalPort -in 10808,10809 } |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id (Get-NetTCPConnection -LocalPort 10809 -State Listen).OwningProcess

macOS와 Linux에서는 운영체제에 기본 포함된 네트워크 도구로 수신 대기 상태를 확인할 수 있습니다. 결과가 127.0.0.1에서만 수신 대기 중이라면 로컬 프로그램만 접근할 수 있다는 뜻이며, 데스크톱 단독 사용에서는 정상적인 범위입니다. LAN 기기의 연결이 명확히 필요할 때만 LAN 연결 허용을 고려하세요. 단일 기기 문제를 점검할 때 먼저 수신 범위를 넓히면 변수가 늘어날 뿐 시스템 프록시 대상 오류는 해결되지 않습니다.

MACOS / LINUX / LOCAL LISTENER

ss -lntp | grep -E '10808|10809'
lsof -nP -iTCP:10809 -sTCP:LISTEN

증상으로 프록시·라우팅·원격 문제 구분하기

라우팅 모드는 이 증상에서 가장 자주 놓치는 변수입니다. 규칙 모드에서는 도메인, 대상 주소, 규칙 집합에 따라 직접 연결 또는 프록시 아웃바운드를 선택합니다. 글로벌 모드는 일반적으로 더 많은 트래픽을 프록시 아웃바운드로 보냅니다. 진단을 위해 잠시 글로벌 모드로 전환할 수 있습니다. 글로벌 모드에서 복구된다면 노드 자체는 정상일 가능성이 높고, 문제는 규칙 매칭이나 DNS 응답 결과에 집중됩니다. 글로벌 모드에서도 실패한다면 노드와 전송 계층을 계속 확인하세요. 진단이 끝나면 원래 모드로 되돌리고 관련 규칙을 수정해야 하며, 임시 진단 모드를 영구 해결책으로 사용해서는 안 됩니다.

마지막으로 이미 정상 작동이 확인된 두 번째 노드를 비교에 사용하세요. 노드만 바꾸고 라우팅, DNS, 시스템 프록시는 수정하지 않습니다. 두 번째 노드에서 복구되면 원래 노드나 전송 매개변수에 문제가 있는 것입니다. 모든 노드가 실패한다면 로컬 수신 대기, 시스템 프록시, 클라이언트 코어로 돌아가야 합니다. 이처럼 하나의 변수만 바꾸면 노드 문제를 소프트웨어 문제로 오해하거나 의미 없이 클라이언트를 반복 설치하는 일을 피할 수 있습니다.

서버 주소와 포트부터 확인

현재 노드의 편집 화면을 열고 주소, 포트, 사용자 식별자, 암호화 옵션, 전송 방식, TLS 활성화 여부, 서버 이름, 경로, Host를 하나씩 확인하세요. 구독에서 가져온 노드는 보통 이 필드를 직접 수정할 필요가 없습니다. 문제를 확인하려고 특정 항목을 바꾼 적이 있다면 구독 원본과 다시 비교하는 것이 우선입니다. 주소 필드에는 호스트 이름이나 주소만 입력하고 프로토콜 접두사, 경로, 포트를 함께 붙여 넣지 마세요. 포트는 유효한 숫자여야 하며 서버의 수신 대기 포트와 일치해야 합니다.

노드가 도메인을 사용할 때는 먼저 이 기기에서 해당 도메인을 확인할 수 있는지 점검하세요. 확인에 성공했다는 것은 주소를 받았다는 뜻일 뿐, 해당 포트에 접근할 수 있다는 의미는 아닙니다. Windows에서는 Test-NetConnection으로 TCP 연결을 확인할 수 있고, macOS와 Linux에서는 nc를 사용할 수 있습니다. 명령의 예시 도메인과 포트는 실제 노드 값으로 바꾸세요. TCP 점검이 실패한다면 클라이언트 프로토콜 매개변수를 계속 바꿔도 의미가 없습니다. 먼저 네트워크 경로, 주소, 포트를 확인해야 합니다.

TCP / REACHABILITY

Test-NetConnection server.example.net -Port 443

nc -vz server.example.net 443

테스트 결과는 사용 환경과 함께 해석해야 합니다. 도메인은 확인되지만 포트 연결이 실패한다면 원격 서버가 수신 대기하지 않거나, 주소가 변경됐거나, 중간 네트워크가 차단했거나, 로컬 보안 소프트웨어가 가로막고 있을 수 있습니다. 포트 연결은 성공했지만 클라이언트가 계속 시간 초과를 보고한다면 TLS, WebSocket, gRPC 또는 프로토콜 인증 계층에 더 가까운 문제입니다. 브라우저에서 노드 도메인이 열리는지로 서비스 정상 여부를 판단하지 마세요. 브라우저는 HTTP 요청을 보내지만 노드는 전혀 다른 경로와 핸드셰이크 형식을 사용할 수 있습니다.

TLS와 전송 매개변수가 한 세트로 일치하는지 확인

TLS 환경에서는 서버 이름이 인증서 및 핸드셰이크 일치 여부에 관여하는 경우가 많습니다. 노드 주소는 주소값이어도 서버 이름에는 설정 제공자가 지정한 도메인을 입력해야 할 수 있습니다. 두 값을 기계적으로 같게 바꾸면 핸드셰이크가 실패할 수 있습니다. 로그에 인증서 이름 불일치, 핸드셰이크 조기 종료, 프로토콜 버전 협상 실패가 나타난다면 검증을 끄기보다 구독에 포함된 서버 이름과 보안 설정을 복원하세요. 시스템 시간이 크게 틀려도 인증서 유효 기간 판단에 영향을 주므로 시스템 시간과 시간대를 자동 동기화로 먼저 되돌리세요.

WebSocket 노드는 경로와 Host를 함께 확인해야 합니다. 경로는 보통 슬래시로 시작하며 대소문자와 끝부분 문자도 서버 매칭에 포함될 수 있습니다. gRPC 노드는 서비스 이름을 확인하세요. VMess, VLESS 등의 프로토콜 필드는 전송 계층과 분리해 판단할 수 없습니다. 프로토콜 인증이 올바르더라도 전송 경로가 틀리면 인증 전에 실패합니다. 구독 업데이트 후 일부 오래된 노드만 시간 초과가 발생한다면 서버 매개변수가 변경됐는데 클라이언트에 이전 노드 사본이 남아 있을 수 있습니다. 이전 사본을 삭제한 뒤 구독에서 다시 생성하세요.

비교군으로 문제 범위 좁히기

세 가지를 비교해 보세요. 같은 클라이언트의 다른 노드, 다른 네트워크에서 같은 노드, 다른 기기에서 같은 구독입니다. 다른 노드가 작동한다면 클라이언트 기본 경로는 정상입니다. 같은 노드가 네트워크를 바꾼 뒤 작동한다면 기존 네트워크 경로에 차이가 있는 것입니다. 같은 노드가 모든 기기에서 실패한다면 원격 노드 상태나 구독 매개변수일 가능성이 높습니다. 매번 조건 하나만 바꾸고 결과를 기록하세요. 세 번의 비교가 반복 재시작보다 훨씬 많은 정보를 제공하는 경우가 많습니다.

지연 시간 테스트도 올바르게 해석해야 합니다. 클라이언트에 표시되는 연결 지연은 일반적으로 특정 탐색 요청의 완료 시간이며 모든 실제 트래픽의 속도와 같지 않습니다. 일부 노드는 특정 탐색 방식에 응답하지 않아도 실제 연결은 작동할 수 있습니다. 반대로 탐색은 빠르지만 이후 TLS나 앱 요청이 실패할 수도 있습니다. 따라서 실제 웹 요청과 실행 로그를 함께 관찰하세요. 모든 노드가 동시에 시간 초과를 일으킬 때는 각 노드를 일일이 편집하기보다 시스템 시간, DNS, 시스템 보안 정책, 클라이언트 코어가 정상적으로 로드되는지 확인해야 합니다.

노드가 구독으로 관리된다면 최종 해결은 구독 소스로 돌아가야 합니다. 구독이 아직 유효한지 확인하고, 업데이트 후 노드 매개변수가 바뀌었는지 점검한 다음 수동 수정으로 생긴 중복 항목을 삭제하세요. 노드 매개변수가 정확한데도 원격에 계속 접근할 수 없다면 로컬 클라이언트에서 더 수정할 설정은 없습니다. 로그에 단계별 정보를 남기고 사용 가능한 노드로 교체하세요. 이렇게 하면 “원격을 사용할 수 없는 문제”와 “로컬 설정 오류”를 명확히 구분할 수 있습니다.

링크 자체와 업데이트 경로 확인

먼저 구독 관리 화면에서 현재 링크를 복사하고 앞뒤에 공백, 줄바꿈, 한글 문장 부호, 중복 문자가 섞였는지 확인하세요. 메신저로 전달된 긴 링크는 줄바꿈될 수 있고, 복사할 때 보이는 부분만 선택될 수도 있습니다. 직접 디코딩한 뒤 붙여 넣지 마세요. 클라이언트에는 완전한 원본 링크가 필요합니다. 서비스 제공자가 구독 주소를 변경했다면 기존 항목을 삭제한 후 다시 추가하세요. 이름이 비슷한 구독 두 개가 함께 있으면 실제로는 이전 링크가 업데이트될 수 있습니다.

그다음 “프록시를 통해 구독 업데이트”와 “직접 업데이트”를 구분하세요. 현재 네트워크에서 구독 주소에 직접 접근할 수 없는데 클라이언트가 직접 연결로 업데이트하도록 설정되어 있으면 주소 확인이나 연결 단계에서 실패합니다. 반대로 이미 만료된 노드를 통해 업데이트하도록 강제해도 구독을 요청할 수 없습니다. v2rayN에서는 구독 업데이트 관련 프록시 옵션을 확인하고, Android 클라이언트에서는 업데이트 시 VPN 연결 상태와 앱별 규칙을 확인하세요. 업데이트 경로 전환은 진단용으로만 사용하고, 사용 가능한 경로를 확인한 뒤 설정을 고정하세요.

1. STEP 01전체 링크 확인
2. STEP 02요청 성공 여부 판단
3. STEP 03응답 콘텐츠 식별
4. STEP 04파싱 호환성 확인

응답 결과로 문제 단계 판단

로그에 HTTP 상태가 표시된다면 먼저 범주별로 판단하세요. 리디렉션이 항상 오류인 것은 아니지만 클라이언트가 최종 주소까지 따라갈 수 있어야 합니다. 권한 관련 응답은 링크 인증 정보, 유효 기간 또는 접근 조건이 바뀌었음을 의미하는 경우가 많습니다. 서버 오류는 구독 서버가 일시적으로 콘텐츠를 정상 생성하지 못한다는 뜻입니다. 상태가 성공이어도 파싱 가능한 콘텐츠라는 보장은 없습니다. 로그인 페이지, 안내 페이지, 게이트웨이 오류 페이지도 성공 상태로 반환될 수 있으며, 이후 클라이언트는 형식 오류나 노드 수 0을 보고할 수 있습니다.

구독 링크를 공개 검사 페이지에 붙여 넣지 말고, 도움을 요청하는 스크린샷에도 전체 링크를 표시하지 마세요. 링크에는 접근 인증 정보가 포함되는 경우가 많으므로 점검 시 도메인, 응답 상태, 오류 유형만 기록하면 됩니다. 링크를 비교해야 한다면 길이와 앞뒤 일부 문자만 비교하고 중간 매개변수는 가리세요. 클라이언트 로그에 전체 주소가 그대로 출력된다면 공유 전에 쿼리 매개변수를 삭제해야 합니다.

파싱 실패와 노드 목록이 비어 있는 경우

요청은 성공했지만 파싱에 실패했다면 먼저 클라이언트 종류를 확인하세요. 데스크톱에서는 v2rayN을, Android에서는 v2rayNG를 우선 사용하고, v2flyNG는 V2Fly 코어를 사용하는 대안으로 활용할 수 있습니다. 오래된 클라이언트는 구독에 새로 추가된 프로토콜 필드나 전송 옵션을 인식하지 못할 수 있습니다. 이 경우 다운로드 페이지에서 최신 설치 파일을 받아 구독 업데이트를 다시 실행하세요. 오래된 클라이언트에서 낯선 필드를 하나씩 삭제하지 마세요. 노드가 겉으로는 저장되어도 실제 핸드셰이크는 계속 실패할 수 있습니다.

노드 목록이 비어 있는 원인은 구독 그룹, 필터, 중복 제거 설정일 수도 있습니다. 먼저 이름 필터를 해제하고 모든 그룹을 확인한 뒤 업데이트가 현재 구독을 대상으로 실행됐는지 확인하세요. 메모 기준 중복 제거를 설정하면 이름이 같은 여러 노드 중 하나만 남을 수 있습니다. 오래된 노드 자동 삭제를 켜 둔 경우 응답이 비어 있으면 기존 목록까지 정리될 수 있습니다. 중요한 설정은 업데이트 전에 백업으로 내보내고, 점검 중에는 목록 구조를 바꾸는 자동 규칙을 끄세요. 응답 문제와 로컬 필터가 겹치는 일을 막을 수 있습니다.

같은 구독이 한 기기에서는 업데이트되고 다른 기기에서는 실패한다면 양쪽의 클라이언트 버전, 업데이트 프록시, DNS, 시스템 시간을 먼저 비교하세요. 모든 기기에서 같은 오류가 발생한다면 링크와 응답 서버에 초점을 맞춰야 합니다. 복구 후에는 “업데이트 성공” 메시지만 보지 말고 노드 수가 적절한지, 기존 노드가 예상대로 교체됐는지 확인한 다음 노드 하나를 무작위로 선택해 실제 연결을 완료하세요. 요청, 파싱, 연결 세 단계가 모두 통과해야 구독 경로가 복구된 것입니다.

고정된 대상으로 비교하기

직접 연결 시 안정적이고 콘텐츠 크기가 비교적 일정한 웹 페이지나 파일을 선택한 뒤, 프록시를 끈 상태, 현재 노드, 다른 노드의 세 조건에서 각각 테스트하세요. 매번 이전 다운로드가 끝날 때까지 기다리고 대역폭을 사용하는 동기화, 업데이트, 동영상 작업을 종료하며 같은 네트워크를 유지합니다. 여러 속도 측정 페이지의 평균을 내지 마세요. 테스트 서버 위치와 연결 수가 달라 새로운 변수가 생깁니다. 목표는 보기 좋은 숫자를 얻는 것이 아니라 병목이 노드, 네트워크, 특정 대상 사이트 중 어디를 따라 변하는지 확인하는 것입니다.

처음 열 때만 느리고 열린 뒤 전송이 정상이라면 DNS, TCP 연결, TLS 핸드셰이크를 우선 확인하세요. 지속 전송 속도는 낮지만 지연은 정상이라면 노드의 출구 대역폭, 경로 혼잡, 전송 방식을 확인합니다. 속도가 주기적으로 떨어지고 재전송이 동반된다면 무선 네트워크 품질, 패킷 손실, 경로 변동과 관련될 가능성이 높습니다. 특정 사이트 하나만 느리다면 해당 사이트와 노드 출구 사이의 라우팅이나 사이트 자체의 제한일 수 있습니다. 이러한 현상을 나누어 보는 것이 클라이언트 지연 시간만 확인하는 것보다 효과적입니다.

로컬 경로와 프로토콜 오버헤드 확인

먼저 같은 기기에서 직접 연결 네트워크를 테스트하세요. 무선 신호가 약하거나 주파수 대역이 혼잡하거나 백그라운드 업로드가 업로드 대역폭을 모두 사용하면 프록시 연결도 크게 느려집니다. 업로드가 포화되면 확인 패킷과 제어 패킷을 제때 보내기 어려워져 다운로드 대역폭에 여유가 있어도 웹 페이지가 끊길 수 있습니다. 클라우드 동기화, 시스템 업데이트, 대용량 업로드를 잠시 끄고 유선 네트워크나 액세스 포인트 가까운 위치에서 다시 테스트하세요. 직접 연결부터 불안정하다면 프로토콜을 바꿔도 안정적인 결론을 얻기 어렵습니다.

전송 캡슐화는 헤더와 핸드셰이크 비용을 늘릴 수 있지만 모든 성능 문제를 특정 프로토콜 이름 탓으로 돌려서는 안 됩니다. WebSocket, gRPC, TLS 조합의 성능은 실제 경로와 서버 설정에 따라 달라집니다. 구독에서 제공하는 노드 매개변수는 보통 한 세트로 설계되므로 속도를 높이려고 보안 계층을 끄거나 전송 방식을 임의로 바꾸지 마세요. 잘못된 조합은 간헐적으로 연결되더라도 지속 전송 중 재시도를 일으킬 수 있습니다. 올바른 방법은 설정이 완전한 다른 노드와 비교하는 것이지 기존 노드를 분해해 수정하는 것이 아닙니다.

라우팅·동시 연결·테스트 오차

규칙 모드에서는 도메인마다 다른 아웃바운드를 사용할 수 있습니다. 속도 측정 페이지의 메인 페이지, 테스트 API, 정적 리소스도 여러 도메인으로 나뉠 수 있어 최종 결과가 여러 경로의 혼합값이 될 수 있습니다. 진단할 때는 잠시 글로벌 모드를 사용해 관련 요청이 같은 노드를 거치는지 확인하세요. 글로벌 모드에서 뚜렷하게 개선된다면 노드 성능 이상으로 단정하지 말고 규칙 매칭을 확인해야 합니다. 로그의 아웃바운드 태그를 보면 요청이 프록시를 거쳤는지 직접 연결됐는지 확인할 수 있습니다.

동시 연결 수 역시 결과를 바꿉니다. 일부 속도 측정 도구는 많은 동시 연결로 대역폭을 채우지만 실제 웹 탐색은 짧은 연결이 많이 발생하는 방식입니다. 전자의 수치가 높다고 후자가 반드시 원활한 것은 아닙니다. 반대로 단일 연결 속도가 낮아도 전체 처리량이 반드시 낮은 것은 아닙니다. 웹 페이지가 느린 문제는 DNS와 핸드셰이크를, 다운로드가 느린 문제는 하나의 고정된 파일을, 동영상 버퍼링은 콘텐츠 전송 노드 선택을 확인하세요. 상황에 맞는 지표를 사용해 하나의 숫자로 모든 사용 경험을 설명하지 않도록 하세요.

모든 노드가 특정 네트워크에서만 느리고 네트워크를 바꾸면 복구된다면 로컬 접속 환경이나 네트워크 경로에 문제가 있을 가능성이 높습니다. 같은 노드가 모든 기기에서 느리고 다른 노드는 정상이라면 노드를 먼저 교체하세요. 특정 대상만 느리다면 라우팅과 대상 측 경로를 확인합니다. 위치를 파악한 뒤에는 임시로 끈 백그라운드 서비스, 라우팅 모드, 테스트 설정을 원래대로 돌려 일상 사용에 맞지 않는 설정이 남지 않도록 하세요.

시스템 확인과 내장 확인 구분

일반 시스템 프록시 모드에서는 앱이 먼저 시스템 DNS로 대상 주소를 받은 뒤 그 주소를 프록시에 전달할 수 있습니다. 일부 앱은 암호화 DNS를 별도로 사용해 시스템 설정을 따르지 않습니다. 가상 네트워크 인터페이스 모드에서는 더 많은 DNS 요청을 클라이언트가 처리할 수 있습니다. 세 경로가 함께 존재하면 같은 도메인에서 서로 다른 결과가 나올 수 있습니다. 점검 전에는 브라우저에 별도로 설정한 DNS 기능을 잠시 끄고 테스트 경로를 최대한 단순하게 만든 뒤, 클라이언트 로그에 해당 도메인이 나타나는지 확인하세요.

시스템 조회 도구로 기준 상태를 만들 수 있습니다. Windows에서는 Resolve-DnsName을 실행하고, macOS와 Linux에서는 nslookup 또는 dig를 사용할 수 있습니다. 먼저 서버를 지정하지 않고 시스템 기본 결과를 확인한 뒤 클라이언트 로그의 대상 주소와 비교하세요. 시스템에서는 확인되지만 클라이언트가 확인 실패를 보고한다면 클라이언트 내장 DNS 설정을 점검합니다. 둘 다 실패한다면 현재 네트워크의 DNS 서비스, 시스템 네트워크 설정, 도메인 철자를 확인하세요.

DNS / BASELINE

Resolve-DnsName example.com

nslookup example.com

dig example.com A
dig example.com AAAA

주소 체계와 라우팅 매칭 이해

도메인은 IPv4와 IPv6 주소를 동시에 반환할 수 있습니다. 현재 네트워크의 IPv6 경로가 완전하지 않으면 앱이 IPv6을 먼저 시도한 뒤 실패하고 나서야 되돌아가므로 첫 접속이 크게 지연될 수 있습니다. 조회 결과와 연결 로그로 실제 사용된 주소 체계를 확인하고 시스템 전체의 IPv6을 바로 끄지는 마세요. 클라이언트에 주소 전략이 있다면 로컬 네트워크 능력에 맞는 전략을 선택하세요. 변경 후 IPv4만 반환하는 도메인과 두 주소를 모두 반환하는 도메인을 각각 테스트해 새로운 접속 차이가 생기지 않았는지 확인합니다.

라우팅 규칙은 도메인으로 매칭하거나 확인된 주소로 매칭할 수 있습니다. 도메인 규칙에서 필요한 스니핑이나 도메인 보존 기능을 활성화하지 않았고 앱이 대상 주소만 제출하면 도메인 규칙이 적용되지 않을 수 있습니다. 반대로 주소 규칙에 지나치게 의존하면 콘텐츠 전송 주소 변경의 영향을 받습니다. 진단할 때는 로그에서 매칭된 규칙과 아웃바운드 태그를 확인하세요. 임시 글로벌 모드로 규칙 문제인지 검증할 수 있지만, 최종 수정은 명확한 도메인 또는 주소 규칙으로 돌아가야 합니다.

V2RAY / DNS STRUCTURE EXAMPLE

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

이 예시는 구조의 관계를 설명하기 위한 것이므로 클라이언트가 자동 생성한 전체 설정을 그대로 덮어쓰면 안 됩니다. servers의 순서와 도메인 범위는 조회 경로에 영향을 주며, localhost는 시스템 확인 경로를 사용한다는 뜻입니다. queryStrategy는 허용할 주소 유형을 결정합니다. 그래픽 클라이언트는 저장할 때 설정을 다시 생성할 수 있으므로 우선 화면에서 제공하는 DNS 설정을 수정하세요. 생성 로직을 명확히 이해한 경우에만 사용자 지정 설정 조각을 편집해야 합니다.

캐시·오염된 결과·검증 절차

DNS를 바꾼 뒤에도 이전 주소가 나온다면 시스템, 브라우저, 클라이언트 캐시가 삭제되지 않았을 수 있습니다. Windows에서는 ipconfig /flushdns로 시스템 캐시를 지울 수 있습니다. 브라우저는 완전히 종료한 뒤 다시 열고, 클라이언트는 코어를 재시작하세요. 캐시 삭제는 설정을 바꾼 뒤에만 실행하면 되며 매 단계마다 반복할 필요는 없습니다. 삭제 후 잠시 복구됐다가 다시 이상이 생긴다면 캐시를 원인으로 단정하지 말고 실제 조회 경로를 계속 확인하세요.

WINDOWS / CLEAR SYSTEM DNS CACHE

ipconfig /flushdns

유효한 해결 절차에는 세 가지가 포함되어야 합니다. 시스템 도구에서 합리적인 결과를 얻고, 클라이언트 로그에서 조회가 예상한 경로를 거치며, 실제 연결이 예상한 아웃바운드에 도달해야 합니다. DNS 주소만 바꾸고 나머지 두 항목을 확인하지 않으면 결과가 일시적으로만 달라질 수 있습니다. 테스트가 끝나면 브라우저의 원래 설정을 복원하고 여러 앱에서 확인해 특정 테스트 페이지만 통과한 것이 아닌 실제 사용 경로까지 해결됐는지 점검하세요.

주소·포트·프록시 유형 확인

v2rayN에서 시스템 프록시를 설정하면 Windows 프록시 페이지에 로컬 주소와 해당 HTTP 포트가 표시되어야 합니다. 흔한 오류는 SOCKS 포트를 HTTP 프록시만 받는 위치에 입력하거나, 클라이언트 포트를 바꾼 뒤에도 시스템에 이전 값이 남아 있는 경우입니다. 먼저 클라이언트 설정 화면에서 HTTP와 SOCKS의 실제 포트를 기록한 뒤 시스템 화면과 항목별로 비교하세요. 주소는 보통 루프백 주소입니다. 이미 바뀐 LAN 주소로 설정되어 있으면 오프라인 상태나 네트워크 전환 후 작동하지 않을 수 있습니다.

시스템에는 자동 구성 스크립트, 기업 정책, 브라우저 확장, 다른 프록시 소프트웨어가 함께 존재하며 제어권을 놓고 충돌할 수 있습니다. 클라이언트가 설정을 쓴 직후 몇 초 뒤 원래 값으로 돌아가거나 브라우저와 시스템 페이지에 서로 다른 프록시가 표시되는 것이 일반적인 증상입니다. 점검 중에는 프록시를 변경하는 다른 프로그램과 브라우저 프록시 확장을 잠시 끄고 하나의 제어 주체만 남기세요. 기기가 관리 정책의 영향을 받는다면 시스템 안내를 확인하고 레지스트리 값을 반복해서 쓰며 정책에 맞서지 마세요.

WINDOWS / CURRENT USER PROXY

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable,ProxyServer,AutoConfigURL

출력의 ProxyEnable은 수동 프록시가 활성화됐는지 확인하는 데 사용할 수 있고, ProxyServer는 현재 주소와 포트를 보여 주며, AutoConfigURL은 자동 구성 스크립트가 있는지 나타냅니다. 조회 결과는 진단에만 사용하고 시스템 설정과 클라이언트 화면에서 수정하세요. 레지스트리 값을 직접 편집하는 것은 권장하지 않습니다. 클라이언트를 종료한 뒤에도 프록시가 켜져 있으면 브라우저가 종료된 로컬 포트로 요청을 보내 “클라이언트 종료 후 인터넷이 완전히 끊기는” 현상이 나타날 수 있습니다. 이때 시스템 프록시를 끄면 직접 연결을 복구할 수 있습니다.

시스템 프록시와 가상 네트워크 인터페이스 모드 구분

시스템 프록시는 운영체제 프록시 인터페이스를 따르는 앱에 적합하고, 가상 네트워크 인터페이스 모드는 더 낮은 계층에서 작동해 프록시 설정이 없는 프로그램도 처리할 수 있습니다. 둘을 많이 켤수록 좋은 것은 아닙니다. 동시에 활성화하고 잘못 설정하면 트래픽이 클라이언트에 중복 유입되거나 루프가 생길 수 있습니다. 시스템 프록시를 진단할 때는 먼저 가상 네트워크 인터페이스 모드를 끄고 브라우저가 로컬 HTTP 인바운드를 통해 접속되는지 확인하세요. 시스템 프록시를 읽지 않는 앱까지 포함해야 할 때 가상 네트워크 인터페이스 모드와 라우팅 범위를 별도로 평가합니다.

명령줄 도구는 자체 프록시 변수를 사용하는 경우가 많습니다. 예를 들어 일부 도구는 HTTP_PROXY와 HTTPS_PROXY를 읽지만 데스크톱 시스템 프록시를 자동으로 사용하지 않습니다. 테스트할 때는 현재 터미널 세션에만 변수를 설정하고 처음부터 전역 영구값으로 만들지 마세요. 프록시 주소에는 클라이언트의 실제 HTTP 포트를 사용하고, 클라이언트를 종료한 뒤에는 변수도 삭제해 이후 명령이 종료된 포트로 계속 연결하지 않도록 하세요.

SHELL / SESSION PROXY EXAMPLE

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

unset HTTP_PROXY
unset HTTPS_PROXY

앱별로 요청이 코어에 들어오는지 확인

클라이언트 로그를 비운 뒤 대상 앱에서 식별 가능한 요청 하나만 실행하세요. 로그에 해당 도메인이나 주소가 나타나면 앱 트래픽이 코어에 유입된 것이므로 이후 라우팅과 아웃바운드를 확인해야 합니다. 아무 기록도 없다면 문제는 여전히 앱과 로컬 인바운드 사이에 있습니다. 브라우저는 먼저 모든 프록시 확장을 끄고 다시 시작하세요. 업무용 소프트웨어와 개발 도구는 각 앱의 네트워크 설정을 확인해야 합니다. 브라우저가 된다고 해서 모든 앱이 시스템 프록시를 사용하는 것은 아닙니다.

복구의 기준은 시스템 스위치가 켜져 있는지가 아니라 대상 앱의 요청 하나가 클라이언트 로그에 나타나 예상한 라우팅을 통해 정상적으로 반환되는지입니다. 로그에 요청이 전혀 없다면 원격 노드를 계속 바꿔도 효과가 없습니다. 요청은 들어왔지만 실패한다면 노드, DNS, 라우팅 항목으로 돌아가 점검하세요. 로그를 경계로 삼으면 “앱이 트래픽을 넘기지 않은 경우”와 “코어가 트래픽을 전달하지 못한 경우”를 정확히 나눌 수 있습니다.

UI 프로세스와 코어 프로세스 구분

v2rayN 데스크톱 버전에는 그래픽 UI와 실제 트래픽을 처리하는 코어 프로세스가 함께 있습니다. UI는 조작할 수 있지만 모든 요청이 실패한다면 코어가 정상적으로 시작되지 않았을 수 있습니다. UI가 바로 종료된다면 앱 로그와 시스템 이벤트를 확인해야 합니다. 먼저 충돌이 시작 시, 노드 전환 시, 구독 업데이트 시, 가상 네트워크 인터페이스 활성화 시 중 언제 발생하는지 기록하세요. 안정적으로 재현되는 동작이 문제를 찾는 근거입니다. “가끔 충돌”보다 “특정 설정을 가져온 뒤 연결을 클릭하자마자 종료”라고 기록하는 편이 훨씬 유용합니다.

작업 관리자 또는 활성 상태 보기에서 이전 코어 프로세스가 남아 있는지 확인하세요. 이전 프로세스가 포트를 점유하면 새 코어가 시작되지 않을 수 있습니다. 여러 클라이언트를 동시에 실행해도 시스템 프록시, 가상 네트워크 인터페이스, 수신 포트를 놓고 충돌할 수 있습니다. 관련 클라이언트를 모두 종료하고 프로세스가 끝날 때까지 기다린 뒤 하나만 실행해 테스트하세요. 프로세스가 정상적으로 종료되지 않는다면 먼저 로그를 저장한 다음 해당 프로세스를 종료하세요. 잔류 프로세스 관계를 가리기 위해 바로 기기를 재시작하지 마세요.

설정 손상과 권한 문제 처리

특정 설정 편집이나 구독 업데이트 직후 충돌이 시작됐다면 현재 설정을 먼저 내보낸 뒤 최소 테스트 환경을 만드세요. 최근 가져온 비정상 노드를 삭제하고 자동 시작, 자동 구독 업데이트, 가상 네트워크 인터페이스를 끈 다음 구조가 명확한 노드 하나만 남깁니다. 최소 환경이 시작되면 설정을 하나씩 복원하세요. 이전 데이터 디렉터리 전체를 새 설치 위치에 한 번에 복사하지 마세요. 손상된 설정과 이전 경로까지 그대로 따라올 수 있습니다.

설치 디렉터리 권한은 로그, 데이터베이스, 코어 파일 쓰기에도 영향을 줍니다. 데스크톱 클라이언트는 현재 사용자가 읽고 쓸 수 있는 위치에 두고, 계속 권한 상승이 필요한 디렉터리는 피하세요. 압축 파일에서 실행한다면 먼저 완전히 압축을 푼 뒤 실행해야 하며 압축 도구의 임시 화면에서 바로 실행하지 마세요. 보안 소프트웨어가 코어 파일을 격리하면 UI만 남고 연결되지 않을 수 있습니다. 시스템 보안 기록에서 처리 이유를 확인한 뒤 설치 파일 페이지에서 플랫폼에 맞는 클라이언트를 다시 받으세요.

Windows 데스크톱 버전과 클래식 WPF 버전은 사용하는 UI 기술이 다릅니다. 특정 UI가 현재 시스템 환경에서 안정적으로 시작되지 않는다면 먼저 실행 환경과 시스템 업데이트를 확인한 뒤 다운로드 페이지에 제공된 다른 데스크톱 경로로 비교해 보세요. 버전을 바꾸기 전 구독 주소와 라우팅 설정을 보존하고, 첫 실행은 새 디렉터리에서 진행하며 기존 디렉터리를 덮어쓰지 마세요. 이를 통해 문제가 UI 실행 환경에 있는지, 공유 설정이 원인인지 구분할 수 있습니다.

로그·리소스·재현 정보

로그 수준이 너무 높으면 장시간 실행 중 디스크에 대량으로 기록될 수 있습니다. 특히 모든 연결을 상세 디버그 정보로 남기는 경우가 그렇습니다. 평소에는 일반 수준을 유지하고 문제를 재현하는 짧은 시간에만 상세도를 높이세요. 재현하기 전에 기존 로그를 비우고 한 번만 동작을 실행한 뒤 즉시 저장합니다. 이렇게 하면 개인 설정 정보 노출을 줄이고 수만 줄의 오래된 기록 속에서 실제 오류를 찾는 일도 피할 수 있습니다.

디스크 여유 공간, 메모리 사용량, 시스템 절전 모드 복귀도 관찰해야 합니다. 디스크 공간이 부족하면 데이터베이스나 로그 기록이 실패할 수 있습니다. 절전 모드에서 복귀한 뒤 네트워크 인터페이스가 바뀌면 이전 연결과 가상 네트워크 인터페이스 상태가 제대로 재구성되지 않을 수 있습니다. 충돌이 절전 모드 해제 후에만 발생한다면 클라이언트를 종료했다가 다시 시작해 복구 과정의 문제인지 확인하세요. 새로 시작해도 발생한다면 설정과 실행 환경을 계속 점검합니다.

재설치는 설정과 환경을 비교한 뒤에 진행해야 합니다. 올바른 재설치 테스트는 기존 디렉터리를 덮어쓰지 않고 새 디렉터리에서 현재 설치 파일을 시작하며, 기존 설정 전체를 가져오지 않고 최소 설정만 추가하는 것입니다. 새 환경이 안정적이면 구독과 라우팅을 단계적으로 옮기세요. 새 환경에서도 같은 동작에서 충돌한다면 시스템 환경, 드라이버, 특정 설정 형식에 문제가 있을 가능성이 높습니다. v2rayN Windows 설치 설정 및 흔한 문제를 참고하면 데스크톱 실행 환경과 시스템 프록시 잔여 설정을 더 확인할 수 있습니다.

VPN 인터페이스와 단독 사용 여부 확인

연결을 시작하면 시스템에 VPN 권한 요청이 나타나고 해당 상태가 표시되어야 합니다. Android에서는 일반적으로 한 번에 하나의 앱만 시스템 VPN 인터페이스를 사용할 수 있으므로 다른 VPN, 네트워크 필터 도구, 업무 프로필의 네트워크 서비스가 v2rayNG와 v2flyNG의 인터페이스 생성을 막을 수 있습니다. 먼저 다른 VPN 앱을 끊은 뒤 현재 클라이언트에 다시 연결하세요. 권한 대화상자가 더 이상 나타나지 않고 상태가 즉시 종료된다면 시스템 VPN 설정에서 이전 권한을 삭제한 뒤 다시 시도하세요.

항상 VPN 사용과 “VPN을 사용하지 않는 연결 차단”은 시스템 수준의 정책입니다. 설정이 올바르면 트래픽 경로를 제한할 수 있지만, 클라이언트 코어가 시작되지 않거나 구독이 만료됐거나 노드를 사용할 수 없을 때 기기 전체가 오프라인처럼 보일 수 있습니다. 점검 단계에서는 먼저 두 항목을 끄고 일반 연결이 복구되는지 확인한 다음 클라이언트를 별도로 테스트하세요. 문제를 찾은 뒤 다시 활성화할지는 실제 네트워크 정책에 따라 결정해야 하며, 시스템 차단을 클라이언트가 종료되지 않는 문제로 오해해서는 안 됩니다.

백그라운드 및 배터리 제한 해제

일부 기기는 화면이 꺼지거나 앱을 전환하거나 일정 시간 전면 활동이 없으면 백그라운드 프로세스를 제한합니다. 연결 직후에는 정상인데 몇 분간 화면을 잠그면 모든 요청이 멈추고 클라이언트를 다시 열면 복구되는 것이 대표적인 증상입니다. 시스템 앱 설정에서 클라이언트의 백그라운드 실행을 허용하고 배터리 정책을 제한 없음으로 설정하며 필요한 백그라운드 데이터를 허용하세요. 기기마다 메뉴 이름은 다를 수 있지만 판단 기준은 같습니다. 화면이 꺼진 뒤에도 클라이언트 프로세스가 유지되는지, VPN 상태가 시스템에 의해 회수되지 않는지 확인해야 합니다.

여러 클라이언트에 자동 연결을 동시에 설정하지 마세요. v2rayNG와 v2flyNG는 서로 다른 코어 환경에서 사용할 수 있지만, 한 번의 점검에서는 하나만 실행해야 합니다. 두 앱이 VPN 권한을 번갈아 차지하면 상태 표시 아이콘이 깜박이거나 연결 직후 끊기거나 시스템이 계속 다른 앱으로 돌아갈 수 있습니다. 테스트하지 않는 클라이언트를 먼저 강제 종료한 뒤 현재 클라이언트의 배터리 제한과 자동 시작 정책을 정리하세요.

앱별 설정·Private DNS·네트워크 전환 확인

앱별 프록시는 어떤 앱을 VPN에 포함할지 선택하거나 제외 방식으로 설정할 수 있습니다. 규칙 방향을 잘못 이해하면 브라우저는 정상인데 대상 앱은 직접 연결되거나, 제외된 앱만 작동하는 현상이 나타납니다. 진단할 때는 먼저 앱별 기능을 끄고 모든 앱을 같은 경로로 보내세요. 연결이 정상임을 확인한 후 앱을 하나씩 포함하거나 제외합니다. 규칙을 바꿀 때마다 대상 앱을 완전히 종료했다가 다시 열어 이전 경로를 사용하는 기존 연결을 제거하세요.

시스템 Private DNS와 클라이언트 내장 DNS가 동시에 작동할 수 있습니다. Private DNS 호스트에 접근할 수 없으면 도메인 요청이 클라이언트에 들어오기 전에 실패할 수 있습니다. 앱이 자체 암호화 DNS를 사용하면 클라이언트 라우팅에는 조회 서비스 연결만 보일 수도 있습니다. 점검할 때는 Private DNS를 잠시 자동으로 되돌리고 브라우저의 독립 DNS를 끈 뒤 시스템 조회 경로를 테스트하세요. 복구된다면 시스템 Private DNS와 클라이언트 DNS 중 하나를 선택하고 여러 계층이 중복으로 제어하지 않도록 하세요.

무선 네트워크에서 모바일 네트워크로 전환하면 로컬 주소, 기본 경로, 사용 가능한 주소 체계가 모두 바뀝니다. 기존 연결 일부가 자동으로 이동하지 않아 VPN은 연결된 상태인데 요청만 멈출 수 있습니다. 네트워크 전환 후 시스템 연결이 안정될 때까지 기다린 다음 클라이언트를 끊었다가 다시 연결하세요. 한 네트워크에서만 실패한다면 노드와 클라이언트 설정을 유지하고 해당 네트워크의 DNS, IPv6 경로, 인증 페이지를 비교하세요. 공용 무선 네트워크는 직접 연결 상태에서 웹 인증을 먼저 완료한 뒤 VPN을 시작해야 합니다.

Android에서 구독 업데이트는 백그라운드 데이터와 현재 VPN 경로의 영향도 받습니다. 업데이트 결과가 빈 목록이어도 기존 노드를 바로 삭제하지 마세요. 먼저 클라이언트의 네트워크 사용이 허용됐는지와 구독 링크가 완전한지 확인하고, 연결 상태와 연결 해제 상태에서 각각 업데이트를 테스트하세요. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용하므로 구독의 일부 필드에 대한 지원 범위가 다를 수 있습니다. 비교할 때는 같은 네트워크와 같은 구독을 유지하고 코어, 노드, DNS를 동시에 바꾸지 마세요.

마지막으로 앱 로그의 시간 순서를 확인하세요. VPN 인터페이스가 생성됐는지, 코어가 시작됐는지, 노드 핸드셰이크가 완료됐는지, DNS가 결과를 반환했는지를 순서대로 봅니다. 인터페이스가 생성되지 않았다면 시스템 권한을 처리하세요. 인터페이스는 생성됐지만 코어가 종료됐다면 설정과 클라이언트를 확인합니다. 코어는 실행 중인데 노드가 시간 초과를 일으킨다면 노드 항목으로 돌아가세요. 특정 앱만 실패한다면 앱별 규칙을 점검합니다. 이 경계를 따라가면 기기의 전체 네트워크 설정을 지우지 않고도 이미 검증된 설정을 보존할 수 있습니다.